Re: Application Scoped Session Attibutes Work (was: Re: FW: Cross ContextSessions (was RE: Defining the release))

["David H. DeWolf" <dd...@apache.org>]

I think your right.  As far as I can tell the Connector class that was 
patched didn't even exist in 5.0.x (or at least wasn't in the same package).

I tested the fix with:

1) tomcat 5.5 and JDK5
2) tomcat 5.5 w/ compat and JDK1.4.2_04

David

Nick Lothian wrote:
> Is this available in the Tomcat 5.0.x stream as well as Tomcat 5.5?
> 
> Unless I'm misunderstanding the Tomcat CVS structure I think it is only in
> 5.5, which is less that ideal, and would cause us problems with doing a
> stable Pluto 1.0 release (since Tomcat 5.5 is still alpha)
> 
> Nick
> 
> 
>>-----Original Message-----
>>From: David H. DeWolf [mailto:ddewolf@apache.org]
>>Sent: Thursday, 14 October 2004 10:30 PM
>>To: pluto-dev@portals.apache.org
>>Subject: Application Scoped Session Attibutes Work (was: Re: FW: Cross
>>ContextSessions (was RE: Defining the release))
>>Importance: Low
>>
>>
>>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-d
>>ev@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
>>>>>
>>>>
>>>>
>>>
>