tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Edwards <mike.edwards.inglen...@gmail.com>
Subject Re: [2.x] Classloading Failures running under OSGi with recent code
Date Tue, 04 Aug 2009 21:36:43 GMT

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?

> 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?

> 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
in Axis2ServiceClient.

> 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?

The testcases I've been using are the OASIS ones:


> [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. 

View raw message