sling-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unmesh Joshi <unmeshjo...@gmail.com>
Subject Re: sharing http session between sling servlets and other web applications in an EAR
Date Fri, 11 Mar 2011 10:05:32 GMT
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.bhuiyan@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
> <aklimets@adobe.com>wrote:
>
>> On 03.03.11 19:47, "Unmesh Joshi" <unmeshjoshi@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
>>
>>
>>
>>
>>
>

Mime
View raw message