Fabian Ritzmann wrote:
> 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.
A bundle's class loader is able to load everything from its own class
path, otherwise it would not be able to function. If you load a class
from bundle B (e.g., Bundle.loadClass() or by directly gettings its
class loader), it will be loaded by bundle B's class loader. All
subsequent class loads instigated by that class will be first directed
to bundle B's class loader, which should be able to load anything on the
bundle class path.
Perhaps I do not understand the scenario well enough, but it just
doesn't sound right. Can you boil down an example that demonstrates the
situation for me to look at?
-> richard
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>