Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

[Raymond Feng]

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" <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> 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