tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ant elder" <ant.el...@gmail.com>
Subject Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Date Wed, 02 Jul 2008 07:44:21 GMT
There was a strawman type example in
http://apache.markmail.org/message/te5ork3yppzf3a6i

   ...ant

On Tue, Jul 1, 2008 at 5:53 PM, Raymond Feng <enjoyjava@gmail.com> wrote:

> 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