I don't know if it's related but I thought I'd record something about a problem I ran into today.
Apparently if you modify a generated jaxb class by changing a Boolean field to boolean the 2.2 jaxb runtime implementation generates a class at runtime that directly accesses com.sun.xml.bind classes. I think the safest way to proceed here (since as Ivan points out the corresponding class would be in a different package for the 2.1 implementation in the vm) is to not change the type of the field or accessors but provide a default value of Boolean.FALSE and rely on autoboxing. Unfortunately I didn't record the stack trace or generated class name. thanks david jencks On May 4, 2011, at 11:27 PM, David Jencks wrote: > You are certainly correct that the package names are different. When I have > a few minutes I'll try removing my changes and see what happens and verify > which classes are having problems. > > thanks > david jencks > > On May 4, 2011, at 5:16 PM, Ivan wrote: > >> The package name of jaxb impl shipped with JRE is com/sun/xml/internal/..., >> and the package name of jaxb impl bundle is com/sun/xml/.... It looks to me >> that once the SPI is located correctly, it would never load the class from >> vm, as those classes could not be found there. I do not think that some >> exclusion for the package is required in this scenario. Do I miss anything ? >> >> 2011/5/5 David Jencks <[email protected]> >> I solved this problem, at least for car-maven-plugin, by setting the >> bootdelegation to include all the com.sun packages in the class library >> other than com.sun.xml.bind. I wish there was an exclusion syntax for the >> bootdelegation property. >> >> Further thoughts are definitely welcome.... >> >> thanks >> david jencks >> >> On May 4, 2011, at 7:56 AM, Jarek Gawor wrote: >> >> > The only difference I'm aware of that we have between Karaf and >> > Geronimo configuration is the org.osgi.framework.bundle.parent >> > property. Karaf sets it to org.osgi.framework.bundle.parent=framework >> > while we don't set it in Geronimo and it defaults to "boot". But that >> > really shouldn't make any difference in this case as far as I can >> > tell. >> > >> > Jarek >> > >> > On Wed, May 4, 2011 at 3:57 AM, David Jencks <[email protected]> >> > wrote: >> >> I've run into a problem in the osgi branch that I don't really understand >> >> yet. >> >> >> >> AFAICT in the trunk 3.0 server we install our jaxb 2.2 spec jar and the >> >> sun/oracle jaxb 2.2. implementation as a bundle. Furthermore when we try >> >> to use jaxb e.g. for parsing spec dds, this works and we are actually >> >> using the 2.2 bundle. We also have boot delegation of com.sun packages >> >> turned on. >> >> >> >> In the osgi branch, the car plugin runs a karaf instance in the maven vm. >> >> After the framework gets built, we start needing to install the jaxb 2.2 >> >> stuff. So, I wrote a little feature to install the specs, woodstox, and >> >> the jaxb 2.2 impl. However, now the com.sun bootdelegation seems to be >> >> kicking in so that as soon as the jaxb implementation gets to com.sun >> >> classes they are loaded from the framework/vm rather than the jaxb 2.2 >> >> imple bundle. >> >> >> >> This pretty much makes sense to me since we have the com.sun.* >> >> bootdelegation which IIUC is supposed to override any imports you may >> >> specify. However, what appears to me to be the same bundles seem to be >> >> working fine in trunk. >> >> >> >> Does anyone have any ideas how to make this work in the osgi branch or >> >> why it works in trunk? >> >> >> >> To see the problem, you can check out server/branches/3.0-osgi and build >> >> framework and plugins/j2ee. The problem appears in >> >> plugins/j2ee/j2ee-deployer. You may have to use -Pstage-bootstrap to get >> >> the car-maven-plugin to build the first time. >> >> >> >> many thanks >> >> david jencks >> >> >> >> >> >> >> >> >> -- >> Ivan >
