Hi Sarwar, I did a little more investigation on why it was working with JSPs and not with sling servlets. Following is the reason.
Weblogic uses context classloader of the thread to resolve classes while deserializing session objects. When JSP is processed in Sling, the context classloader is org.apache.sling.commons.classloader.impl.ClassLoaderFacade This classloader can find classes exported from OSGI bundles loaded in felix. When servlet is executed the context classloader is weblogic.utils.classloaders.ChangeAwareClassLoader. This classloader finds classes in EAR or classpath, so we get ClassCastException. The worst part here is that, once the object is deserialized, weblogic replaces original object reference to the deserialized object. So if any other WAR needs the object again, it needs to be serialized/deserialized again. But that works only if original object is loaded with weblogic classloader. So once object is serialized/deserialized with Sling classloader, it will never be serialized/deserialized for other WARs and you will always get ClassCastException. So class/session sharing should never be done with classes packaged and exported in an OSGI bundle. Relying on weblogic to serialize and deserialize is always likely to fail. System fragment extensions is the only safer approach in this case. Thanks, Unmesh On Fri, Mar 4, 2011 at 5:26 PM, Sarwar Bhuiyan <[email protected]> wrote: > We got the session object casting working when we used Felix's suggestion of > the fragment bundle. > > However, the question of the JSP is still there. > > Sarwar > > > On Fri, Mar 4, 2011 at 11:37 AM, Alexander Klimetschek > <[email protected]>wrote: > >> On 03.03.11 19:47, "Unmesh Joshi" <[email protected]> wrote: >> >> >The actual deserialization is going on and it happens only when >> >session.getAttribute is called from JSP in sling. If its called from >> >SlingServlet, which is in OSGI bundle, this doesn't happen. >> >We do not need serialization at all, but not sure why this kind of >> >thing is happening only when called from JSP running in sling. >> >> Ok, that sounds a bit weird. How does the stack trace (when debugging) >> look like if you call session.getAttribute() from a servlet in sling? >> >> Regards, >> Alex >> >> -- >> Alexander Klimetschek >> Developer // Adobe (Day) // Berlin - Basel >> >> >> >> >> >
