Richard S. Hall 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?
>
> 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.
D'oh! That should say, "...on the Bundle-ClassPath..."
-> richard
>
> -> 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!
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>