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:[email protected]] > > Sent: Thursday, December 08, 2011 3:46 PM > > To: [email protected] > > Subject: Re: Contributions and Runtime Classpath > > > > Millies, Sebastian wrote: > > >> -----Original Message----- > > >> From: Simon Nash [mailto:[email protected]] > > >> Sent: Thursday, December 08, 2011 11:32 AM > > >> To: [email protected] > > >> 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/[email protected]/msg02597.html > > [2] http://www.mail-archive.com/[email protected]/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
