Found another problem although slightly different. Although the session
objects in the Sling JSP are accessible by
request.getSession().getAttribute("key") they are not accessible via <c:out
value="${sessionScope.key}" /> (jstl). I have no problem with the
requestScope objects but the sessionScope objects are null.
Not sure if anybody can shed any light on this but these are interesting
findings.
Sarwar
On Fri, Mar 11, 2011 at 12:50 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
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
>
>
>
