Richard S. Hall wrote:
> Sahoo wrote:
>> Paul Sandoz wrote:
>>>
>>> On Oct 8, 2008, at 11:22 AM, Sahoo wrote:
>>>
>>>> Jakub Podlesak wrote:
>>>>> On Wed, Oct 08, 2008 at 08:08:38AM +0530, Sahoo wrote:
>>>>>
>>>>>> That bundle is an implementation artifact and is not to be used
>>>>>> by applications. Since applications can't always use the version
>>>>>> of ASM that server requires, we have to hide the version that
>>>>>> server requires. We do so by using those extra attributes. Only
>>>>>> people who deploy OSGi bundles can use that bundle if they
>>>>>> suitably specify the import headers in their bundles, but that
>>>>>> does not apply to normal web app deployment.
>>>>>
>>>>> I am in fact adding a Jersey based module
>>>>> to GlassFish, so that users could deploy Jersey based apps without
>>>>> a need
>>>>> to bundle additional jars into their wars.
>>>>>
>>>>> So i believe there are two possible ways how to resolve the
>>>>> asm-3.1 dependency
>>>>> for Jersey module here:
>>>>>
>>>>> 1. Jersey module would use the required GlassFish specific attributes
>>>>> in the ImportPackages header for the asm related packages
>>>>>
>>>>> 2. I would provide an OSGified asm 3.1 module and put it into
>>>>> GlassFish modules.
>>>>> It shouldn't create any conflict with your privately updated
>>>>> [asm-all-repackaged.jar]
>>>>> module, as you use a GlassFish specific attributes in it's OSGi
>>>>> headers
>>>>> Is my assumptions correct?
>>>>>
>>>>>
>>>> Yes, they are correct. If you can use #1, then better as it
>>>> increases sharing of classes.
>>>>
>>>
>>> #1 would make the Jersey module GF specific,
>> Not really. Specifying that extra attribute in Import-Package does
>> not make it GF specific.
>
> It will only work with exporters that have 'password="GlassFish"'...so
> it just depends on how you define GF specific.
>
Thanks Richard pointing this out. I had misinterpreted the "attribute
matching" section. I was wrong. It will indeed make Jersy bundle GF
specific if #1 is followed.
Thanks,
Sahoo