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 Wed, 21 Dec 2011 11:06:42 GMT
I've thought about this some more. It appears that what I had in mind
is not possible. See below (the exposition is rather long, but I hope
that it is clear and simple).

> > -----Original Message-----
> > From: Simon Nash [mailto:nash@apache.org]
> > Sent: Thursday, December 08, 2011 3:46 PM
> > To: user@tuscany.apache.org
> > Subject: Re: Contributions and Runtime Classpath
> >
> > Millies, Sebastian wrote:
> > >> -----Original Message-----
> > >> From: Simon Nash [mailto:nash@apache.org]
> > >> Sent: Thursday, December 08, 2011 11:32 AM
> > >> To: user@tuscany.apache.org
> > >> Subject: Re: Contributions and Runtime Classpath
> > >>
> > >> [snip]
> > >> My guess is that you have broken the "golden rule" to keep all
> your
> > >> contribution classes off the Java classpath.
> > >>
> > [snip]
> > This has been discussed on the Tuscany user list (see [1] and [2]).
> > [snip]
> >
> > [1] http://www.mail-archive.com/user@tuscany.apache.org/msg02597.html
> > [2] http://www.mail-archive.com/user@tuscany.apache.org/msg02897.html
> > [snip]

To recapitulate:

I have a contribution that basically consists of a single composite and
several implementation classes contained in a jar-file. The service implementations
have references to services that sit in other composites on remote nodes. The
Java interfaces to the remote services are available in jar-files which are also
contributed (along with the main contribution) to my local node. All contributions
are loaded by the contribution class loader, imports and exports work through
sca-contribution.xml declarations. Common libraries are loaded from the Java classpath
by the Java application classloader, which otherwise loads only a dedicated launcher
for the node.

So far, so good, and all according to the best-practice you have described.

Now, I had in mind a particular mechanism for customer extensions to hook into my
application. This idea went like this:

a) provide an interface that the customer may implement.
b) provide a customizing opportunity (e. g. property file) in which the customer can
specify an implementation class for that interface.
c) have some service implementation in the main contribution dynamically load and
instantiate that implementation at runtime.
d) Let the implementation class access all the code in my main contribution, because
the customer code is part of the business logic to be implemented. (In particular, the
interface that the extension must implement must at least be accessible.)
e) Have the customer provide the implementation class at run-time (i. e. when the
node is started) and have the launcher do the assembly of the contributions. In particular,
I absolutely require that no modification of my sca-contribution.xml take place when the
customer substitutes a new implementation class (in a different package) and restarts the
node.
I cannot know the package names of the extension implementation classes in advance.

c) and d) require the customer class to be on inside some contribution to the local node.
e) is the problem: Since I cannot know the package of the customer extension, I cannot
import it into my main contribution. So the customer code must be part of the SAME
contribution.

However, the code sits in different jar-files provided at different times by different people,
not being part of the same build process.

What I guess I need is a node/contribution api that lets me load code from multiple locations
(jars) into a single contribution. The SCAContribution class will not do, because it accepts
exactly one location.

I have not been able to make this work. Any ideas? Or different approaches?

Must I require the implementation to sit in a particular package and require a customer to
provide an sca-contribution.xml that exports that package? I'd really hate that.

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

Mime
View raw message