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 <david_jencks@yahoo.com>
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 <david_jencks@yahoo.com> 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