You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Unmesh Joshi <un...@gmail.com> on 2011/03/02 23:10:20 UTC
sharing http session between sling servlets and other web
applications in an EAR
Hi,
In our current project, we have a mix of sling servlets (as part of
CQ) and an old spring mvc application. The migration is planned to
move completely to sling/CQ. But till the complete migration happens,
these two need to coexist in the same web container (weblogic in this
case).
We have a successful POC working where JSPs, which are CQ components,
can access session objects set by other web applications. (Made
possible by session sharing facility in weblogic). For refering to the
Java classes in JSP, they need to be packaged and exported as an OSGI
bundle.
I am trying to understand how http session handling happens in OSGI
container (felix) and other web applications in same web container.
Because, if I try to use the same class in sling servlet (which is
packaged as OSGI bundle), I get ClassCastException (as expected).
Are there any pointers which explain how class loading works in HTTP
service in Felix?
Thanks,
Unmesh
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Sarwar Bhuiyan <sa...@gmail.com>.
The JSPs are running in sling. In order to share the session we installed
crx-launchpad and the other webapp in the same EAR with session sharing
enabled in the weblogic-applicaiton.xml
Sarwar
On Thu, Mar 3, 2011 at 10:01 AM, Felix Meschberger <fm...@adobe.com>wrote:
> Hi,
>
> Am Donnerstag, den 03.03.2011, 08:29 +0000 schrieb Sarwar Bhuiyan:
> > Hi felix, how does it work in the sling jsps then? Grabbing the object
> > from the session and casting it works in the JSP but not in a sling
> > servlet. (This is with us using the embedded dependencies bundle with
> > the same jar in the ear classpath.) What makes it work in the JSP?
>
> What JSPs does it work in ? JSPs runing inside Sling or JSPs running in
> the other web application ?
>
> If it for JSPs in other Web Applications, it is such that the other web
> application just sees the ear classpath provided classes while in the
> OSGi framework this is not automatically the case ...
>
> Regards
> Felix
>
> > Sarwar
> >
> > On Thursday, March 3, 2011, Felix Meschberger <fm...@adobe.com>
> wrote:
> > > Hi,
> > >
> > > Am Mittwoch, den 02.03.2011, 23:02 +0000 schrieb Sarwar Bhuiyan:
> > >> Ah, so it is not enough to have a bundle with embedded libs( the
> > >> dependencies) and in another jar weblogicwith the same dependencies or
> the
> > >> EAR's classpath?
> > >
> > > No, this is the Java classloading 101. An object has a reference to is
> > > Class object (see Object.getClass()). For two parts of Java to access
> > > the same object the have to have visibility to the same Class object.
> > >
> > > Both parts need to have access to the same class objects thus the
> > > requirement of loading the classes from a shared class loader.
> > >
> > > It is not enough for them to see the same class bytes.
> > >
> > > Regards
> > > Felix
> > >
> > >>
> > >> Sarwar
> > >>
> > >> On Wed, Mar 2, 2011 at 10:51 PM, Felix Meschberger <
> fmeschbe@adobe.com>wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > In CQ/Sling we use HttpSession objects created by the servlet
> container
> > >> > used. In your case this would be the weblogic server.
> > >> >
> > >> > The problem with the objects in the session is that the same classes
> > >> > (class objects) must be used in the OSGi framework as well as in the
> > >> > other parts of the EAR.
> > >> >
> > >> > So the classes must be loaded from a shared class loader. To do this
> in
> > >> > the OSGi framework you will want to use a feature call system
> package
> > >> > exports.
> > >> >
> > >> > The easiest way to get this done is creating a framework extension
> > >> > fragment which attaches to the system bundle and enhances the
> exports of
> > >> > that system bundle.
> > >> >
> > >> > Refer to [1] for how this could be done.
> > >> >
> > >> > Regards
> > >> > Felix
> > >> >
> > >> > [1]
> > >> >
> http://blog.meschberger.ch/2008/10/osgi-framework-extension-as-maven.html
> > >> >
> > >> > Am Mittwoch, den 02.03.2011, 22:10 +0000 schrieb Unmesh Joshi:
> > >> > > Hi,
> > >> > >
> > >> > > In our current project, we have a mix of sling servlets (as part
> of
> > >> > > CQ) and an old spring mvc application. The migration is planned to
> > >> > > move completely to sling/CQ. But till the complete migration
> happens,
> > >> > > these two need to coexist in the same web container (weblogic in
> this
> > >> > > case).
> > >> > > We have a successful POC working where JSPs, which are CQ
> components,
> > >> > > can access session objects set by other web applications. (Made
> > >> > > possible by session sharing facility in weblogic). For refering to
> the
> > >> > > Java classes in JSP, they need to be packaged and exported as an
> OSGI
> > >> > > bundle.
> > >> > > I am trying to understand how http session handling happens in
> OSGI
> > >> > > container (felix) and other web applications in same web
> container.
> > >> > > Because, if I try to use the same class in sling servlet (which is
> > >> > > packaged as OSGI bundle), I get ClassCastException (as expected).
> > >> > >
> > >> > > Are there any pointers which explain how class loading works in
> HTTP
> > >> > > service in Felix?
> > >> > >
> > >> > > Thanks,
> > >> > > Unmesh
> > >> >
> > >> >
> > >> >
> > >
> > >
> > >
>
>
>
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am Donnerstag, den 03.03.2011, 08:29 +0000 schrieb Sarwar Bhuiyan:
> Hi felix, how does it work in the sling jsps then? Grabbing the object
> from the session and casting it works in the JSP but not in a sling
> servlet. (This is with us using the embedded dependencies bundle with
> the same jar in the ear classpath.) What makes it work in the JSP?
What JSPs does it work in ? JSPs runing inside Sling or JSPs running in
the other web application ?
If it for JSPs in other Web Applications, it is such that the other web
application just sees the ear classpath provided classes while in the
OSGi framework this is not automatically the case ...
Regards
Felix
> Sarwar
>
> On Thursday, March 3, 2011, Felix Meschberger <fm...@adobe.com> wrote:
> > Hi,
> >
> > Am Mittwoch, den 02.03.2011, 23:02 +0000 schrieb Sarwar Bhuiyan:
> >> Ah, so it is not enough to have a bundle with embedded libs( the
> >> dependencies) and in another jar weblogicwith the same dependencies or the
> >> EAR's classpath?
> >
> > No, this is the Java classloading 101. An object has a reference to is
> > Class object (see Object.getClass()). For two parts of Java to access
> > the same object the have to have visibility to the same Class object.
> >
> > Both parts need to have access to the same class objects thus the
> > requirement of loading the classes from a shared class loader.
> >
> > It is not enough for them to see the same class bytes.
> >
> > Regards
> > Felix
> >
> >>
> >> Sarwar
> >>
> >> On Wed, Mar 2, 2011 at 10:51 PM, Felix Meschberger <fm...@adobe.com>wrote:
> >>
> >> > Hi,
> >> >
> >> > In CQ/Sling we use HttpSession objects created by the servlet container
> >> > used. In your case this would be the weblogic server.
> >> >
> >> > The problem with the objects in the session is that the same classes
> >> > (class objects) must be used in the OSGi framework as well as in the
> >> > other parts of the EAR.
> >> >
> >> > So the classes must be loaded from a shared class loader. To do this in
> >> > the OSGi framework you will want to use a feature call system package
> >> > exports.
> >> >
> >> > The easiest way to get this done is creating a framework extension
> >> > fragment which attaches to the system bundle and enhances the exports of
> >> > that system bundle.
> >> >
> >> > Refer to [1] for how this could be done.
> >> >
> >> > Regards
> >> > Felix
> >> >
> >> > [1]
> >> > http://blog.meschberger.ch/2008/10/osgi-framework-extension-as-maven.html
> >> >
> >> > Am Mittwoch, den 02.03.2011, 22:10 +0000 schrieb Unmesh Joshi:
> >> > > Hi,
> >> > >
> >> > > In our current project, we have a mix of sling servlets (as part of
> >> > > CQ) and an old spring mvc application. The migration is planned to
> >> > > move completely to sling/CQ. But till the complete migration happens,
> >> > > these two need to coexist in the same web container (weblogic in this
> >> > > case).
> >> > > We have a successful POC working where JSPs, which are CQ components,
> >> > > can access session objects set by other web applications. (Made
> >> > > possible by session sharing facility in weblogic). For refering to the
> >> > > Java classes in JSP, they need to be packaged and exported as an OSGI
> >> > > bundle.
> >> > > I am trying to understand how http session handling happens in OSGI
> >> > > container (felix) and other web applications in same web container.
> >> > > Because, if I try to use the same class in sling servlet (which is
> >> > > packaged as OSGI bundle), I get ClassCastException (as expected).
> >> > >
> >> > > Are there any pointers which explain how class loading works in HTTP
> >> > > service in Felix?
> >> > >
> >> > > Thanks,
> >> > > Unmesh
> >> >
> >> >
> >> >
> >
> >
> >
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Sarwar Bhuiyan <sa...@gmail.com>.
Hi felix, how does it work in the sling jsps then? Grabbing the object
from the session and casting it works in the JSP but not in a sling
servlet. (This is with us using the embedded dependencies bundle with
the same jar in the ear classpath.) What makes it work in the JSP?
Sarwar
On Thursday, March 3, 2011, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> Am Mittwoch, den 02.03.2011, 23:02 +0000 schrieb Sarwar Bhuiyan:
>> Ah, so it is not enough to have a bundle with embedded libs( the
>> dependencies) and in another jar weblogicwith the same dependencies or the
>> EAR's classpath?
>
> No, this is the Java classloading 101. An object has a reference to is
> Class object (see Object.getClass()). For two parts of Java to access
> the same object the have to have visibility to the same Class object.
>
> Both parts need to have access to the same class objects thus the
> requirement of loading the classes from a shared class loader.
>
> It is not enough for them to see the same class bytes.
>
> Regards
> Felix
>
>>
>> Sarwar
>>
>> On Wed, Mar 2, 2011 at 10:51 PM, Felix Meschberger <fm...@adobe.com>wrote:
>>
>> > Hi,
>> >
>> > In CQ/Sling we use HttpSession objects created by the servlet container
>> > used. In your case this would be the weblogic server.
>> >
>> > The problem with the objects in the session is that the same classes
>> > (class objects) must be used in the OSGi framework as well as in the
>> > other parts of the EAR.
>> >
>> > So the classes must be loaded from a shared class loader. To do this in
>> > the OSGi framework you will want to use a feature call system package
>> > exports.
>> >
>> > The easiest way to get this done is creating a framework extension
>> > fragment which attaches to the system bundle and enhances the exports of
>> > that system bundle.
>> >
>> > Refer to [1] for how this could be done.
>> >
>> > Regards
>> > Felix
>> >
>> > [1]
>> > http://blog.meschberger.ch/2008/10/osgi-framework-extension-as-maven.html
>> >
>> > Am Mittwoch, den 02.03.2011, 22:10 +0000 schrieb Unmesh Joshi:
>> > > Hi,
>> > >
>> > > In our current project, we have a mix of sling servlets (as part of
>> > > CQ) and an old spring mvc application. The migration is planned to
>> > > move completely to sling/CQ. But till the complete migration happens,
>> > > these two need to coexist in the same web container (weblogic in this
>> > > case).
>> > > We have a successful POC working where JSPs, which are CQ components,
>> > > can access session objects set by other web applications. (Made
>> > > possible by session sharing facility in weblogic). For refering to the
>> > > Java classes in JSP, they need to be packaged and exported as an OSGI
>> > > bundle.
>> > > I am trying to understand how http session handling happens in OSGI
>> > > container (felix) and other web applications in same web container.
>> > > Because, if I try to use the same class in sling servlet (which is
>> > > packaged as OSGI bundle), I get ClassCastException (as expected).
>> > >
>> > > Are there any pointers which explain how class loading works in HTTP
>> > > service in Felix?
>> > >
>> > > Thanks,
>> > > Unmesh
>> >
>> >
>> >
>
>
>
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Sarwar Bhuiyan <sa...@gmail.com>.
Hi felix, how does it work in the sling jsps then? Grabbing the object
from the session and casting it works in the JSP but not in a sling
servlet. (This is with us using the embedded dependencies bundle with
the same jar in the ear classpath.) What makes it work in the JSP?
Sarwar
On Thursday, March 3, 2011, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> Am Mittwoch, den 02.03.2011, 23:02 +0000 schrieb Sarwar Bhuiyan:
>> Ah, so it is not enough to have a bundle with embedded libs( the
>> dependencies) and in another jar weblogicwith the same dependencies or the
>> EAR's classpath?
>
> No, this is the Java classloading 101. An object has a reference to is
> Class object (see Object.getClass()). For two parts of Java to access
> the same object the have to have visibility to the same Class object.
>
> Both parts need to have access to the same class objects thus the
> requirement of loading the classes from a shared class loader.
>
> It is not enough for them to see the same class bytes.
>
> Regards
> Felix
>
>>
>> Sarwar
>>
>> On Wed, Mar 2, 2011 at 10:51 PM, Felix Meschberger <fm...@adobe.com>wrote:
>>
>> > Hi,
>> >
>> > In CQ/Sling we use HttpSession objects created by the servlet container
>> > used. In your case this would be the weblogic server.
>> >
>> > The problem with the objects in the session is that the same classes
>> > (class objects) must be used in the OSGi framework as well as in the
>> > other parts of the EAR.
>> >
>> > So the classes must be loaded from a shared class loader. To do this in
>> > the OSGi framework you will want to use a feature call system package
>> > exports.
>> >
>> > The easiest way to get this done is creating a framework extension
>> > fragment which attaches to the system bundle and enhances the exports of
>> > that system bundle.
>> >
>> > Refer to [1] for how this could be done.
>> >
>> > Regards
>> > Felix
>> >
>> > [1]
>> > http://blog.meschberger.ch/2008/10/osgi-framework-extension-as-maven.html
>> >
>> > Am Mittwoch, den 02.03.2011, 22:10 +0000 schrieb Unmesh Joshi:
>> > > Hi,
>> > >
>> > > In our current project, we have a mix of sling servlets (as part of
>> > > CQ) and an old spring mvc application. The migration is planned to
>> > > move completely to sling/CQ. But till the complete migration happens,
>> > > these two need to coexist in the same web container (weblogic in this
>> > > case).
>> > > We have a successful POC working where JSPs, which are CQ components,
>> > > can access session objects set by other web applications. (Made
>> > > possible by session sharing facility in weblogic). For refering to the
>> > > Java classes in JSP, they need to be packaged and exported as an OSGI
>> > > bundle.
>> > > I am trying to understand how http session handling happens in OSGI
>> > > container (felix) and other web applications in same web container.
>> > > Because, if I try to use the same class in sling servlet (which is
>> > > packaged as OSGI bundle), I get ClassCastException (as expected).
>> > >
>> > > Are there any pointers which explain how class loading works in HTTP
>> > > service in Felix?
>> > >
>> > > Thanks,
>> > > Unmesh
>> >
>> >
>> >
>
>
>
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am Mittwoch, den 02.03.2011, 23:02 +0000 schrieb Sarwar Bhuiyan:
> Ah, so it is not enough to have a bundle with embedded libs( the
> dependencies) and in another jar weblogicwith the same dependencies or the
> EAR's classpath?
No, this is the Java classloading 101. An object has a reference to is
Class object (see Object.getClass()). For two parts of Java to access
the same object the have to have visibility to the same Class object.
Both parts need to have access to the same class objects thus the
requirement of loading the classes from a shared class loader.
It is not enough for them to see the same class bytes.
Regards
Felix
>
> Sarwar
>
> On Wed, Mar 2, 2011 at 10:51 PM, Felix Meschberger <fm...@adobe.com>wrote:
>
> > Hi,
> >
> > In CQ/Sling we use HttpSession objects created by the servlet container
> > used. In your case this would be the weblogic server.
> >
> > The problem with the objects in the session is that the same classes
> > (class objects) must be used in the OSGi framework as well as in the
> > other parts of the EAR.
> >
> > So the classes must be loaded from a shared class loader. To do this in
> > the OSGi framework you will want to use a feature call system package
> > exports.
> >
> > The easiest way to get this done is creating a framework extension
> > fragment which attaches to the system bundle and enhances the exports of
> > that system bundle.
> >
> > Refer to [1] for how this could be done.
> >
> > Regards
> > Felix
> >
> > [1]
> > http://blog.meschberger.ch/2008/10/osgi-framework-extension-as-maven.html
> >
> > Am Mittwoch, den 02.03.2011, 22:10 +0000 schrieb Unmesh Joshi:
> > > Hi,
> > >
> > > In our current project, we have a mix of sling servlets (as part of
> > > CQ) and an old spring mvc application. The migration is planned to
> > > move completely to sling/CQ. But till the complete migration happens,
> > > these two need to coexist in the same web container (weblogic in this
> > > case).
> > > We have a successful POC working where JSPs, which are CQ components,
> > > can access session objects set by other web applications. (Made
> > > possible by session sharing facility in weblogic). For refering to the
> > > Java classes in JSP, they need to be packaged and exported as an OSGI
> > > bundle.
> > > I am trying to understand how http session handling happens in OSGI
> > > container (felix) and other web applications in same web container.
> > > Because, if I try to use the same class in sling servlet (which is
> > > packaged as OSGI bundle), I get ClassCastException (as expected).
> > >
> > > Are there any pointers which explain how class loading works in HTTP
> > > service in Felix?
> > >
> > > Thanks,
> > > Unmesh
> >
> >
> >
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Sarwar Bhuiyan <sa...@gmail.com>.
Ah, so it is not enough to have a bundle with embedded libs( the
dependencies) and in another jar weblogicwith the same dependencies or the
EAR's classpath?
Sarwar
On Wed, Mar 2, 2011 at 10:51 PM, Felix Meschberger <fm...@adobe.com>wrote:
> Hi,
>
> In CQ/Sling we use HttpSession objects created by the servlet container
> used. In your case this would be the weblogic server.
>
> The problem with the objects in the session is that the same classes
> (class objects) must be used in the OSGi framework as well as in the
> other parts of the EAR.
>
> So the classes must be loaded from a shared class loader. To do this in
> the OSGi framework you will want to use a feature call system package
> exports.
>
> The easiest way to get this done is creating a framework extension
> fragment which attaches to the system bundle and enhances the exports of
> that system bundle.
>
> Refer to [1] for how this could be done.
>
> Regards
> Felix
>
> [1]
> http://blog.meschberger.ch/2008/10/osgi-framework-extension-as-maven.html
>
> Am Mittwoch, den 02.03.2011, 22:10 +0000 schrieb Unmesh Joshi:
> > Hi,
> >
> > In our current project, we have a mix of sling servlets (as part of
> > CQ) and an old spring mvc application. The migration is planned to
> > move completely to sling/CQ. But till the complete migration happens,
> > these two need to coexist in the same web container (weblogic in this
> > case).
> > We have a successful POC working where JSPs, which are CQ components,
> > can access session objects set by other web applications. (Made
> > possible by session sharing facility in weblogic). For refering to the
> > Java classes in JSP, they need to be packaged and exported as an OSGI
> > bundle.
> > I am trying to understand how http session handling happens in OSGI
> > container (felix) and other web applications in same web container.
> > Because, if I try to use the same class in sling servlet (which is
> > packaged as OSGI bundle), I get ClassCastException (as expected).
> >
> > Are there any pointers which explain how class loading works in HTTP
> > service in Felix?
> >
> > Thanks,
> > Unmesh
>
>
>
Re: Modifying Apache Sling JCR Resource Resolver
Posted by Sarwar Bhuiyan <sa...@gmail.com>.
I believe the resource resolver settings are loaded from the repository on
startup. Go to
/libs/sling/config/org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl<http://localhost:4502/crx/repository/crx.default/libs/sling/config/org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl>to
see the properties
I'm not sure how you can use curl POST to change the
resource.resolver.mapping property as it is a String[] but I believe it can
be done.
Sarwar
On Fri, Mar 11, 2011 at 10:49 PM, Shay Thompson <st...@adobe.com> wrote:
>
> I need to add an extra URL Mapping to the Resource Resolver in a way that
> doesn't require the felix console. I was hoping to POST a .cfg file but
> I've been unable to get that to work. Could anyone recommend a different
> route I could use?
>
> Thanks,
> Shay
>
Modifying Apache Sling JCR Resource Resolver
Posted by Shay Thompson <st...@adobe.com>.
I need to add an extra URL Mapping to the Resource Resolver in a way that doesn't require the felix console. I was hoping to POST a .cfg file but I've been unable to get that to work. Could anyone recommend a different route I could use?
Thanks,
Shay
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Davide Giannella <dg...@adobe.com>.
On 11/03/2011 19:47, "Sarwar Bhuiyan" <sa...@gmail.com> wrote:
>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.
We found the solution (or almost). It was the <@page session="false"
within the CQ's global.jsp.
Removing the session=false makes jstl sessionScope works fine. Don't know
exactly why with that header request.getSession().getAttribute works,
while jstl's sessionScope not.
Davide
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Sarwar Bhuiyan <sa...@gmail.com>.
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 <fm...@adobe.com>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 <sa...@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
> > > <ak...@adobe.com>wrote:
> > >
> > >> On 03.03.11 19:47, "Unmesh Joshi" <un...@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
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
>
>
>
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Unmesh Joshi <un...@gmail.com>.
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 <un...@gmail.com> wrote:
>> Hi Felix,
>>
>> I will surely add it to FAQ.
>>
>> Thanks,
>> Unmesh
>>
>> On Fri, Mar 11, 2011 at 6:20 PM, Felix Meschberger <fm...@adobe.com> 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 <sa...@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
>>>> > <ak...@adobe.com>wrote:
>>>> >
>>>> >> On 03.03.11 19:47, "Unmesh Joshi" <un...@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
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>
>>>
>>>
>>
>
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Unmesh Joshi <un...@gmail.com>.
Hi Felix,
I will surely add it to FAQ.
Thanks,
Unmesh
On Fri, Mar 11, 2011 at 6:20 PM, Felix Meschberger <fm...@adobe.com> 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 <sa...@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
>> > <ak...@adobe.com>wrote:
>> >
>> >> On 03.03.11 19:47, "Unmesh Joshi" <un...@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
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>
>
>
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Felix Meschberger <fm...@adobe.com>.
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 <sa...@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
> > <ak...@adobe.com>wrote:
> >
> >> On 03.03.11 19:47, "Unmesh Joshi" <un...@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
> >>
> >>
> >>
> >>
> >>
> >
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Unmesh Joshi <un...@gmail.com>.
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 <sa...@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
> <ak...@adobe.com>wrote:
>
>> On 03.03.11 19:47, "Unmesh Joshi" <un...@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
>>
>>
>>
>>
>>
>
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Sarwar Bhuiyan <sa...@gmail.com>.
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
<ak...@adobe.com>wrote:
> On 03.03.11 19:47, "Unmesh Joshi" <un...@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
>
>
>
>
>
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Unmesh Joshi <un...@gmail.com>.
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
<ak...@adobe.com> wrote:
> On 03.03.11 19:47, "Unmesh Joshi" <un...@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
>
>
>
>
>
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 03.03.11 19:47, "Unmesh Joshi" <un...@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
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Unmesh Joshi <un...@gmail.com>.
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.
On Thu, Mar 3, 2011 at 11:01 PM, Alexander Klimetschek
<ak...@adobe.com> wrote:
> On 03.03.11 14:44, "Unmesh Joshi" <un...@gmail.com> wrote:
>>When JSP running inside sling is trying to get session objects, it is
>>ALWAYS getting deserialized by weblogic. See the following stack
>>trace. This does not happen when Sling servlet is trying to get
>>session data. Is something special happens when JSP is processed by
>>sling?
>>
>>at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:546)
>> at
>>java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
>> at
>>java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
>> at
>>java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
>> at
>>weblogic.common.internal.PassivationUtils.toObject(PassivationUtils.java:5
>>4)
>> at
>>weblogic.common.internal.PassivationUtils.toObject(PassivationUtils.java:4
>>6)
>> at
>>weblogic.common.internal.PassivationUtils.copy(PassivationUtils.java:64)
>> at
>>weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java
>>:100)
>> at
>>weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java
>>:44)
>> at
>>weblogic.servlet.internal.session.SessionData.getAttribute(SessionData.jav
>>a:395)
>> at
>>weblogic.servlet.internal.session.SharedSessionData.getAttribute(SharedSes
>>sionData.java:59)
>> at
>>org.apache.jsp.apps.myapp.components.Login.Login_jsp._jspService(Login_jsp
>>.java:145)
>
> Well, not sure from the stacktrace if there is an actual deserialization
> going on. Weblogic could also just "try" to read from some cache.
>
> Maybe you could disable that serialization in Weblogic - I don't really
> see the reason why you want that overhead between two webapps on the same
> web application server. (Except persisting the sessions on disk is
> important)
>
> In any case, this is all happening inside Weblogic, not Sling. The JSP
> just calls session.getAttribute() here.
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> Developer // Adobe (Day) // Berlin - Basel
>
>
>
>
>
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 03.03.11 14:44, "Unmesh Joshi" <un...@gmail.com> wrote:
>When JSP running inside sling is trying to get session objects, it is
>ALWAYS getting deserialized by weblogic. See the following stack
>trace. This does not happen when Sling servlet is trying to get
>session data. Is something special happens when JSP is processed by
>sling?
>
>at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:546)
> at
>java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
> at
>java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
> at
>java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
> at
>weblogic.common.internal.PassivationUtils.toObject(PassivationUtils.java:5
>4)
> at
>weblogic.common.internal.PassivationUtils.toObject(PassivationUtils.java:4
>6)
> at
>weblogic.common.internal.PassivationUtils.copy(PassivationUtils.java:64)
> at
>weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java
>:100)
> at
>weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java
>:44)
> at
>weblogic.servlet.internal.session.SessionData.getAttribute(SessionData.jav
>a:395)
> at
>weblogic.servlet.internal.session.SharedSessionData.getAttribute(SharedSes
>sionData.java:59)
> at
>org.apache.jsp.apps.myapp.components.Login.Login_jsp._jspService(Login_jsp
>.java:145)
Well, not sure from the stacktrace if there is an actual deserialization
going on. Weblogic could also just "try" to read from some cache.
Maybe you could disable that serialization in Weblogic - I don't really
see the reason why you want that overhead between two webapps on the same
web application server. (Except persisting the sessions on disk is
important)
In any case, this is all happening inside Weblogic, not Sling. The JSP
just calls session.getAttribute() here.
Regards,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Unmesh Joshi <un...@gmail.com>.
On Thu, Mar 3, 2011 at 10:27 AM, Alexander Klimetschek
<ak...@adobe.com> wrote:
> On 03.03.11 07:01, "Unmesh Joshi" <un...@gmail.com> wrote:
> If these are JSPs running inside Sling, I would guess: it might be that
> the classloader used by the JSP scripting engine actually directly uses
> the shared classloader from the servlet container, without the need for
> the special framework extension fragment in the OSGi container. But not
> sure.
When JSP running inside sling is trying to get session objects, it is
ALWAYS getting deserialized by weblogic. See the following stack
trace. This does not happen when Sling servlet is trying to get
session data. Is something special happens when JSP is processed by
sling?
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:546)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at weblogic.common.internal.PassivationUtils.toObject(PassivationUtils.java:54)
at weblogic.common.internal.PassivationUtils.toObject(PassivationUtils.java:46)
at weblogic.common.internal.PassivationUtils.copy(PassivationUtils.java:64)
at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java:100)
at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java:44)
at weblogic.servlet.internal.session.SessionData.getAttribute(SessionData.java:395)
at weblogic.servlet.internal.session.SharedSessionData.getAttribute(SharedSessionData.java:59)
at org.apache.jsp.apps.myapp.components.Login.Login_jsp._jspService(Login_jsp.java:145)
at org.apache.sling.scripting.jsp.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:394)
at org.apache.sling.scripting.jsp.JspServletWrapperAdapter.service(JspServletWrapperAdapter.java:59)
at org.apache.sling.scripting.jsp.JspScriptEngineFactory.callJsp(JspScriptEngineFactory.java:142)
at org.apache.sling.scripting.jsp.JspScriptEngineFactory.access$100(JspScriptEngineFactory.java:73)
at org.apache.sling.scripting.jsp.JspScriptEngineFactory$JspScriptEngine.eval(JspScriptEngineFactory.java:344)
at org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:224)
at org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:161)
at org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:320)
at org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:525)
at org.apache.sling.engine.impl.filter.SlingComponentFilterChain.render(SlingComponentFilterChain.java:45)
at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:64)
at com.day.cq.wcm.core.impl.WCMDebugFilter.doFilterWithErrorHandling(WCMDebugFilter.java:183)
at com.day.cq.wcm.core.impl.WCMDebugFilter.doFilter(WCMDebugFilter.java:150)
at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
at com.day.cq.wcm.core.impl.WCMRequestFilter.doFilter(WCMRequestFilter.java:239)
at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
at org.apache.sling.engine.impl.SlingMainServlet.processRequest(SlingMainServlet.java:427)
at org.apache.sling.engine.impl.SlingMainServlet.includeContent(SlingMainServlet.java:408)
at org.apache.sling.engine.impl.request.SlingRequestDispatcher.dispatch(SlingRequestDispatcher.java:175)
at org.apache.sling.engine.impl.request.SlingRequestDispatcher.include(SlingRequestDispatcher.java:69)
at com.day.cq.wcm.core.impl.WCMRequestFilter$ForwardRequestDispatcher.include(WCMRequestFilter.java:457)
at org.apache.sling.scripting.jsp.taglib.IncludeTagHandler.dispatch(IncludeTagHandler.java:47)
at org.apache.sling.scripting.jsp.taglib.AbstractDispatcherTagHandler.doEndTag(AbstractDispatcherTagHandler.java:129)
at org.apache.jsp.libs.foundation.components.parsys.parsys_jsp._jspService(parsys_jsp.java:308)
at org.apache.sling.scripting.jsp.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:394)
at org.apache.sling.scripting.jsp.JspServletWrapperAdapter.service(JspServletWrapperAdapter.java:59)
at org.apache.sling.scripting.jsp.JspScriptEngineFactory.callJsp(JspScriptEngineFactory.java:142)
at org.apache.sling.scripting.jsp.JspScriptEngineFactory.access$100(JspScriptEngineFactory.java:73)
at org.apache.sling.scripting.jsp.JspScriptEngineFactory$JspScriptEngine.eval(JspScriptEngineFactory.java:344)
at org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:224)
at org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:161)
at org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:320)
at org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:525)
at org.apache.sling.engine.impl.filter.SlingComponentFilterChain.render(SlingComponentFilterChain.java:45)
at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:64)
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 03.03.11 07:01, "Unmesh Joshi" <un...@gmail.com> wrote:
>1. Why would the classes be resolved in JSP components when exported
>from a OSGI bundle which includes all the shared jars.
> Here they are not getting loaded by shared ear class loader.
If these are JSPs running inside Sling, I would guess: it might be that
the classloader used by the JSP scripting engine actually directly uses
the shared classloader from the servlet container, without the need for
the special framework extension fragment in the OSGi container. But not
sure.
> Some colleagues told me that session objects are actually getting
>serialized and then deserialized in OSGI container, so the behaviour
>is similar to how remote calls work with serialization.
No, there is no serialization going on. AFAIK this only happens in servlet
containers that cache sessions on disk and/or move the session across
instances and hence need to serialize/deserialize them.
This statefulness (and complexity) you get here from using http sessions
is the central point why they are considered a bad idea (tm). OSGi itself
doesn't do anything here (since it is about classloading and a general
framework) and Sling also doesn't do anything with HttpSessions, so they
use them as they are provided by the underlying servlet container.
>2. How does OSGI framework know about Ear classloader as its parent
>classloader (and not go to Java system classloader)?
> In the OSGI bundles, if I try to get parent classloader by calling
>getClassLoader().getParent(), I get null, which I suppose means
>bootstrap classloader.
I think the OSGi class loader prevents you from going to the parent class
loader, in order to make sure its class loading mechanism is not
mitigated. Internally it still has access to the parent class loader that
it gets from the servlet container (if the OSGi framework is running
inside a webapp, as it is the case with Sling), but here you need the
framework extension fragment being present so that OSGi can properly pass
those classes "through" (again, not 100% sure, Felix probably knows it
much better than me).
Regards,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Unmesh Joshi <un...@gmail.com>.
Two questions..
1. Why would the classes be resolved in JSP components when exported
from a OSGI bundle which includes all the shared jars.
Here they are not getting loaded by shared ear class loader.
Some colleagues told me that session objects are actually getting
serialized and then deserialized in OSGI container, so the behaviour
is similar to how remote calls work with serialization.
2. How does OSGI framework know about Ear classloader as its parent
classloader (and not go to Java system classloader)?
In the OSGI bundles, if I try to get parent classloader by calling
getClassLoader().getParent(), I get null, which I suppose means
bootstrap classloader.
Thanks,
Unmesh
On Thu, Mar 3, 2011 at 4:21 AM, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> In CQ/Sling we use HttpSession objects created by the servlet container
> used. In your case this would be the weblogic server.
>
> The problem with the objects in the session is that the same classes
> (class objects) must be used in the OSGi framework as well as in the
> other parts of the EAR.
>
> So the classes must be loaded from a shared class loader. To do this in
> the OSGi framework you will want to use a feature call system package
> exports.
>
> The easiest way to get this done is creating a framework extension
> fragment which attaches to the system bundle and enhances the exports of
> that system bundle.
>
> Refer to [1] for how this could be done.
>
> Regards
> Felix
>
> [1]http://blog.meschberger.ch/2008/10/osgi-framework-extension-as-maven.html
>
> Am Mittwoch, den 02.03.2011, 22:10 +0000 schrieb Unmesh Joshi:
>> Hi,
>>
>> In our current project, we have a mix of sling servlets (as part of
>> CQ) and an old spring mvc application. The migration is planned to
>> move completely to sling/CQ. But till the complete migration happens,
>> these two need to coexist in the same web container (weblogic in this
>> case).
>> We have a successful POC working where JSPs, which are CQ components,
>> can access session objects set by other web applications. (Made
>> possible by session sharing facility in weblogic). For refering to the
>> Java classes in JSP, they need to be packaged and exported as an OSGI
>> bundle.
>> I am trying to understand how http session handling happens in OSGI
>> container (felix) and other web applications in same web container.
>> Because, if I try to use the same class in sling servlet (which is
>> packaged as OSGI bundle), I get ClassCastException (as expected).
>>
>> Are there any pointers which explain how class loading works in HTTP
>> service in Felix?
>>
>> Thanks,
>> Unmesh
>
>
>
Re: sharing http session between sling servlets and other web
applications in an EAR
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
In CQ/Sling we use HttpSession objects created by the servlet container
used. In your case this would be the weblogic server.
The problem with the objects in the session is that the same classes
(class objects) must be used in the OSGi framework as well as in the
other parts of the EAR.
So the classes must be loaded from a shared class loader. To do this in
the OSGi framework you will want to use a feature call system package
exports.
The easiest way to get this done is creating a framework extension
fragment which attaches to the system bundle and enhances the exports of
that system bundle.
Refer to [1] for how this could be done.
Regards
Felix
[1]http://blog.meschberger.ch/2008/10/osgi-framework-extension-as-maven.html
Am Mittwoch, den 02.03.2011, 22:10 +0000 schrieb Unmesh Joshi:
> Hi,
>
> In our current project, we have a mix of sling servlets (as part of
> CQ) and an old spring mvc application. The migration is planned to
> move completely to sling/CQ. But till the complete migration happens,
> these two need to coexist in the same web container (weblogic in this
> case).
> We have a successful POC working where JSPs, which are CQ components,
> can access session objects set by other web applications. (Made
> possible by session sharing facility in weblogic). For refering to the
> Java classes in JSP, they need to be packaged and exported as an OSGI
> bundle.
> I am trying to understand how http session handling happens in OSGI
> container (felix) and other web applications in same web container.
> Because, if I try to use the same class in sling servlet (which is
> packaged as OSGI bundle), I get ClassCastException (as expected).
>
> Are there any pointers which explain how class loading works in HTTP
> service in Felix?
>
> Thanks,
> Unmesh