On 22. Aug 2008, at 02:11, Richard S. Hall wrote:
> 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.
The problem is that we got NoClassDefinitionErrors all over the place
as long as these particular packages were not exported. As soon as I
added exports for exactly these packages the errors went away. I am
pretty certain there were no issues with the Bundle-Classpath. We
don't have it set and the default is just right.
BTW, Bhakti and me are working with Java 5. That is because Java 6 has
an older version of JAX-WS (which is a part of Metro) incorporated and
as long as Felix is configured with
org.osgi.framework.bootdelegation=*, we cannot be certain that our
classes are loaded from the right place with Java 6.
Fabian
>> 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