Bill Shannon wrote:
> Craig L Russell wrote:
>>
>> On Aug 21, 2008, at 1:21 PM, Bill Shannon wrote:
>>
>>> Craig L Russell wrote:
>>>> Apropos of:
>>>>> We already had to export a lot of supposedly private packages that
>>>>> contained classes that were looked up through META-INF/services.
>>>> I'm interested in the answer to this question:
>>>> If an OSGi-enabled jar file has an entry in META-INF/services/foo
>>>> and the contents of the file foo is com.sun.fooservice.Foofactory,
>>>> does com.sun.fooservice have to be exported?
>>>
>>> I'm curious too. I assume the answer is "yes".
>>>
>>> Or at least it's a "should", if not a "must".
>>
>> Ok, I'm of the opinion that if the service is self-contained in the
>> jar file, and all of its dependencies are listed as imports, then the
>> implementation class should not (best practice) be exported. This
>> preserves encapsulation since only the ServiceLoader needs to know
>> anything about the package.
>>
>> By the way is there any interaction between ServiceLoader and OSGi?
>> (I know, RTFM ;-)
>>
>> Here's what Richard Hall has to offer, which I agree with:
>>> It depends on how you want to use it, but I would say no. It only
>>> has to be on the Bundle-ClassPath, so you should be able to load it
>>> from the bundle's class loader, which is the main requirement.
>
> Since ServiceLoader is loading the class, and ServiceLoader isn't in the
> same bundle/module as the class, seems to me it shouldn't be able to
> access the class. If the JVM were enforcing module boundaries, wouldn't
> this fail if the implementation class isn't exported?
Conceptually, that is accurate, but OSGi cannot do such enforcement. For
OSGi, there is only one class loader that is used to load classes from a
bundle, so if you get a reference to the class loader then you can load
any class from the bundle that is on its bundle class path. Typically,
bundles should not be loading classes this way and should only use their
own class loader which will delegate appropriately.
In the long run, if we get VM support for module visibility, then yes
this could be an issue, but for me it is probably more a sign of how the
META-INF/services approach is broken with respect to modularity.
-> richard
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>