I managed to figure out why weblogic is serializing session objects.
It has nothing to do with Sling JSPs/Servlets.
Its little strange and not documented anywhere in weblogic
documentation. Explanation follows.
If two web applications need to share classes and session objects,
there are two ways to do it
First Package both web applications in EAR, then either
1. Have shared classes in jar placed in APP-INF/lib directory.
or
2. Have shared classes in a common place say lib directory at EAR
level. Then in each WAR, have a Class-Path attribute in
META-INF/MANIFESH.MF which explicitly lists the jar file
Approach 2 is where serialization happens. When you have Class-Path in
MANIFEST.MF, the classes are still loaded by WAR class loader.
If both the web applications are sharing session objects and refering
to classes referred in MANIFEST.MF, you should ideally be getting
ClassCastException. This happens if classes do not implement
Serializable.
But the behaviour is very different if classes used in session objects
are implementing Serializable.
Weblogic seems to serialize and then deserialize objects in session,
whenever session.getAttribute is called. This makes it possible to
have classes loaded by separate WAR classloaders, but still possible
to share Session objects,
If we have CQ packaged as a Web Application in an EAR, we need to have
Class-path entry in manifest.mf file of launchpad.war.
to refer to shared jars.
Then, whenever you access session objects in Sling, the objects are
serialized and deserialized again and resolved to classes in Sling
bundle class space.
So approach to share classes and session in Sling with other web
application is as following.
1. Package CQ/Sling as web application in an existing EAR.
2. Deploy system.bundle extension fragment exporting all the packages
that you need to access in CQ.
3. In Weblogic, there are two ways to share classes
a) Put all the shared jars in APP-INF/lib directory in EAR. With
this approach you do not need Class-Path entries in MANIFEST.MF. And
classes are loaded by EAR classloader.
b) Put jars in some common lib in ear. Say EAR/lib. Then in all
the web applications have Class-path entry in MANIFEST.MF to list the
jars in EAR/lib. Make sure all the classes in shared jars are
serializable.
Update MANIFEST.MF in launchpad.war to have same Class-Path entries.
Now whenever you access a session object by
request.getSession().getAttribute(), the object will be serialized,
and then deserialized again. While deserialzing, it will resolve class
by Launchpad's classloader.
I will prefer APP-INF/lib approach to MANIFEST.MF, as the later
is adding unnecessary overhead of serialization and deserialization
for session sharing within same JVM. I am not sure why people have
used that approach.
In J2EE 5, there is addition of library element in
application.xml in EAR, which allows you to define EAR level library.
That is much cleaner than above two approaches.
Hope it helps.
Thanks,
Unmesh
Thanks,
Unmesh
On Fri, Mar 4, 2011 at 5:07 PM, 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
>
>
>
>
>
