users@glassfish.java.net

RE: OSGi Web Bundle Classloader Magic

From: Martin Gainty <mgainty_at_hotmail.com>
Date: Sun, 26 Jun 2011 10:32:02 -0400

Harald

are you implementing jersey-guice injector?
http://svn-mirror.glassfish.org/jersey/tags/jersey-1.5-ea02/jersey/samples/jersey-guice-filter/README.html

can you verify the GF app was stopped and started to ingest the refactored web.xml
?
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.




> Date: Sun, 26 Jun 2011 13:55:56 +0200
> From: harald.wellmann_at_gmx.de
> To: users_at_glassfish.java.net
> Subject: OSGi Web Bundle Classloader Magic
>
> 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