You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "David H. DeWolf" <dd...@apache.org> on 2004/10/14 14:59:52 UTC
Application Scoped Session Attibutes Work (was: Re: FW: Cross Context
Sessions (was RE: Defining the release))
Remmy checked in a fix to the ant scripts last night and I was able to
build tomcat from source.
The patch that has been applied to tomcat DOES fix our problem with
Application Scoped session attributes.
Special thanks to Nick and the Tomcat team for working with each other
to come up with a creative solution.
** Remember that if you want this to work you MUST modify your
server.xml. Specifically, set the parameter "emptySessionPath"
to true in your connector config. An example is below:
<Connector port="8080" maxThreads="150" minSpareThreads="25"
maxSpareThreads="75" enableLookups="false"
redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"
emptySessionPath="true" />
David
David H. DeWolf wrote:
> Thanks for pursuing this Nick!
>
> I've taken a shot at trying it out but have been unsuccessfully in
> getting the latest version of Tomcat running.
>
> When building from source I am unable to complete the build because of
> an error when creating the jk connector (it can't find the coyote jar -
> it looks like an ant property isn't being set properly).
>
> When attempting to use last night's nightly build I am unable to startup
> the server because it can't find coyote.
>
> My guess is that there is a small ant tweak that needs to occur to get
> the current source building correctly. Unfortunately I don't have the
> cycles to look at it at the moment.
>
> I'm looking forward to hearing if anyone else has been able to get this
> tested. It looks like a good solution to me!
>
> David
>
> Nick Lothian wrote:
>
>> The Tomcat team have just committed a change
>> (<http://nagoya.apache.org/eyebrowse/ReadMsg?listName=tomcat-dev@jakarta.apa
>>
>> che.org&msgNo=80223>), which "Add the ability to force session cookies
>> to be
>> set to the root path "/"".
>>
>> Comments in the commit message suggest that "This will allow the use
>> case of
>> the Pluto folks, in a reliable way.".
>>
>> Is anyone in a position to test this change at the moment? I'm at work
>> and
>> so don't have immediate CVS access. I think it's currently only in the
>> Tomcat 5.5 stream.
>> In theory using the same cookie for all sessions should fix the problems
>> we've had.
>> (They didn't like the original patch because it wouldn't work if the
>> response had already been committed - amongst other things).
>>
>> Nick
>>
>>
>>> -----Original Message-----
>>> From: Nick Lothian [mailto:nick.lothian@essential.com.au]
>>> Sent: Tuesday, 12 October 2004 3:43 PM
>>> To: pluto-dev@portals.apache.org
>>> Subject: RE: FW: Cross Context Sessions (was RE: Defining the release)
>>> Importance: Low
>>>
>>>
>>>
>>>
>>>> In previous versions of tomcat it was possible to put an object into
>>>> the session in app1 and have it be available in app2. But I think
>>>> almost any reading of the above specification section, would
>>>> consider this behavior to be out of line with the spec.
>>>
>>>
>>> We are always talking about putting things into the session of app2.
>>> Sometime app2 is being invoked via a RequestDispatcher from app1,
>>> however.
>>>
>>> The requirement here is to be able to share data between a portlet
>>> (which is
>>> invoked via a RequestDispatcher) and a servlet inside the web app as the
>>> portlet (so the servlet and the portlet are inside the same context).
>>>
>>> I've just started a discussion on Tomcat-Dev of this issue (and that bug
>>> which you raised).
>>>
>>> Nick
>>>
>>
>>
>
>
Re: Application Scoped Session Attibutes Work
Posted by David Jencks <da...@yahoo.com>.
To amplify on David's response, the servlet spec requires that
different web apps have different sessions. You will not be able to
access the same session from servlets in different web apps in a
spec-compliant servlet container.
However, if the rather ill-specified cross context dispatch is working
properly, which IMO it is likely to be on any servlet container on
which pluto is certified, within each webapp, all requests within a
"client" session will get the same session. In other words, the cookie
or url session id info will get to each webapp somehow and the correct
session will be supplied for that webapp for that client visible
session id. Although I haven't looked at the tomcat issue in detail I
suspect it deals with this: it is not too easy to implement correctly.
thanks
david jencks
On Feb 4, 2005, at 6:03 PM, David H. DeWolf wrote:
> Glenn,
>
> I don't think this is the solution you are looking for. What the fix
> that you are referring to does is ensure that requests made directly
> to the *portlet's* context have access to the same session which
> requests targeted to the portlet *through the portal* do.
>
> Note that per the spec this session must be different from the session
> of the portal itself.
>
> In short, each client should access exactly one session per webapp -
> no matter if that webapp is accessed directly or through the portal
> (or another webapp).
>
> David
>
> Glenn R. Golden wrote:
>> Does anyone in the Pluto community understand the tomcat issue in the
>> below messages?
>> I thought this was designed to solve the problem that when a portlet
>> is running, the request first went into the Pluto webapp and then
>> was dispatched to the portlet's own (separate webapp). The http
>> session would then be a) by the Servlet Spec, and b) by Tomcat's
>> implementation... I'm not sure! Would it be the sessions from the
>> Pluto webapp? Would it be the sessions from the portlet's webapp?
>> The problem comes up when you have a servlet in the portlet's webapp,
>> and they need to share session information. The servlet's requests
>> come directly to the webapp, so the servlet has the webapp's
>> sessions. The portlet's requests come first through Pluto then are
>> dispatched to the servlet+portlet's webapp, so if there was trouble,
>> it would have to be that the portlet is getting Pluto's set of
>> sessions, not it's own.
>> Am I even close here?
>> So I thought the solution below was to, essentially, "share sessions"
>> among the many webapps that a Pluto / portlet environment has. I
>> just tested this with Tomcat 5.5.7, and it acts strangely. When
>> "emptySessionPath" is set, the JSESSIONID cookies are truly set to
>> the "/" path, rather than the webapp's path. But, when two
>> different webapps are worked with, they still get their own separate
>> sessions. So what happens is that the second one causes the same
>> root JSESSIONID cookie in the browser to get modified to the
>> second's session id... then when you return to the first it does NOT
>> see it's session value so creates yet another new session, and
>> updates the cookie... This does not seem at all what we want.
>> What *I* need is a way to share sessions among the webapps in a Pluto
>> like environment. I thought this looked promising, since we have
>> needs much like Pluto's.
>> Thanks for any information you can shed on this issue.
>> - Glenn
>> On Oct 14, 2004, at 8:59 AM, David H. DeWolf wrote:
>>> Remmy checked in a fix to the ant scripts last night and I was able
>>> to build tomcat from source.
>>>
>>> The patch that has been applied to tomcat DOES fix our problem with
>>> Application Scoped session attributes.
>>>
>>> Special thanks to Nick and the Tomcat team for working with each
>>> other to come up with a creative solution.
>>>
>>> ** Remember that if you want this to work you MUST modify your
>>> server.xml. Specifically, set the parameter "emptySessionPath"
>>> to true in your connector config. An example is below:
>>>
>>> <Connector port="8080" maxThreads="150" minSpareThreads="25"
>>> maxSpareThreads="75" enableLookups="false"
>>> redirectPort="8443" acceptCount="100"
>>> connectionTimeout="20000" disableUploadTimeout="true"
>>> emptySessionPath="true" />
>>>
>>> David
>>>
>>>
>>> David H. DeWolf wrote:
>>>
>>>> Thanks for pursuing this Nick!
>>>> I've taken a shot at trying it out but have been unsuccessfully in
>>>> getting the latest version of Tomcat running.
>>>> When building from source I am unable to complete the build because
>>>> of an error when creating the jk connector (it can't find the
>>>> coyote jar - it looks like an ant property isn't being set
>>>> properly).
>>>> When attempting to use last night's nightly build I am unable to
>>>> startup the server because it can't find coyote.
>>>> My guess is that there is a small ant tweak that needs to occur to
>>>> get the current source building correctly. Unfortunately I don't
>>>> have the cycles to look at it at the moment.
>>>> I'm looking forward to hearing if anyone else has been able to get
>>>> this tested. It looks like a good solution to me!
>>>> David
>>>> Nick Lothian wrote:
>>>>
>>>>> The Tomcat team have just committed a change
>>>>> (<http://nagoya.apache.org/eyebrowse/ReadMsg?listName=tomcat-
>>>>> dev@jakarta.apa
>>>>> che.org&msgNo=80223>), which "Add the ability to force session
>>>>> cookies to be
>>>>> set to the root path "/"".
>>>>>
>>>>> Comments in the commit message suggest that "This will allow the
>>>>> use case of
>>>>> the Pluto folks, in a reliable way.".
>>>>>
>>>>> Is anyone in a position to test this change at the moment? I'm at
>>>>> work and
>>>>> so don't have immediate CVS access. I think it's currently only in
>>>>> the
>>>>> Tomcat 5.5 stream.
>>>>> In theory using the same cookie for all sessions should fix the
>>>>> problems
>>>>> we've had.
>>>>> (They didn't like the original patch because it wouldn't work if
>>>>> the
>>>>> response had already been committed - amongst other things).
>>>>>
>>>>> Nick
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Nick Lothian [mailto:nick.lothian@essential.com.au]
>>>>>> Sent: Tuesday, 12 October 2004 3:43 PM
>>>>>> To: pluto-dev@portals.apache.org
>>>>>> Subject: RE: FW: Cross Context Sessions (was RE: Defining the
>>>>>> release)
>>>>>> Importance: Low
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> In previous versions of tomcat it was possible to put an object
>>>>>>> into the session in app1 and have it be available in app2. But
>>>>>>> I think almost any reading of the above specification section,
>>>>>>> would consider this behavior to be out of line with the spec.
>>>>>>
>>>>>>
>>>>>>
>>>>>> We are always talking about putting things into the session of
>>>>>> app2.
>>>>>> Sometime app2 is being invoked via a RequestDispatcher from app1,
>>>>>> however.
>>>>>>
>>>>>> The requirement here is to be able to share data between a
>>>>>> portlet (which is
>>>>>> invoked via a RequestDispatcher) and a servlet inside the web app
>>>>>> as the
>>>>>> portlet (so the servlet and the portlet are inside the same
>>>>>> context).
>>>>>>
>>>>>> I've just started a discussion on Tomcat-Dev of this issue (and
>>>>>> that bug
>>>>>> which you raised).
>>>>>>
>>>>>> Nick
>>>>>>
>>>>>
>>>>>
>>>
>
Re: Application Scoped Session Attibutes Work
Posted by "David H. DeWolf" <dd...@apache.org>.
Glenn,
I don't think this is the solution you are looking for. What the fix
that you are referring to does is ensure that requests made directly to
the *portlet's* context have access to the same session which requests
targeted to the portlet *through the portal* do.
Note that per the spec this session must be different from the session
of the portal itself.
In short, each client should access exactly one session per webapp - no
matter if that webapp is accessed directly or through the portal (or
another webapp).
David
Glenn R. Golden wrote:
> Does anyone in the Pluto community understand the tomcat issue in the
> below messages?
>
> I thought this was designed to solve the problem that when a portlet is
> running, the request first went into the Pluto webapp and then was
> dispatched to the portlet's own (separate webapp). The http session
> would then be a) by the Servlet Spec, and b) by Tomcat's
> implementation... I'm not sure! Would it be the sessions from the
> Pluto webapp? Would it be the sessions from the portlet's webapp?
>
> The problem comes up when you have a servlet in the portlet's webapp,
> and they need to share session information. The servlet's requests
> come directly to the webapp, so the servlet has the webapp's sessions.
> The portlet's requests come first through Pluto then are dispatched to
> the servlet+portlet's webapp, so if there was trouble, it would have to
> be that the portlet is getting Pluto's set of sessions, not it's own.
>
> Am I even close here?
>
> So I thought the solution below was to, essentially, "share sessions"
> among the many webapps that a Pluto / portlet environment has. I just
> tested this with Tomcat 5.5.7, and it acts strangely. When
> "emptySessionPath" is set, the JSESSIONID cookies are truly set to the
> "/" path, rather than the webapp's path. But, when two different
> webapps are worked with, they still get their own separate sessions.
> So what happens is that the second one causes the same root JSESSIONID
> cookie in the browser to get modified to the second's session id...
> then when you return to the first it does NOT see it's session value so
> creates yet another new session, and updates the cookie... This does
> not seem at all what we want.
>
> What *I* need is a way to share sessions among the webapps in a Pluto
> like environment. I thought this looked promising, since we have needs
> much like Pluto's.
>
> Thanks for any information you can shed on this issue.
>
> - Glenn
>
> On Oct 14, 2004, at 8:59 AM, David H. DeWolf wrote:
>
>> Remmy checked in a fix to the ant scripts last night and I was able
>> to build tomcat from source.
>>
>> The patch that has been applied to tomcat DOES fix our problem with
>> Application Scoped session attributes.
>>
>> Special thanks to Nick and the Tomcat team for working with each
>> other to come up with a creative solution.
>>
>> ** Remember that if you want this to work you MUST modify your
>> server.xml. Specifically, set the parameter "emptySessionPath"
>> to true in your connector config. An example is below:
>>
>> <Connector port="8080" maxThreads="150" minSpareThreads="25"
>> maxSpareThreads="75" enableLookups="false"
>> redirectPort="8443" acceptCount="100"
>> connectionTimeout="20000" disableUploadTimeout="true"
>> emptySessionPath="true" />
>>
>> David
>>
>>
>> David H. DeWolf wrote:
>>
>>> Thanks for pursuing this Nick!
>>> I've taken a shot at trying it out but have been unsuccessfully in
>>> getting the latest version of Tomcat running.
>>> When building from source I am unable to complete the build because
>>> of an error when creating the jk connector (it can't find the coyote
>>> jar - it looks like an ant property isn't being set properly).
>>> When attempting to use last night's nightly build I am unable to
>>> startup the server because it can't find coyote.
>>> My guess is that there is a small ant tweak that needs to occur to
>>> get the current source building correctly. Unfortunately I don't
>>> have the cycles to look at it at the moment.
>>> I'm looking forward to hearing if anyone else has been able to get
>>> this tested. It looks like a good solution to me!
>>> David
>>> Nick Lothian wrote:
>>>
>>>> The Tomcat team have just committed a change
>>>> (<http://nagoya.apache.org/eyebrowse/ReadMsg?listName=tomcat-
>>>> dev@jakarta.apa
>>>> che.org&msgNo=80223>), which "Add the ability to force session
>>>> cookies to be
>>>> set to the root path "/"".
>>>>
>>>> Comments in the commit message suggest that "This will allow the
>>>> use case of
>>>> the Pluto folks, in a reliable way.".
>>>>
>>>> Is anyone in a position to test this change at the moment? I'm at
>>>> work and
>>>> so don't have immediate CVS access. I think it's currently only in the
>>>> Tomcat 5.5 stream.
>>>> In theory using the same cookie for all sessions should fix the
>>>> problems
>>>> we've had.
>>>> (They didn't like the original patch because it wouldn't work if the
>>>> response had already been committed - amongst other things).
>>>>
>>>> Nick
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Nick Lothian [mailto:nick.lothian@essential.com.au]
>>>>> Sent: Tuesday, 12 October 2004 3:43 PM
>>>>> To: pluto-dev@portals.apache.org
>>>>> Subject: RE: FW: Cross Context Sessions (was RE: Defining the
>>>>> release)
>>>>> Importance: Low
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> In previous versions of tomcat it was possible to put an object
>>>>>> into the session in app1 and have it be available in app2. But I
>>>>>> think almost any reading of the above specification section,
>>>>>> would consider this behavior to be out of line with the spec.
>>>>>
>>>>>
>>>>>
>>>>> We are always talking about putting things into the session of app2.
>>>>> Sometime app2 is being invoked via a RequestDispatcher from app1,
>>>>> however.
>>>>>
>>>>> The requirement here is to be able to share data between a portlet
>>>>> (which is
>>>>> invoked via a RequestDispatcher) and a servlet inside the web app
>>>>> as the
>>>>> portlet (so the servlet and the portlet are inside the same context).
>>>>>
>>>>> I've just started a discussion on Tomcat-Dev of this issue (and
>>>>> that bug
>>>>> which you raised).
>>>>>
>>>>> Nick
>>>>>
>>>>
>>>>
>>
>
>
Re: Application Scoped Session Attibutes Work (was: Re: FW: Cross Context Sessions (was RE: Defining the release))
Posted by "Glenn R. Golden" <gg...@umich.edu>.
Does anyone in the Pluto community understand the tomcat issue in the
below messages?
I thought this was designed to solve the problem that when a portlet is
running, the request first went into the Pluto webapp and then was
dispatched to the portlet's own (separate webapp). The http session
would then be a) by the Servlet Spec, and b) by Tomcat's
implementation... I'm not sure! Would it be the sessions from the
Pluto webapp? Would it be the sessions from the portlet's webapp?
The problem comes up when you have a servlet in the portlet's webapp,
and they need to share session information. The servlet's requests
come directly to the webapp, so the servlet has the webapp's sessions.
The portlet's requests come first through Pluto then are dispatched to
the servlet+portlet's webapp, so if there was trouble, it would have to
be that the portlet is getting Pluto's set of sessions, not it's own.
Am I even close here?
So I thought the solution below was to, essentially, "share sessions"
among the many webapps that a Pluto / portlet environment has. I just
tested this with Tomcat 5.5.7, and it acts strangely. When
"emptySessionPath" is set, the JSESSIONID cookies are truly set to the
"/" path, rather than the webapp's path. But, when two different
webapps are worked with, they still get their own separate sessions.
So what happens is that the second one causes the same root JSESSIONID
cookie in the browser to get modified to the second's session id...
then when you return to the first it does NOT see it's session value so
creates yet another new session, and updates the cookie... This does
not seem at all what we want.
What *I* need is a way to share sessions among the webapps in a Pluto
like environment. I thought this looked promising, since we have needs
much like Pluto's.
Thanks for any information you can shed on this issue.
- Glenn
On Oct 14, 2004, at 8:59 AM, David H. DeWolf wrote:
> Remmy checked in a fix to the ant scripts last night and I was able to
> build tomcat from source.
>
> The patch that has been applied to tomcat DOES fix our problem with
> Application Scoped session attributes.
>
> Special thanks to Nick and the Tomcat team for working with each other
> to come up with a creative solution.
>
> ** Remember that if you want this to work you MUST modify your
> server.xml. Specifically, set the parameter "emptySessionPath"
> to true in your connector config. An example is below:
>
> <Connector port="8080" maxThreads="150" minSpareThreads="25"
> maxSpareThreads="75" enableLookups="false"
> redirectPort="8443" acceptCount="100"
> connectionTimeout="20000" disableUploadTimeout="true"
> emptySessionPath="true" />
>
> David
>
>
> David H. DeWolf wrote:
>> Thanks for pursuing this Nick!
>> I've taken a shot at trying it out but have been unsuccessfully in
>> getting the latest version of Tomcat running.
>> When building from source I am unable to complete the build because
>> of an error when creating the jk connector (it can't find the coyote
>> jar - it looks like an ant property isn't being set properly).
>> When attempting to use last night's nightly build I am unable to
>> startup the server because it can't find coyote.
>> My guess is that there is a small ant tweak that needs to occur to
>> get the current source building correctly. Unfortunately I don't
>> have the cycles to look at it at the moment.
>> I'm looking forward to hearing if anyone else has been able to get
>> this tested. It looks like a good solution to me!
>> David
>> Nick Lothian wrote:
>>> The Tomcat team have just committed a change
>>> (<http://nagoya.apache.org/eyebrowse/ReadMsg?listName=tomcat-
>>> dev@jakarta.apa
>>> che.org&msgNo=80223>), which "Add the ability to force session
>>> cookies to be
>>> set to the root path "/"".
>>>
>>> Comments in the commit message suggest that "This will allow the use
>>> case of
>>> the Pluto folks, in a reliable way.".
>>>
>>> Is anyone in a position to test this change at the moment? I'm at
>>> work and
>>> so don't have immediate CVS access. I think it's currently only in
>>> the
>>> Tomcat 5.5 stream.
>>> In theory using the same cookie for all sessions should fix the
>>> problems
>>> we've had.
>>> (They didn't like the original patch because it wouldn't work if the
>>> response had already been committed - amongst other things).
>>>
>>> Nick
>>>
>>>
>>>> -----Original Message-----
>>>> From: Nick Lothian [mailto:nick.lothian@essential.com.au]
>>>> Sent: Tuesday, 12 October 2004 3:43 PM
>>>> To: pluto-dev@portals.apache.org
>>>> Subject: RE: FW: Cross Context Sessions (was RE: Defining the
>>>> release)
>>>> Importance: Low
>>>>
>>>>
>>>>
>>>>
>>>>> In previous versions of tomcat it was possible to put an object
>>>>> into the session in app1 and have it be available in app2. But I
>>>>> think almost any reading of the above specification section, would
>>>>> consider this behavior to be out of line with the spec.
>>>>
>>>>
>>>> We are always talking about putting things into the session of app2.
>>>> Sometime app2 is being invoked via a RequestDispatcher from app1,
>>>> however.
>>>>
>>>> The requirement here is to be able to share data between a portlet
>>>> (which is
>>>> invoked via a RequestDispatcher) and a servlet inside the web app
>>>> as the
>>>> portlet (so the servlet and the portlet are inside the same
>>>> context).
>>>>
>>>> I've just started a discussion on Tomcat-Dev of this issue (and
>>>> that bug
>>>> which you raised).
>>>>
>>>> Nick
>>>>
>>>
>>>
>