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
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
On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED] 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
On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski [EMAIL PROTECTED] wrote:
On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED] wrote:
However, lots of these spec jars define factories (stax, saaj for example)
that use the META-INF/services/ discovery mechanism to find an
On Wed, Apr 16, 2008 at 5:49 PM, David Jencks [EMAIL PROTECTED] 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
On Thursday 17 April 2008, Jacek Laskowski wrote:
On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED]
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
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)
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
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
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 [EMAIL PROTECTED] 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
On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:
On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski [EMAIL PROTECTED]
wrote:
On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED]
wrote:
However, lots of these spec jars define factories (stax, saaj for
example)
that use
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
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
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
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
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
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.
On Thu, Apr 17, 2008 at 5:05 PM, Alan D. Cabrera [EMAIL PROTECTED] 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
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
On Thu, Apr 17, 2008 at 5:05 PM, Alan D. Cabrera [EMAIL PROTECTED] 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
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
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
23 matches
Mail list logo
