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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > Sent: Tuesday, July 01, 2008 3:59 AM > To: <[email protected]> > 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 >> > >
