Hi, I have updated the FAQ page with question on session sharing. https://cwiki.apache.org/confluence/display/SLING/FAQ#FAQ-HowtosharesessionbetweenSlingandotherwebapplications%3F
Thanks, Unmesh > On Sat, Mar 12, 2011 at 11:56 PM, Unmesh Joshi <[email protected]> wrote: >> Hi Felix, >> >> I will surely add it to FAQ. >> >> Thanks, >> Unmesh >> >> On Fri, Mar 11, 2011 at 6:20 PM, Felix Meschberger <[email protected]> >> 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 <[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 >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> > >>> >>> >>> >> >
