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 Wed, 21 Dec 2011 14:25:47 GMT
Millies, Sebastian wrote:
> 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
> 
> 
Here's a suggestion:

1. Define an SPI which contains the interface that the customer class will
    implement, and also contains one or more interfaces that will be
    implemented by your main contribution code and used by the customer code
    to access the implementation logic in your main contribution.

2. Put the above interfaces in their own jar file and in a Java package
    that is different from all the Java packages used by your SCA
    contribution code.

3. Put this jar file on the application classpath so that it's loaded
    by the application classloader and visible to all the SCA contributions.

4. Put the customer implementation code in another jar file that
    depends on the SPI jar.  This implementation jar would also be on
    the application classpath.

5. When your main contribution instantiates the customer implementation code,
    pass to the customer object's constructor a reference to an object of
    yours that implements one of the SPI interfaces described in step 1.
    This object provides the necessary bootstrap link from the customer code
    to your code.

Would this approach be suitable?

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