how to link a webapp deployed on one tomcat server on another tomcat server?
i have a main domain tomcat server ,i want to link a webapp that's deployed in an another tomcat server which is in the LAN of the main server . i do not want to use apache2 server and i cant deploy the app on the main server .how can i do this ,any suggestions are welcome thanks sanre6 -- View this message in context: http://old.nabble.com/how-to-link-a-webapp-deployed-on-one-tomcat-server-on-another-tomcat-server--tp32316847p32316847.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[Apache_Tomcat]: $CATALINA_HOME/webapps/host-manager/manager.xml
Hi there,
I am a newbie to Apache Tomcat. While studying the host-manager application,
I found the file $CATALINA_HOME/webapps/host-manager/manager.xml. This file
seems to be the configuration file for the manager application (not the
host-manager):
Context docBase=${catalina.home}/webapps/manager .../
I wonder what the file is used for? I tried to configure the file but
neither manager application nor host-manager application is affected.
Thanks in advance
--
View this message in context:
http://old.nabble.com/-Apache_Tomcat-%3A-%24CATALINA_HOME-webapps-host-manager-manager.xml-tp32317403p32317403.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Logging in options in Tomcat 6.0.26
Hello I wonder if anyone can advise? I am using Tomcat 6.0.26 in an application with a MySQL 5.* back end database. Currently my users' username and userrole details are stored in the User table of the database. At the moment though, there is no actual logging in facility in the application. What I want is for users to be able to log in only when they have to create content, and then for the login facility to be embedded in the relevant pages, e.g. if a user posts a comment, they log in and then return to the comment posting page. I can do this using my own look-up process to check a user's name and password, but can this be done through the j_username and j_password combination as part of Tomcat's: form method = POST action='%= response.encodeURL(j_security_check) %' Process? I do not want the application in question to be accessible only through a log in page. There is no secure information held in the database and the users' passwords are encrypted using MD5. Thanks Martin.
Re: [Apache_Tomcat]: $CATALINA_HOME/webapps/host-manager/manager.xml
On 23/08/2011 10:12, quanba wrote:
Hi there,
I am a newbie to Apache Tomcat. While studying the host-manager application,
I found the file $CATALINA_HOME/webapps/host-manager/manager.xml. This file
seems to be the configuration file for the manager application (not the
host-manager):
Context docBase=${catalina.home}/webapps/manager .../
I wonder what the file is used for? I tried to configure the file but
neither manager application nor host-manager application is affected.
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/manager/host/HostManagerServlet.java?view=annotate
Start around line 400.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Logging in options in Tomcat 6.0.26
On 23/08/2011 10:48, Martin O'Shea wrote: Hello I wonder if anyone can advise? I am using Tomcat 6.0.26 in an application with a MySQL 5.* back end database. Currently my users' username and userrole details are stored in the User table of the database. At the moment though, there is no actual logging in facility in the application. What I want is for users to be able to log in only when they have to create content, and then for the login facility to be embedded in the relevant pages, e.g. if a user posts a comment, they log in and then return to the comment posting page. I can do this using my own look-up process to check a user's name and password, but can this be done through the j_username and j_password combination as part of Tomcat's: form method = POST action='%= response.encodeURL(j_security_check) %' Process? I do not want the application in question to be accessible only through a log in page. There is no secure information held in the database and the users' passwords are encrypted using MD5. Tomcat applies auth by checking the URL of the request. So if you put the comment form URL inside an area requiring auth, you'll get the result you want. It's up to you to handle the comment form redirection. If you configure FORM auth with the following URL secured: /account/* you could make: /account/add_comment the URl for, well, adding a comment. Tomcat will then ask a user to login before they can submit to the form. p signature.asc Description: OpenPGP digital signature
Re: how to link a webapp deployed on one tomcat server on another tomcat server?
On 23/08/2011 08:32, sanre6 wrote: i have a main domain tomcat server ,i want to link a webapp that's deployed in an another tomcat server which is in the LAN of the main server . i do not want to use apache2 server and i cant deploy the app on the main server .how can i do this ,any suggestions are welcome Define 'link'. p signature.asc Description: OpenPGP digital signature
RE: Tomcat 5.5.28 on 64 bit windows server 2008.
Hi, -Original Message- From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Sent: Monday, August 22, 2011 5:35 PM To: 'Tomcat Users List' Subject: RE: Tomcat 5.5.28 on 64 bit windows server 2008. Allow me to clear that up: 1) If no address= parameter is given in the Connector when running under Windows 2008/Vista/7, then the APR will only bind to the IPv6 any address of [::] for the specified port. 2) If you need IPv4 support under APR, you will need to either specify the address=0.0.0.0 parameter to get the IPv4 any address, or specify the actual IP address to listen on. 3) If you need to support both IPv4 IPv6, you will need to set up two connectors, one for each protocol. 4) This only applies if you are using the APR/native libraries. This was originally discussed on this list in May of 2010, and I think this was determined to be due to Microsoft deciding to implement two protocol stacks, but no one was exactly sure. Also, this only applies to APR/native version 1.1.12 and later, but I doubt anyone really wants to use the earlier versions any more. This seems to only apply to Tomcat 5.5.x, however. When Tomcat 7.0.20 and Tomcat 6.0.33 are run on a Windows 2008 machine without editing the config and using the (default) HTTP-APR / AJP-APR connectors, they only bind to the IPv4 any address. Only Tomcat 5.5.x binds to the IPv6 address, by default. Maybe 7.0.x and 6.0.x have been changed to use the IPv4 any address by default with the APR connectors, but not 5.5.x. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
IPv6 support dropped in Tomcat Native 1.1.22 (on Windows)?
Hi all, while reading the thread Tomcat 5.5.28 on 64 bit windows server 2008., I was experimenting with various Tomcat versions and noticed that IPv6 support seems to have been dropped in the Windows version (32 bit as well as 64 bit) of TC Native 1.1.22 (which is included in Tomcat 7.0.20). I tested on Windows 7 (32 bit), Sun/Oracle JDK 1.7.0. 1. When I downloaded Tomcat 7.0.20, I edited the server.xml and added address=[::] attribute to the HTTP Connector element: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 address=[::] / 2. After starting Tomcat, the following is displayed: Aug 23, 2011 5:57:40 AM org.apache.catalina.core.AprLifecycleListener init INFO: Loaded APR based Apache Tomcat Native library 1.1.22. Aug 23, 2011 5:57:40 AM org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [false], sendfile [true], accept filters [false], random [true]. Aug 23, 2011 5:57:41 AM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler [http-apr-/0:0:0:0:0:0:0:0-8080] Aug 23, 2011 5:57:48 AM org.apache.coyote.AbstractProtocol init SEVERE: Failed to initialize end point associated with ProtocolHandler [http-apr-/0:0:0:0:0:0:0:0-8080] org.apache.tomcat.jni.Error: 731004: The requested name is valid, but no data of the requested type was found. at org.apache.tomcat.jni.Address.info(Native Method) at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:395) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:492) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:369) at org.apache.catalina.connector.Connector.initInternal(Connector.java:910) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:559) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:781) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.startup.Catalina.load(Catalina.java:573) at org.apache.catalina.startup.Catalina.load(Catalina.java:596) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:449) Aug 23, 2011 5:57:48 AM org.apache.catalina.core.StandardService initInternal SEVERE: Failed to initialize connector [Connector[HTTP/1.1-8080]] org.apache.catalina.LifecycleException: Failed to initialize component [Connector[HTTP/1.1-8080]] at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:106) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:559) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:781) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.startup.Catalina.load(Catalina.java:573) at org.apache.catalina.startup.Catalina.load(Catalina.java:596) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:449) Caused by: org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:912) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) ... 12 more Caused by: org.apache.tomcat.jni.Error: 731004: The requested name is valid, but no data of the requested type was found. at org.apache.tomcat.jni.Address.info(Native Method) at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:395) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:492) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:369) at org.apache.catalina.connector.Connector.initInternal(Connector.java:910) ... 13 more Aug 23, 2011 5:57:48 AM org.apache.coyote.AbstractProtocol init INFO: Initializing
RE: Tomcat 5.5.28 on 64 bit windows server 2008.
-Original Message- From: eurotrans-Verlag [mailto:verlag.preis...@t-online.de] Sent: Tuesday, August 23, 2011 7:14 AM To: 'Tomcat Users List' Subject: RE: Tomcat 5.5.28 on 64 bit windows server 2008. Hi, This seems to only apply to Tomcat 5.5.x, however. When Tomcat 7.0.20 and Tomcat 6.0.33 are run on a Windows 2008 machine without editing the config and using the (default) HTTP-APR / AJP-APR connectors, they only bind to the IPv4 any address. Only Tomcat 5.5.x binds to the IPv6 address, by default. Maybe 7.0.x and 6.0.x have been changed to use the IPv4 any address by default with the APR connectors, but not 5.5 Thanks for the update. My experience so far has just been with 5.5.x, but we are moving to 6.0.x with our next software release, so I will be testing this soon. It's good to hear that it appears to have been addressed. Jeff __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Moving init params from web.xml to context.xml
If it helps generate a reply, I'm deploying into Tomcat 6.0.3x running under JDK 1.6.0_2x. -Original Message- From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Sent: Monday, August 22, 2011 3:12 PM To: 'Tomcat Users List' Subject: Moving init params from web.xml to context.xml Our apps are currently deployed using a minimal context.xml file (pointer to doc-base only), with all the other information contained in the web.xml and some properties files. What I'd like to do is move as much of the customizable values out of the web.xml file and into the context.xml file to make upgrades a bit easier. Specifically, I want to move the properties files to a location that won't get overridden when new war files are deployed. Our current web.xml file is structured: web-app context-param param-nameLOG4J_PROPS/param-name param-value/WEB-INF/Log4j.properties/param-value /context-param servlet servlet-nameSERVA/servlet-name display-nameSERVA/display-name descriptionControlling servlet for A/description servlet-classcom.mycompany.webapp.serva/servlet-class init-param param-nameSERVA_PROPS/param-name param-value/WEB-INF/SERVA.properties/param-value /init-param load-on-startup1/load-on-startup /servlet servlet servlet-nameSERVB/servlet-name display-nameSERVB/display-name descriptionControlling servlet for B/description servlet-classcom.mycompany.webapp.servb/servlet-class init-param param-nameSERVB_PROPS/param-name param-value/WEB-INF/SERVB.properties/param-value /init-param load-on-startup1/load-on-startup /servlet /web-app I know from the docs that I can save move the LOG4J_PROPS to the context.xml as it is defined as a context-param. However, can I move the 2 servlet props to the context.xml file also? If so, is it the same as the log4j, or do I need to do something different? Lastly, can the session-timeout setting be located outside of the web.xml file? We customer with different requirements for this value (some misguided), and would like to make it easy for them to set it without having to update it with every deployment. Jeff ___ ___ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cache-Control headers not being added to secure requests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael,
On 8/22/2011 5:39 PM, Zampani, Michael wrote:
However, I'm still confused about
- {request.isSecure()} means that the headers are only added if
the request is not secure since responses from secure requests
must not be cached
I don't see anything regarding secure requests in RFC2616
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.4 or
RFC2818 http://www.ietf.org/rfc/rfc2818.txt
Also, since the code in question is limiting the cacheability of
the response, what is the downside of sending the no-cache header
on secure requests?
http://en.wikipedia.org/wiki/Robustness_principle
I ask because we're seeing problems with IE8 caching these
responses where it previously did not when the headers were being
automatically appended.
While it may be a client problem, it seems like the change that
was removed was made to work around a similar client problem.
You should be able to fix this with a simple Filter of your own
design. If you need help with such a Filter, just ask.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5Tr40ACgkQ9CaO5/Lv0PAzNgCgppYy44nkb4dJ16x6D5ouq673
SE4An2eTotSm1GQ8CQH2dOAKMReNwWcJ
=Gl2e
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: How to cancel upload?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steffen, On 8/21/2011 9:21 AM, Steffen Heil (Mailinglisten) wrote: Hi Actually, I'm not entirely correct and I am now remembering this has been discussed before on either this list or the tomcat-dev list. Do you remember anything else about that thread? Something that might help me find it... ? I've been looking for it, too, since I know it's been discussed. There's this from users@ http://markmail.org/thread/vlebky5z6hl6wdjj and this from dev@ (which is more recent) http://markmail.org/thread/qpdza5qz4ziigkx5 Are you throwing an exception, or closing the inputstream? I tried to throw an exception (IOException) but it seemed tomcat would then read the stream for me. Right, Tomcat will drain the InputStream for you. That provides a nicer experience for a client that would otherwise receive a nasty error (because the server hangs up before the complete request has been made). I tried to close the inputstream I got from ServletUpload, I think I did not try to close request.getInputStream() yet. I will try. Are you able to force the clients to use Expect/Continue? Client: PUT /foo/bar HTTP/1.1 Expect: 100-continue Content-Length: 1234567890 Content-Type: image/jpeg Server: 100 Continue (or some error code) I'm not sure if you can determine merely from the headers whether or not the request is going to be valid, so this might not be an option for you. Or, you may have dumb (software) clients that can't be asked to use Expect/Continue in this way. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5TsjMACgkQ9CaO5/Lv0PDZuQCgj4/ogEJEc3FyoaYY//57LNdn hRcAoLp5hv8843erB8ZKgDwG+OLMFWX6 =LvX6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Moving init params from web.xml to context.xml
from tomcat configuration docs http://tomcat.apache.org/tomcat-7.0-doc/config/context.html You can configure named values that will be made visible to the web application as servlet context initialization parameters by nesting Parameter elements inside this element. For example, you can create an initialization parameter like this: Context ... Parameter name="companyName" value="My Company, Incorporated" override="false"/ ... /Context This is equivalent to the inclusion of the following element in the web application deployment descriptor (/WEB-INF/web.xml): context-param param-namecompanyName/param-name param-valueMy Company, Incorporated/param-value /context-param but does not require modification of the deployment descriptor to customize this value. On 08/23/2011 09:45 AM, Jeffrey Janner wrote: If it helps generate a reply, I'm deploying into Tomcat 6.0.3x running under JDK 1.6.0_2x. -Original Message- From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Sent: Monday, August 22, 2011 3:12 PM To: 'Tomcat Users List' Subject: Moving init params from web.xml to context.xml Our apps are currently deployed using a minimal context.xml file (pointer to doc-base only), with all the other information contained in the web.xml and some properties files. What I'd like to do is move as much of the customizable values out of the web.xml file and into the context.xml file to make upgrades a bit easier. Specifically, I want to move the properties files to a location that won't get overridden when new war files are deployed. Our current web.xml file is structured: web-app context-param param-nameLOG4J_PROPS/param-name param-value/WEB-INF/Log4j.properties/param-value /context-param servlet servlet-nameSERVA/servlet-name display-nameSERVA/display-name descriptionControlling servlet for A/description servlet-classcom.mycompany.webapp.serva/servlet-class init-param param-nameSERVA_PROPS/param-name param-value/WEB-INF/SERVA.properties/param-value /init-param load-on-startup1/load-on-startup /servlet servlet servlet-nameSERVB/servlet-name display-nameSERVB/display-name descriptionControlling servlet for B/description servlet-classcom.mycompany.webapp.servb/servlet-class init-param param-nameSERVB_PROPS/param-name param-value/WEB-INF/SERVB.properties/param-value /init-param load-on-startup1/load-on-startup /servlet /web-app I know from the docs that I can save move the LOG4J_PROPS to the context.xml as it is defined as a context-param. However, can I move the 2 servlet props to the context.xml file also? If so, is it the same as the log4j, or do I need to do something different? Lastly, can the session-timeout setting be located outside of the web.xml file? We customer with different requirements for this value (some misguided), and would like to make it easy for them to set it without having to update it with every deployment. Jeff ___ ___ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands,
Re: About SSO between Apache2 and Tomcat...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To whom it may concern, On 8/21/2011 7:30 AM, pushme wrote: Here's what i'd like to do: 1. User authenticates against Joomla (running on Apache). For those playing along at home, Joomla is PHP-based. Pushme, how does Joomla perform it's authentication? Presumably it's not Apache-based, but something internal to Joomla, right? 2. GWT (javascript) client side code queries the Joomla userId/sessionId/orWhateverItsCalled and passes it to the servlets at each rpc call. 3. The Servlet (running on Tomcat) asks Apache if the userId/sessionId/orWhateverItsCalled-WhatsItCalledBTW? is still valid. I would think that the servlet would have to ask Joomla about the credentials and/or session identification. The first question is: does the servlet even have access to anything like that? Is there even a cookie/request parameter going to the servlet that can be used to ask Joomla? The short question is how can this be achieved with as less effort as possible? I think you'd have to create an authentication verification service within Joomla. Perhaps one already exists (but probably not). I.e. Does this setup make sense at all? Yes, but it's awkward :) and if so, how do i have to setup Tomcat and Apache in order to allow a servlert (running on tomcat) to query Apache if a given userId/sessionId/whatever is still valid? I think you'll have to implement everything yourself. A (relatively) simple hey-Joomla-is-this-user-token-currently-valid message is all that would be needed... just call that from the servlet and read the response. If all is well, continue processing, otherwise return some appropriate error code and/or redirect the user toward whatever the login mechanism is. I don't know if this is possible at all so any information is welcome. Sure, it's possible. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5TtqkACgkQ9CaO5/Lv0PAOFwCfd8eYUDNhwV2Uw/f1ybYHL22T XlMAoIM3cirB1866oQGgOwgJk5kAVkc1 =MGiW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Multiple Tomcat Instances with Multiple IPs
I've been out for a few days; but, thanks for your input. It does seem like a firewall issue; and I've put a ticket into the right people to open up that port. When it's completed, I'll continue and see what I get. Again, thanks for your input. ___ Regards, From: chuck.caldar...@unisys.com To: users@tomcat.apache.org Date: Fri, 19 Aug 2011 15:54:47 -0500 Subject: RE: Multiple Tomcat Instances with Multiple IPs From: Vickie Troy-McKoy [mailto:vtmc...@hotmail.com] Subject: RE: Multiple Tomcat Instances with Multiple IPs When I put in the DNS name or the IP address of the newly defined interface with the correct port in the browser, I get page can not be displayed. Use netstat -ap to make sure Tomcat is listening on the IP:port you think it should be. If it is, then you might have a firewall blocking that port. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Moving init params from web.xml to context.xml
This is equivalent to the inclusion of the following element in the web application deployment descriptor (/WEB-INF/web.xml): context-param param-namecompanyName/param-name param-valueMy Company, Incorporated/param-value /context-param but does not require modification of the deployment descriptor to customize this value. That's correct but there's no way afaik to map a context parameter onto a servlet init parameter like these mentioned previously: servlet ... init-param param-nameSERVA_PROPS/param-name param-value/WEB-INF/SERVA.properties/param-value /init-param /servlet In my experience the servlet needs to search both context parameters and init parameters for initialization. M - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Moving init params from web.xml to context.xml
-Original Message- From: Marvin Addison [mailto:marvin.addi...@gmail.com] Sent: Tuesday, August 23, 2011 9:43 AM To: Tomcat Users List Subject: Re: Moving init params from web.xml to context.xml This is equivalent to the inclusion of the following element in the web application deployment descriptor (/WEB-INF/web.xml): context-param param-namecompanyName/param-name param-valueMy Company, Incorporated/param-value /context-param but does not require modification of the deployment descriptor to customize this value. That's correct but there's no way afaik to map a context parameter onto a servlet init parameter like these mentioned previously: servlet ... init-param param-nameSERVA_PROPS/param-name param-value/WEB-INF/SERVA.properties/param-value /init-param /servlet In my experience the servlet needs to search both context parameters and init parameters for initialization. M Thanks Marvin. That is what I was thinking, the two are separate entities, with separate methods of accessing them. Not being a developer, I wasn't positive though. I can get with the Dev team and see if they are willing to re-code for the possibility (or even need to). __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Need Help - Vulnerability Details
Hi, We are using *Tomcat 6.0.26* with* Windows Server 2008 R2 Enterprise *as Operating system. We performed security scan on environment and observed Apache Tomcat NIO Connector Denial of Service. Here we go with the detail description and observation:* * * * *Description:* A denial of se*r*vice vulnerability is present in some versions of Apache Tomcat. * * *Observation:* A denial of service vulnerability is present in some versions of Apache Tomcat. The vulnerability is caused by an error in the NIO connector when processing a request line. By sending a specially-crafted request. Remote attackers could exploit the vulnerability to cause an OutOfMemory error and crash the server. Will you be able to provide a patch or it’s already there then can you please point down there? Thanks and Regards, Chirag
Appropriate version of Java
Should I install an Apache Tomcat 6.0.30 server, however I have the following question, what is the appropriate version of Java for this version of Tomcat? Thank in advance any opinions or experience with it. Rafael Flórez A. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Moving init params from web.xml to context.xml
I can get with the Dev team and see if they are willing to re-code for the possibility (or even need to). It's a valuable change that dramatically increases your deployment options; well worth the effort IMO. M - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Need Help - Vulnerability Details
i think it's already release 6.0.33 now. your version 6.0.26 is quite outdated. please upgrade to the latest one. http://tomcat.apache.org/download-60.cgi --- daniel baktiar On Wed, Aug 24, 2011 at 12:39 AM, Chirag Suthar cbsut...@gmail.com wrote: Hi, We are using *Tomcat 6.0.26* with* Windows Server 2008 R2 Enterprise *as Operating system. We performed security scan on environment and observed Apache Tomcat NIO Connector Denial of Service. Here we go with the detail description and observation:* * * * *Description:* A denial of se*r*vice vulnerability is present in some versions of Apache Tomcat. * * *Observation:* A denial of service vulnerability is present in some versions of Apache Tomcat. The vulnerability is caused by an error in the NIO connector when processing a request line. By sending a specially-crafted request. Remote attackers could exploit the vulnerability to cause an OutOfMemory error and crash the server. Will you be able to provide a patch or it’s already there then can you please point down there? Thanks and Regards, Chirag
Re: Appropriate version of Java
Il 23/08/11 18:41, Rafael Giovanni Florez Arango - EyS ha scritto: Should I install an Apache Tomcat 6.0.30 server, however I have the following question, what is the appropriate version of Java for this version of Tomcat? Latest version of java 1.6 works fine form me. I am using 1.6.0_26 unde OS X (devel machine), 1.6.0_18 openjdk Debian stable in production. I did only little tests using java 1.7 on my devel machine under OS X and all goes well. You need only the JRE for Tomcat. Edoardo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Need Help - Vulnerability Details
- Original Message - From: Chirag Suthar cbsut...@gmail.com To: users@tomcat.apache.org Cc: Sent: Tuesday, August 23, 2011 9:39 AM Subject: Need Help - Vulnerability Details Hi, We are using *Tomcat 6.0.26* with* Windows Server 2008 R2 Enterprise *as Operating system. We performed security scan on environment and observed Apache Tomcat NIO Connector Denial of Service. Here we go with the detail description and observation:* * * * *Description:* A denial of se*r*vice vulnerability is present in some versions of Apache Tomcat. * * *Observation:* A denial of service vulnerability is present in some versions of Apache Tomcat. The vulnerability is caused by an error in the NIO connector when processing a request line. By sending a specially-crafted request. Remote attackers could exploit the vulnerability to cause an OutOfMemory error and crash the server. Will you be able to provide a patch or it’s already there then can you please point down there? Thanks and Regards, Chirag Read the following: http://tomcat.apache.org/security-6.html In particular: Important: Remote Denial Of Service CVE-2011-0534 This was fixed in 6.0.32. The current version 6.0.33. . . . . just my two cents. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Cache-Control headers not being added to secure requests
Chris,
Doesn't the entire securePagesWithPragma flag fail the robustness principle?
It's specifically there to fix caching issues with IE, similar to the issue
we're now seeing.
I understand how I would create a Filter to do this, but I'm trying to
understand why this behavior was removed from Tomcat itself, while other IE
specific logic remains.
It seems as though the kernel of logic here is that 'pages with
security-constraints' should have these headers automatically added.
There should be a specific reason to add the additional isSecure() check.
For example, there is a clear reason the POST check was added.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10
But I cannot find a similar argument for checking isSecure
Thanks,
Michael
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, August 23, 2011 6:48 AM
To: Tomcat Users List
Subject: Re: Cache-Control headers not being added to secure requests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael,
On 8/22/2011 5:39 PM, Zampani, Michael wrote:
However, I'm still confused about
- {request.isSecure()} means that the headers are only added if the
request is not secure since responses from secure requests must not
be cached
I don't see anything regarding secure requests in RFC2616
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.4 or
RFC2818 http://www.ietf.org/rfc/rfc2818.txt
Also, since the code in question is limiting the cacheability of the
response, what is the downside of sending the no-cache header on
secure requests?
http://en.wikipedia.org/wiki/Robustness_principle
I ask because we're seeing problems with IE8 caching these responses
where it previously did not when the headers were being automatically
appended.
While it may be a client problem, it seems like the change that was
removed was made to work around a similar client problem.
You should be able to fix this with a simple Filter of your own design. If you
need help with such a Filter, just ask.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5Tr40ACgkQ9CaO5/Lv0PAzNgCgppYy44nkb4dJ16x6D5ouq673
SE4An2eTotSm1GQ8CQH2dOAKMReNwWcJ
=Gl2e
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Moving init params from web.xml to context.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeffrey, On 8/23/2011 12:38 PM, Jeffrey Janner wrote: Thanks Marvin. That is what I was thinking, the two are separate entities, with separate methods of accessing them. Not being a developer, I wasn't positive though. I can get with the Dev team and see if they are willing to re-code for the possibility (or even need to). One option is to modify your servlets' base class to override getInitParameter (and friends) to also search the context parameters. You could even use a servlet-name prefix for your context-param to avoid collisions. If you don't have a servlet base class... you should :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5T+ScACgkQ9CaO5/Lv0PCLfQCguxuL2SjVgquZPtZ69zkB6+lA GbcAn0LHiOTEqvTrTc9T1wuzgOy1SdUF =S2iG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cache-Control headers not being added to secure requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael, On 8/23/2011 2:09 PM, Zampani, Michael wrote: It seems as though the kernel of logic here is that 'pages with security-constraints' should have these headers automatically added. There should be a specific reason to add the additional isSecure() check. I believe Mark's argument was that web browsers are violating the some spec if they cache secure pages. Tomcat should not have to set such cache-control headers for secure requests, so it's being instructed not to do so. The fact that RFC 2616 does not mention anything about HTTPS and caching is not surprising -- it's the HTTP RFC not the HTTPS RFC. Honestly, I couldn't find anywhere a reference to any spec that explicitly says what Mark suggests, but it was my general understanding to be the case. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5T+zkACgkQ9CaO5/Lv0PByKACfZli2aoRMAAaRjATrk+F/0fuc WWAAnjj4duJJm5RtcwYgtz/vuADU5VEp =QOZa -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
jvmRoute generation
I'm working on putting together a clustered environment with sticky sessions, and I'm wondering if there's any way of automatically generating a jvmRoute value in the engine container (https://tomcat.apache.org/tomcat-7.0-doc/config/engine.html) rather than setting one manually for each Tomcat instance. Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cache-Control headers not being added to secure requests
On 23/08/2011 19:09, Zampani, Michael wrote: Chris, Doesn't the entire securePagesWithPragma flag fail the robustness principle? It's specifically there to fix caching issues with IE, similar to the issue we're now seeing. I understand how I would create a Filter to do this, but I'm trying to understand why this behavior was removed from Tomcat itself, while other IE specific logic remains. It seems as though the kernel of logic here is that 'pages with security-constraints' should have these headers automatically added. There should be a specific reason to add the additional isSecure() check. For example, there is a clear reason the POST check was added. http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 But I cannot find a similar argument for checking isSecure The isSecure() check pre-dates my involvement with the project. I did some digging and this is the reason: http://svn.apache.org/viewvc?view=revisionrevision=287690 https://issues.apache.org/bugzilla/show_bug.cgi?id=6641 It looks very much like a work-around for an IE bug, almost certainly the same one that securePagesWithPragma is intended to fix. On that basis, I'm not against removing the request.isSecure() check. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jvmRoute generation
On 23/08/2011 20:22, Andrew Todd wrote: I'm working on putting together a clustered environment with sticky sessions, and I'm wondering if there's any way of automatically generating a jvmRoute value in the engine container (https://tomcat.apache.org/tomcat-7.0-doc/config/engine.html) rather than setting one manually for each Tomcat instance. Thanks. No. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jvmRoute generation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew,
On 8/23/2011 3:22 PM, Andrew Todd wrote:
I'm working on putting together a clustered environment with
sticky sessions, and I'm wondering if there's any way of
automatically generating a jvmRoute value in the engine container
(https://tomcat.apache.org/tomcat-7.0-doc/config/engine.html)
rather than setting one manually for each Tomcat instance. Thanks.
You should be able to use a parametric replacement using a system
property. That way, the file is the same across all installations but
the system property can be set locally.
Something like this:
Engine name=Catalina
defaultHost=localhost
jvmRoute=${jvmRoute}
Then start Tomcat with CATALINA_OPTS=-DjvmRoute=galdalf or whatever.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5UBi4ACgkQ9CaO5/Lv0PAG4ACfayQFX87SJ2PAYPnrC5JpTm3W
tw8An07LwnoWs3kNpXyTdSqgZcOYTibI
=siWU
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, July 26, 2011 6:15 PM To: Tomcat Users List Subject: Re: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32 Konstantin, Such a class would definitely be useful to post on the Wiki. Hi Christopher, Some days ago I made an entry in the Tomcat Wiki with such a OutputStream decorator class: http://wiki.apache.org/tomcat/FAQ/KnownIssues#ImageIOIssues I see that you changed the flush() method in the decorator class to pass flush() calls to the underlying stream as long as the stream is set to be active. The reason that I didn't make this call-through was because it seems that flush() is the only method called by the ImageIO (when the Image Writer is garbage collected), and by preventing any pass-through of flush(), no errors can occur. When flush() of the decorator class passes its call to the original stream as long as it's active, there may be a race condition between the request processing thread of the Servlet and the GC thread which collects the Image Writer, which possibly (but highly unlikely) could cause a flush() call (from GC thread) on the already closed stream, even if the isActive flag is volatile (please correct me if I'm wrong - I'm not a expert in how GC is working). Also, it seems that ImageIO is calling flush() a few times while writing an image, and I wanted to avoid the unnecessary flush() calls. ;-) Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Choosing an AJP Connector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I've been using Tomcat fronted by Apache httpd (terminating SSL I might add) for years and I've never given any thought to which flavor of AJP connector I've been using. We don't build APR as part of our standard build process and it's unclear from the docs but I suspect you don't get NIO unless you specify that you want it. I guess that means I've been stuck in BIO-ville all this time. We're looking to upgrade to TC7 soon so I will have 3 options, now. I'm wondering which one would be best for us. - From my perspective, the most useful thing you get from both APR and NIO is the ability to service more simultaneous requests than you actually have threads, because of their polling capabilities. That also means that a slow client won't tie-up a thread for a long time. But, since I'm using AJP, there is a one-to-one relationship between request processors at the httpd level and in Tomcat, so being able to handle more requests doesn't sound like it's buying me anything. I'm not sure how HTTP keepalives fit into all this, but I suspect that mod_jk takes care of this and Tomcat has little to no control over any of it. So, what does either AJP or NIO buy me in an AJP environment? We have no notable performance problems that do not involve obvious application slowness, so BIO has been working fine for us. I'm inclined to stick with it unless there are some compelling reasons to switch. Any thoughts? Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5UD4EACgkQ9CaO5/Lv0PALqgCdFwCB4A5LAEnsXHkxfiGBpcYp I/UAnjfmzAlqhTq5XMOWY9nOUvrJe4bd =VQJI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Cache-Control headers not being added to secure requests
Wonderful! Should I file a bug report for this? It's only a 1 line diff. Thanks, Michael -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, August 23, 2011 12:49 PM To: Tomcat Users List Subject: Re: Cache-Control headers not being added to secure requests On 23/08/2011 19:09, Zampani, Michael wrote: Chris, Doesn't the entire securePagesWithPragma flag fail the robustness principle? It's specifically there to fix caching issues with IE, similar to the issue we're now seeing. I understand how I would create a Filter to do this, but I'm trying to understand why this behavior was removed from Tomcat itself, while other IE specific logic remains. It seems as though the kernel of logic here is that 'pages with security-constraints' should have these headers automatically added. There should be a specific reason to add the additional isSecure() check. For example, there is a clear reason the POST check was added. http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 But I cannot find a similar argument for checking isSecure The isSecure() check pre-dates my involvement with the project. I did some digging and this is the reason: http://svn.apache.org/viewvc?view=revisionrevision=287690 https://issues.apache.org/bugzilla/show_bug.cgi?id=6641 It looks very much like a work-around for an IE bug, almost certainly the same one that securePagesWithPragma is intended to fix. On that basis, I'm not against removing the request.isSecure() check. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Choosing an AJP Connector
On 23/08/2011 21:37, Christopher Schultz wrote: All, I've been using Tomcat fronted by Apache httpd (terminating SSL I might add) for years and I've never given any thought to which flavor of AJP connector I've been using. We don't build APR as part of our standard build process and it's unclear from the docs but I suspect you don't get NIO unless you specify that you want it. I guess that means I've been stuck in BIO-ville all this time. We're looking to upgrade to TC7 soon so I will have 3 options, now. I'm wondering which one would be best for us. From my perspective, the most useful thing you get from both APR and NIO is the ability to service more simultaneous requests than you actually have threads, because of their polling capabilities. That also means that a slow client won't tie-up a thread for a long time. But, since I'm using AJP, there is a one-to-one relationship between request processors at the httpd level and in Tomcat, so being able to handle more requests doesn't sound like it's buying me anything. I'm not sure how HTTP keepalives fit into all this, but I suspect that mod_jk takes care of this and Tomcat has little to no control over any of it. Not quite correct. With BIO it is one thread/processor per connection. With NIO/APR it is one thread per currently processing request (i.e connections in keep-alive (HTTP or AJP) do not require a thread or processor). So, what does either AJP or NIO buy me in an AJP environment? In short, NIO APR will scale better. We have no notable performance problems that do not involve obvious application slowness, so BIO has been working fine for us. I'm inclined to stick with it unless there are some compelling reasons to switch. Any thoughts? If it ain't broke... Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cache-Control headers not being added to secure requests
On 23/08/2011 21:40, Zampani, Michael wrote: Wonderful! Should I file a bug report for this? It's only a 1 line diff. Please do. Please also include the various references in this thread so folks coming to this later have the full info. Mark Thanks, Michael -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, August 23, 2011 12:49 PM To: Tomcat Users List Subject: Re: Cache-Control headers not being added to secure requests On 23/08/2011 19:09, Zampani, Michael wrote: Chris, Doesn't the entire securePagesWithPragma flag fail the robustness principle? It's specifically there to fix caching issues with IE, similar to the issue we're now seeing. I understand how I would create a Filter to do this, but I'm trying to understand why this behavior was removed from Tomcat itself, while other IE specific logic remains. It seems as though the kernel of logic here is that 'pages with security-constraints' should have these headers automatically added. There should be a specific reason to add the additional isSecure() check. For example, there is a clear reason the POST check was added. http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 But I cannot find a similar argument for checking isSecure The isSecure() check pre-dates my involvement with the project. I did some digging and this is the reason: http://svn.apache.org/viewvc?view=revisionrevision=287690 https://issues.apache.org/bugzilla/show_bug.cgi?id=6641 It looks very much like a work-around for an IE bug, almost certainly the same one that securePagesWithPragma is intended to fix. On that basis, I'm not against removing the request.isSecure() check. 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: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 8/23/2011 4:02 PM, Konstantin Preißer wrote: I see that you changed the flush() method in the decorator class to pass flush() calls to the underlying stream as long as the stream is set to be active. The reason that I didn't make this call-through was because it seems that flush() is the only method called by the ImageIO (when the Image Writer is garbage collected), and by preventing any pass-through of flush(), no errors can occur. When flush() of the decorator class passes its call to the original stream as long as it's active, there may be a race condition between the request processing thread of the Servlet and the GC thread which collects the Image Writer, which possibly (but highly unlikely) could cause a flush() call (from GC thread) on the already closed stream, even if the isActive flag is volatile (please correct me if I'm wrong - I'm not a expert in how GC is working). I added the flush() pass-through in case you actually wanted to flush the stream. It seems reasonable that you might want to flush the buffer at some point, and turning flush() into a no-op didn't seem like a good idea. I would expect the image writer to be available for GC after the request was processed, but I guess the request could have operations after the ImageIO is actually done and you're right: the GC could kick-in virtually at any time. If you use your wrapper class as a fire-and-forget kind of thing while maintaining the original reference to the OutputStream, I suppose you still have complete control over flushing that underlying stream. Also, it seems that ImageIO is calling flush() a few times while writing an image, and I wanted to avoid the unnecessary flush() calls. ;-) That's a different story :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5UEXkACgkQ9CaO5/Lv0PCiNQCgu1foU5uwo63iExja+Wf+WPys 8iIAoJRaIucq9losxjKp0kkhUs6ycZYj =HDoE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jvmRoute generation
On Tue, Aug 23, 2011 at 3:57 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
You should be able to use a parametric replacement using a system
property. That way, the file is the same across all installations but
the system property can be set locally.
Something like this:
Engine name=Catalina
defaultHost=localhost
jvmRoute=${jvmRoute}
Then start Tomcat with CATALINA_OPTS=-DjvmRoute=galdalf or whatever.
Thanks, I'm sure that's probably useful for someone, but for now it's
easier for me just to run server.xml through sed during deployment and
generate a random jvmRoute value.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Choosing an AJP Connector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 8/23/2011 4:43 PM, Mark Thomas wrote: On 23/08/2011 21:37, Christopher Schultz wrote: But, since I'm using AJP, there is a one-to-one relationship between request processors at the httpd level and in Tomcat, so being able to handle more requests doesn't sound like it's buying me anything. I'm not sure how HTTP keepalives fit into all this, but I suspect that mod_jk takes care of this and Tomcat has little to no control over any of it. Not quite correct. With BIO it is one thread/processor per connection. With NIO/APR it is one thread per currently processing request (i.e connections in keep-alive (HTTP or AJP) do not require a thread or processor). Aah, that's a not-so-subtle detail that I seem to have missed: I can (might be able to) handle more connections from httpd with fewer threads on the Tomcat side. So, what does either AJP or NIO buy me in an AJP environment? In short, NIO APR will scale better. Gotcha. Any opinions on APR versus NIO? APR can do more damage if it dies by taking-down the JVM but the NIO connector is less mature and might be (slightly) buggier. We have no notable performance problems that do not involve obvious application slowness, so BIO has been working fine for us. I'm inclined to stick with it unless there are some compelling reasons to switch. Any thoughts? If it ain't broke... I'm kinda thinking that way. It's not like I'm having to serve so much traffic that I'm thrashing my threads or anything. On the other hand, it might not be a bad idea to avoid such problems in the future by planning for them, now. Our usage is only increasing over time. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5UEo4ACgkQ9CaO5/Lv0PD+qQCgsYpC+QcnB/EGZ+s+b5JsM/FJ 4k8An37vHuJe1mNkFsco7uBHiJU/VQAk =Wi/m -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Choosing an AJP Connector
On 23/08/2011 21:50, Christopher Schultz wrote: Mark, On 8/23/2011 4:43 PM, Mark Thomas wrote: On 23/08/2011 21:37, Christopher Schultz wrote: But, since I'm using AJP, there is a one-to-one relationship between request processors at the httpd level and in Tomcat, so being able to handle more requests doesn't sound like it's buying me anything. I'm not sure how HTTP keepalives fit into all this, but I suspect that mod_jk takes care of this and Tomcat has little to no control over any of it. Not quite correct. With BIO it is one thread/processor per connection. With NIO/APR it is one thread per currently processing request (i.e connections in keep-alive (HTTP or AJP) do not require a thread or processor). Aah, that's a not-so-subtle detail that I seem to have missed: I can (might be able to) handle more connections from httpd with fewer threads on the Tomcat side. Exactly. So, what does either AJP or NIO buy me in an AJP environment? In short, NIO APR will scale better. Gotcha. Any opinions on APR versus NIO? APR can do more damage if it dies by taking-down the JVM but the NIO connector is less mature and might be (slightly) buggier. Not really. The code between all the connectors is getting more similar as I reduce the duplication. That should mean fewer bugs/inconsistencies and simpler fixes when a bug is discovered. Given the monthly release cycle of 7.0.x (assuming it continues) then any bug that can be reproduced is going to get fixed pretty quickly. We have no notable performance problems that do not involve obvious application slowness, so BIO has been working fine for us. I'm inclined to stick with it unless there are some compelling reasons to switch. Any thoughts? If it ain't broke... I'm kinda thinking that way. It's not like I'm having to serve so much traffic that I'm thrashing my threads or anything. On the other hand, it might not be a bad idea to avoid such problems in the future by planning for them, now. Our usage is only increasing over time. Better to test NIO or APR while you can go back to BIO and get any issues fixed now. Easier than waiting until you need NIO or APR to find out there is a bug that breaks things for your site. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: jvmRoute generation
-Original Message-
From: Andrew Todd [mailto:andrew.todd...@gmail.com]
Sent: Tuesday, August 23, 2011 3:50 PM
To: Tomcat Users List
Subject: Re: jvmRoute generation
On Tue, Aug 23, 2011 at 3:57 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
You should be able to use a parametric replacement using a system
property. That way, the file is the same across all installations but
the system property can be set locally.
Something like this:
Engine name=Catalina
defaultHost=localhost
jvmRoute=${jvmRoute}
Then start Tomcat with CATALINA_OPTS=-DjvmRoute=galdalf or
whatever.
Thanks, I'm sure that's probably useful for someone, but for now it's
easier for me just to run server.xml through sed during deployment and
generate a random jvmRoute value.
Why on God's Green Earth would you want a random jvmRoute value?
After all, you have to put all values used in the config for the web server
directing the traffic.
Use that wonderful computer you were given on your birthday and either generate
your own random value, and keep track of it, or come up with some easily
documented naming scheme.
__
Confidentiality Notice: This Transmission (including any attachments) may
contain information that is privileged, confidential, and exempt from
disclosure under applicable law. If the reader of this message is not the
intended recipient you are hereby notified that any dissemination,
distribution, or copying of this communication is strictly prohibited.
If you have received this transmission in error, please immediately reply to
the sender or telephone (512) 343-9100 and delete this transmission from your
system.
Re: jvmRoute generation
On Tue, Aug 23, 2011 at 5:08 PM, Jeffrey Janner jeffrey.jan...@polydyne.com wrote: Why on God's Green Earth would you want a random jvmRoute value? I'm new at this, explain to me why I wouldn't. I have to deploy to a cluster, and my understanding is that the Apache front-end server doesn't care about the value of jvmRoute. Generating a value at deployment time therefore seemed like the easiest way of doing this. I could just as easily generate a more predictable value from the hostname, but I'm not sure of the benefits or considerations of that choice, either. If I'm wrong, well -- that's why I'm asking on this mailing list. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Choosing an AJP Connector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 8/23/2011 4:59 PM, Mark Thomas wrote: [The NIO code is ]not really [any less robust]. The code between all the connectors is getting more similar as I reduce the duplication. That should mean fewer bugs/inconsistencies and simpler fixes when a bug is discovered. I've been seeing all that code merge and it's nice to have it happen. Thanks for your great (but probably relatively un-rewarding) work in this area. Better to test NIO or APR while you can go back to BIO and get any issues fixed now. Easier than waiting until you need NIO or APR to find out there is a bug that breaks things for your site. Sure. Testing with NIO is as simple as changing the protocol attribute. Can't beat that for plug-and-play configuration. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5UGvYACgkQ9CaO5/Lv0PAIfgCeKXNPZ/B2NqHTYnNs/OtbV48y EPwAnRuMgeVV6C0zKlQNKzm92Bc6J+3s =uNY+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jvmRoute generation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew,
On 8/23/2011 4:49 PM, Andrew Todd wrote:
On Tue, Aug 23, 2011 at 3:57 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
You should be able to use a parametric replacement using a
system property. That way, the file is the same across all
installations but the system property can be set locally.
Something like this:
Engine name=Catalina defaultHost=localhost
jvmRoute=${jvmRoute}
Then start Tomcat with CATALINA_OPTS=-DjvmRoute=galdalf or
whatever.
Thanks, I'm sure that's probably useful for someone, but for now
it's easier for me just to run server.xml through sed during
deployment and generate a random jvmRoute value.
Uh... you want a completely random jvmRoute?
That needs to be in sync with your mod_jk configuration, so how are
you doing that?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5UGzEACgkQ9CaO5/Lv0PAqlACggcwMRUfyuwl5S7AFtNCeb6X4
ijcAnRTspbswpyPLrrj3GKdDpW8dfTUY
=ePNF
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jvmRoute generation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew, On 8/23/2011 5:25 PM, Andrew Todd wrote: On Tue, Aug 23, 2011 at 5:08 PM, Jeffrey Janner jeffrey.jan...@polydyne.com wrote: Why on God's Green Earth would you want a random jvmRoute value? I'm new at this, explain to me why I wouldn't. I have to deploy to a cluster, and my understanding is that the Apache front-end server doesn't care about the value of jvmRoute. If you are using sticky sessions, then it is vital to the operation of your cluster that the jvmRoutes be set with care and configured in the web server to match the individual Tomcat instances. If you aren't using sticky sessions, then you can eliminate the jvmRoute because it doesn't matter which back-end server the requests go to. Generating a value at deployment time therefore seemed like the easiest way of doing this. I could just as easily generate a more predictable value from the hostname, but I'm not sure of the benefits or considerations of that choice, either. You could also set it to but I recently found out that gives you an empty jvmRoute, not a non-existent one. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5UHCsACgkQ9CaO5/Lv0PDwyQCfbBMxQcfi8WCXbjjyP+c4oAG6 eQoAoLPKUp7MXfjg1SfxB0u2M78Jq+GM =I58I -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: How to handle the AWT-Windows thread?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, On 8/21/2011 4:53 AM, Pid wrote: On 21/08/2011 01:19, Christopher Schultz wrote: I'm not sure how one would intercept the call, though. I've never looked into it, but I would guess that Toolkit.getDefaultToolkit can be configured to return an object of a different class -- one that would presumably temporarily set the CCL to the system ClassLoader. Hmm. Modifying the loadClass(str) method might suffice, on the basis that a call to load Toolkit.class is likely to result in a Toolkit.getDefaultToolkit() - rather than trying to intercept the method call. Meh. Explicit configuration beats guessing IMHO. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5UHG8ACgkQ9CaO5/Lv0PBPXwCglxYZHLmcnQb4eRyvwmFZ4H4l kSYAn184s7Mmm1Jr9yrj7FSRmdAfPUbi =mXUj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Conditional Branch from Servlet to URL
I have a book on Tomcat. In a section entitled, Forwarding HTTP Requests reference is made to the fact that sometimes it's desirable to branch form a servlet to an alternative URL upon the occurrence of some condition such as encountering an exception. The book provides the following sample code for accomplishing the branch: RequestDispatcher rd = request.getRequestDispatcher(/alternative_url) if (rd != null) rd.forward(request, response); I can't get the above code to work. At compile time I get 3 cannot-find-symbol errors. The 3 symbols that can't be found are getRequestDispatcher, request, and response. I'm not at all surprised about the request and response symbols as they appear to be undefined. I really expected that getRequestDispatcher would have been found in javax.servlet.* which is imported. Can someone please tell me what I am missing or point me to some detailed documentation which fill in the blanks so that I can get this thing to work? Thanks for any input. ... doug
RE: Conditional Branch from Servlet to URL
From: Donald Jolley [jolleyt...@gmail.com] Subject: Conditional Branch from Servlet to URL I'm not at all surprised about the request and response symbols as they appear to be undefined. I really expected that getRequestDispatcher would have been found in javax.servlet.* which is imported. ... doug * Shouldn't you import javax.servlet.http ? If your request and response objects are undefined - wish we could see how you declared them, how can RequestDispatcher perform the forward? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Apache_Tomcat]: $CATALINA_HOME/webapps/host-manager/manager.xml
Thanks Mark, that's exactly the answer I want
Mark Thomas wrote:
On 23/08/2011 10:12, quanba wrote:
Hi there,
I am a newbie to Apache Tomcat. While studying the host-manager
application,
I found the file $CATALINA_HOME/webapps/host-manager/manager.xml. This
file
seems to be the configuration file for the manager application (not the
host-manager):
Context docBase=${catalina.home}/webapps/manager .../
I wonder what the file is used for? I tried to configure the file but
neither manager application nor host-manager application is affected.
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/manager/host/HostManagerServlet.java?view=annotate
Start around line 400.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
View this message in context:
http://old.nabble.com/-Apache_Tomcat-%3A-%24CATALINA_HOME-webapps-host-manager-manager.xml-tp32317403p32323592.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
