tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Millies, Sebastian" <Sebastian.Mill...@softwareag.com>
Subject Re: Contributions and Runtime Classpath
Date Thu, 08 Dec 2011 09:56:18 GMT
> -----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).


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

Isn't there some way for a service implementation to gain access to its
contribution class loader at run time?

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

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

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

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

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

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

View raw message