tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <enjoyj...@gmail.com>
Subject Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Date Tue, 01 Jul 2008 16:53:03 GMT
Hi,

Can one of you show me a sample of the definitions.xml to configure the SCA 
extensions? I would like to better understand how Tuscany would works with 
it to provide the extensibility.

Thanks,
Raymond

--------------------------------------------------
From: "Simon Nash" <nash@apache.org>
Sent: Tuesday, July 01, 2008 3:59 AM
To: <dev@tuscany.apache.org>
Subject: Re: Tracking Tuscany extensions, was: Distribution zips and what 
they contain, was: SCA runtimes

> 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