Bhakti Mehta wrote:
> 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..
Yes, that is an example of the extender pattern, but you do not
necessarily need activators with the extender pattern, which is sounds
like the proposed above does use. It is not necessary to export
everything if they are on the bundle class path, since you will be able
to access everything on the bundle class path from the bundle's class
loader, so it is best to avoid exporting everything. However, as Bill
points out, in a world where we have module private classes then this
could also be an issue.
-> richard
>
> 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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>