Harald,
What exactly you mean by "W can load classes from B?" Is W loading a
class from B reflectively? While loading classes, what matters is the
class loader being used to initiate the loading. You must be using
thread's context class loader to load the class. In the context of
request processing or deployment, GlassFish sets the context class
loader of the WAB to be a class loader which can load from WAB as well
as from other bundle's exported packages.
Thanks,
Sahoo
On Sunday 26 June 2011 05:25 PM, Harald Wellmann wrote:
> I have a Web Application Bundle B which depends on some other bundle
> W. B and W and some other dependencies are deployed to GlassFish
> 3.1.1_b06 as OSGi bundles, by copying the whole lot to
> autodeploy/bundles.
>
> I was surprised to see that W can load classes from B, and I wonder
> why and how this works - after all, it's B that imports W and not vice
> versa. Does the GlassFish Web Extender set B's bundle class loader as
> ThreadContextClassLoader? (This would be a possible explanation, and
> this is exactly what I noticed when running the same bundles on Jetty
> + Pax.)
>
> The OSGi Enterprise Web Applications Spec does not say anything about
> class loaders, so I wonder if it is safe and portable to rely on this
> behaviour.
>
> Some background: W is Apache Wicket, with a patched manifest that does
> not use DynamicImport-Package. B is a simple Wicket web application
> which installs the WicketFilter in web.xml, passing my application
> class name as an init-parameter to the filter. WicketFilter loads this
> class by name, which should not work by normal OSGi rules, but does
> work for some reason I would like to understand.
>
> My scenario is described in detail in
> http://code.google.com/p/osgi-enterprise/wiki/WicketAndOsgi, but maybe
> that's not really needed to shed some light on my question.
>
> Thanks,
> Harald