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
