tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Nash <n...@apache.org>
Subject Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Date Tue, 01 Jul 2008 10:59:50 GMT
ant elder wrote:
> 
> 
> On Tue, Jul 1, 2008 at 12:26 AM, Raymond Feng <enjoyjava@gmail.com 
> <mailto:enjoyjava@gmail.com>> wrote:
> 
>     Hi,
> 
>     I would like to reactivate the discussion on how we can improve the
>     extensibility story based on the following use cases.
> 
>     1) Be able to discover extensions declared using the
>     META-INF/services pattern in a non-OSGi environment
>     2) Be able to discover extensions declared using the
>     META-INF/services pattern in an OSGi environment
>     3) Be able to discover extensions declared using the
>     META-INF/plugin.xml with the Eclipse Equinox Extension Registry
>     4) Be able to discover extensions declared using the
>     META-INF/plugin.xml with other OSGi implementation such as Apache Felix
> 
>     1 & 2 is the poor-man's ExtensionRegistry and 3 & 4 is based on the
>     Eclipse extension registry syntax with nice tooling support.
> 
>     At this moment, the ServiceDiscovery SPI is a class which depends on
>     the registered classloaders. To support the different extension
>     mechanisms, the ServiceDiscovery.getInstance() should be able to
>     return an instance of the ServiceDiscovery which fits the hosting
>     environment.
> 
>     For 1), we can use ClassLoader.getResources() to find the service
>     provider files
>     For 2), we can use the BundleContext.getBundles() from the OSGi
>     runtime and Bundle.findEntries() to find the service provider entries
>     For 3), we can use the Eclipse Equinox IExtensionRegistry API
>     For 4), we can simulates 3) as the ExtensionRegistry is implemented
>     using standard OSGi APIs without Equinox backdoors.
> 
>     If we agree on the objectives, I can start to prototype some of the
>     approaches and share with you over time.
> 
>     Thanks,
>     Raymond
> 
> 
> If we're going to start redoing the extensibility story I think we 
> should be using the definitions.xml file for defining the SCA extensions 
> as discussed in http://apache.markmail.org/message/unubgkqdcwwch66m
> 
> It sounds like we've two different types of extensions:
> 
> (1) SCA extensions for binding, implantation and interface types
> (2) Tuscany runtime extensions for creating the actual runtime code, 
> things like our host-http-jetty etc
> 
> These have different characteristics and requirements so don't need to 
> use the same extension mechanism.
> 
>    ...ant
> 
>   
I agree.  I think there are two levels of this:
  1. A Tuscany extension model that is used for all Tuscany extensions.
     This includes mechanisms for packaging, installing, loading and
     configuring Tuscany extensions.
  2. An SCA extension mechanism based on the definitions.xml file.  This
     includes mechanisms for specifying and configuring SCA extensions.
     These would sit on top of the underlying Tuscany mechanisms as
     described in point 1.

   Simon

Mime
View raw message