Hi, as has been said before, the main "problem" (if you want to say so) is the fact that, the session is provided by the servlet container (e.g. Tomcat). Usually the main purpose of a session is to identify a returning user (session), this is commonly achieved by associating each new user with a session identifier. This identifier is then either encoded in the URL or saved in a session cookie and maintained for the lifetime of the session. On the serverside this handle is then used to store session specific data across requests... This is were your "problem" comes in; if you open a new window from a link within the original one and your server is using URL encoded sessions, you will have the session URL encoded in that link and the server will associate that window with the old session. If the server is ussing cookie based sessions, your cookie will be shared across windows of the same browser instance.
If you really want to open multiple sessions from one browser instance you should try the following: Setup your servlet container to use URL encoded sessions _only_. Then provide specific links from the original session to open in an new window and ensure that these links are not rewritten by the container (e.g. ensure that they do not contain the encoded session key). That should (in theory) create a new session within the new browser window. Be aware though that in doing so you loose everything associated with the original session (of course) - like authentification and authorization data. HTH, Jan km <[EMAIL PROTECTED]> schrieb am 16.11.2006 15:30:46: > Hello > > yes I meen multiple session from one client computer. I know that > cocoon handle more session from different clients. But I meen more > session from one IP, one client. With different requests, with > different desing. I know it could sound crazy :) > > Did someone done something like this?? > > Kris > > > km wrote: > > > Hello Thanks for your answer. Sorry for my english :) I try to do it > > > with other browsers - one catalog in ie and another in ffox. but it > > > didn't work. I think I rewrite the cocoon session, not only the > > > browser session. Is cocoon able to handle multisession? > > > > Yes, absolutely -- it would be kind of dumb if it didn't handle multiple > > sessions, that would defeat the whole purpose of sessions anyway. > > Actually, Cocoon just uses the HttpSession provided by the servlet > > container (Tomcat, Jetty, etc.) so it's not even Cocoon-specific. I'm > > assuming that by "multisession" you're talking about multiple > > HttpSessions; I'm not familiar with the term multisession so maybe > > you're talking about something else? > > > > > > > > > >>> Hello > > >>> > > >>> I have a problem with Session (Multisession) under cocoon. I'm > > >>> using Cocoon with an DB and I use it for the catalog viewing. If > > >>> I use one window (browser) it is everything ok. If I use two or > > >>> more windows, with others catalog (first window catalog one, > > >>> secound window catalog two) I have a problem with session. > > >>> Session of window one (catalog one) is rewrited with session from > > >>> window two (catalog two). Can someone help me? > > >> Oooooow, I first did not understand your problem, but I think I do > > >> now. I am not to familiar with the exact working of sessions > > >> (mozilla also works differently the explorer), but I think your > > >> problem is not really a problem in my opinion. If you have a > > >> session open, and you have a new window or a popup, and request to > > >> the same server, I think you just maintain the same session. This > > >> really is common for every framework, because I think it is how a > > >> browser works in combination with tomcat or jetty. Why would you > > >> want to have different behavior? Probably, not opening another > > >> window, but another *browser* (like, you have explorer session, now > > >> open mozilla), this will create a seperate session, and will behave > > >> according your expectations > > >> > > >> > > >> Regards Ard > > >> > > >> > > >>> Thanks > > >>> > > >>> Kris > > >>> > > >>> --------------------------------------------------------------------- > > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] For > > >>> additional commands, e-mail: [EMAIL PROTECTED] > > >>> > > >>> > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > **************************** > kmConsulting > Krzysztof Murmylo > > Mobil: +49 179 31 53 791 > eMail: [EMAIL PROTECTED] > http://www.kmconsulting.org > **************************** > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
