geronimo-dev mailing list archives

On Monday 17 November 2008 8:22:21 pm Kevan Miller wrote:
> On Nov 17, 2008, at 4:35 PM, Daniel Kulp wrote:
> > On Monday 17 November 2008 4:19:45 pm Donald Woods wrote:
> >> Sorry, I was away on vacation last week.
> >>
> >> Does anyone know of technical reason why we can't move to Java SE 6
> >> and
> >> use the JAXB/JAX-WS implementation provided in the JDK?
> >
> > Yes. There are parts of CXF that won't work without the non-
> > mungled versions
> > JAXB. (the versions in the JDK are package mungled.) I've
> > STARTED going
> > down the route of using ASM and other trickery to get it working on
> > cxf's
> > trunk, but that's not on the 2.1.x branch.
>
> Thanks for the info, Dan. For collective awareness, could I ask you to
> be a bit more specific about the "packaged mungled" versions of JAXB?
>
> --kevan
When Sun puts things into the JDK, they tend to mangle the package name from
their standalone versions to something else. In the case of JAXB, they
changed the com.sun.xml.bind package to com.sun.xml.internal.bind. That's
fine if you JUST need to use the public API's in javax.xml.bind, but to do a
bunch of more advanced things, you need to interact directly with stuff in
the the com.sun packages.
In particular, there are several area's that we need to do so:
1) Namespace mapping - to customize the namespace mapping, you have to
subclass a class in the com.sun.xml.bind package. Thus, if you subclass the
version for "external" jaxb, that class doesn't work for the "internal" jaxb
(class cast exception) since the parent is diffent. (and vice versa)
2) Do to some advanced Map/interface mapping WITHOUT generating wrapper types
first, you need to use the JAXB bridge things that are in com.sun. However,
this isn't "normal" for CXF anymore. If you have ASM on the classpath, we
generate wrapper classes in memory. That solve this without the bridges.
However, if you don't have asm, you still need the bridges.
3) The "default" namespace mapping, while just a string property name, also
changed. What's worse, if you pass the other property in a context creation
time, it throws an exception. Thus, you kind of have to try one, catch any
exception, try the other.
4) For code generation time (wsdl->java) even more problems come up. First,
NONE of XJC is in javax.xml. It's all in com.sun.xml.bind packages. So
all of that changes. Plus, XJC plugins have the same "superclass has
changed" problem. XJC plugins written for external JAXB won't work
with "internal" jaxb. In fact, if you have the external plugins even on the
classpath, the internal xjc won't even run at all.
On trunk, I've tackled 1 - 3. 4 is a ton of work that I haven't had time to
complete. The XJC plugin stuff is also something I have absolutely no idea
how to handle. :-(
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog