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 [EMAIL PROTECTED] http://dankulp.com/blog
