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, but i am not sure that is
an issue since we are relying implicitly on the GF OSGi container for
other support e.g. META-INF/services support.
Paul.
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>