From dev-return-90422-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Sat May 7 06:07:13 2011 Return-Path: X-Original-To: apmail-geronimo-dev-archive@www.apache.org Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E7B2423AE for ; Sat, 7 May 2011 06:07:13 +0000 (UTC) Received: (qmail 22964 invoked by uid 500); 7 May 2011 06:07:13 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 22504 invoked by uid 500); 7 May 2011 06:07:10 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 22480 invoked by uid 99); 7 May 2011 06:07:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 May 2011 06:07:06 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [98.136.44.62] (HELO smtp107.prem.mail.sp1.yahoo.com) (98.136.44.62) by apache.org (qpsmtpd/0.29) with SMTP; Sat, 07 May 2011 06:06:58 +0000 Received: (qmail 93801 invoked from network); 7 May 2011 06:06:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer; b=5X2zVU6hPVehQ0hOz9BooBaRszLfiiAqD2EzOj9jz/qR+ULfj+y0IdCOuYfSrkMGQY1HhDBqb2vGogzYHCxsjtHbRo+f0Bc3SUTdU8yFK+3WX4yUf7ZeVa4GUXS+rpIJ5Nh+FarLtqSWiMEkziixwKmfwRFh20epDW7aEpmKdXk= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1304748396; bh=EP+vShgqo3EoPQIpLIA5Qdbm6qJ8uzpN7qHq5HXdT0s=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer; b=ePzf9MtKOpTZudc8/9bwukaz3G2zFMNJVdweMQ4bP1TzmWZfEgY0ZDarp5klPXa7HDoNJrGWsGuummzkgU3u4bwwgBr8w/iUN4+cWkkU6KOoXToYAsSw3YBCeCoth0B3fyiiJPUqH5qk70znCYTwfqv3hh7mpdjyAfqCNojfMdQ= Received: from [10.0.1.147] (david_jencks@76.76.148.215 with plain) by smtp107.prem.mail.sp1.yahoo.com with SMTP; 06 May 2011 23:06:35 -0700 PDT X-Yahoo-SMTP: .9oIUzyswBANsYgUm_5uPui0skTnzGJXJQ-- X-YMail-OSG: L1LjKBUVM1lwH8xcM7HvOD7.XaOGnY0RkJVo6Z42_2ccmye oonbu1JhJ9BLynns6g1qmThKg5nakpWUFwMoQ80hVrZ7tz_D6G0rz6mB76NU QtNbP9.sgG659QooeiUnaVbDbr7vCl2q3YHIJJB0vylaU.cxbiPRVNn6D0VP mM96of1pwFnO47fPmXeRbF2snKwbD.A.hgLQrPEZULDN_aUtkYORsAxnZJ2k 7LsfrQzkLLSG8NSv88ECRQAF6wwZHCUStPOQMBqb38xg5p8LWmUSVMFNA2nE 1zUmw4sKdV2qe86NPFMpGV0.cnrzAWyeLEbj63RWHOcl48110RyaJOisYO5H QLDvw2llsD0uwnt5PBkp9NsdoNWRjp3AJaYGqIzTH6mKc2JqJSAVQpmHVkDT 37OYEUH2rtY5Yr5r.5nLTUVY5.S06 X-Yahoo-Newman-Property: ymail-3 From: David Jencks Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-9-23679644 Subject: Re: jaxb 2.2 problem in osgi branch Date: Fri, 6 May 2011 23:06:33 -0700 In-Reply-To: To: dev@geronimo.apache.org References: <43171A49-CDB3-4898-AB0E-386769E53383@yahoo.com> <49D852BD-F21F-438F-AF3D-A2D2F3964393@yahoo.com> Message-Id: <3861447A-DC48-4474-850B-768391D52C80@yahoo.com> X-Mailer: Apple Mail (2.1084) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-9-23679644 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. >=20 > thanks > david jencks >=20 > On May 4, 2011, at 5:16 PM, Ivan wrote: >=20 >> 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 ? >>=20 >> 2011/5/5 David Jencks >> 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. >>=20 >> Further thoughts are definitely welcome.... >>=20 >> thanks >> david jencks >>=20 >> On May 4, 2011, at 7:56 AM, Jarek Gawor wrote: >>=20 >> > 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=3Dframework >> > 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 = 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 >> >> >> >> >>=20 >>=20 >>=20 >>=20 >> --=20 >> Ivan >=20 --Apple-Mail-9-23679644 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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=3Dframework
> 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
=


= --Apple-Mail-9-23679644--