response.sendRedirect
The Servlet API doc for the sendRedirect method states: If the location is relative with a leading '/' the container interprets it as relative to the servlet container root. I've looked thru the Servlet Spec and can not quite figure out what they mean by servlet container root ? Is this a typo and supposed to be servlet context root ? Or is there really such a thing as the servlet container root, and if so, what is it ? e.g. if my context path is /cal and I want to redirect to /cal/form/index.jsp, what would I use in sendRedirect ? (I know I could do a forward, but want to redirect in my situation) Thanks, Charlie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Way to cleanup *before* session terminates ?
Just tried implementing HttpSessionActivationListener, and the sessionWillPassivate method does not get called when the session is invalidated. I'm using Tomcat 4.1.24. Maybe its not suppposed to ? Per the docs, this is called when the session is migrating between VMs and when persisting sessions, but all I've got going is a session in a single VM being created and being invalidated. On Thursday 31 July 2003 06:33 am, Shapira, Yoav wrote: Howdy, What about the HttpSessionActivationListener's sessionWillPassivate() event? Yoav Shapira Millennium ChemInformatics -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 4:18 AM To: [EMAIL PROTECTED] Subject: Re: Way to cleanup *before* session terminates ? Sorry Charlie (ok, I couldn't resist :), but there isn't a way to do this in Tomcat 4.x and lower. However, the (current draft of the) 2.4 Servlet- Spec has changed the behavior, and so in Tomcat 5.x you can define a HttpSessionListener that will get called before the session is invalidated. Charlie Toohey [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I have been looking for a way to execute some code when a session is terminating due to invalidation or expiration, but before the session has actually been terminated. I know that implementing HttpSessionBindingListener and binding my object into the session will allow me to execute code in my valueUnbound method, but the notifcation is sent after the session has been invalidatd or expired. But is there any way to be notified that the session is about to terminate before it actually has been invalidated or expired ? - Charlie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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]
Way to cleanup *before* session terminates ?
I have been looking for a way to execute some code when a session is terminating due to invalidation or expiration, but before the session has actually been terminated. I know that implementing HttpSessionBindingListener and binding my object into the session will allow me to execute code in my valueUnbound method, but the notifcation is sent after the session has been invalidatd or expired. But is there any way to be notified that the session is about to terminate before it actually has been invalidated or expired ? - Charlie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Define Resource globally or within Context ?
I have several groups of webapps -- all webapps in the same group access the same database. I am defining a Resource and ResourceParams in server.xml and using JNDI to acquire a DataSource (I'm using the Jakarta Commons database connection pool). The question is, should I define a Resource/ResourceParams for each webapp Context, or should I just define a single Resource/ResourceParams for each database within the GlobalNamingResources element. The former would be a lot more maintenance, since I would have multiple copies of the Resource/ResourceParams definition for the same database (for every webapp that used that database). But I was wondering if there were any advantages/disadvantages to having a single global Resource/ResourceParams shared among a group of webapps, or each webapp defining its own Resource /ResourceParams. Ideally, in my case, all webapps that use the same database use the same host, so I would define the Resource/ResourceParams within the Host, but that is not permitted --- they can only be defined globally or within a Context. Thanks, Charlie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat losing session
Infrequently, Tomcat is creating a new session on each request from the same cookie, when all of the requests should be in the same session. I am logging the cookie and session ids to debug this. What I see is that a request comes in with cookie JSESSIONID=X. Tomcat creates a new session, with session id=Y. Then, another request comes in from the same client, and cookie value JSESSIONID=X (still). Tomcat creates a new session again, with session id=Z. What happens most of the time is that client request comes in with cookie value JSESSIONID=X, and Tomcat creates a new session with session id = Y. When another request comes in from the same client, cookie value JSESSIONID now = Y, and Tomcat session id is Y. As expected. The same requests can produce the two different scenarios, so it does not appear to be specific to the resource which is requested. But there are more specifics --- when this happens, the first resource requested in the session is a servlet, which does a sendRedirect, resulting in the request. I don't know if there is something about this sequence that could cause the problem. As I said, this happens very infrequently, and can not be reproduced at will. When it does happen, it happens on every request from the client --- every request receives the same cookie JSESSIONID value, but creates a new session. It's like once it gets into that mode, it can't get out. Has anyone else ever experience this behavior of losing sessions ? We are using Tomcat 4.1.12 with Apache 1.3.27 running on Mandrake Linux 8.1. Thanks for any help, Charlie -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat losing session
Thanks. However, I am writing the cookie value to the log, and the cookie value is identical for subsequent requests, yet Tomcat creates a new session on each request. So it looks like it is parsing the headers correctly. I had a problem recently with a browser not setting Content-type correctly. If the Content-type is note set correctly, Tomcat can't parse the HTTP headers (including the cookie), so it'll create a new one. Charlie Toohey wrote: Infrequently, Tomcat is creating a new session on each request from the same cookie, when all of the requests should be in the same session. I am logging the cookie and session ids to debug this. What I see is that a request comes in with cookie JSESSIONID=X. Tomcat creates a new session, with session id=Y. Then, another request comes in from the same client, and cookie value JSESSIONID=X (still). Tomcat creates a new session again, with session id=Z. What happens most of the time is that client request comes in with cookie value JSESSIONID=X, and Tomcat creates a new session with session id = Y. When another request comes in from the same client, cookie value JSESSIONID now = Y, and Tomcat session id is Y. As expected. The same requests can produce the two different scenarios, so it does not appear to be specific to the resource which is requested. But there are more specifics --- when this happens, the first resource requested in the session is a servlet, which does a sendRedirect, resulting in the request. I don't know if there is something about this sequence that could cause the problem. As I said, this happens very infrequently, and can not be reproduced at will. When it does happen, it happens on every request from the client --- every request receives the same cookie JSESSIONID value, but creates a new session. It's like once it gets into that mode, it can't get out. Has anyone else ever experience this behavior of losing sessions ? We are using Tomcat 4.1.12 with Apache 1.3.27 running on Mandrake Linux 8.1. Thanks for any help, Charlie -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Session experation questions
Yes. Entirely normal. Read the Servlet Specification. Specifically the sections on Sessions and the Deployment Descriptor --- the web.xml you can set the default session timeout value for your webapp. This can be modified at run-time using a servlet API method. On Tuesday 14 January 2003 03:33 pm, you wrote: I have been encountering something that I am not sure if it is normal. I am logged into my Web App and I just let it sit there for about a hour not making any request, then I attempt to start using it again and my session has DISSAPEARED. Is this normal?? If so is there anyway to adjust the expiration times? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Context elements question
per the Tomcat configuration documentation at http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html you MUST define a Context with a context path equal to a zero-length string. This Context becomes the default web application for this virtual host, and is used to process all requests that do not match any other Context's context path. I have two questions about this statement: 1) I don't have a Context meeting this description and everything seems to work fine, so what are the ramifications of violating this ? 2) If I were to follow this, and did not have an actual webapp with a zero-length string as the context path (meaning that I would not have anything valid to specify for docBase), would I then just create a dummy webapp in directory ROOT (or wherever) just so that I could comply with this ? - Charlie -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Context elements question
Paul, That's exactly my point -- and my question. I do NOT have a ROOT directory, THEREFORE Automatic Application Deployment does not automatically create a Context element with context path equal to the empty string, THEREFORE I am violating the configuration docs which say that you MUST have a Context with a context path equal to a zero-length string. What are the ramifications of violating this ? Should I create a ROOT directory with dummy webapp just so that Tomcat will generate the Context element with context path equal to the empty string ? What will this do ? Why do the docs state that this is necessary ? - Charlie On Friday 10 January 2003 01:02 pm, you wrote: On Friday 10 January 2003 03:53 pm, Charlie Toohey wrote: per the Tomcat configuration documentation at http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html you MUST define a Context with a context path equal to a zero-length string. This Context becomes the default web application for this virtual host, and is used to process all requests that do not match any other Context's context path. I have two questions about this statement: 1) I don't have a Context meeting this description and everything seems to work fine, so what are the ramifications of violating this ? Charlie, if you click on the Automatic Application Deployment link in the fourth or fifth paragraph on the same page, you will read the following: Automatic Application Deployment * Any XML ... * Any web... * Any subdirectory within the Application Base directory that appears to be an unpacked web application (that is, it contains a /WEB-INF/web.xml file) will receive an automatically generated Context element, even if this directory is not mentioned in the conf/server.xml file. This generated Context entry will be configured according to the properties set in any DefaultContext element nested in this Host element. The context path for this deployed Context will be a slash character (/) followed by the directory name, unless the directory name is ROOT, in which case the context path will be an empty string (). The last sentence seems to address your question but you could try deleting the ROOT directory, restarting Tomcat and seeing what happens then. 2) If I were to follow this, and did not have an actual webapp with a zero-length string as the context path (meaning that I would not have anything valid to specify for docBase), would I then just create a dummy webapp in directory ROOT (or wherever) just so that I could comply with this ? - Charlie Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Manager App in 4.0
Hi, I was looking thru the archives and see your suggestion below. I am also using Apache/Tomcat. I added your configuration to my server.xml file. Now I get the following exception in the apache_log file when starting up Apache to install the web applications: java.lang.SecurityException: Servlet of class org.apache.catalina.servlets.ManagerServlet is privileged and cannot be loaded by this web application Did you ever get this ? Thanks, Charlie On Thursday 14 March 2002 02:25 am, you wrote: Scott Shorter a écrit : I would speculate that that was a typo for $CATALINA_HOME/conf/tomcat-users.xml - Scott -Original Message- From: John Regan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 13, 2002 6:00 PM To: 'Tomcat Users List' Subject: RE: Manager App in 4.0 thank you for the quick response. yes, i did change the default port to 8100. I made the change and restarted but i still get same thing: 404 Page Not Found Any other suggestions? My file is called tomcat-users.xml should it be conf.tomcat-users.xml? thanks again. -Original Message- From: Ashutosh Aman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 13, 2002 2:25 PM To: Tomcat Users List Subject: Re: Manager App in 4.0 go to $CATALINE_HOME/conf.tomcat-users.xml file where CATALINA_HOME is the directory where you have installed Tomcat. Add one line user name=Me myself password=and Tomcat roles=manager / or you can insert the role manager in one of the existing role. shutdown and start Tomcat and then http://localhost:8100/manager/list I see you are using port 8100. Default is 8080 unless you have changed it. Good luck Aman -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] I paste the answer i did to somebody else. It is for the Tomcat_Apache Engine, but it works the same for the Tomcat_Standalone part. It had been such a mess all around it ! I give yu my code: !-- Define an Apache-Connector Service -- Service name=Tomcat-Apache Connector className=org.apache.catalina.connector.warp.WarpConnector port=8025 minProcessors=5 maxProcessors=75 enableLookups=true appBase=webapps acceptCount=10 debug=0/ !-- Replace localhost with what your Apache ServerName is set to -- Engine className=org.apache.catalina.connector.warp.WarpEngine name=Apache appBase=webapps defaulthost=MyServer.com DefaultContext reloadable=true/ Valve className=org.apache.catalina.valves.AccessLogValve directory=Logs prefix=local_access_log. suffix=.txt pattern=common / !-- Global logger unless overridden at lower levels -- Logger className=org.apache.catalina.logger.FileLogger prefix=apache_log. suffix=.txt timestamp=true/ !-- Because this Realm is here, an instance will be shared globally -- Realm className=org.apache.catalina.realm.MemoryRealm / Host name=MyServer.com debug=10 appBase=webapps unpackWARs=true !-- Tomcat Manager Context -- Context path=/manager docBase=manager privileged=true/ /Host /Engine /Service The best way is via the manager facilities. To do so yu DO have to declare the Host, like in the code below, so that it is available thru the warp connector via: WebAppDeploy manager conn /manager/ Hope this help. Jean-Luc B :O) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Warp and Virtual Hosts (quick question)
When configuring Apache's httpd.conf (or Vhosts.conf) with multiple name-based virtual hosts, I can not find any documentation regarding the WebAppConnection statement. Should I have a separate WebAppConnection within each virtual host section, or should I just have one WebAppConnection in the main section of httpd.conf, and then refer to that in each of the WebAppDeploy statements that are within the virtual host sections (I do understand that the WebAppDeploy statements for each given webapp needs to be within the virtual host section --- it is the WebAppConnection which I'm not sure about). Thanks, Charlie -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Connecting Apache 1.3.23 and Tomcat 4.0.3 via WARP
I've had better luck with the mod_webapp.so binary from Tomcat 4.0.1 than the one from Tomcat 4.0.2. I've used it successfully with Tomcat 4.0.1, 4.0.2 and 4.0.3. available at: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.1/bin/linux/i386/ Also, in my environment I've noticed that if I start Apache immediately after starting Tomcat, my webapps don't get deployed/installed. So I usually wait 15-30 seconds after starting Tomcat before starting Apache (in the same, vein, when bouncing Tomcat in an Apache/Tomcat setup, I've noticed that it takes a while for Tomcat to shut down properly, so after shutting Tomcat down, I wait a while before starting Tomcat up again). Once Apache is started, you should be able to see your webpps being deployed (a.k.a. installed) in the Tomcat logs/apache.TODAY'S-DATE-GOES-HERE.txt log file, so you may want to tail -f this file to watch what is happening. If you don't see anything there, I would definitely focus on the Apache httpd.conf setup with regard to WARP and make sure you've got everything set up correctly. - Charlie On Thursday 28 March 2002 12:55 pm, you wrote: Mine did the same damn thing. I ended up using the proxy connector on port 8181 and proxying my virtual hosts to tomcat. Love to hear the solution. J a m e s B. S w a r t -Original Message- From: Thomas Gideon [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 28, 2002 1:08 PM To: Tomcat Users List Subject: Connecting Apache 1.3.23 and Tomcat 4.0.3 via WARP I grabbed the binary for mod_webapp from the Tomcat 4.0 download directories, for Linux 2.2 but cannot get it to work. I am running Debian Woody, with the testing package for Apache 1.3.23. I have been running this version of Apache successfull with Tomcat 3.x via mod_jk for some time, using the Debian testing packages for Tomcat and mod_jk. I have decided to step up to Tomcat 4.0, mostly to start working the the Standard Taglib. I have Tomcat 4.0 installed and have no problem working with the HTTP 1.1 connector, I have done so for the past few days will worknig to migrate my existing JSPs over to 4.0. I tried to set up mod_webapp exactly as the directions indicate and appear to do so successfully. apachectl configtest only complains about not being compiled with the -DEAPI option and apache starts without any errors showing in the logs. When I request a JSP, though, I get a series of segfaults in the apache error.log, nothing shows in *any* of the Tomcat logs except for the usual startup messages, i.e. it looks like the request dies before even reaching Tomcat. I tried compiling mod_webapp from source, but I get an error late in the make output about an invalid operator string. I am not comfy enough with make or C to troubleshoot this one my own. If needed, I can post whatever logs anyone thinks applicable as well as output from my attempts to build mod_webapp from source, if the pre-existing binary just plumb won't exist. I have not tried to get and compile the CVS code for mod_webapp yet. I'd really like to be able to use Apache with Tomcat, as I have in the past, as I have a lot of static content, in the form of XML and XSL files, I'd prefer to server via Apache, and let Tomcat just deal with my Java code. TIA, Thomas -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
configuring logger, given Tomcat's daily log filename changes
Yes, but the name of the tomcat log file changes daily --- is there some way to set up the logger to automcatically deal with these name changes ? I realize this thread has run outside of the realm of Struts, and should really be appearing in the Tomcat mailing list now, so I'm sending it there. - Charlie On Tuesday 26 February 2002 12:04 pm, you wrote: Can't you have a logger point to tomcat log file? Ben - Original Message - From: Charlie Toohey [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Tuesday, February 26, 2002 1:18 PM Subject: Re: Logging in beans Thanks for all of the responses. They've gotten away from my original question just a bit. Assuming that I am using the Commons Logging package/Log4j in my beans, and I want to log something to the Tomcat log file, how can the bean obtain the output stream for the Tomcat log file in a webapp framework independent way --- i.e. I don't want to pass the ActionServlet object to the bean and use its log method, as the bean would then be tied to a particular web application framework (in this case, Struts), which would inhibit its reusability. Instead, I would want to pass something more generic, java.io.OuputStream-like, to the bean, so that it can use whatever logging package I have chosen to log to this stream. The question is really, how do I obtain the java.io.OutputStream for the Tomcat log file in my Struts action class so that I can pass it as a parameter to my bean methods. Charlie On Tuesday 26 February 2002 10:04 am, you wrote: I think it is nice to use Commons Logging just so you have the option of easily switching to another logging framework. You may want to use some other logging framework other than Log4J (my choice) or Jdk1.4 at some point. You won't have to change any of you code if you use Commons Logging. Struts 1.1 is going to use Commons Logging. The Struts shared source is using it as of last nights build. David --- keithBacon [EMAIL PROTECTED] wrote: Does anybody know how the new Java 1.4 logging API affects things? My guess is it increases the desirability of using the jakarta Commons Logging Package. You can use log4j for now easily switch later. But for students or people that can gurantee they will deploy on Java 1.4 shouldn't they just use the JDK logging API directly? But then surely the next release of struts will use the Commons logging so we should too? Oh boy. --- David Winterfeldt [EMAIL PROTECTED] wrote: I would suggest using the Commons Logging Package (http://jakarta.apache.org/commons/logging.html). This is a generic interface to logging packages. If Log4J is detected, it will use it. excerpt from the website: The Logging package is an ultra-thin bridge between different logging libraries. Commons components may use the Logging API to remove compile-time and run-time dependencies on any particular logging package, and contributors may write Log implementations for the library of their choice. David --- Phase Web and Multimedia [EMAIL PROTECTED] wrote: log4j would work well. Schedule away a day or so to become familiar with it and download the 1.2b3 version. This will insure that you are prepared for the future changes in log4j and will keep you from programming with deprecated code. http://jakarta.apache.org/log4j/ Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -Original Message- From: Charlie Toohey [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 7:28 PM To: [EMAIL PROTECTED] Subject: Logging in beans I would like to log some information in the Tomcat log file from my beans. But I don't want to use the ActionServlet log method, as passing an ActionServlet object as a parameter to a bean would violate the bean philosophy that beans should be completely independent of a web application framework, such as Struts, for reusability. How could I just pass in the Stream to the Tomcat log file to a bean so that it can log to the Stream and maintain its web app framework independence ? Thanks, Charlie -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto
Re: session question for tomcat 4.0.1 and 4.0.2
First, of all, the assumption is that you have not turned off session support
using the JSP page directive, i.e. you do NOT have
%@ page session=false
The default is true, so as long as you do not have this, you are fine.
Now, session.isNew() would continually return false if the following
conditions were true:
1. the browser you are testing with is set to NOT accept cookies,
AND
2. you are not encoding your URL's in which case Tomcat can not manage
sessions using URL rewriting, e.g. you should be doing the following in your
.jsp files :
a href=%=response.encodeURL(page1.jsp)%Page 1/a
- Charlie
On Wednesday 13 February 2002 07:08 am, Zhiyong Li wrote:
I posted the following message a while ago and have not got any
response. So, I tried it on tomcat 4.0.2 release. However, I got the
same result. I would appreciate your help.
2. I am trying to use isNew() method on session to detect whether a
session is newly created or not. For example,
HttpSession session = request.getSession();
if (session.isNew()) {
// do something
}
However, session.isNew() always returns false. I tried several other
combinations such as: request.getSession(true) and I got the same
result.
Are these two known problems or anything I am missing?
Zhiyong Li
Analytical Solutions, SAS Institute
(919) 653-2746
[EMAIL PROTECTED]
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
