Hi Felix, I will surely add it to FAQ.
Thanks, Unmesh On Fri, Mar 11, 2011 at 6:20 PM, Felix Meschberger <fmesc...@adobe.com> wrote: > Hi Unmesh, > > Thanks alot for this great write-up ! This makes perfect sense now. > > May I ask you to write a small FAQ entry to the Sling Wiki FAQ [1] ? > That would be nice. Thanks alot. > > Regards > Felix > > [1] https://cwiki.apache.org/confluence/display/SLING/FAQ > > Am Freitag, den 11.03.2011, 10:05 +0000 schrieb Unmesh Joshi: >> 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 <sarwar.bhui...@gmail.com> >> 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 >> > <aklim...@adobe.com>wrote: >> > >> >> On 03.03.11 19:47, "Unmesh Joshi" <unmeshjo...@gmail.com> 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 >> >> >> >> >> >> >> >> >> >> >> > > > >
