geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: [DISCUSS] Only Support Java SE 6 with Geronimo 2.2
Date Tue, 18 Nov 2008 01:38:54 GMT
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

Mime
View raw message