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 > >> > >> > >> > >> > >> > >
