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 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 <[EMAIL PROTECTED]>
> 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
> <[EMAIL PROTECTED]>
> > > >
> > > wrote:
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > 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 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/

Reply via email to