geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: jaxb 2.2 problem in osgi branch
Date Sat, 07 May 2011 06:06:33 GMT
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
> 


Mime
View raw message