You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2008/07/01 01:26:59 UTC
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
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
--------------------------------------------------
From: "Jean-Sebastien Delfino" <js...@apache.org>
Sent: Tuesday, June 10, 2008 9:37 AM
To: <tu...@ws.apache.org>
Subject: Tracking Tuscany extensions, was: Distribution zips and what they
contain, was: SCA runtimes
> Simon Nash wrote:
>> ant elder wrote:
>>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>> jsdelfino@apache.org> wrote:
>>>> Jean-Sebastien Delfino wrote:
>>>>> I'd like to discuss the following: "What distro Zips are we building
>>>>> and
>>>>> what do they contain?"
>>>>>
>>>>> I think we could improve our distro scheme to provide:
>>>>> - smaller packages
>>>>> - easier for people to find what they need
>>>>>
>>>>> I was thinking about the following binary distro zips:
>>>>>
>>>>> - tuscany-core.zip - The base that everybody needs.
>>>>> core assembly model and runtime
>>>>> Java APIs, Java components
>>>>>
>>>>> - tuscany-web.zip - For WS and Web developers
>>>>> WS binding, Web 2.0 bindings, Scripting components, Widget components
>>>>>
>>>>> - tuscany-jee.zip - For JEE app integration
>>>>> EJB, RMI and JMS bindings, Spring components
>>>>>
>>>>> - tuscany-process.zip - For process development
>>>>> BPEL and XQuery components
>>>>>
>>>>> - tuscany-all.zip - all of the above
>>>>>
>>>>> Note that I'm not trying to tackle release cycles and the potential
>>>>> for
>>>>> releasing the above zips independently in this discussion and I'm
>>> assuming
>>>>> that we release all of the above together.
>>>>>
>>>>> I'm also assuming that the relevant samples are included in each zip.
>>>>>
>>>> This email was from 1/22/08, generated a lot of discussion for about 3
>>>> weeks, lots of opinions, no conclusion, no commits :)
>>>>
>>>
>>> No commits as we haven't found much consensus yet.
>>>
>>>> I still think the same as what I had posted then, plus additional
>>>> ideas:
>>>>
>>>> - Use OSGi exports/imports to export clean SPIs, hide internals, and
>>> refine
>>>> the contents of the distros and their dependencies.
>>>>
>>>> Disclaimer - Please don't get me wrong I'm not saying that one distro
>>>> ==
>>> one
>>>> OSGi bundle, as I've already said several times on the list that the
>>>> big-OSGi-bundle approach didn't make sense to me :) I just think that
>>>> declaring and enforcing clean dependencies using OSGi will help us
>>>> refine
>>>> the contents of each distro.
>>>>
>> The term "enforcing" seems to suggest that there might be an OSGi
>> dependency for the Tuscany runtime. I don't know if this was
>> intended. I think the right approach is to have a Tuscany+OSGi
>> runtime (as we are building in itest\osgi-tuscany) which would
>> actually do enforcement, and a non-OSGi Tuscany runtime in which
>> the exports/imports are present in the jars but not enforced.
>
> Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi
> environment...
>
>>
>> What would be the granularity of these OSGi bundles? If the bundles
>> are the current maven modules, I think we will find a number of
>> classes that need to be exported even though these classes are not
>> considered part of the SPI or API that the module provides.
>> To resolve this I see the following options:
>> a) Export more than we really believe is correct. This
>> leaves us in the current unsatisfactory position of exposing
>> unwanted implementation internals.
>> b) Combine multiple maven modules with a close implementation
>> affinity into a single OSGi bundle, and only expose true
>> APIs or SPIs from these bundles.
>> c) Refactor the code to remove dependencies on internals of other
>> modules, and create new SPIs or APIs when this isn't possible.
>>
>> I believe a combination of b) and c) is the best approach.
>
> We've already rehashed this (and disagreed on this) in several other
> threads, where I've already given my opinion:
> - 1 bundle per module
> - clean API/SPI imports/exports
>
>>
>>>> - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an
>>>> extension
>>>> registry mechanism (what we have now in Tuscany or better a combination
>>>> of
>>>> what we have now and the Eclipse Equinox registry for example) to
>>>> detect
>>>> which pieces are installed and activate their capabilities.
>>>>
>>>
>>> Can you say a bit more about what an "extension registry mechanism"
>>> would
>>> look like?
>>>
>>> What the tuscany-all/manifest jar are trying to do is to have users not
>>> need
>>> to know about the internal makeup of Tuscany. So they can simply use
>>> tuscany-all and avoid needing to know about all the dozens of different
>>> Tuscany modules and their dependencies, and that should keep working
>>> over
>>> many Tuscany releases whereas as we keep adding/deleting/changing the
>>> modules we keep breaking user builds for each Tuscany release if they
>>> refer
>>> to the individual modules. Maybe the granularity isn't quite right yet
>>> and
>>> we need something in between the all jar and all the individual modules.
>>>
>>> Is there much agreement that avoiding users needing to know about the
>>> internal Tuscany modules is a Good Thing?
>>>
>> Yes, I think this is important. Ideally the Tuscany core runtime
>> would figure out which pieces are needed for the domain configuration
>> and load these pieces automatically.
>>
>
> Good requirement, but I don't think that the current manifest +
> tuscany-all JAR solution is a good one (for example it mixes APIs and
> internals in the same JAR, doesn't work well with IDEs, works only for one
> big distro, requires different settings in J2SE and webapps)
>
> Here's what I'd like to see as a user:
>
> - a short list of API JARs that I can add to my dev compile/build path
>
> - a single small launcher or bootstrap JAR that takes care of
> bootstrapping the Tuscany runtime
>
> - the launcher should detect the presence of installed extensions in a
> particular Tuscany installation
>
> - as a user / app developer I should not have to know the list of JARs
> from all these extensions.
>
> That's what I've been trying to do with the Node launcher and the library
> provided by the Tuscany Eclipse plugin. More work is required to get that
> vision in place (as the current launcher is still pretty rudimentary and
> only scans an installation directory for JARs).
>
> There's a good extension registry mechanism in Eclipse Equinox [1]. It
> would allow us to rely on a robust mechanism for detecting installed
> extensions, tracking what they provide in an extension registry [2], and
> use a more user friendly syntax for registering extensions using
> plugin.xml files. If we start to integrate more with OSGi I think we
> should just use it (maybe in combination with what we currently have with
> META-INF/services for the cases where we don't use OSGi).
>
> [1] http://www.eclipse.org/equinox/
> [2] http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox.registry/
>
> -- Sebastien
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
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 <en...@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" <na...@apache.org>
> Sent: Tuesday, July 01, 2008 3:59 AM
> To: <de...@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
>>
>
>
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
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" <na...@apache.org>
Sent: Tuesday, July 01, 2008 3:59 AM
To: <de...@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
>> <ma...@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
Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
>
>
> On Tue, Jul 1, 2008 at 12:26 AM, Raymond Feng <enjoyjava@gmail.com
> <ma...@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
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Tue, Jul 1, 2008 at 12:26 AM, Raymond Feng <en...@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