RE: [EXTERNAL] Re: Windows Event Log
Thanks for the response. Can the server logs be setup this way or it is just for application logs? Is there any place I can go to learn how to do this? Gerald -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, March 27, 2019 10:31 AM To: users@tomcat.apache.org Subject: [EXTERNAL] Re: Windows Event Log WARNING:This is an external email that originated outside of our email system. DO NOT CLICK links or open attachments unless you recognize the sender and know that the content is safe! On 27/03/2019 13:24, GERALD EICHELBERGER wrote: > Greetings, I am looking for assistance in determining if Apache Tomcat has > the ability to have its events/logs to output to the Windows Event Log. Out of the box? No. Configure logging to use log4j and then add Log4JNA and it looks to be doable. > This is now a requirement for my organization. If this is not available where > can I go to get documentation so that I can create a BRJ for this requirement? BRJ? > I am currently working with Tomcat version 7.0.93 in a Test and Production > environment on Windows Server 2012. With Tomcat 7 you'll probably want to use log4j rather than log4j2 but still with log4JNA. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Persistence Problems -- Epilog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jerry, On 4/11/19 19:34, Jerry Malcolm wrote: > > On 4/11/2019 5:05 PM, Jerry Malcolm wrote: >> On 4/11/2019 4:22 PM, Christopher Schultz wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >>> >>> Jerry, >>> >>> On 4/11/19 15:29, Jerry Malcolm wrote: Alternatively, if I had a better understanding of how sessions are managed by both TC and the browser, it might help me figure out what is going wrong. I know a session key is generated by TC and sent back in a response. And I'm assuming that the browser must return that session key on subsequent calls. But if there are several webapps on domain, how does the browser differentiate which session key to send back on a subsequent response? Is it just understood that the first 'folder' level under the domain (i.e. context name) is always a different session key? (myDomain.com/order vs. myDomain/account)? Or does the browser send all session keys back per domain and let TC figure out which one, if any, to use? Again, just looking for a little education here >>> Do you know if HTTP cookies or URL-parameters are being used >>> for session-management? If you aren't sure, try logging-in to >>> your application and look at the URLs and cookies. >>> >>> Typically, a web application will use cookies with the name >>> JSESSIONID. If the session identifier is tracked in the URL, >>> then you'll see ";jsessionid=[id]" in your URLs after the path >>> but before the query string. >>> >>> It's very easy to "lose" a URL-tracked session id because every >>> single URL generated by your application must include that >>> parameter. A sinle miss can cause the session to be lost by the >>> client. If you are using SSO (always with a cookie), it can >>> mask the dropping of the session in this way. >>> >>> It's harder to "lose" a session cookie since the browser >>> typically manages that. Cookies are tracked per web-application >>> using each application's path. The browser should only return a >>> single cookie for a given path. If you have applications that >>> share a URL space (e.g. /master and /master/sub and >>> /master/sub2) then things can get very confusing for the >>> browser and the server. It's best not to overlap URL-spaces in >>> this way. >>> >>> Are you using clustering or anything else like that which might >>> also cause session-ids to change? >>> >>> - -chris >> >> Thank you so much for the info... I think we're getting >> somewhere I am definitely using cookies and not url parms for >> the session id. (no clustering). I went into the firefox >> debugger and located the cookie storage for the site. I found a >> cookie for each webapp context that I am using. That makes >> sense. I think I know what is happening. Correct my >> assumptions here: >> >> I have a webapp with context /order. There is a JSESSIONID >> cookie for /order as expected. I assume that every time I send a >> URL from the browser with the /order context, the browser will >> correctly send the /order session cookie. So far, so good... >> >> But I have a rewrite rule "/storefront" that maps to one of >> the /order urls. I assume the browser knows nothing about >> rewrites, so the browser is going to assume that "/storefront" is >> simply a different webapp context that it doesn't have a session >> id cookie for, and therefore doesn't send anything. Therefore, >> when the rewritten url becomes another /order url, TC gets an >> /order request but with no session id, and therefore creates a >> new session and sends it back for the browser to store (replace) >> as the /order session id. >> >> So assuming I have analyzed this correctly, that can explain >> precisely what I'm seeing. Understanding the problem is a big >> step... But now I have to figure out how to get around it and >> make it do what I want. At this point, I see three options: >> >> 1) remove all rewrites from httpd. That is going to be massive, >> very difficult, and non-trivial. And I'll also have to come up >> with way to handle multi-client variations, etc. that I have been >> mapping by simply using different rewrites on each site. This >> one is not even close to my first choice >> >> 2) Could I perhaps send my own additional JSESSIONID cookies with >> the current "/order" session id for the rewrite 'fake contexts' >> such as "/storefront" so that the browser will basically send a >> copy of the /order session id with the /storefront url? >> >> 3) I really don't care to have separate sessions for each webapp >> context anyway. In fact, I'd prefer it if there was one session >> / sessionId for the enter application (all 10 contexts). Is >> there any way to send the session id cookie keyed as simply "/" >> instead of "/"? All URLs to the domain whether rewrite >> aliases or actually urls would match this one JSESSIONID cookie >> and therefore would
Re: Session Persistence Problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jerry, On 4/11/19 18:05, Jerry Malcolm wrote: > On 4/11/2019 4:22 PM, Christopher Schultz wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> Jerry, >> >> On 4/11/19 15:29, Jerry Malcolm wrote: >>> Alternatively, if I had a better understanding of how sessions >>> are managed by both TC and the browser, it might help me figure >>> out what is going wrong. I know a session key is generated by >>> TC and sent back in a response. And I'm assuming that the >>> browser must return that session key on subsequent calls. But >>> if there are several webapps on domain, how does the browser >>> differentiate which session key to send back on a subsequent >>> response? Is it just understood that the first 'folder' level >>> under the domain (i.e. context name) is always a different >>> session key? (myDomain.com/order vs. myDomain/account)? Or >>> does the browser send all session keys back per domain and let >>> TC figure out which one, if any, to use? Again, just looking >>> for a little education here >> Do you know if HTTP cookies or URL-parameters are being used for >> session-management? If you aren't sure, try logging-in to your >> application and look at the URLs and cookies. >> >> Typically, a web application will use cookies with the name >> JSESSIONID. If the session identifier is tracked in the URL, >> then you'll see ";jsessionid=[id]" in your URLs after the path >> but before the query string. >> >> It's very easy to "lose" a URL-tracked session id because every >> single URL generated by your application must include that >> parameter. A sinle miss can cause the session to be lost by the >> client. If you are using SSO (always with a cookie), it can mask >> the dropping of the session in this way. >> >> It's harder to "lose" a session cookie since the browser >> typically manages that. Cookies are tracked per web-application >> using each application's path. The browser should only return a >> single cookie for a given path. If you have applications that >> share a URL space (e.g. /master and /master/sub and /master/sub2) >> then things can get very confusing for the browser and the >> server. It's best not to overlap URL-spaces in this way. >> >> Are you using clustering or anything else like that which might >> also cause session-ids to change? >> >> - -chris > > Thank you so much for the info... I think we're getting > somewhere I am definitely using cookies and not url parms for > the session id. (no clustering). I went into the firefox debugger > and located the cookie storage for the site. I found a cookie for > each webapp context that I am using. That makes sense. I think I > know what is happening. Correct my assumptions here: > > I have a webapp with context /order. There is a JSESSIONID cookie > for /order as expected. I assume that every time I send a URL from > the browser with the /order context, the browser will correctly > send the /order session cookie. So far, so good... > > But I have a rewrite rule "/storefront" that maps to one of > the /order urls. Hmm... > I assume the browser knows nothing about rewrites, so the browser > is going to assume that "/storefront" is simply a different webapp > context that it doesn't have a session id cookie for, and therefore > doesn't send anything. Yes, exactly. > Therefore, when the rewritten url becomes another /order url, TC > gets an /order request but with no session id, and therefore > creates a new session and sends it back for the browser to store > (replace) as the /order session id. Correct. Had the rewrite been done as a REDIRECT, the browser would have made a second request which would have included the (correct) session cookie. Since your rewriting happens exclusively on the server-end, the cookie is not available. > So assuming I have analyzed this correctly, that can explain > precisely what I'm seeing. Understanding the problem is a big > step... But now I have to figure out how to get around it and make > it do what I want. At this point, I see three options: > > 1) remove all rewrites from httpd. That is going to be massive, > very difficult, and non-trivial. And I'll also have to come up > with way to handle multi-client variations, etc. that I have been > mapping by simply using different rewrites on each site. This one > is not even close to my first choice You may not have to give-up ALL rewrites. Just the problematic ones. you might even be able to convert the rewrites into redirects. That doesn't help you with SEO (lol) but it will take a broken application and make it work again without too much hassle. > 2) Could I perhaps send my own additional JSESSIONID cookies with > the current "/order" session id for the rewrite 'fake contexts' > such as "/storefront" so that the browser will basically send a > copy of the /order session id with the /storefront url? That would be very difficult to accomplish.
Re: Is there a problem with the digest?
On 12/04/2019 16:29, Mark Thomas wrote: > Which address did you use to subscribe to the digest list? It wasn't > this one... Ignore that. ezmlm cmd line error on my part. I see your digest subscription in the logs from this address. Hmmm. Let me go and dig into the mail logs... Mark > > Mark > > > On 12/04/2019 15:43, Mark Thomas wrote: >> On 12/04/2019 15:27, Richard Huntrods wrote: >>> It's been four days since I've seen a 'users-dig...@tomcat.apache.org' >>> email. I posted a question on April 9, and no digest since (I subscribed >>> to the digest), yet I found a reply on the digest archive by searching >>> with Google. >>> >>> So again... is there a problem with digest emails? I have no spam >>> filters enabled and there's nothing in a junk or trash folder. >>> >>> I also tried sending a blank email to >>> users-digest-h...@tomcat.apache.org yesterday and no reply from that >>> either. >> >> Talk to your mail server admins. >> >> The ASF suffered a hardware failure of our main mail server ~4 days ago >> and, as a result, stood up a new server in a different data centre. >> >> The ASF mail server sends out a LOT of email. >> >> Some mail servers appear to be configured to assume large volumes of >> email from a server they have never seen before must be spam and are >> therefore rejecting all ASF mail. >> >> Of course, the chances are that you will never receive this email >> either. Sigh. I'll forward it to you from a different address. >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a problem with the digest?
Which address did you use to subscribe to the digest list? It wasn't this one... Mark On 12/04/2019 15:43, Mark Thomas wrote: > On 12/04/2019 15:27, Richard Huntrods wrote: >> It's been four days since I've seen a 'users-dig...@tomcat.apache.org' >> email. I posted a question on April 9, and no digest since (I subscribed >> to the digest), yet I found a reply on the digest archive by searching >> with Google. >> >> So again... is there a problem with digest emails? I have no spam >> filters enabled and there's nothing in a junk or trash folder. >> >> I also tried sending a blank email to >> users-digest-h...@tomcat.apache.org yesterday and no reply from that >> either. > > Talk to your mail server admins. > > The ASF suffered a hardware failure of our main mail server ~4 days ago > and, as a result, stood up a new server in a different data centre. > > The ASF mail server sends out a LOT of email. > > Some mail servers appear to be configured to assume large volumes of > email from a server they have never seen before must be spam and are > therefore rejecting all ASF mail. > > Of course, the chances are that you will never receive this email > either. Sigh. I'll forward it to you from a different address. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a problem with the digest?
Why google? Actually I was continuing to research the problem I'd posted, and the digest archive showed up as the first two hits. :-) -R On 4/12/2019 7:34 AM, Konstantin Kolinko wrote: пт, 12 апр. 2019 г. в 17:27, Richard Huntrods : It's been four days since I've seen a 'users-dig...@tomcat.apache.org' email. I posted a question on April 9, and no digest since (I subscribed to the digest), yet I found a reply on the digest archive by searching with Google. Why Google? The are several public archives of this mailing list, as listed here: https://tomcat.apache.org/lists.html#tomcat-users So again... is there a problem with digest emails? I have no spam filters enabled and there's nothing in a junk or trash folder. I also tried sending a blank email to users-digest-h...@tomcat.apache.org yesterday and no reply from that either. I never tried sending a "blank" email. Those may be rejected by spam filer (as well as e-mails using HTML formatting). I usually add a few lines of text. Best regards, Konstantin Kolinko --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Persistence Problems
Thanks, Luis. I tried that. And it indeed does store only one session cookie for the entire domain. But it does not change the fact that if you have two webapps in the same domain (contexts), you still have two different sessions and therefore two different session ids. You now just have one place to store both, and the cookie will always be replaced with id from the last call, throwing away the session id from the previous call. When you call context A, the cookie is set to context A session id. When you next call context B, the cookie is replaced with context B session id. The you call context A again, it has to create a new session since it doesn't recognize context B's session id. If it was possible to have all contexts share the SAME session (and session id), this would be perfect. But from what I understand it is not possible to share the same session across multiple contexts. Am I correct, or is there indeed a way to have one session for all contexts (not crosscontext access to other sessions... truly only ONE session used by all contexts)? Jerry On 4/12/2019 2:17 AM, Luis Rodríguez Fernández wrote: Hello Jerry, Sure, you can always set the path of your cookies to "/" via the cookie-config element [1] in your web.xml descriptor: / Or via your context.xml [2] Hope it helps, Luis [1] https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf [2] https://tomcat.apache.org/tomcat-9.0-doc/config/context.html El vie., 12 abr. 2019 a las 0:14, Jerry Malcolm () escribió: On 4/11/2019 4:22 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jerry, On 4/11/19 15:29, Jerry Malcolm wrote: Alternatively, if I had a better understanding of how sessions are managed by both TC and the browser, it might help me figure out what is going wrong. I know a session key is generated by TC and sent back in a response. And I'm assuming that the browser must return that session key on subsequent calls. But if there are several webapps on domain, how does the browser differentiate which session key to send back on a subsequent response? Is it just understood that the first 'folder' level under the domain (i.e. context name) is always a different session key? (myDomain.com/order vs. myDomain/account)? Or does the browser send all session keys back per domain and let TC figure out which one, if any, to use? Again, just looking for a little education here Do you know if HTTP cookies or URL-parameters are being used for session-management? If you aren't sure, try logging-in to your application and look at the URLs and cookies. Typically, a web application will use cookies with the name JSESSIONID. If the session identifier is tracked in the URL, then you'll see ";jsessionid=[id]" in your URLs after the path but before the query string. It's very easy to "lose" a URL-tracked session id because every single URL generated by your application must include that parameter. A sinle miss can cause the session to be lost by the client. If you are using SSO (always with a cookie), it can mask the dropping of the session in this way. It's harder to "lose" a session cookie since the browser typically manages that. Cookies are tracked per web-application using each application's path. The browser should only return a single cookie for a given path. If you have applications that share a URL space (e.g. /master and /master/sub and /master/sub2) then things can get very confusing for the browser and the server. It's best not to overlap URL-spaces in this way. Are you using clustering or anything else like that which might also cause session-ids to change? - -chris Thank you so much for the info... I think we're getting somewhere I am definitely using cookies and not url parms for the session id. (no clustering). I went into the firefox debugger and located the cookie storage for the site. I found a cookie for each webapp context that I am using. That makes sense. I think I know what is happening. Correct my assumptions here: I have a webapp with context /order. There is a JSESSIONID cookie for /order as expected. I assume that every time I send a URL from the browser with the /order context, the browser will correctly send the /order session cookie. So far, so good... But I have a rewrite rule "/storefront" that maps to one of the /order urls. I assume the browser knows nothing about rewrites, so the browser is going to assume that "/storefront" is simply a different webapp context that it doesn't have a session id cookie for, and therefore doesn't send anything. Therefore, when the rewritten url becomes another /order url, TC gets an /order request but with no session id, and therefore creates a new session and sends it back for the browser to store (replace) as the /order session id. So assuming I have analyzed this correctly, that can explain precisely what I'm seeing.
Re: Is there a problem with the digest?
On 12/04/2019 15:27, Richard Huntrods wrote: > It's been four days since I've seen a 'users-dig...@tomcat.apache.org' > email. I posted a question on April 9, and no digest since (I subscribed > to the digest), yet I found a reply on the digest archive by searching > with Google. > > So again... is there a problem with digest emails? I have no spam > filters enabled and there's nothing in a junk or trash folder. > > I also tried sending a blank email to > users-digest-h...@tomcat.apache.org yesterday and no reply from that > either. Talk to your mail server admins. The ASF suffered a hardware failure of our main mail server ~4 days ago and, as a result, stood up a new server in a different data centre. The ASF mail server sends out a LOT of email. Some mail servers appear to be configured to assume large volumes of email from a server they have never seen before must be spam and are therefore rejecting all ASF mail. Of course, the chances are that you will never receive this email either. Sigh. I'll forward it to you from a different address. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a problem with the digest?
пт, 12 апр. 2019 г. в 17:27, Richard Huntrods : > > It's been four days since I've seen a 'users-dig...@tomcat.apache.org' > email. I posted a question on April 9, and no digest since (I subscribed > to the digest), yet I found a reply on the digest archive by searching > with Google. Why Google? The are several public archives of this mailing list, as listed here: https://tomcat.apache.org/lists.html#tomcat-users > So again... is there a problem with digest emails? I have no spam > filters enabled and there's nothing in a junk or trash folder. > > I also tried sending a blank email to > users-digest-h...@tomcat.apache.org yesterday and no reply from that either. I never tried sending a "blank" email. Those may be rejected by spam filer (as well as e-mails using HTML formatting). I usually add a few lines of text. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Is there a problem with the digest?
It's been four days since I've seen a 'users-dig...@tomcat.apache.org' email. I posted a question on April 9, and no digest since (I subscribed to the digest), yet I found a reply on the digest archive by searching with Google. So again... is there a problem with digest emails? I have no spam filters enabled and there's nothing in a junk or trash folder. I also tried sending a blank email to users-digest-h...@tomcat.apache.org yesterday and no reply from that either. -R --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: connectionInitSqls
Are you using the "*" (splat/star/asterisk) characters below to highlight the configuration entry for our benefit? Are you sure you're putting the connectionInitSqls on the correct Resource element below (noticed you had two)? Try verifying the JNDI lookup in your code with the configuration below just to make sure. Also, logs? On 4/12/19, Peter Tom wrote: > Hi all, > > I have third party application installed on Tomcat 8.5. > > The application uses DB Oracle connection (ojdbc7) and everything working > fine. > > I would like to set session parameter on first db connect (alter session > set NLS_NUMERIC_CHARACTERS = '.,') > > I added this (connectionInitSqls ="alter session set NLS_NUMERIC_CHARACTERS > = '.,'") into the context.xml file in the app. META-INF directory: > > > factory="org.apache.tomcat.dbcp.dbcp2.cpdsadapter.DriverAdapterCPDS" > name="jdbc/ZDB_TESTCPDS" > type="org.apache.tomcat.dbcp.dbcp2.cpdsadapter.DriverAdapterCPDS" > url="jdbc:oracle:thin:@10.16.43.3:1521:ZDB001"/> > dataSourceName="java:/comp/env/jdbc/ZDB_TESTCPDS" defaultMaxActive="10" > defaultMaxIdle="5" defaultMaxWait="1" > factory="org.apache.tomcat.dbcp.dbcp2.datasources.PerUserPoolDataSourceFactory" > logAbandoned="true" name="jdbc/ZDB_TEST" removeAbandoned="true" > removeAbandonedTimeout="300" testOnBorrow="false" > type="org.apache.tomcat.dbcp.dbcp2.datasources.PerUserPoolDataSource" > validationQuery="select 1 from AnyTable" *connectionInitSqls ="alter > session set NLS_NUMERIC_CHARACTERS = '.,'"*/> > > > > But still not working. > > Has somebody idea how to solve it? > > > thank you > Peter > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
connectionInitSqls
Hi all, I have third party application installed on Tomcat 8.5. The application uses DB Oracle connection (ojdbc7) and everything working fine. I would like to set session parameter on first db connect (alter session set NLS_NUMERIC_CHARACTERS = '.,') I added this (connectionInitSqls ="alter session set NLS_NUMERIC_CHARACTERS = '.,'") into the context.xml file in the app. META-INF directory: But still not working. Has somebody idea how to solve it? thank you Peter
Re: Session Persistence Problems
Hello Jerry, Sure, you can always set the path of your cookies to "/" via the cookie-config element [1] in your web.xml descriptor: / Or via your context.xml [2] Hope it helps, Luis [1] https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf [2] https://tomcat.apache.org/tomcat-9.0-doc/config/context.html El vie., 12 abr. 2019 a las 0:14, Jerry Malcolm () escribió: > On 4/11/2019 4:22 PM, Christopher Schultz wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Jerry, > > > > On 4/11/19 15:29, Jerry Malcolm wrote: > >> Alternatively, if I had a better understanding of how sessions are > >> managed by both TC and the browser, it might help me figure out > >> what is going wrong. I know a session key is generated by TC and > >> sent back in a response. And I'm assuming that the browser must > >> return that session key on subsequent calls. But if there are > >> several webapps on domain, how does the browser differentiate which > >> session key to send back on a subsequent response? Is it just > >> understood that the first 'folder' level under the domain (i.e. > >> context name) is always a different session key? > >> (myDomain.com/order vs. myDomain/account)? Or does the browser > >> send all session keys back per domain and let TC figure out which > >> one, if any, to use? Again, just looking for a little education > >> here > > Do you know if HTTP cookies or URL-parameters are being used for > > session-management? If you aren't sure, try logging-in to your > > application and look at the URLs and cookies. > > > > Typically, a web application will use cookies with the name > > JSESSIONID. If the session identifier is tracked in the URL, then > > you'll see ";jsessionid=[id]" in your URLs after the path but before > > the query string. > > > > It's very easy to "lose" a URL-tracked session id because every single > > URL generated by your application must include that parameter. A sinle > > miss can cause the session to be lost by the client. If you are using > > SSO (always with a cookie), it can mask the dropping of the session in > > this way. > > > > It's harder to "lose" a session cookie since the browser typically > > manages that. Cookies are tracked per web-application using each > > application's path. The browser should only return a single cookie for > > a given path. If you have applications that share a URL space (e.g. > > /master and /master/sub and /master/sub2) then things can get very > > confusing for the browser and the server. It's best not to overlap > > URL-spaces in this way. > > > > Are you using clustering or anything else like that which might also > > cause session-ids to change? > > > > - -chris > > Thank you so much for the info... I think we're getting somewhere I > am definitely using cookies and not url parms for the session id. (no > clustering). I went into the firefox debugger and located the cookie > storage for the site. I found a cookie for each webapp context that I > am using. That makes sense. I think I know what is happening. > Correct my assumptions here: > > I have a webapp with context /order. There is a JSESSIONID cookie for > /order as expected. I assume that every time I send a URL from the > browser with the /order context, the browser will correctly send the > /order session cookie. So far, so good... > > But I have a rewrite rule "/storefront" that maps to one of the > /order urls. I assume the browser knows nothing about rewrites, so the > browser is going to assume that "/storefront" is simply a different > webapp context that it doesn't have a session id cookie for, and > therefore doesn't send anything. Therefore, when the rewritten url > becomes another /order url, TC gets an /order request but with no > session id, and therefore creates a new session and sends it back for > the browser to store (replace) as the /order session id. > > So assuming I have analyzed this correctly, that can explain precisely > what I'm seeing. Understanding the problem is a big step... But now I > have to figure out how to get around it and make it do what I want. At > this point, I see three options: > > 1) remove all rewrites from httpd. That is going to be massive, very > difficult, and non-trivial. And I'll also have to come up with way to > handle multi-client variations, etc. that I have been mapping by simply > using different rewrites on each site. This one is not even close to my > first choice > > 2) Could I perhaps send my own additional JSESSIONID cookies with the > current "/order" session id for the rewrite 'fake contexts' such as > "/storefront" so that the browser will basically send a copy of the > /order session id with the /storefront url? > > 3) I really don't care to have separate sessions for each webapp context > anyway. In fact, I'd prefer it if there was one session / sessionId for > the enter application (all
