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 15:06:21 GMT
> -----Original Message-----
> From: Simon Nash [mailto:nash@apache.org]
> Sent: Wednesday, December 21, 2011 3:26 PM
> To: user@tuscany.apache.org
> Subject: Re: Contributions and Runtime Classpath
>
> Millies, Sebastian wrote:
> >
> > [snip]
> >
> > 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
>

Thanks for the suggestion. In principle, that would work for me, except for one
complication: In my application, I pass around data objects (defined by xsd). The
backing xsd's are resource imports/exports, and I have my own helper classes for
SDO manipulation. These helpers load the xsd's as resources, i. e. they must be
accessible to contribution code, the helper classes and the customer code.
Which means the xsd's and helper classes would also have to go on the application
classpath.

However, I think that's not going to be possible, because the SDOs of course also
occur in service calls as parameters and return values, and the serialization via
the SDO databinding will only work correctly when the defining types are declared
with <dbsdo:import.sdo> elements in the composite files (where
xmlns:dbsdo="http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0"  ).
This, I think only works when they are exported/imported as resources of the
contribution, and does not work when they just sit on the application classpath.

In any case I'd have some refactoring on my hands. So for the near future I'll probably
prescribe an implementation package for the customer code, and revisit the situation
later. If our project really abandons SDO (a possibility I mentioned in another
thread), then this particular problem will vanish and your suggestion become
immediately feasible.

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