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