Hi Hussayn: I agree with you. In that case you lost the session tracking. Apparently Cocoon manages his own sessions.
I think we need to make Cocoon to work with the Tomcat Sessions or (to be more general) with the Servlet Container Session Management. In that way all will be OK accross multiple web applications. Yesterday I was reading about the new persistent session management in Tomcat 4.1.x. I think we can make use of it. But, since Cocoon works with the Java Servlet Specification 2.2 and not 2.3, this can be an issue to resolve. I feel like you in that the session management is weak at the current development of Cocoon. We need some improvement here to help webapplication development. The best approach is try to be the most closest to the specification 2.3. At the end, for session management in only one application, the current authentication framework is OK. Sorry for the incoveniences. :-D Antonio Gallardo. SAXESS - Hussayn Dabbous dijo: > Maybe there is a missunderstanding here? > > cocoon preserves session when you keep within your > webapplication. But i am talking about another > problem: > > If you are specifying a source over the http: protocol, > cocoon simply opens another HTTPClient request. This > request does NOT preserve the session state! > > I am talking about following setup: > > You have two separate webapplications not necessaryly > running in the same container! One app is the cocoon > application. The other app is a session based webapp. > > Now you setup a pipeline, which gathers data from the > other webapp. Here you are lost. > > What basically is missing: The session state is > usually preserved within cookies, or by URL-rewriting. > If sessions are cookie based, we need to pass the session > cookie through cocoon. And this is definitely not implemented > yet. Or my understanding of the cocoon code is absolutley > wrong ;-) > > > regards, hussayn > > > Antonio Gallardo wrote: >> SAXESS - Hussayn Dabbous dijo: >> >>>cocoon basically does not preserve session state in >>>subrequests. >> >> ? I dont think soo. I have currently running an application 100% >> Cocoon based that works with the authentication framework. And it >> looks like the sessions are preserved. >> >> Can you explain more why you told that? >> >> Antonio Gallardo >> >> >>>i'm currently working together with another developer on a >>>general solution. We are investigating severeal approaches. >>> >>>Currently we are looking at the idea to add another >>>protocol to cocoon, or enhance the http protocol. There >>>was the idea to enhance the new webproxy generator, but >>>we want to check out first, if the protocol enhancement >>>would do a better job here. It may be a more general >>>approach... >>> >>>I made some basic tests and things work fine. I expect to >>>write some preliminary results tonight or tomorrow. >>> >>>As i see multiple requests on this theme i get convinced >>>there is severe need for this feature. >>> >>>I want to inform you, that this enhancement is a commercially >>>triggered work. The participants in the project are beeing >>>payed for their work but the results are kept open source... >>> >>>I'd like to see more projects of this kind. So also individual >>>programmers could can benefit ... >>> >>>regards, hussayn >>> >>>Kishore wrote: >>> >>>>Hi all, >>>> I am using cocoon to apply XSL transformation >>>>on XML files generated by my 'SERVLETS'. So, cocoon >>>>intercepts the client request, calls the proper application servlet, >>>> then applies xsl mapping on the servlet's output and returns the >>>> result as a html file. >>>> Now, the problem I am facing is, this way I am unable >>>>to >>>>maintain sessions among my servlet's clients. Each new request coming >>>> to my servlet is creating a session afresh because it's not the >>>> client directly, but cocoon that's making a request for my servlets. >>>> Has anybody faced this problem or know the solution? >>>>Pl. >>>>let me know ASAP. >>>> >>>>regards >>>>nanda kishore. >>> >>> >>>--------------------------------------------------------------------- >>> Please check that your question has not already been answered in the >>> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> >>> >>>To unsubscribe, e-mail: <[EMAIL PROTECTED]> >>> For additional commands, e-mail: <[EMAIL PROTECTED]> >> >> >> >> >> >> --------------------------------------------------------------------- >> Please check that your question has not already been answered in the >> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> >> >> To unsubscribe, e-mail: <[EMAIL PROTECTED]> >> For additional commands, e-mail: <[EMAIL PROTECTED]> >> > > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
