tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <enjoyj...@gmail.com>
Subject Re: [2.x] Classloading Failures running under OSGi with recent code
Date Tue, 04 Aug 2009 23:42:04 GMT
More comments inline.

Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <mike.edwards.inglenook@gmail.com>
Sent: Tuesday, August 04, 2009 2:36 PM
To: <dev@tuscany.apache.org>
Subject: Re: [2.x] Classloading Failures running under OSGi with recent code

> Raymond,
>
> Comments inline.
>
> Raymond Feng wrote:
>> Hi,
>>
>> There might be a few changes that expose the issue:
>>
>> 1) I recently added some code to create a "gateway" bundle that uses the 
>> "Require-Bundle" to aggregate split packages including 
>> "META-INF.services".
>
> Not sure that I follow the scenario that you're trying to deal with here. 
> What does META-INF/services have to do with split packages?

To make the service provider pattern working with 3rd party jars, we need to 
support:

ClassLoader.getResources("META-INF/services/<...>")

In OSGi, it means that the META-INF.services package is exported by the 
bundle that owns the META-INF/services/<...>. But typically there are more 
than one jar that contains the META-INF/services. The META-INF.services 
becomes a split package.

Let's say Bundle A and Bundle B contain META-INF/services/<...>, then set up 
A and B with:

Export-Package: META-INF.services;partial=true;mandatory:=partial

This creates a conditional export for Import-Package with a mandatory 
attribute partial=true. Require-Bundle ignores the "mandatory" directive. So 
we create a Bundle C so that:

Require-Bundle: A,B
Export-Package: META-INF.services

C sees the META-INF.services from A and B and reexports it. Now C exports 
META-INF.services as the aggregation of META-INF.services from A and B.

>
>> 2) The bundle class loader for tuscany-extensibility-equinox (which has 
>> DynamicImport-Package: *) is used as the parent classloader of the 
>> non-OSGi contributions.
>> 3) The org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider now 
>> uses the following classloaders in order:
>>     * The tuscany-binding-ws-axis2 bundle classloader
>>     * The axis2 bundle classloader
>>     * The tuscany-extensibility-equinox bundle classloader
>>     * The TCCL
>>
>
> Why do you need 4 classloaders?

This is nasty hack. The TCCL needs to access classes from:
a) The axis2 bundle
b) The tuscany-binding-ws-axis2 bundle (we contribute a set of 
MessageReceiver classes into the axis2.xml)
c) Other 3rd party jars (this can be redundant if axis2 bundle has 
DynamicImport-Package *)

We could remove the current TCCL.

>
>> I could see the OSGi launcher failure for otest that complains about 
>> ClassNotFoundException for SOAP11Factory and SOAP12Factory. This is a 
>> known issue and we override the MF in producing the distribution.
>
> The fix you have above for Axis2ServiceProvider works fine for services 
> exposed using binding.ws. Unfortunately, it does not handle references 
> that use binding.ws - these require a classloading fix in 
> Axis2ServiceClient.

You are right. It needs to have the same fix as for the service side.

>
>>
>> I just added the same customization for the launcher under [1]. With this 
>> change, I can run the otests under OSGi.
>>
>> What led you to believe that the classloader is the application 
>> classloader? Is it the output message as follows?
>>
>> SCA Node API ClassLoader: sun.misc.Launcher$AppClassLoader@11b86e7
>>
>> This is a false alarm as the printout is on a proxy of the Node in the 
>> application classloader. The real node is loaded by OSGi as we can see 
>> from the debugger.
>
> Debugging the "ClassNotFound" exception for one of the Tuscany classes 
> related to Axis (one of our Message handlers) showed me that the App class 
> loader was being used.  Turned out the Axis code was getting this from the 
> TCCL.  So my fix replaces the TCCL in Axis2ServiceClient.
>
>>
>> Can you point to me the failing test cases you ran into? If the fix in 
>> [1] doesn't help, I can further debug.
>
> Can you explain what this fix does?

This fixes the MANIFEST.MF for axiom-api-1.2.7 which is missing a few import 
packages to SOAP11Factory and SOAP12Factory in the equinox launcher.

>
> The testcases I've been using are the OASIS ones:
>
> ASM_9003_TestCase
> ASM_12005_TestCase
>
>>
>> [1] http://svn.apache.org/viewvc?rev=800929&view=rev
>>
>> Thanks,
>> Raymond
>> --------------------------------------------------
>> From: "Mike Edwards" <mike.edwards.inglenook@gmail.com>
>> Sent: Tuesday, August 04, 2009 5:59 AM
>> To: "tuscany-dev" <dev@tuscany.apache.org>
>> Subject: [2.x] Classloading Failures running under OSGi with recent code
>>
>>> Folks,
>>>
>>> In the past 2 days, I have run into classloading failures with both the 
>>> BPEL runtime module and with the Axis2 WS Binding module.
>>>
>>> Since these failures did not occur in code previously, I assume that 
>>> there has been some significant change in the handling of classloaders 
>>> in the 2.x stream recently.  I'd be grateful if someone could explain 
>>> what changes have been made.  I'd also like to pose the question as to 
>>> why the failures have not been picked up by any testcases?
>>>
>>> The problem appears to be with 3rd party code that use the Thread 
>>> Context ClassLoader to load classes.  The symptom is that we get class 
>>> not found errors since under OSGi the bulk of our code is loaded with 
>>> OSGi classloaders and the TCCL in the recent builds seems to be the app 
>>> class loader.
>>>
>>> I fixed the BPEL code by forcing the TCCL to be the OSGI Bundle 
>>> ClassLoader used for loading the BPEL runtime module classes, in 
>>> EmbeddedODEServer.init().
>>>
>>> I fixed the Axis client code by a similar means of forcing the TCCL to 
>>> be the OSGi Bundle ClassLoader, in 
>>> Axis2ServiceClient.createServiceClient().
>>>
>>>
>>> Yours,  Mike.
>>
>>
> 

Mime
View raw message