On 03.03.11 07:01, "Unmesh Joshi" <[email protected]> wrote: >1. Why would the classes be resolved in JSP components when exported >from a OSGI bundle which includes all the shared jars. > Here they are not getting loaded by shared ear class loader.
If these are JSPs running inside Sling, I would guess: it might be that the classloader used by the JSP scripting engine actually directly uses the shared classloader from the servlet container, without the need for the special framework extension fragment in the OSGi container. But not sure. > Some colleagues told me that session objects are actually getting >serialized and then deserialized in OSGI container, so the behaviour >is similar to how remote calls work with serialization. No, there is no serialization going on. AFAIK this only happens in servlet containers that cache sessions on disk and/or move the session across instances and hence need to serialize/deserialize them. This statefulness (and complexity) you get here from using http sessions is the central point why they are considered a bad idea (tm). OSGi itself doesn't do anything here (since it is about classloading and a general framework) and Sling also doesn't do anything with HttpSessions, so they use them as they are provided by the underlying servlet container. >2. How does OSGI framework know about Ear classloader as its parent >classloader (and not go to Java system classloader)? > In the OSGI bundles, if I try to get parent classloader by calling >getClassLoader().getParent(), I get null, which I suppose means >bootstrap classloader. I think the OSGi class loader prevents you from going to the parent class loader, in order to make sure its class loading mechanism is not mitigated. Internally it still has access to the parent class loader that it gets from the servlet container (if the OSGi framework is running inside a webapp, as it is the case with Sling), but here you need the framework extension fragment being present so that OSGi can properly pass those classes "through" (again, not 100% sure, Felix probably knows it much better than me). Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
