Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates
 209.85.220.209 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=FMOn+PJbGBorjuQYftKXvaIjnek9bKWNZ1JwPCUm+aCgJBDJhdMNUVT+/VwRtynYAc
         /H45Hyd1b24VkAR9/TZ9/BAsDZAhwn5Jqi3gOKIddz7GQV0uh1XEMtuAGecK3Cq8a95n
         Pg331w581N5I3oibcLPdYqWWKcNoW8lDYzuZc=
MIME-Version: 1.0
In-Reply-To: <4B87CE2A.9060008@gmail.com>
References: <4B87CE2A.9060008@gmail.com>
Date: Fri, 26 Feb 2010 15:22:48 +0100
Message-ID: <b23ecedc1002260622g5e6cd64ei867a5919b7038f68@mail.gmail.com>
Subject: Re: Adding OSGi support to Geronimo spec jars.
From: Guillaume Nodet <gnodet@gmail.com>
To: dev@geronimo.apache.org, rickmcg@gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If you're working on a fresh implementation, I have some thoughts I
gathered in the past months when writing / using the ServiceMix Specs.
A few shortcomings of the current implementation are:
  * a given bundle does not have a way to select a particular
implementation, i think we should define a header that may allow
customizing the provider used for this very bundle
  * there is currently no isolation between the client and the
provider.  I think we should proxy the provider so that if it the
bundle goes away, the implementation could be replaced underneath
  * specify in which order the provider is selected.  One possible
solution would be to default to the provider with the lowest bundle id
(which is something used in several places in OSGi).  This must be
specified and easy to deal with (i.e. the user must be able to easily
control which one will be used).

Just my 2 cents.


On Fri, Feb 26, 2010 at 14:35, Rick McGuire <rickmcg@gmail.com> wrote:
> I've been taking a hard look at what Servicemix had done to the various s=
pec
> jars to make them better behaved in an OSGi environment. =A0This is being=
 done
> with the intent of adding similar support to the base Geronimo spec jars.
> =A0I'm taking a fresh approach to this rather than necessarily just copyi=
ng
> what Servicemix is doing. =A0I've found a number of interesting things du=
ring
> this process, so I thought it would be good to do a brain dump of what I'=
ve
> found and how I'm planning on implementing this.
>
> The basics of the Servicemix approach is to add an Activator to each of t=
he
> spec bundle that maintains a registry of factory class information. =A0Ea=
ch
> spec bundle have a listener that tracks bundle activity and will check fo=
r
> factory information in the META-INF/services directory of each started
> bundle. =A0Each started bundle has its own listener and own copy of the
> factory information. =A0The registry information is used in the various p=
laces
> spec code needs to dynamically load provider classes for different
> subsystems. =A0For example, loading a persistence provider. =A0All classl=
oading
> is done lazily when a request is made for a matching class file. =A0The s=
pec
> code retrieves the loaded classes and handles all details of creating the
> instances using the retrieved classes.
>
> Jarek Gawor suggested I might want to take a look at what the Aries proje=
ct
> had for processing the META-INF/services information. =A0This test
> implementation, called "spifly", uses the OSGi extender pattern to inspec=
t
> the META-INF/services directories and uses that information to automatica=
lly
> register services in the OSGi services registry. =A0In this situation, th=
e
> classes are eagerly loaded, instances are created (which requires a
> no-argument constructor) and the services are registered in the OSGi
> registry.
>
> So, we have one set of information, but two different interpretations of =
how
> this information should be used. =A0The new implementation I was working =
on
> was using the extender pattern to maintain a single registry of this
> information that could be accessed using a provider registry service. =A0=
This
> would have a single listener, with a single version of the registry, and
> each bundle that required the service would just have a thin accessor lay=
er
> to call the registry service if it was available. =A0This is essentially
> combining the approaches used by Servicemix and spifly.
>
> However, I was becoming increasingly concerned about this dual
> interpretation of the META-INF/services information, and started research=
ing
> what conventions were in play with this. =A0What I found was there is a n=
ew
> feature in Java SE 6 called the ServiceLoader:
>
> http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html
>
> The service loader uses the META-INF/services information to create mappi=
ngs
> between interface classes and concrete implementations of these interface=
s.
> =A0This is similar to the spifly approach, but there are a few fundamenta=
l
> differences. =A0The biggest difference is that each instance of the
> ServiceLoader class will instantiate a new instance of the implementation
> class when needed. =A0For spifly, there is only ever a single instance of=
 the
> service created. =A0Both spifly and Servicemix are only processing the fi=
rst
> line of the services files, while the ServiceLoader defines that an
> individual definition file can define a one-to-many interface/implementat=
ion
> mapping. =A0So, now we're up to 3 different interpretations of the
> META-INF/services information.
>
> Looking a little deeper into how Servicemix was using this information, I
> found that it was bending the intent of the META-INF/services information=
 a
> bit. =A0The ServiceLoader definitions are intended to create mappings bet=
ween
> interface classes and implementers of a given interface. =A0The service m=
ix
> lookups were being used to directly resolve implementation classes. =A0To=
 do
> this, the service definition file would need to use the same class as bot=
h
> interface name and implementer class. =A0This has a nice side effect of
> allowing particular implementations to be selectively replaced, but this =
is
> a usage that could cause problems if the information was picked up by eit=
her
> spifly or ServiceLoader. =A0This violated the fundamental assumption that=
 this
> information defined interface-to-implementation mappings.
>
> In addition, the javamail changes were using this information to define
> protocol-to-provider mappings. =A0For example, an "smtp" javamail provide=
r
> implementation class. =A0In this case, the mapping did not even start wit=
h the
> name of a Java class. =A0This definitely conflicted with both spifly and
> ServiceLoader.
>
> A lot of these difficulties go away if I decouple the Servicemix semantic=
s
> by moving the information to a different location so that we're not seein=
g
> multiple interpretations of what the data in META-INF/services means. =A0=
The
> code I'm working on will be looking in OSGI-INF/providers, and the mappin=
g
> information is defined in terms of a provider identifier-to-provider clas=
s
> mapping. =A0This is really is the interpretation used by the Servicemix c=
ode,
> but removes the conflicting usage.
>
> Rick
>


--=20
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com