Return-Path: Delivered-To: apmail-tuscany-dev-archive@www.apache.org Received: (qmail 52954 invoked from network); 2 Jul 2008 07:44:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Jul 2008 07:44:54 -0000 Received: (qmail 88837 invoked by uid 500); 2 Jul 2008 07:44:55 -0000 Delivered-To: apmail-tuscany-dev-archive@tuscany.apache.org Received: (qmail 88798 invoked by uid 500); 2 Jul 2008 07:44:55 -0000 Mailing-List: contact dev-help@tuscany.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@tuscany.apache.org Delivered-To: mailing list dev@tuscany.apache.org Received: (qmail 88789 invoked by uid 99); 2 Jul 2008 07:44:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jul 2008 00:44:55 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ant.elder@gmail.com designates 64.233.182.186 as permitted sender) Received: from [64.233.182.186] (HELO nf-out-0910.google.com) (64.233.182.186) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jul 2008 07:44:02 +0000 Received: by nf-out-0910.google.com with SMTP id g16so63477nfd.38 for ; Wed, 02 Jul 2008 00:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:in-reply-to:mime-version:content-type:references; bh=PRnsvdxfCes2U4HW6FXmB+Ukk3jdZE5e0jg9bWEEjxs=; b=h2dZugOC+GvTKPP5Eso1vyv55uZjYmwCrsaRg8tAgk4Gr2HuH5v4Kt73mRQYedW6IF JQWACOlBH3YietHsnrAKzPRr/BTNCGdmvR1q0PFTy4gshX/TkureDcoHbT+USa85rpWk QPhMGqVRNoiBHs51ICJiFkWd97FvgFampOvrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:in-reply-to:mime-version :content-type:references; b=qmXabhnwHvgPHiZiqniRYKXOKisb6w7U8Klhy5FNscAfWJvQ8fUSdCSCVQhZH0uNMu l4z1nxYJoRdKGHHQ9/6sCCmwN/NvsgKHDXfuHOoVkNMeJOE/OcSZrH7u/3NTRE3shhGn wBwjVshuUNYYWxHw6d0nqyMu4LXB+pcVxwK9Q= Received: by 10.210.35.5 with SMTP id i5mr6277916ebi.5.1214984661526; Wed, 02 Jul 2008 00:44:21 -0700 (PDT) Received: by 10.210.52.3 with HTTP; Wed, 2 Jul 2008 00:44:21 -0700 (PDT) Message-ID: <71e1b5740807020044w5a5ff83ao3ed629010c2a4b2c@mail.gmail.com> Date: Wed, 2 Jul 2008 08:44:21 +0100 From: "ant elder" Reply-To: antelder@apache.org To: dev@tuscany.apache.org Subject: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3880_3537377.1214984661516" References: <71e1b5740801071003maa5b07cnff914f38d3fc4280@mail.gmail.com> <47962990.2080807@apache.org> <484DE0A0.6060504@apache.org> <71e1b5740806100045g686a54fdq7331b43fd9a514e1@mail.gmail.com> <484E7957.9020000@apache.org> <484EADC1.4060405@apache.org> <101536303D30446882D5CB4184F6FF22@rfengt60p> <71e1b5740807010026x1a97ff29r681bcc2727ecd0e0@mail.gmail.com> <486A0E26.4040904@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_3880_3537377.1214984661516 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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" > Sent: Tuesday, July 01, 2008 3:59 AM > To: > 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>> 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 >> > > ------=_Part_3880_3537377.1214984661516 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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


------=_Part_3880_3537377.1214984661516--