dev@glassfish.java.net

Re: [v3] exporting all Metro packages for OSGi

From: Bhakti Mehta <Bhakti.Mehta_at_Sun.COM>
Date: Thu, 21 Aug 2008 15:32:35 -0700

I assume this is an approach to the extender pattern.
http://gnodet.blogspot.com/2008/05/jee-specs-in-osgi.html
I was anticipating that we would need to do something like this for our
service lookups but Fabian is mentioning that exporting all packages
worked for him. FWIW We are having the apis and implementation bundled
together in one bundle
I am still having issues with it so will follow up later on that..

Regards,
Bhakti
Richard S. Hall wrote:
> Bill Shannon wrote:
>> Richard S. Hall wrote:
>>> In such a future with VM support, I would say yes. This is somewhat
>>> ugly, but not much can be done about it. What you really want to
>>> have happen is that the service provider publishes their own
>>> services using a common Factory interface (in OSGi this could be
>>> published into the service registry), so that no one would ever need
>>> to know their implementation class, but at least if it can be
>>> limited to the ServiceLoader, that is better than nothing.
>>
>> An advantage of ServiceLoader is that the publishing has *zero* cost.
>> You pay nothing until you need to use something that's been published.
>>
>> My limited understanding of OSGi is that I would need to have a bundle
>> activator that ran code that created an instance and registered that
>> instance "somewhere", even if no one ever used the instance.
>
> This is basically true, but there are potential patterns and
> approaches for dealing with this too...one of which, the extender
> pattern, is what you guys might already be employing, if I understand
> correctly...
>
> -> richard
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>