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
 74.125.46.31 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type;
        b=KR8jUX3wFPXlTAPK90B0MNJyBGGIhb7OSuCLapyCP+i8Uuj3/pkL1AOuza3IILuK0x8yH5FwKJLkoeVqynKnk0djVdoRFqqbxXW7IM6JvPGfo9QeJfhXahf/lJdLiMe1uZMSi0KrDpHmvS8cR6ujdqL7WC4n+qeT76Agc3TS+Oo=
Message-ID: <b23ecedc0804160820n1e13d678gb0d52f3ace08efa3@mail.gmail.com>
Date: Wed, 16 Apr 2008 17:20:13 +0200
From: "Guillaume Nodet" <gnodet@gmail.com>
To: dev@geronimo.apache.org
Subject: Geronimo specs jars in OSGi
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_8335_338.1208359213354"

------=_Part_8335_338.1208359213354
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

In the past months, I've been working on making the specs jars from Geronimo
working in an OSGi environment.
All these jars have been published and work great :-)
However, lots of these spec jars define factories (stax, saaj for example)
that use the META-INF/services/ discovery mechanism to find an
implementation of the spec and load it.  This mechanism does not fit well in
OSGi (really, it does not), mainly because usually, the classloader
containing the spec jar will not contain the implementation.
I'd like to work on these spec jars so that they will contain an OSGi
BundleActivator that would change the behavior of these factories when
deployed in an OSGi environment (without changing the behavior in other
case).  The idea is that the activator would scan OSGi bundles when they are
started to find META-INF/services and populate a map that would be used by
the factory when creating an object before using the standard mechanism.

The only real difference compared to what we currently have would be the
addition of a package named org.apache.geronimo.specs.stax (for example)
that would contain the needed classes (i suppose two classes), and the
modification of the factories to delegate to one of these class before using
the standard behavior (the class would do nothing if not deployed in an OSGi
environment).
Has anyone any objection with such an enhancement in the specs jar ?

-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

------=_Part_8335_338.1208359213354
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

In the past months, I&#39;ve been working on making the specs jars from Geronimo working in an OSGi environment.<br>All these jars have been published and work great :-)<br>However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it.&nbsp; This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation.<br>
I&#39;d like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case).&nbsp; The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism.<br>
<br>The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment).<br>
Has anyone any objection with such an enhancement in the specs jar ?<br clear="all"><br>-- <br>Cheers,<br>Guillaume Nodet<br>------------------------<br>Blog: <a href="http://gnodet.blogspot.com/">http://gnodet.blogspot.com/</a>

------=_Part_8335_338.1208359213354--