You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Guillaume Nodet <gn...@gmail.com> on 2008/04/16 17:20:13 UTC
Geronimo specs jars in OSGi
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/
Re: Geronimo specs jars in OSGi
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 17 April 2008, Alan D. Cabrera wrote:
> On Apr 17, 2008, at 7:19 AM, Guillaume Nodet wrote:
> > I've thought about this. The main problem is that you end up having
> > two different
> > jars for the spec, one being a plain jar and another one being an
> > OSGi bundle.
> > Both would not be compatible if the bundle embeds the spec jar,
> > because non osgi
> > environment would not be able to load the jar inside the bundle.
> > Imho, creating two different jars would confuse the users and be
> > more error prone.
>
> Non OSGi environments use the vanilla jar as they currently do. OSGi
> environments load the spec bundle. Doesn't seem confusing to me.
Well, it IS confusing when you have projects that are required to work in
both OSGi and non-OSGi environments. Suddenly, they have to ship two
versions of the same jar so downloads are bigger. They have to
document when they can use one versus the other. You have to deal with
users that don't read the docs and try to do something with the wrong
one, etc... Not fun.
There are also issues with maven and dependencies (must depend on the
non-osgi for compiling, but the non-osgi for testing/shipping?), but
that's a completely different issue.
Dan
>
> > On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera
> >
> > <li...@toolazydogs.com> wrote:
> >> On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
> >>> 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
> >>> ?
> >>
> >> I would prefer to have a virgin spec jar wrapped inside an OSGi
> >> bundle.
> >> Here the virgin factories would be overshadowed by the OSGi
> >> specific factories.
> >>
> >> I feel strongly about this but am willing to discuss it.
> >>
> >>
> >> Regards,
> >> Alan
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: Geronimo specs jars in OSGi
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Apr 17, 2008, at 7:19 AM, Guillaume Nodet wrote:
> I've thought about this. The main problem is that you end up having
> two different
> jars for the spec, one being a plain jar and another one being an
> OSGi bundle.
> Both would not be compatible if the bundle embeds the spec jar,
> because non osgi
> environment would not be able to load the jar inside the bundle.
> Imho, creating two different jars would confuse the users and be more
> error prone.
Non OSGi environments use the vanilla jar as they currently do. OSGi
environments load the spec bundle. Doesn't seem confusing to me.
>
>
> On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera
> <li...@toolazydogs.com> wrote:
>>
>> On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
>>
>>
>>
>>> 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 ?
>>>
>>
>> I would prefer to have a virgin spec jar wrapped inside an OSGi
>> bundle.
>> Here the virgin factories would be overshadowed by the OSGi specific
>> factories.
>>
>> I feel strongly about this but am willing to discuss it.
>>
>>
>> Regards,
>> Alan
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
Re: Geronimo specs jars in OSGi
Posted by Guillaume Nodet <gn...@gmail.com>.
I've thought about this. The main problem is that you end up having
two different
jars for the spec, one being a plain jar and another one being an OSGi bundle.
Both would not be compatible if the bundle embeds the spec jar, because non osgi
environment would not be able to load the jar inside the bundle.
Imho, creating two different jars would confuse the users and be more
error prone.
On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
>
>
>
> > 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 ?
> >
>
> I would prefer to have a virgin spec jar wrapped inside an OSGi bundle.
> Here the virgin factories would be overshadowed by the OSGi specific
> factories.
>
> I feel strongly about this but am willing to discuss it.
>
>
> Regards,
> Alan
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
> 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 ?
I would prefer to have a virgin spec jar wrapped inside an OSGi
bundle. Here the virgin factories would be overshadowed by the OSGi
specific factories.
I feel strongly about this but am willing to discuss it.
Regards,
Alan
Re: Geronimo specs jars in OSGi
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Sorry. This is for David's idea:
"I also wonder if there is a way to generalize the osgi method so it
might work in some non-osgi environments."
Another reason to wrap the spec jar in a bundle is that we won't be
seen as extending the spec, something that is explicitly prohibited in
the licensing of the JSRs.
Regards,
Alan
On Apr 17, 2008, at 7:17 AM, Guillaume Nodet wrote:
> Do you mean your -1 only apply to extending the behavior of the spec
> in the J2EE environment,
> and does not apply to extending the behavior in an OSGi environment ?
> I'm not sure to completely understand your reasoning.
>
> On Thu, Apr 17, 2008 at 4:15 PM, Alan D. Cabrera
> <li...@toolazydogs.com> wrote:
>> Sorry, I meant to say:
>>
>>
>> On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote:
>>
>>
>>>
>>> On Apr 16, 2008, at 8:49 AM, David Jencks wrote:
>>>
>>>
>>>> I'd like to see an example in action before I commit myself but
>>>> so far I
>> don't see any problems with this. I assume you have already or
>> will soon
>> verify this doesn't cause problems with the tck :-)
>>>>
>>>> I wonder if a package name with "osgi" in it somewhere would be
>>>> more
>> appropriate?
>>>>
>>>> There are some specs (jacc for instance) that use a system
>>>> property to
>> figure out what to create. I've always thought this was a less than
>> brilliant idea and wonder if we can do something similar for
>> those. I also
>> wonder if there is a way to generalize the osgi method so it might
>> work in
>> some non-osgi environments.
>>>>
>>>
>>
>>
>>
>>> -1 technical veto
>>>
>>> These are spec jars and extending the behavior of these jars on an
>>> ad hoc
>> basis is bad and possibly violates the licenses of the JSRs they
>> implement.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
Re: Geronimo specs jars in OSGi
Posted by Guillaume Nodet <gn...@gmail.com>.
Do you mean your -1 only apply to extending the behavior of the spec
in the J2EE environment,
and does not apply to extending the behavior in an OSGi environment ?
I'm not sure to completely understand your reasoning.
On Thu, Apr 17, 2008 at 4:15 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Sorry, I meant to say:
>
>
> On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote:
>
>
> >
> > On Apr 16, 2008, at 8:49 AM, David Jencks wrote:
> >
> >
> > > I'd like to see an example in action before I commit myself but so far I
> don't see any problems with this. I assume you have already or will soon
> verify this doesn't cause problems with the tck :-)
> > >
> > > I wonder if a package name with "osgi" in it somewhere would be more
> appropriate?
> > >
> > > There are some specs (jacc for instance) that use a system property to
> figure out what to create. I've always thought this was a less than
> brilliant idea and wonder if we can do something similar for those. I also
> wonder if there is a way to generalize the osgi method so it might work in
> some non-osgi environments.
> > >
> >
>
>
>
> > -1 technical veto
> >
> > These are spec jars and extending the behavior of these jars on an ad hoc
> basis is bad and possibly violates the licenses of the JSRs they implement.
> >
> >
> > Regards,
> > Alan
> >
> >
> >
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Sorry, I meant to say:
On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote:
>
> On Apr 16, 2008, at 8:49 AM, David Jencks wrote:
>
>> I'd like to see an example in action before I commit myself but so
>> far I don't see any problems with this. I assume you have already
>> or will soon verify this doesn't cause problems with the tck :-)
>>
>> I wonder if a package name with "osgi" in it somewhere would be
>> more appropriate?
>>
>> There are some specs (jacc for instance) that use a system property
>> to figure out what to create. I've always thought this was a less
>> than brilliant idea and wonder if we can do something similar for
>> those. I also wonder if there is a way to generalize the osgi
>> method so it might work in some non-osgi environments.
> -1 technical veto
>
> These are spec jars and extending the behavior of these jars on an
> ad hoc basis is bad and possibly violates the licenses of the JSRs
> they implement.
>
>
> Regards,
> Alan
>
>
Re: Geronimo specs jars in OSGi
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Apr 16, 2008, at 8:49 AM, David Jencks wrote:
> I'd like to see an example in action before I commit myself but so
> far I don't see any problems with this. I assume you have already
> or will soon verify this doesn't cause problems with the tck :-)
>
> I wonder if a package name with "osgi" in it somewhere would be more
> appropriate?
>
> There are some specs (jacc for instance) that use a system property
> to figure out what to create. I've always thought this was a less
> than brilliant idea and wonder if we can do something similar for
> those. I also wonder if there is a way to generalize the osgi
> method so it might work in some non-osgi environments. I'm looking
> forward to seeing what you have in mind.
>
> thanks
> david jencks
>
> On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
>> 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 ?
-1 technical veto
These are spec jars and extending the behavior of these jars on an ad
hoc basis is bad and possibly violates the licenses of the JSRs they
implement.
Regards,
Alan
Re: Geronimo specs jars in OSGi
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Apr 16, 2008 at 5:49 PM, David Jencks <da...@yahoo.com> wrote:
> I'd like to see an example in action before I commit myself but so far I
> don't see any problems with this. I assume you have already or will soon
> verify this doesn't cause problems with the tck :-)
Fair enough ;-) I may ping someone, as I've never worked on the TCK so far.
>
> I wonder if a package name with "osgi" in it somewhere would be more
> appropriate?
Agreed.
>
> There are some specs (jacc for instance) that use a system property to
> figure out what to create. I've always thought this was a less than
> brilliant idea and wonder if we can do something similar for those. I also
> wonder if there is a way to generalize the osgi method so it might work in
> some non-osgi environments. I'm looking forward to seeing what you have in
> mind.
I guess you are talking about the PolicyConfigurationFactory in jacc.
I suppose we could extend the mechanism to include searching through
the META-INF/services/xxx stuff instead of simply relying on a system property.
However, the mechanism I'm thinking about is quite specific to OSGi (at least
in its implementation).
>
> thanks
> david jencks
>
>
> On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
> 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/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
Posted by David Jencks <da...@yahoo.com>.
I'd like to see an example in action before I commit myself but so
far I don't see any problems with this. I assume you have already or
will soon verify this doesn't cause problems with the tck :-)
I wonder if a package name with "osgi" in it somewhere would be more
appropriate?
There are some specs (jacc for instance) that use a system property
to figure out what to create. I've always thought this was a less
than brilliant idea and wonder if we can do something similar for
those. I also wonder if there is a way to generalize the osgi method
so it might work in some non-osgi environments. I'm looking forward
to seeing what you have in mind.
thanks
david jencks
On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
> 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/
Re: Geronimo specs jars in OSGi
Posted by Daniel Kulp <dk...@apache.org>.
IMO, if we can release a single jar that has the OSGi mechanism in it that
would also pass the TCK, then, to me, that is preferred. Thus, my
suggestion would be to take something that we DO have the tck for (jaxws 2.1
or saaj or something), add the OSGi stuff to it, and run the tck's to see what
happens.
Dan
On Tue June 16 2009 1:38:49 pm David Jencks wrote:
> It's been a year.... IIUC servicemix has done something so the specs
> that have this discovery pattern solve the problem somehow. Now we
> have a jaxws 2.2 spec with the same problem.
>
> I think its silly to have the osgi-usable version of the spec far away
> from the spec source code. Can we revisit this discussion?
>
> I'd need to review what the servicemix bundles actually do but I'm
> pretty much in favor of having the geronimo spec jars work in osgi
> unchanged. If that's really unacceptable I'd suggest releasing two
> artifacts, one a working osgi bundle the other a non-osgi plain jar.
>
> thanks
> david jencks
>
> On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
> > 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/
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Geronimo specs jars in OSGi
Posted by David Jencks <da...@yahoo.com>.
It's been a year.... IIUC servicemix has done something so the specs
that have this discovery pattern solve the problem somehow. Now we
have a jaxws 2.2 spec with the same problem.
I think its silly to have the osgi-usable version of the spec far away
from the spec source code. Can we revisit this discussion?
I'd need to review what the servicemix bundles actually do but I'm
pretty much in favor of having the geronimo spec jars work in osgi
unchanged. If that's really unacceptable I'd suggest releasing two
artifacts, one a working osgi bundle the other a non-osgi plain jar.
thanks
david jencks
On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
> 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/
Re: Geronimo specs jars in OSGi
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 17 April 2008, Jacek Laskowski wrote:
> On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <gn...@gmail.com>
wrote:
> > 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.
>
> Just to ensure I'm following, you are about to create a activator that
> would be a bundle listener (o.o.f.BundleListener) and whenever a
> bundle is registered the activator will scan it for provided services?
> Can you explain how osgi works now without these
> META-INF/services-based services? Doesn't it use them at all?
I'll provide an example that I'm running into.... In my OSGi app, if I
do something like MessageFactory.newInstance() to create a new SAAJ
MessageFactory, the current spec implementations check the
contextClassLoader for the
META-INF/services/javax.xml.soap.MessageFactory file. Outside of OSGi,
that would be properly picked up from the implementation jar. Inside
OSGi, the file isn't available, so it defaults to whatever version is
hardcoded into the saaj-api jar, which may not even be available.
Basically, in OSGi, you cannot have multiple jars/bundles export the
META-INF/services directory. That won't work. Thus, the whole
META-INF/services thing that all the specs rely on just doesn't work.
(IMO: this is a big deficiency in the OSGi spec, but that's my opinion)
The goal is to allow the "default" that is hard coded into the saaj-api
jar to be replaced/augmented at runtime based on information the bundle
listener finds in the other bundles that are available. Thus, when we
call MessageFactory.newInstance(), it would probably still check
META-INF/services/javax.xml.soap.MessageFactory (so someone COULD put
that in their application bundle and possibly get it), but if not found,
use a default value that can actually have a chance of succeeding.
Dan
>
> > 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
> > ?
>
> Unless I'm mistaken it shouldn't cause any troubles on non-osgi
> environments and big +1 for the upcoming changes.
>
> Jacek
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: Geronimo specs jars in OSGi
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Apr 17, 2008 at 5:05 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> I must be missing something. That legacy code would not need to change.
> The whiteboard pattern only obviates the need to scavenge every bundle the
> META-INF/services entries. The rest works as you say.
You mean, having each implementation jar register a service in the
osgi registry ?
Yeah, doable. Just requires more work.
>
> But, as I think about it some more, I'm thinking that this is over
> engineering it. Let's drop this aspect of the thread.
>
> I still feel strongly that the virgin spec jar should be wrapped in a
> bundle.
I can understand that there is legal problems changing the behavior
of the spec, but I'm not sure how repackaging it would lead to a different
conclusion: the behavior would still be changed.
If we do use a separate bundle, I would lean towards removing the existing
manifest headers so that there is no confusion, but I don't really see
the benefit
of doing this. The added code would not run in a non-osgi environment, so
there is not much risk there.
>
>
> Regards,
> Alan
>
>
> On Apr 17, 2008, at 7:54 AM, Guillaume Nodet wrote:
>
>
> > i don't mean legacy jars but legacy *code*.
> > If you have a jar which uses
> > javax.xml.stream.XMLInputFactory.newInstance()
> > somewhere deep in the code, I don't really understand how using a
> whiteboard
> > pattern will solve the problem. I'm not trying to make people rewrite
> > everything,
> > but rather make things easy for them to deploy their application and keep
> the
> > behavior they are used to see.
> > it could be you want to deploy the jaxws-ri, jersey or any other xml
> related
> > technology that could use SAAJ, Stax, Jaxb2 ...
> >
> >
> > On Thu, Apr 17, 2008 at 4:40 PM, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
> >
> > > IIUC, they're not entirely legacy, i.e. you at least put in the OSGi
> > > manifest entries. You do so using the maven/BND plugin I suspect.
> > >
> > > This strikes me as a common service discovery pattern. Off the top of
> my
> > > head I would think that a plugin that adds the necessary BundleActivator
> for
> > > legacy modules would be useful.
> > >
> > > Another thought that flashed in my head is that in a buttoned down
> > > environment getting service notifications might be easier than getting
> > > access to every Bundle's class loader.
> > >
> > >
> > > Regards,
> > > Alan
> > >
> > >
> > >
> > > On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote:
> > >
> > >
> > >
> > > > Cleaner, but the main problem is that it does not work with legacy
> code.
> > > > Will you rewrite the jaxb2 implementation to do that instead of using
> the
> > > >
> > > stax
> > >
> > > > factory ? ;-)
> > > > We've got tons of legacy stuff that use stax, or jaxb2 and i don't see
> > > >
> > > rewriting
> > >
> > > > the whole lot as realistic. it would also mean having an OSGi
> specific
> > > >
> > > thing
> > >
> > > > everywhere we use a factory from a j2ee spec :-(
> > > >
> > > > On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera
> <li...@toolazydogs.com>
> > > >
> > > wrote:
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski
> > > > > >
> > > > >
> > > >
> > > <ja...@laskowski.net.pl>
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > wrote:
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet
> <gn...@gmail.com>
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > wrote:
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > 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.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Just to ensure I'm following, you are about to create a
> activator
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > that
> > >
> > > >
> > > > >
> > > > > >
> > > > > > > would be a bundle listener (o.o.f.BundleListener) and whenever a
> > > > > > > bundle is registered the activator will scan it for provided
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > services?
> > >
> > > >
> > > > >
> > > > > >
> > > > > > > Can you explain how osgi works now without these
> > > > > > > META-INF/services-based services? Doesn't it use them at all?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > This is the tricky part. The work we've done on the specs so far
> > > > > > means that each spec
> > > > > > is an OSGi bundle. In OSGi, each bundle has each own classloader
> and
> > > > > > classloaders
> > > > > > are not organized in a simple tree: if bundle A requires bundle B
> and
> > > > > > bundle B requires
> > > > > > bundle C, it does not mean that C will be accessible to A.
> Following
> > > > > >
> > > > >
> > > >
> > > so
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > far ?
> > > > >
> > > > >
> > > > > > So, let's say I create a bundle that references the Stax Api.
> > > > > > My bundle will have the geronimo stax api in its classpath. The
> stax
> > > > > > implementation that
> > > > > > I deploy will also have the stax api in its classpath, but it
> won't be
> > > > > > available to either
> > > > > > the the stax api or my bundle.
> > > > > > The problem happens when the stax api needs to find and create the
> > > > > > implementation.
> > > > > > Usually, the existing code won't be able to do that at all,
> because
> > > > > > the META-INF/services
> > > > > > and the implementation class are not available from the stax api
> > > > > >
> > > > > >
> > > > > classloader.
> > > > >
> > > > >
> > > > > > One way to work around that is (if the api uses the thread context
> > > > > > classloader) to make sure
> > > > > > my bundle includes the implementation in its classloader and make
> sure
> > > > > > the thread context
> > > > > > classloader is correctly set. This usually involves copying the
> > > > > > META-INF/services/xx stuff
> > > > > > in our bundle and explicitely referencing the implementation to
> make
> > > > > > sure the classloader
> > > > > > includes it.
> > > > > >
> > > > > > The problem is that it's a bit annoying to do that on all the
> bundles
> > > > > > and it does prevent
> > > > > > swicthing implementations.
> > > > > >
> > > > > > So now, there is no need to reference the implementation from the
> > > > > > bundle. The spec jar bundle
> > > > > > activator will use OSGi to find the META-INF/services/ entries
> each
> > > > > > time a bundle is installed
> > > > > > and if an implementation is used, will load the class through OSGi
> > > > > > API, using the implementation
> > > > > > bundle classloader instead of the spec jar classloader.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > I think, just my personal opinion, that scouring bundles'
> > > > >
> > > >
> > > META-INF/services
> > >
> > > >
> > > > > entries is kinda klunky. Could we not use a service/whiteboard
> approach
> > > > > that is common in OSGi? When in Rome, do as the Romans do.
> > > > >
> > > > > Let's assume that we go with the virgin spec jar wrapped in a bundle
> > > > > paradigm I spoke of in a previous post. Here the bundles that use
> the
> > > > >
> > > >
> > > stax
> > >
> > > >
> > > > > api would register stax api service implementations. The stax api
> would
> > > > > catch those service registrations and properly configure the
> factory.
> > > > >
> > > >
> > > A
> > >
> > > >
> > > > > bit cleaner imo and you don't have to search every bundle.
> > > > >
> > > > >
> > > > > Regards,
> > > > > Alan
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > > Guillaume Nodet
> > > > ------------------------
> > > > Blog: http://gnodet.blogspot.com/
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> >
> >
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Apr 17, 2008 at 5:05 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> I must be missing something. That legacy code would not need to change.
> The whiteboard pattern only obviates the need to scavenge every bundle the
> META-INF/services entries. The rest works as you say.
>
> But, as I think about it some more, I'm thinking that this is over
> engineering it. Let's drop this aspect of the thread.
>
Actually it may be a good idea. I think it would allow running
multiple versions concurrently.
This would be true for jaxb 2.0 / 2.1 I think. The reason is that the
way I've done that, if you
deploy a jaxb 2.1 spec jar, it could try to create a jaxb 2.0
implementation. However, using the
whiteboard pattern, the implementation bundle would register its own
factory in OSGi, while the
spec jar would listen for compatible services. The benefit is that
OSGi can check the service
implementation wrt to classloader constraints and would not allow the
jaxb 2.1 spec bundle to
see a service implementing jaxb 2.0. This would only work if we use
the versions on the packages,
but it may be worth the extra work.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
I must be missing something. That legacy code would not need to
change. The whiteboard pattern only obviates the need to scavenge
every bundle the META-INF/services entries. The rest works as you say.
But, as I think about it some more, I'm thinking that this is over
engineering it. Let's drop this aspect of the thread.
I still feel strongly that the virgin spec jar should be wrapped in a
bundle.
Regards,
Alan
On Apr 17, 2008, at 7:54 AM, Guillaume Nodet wrote:
> i don't mean legacy jars but legacy *code*.
> If you have a jar which uses
> javax.xml.stream.XMLInputFactory.newInstance()
> somewhere deep in the code, I don't really understand how using a
> whiteboard
> pattern will solve the problem. I'm not trying to make people rewrite
> everything,
> but rather make things easy for them to deploy their application
> and keep the
> behavior they are used to see.
> it could be you want to deploy the jaxws-ri, jersey or any other
> xml related
> technology that could use SAAJ, Stax, Jaxb2 ...
>
>
> On Thu, Apr 17, 2008 at 4:40 PM, Alan D. Cabrera
> <li...@toolazydogs.com> wrote:
>> IIUC, they're not entirely legacy, i.e. you at least put in the OSGi
>> manifest entries. You do so using the maven/BND plugin I suspect.
>>
>> This strikes me as a common service discovery pattern. Off the
>> top of my
>> head I would think that a plugin that adds the necessary
>> BundleActivator for
>> legacy modules would be useful.
>>
>> Another thought that flashed in my head is that in a buttoned down
>> environment getting service notifications might be easier than
>> getting
>> access to every Bundle's class loader.
>>
>>
>> Regards,
>> Alan
>>
>>
>>
>> On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote:
>>
>>
>>> Cleaner, but the main problem is that it does not work with
>>> legacy code.
>>> Will you rewrite the jaxb2 implementation to do that instead of
>>> using the
>> stax
>>> factory ? ;-)
>>> We've got tons of legacy stuff that use stax, or jaxb2 and i
>>> don't see
>> rewriting
>>> the whole lot as realistic. it would also mean having an OSGi
>>> specific
>> thing
>>> everywhere we use a factory from a j2ee spec :-(
>>>
>>> On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera
>>> <li...@toolazydogs.com>
>> wrote:
>>>
>>>>
>>>>
>>>> On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:
>>>>
>>>>
>>>>
>>>>> On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski
>> <ja...@laskowski.net.pl>
>>>>>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>>> On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet
>>>>>> <gn...@gmail.com>
>>>>>>
>>>>>
>>>> wrote:
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Just to ensure I'm following, you are about to create a activator
>> that
>>>>>> would be a bundle listener (o.o.f.BundleListener) and whenever a
>>>>>> bundle is registered the activator will scan it for provided
>> services?
>>>>>> Can you explain how osgi works now without these
>>>>>> META-INF/services-based services? Doesn't it use them at all?
>>>>>>
>>>>>>
>>>>>
>>>>> This is the tricky part. The work we've done on the specs so far
>>>>> means that each spec
>>>>> is an OSGi bundle. In OSGi, each bundle has each own
>>>>> classloader and
>>>>> classloaders
>>>>> are not organized in a simple tree: if bundle A requires bundle
>>>>> B and
>>>>> bundle B requires
>>>>> bundle C, it does not mean that C will be accessible to A.
>>>>> Following
>> so
>>>>>
>>>> far ?
>>>>
>>>>> So, let's say I create a bundle that references the Stax Api.
>>>>> My bundle will have the geronimo stax api in its classpath.
>>>>> The stax
>>>>> implementation that
>>>>> I deploy will also have the stax api in its classpath, but it
>>>>> won't be
>>>>> available to either
>>>>> the the stax api or my bundle.
>>>>> The problem happens when the stax api needs to find and create the
>>>>> implementation.
>>>>> Usually, the existing code won't be able to do that at all,
>>>>> because
>>>>> the META-INF/services
>>>>> and the implementation class are not available from the stax api
>>>>>
>>>> classloader.
>>>>
>>>>> One way to work around that is (if the api uses the thread context
>>>>> classloader) to make sure
>>>>> my bundle includes the implementation in its classloader and
>>>>> make sure
>>>>> the thread context
>>>>> classloader is correctly set. This usually involves copying the
>>>>> META-INF/services/xx stuff
>>>>> in our bundle and explicitely referencing the implementation to
>>>>> make
>>>>> sure the classloader
>>>>> includes it.
>>>>>
>>>>> The problem is that it's a bit annoying to do that on all the
>>>>> bundles
>>>>> and it does prevent
>>>>> swicthing implementations.
>>>>>
>>>>> So now, there is no need to reference the implementation from the
>>>>> bundle. The spec jar bundle
>>>>> activator will use OSGi to find the META-INF/services/ entries
>>>>> each
>>>>> time a bundle is installed
>>>>> and if an implementation is used, will load the class through OSGi
>>>>> API, using the implementation
>>>>> bundle classloader instead of the spec jar classloader.
>>>>>
>>>>>
>>>>
>>>> I think, just my personal opinion, that scouring bundles'
>> META-INF/services
>>>> entries is kinda klunky. Could we not use a service/whiteboard
>>>> approach
>>>> that is common in OSGi? When in Rome, do as the Romans do.
>>>>
>>>> Let's assume that we go with the virgin spec jar wrapped in a
>>>> bundle
>>>> paradigm I spoke of in a previous post. Here the bundles that
>>>> use the
>> stax
>>>> api would register stax api service implementations. The stax
>>>> api would
>>>> catch those service registrations and properly configure the
>>>> factory.
>> A
>>>> bit cleaner imo and you don't have to search every bundle.
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>>
>>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
Re: Geronimo specs jars in OSGi
Posted by Guillaume Nodet <gn...@gmail.com>.
i don't mean legacy jars but legacy *code*.
If you have a jar which uses
javax.xml.stream.XMLInputFactory.newInstance()
somewhere deep in the code, I don't really understand how using a whiteboard
pattern will solve the problem. I'm not trying to make people rewrite
everything,
but rather make things easy for them to deploy their application and keep the
behavior they are used to see.
it could be you want to deploy the jaxws-ri, jersey or any other xml related
technology that could use SAAJ, Stax, Jaxb2 ...
On Thu, Apr 17, 2008 at 4:40 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> IIUC, they're not entirely legacy, i.e. you at least put in the OSGi
> manifest entries. You do so using the maven/BND plugin I suspect.
>
> This strikes me as a common service discovery pattern. Off the top of my
> head I would think that a plugin that adds the necessary BundleActivator for
> legacy modules would be useful.
>
> Another thought that flashed in my head is that in a buttoned down
> environment getting service notifications might be easier than getting
> access to every Bundle's class loader.
>
>
> Regards,
> Alan
>
>
>
> On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote:
>
>
> > Cleaner, but the main problem is that it does not work with legacy code.
> > Will you rewrite the jaxb2 implementation to do that instead of using the
> stax
> > factory ? ;-)
> > We've got tons of legacy stuff that use stax, or jaxb2 and i don't see
> rewriting
> > the whole lot as realistic. it would also mean having an OSGi specific
> thing
> > everywhere we use a factory from a j2ee spec :-(
> >
> > On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
> >
> > >
> > >
> > > On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:
> > >
> > >
> > >
> > > > On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski
> <ja...@laskowski.net.pl>
> > > >
> > > wrote:
> > >
> > > >
> > > >
> > > > > On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <gn...@gmail.com>
> > > > >
> > > >
> > > wrote:
> > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > > 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.
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > Just to ensure I'm following, you are about to create a activator
> that
> > > > > would be a bundle listener (o.o.f.BundleListener) and whenever a
> > > > > bundle is registered the activator will scan it for provided
> services?
> > > > > Can you explain how osgi works now without these
> > > > > META-INF/services-based services? Doesn't it use them at all?
> > > > >
> > > > >
> > > >
> > > > This is the tricky part. The work we've done on the specs so far
> > > > means that each spec
> > > > is an OSGi bundle. In OSGi, each bundle has each own classloader and
> > > > classloaders
> > > > are not organized in a simple tree: if bundle A requires bundle B and
> > > > bundle B requires
> > > > bundle C, it does not mean that C will be accessible to A. Following
> so
> > > >
> > > far ?
> > >
> > > > So, let's say I create a bundle that references the Stax Api.
> > > > My bundle will have the geronimo stax api in its classpath. The stax
> > > > implementation that
> > > > I deploy will also have the stax api in its classpath, but it won't be
> > > > available to either
> > > > the the stax api or my bundle.
> > > > The problem happens when the stax api needs to find and create the
> > > > implementation.
> > > > Usually, the existing code won't be able to do that at all, because
> > > > the META-INF/services
> > > > and the implementation class are not available from the stax api
> > > >
> > > classloader.
> > >
> > > > One way to work around that is (if the api uses the thread context
> > > > classloader) to make sure
> > > > my bundle includes the implementation in its classloader and make sure
> > > > the thread context
> > > > classloader is correctly set. This usually involves copying the
> > > > META-INF/services/xx stuff
> > > > in our bundle and explicitely referencing the implementation to make
> > > > sure the classloader
> > > > includes it.
> > > >
> > > > The problem is that it's a bit annoying to do that on all the bundles
> > > > and it does prevent
> > > > swicthing implementations.
> > > >
> > > > So now, there is no need to reference the implementation from the
> > > > bundle. The spec jar bundle
> > > > activator will use OSGi to find the META-INF/services/ entries each
> > > > time a bundle is installed
> > > > and if an implementation is used, will load the class through OSGi
> > > > API, using the implementation
> > > > bundle classloader instead of the spec jar classloader.
> > > >
> > > >
> > >
> > > I think, just my personal opinion, that scouring bundles'
> META-INF/services
> > > entries is kinda klunky. Could we not use a service/whiteboard approach
> > > that is common in OSGi? When in Rome, do as the Romans do.
> > >
> > > Let's assume that we go with the virgin spec jar wrapped in a bundle
> > > paradigm I spoke of in a previous post. Here the bundles that use the
> stax
> > > api would register stax api service implementations. The stax api would
> > > catch those service registrations and properly configure the factory.
> A
> > > bit cleaner imo and you don't have to search every bundle.
> > >
> > >
> > > Regards,
> > > Alan
> > >
> > >
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> >
> >
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
IIUC, they're not entirely legacy, i.e. you at least put in the OSGi
manifest entries. You do so using the maven/BND plugin I suspect.
This strikes me as a common service discovery pattern. Off the top of
my head I would think that a plugin that adds the necessary
BundleActivator for legacy modules would be useful.
Another thought that flashed in my head is that in a buttoned down
environment getting service notifications might be easier than getting
access to every Bundle's class loader.
Regards,
Alan
On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote:
> Cleaner, but the main problem is that it does not work with legacy
> code.
> Will you rewrite the jaxb2 implementation to do that instead of
> using the stax
> factory ? ;-)
> We've got tons of legacy stuff that use stax, or jaxb2 and i don't
> see rewriting
> the whole lot as realistic. it would also mean having an OSGi
> specific thing
> everywhere we use a factory from a j2ee spec :-(
>
> On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera
> <li...@toolazydogs.com> wrote:
>>
>>
>> On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:
>>
>>
>>> On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski <jacek@laskowski.net.pl
>>> >
>> wrote:
>>>
>>>> On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <gn...@gmail.com>
>> wrote:
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Just to ensure I'm following, you are about to create a activator
>>>> that
>>>> would be a bundle listener (o.o.f.BundleListener) and whenever a
>>>> bundle is registered the activator will scan it for provided
>>>> services?
>>>> Can you explain how osgi works now without these
>>>> META-INF/services-based services? Doesn't it use them at all?
>>>>
>>>
>>> This is the tricky part. The work we've done on the specs so far
>>> means that each spec
>>> is an OSGi bundle. In OSGi, each bundle has each own classloader
>>> and
>>> classloaders
>>> are not organized in a simple tree: if bundle A requires bundle B
>>> and
>>> bundle B requires
>>> bundle C, it does not mean that C will be accessible to A.
>>> Following so
>> far ?
>>> So, let's say I create a bundle that references the Stax Api.
>>> My bundle will have the geronimo stax api in its classpath. The
>>> stax
>>> implementation that
>>> I deploy will also have the stax api in its classpath, but it
>>> won't be
>>> available to either
>>> the the stax api or my bundle.
>>> The problem happens when the stax api needs to find and create the
>>> implementation.
>>> Usually, the existing code won't be able to do that at all, because
>>> the META-INF/services
>>> and the implementation class are not available from the stax api
>> classloader.
>>> One way to work around that is (if the api uses the thread context
>>> classloader) to make sure
>>> my bundle includes the implementation in its classloader and make
>>> sure
>>> the thread context
>>> classloader is correctly set. This usually involves copying the
>>> META-INF/services/xx stuff
>>> in our bundle and explicitely referencing the implementation to make
>>> sure the classloader
>>> includes it.
>>>
>>> The problem is that it's a bit annoying to do that on all the
>>> bundles
>>> and it does prevent
>>> swicthing implementations.
>>>
>>> So now, there is no need to reference the implementation from the
>>> bundle. The spec jar bundle
>>> activator will use OSGi to find the META-INF/services/ entries each
>>> time a bundle is installed
>>> and if an implementation is used, will load the class through OSGi
>>> API, using the implementation
>>> bundle classloader instead of the spec jar classloader.
>>>
>>
>> I think, just my personal opinion, that scouring bundles' META-INF/
>> services
>> entries is kinda klunky. Could we not use a service/whiteboard
>> approach
>> that is common in OSGi? When in Rome, do as the Romans do.
>>
>> Let's assume that we go with the virgin spec jar wrapped in a bundle
>> paradigm I spoke of in a previous post. Here the bundles that use
>> the stax
>> api would register stax api service implementations. The stax api
>> would
>> catch those service registrations and properly configure the
>> factory. A
>> bit cleaner imo and you don't have to search every bundle.
>>
>>
>> Regards,
>> Alan
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
Re: Geronimo specs jars in OSGi
Posted by Guillaume Nodet <gn...@gmail.com>.
Cleaner, but the main problem is that it does not work with legacy code.
Will you rewrite the jaxb2 implementation to do that instead of using the stax
factory ? ;-)
We've got tons of legacy stuff that use stax, or jaxb2 and i don't see rewriting
the whole lot as realistic. it would also mean having an OSGi specific thing
everywhere we use a factory from a j2ee spec :-(
On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>
> On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:
>
>
> > On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski <ja...@laskowski.net.pl>
> wrote:
> >
> > > On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <gn...@gmail.com>
> wrote:
> > >
> > >
> > > > 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.
> > > >
> > >
> > > Just to ensure I'm following, you are about to create a activator that
> > > would be a bundle listener (o.o.f.BundleListener) and whenever a
> > > bundle is registered the activator will scan it for provided services?
> > > Can you explain how osgi works now without these
> > > META-INF/services-based services? Doesn't it use them at all?
> > >
> >
> > This is the tricky part. The work we've done on the specs so far
> > means that each spec
> > is an OSGi bundle. In OSGi, each bundle has each own classloader and
> > classloaders
> > are not organized in a simple tree: if bundle A requires bundle B and
> > bundle B requires
> > bundle C, it does not mean that C will be accessible to A. Following so
> far ?
> > So, let's say I create a bundle that references the Stax Api.
> > My bundle will have the geronimo stax api in its classpath. The stax
> > implementation that
> > I deploy will also have the stax api in its classpath, but it won't be
> > available to either
> > the the stax api or my bundle.
> > The problem happens when the stax api needs to find and create the
> > implementation.
> > Usually, the existing code won't be able to do that at all, because
> > the META-INF/services
> > and the implementation class are not available from the stax api
> classloader.
> > One way to work around that is (if the api uses the thread context
> > classloader) to make sure
> > my bundle includes the implementation in its classloader and make sure
> > the thread context
> > classloader is correctly set. This usually involves copying the
> > META-INF/services/xx stuff
> > in our bundle and explicitely referencing the implementation to make
> > sure the classloader
> > includes it.
> >
> > The problem is that it's a bit annoying to do that on all the bundles
> > and it does prevent
> > swicthing implementations.
> >
> > So now, there is no need to reference the implementation from the
> > bundle. The spec jar bundle
> > activator will use OSGi to find the META-INF/services/ entries each
> > time a bundle is installed
> > and if an implementation is used, will load the class through OSGi
> > API, using the implementation
> > bundle classloader instead of the spec jar classloader.
> >
>
> I think, just my personal opinion, that scouring bundles' META-INF/services
> entries is kinda klunky. Could we not use a service/whiteboard approach
> that is common in OSGi? When in Rome, do as the Romans do.
>
> Let's assume that we go with the virgin spec jar wrapped in a bundle
> paradigm I spoke of in a previous post. Here the bundles that use the stax
> api would register stax api service implementations. The stax api would
> catch those service registrations and properly configure the factory. A
> bit cleaner imo and you don't have to search every bundle.
>
>
> Regards,
> Alan
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:
> On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski <jacek@laskowski.net.pl
> > wrote:
>> On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <gn...@gmail.com>
>> wrote:
>>
>>> 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.
>>
>> Just to ensure I'm following, you are about to create a activator
>> that
>> would be a bundle listener (o.o.f.BundleListener) and whenever a
>> bundle is registered the activator will scan it for provided
>> services?
>> Can you explain how osgi works now without these
>> META-INF/services-based services? Doesn't it use them at all?
>
> This is the tricky part. The work we've done on the specs so far
> means that each spec
> is an OSGi bundle. In OSGi, each bundle has each own classloader and
> classloaders
> are not organized in a simple tree: if bundle A requires bundle B and
> bundle B requires
> bundle C, it does not mean that C will be accessible to A.
> Following so far ?
> So, let's say I create a bundle that references the Stax Api.
> My bundle will have the geronimo stax api in its classpath. The stax
> implementation that
> I deploy will also have the stax api in its classpath, but it won't be
> available to either
> the the stax api or my bundle.
> The problem happens when the stax api needs to find and create the
> implementation.
> Usually, the existing code won't be able to do that at all, because
> the META-INF/services
> and the implementation class are not available from the stax api
> classloader.
> One way to work around that is (if the api uses the thread context
> classloader) to make sure
> my bundle includes the implementation in its classloader and make sure
> the thread context
> classloader is correctly set. This usually involves copying the
> META-INF/services/xx stuff
> in our bundle and explicitely referencing the implementation to make
> sure the classloader
> includes it.
>
> The problem is that it's a bit annoying to do that on all the bundles
> and it does prevent
> swicthing implementations.
>
> So now, there is no need to reference the implementation from the
> bundle. The spec jar bundle
> activator will use OSGi to find the META-INF/services/ entries each
> time a bundle is installed
> and if an implementation is used, will load the class through OSGi
> API, using the implementation
> bundle classloader instead of the spec jar classloader.
I think, just my personal opinion, that scouring bundles' META-INF/
services entries is kinda klunky. Could we not use a service/
whiteboard approach that is common in OSGi? When in Rome, do as the
Romans do.
Let's assume that we go with the virgin spec jar wrapped in a bundle
paradigm I spoke of in a previous post. Here the bundles that use the
stax api would register stax api service implementations. The stax
api would catch those service registrations and properly configure the
factory. A bit cleaner imo and you don't have to search every bundle.
Regards,
Alan
Re: Geronimo specs jars in OSGi
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>
> > 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.
>
> Just to ensure I'm following, you are about to create a activator that
> would be a bundle listener (o.o.f.BundleListener) and whenever a
> bundle is registered the activator will scan it for provided services?
> Can you explain how osgi works now without these
> META-INF/services-based services? Doesn't it use them at all?
This is the tricky part. The work we've done on the specs so far
means that each spec
is an OSGi bundle. In OSGi, each bundle has each own classloader and
classloaders
are not organized in a simple tree: if bundle A requires bundle B and
bundle B requires
bundle C, it does not mean that C will be accessible to A. Following so far ?
So, let's say I create a bundle that references the Stax Api.
My bundle will have the geronimo stax api in its classpath. The stax
implementation that
I deploy will also have the stax api in its classpath, but it won't be
available to either
the the stax api or my bundle.
The problem happens when the stax api needs to find and create the
implementation.
Usually, the existing code won't be able to do that at all, because
the META-INF/services
and the implementation class are not available from the stax api classloader.
One way to work around that is (if the api uses the thread context
classloader) to make sure
my bundle includes the implementation in its classloader and make sure
the thread context
classloader is correctly set. This usually involves copying the
META-INF/services/xx stuff
in our bundle and explicitely referencing the implementation to make
sure the classloader
includes it.
The problem is that it's a bit annoying to do that on all the bundles
and it does prevent
swicthing implementations.
So now, there is no need to reference the implementation from the
bundle. The spec jar bundle
activator will use OSGi to find the META-INF/services/ entries each
time a bundle is installed
and if an implementation is used, will load the class through OSGi
API, using the implementation
bundle classloader instead of the spec jar classloader.
>
>
> > 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 ?
>
> Unless I'm mistaken it shouldn't cause any troubles on non-osgi
> environments and big +1 for the upcoming changes.
Exactly, the behavior should be exactly the same in non OSGi environment.
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> 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.
Just to ensure I'm following, you are about to create a activator that
would be a bundle listener (o.o.f.BundleListener) and whenever a
bundle is registered the activator will scan it for provided services?
Can you explain how osgi works now without these
META-INF/services-based services? Doesn't it use them at all?
> 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 ?
Unless I'm mistaken it shouldn't cause any troubles on non-osgi
environments and big +1 for the upcoming changes.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl