Per the search order defined in OSGi runtime classloading, it will delegate the request class to parent classloader if its name matches the bootdelegate names, and it will try other strategies if it is not found.
I guess the problems is that the jaxb-api and jaxb-impl bundle are not started in your environment, so our OSGi registry did not register those SPI. While doing the lifecycle changing in the past, the similar problem is found. The final solution is to introduce a "eargerStart" tag in the geronimo-plugins.xml file, which means those bundles will be class loading ready only when they are active.
Hope it helps.
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.