cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: [Slightly OT] Session problem with Apache-fronted Cocoon site
Date Mon, 09 Jul 2007 03:16:34 GMT
Ard,

You didn't really answer his question, but I didn't really grasp it either.

When Tomcat or Jetty create a session they are going to create a token 
that represents the session will end up in the user's browser or as part 
of each subsequent request. By design, it is not possible for multiple 
end users to share this session, although I suppose it could be done if 
your proxy "owned" the session. However, I've never heard of a proxy 
that would do that.

Can you explain why you would want multiple user's to share a single 
session? In fact, why wouldn't you want each user to have their own locale?

Ralph

Ard Schrijvers wrote:
> Hello,
>
> we run all our sites with httpd in front of cocoon (Jetty or Tomcat), but we are kind
of used to not rely on the locale of the browser, because you cannot be sure all proxies between
the client and your application honour the locale correctly (you might have proxies in between,
for example a proxy within a company, that caches pages but does not use the locale..then
the first locale gets the page, and everybody else with different locale's see the same page.
We therefor user /nl, /en, /fr etc as a prefix in the url)
>
> For the rest, I did not totally grasp the picture you described here, with "changing
the locale only the session ....etc". So, either you use the locale in the url, or try to
explain the timeline of events a little better, because i did not get it. You did configure
httpd (if you use mod_cache) correctly to honour the locale?
>
> Regards Ard
>
>
>   
>> I have a multilingual website implemented with Cocoon 2.1.9 which  
>> runs on top of Tomcat 5.5. I use  
>> org.apache.cocoon.acting.LocaleAction to keep track of the current  
>> language and have set this up as follows:
>>
>>      <map:action logger="sitemap.action.locale" name="locale"  
>> src="org.apache.cocoon.acting.LocaleAction">
>>      	<locale-attribute>locale</locale-attribute>
>>      	<create-session>true</create-session>
>>      	<store-in-request>false</store-in-request>
>>      	<store-in-session>true</store-in-session>
>>      	<store-in-cookie>false</store-in-cookie>
>>      	<use-locale>true</use-locale>
>>      	<default-locale language="en"/>
>>      </map:action>
>>
>> In other words, I store the current locale in the session.
>>
>> This works fine when I call up the website directly from 
>> Tomcat (port  
>> 8084 in my case). However, I want to use Apache HTTPD 2.0 as a  
>> reverse proxy. I have tried using mod_jk and mod_proxy (as 
>> per http:// 
>> wiki.apache.org/cocoon/ApacheModProxy), but more than one session is  
>> being passed from HTTPD to Tomcat/Cocoon: when I change language,  
>> only the session in which I changed the language gets changed 
>> and the  
>> other remains as it was.
>>
>> I realise this is slightly off-topic for this list, but I thought  
>> other Cocoon users might have experienced the same thing and be able  
>> to give me a hint as to how to force HTTPD and Tomcat to use 
>> just one  
>> session. I've spent all day googling, but all I find is stuff about  
>> load-balancing and sticky sessions when HTTPD is being used with  
>> multiple workers. I just have one worker.
>>
>> Steve
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message