tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Nash <n...@apache.org>
Subject Re: Contributions and Runtime Classpath
Date Thu, 08 Dec 2011 10:32:28 GMT
Millies, Sebastian wrote:
>> -----Original Message-----
>> From: Simon Nash [mailto:nash@apache.org]
>> Sent: Wednesday, December 07, 2011 9:50 PM
>> To: user@tuscany.apache.org
>> Subject: Re: Contributions and Runtime Classpath
>> Simon Nash wrote:
>>> Millies, Sebastian wrote:
>>>> Hello there,
>>>> I am having a class loading problem, and want to make sure that I
>>>> understand what a contribution is.
>>>> My setup is as follows: At some point I want my SCA code to
>>>> dynamically load
>>>> classes (customer-specific stuff provided by the customer at
>>>> deployment time).
> [snip]
>>>> When I do
>> Thread.currentThread().getContextClassLoader().loadClass(className)
>>>> I get a ClassNotFoundException. What may I be overlooking?
>> Tuscany uses contribution classloaders for loading code from
>> contributions.
>>> To get classes loaded by these classloaders, you need to use the SCA
>>> contribution import/export mechanism.
> Why does serviceInstance.getClass().getClassLoader() not give me the
> ContributionClassLoader that loaded the SCA service instance, but the
> Java application class loader?
My guess is that you have broken the "golden rule" to keep all your
contribution classes off the Java classpath.  The contribution classloaders
delegate to the application classloader, so if the same class is
available from both classloaders then it will be loaded by the application

> Isn't there some way for a service implementation to gain access to its
> contribution class loader at run time?
Yes, it should work if you follow the "golden rule" as stated above.

> Or is there a way to subclass the contribution class loader and load
> the extension through the subclass? For that, I'd need to be able to
> construct the contribution that I know the extension class is in from its
> location (given that I can at least know the jar file name, see below).
I wouldn't recommend that.  The contribution classloader is a private
Tuscany implementation class, not a publicly available extension point.

>>> It is possible to set things up so that code is loadable by a
>> contribution
>>> classloader as well as by the thread context classloader and/or the
>> system
>>> classloader that Java uses to start the application.  However this
>> can
>>> cause problems with contribution import/export not working properly,
>>> so this setup isn't a good idea IMO.
> How would one set up things this way? Is there an example? And is it
> a fundamental problem that import/export does not work correctly in this
> case, or rather a bug that may be fixed?
See the travel sample scenario that I mentioned previously for details
of how to do this.  It's important to make sure that no contribution
classes appear on the application classpath.

No, it's not a bug.  It's a consequence of the classloader delegation
model, which causes classes that belong to a contribution to be loaded
by the application classloader instead (see above).  The application
classloader doesn't understand SCA import and export, so you don't get
the right semantics for these.

>>> I prefer to set things up with the contribution classloaders separate
>> from
>>> the system classloader and thread context classloader.  You can see
>> some
>>> examples of this setup in the travel sample--look at the Introducing
>>> scenario which bootstraps by loading three contributions in the
>> launcher,
>>> then hands control to one of them.  All the classes in these
>> contributions
>>> aren't present on the Java system classpath and aren't loaded by the
>>> thread context classloader.
> Yes, that looks quite like my code in the original post.
If you look at the complete example you'll see that none of the
contribution classes appear on the application classpath.  Only
the launcher class is loaded from that classpath.  This is vital
to make things work correctly.

>>> Can you say more about why you are trying to load contribution
>> classes
>>> using the thread context classloader?
>>>   Simon
>>  >
>> Some further thoughts on this: perhaps the issue is that you don't know
>> the Java packages of the customer classes and therefore can't list
>> these
>> classes in export and import statements.  If so, I don't think you will
>> be able to use contributions to load these classes.  However, if you do
>> know the package names then I think you should probably be able to make
>> this work using contributions if you set things up correctly.
>>    Simon
> That is exactly it. The customer can provide his own classes for certain tasks
> (enriching data, accessing proprietary data stores, exporting to Excel sheets,
> printing etc.). In some cases I may be able to prescribe at least a package name.
> In most cases both package name and class name will be unknown to me. The only
> thing I could prescribe would be the name of a jar-file, but I'd rather get along
> even without that.
OK, then it probably isn't possible to use SCA contributions to load
these classes.

> [Side note:
> I did try using the Java extension mechanism for bundling extensions (Class-Path
> entry for the jar in the manifest file of the SCA contribution), but that did not
> work either. If I understand you correctly, this is not even supposed to be supported
> by Tuscany, because it would through the context class loader as well.]
That should work.  Because the contribution classloaders delegate to the
application classloader, any classes loaded by the application classloaders
using the Java extension mechanism should be visible to the contribution
classloaders.  This doesn't break the "golden rule" because the code in
the extension JARs isn't SCA contribution code (even though it's accessible
by SCA contribution code).


> -- Sebastian
> IDS Scheer Consulting GmbH
> Geschäftsführer/Managing Directors: Kamyar Niroumand, Ivo Totev
> Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, Germany - Registergericht/Commercial
register: Saarbrücken HRB 19681
> http://www.softwareag.com

View raw message