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
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 rev
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
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 no
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, hav
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
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 ma
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
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 lega
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 havi
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 o
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
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
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:
> So
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'
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
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) t
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 th
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
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 fin
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
>
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 ar
22 matches
Mail list logo
