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?
It depends on how you want to use it, but I would say no. It only has to
be one the Bundle-ClassPath, then you should be able to load it from the
bundle's class loader, which is the main requirement.
-> richard
>
> Thanks,
>
> Craig
>
> On Aug 21, 2008, at 11:11 AM, Fabian Ritzmann wrote:
>
>> On 21. Aug 2008, at 16:12, Sahoo wrote:
>>
>>> Since you are delivering a single metro bundle that contains
>>> everything, how exporting implementation packages help? Are those
>>> packages used by other bundles?
>>
>> We already had to export a lot of supposedly private packages that
>> contained classes that were looked up through META-INF/services. We
>> also saw issues loading properties for localized log messages.
>> Typically every package has one property file in Metro. As it stands,
>> we would probably have spent weeks (on top of the existing two months
>> we put into this already) iteratively chasing down all these packages
>> and exporting them. Since our test coverage is not 100% we could not
>> have been certain that we really exported all packages that had to be
>> exported. Altogether, I believe we would have had to export so many
>> packages that we might as well export all of them and be on the safe
>> side.
>>
>> Fabian
>>
>>
>>> Fabian Ritzmann wrote:
>>>> Hi,
>>>>
>>>> I had originally planned to export only those Metro packages for
>>>> the GF V3 OSGi bundles that were public interfaces, e.g.
>>>> java.xml.ws, com.sun.xml.ws.api, etc. However we have had issues
>>>> e.g. loading property files for localized log messages if the
>>>> packages that contained these files were not exported. I have
>>>> changed my thinking and I believe now that exporting all packages
>>>> for a stack like Metro is the right thing to do for various reasons:
>>>>
>>>> - Rearchitecting Metro to employ OSGi services internally is far
>>>> too much work, i.e. we have to continue using the existing logging,
>>>> service lookup, etc. mechanisms already implemented in Metro.
>>>>
>>>> - The Metro stack consists of dozens of libraries that may be
>>>> combined and run in an uncontrollable amount of environments. These
>>>> libraries can not rely on the availability of an OSGi container.
>>>>
>>>> - Exporting all packages is not worse than what we have in GF V2,
>>>> where all packages are available globally through the regular Java
>>>> classloading mechanisms.
>>>>
>>>> Fabian
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell_at_sun.com
> P.S. A good JDO? O, Gasp!
>