From: Craig L Russell <Craig.Russell_at_Sun.COM>
Date: Thu, 21 Aug 2008 13:09:28 -0700

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?

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!