On Wed, Oct 08, 2008 at 11:53:56AM +0200, 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, 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.
I could then provide the asm module as a separate
UC module to allow better sharing (other modules available via UC could depend on this one)
and keep the Jersey module from being GlassFish specific in this regard.
Will see what works better for me.
~Jakub
>
> 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
--
http://blogs.sun.com/japod