Re: [error] (32)Broken pipe: ajp_ilink_send(): send failed
Sehyia Jalaludheen wrote: Hi Chuck, Thanks for the quick reply. I am not sure about it. But a few other machines in the same network also have the same Login issues for this application. Thanks Sehiya On Mon, Oct 6, 2008 at 11:39 AM, Caldarale, Charles R [EMAIL PROTECTED] wrote: From: Sehyia Jalaludheen [mailto:[EMAIL PROTECTED] Subject: [error] (32)Broken pipe: ajp_ilink_send(): send failed This happens only when I am logging into the application after a few days inactivity. Login fails in the first three or four attempts and then the login is successful. Any chance the target system has gone into some form of sleep mode and takes a while to wake back up? - Chuck This typically happens to us in the following scenario : - Apache connected to back-end Tomcat via mod_jk - make some requests that are proxied to Tomcat via mod_jk - stop and restart Tomcat, but not Apache - make some new requests that are proxied to Tomcat the first few requests are unsuccesful, and after that everything starts working again. For lack of real knowlede about the underlying mechanism, I interpret this as follows (and sorry for the unprecise language) : somehow some instances of mod_jk stay alive after some requests have been processed, even if one stops and restarts Tomcat, and these instances remember their previous Tomcat connection. When new requests are processed after the Tomcat restart, these mod_jk instances still try to access the old Tomcat and fail. Only when these old instances of mod_jk have been replaced by new instances (which establish new connections to the new Tomcat) does the connection work again. If one always restarts Apache after restarting Tomcat, the above phenomenon does not occur. I know this is an ad-hoc explanation, on the base of the symptoms only, and would welcome an informed one. I would also welcome a work-around if any exits, other than also restarting Apache. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross Context Session in Tomact
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maciej, Bajolek, Maciej wrote: Basically the problem is: how can webAppA share the session object with webAppB. Both apps are deployed within the same instance of Tomact. The servlet specification (section 7.3) specifies that session scope is limited to a single web application, and specifically says that session objects (or their contents) must never be shared between applications. Given this, I don't think Tomcat itself is going to help you out, here. A simple example of how I want it to work is: http://localhost/webappa/setSessionAttr.jsp - sets session attr to value http://localhost/webappa/getSessionAttr.jsp - gets session attr ... and the attribute is set to value This ought to work without any problems. It's when you want: http://localhost/webappb/getSessionAttr.jsp ... to read the stuff set in webappa/setSessionAttr.jsp that it won't work. The only solutions I can think of are: 1. Implement custom SessionManager that stores/reads session objects in some common repository e.g.: shared library (common classloader) This would work, but is fraught with difficulty because you have to worry about releasing memory when you are finished with it. 2. implement some listeners for all applications that will notify each other when session is created/destroyed or attrs set/unset This is similar to #2 because you still need to store everything somewhere. This certainly is a tough problem. :( My grain of (Tomcat- and Java-level incompetent) salt : Maybe you need to step back a bit from the idea of sharing session data directly at the Tomcat session level. What is it really that you need to share in these two applications ? is it simply a user login, and maybe some linked user login level data ? If yes, then maybe you could solve this at the application level by setting a cookie, with either the common data just stored in it or a key to some back-end store containing the data common to the two webapps. Each application would then have to check for the (common) cookie, and if found retrieve the common data first of all; if not re-direct the call to a login page. As long as both applications run on hosts within the same domain, that should not be a problem. What I mean is that Tomcat has an embedded session mechanism which is nice and handy when you can use it, but in your case you cannot. So maybe you have to think about how you would resolve this issue if this was not running under Tomcat in the first place. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to avoid multiple requests from the same client
thanks chris, this may bee what i've been looking for, since we do use user sessions already. we're running the site (with slight differences) on internet and intranet, so we could tell our users to wait until response, but would be quite difficult to tell our customers ;) we're working on the performance in general too, but we would have to decrease the functunality, to make it really performance friendly. thank you all for your answers, have a nice day colin Christopher Schultz-2 wrote: Colin, what is it that is taking so long in your page requests? Are your users being asked /not/ to re-load pages when they take a long time to load? Are you using user sessions in your application? If so, you could write a filter to store a token in the session during processing of a request. If you get another request and the session holds that token, you can refuse to process the (additional) request. Just be aware that you have to clean that token up eventually or else the user might get stuck until their session times out. - -chris -- View this message in context: http://www.nabble.com/how-to-avoid-multiple-requests-from-the-same-client-tp19836189p19852981.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using tomcat to hold many open connections.
Original post : quote Hi. I'm looking for a server that has to hold many (web services) remote clients for controlling them. I want to do things like sending power off command to a bunch of machines remotely. The clients are usually windows machines behind firewalls NAT or web proxies that only allow HTTP (this is why I thought of webservices) The regular request-response fashion that servlet follows is not suitable here since the initiator of the operation is the server. What can I do in order to solve this and still use web services? unquote I'm not really competent to opinionate on whether Tomcat can do this or not, but going back to the original description of the problem, apart from the fact (maybe) that the clients are only accessible via port 80, I must say that I don't really see what this has to do with Tomcat, or any standard HTTP server for that matter. On the client side (the machines to stop), it looks like you would need some process listening on port 80, able to interpret a limited set of commands and do something local (stop/start a motor ?). On the server side, you probably want some easy interface allowing you to send such commands to the many clients, efficiently and fast. (I quote the client and server terms because I'm not quite sure which is which here). So I guess yes, to stop yourself from re-inventing the wheel, you could use webservers on both sides as containers for this application, and you could implement some kind of Web Service to do this, but isn't this a bit heavy ? I mean that if you have a Tomcat on the client side, most of the time sitting idle and just wating for the occasional request for doing something, it is going to take quite a while for it to wake up when it receives this single request, and to process it if it comes in a SOAP envelope. And if your server each time has to wait for each client to acknowledge the request before going on to the next one, it will take it a while to loop through all clients. But then, maybe speed is not the issue here. It's just that you were talking about powering off a bunch of machines. I hope this has nothing to do with preventing a nuclear war or so. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing Tomcat 6 threads : How to make tomcat destroy threads when idle?
I am also facing the same issue. Btw, do you know how to find these configuration values and more importantly the number of 'available' worker threads within a servlet? Thanks, Madhav On Tue, Oct 7, 2008 at 4:12 AM, Rohan Sahgal [EMAIL PROTECTED] wrote: Hi, I tried increasing the number of tomcat threads. However, I cannot get tomcat to destroy the threads once they get created even though tomcat is idle. I have modified my connector as follows :- Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 maxThreads=2000 minSpareThreads=20 maxSpareThreads=100 redirectPort=8443 / However I have observed that once 2000 threads are created (I am monitoring with jconsole), the number never comes down. The minSpareThreads and maxSpareThreads are ignored. I could not find their mention in the tomcat docs either, but this was something I found on a blog post for Tomcat 5.x. Is there a way to make tomcat reduce the number of threads? Appreciate all the help. Thanks, Rohan -- -Madhav
Re: Deploying to a subfolder
McEahern, Mark S wrote: -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Sunday, October 05, 2008 1:41 PM To: Tomcat Users List Subject: Re: Deploying to a subfolder I can repeat this now. It looks like I missed this combination in my testing. I'll get it fixed for 6.0.19+ Mark Awesome, thanks for looking into that. Do you have an ETA for that release? I am afraid not. However, the patch is a simple one. If you need the fix in a hurry, you could with a local pacth. Shout if you want/need the steps to do this. That would be very helpful, thanks! The short version: 1. install an svn client (I like tortoise svn) 2. Checkout http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_18/ 3. cd where/you/placed/the/checkout 4. ant download 5. ant This gives you a local 6.0.18 build 6. use tortoise to merge revision 702208 from http://svn.apache.org/repos/asf/tomcat/trunk/ (right-click on your checkout dir - tortoise svn - merge - range=702208,url=http://svn.apache.org/repos/asf/tomcat/trunk/) 7. ant This gives you a local 6.0.18 build plus the patch You can then do one of the following: - just use this build - use replace catalina.jar in 6.0.18 with the one you just built - copy output\classes\org\apache\catalina\startup\ContextConfig.class to CATALINA_BASE\lib\org\apache\catalina\startup\ContextConfig.class I tend to do the last one so it is clear what is 'pure' 6.0.18 and what i have changed. More detail on building Tomcat: http://tomcat.apache.org/tomcat-6.0-doc/building.html HTH, Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing Tomcat 6 threads : How to make tomcat destroy threads when idle?
Rohan Sahgal wrote: I tried increasing the number of tomcat threads. However, I cannot get tomcat to destroy the threads once they get created even though tomcat is idle. However I have observed that once 2000 threads are created (I am monitoring with jconsole), the number never comes down. The minSpareThreads and maxSpareThreads are ignored. Correct - those parameters have no effect. I could not find their mention in the tomcat docs either, but this was something I found on a blog post for Tomcat 5.x. Tomcat 5.x is not Tomcat 6.x. There are differences and this is one of them. Is there a way to make tomcat reduce the number of threads? Sorry, no. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing Tomcat 6 threads : How to make tomcat destroy threads when idle?
Madhav wrote: I am also facing the same issue. Btw, do you know how to find these configuration values and more importantly the number of 'available' worker threads within a servlet? Take a look at how the manager app does it for the status page. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: hello world
hey guys, i just loaded onto a system with a old harddrive a replacement (different kind of motherboard) and updated/installed a new fedora 9.2 version but cannot get a password to work and all of the user names have been changed.. any ideas how to get from the main on site console root access? On Thu, 18 Sep 2008, Caldarale, Charles R wrote: From: news [mailto:[EMAIL PROTECTED] On Behalf Of thufir Subject: hello world I'm running Ubuntu: [EMAIL PROTECTED]:~$ I thought mentats weren't supposed to use computers... Do I need to install Tomcat 5.5 from Ubuntu We've had no end of problems with 3rd-party repackaged versions of Tomcat. I'd strongly recommend you throw that one away, then download and install a real Tomcat from tomcat.apache.org (latest version recommended, of course). Otherwise, perhaps Ubuntu support could help. - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cannot seem to see deployed application
cooper5114 wrote: Apache Tomcat/5.5.26 OS = RH ES 5 Is this a clean Tomcat install from an Apache tar.gz distro or are you using RedHat packages? Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Exception when deploying with VirtualWebappLoader
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm trying to use the VirtualWebappLoader in Tomcat 6.0.18 to add a directory to the classpath, but get a strange exception. The context definition looks like this: Context Loader className=org.apache.catalina.loader.VirtualWebappLoader virtualClasspath=/home/marcus/webapps/conf / !-- some Resource elements left out --- /Context When deploying the WAR file together with the above context definition using the manager Ant task, I get the following: 2008-okt-07 15:05:27 org.apache.catalina.core.StandardContext processTlds ALLVARLIG: Error reading tld listeners java.lang.IllegalArgumentException: URI has an authority component java.lang.IllegalArgumentException: URI has an authority component at java.io.File.init(File.java:385) at org.apache.catalina.startup.TldConfig.getJarPaths(TldConfig.java:701) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:277) at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4448) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4248) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:627) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:511) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1231) Any ideas what I'm missing? Cheers, Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjrYmkACgkQXjXn6TzcAQlPtACfT42atj3YF6tM8KGeAeOxI3C9 BqsAnR5gO5sgRZk69HjkM62sG0wH+/zK =rU3L -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cannot seem to see deployed application
cooper5114 wrote: I'm very new to Tomcat so bear with me. I ran into a problem where i couldn't access an application (x.war) that i copied to Tomcat's webapps directory. I verified the $CATALINA_HOME env variable points to that tomcat. The ip address/port are fine, etc. I can get to the default Tomcat home page. Any suggestions how to debug this? There is only one copy of tomcat running. So in trying to figure out what was going on, i edited the webapps/ROOT/index.jsp page to verify that it would change. It didn't. So i figured it must be cached, so i killed my browser, restarted. No change. I also deleted $CATALINA_HOME/work directory (which i believe is used for caching). No change Any clues? Tomcat version? OS version? JDK version? Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing Tomcat 6 threads : How to make tomcat destroy threads when idle?
Hi Rohan, at tomcat 6 you must use an external executor thread pool to decrease idle threads: Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=2000 minSpareThreads=20/ Connector executor=tomcatThreadPool port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Look at http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html Executor drop idle threads after one minute. Peter Am 07.10.2008 um 10:29 schrieb Mark Thomas: Rohan Sahgal wrote: I tried increasing the number of tomcat threads. However, I cannot get tomcat to destroy the threads once they get created even though tomcat is idle. However I have observed that once 2000 threads are created (I am monitoring with jconsole), the number never comes down. The minSpareThreads and maxSpareThreads are ignored. Correct - those parameters have no effect. I could not find their mention in the tomcat docs either, but this was something I found on a blog post for Tomcat 5.x. Tomcat 5.x is not Tomcat 6.x. There are differences and this is one of them. Is there a way to make tomcat reduce the number of threads? Sorry, no. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cannot seem to see deployed application
Apache Tomcat/5.5.26 OS = RH ES 5 markt-2 wrote: cooper5114 wrote: I'm very new to Tomcat so bear with me. I ran into a problem where i couldn't access an application (x.war) that i copied to Tomcat's webapps directory. I verified the $CATALINA_HOME env variable points to that tomcat. The ip address/port are fine, etc. I can get to the default Tomcat home page. Any suggestions how to debug this? There is only one copy of tomcat running. So in trying to figure out what was going on, i edited the webapps/ROOT/index.jsp page to verify that it would change. It didn't. So i figured it must be cached, so i killed my browser, restarted. No change. I also deleted $CATALINA_HOME/work directory (which i believe is used for caching). No change Any clues? Tomcat version? OS version? JDK version? Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/cannot-seem-to-see-deployed-application-tp19856874p19857199.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reloading Tomcat Server
Pid wrote: No! Bad! Your tomcat version operating system variant (some version of linux?) would be useful. Try to locate the main tomcat logfile, 'catalina.out' in the tomcat/logs directory. This logfile should contain a detailed error stacktrace for the 500 error page, please send that in your reply. Sorry you are right: Tomcat 6-0-18 Debian 2.6.24 It might be a timeout issue, agreed. That is why I decided on using wget and a local file. Now index.jsp should just read the local file and thus no timeout issue. the wget command is as follows: wget -O .../local_news http://www.topix.com/rss/county/citrus-fl wget -O .../national_news http://hosted.ap.org/lineups/USHEADS-rss_2.0.xml?SITE=RANDOMSECTION=HOME wget -O .../international http://hosted.ap.org/lineups/WORLDHEADS-rss_2.0.xml?SITE=VOICESDSECTION=HOME wget -O .../state_news http://news.yahoo.com/localnews/12772758/source/7818797/St+Petersburg+Times?format=rss Webpage shows: type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: java.lang.NullPointerException org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:418) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) root cause java.lang.NullPointerException com.sun.cnpi.rss.taglib.ForEachItemTag.doStartTag(ForEachItemTag.java:108) org.apache.jsp.index_jsp._jspx_meth_rss_005fforEachItem_005f0(index_jsp.java:367) org.apache.jsp.index_jsp._jspService(index_jsp.java:167) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) note The full stack trace of the root cause is available in the Apache Tomcat/6.0.18 logs. == catalina.out shows Oct 7, 2008 10:08:53 AM org.apache.catalina.core.ApplicationContext log INFO: default: DefaultServlet.serveFile: contentType='text/html' Oct 7, 2008 10:08:53 AM org.apache.catalina.core.ApplicationContext log INFO: default: DefaultServlet.serveFile: contentLength=2060 java.io.FileNotFoundException: http://www.topix.com/rss/county/citrus-fl at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1239) at com.sun.cnpi.rss.parser.RssParserImpl.parse(RssParserImpl.java:100) at com.sun.cnpi.rss.taglib.FeedTag.doStartTag(FeedTag.java:121) at org.apache.jsp.index_jsp._jspService(index_jsp.java:155) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.JDBCAccessLogValve.invoke(JDBCAccessLogValve.java:463) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:354) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Oct 7, 2008 10:13:42 AM
Re: cannot seem to see deployed application
cooper5114: So in trying to figure out what was going on, i edited the webapps/ROOT/index.jsp page to verify that it would change. It didn't. So i figured it must be cached, so i killed my browser, restarted. No change. I also deleted $CATALINA_HOME/work directory (which i believe is used for caching). No change If you take a look at the web.xml of the default ROOT webapp that is shipped with Tomcat, you'll see that /index.jsp is mapped to the pre-compiled servlet that's generated from ROOT/index.jsp, not to the JSP servlet that would compile it on access. Therefore, what you observed is exactly what is to be expected and doesn't help with tracking down the problem you have. But that's just a side note. To really get help with solving the problem, you should continue to answer Mark's questions and follow his advice. Regards mks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reloading Tomcat Server
From: Barry Fawthrop [mailto:[EMAIL PROTECTED] [...] wget -O .../local_news http://www.topix.com/rss/county/citrus-fl [...] java.io.FileNotFoundException: http://www.topix.com/rss/county/citrus-fl at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Htt pURLConnection.java:1239) at com.sun.cnpi.rss.parser.RssParserImpl.parse(RssParserImpl.java:100) at com.sun.cnpi.rss.taglib.FeedTag.doStartTag(FeedTag.java:121) at org.apache.jsp.index_jsp._jspService(index_jsp.java:155) Are you *sure* you've changed your JSP to read from the local file? That looks like it's still trying to read directly from the URL during the request. - Peter - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cannot seem to see deployed application
I'm very new to Tomcat so bear with me. I ran into a problem where i couldn't access an application (x.war) that i copied to Tomcat's webapps directory. I verified the $CATALINA_HOME env variable points to that tomcat. The ip address/port are fine, etc. I can get to the default Tomcat home page. Any suggestions how to debug this? There is only one copy of tomcat running. So in trying to figure out what was going on, i edited the webapps/ROOT/index.jsp page to verify that it would change. It didn't. So i figured it must be cached, so i killed my browser, restarted. No change. I also deleted $CATALINA_HOME/work directory (which i believe is used for caching). No change Any clues? -- View this message in context: http://www.nabble.com/cannot-seem-to-see-deployed-application-tp19856874p19856874.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question About IIS, connector, and 2 tomcats with the same app running
Good Day. Hope u can help me, have read about workers, uri and connector, And i have get to work it. But I have a problem. Situation: 2 Servers, Producttion and Development. Developers deploy .war to developemnt, and when it's correct they move war from development to production. 1 Server, in DMZ zone, with the tomcat connector working. DMZ Server, listen to 8080 petitions. In uriworkermap.properties I have a line like follow: /resource|/*=DevelopmentServer It works nice. Here comes the problem. When ppl move .war to production server, I have to machines with the same /resource. And Only one Server to handle both. The ideal world will be http://DMZServer/Developemnt http://DMZSERVer/Production But, all u know, but tomcat working, that the way is: http://dmzserver/resource ¿Any way to configure more than a redirection with the same URI patther to more than one tomcat ? The options are configuring another Web Service in another port, but configuracion and help in connector didnt seems to explain how to do. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reloading Tomcat Server
Peter Crowther wrote: From: Barry Fawthrop [mailto:[EMAIL PROTECTED] [...] wget -O .../local_news http://www.topix.com/rss/county/citrus-fl [...] java.io.FileNotFoundException: http://www.topix.com/rss/county/citrus-fl at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Htt pURLConnection.java:1239) at com.sun.cnpi.rss.parser.RssParserImpl.parse(RssParserImpl.java:100) at com.sun.cnpi.rss.taglib.FeedTag.doStartTag(FeedTag.java:121) at org.apache.jsp.index_jsp._jspService(index_jsp.java:155) Are you *sure* you've changed your JSP to read from the local file? That looks like it's still trying to read directly from the URL during the request. Yes I'm sure I changed the index.jsp However, it probably is still reading the old version found in /usr/share/tomcat-6.0.18/work/Catalina/ This might also be the cause. Is there anyway to flush it or better yet make it where it has to compile a new version each time. I realize in most cases this would NOT be the case. Thanks again Barry - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SSL Host
Recently I tried to switch from tomcat to jetty (I read it would be faster, so what the heck, I give it a try). Well, I can say, I am definitely sticking with tomcat, it is a lot easier to setup en the docs are way better. I have it running with two hosts and ssl enabled. Each ssl site gets its own page (which seems odd to me) What I would like to know is: how do I setup tomcat to serve a different host on ssl and normal on the same socket. In apache this is easy, just define a new virtual host, set the documentroot and voila, it just works. It seems to me it should be possible by combining listener, connector and host in some way, but I can not find out how I should do that. Thanks a lot in advance Serge Fonville
Re: Non-secure HTTP connector with secure=true requires a keystore?
I'm trying to configure an HTTP Connector that reports to the application that the connection is secure. According to the TC documentation (http://tomcat.apache.org/tomcat-5.5-doc/config/http.html), you should be able to simply set: secure=true in the Connector and all should be well. Yes, this is used when you'll be using SSL/TLS with https type URLs. To do SSL, you'll need a keystore to with a key created that represents the web server's domain name (i.e. cn=www.webserver.org). I would have expected an HTTP connector to be created, but it appears that an HTTPS connector is being created instead. If you only want http, then secure will always be false. Of course, I'm not sure which of the scheme and secure attributes tells it to use SSL HTTP/1.1 connector. If you don't want a keystore and want HTTP instead of HTTPS, just leave the secure attribute off. David - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Welcome file bypasses security-constraint checking?
Hey all, Just noticed some odd behavior in tomcat today, one of our admins setup a new folder on a context as follows: /seasonpass/index.jsf /seasonpass/index.jsp He did not touch the web.xml file and yet the /seasonpass/ folder works as expected!? Without altering the security-constraints in web.xml. The idea is that index.jsp is our welcome file and would forward the user automagically (a technical term) to the /index.jsf file in the seasonpass folder if the user simply went to www.myurl.com/seasonpass/. However, we have no mention of the /seasonpass/ directory in our Not Secured Pages security-constraint elements... so I think what's happening is the fact that our welcome-file is the index.jsp is automatically allowed wherever it appears... Is this a security hole or is this intended? Relevant Copy from web.xml !-- Welcome files -- welcome-file-list welcome-fileindex.jsp/welcome-file /welcome-file-list security-constraint display-nameNot secured Pages/display-name web-resource-collection web-resource-nameWelcome pages/web-resource-name bunch of stuff not pertaining to the /seasonpass/ directory/blah /web-resource-collection /security-constraint Rob Web Developer/Site Administrator
RE: Non-secure HTTP connector with secure=true requires a keystore?
From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Non-secure HTTP connector with secure=true requires a keystore? I'm trying to configure an HTTP Connector that reports to the application that the connection is secure. I thought I had done this using just what you described, but it may have been in 6.0. Can you post the config for the Connector in question? Have you left the scheme set to HTTP? - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Basic Tribes Questions
Hi Filip,
I think I am seeing the message, it was just hidden amongst other log messages
I guess I missed it.
However I do see something else when I added the TcpFailureDetector to the
interceptor list, I see two DISAPPEARED messages?
Without TcpFailureDetector:
1) Start Server #1, then #2
2) Unplug #2 network
3) On #1 - #2 DISAPPEARED, on #2 - #1 DISAPPEARED
4) Reconnect #2 to network, on #1 - #2 SHUTDOWN;#2 ADDED, on #2 - #1
ADDED
Add TcpFailureDetector
1) Start Server #1, #2
2) Unplug #2 network
3) On #1 - #2 DISAPPEARED;#2 DISAPPEARED, on #2 - #1 DISAPPEARED;#1
DISAPPEARED
4) Reconnect #2 to network, on #1 - #2 SHUTDOWN;#2 ADDED, on #2 - #1
ADDED
I take it I get the 2 DISAPPEARED messages because I have another interceptor,
but is this the correct behaviour?
TIA
Mike
-Original Message-
From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
Sent: October 6, 2008 11:28 AM
To: Tomcat Users List
Subject: Re: Basic Tribes Questions
there are getters and setters for everything
and they are all documented here
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-channel.html
each component has getters/setters, for example, the multicast address
setAddress
getAddress
breakpoints might not work very well, since you are stopping one thread,
and not really emulating a real scenario.
again, sounds like you have a simple test case, if you can share that, I
can get more understanding, and help you further.
Filip
Mike Wannamaker wrote:
Hi Filip
Thanks for the info. However, I don't see the documentation for the
setters/getters you mention below?
Also I'm having issues while debugging. When I hit a breakpoint in my code
and while stepping thru code, I get DISAPPEARED/ADDED messages over and over
on the other server? I would think the heartbeat is running in a separate
thread for both send/receive? How to solve this, bump the heartbeat timeout?
TIA
Mike
-Original Message-
From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
Sent: October 3, 2008 2:51 PM
To: Tomcat Users List
Subject: Re: Basic Tribes Questions
answers inline
Mike Wannamaker wrote:
Hi, I am currently trying to use Tribes as the clustering layer on our
server.
My startup code looks like this.
if(_tribesChannel == null)
{ // nothing to do if already running
try
{
_tribesChannel = new GroupChannel();
// must be done before start:
no need to use any properties, there are getters and setters for everything
and they are all documented here
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-channel.html
_tribesChannel.getMembershipService().getProperties().put(mcastPort,
String.valueOf(_mainPort));
_tribesChannel.getMembershipService().getProperties().put(mcastAddress,
_multicastIPAddr);
not sure what you are trying to do in the code below. if you wanna set
the port, then simply do it.
the membership will pick it up automatically
if(_ancillaryPort 0)
{
_tribesChannel.getMembershipService().getProperties().put(tcpListenPort,
String.valueOf(_ancillaryPort));
// hack alert: Default Tribes instantiation (Tomcat
6.0.16) does not read value for tcpListenPort from properties.
// Therefore, set it directly
ChannelReceiver receiver =
_tribesChannel.getChannelReceiver();
if(receiver.getPort() != _ancillaryPort)
{
if(receiver instanceof ReceiverBase)
{
((ReceiverBase)receiver).setPort(_ancillaryPort);
}
}
}
_tribesChannel.addMembershipListener(_tribesMembershipListener);
_tribesChannel.addChannelListener(_tribesChannelListener);
_tribesChannel.start(CHANNEL_COMPONENTS);
}
catch(ChannelException ex)
{
try { _tribesChannel.stop(CHANNEL_COMPONENTS); }
catch(Throwable t) { /*gulp*/}
_tribesChannel = null;
throw new RuntimeException(ex); // todo, exception handling?
}
}
My Question is that when I start Server #1, then Server #2, then unplug
Server #2 network cable, Server #1 gets the DISAPPEARED message but Server
#2 just keeps logging the message below. As I write this it's at attempt
#120. How do I get this to notify on Server #2 that Server #1 has
DISAPPEARED or can I set the number of attempts to a maximum number before
notifying?
the message you are getting is cause the membership tries to recover.
you can limit this, by doing
setRecoveryEnabled(true|false);
Re: Non-secure HTTP connector with secure=true requires a keystore?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, Caldarale, Charles R wrote: I thought I had done this using just what you described, but it may have been in 6.0. Can you post the config for the Connector in question? Have you left the scheme set to HTTP? Yup. Here's the configuration: Connector port=8080 maxHttpHeaderSize=8192 maxThreads=50 minSpareThreads=25 maxSpareThreads=25 enableLookups=false acceptCount=100 connectionTimeout=2 disableUploadTimeout=true secure=true URIEncoding=UTF-8 address=127.0.0.1 / I tried it with scheme=http at first, and got the same exception. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjrrWAACgkQ9CaO5/Lv0PCLEACfSOwB05/YTDTqxEqDEzxb14tN iO0An207foePktmdgJcktXI2NHeyUd1/ =68jf -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setHeader after DoFilter delegation in filter?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael,
Michael Larson wrote:
I'm debugging a tomcat filter. The filter has been designed as follows:
MyFilter::DoFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
{
do_some_stuff();
//now delegate the call the chain
chain.DoFilter();
//the header value below doesn't always show up at the client
response.setHeader(post-filter,true);
}
This might not work because the response could have been committed. If
the response buffer is filled, then the headers will be sent back to the
client. If you come along later and try to set a header, you'll get an
exception.
For the jsp page being accessed I've turned off AutoFlush (via a server
side directive). However, I'm still seeing this page (if it exceeds a
certain size but well below the jspwriter buffer size) will be sent back
to the client before the response header has been modified.
I'm not sure about autoFlush, but it may be that you're hitting a hard
buffer limit and the data is being sent, anyway.
If AutoFlush is turned off for the jsp page and the page doesn't exceed
the buffer size can it still send the response back to the client before
the filter chain has completed (and in this example before the header
has been modified)? Is it a bad idea to modify the response header after
the call to chain.DoFilter()?
It's much better to do it up front if you can. Why do you need the
header to be set after the fact?
If you really must do this, you can always do your own buffering by
wrapping the request along with your own OutputStream/Writer that
buffers itself.
The version of tomcat is v5.5.23, and no exceptions are thrown when the
setHeader call is made.
That's interesting that no exceptions are thrown. :(
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjrrxwACgkQ9CaO5/Lv0PAKdwCfbEXaoIj5cnMLIYZciiEXcAL8
0TMAn0CWqgdA8qQNsZwDabIQHbRHPoqY
=Gqzj
-END PGP SIGNATURE-
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Welcome file bypasses security-constraint checking?
From: Rob Mercer [mailto:[EMAIL PROTECTED] Subject: Welcome file bypasses security-constraint checking? Just noticed some odd behavior in tomcat today Care to tell us the version, or should we consult a psychic reader? He did not touch the web.xml file and yet the /seasonpass/ folder works as expected!? Since security constraints usually define what is restricted, not what is public, that's not surprising. Relevant Copy from web.xml Without the actual config statements, it's not that relevant... security-constraint display-nameNot secured Pages/display-name web-resource-collection web-resource-nameWelcome pages/web-resource-name bunch of stuff not pertaining to the /seasonpass/ directory/blah /web-resource-collection /security-constraint I suppose we should guess the contents of your security-constraint as well... Please post the actual web.xml file, along with your Tomcat version. - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSL Host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge, Serge Fonville wrote: What I would like to know is: how do I setup tomcat to serve a different host on ssl and normal on the same socket. Do you mean the same port? You can't have HTTP and HTTPS on the same port: no product can do that. What you might be really asking for is HTTP on one port with HTTPS on another port, with redirects set up so you can easily go from HTTP - HTTPS. In apache this is easy, just define a new virtual host, set the documentroot and voila, it just works. Maybe you could post a sample Apache httpd config and we can get a better idea of what you're trying to do. It seems to me it should be possible by combining listener, connector and host in some way, but I can not find out how I should do that. I think you really just want two connectors: Connector port=80 redirectPort=443 ... / (this is the http one) Connector port=443 / (this is the https one) See the default server.xml for examples of all the attributes for these elements, or the full documentation at http://tomcat.apache.org/tomcat-5.5-doc/config/http.html - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjrsFAACgkQ9CaO5/Lv0PBejQCeMBpizfHbDnCga3QqxUj4Jwsz JDsAoL8OCw8Zv9qsQ7MoAla5Tl+9gEV7 =IDSk -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Non-secure HTTP connector with secure=true requires a keystore?
From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: Non-secure HTTP connector with secure=true requires a keystore? I tried it with scheme=http at first, and got the same exception. The code in 6.0 is noticeably different from that in 5.5 for protocol initialization, including setting up the socket factory. Would it be possible to test the config on 6.0 to see if you can achieve the desired results there? - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Welcome file bypasses security-constraint checking?
Tomcat 6.0.14 !-- Welcome files -- welcome-file-list welcome-fileindex.jsp/welcome-file /welcome-file-list !-- Security configuration -- security-role role-nametomcat/role-name /security-role security-role role-nameUSR/role-name /security-role security-role role-nameMGR/role-name /security-role security-role role-nameORG/role-name /security-role security-role role-nameADM/role-name /security-role security-constraint display-nameNot secured Pages/display-name web-resource-collection web-resource-nameWelcome pages/web-resource-name url-pattern/faqs.jsf/url-pattern url-pattern/contact_us.jsf/url-pattern url-pattern/contact_success.jsf/url-pattern url-pattern/trouble.jsf/url-pattern url-pattern/share.jsf/url-pattern url-pattern/privacy-policy.jsf/url-pattern url-pattern/forgot-password.jsf/url-pattern url-pattern/demo/*/url-pattern url-pattern/signup/welcome.jsf/url-pattern url-pattern/signup/user-info.jsf/url-pattern url-pattern/signup/terms.jsf/url-pattern url-pattern/signup/mgr/attending.jsf/url-pattern url-pattern/signup/mgr/gym-info.jsf/url-pattern url-pattern/signup/mgr/terms.jsf/url-pattern url-pattern/signup/mgr/welcome.jsf/url-pattern url-pattern/support.jsf/url-pattern url-pattern/password-reset-success.jsf/url-pattern url-pattern/signup/new-organization.jsf/url-pattern !-- notice the lack of /seasonpass/* here --- /web-resource-collection user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-constraint display-nameRestrict Secured JSF Pages/display-name web-resource-collection web-resource-nameJSF/web-resource-name url-pattern*.jsf/url-pattern url-pattern/index.jsp/url-pattern url-pattern/servlet/*/url-pattern http-methodDELETE/http-method http-methodGET/http-method http-methodHEAD/http-method http-methodOPTIONS/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodTRACE/http-method /web-resource-collection auth-constraint role-nametomcat/role-name role-nameUSR/role-name role-nameMGR/role-name role-nameORG/role-name role-nameADM/role-name /auth-constraint !-- require the user to access this page over a secure link -- user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint security-constraint display-nameRestrict Secured Servlets Pages/display-name web-resource-collection web-resource-nameServlet/web-resource-name url-pattern/servlet/*/url-pattern http-methodDELETE/http-method http-methodGET/http-method http-methodHEAD/http-method http-methodOPTIONS/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodTRACE/http-method /web-resource-collection auth-constraint role-nametomcat/role-name role-nameUSR/role-name role-nameMGR/role-name role-nameORG/role-name role-nameADM/role-name /auth-constraint !-- require the user to access this page over a secure link -- user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint -Original Message- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2008 2:47 PM To: Tomcat Users List Subject: RE: Welcome file bypasses security-constraint checking? From:
Re: Monitoring of services deployed in tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raghu, Raghunandan wrote: Is it required to monitor the deployed services in tomcat? No. You can ignore Tomcat after it's been started if you want. Is there option for auto restart if the service goes down? Tomcat does not include any such functionality. You will need to set up this capability on your own. If it is necessary to monitor the deployed services, what are the different ways of monitoring. google tomcat monitoring Many folks have had good results using LambdaProbe (http://www.lambdaprobe.org/), but this does not include any auto-restart features: it's mainly reporting on Tomcat and the JVM from a running instance. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjrseMACgkQ9CaO5/Lv0PD3OwCgsi2GyfzR0nzZX6FXwUR+sC7T frYAoLZHimLILRJVcIqk/Tk8nM/uFcp6 =4/ru -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Non-secure HTTP connector with secure=true requires a keystore?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: Non-secure HTTP connector with secure=true requires a keystore? I tried it with scheme=http at first, and got the same exception. The code in 6.0 is noticeably different from that in 5.5 for protocol initialization, including setting up the socket factory. Would it be possible to test the config on 6.0 to see if you can achieve the desired results there? Yeah, I can probably try that. I don't even need an app to deploy in order to test ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjrsgkACgkQ9CaO5/Lv0PCWPQCbBXylAq0lmheCGZwpsxPrL9yA SJEAoIoJ/FHSV+pK+6J1PalX9DWWWZCq =xNNQ -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Welcome file bypasses security-constraint checking?
From: Rob Mercer [mailto:[EMAIL PROTECTED] Subject: RE: Welcome file bypasses security-constraint checking? Tomcat 6.0.14 Thanks. security-constraint display-nameNot secured Pages/display-name [various unsecured declarations snipped] /security-constraint security-constraint display-nameRestrict Secured JSF Pages/display-name web-resource-collection web-resource-nameJSF/web-resource-name url-pattern*.jsf/url-pattern The above should protect /seasonpass/index.jsf; does it? url-pattern/index.jsp/url-pattern The above *does not* protect /seasonpass/index.jsp? Did you expect it to? url-pattern/servlet/*/url-pattern OT: you're not using the InvokerServlet, are you? That would be abhorrent. [protected methods snipped] /web-resource-collection [other constraints snipped] /security-constraint security-constraint display-nameRestrict Secured Servlets Pages/display-name [declarations snipped] /security-constraint More OT: the Restrict Secured Servlets Pages section is just a subset of Restrict Secured JSF Pages, so you might as well just take it out. I don't see anything in any of your constraints that would lead me to believe /seasonpass/index.jsp should be restricted. Looks like Tomcat is behaving properly. - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSL Host
Chris, Thanks for you repsons. You are right, I'll clarify (add an actual example) I have Tomcat 6.0.18 with the native dll installed I have two hosts presently (more to come) localhost and autumn.nl What I want now is *.autumn.nl accessble only via http secure.autumn.nl accessible only via https localhost accessible via both Presently I have two hosts which are both accessible via http and https This scenario is easily resolved in httpd, but how should it be done in tomcat. Thanks so far Serge On Tue, Oct 7, 2008 at 8:54 PM, Christopher Schultz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge, Serge Fonville wrote: What I would like to know is: how do I setup tomcat to serve a different host on ssl and normal on the same socket. Do you mean the same port? You can't have HTTP and HTTPS on the same port: no product can do that. What you might be really asking for is HTTP on one port with HTTPS on another port, with redirects set up so you can easily go from HTTP - HTTPS. In apache this is easy, just define a new virtual host, set the documentroot and voila, it just works. Maybe you could post a sample Apache httpd config and we can get a better idea of what you're trying to do. It seems to me it should be possible by combining listener, connector and host in some way, but I can not find out how I should do that. I think you really just want two connectors: Connector port=80 redirectPort=443 ... / (this is the http one) Connector port=443 / (this is the https one) See the default server.xml for examples of all the attributes for these elements, or the full documentation at http://tomcat.apache.org/tomcat-5.5-doc/config/http.html - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjrsFAACgkQ9CaO5/Lv0PBejQCeMBpizfHbDnCga3QqxUj4Jwsz JDsAoL8OCw8Zv9qsQ7MoAla5Tl+9gEV7 =IDSk -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat default encoding character ? Dfile.encoding option mean ?
I ran accros the ml archives, and i find some useful posts. I've almost solved my problem: i can now display the accent (é è à) using request.setCharacterEncoding(UTF-8); response.setCharacterEncoding(UTF-8); It seems that the default charset for tomcat is ISO 8859 1 The j2ee javadoc says: If no charset is specified, ISO-8859-1 will be used. I was pretty sure that tomcat handles UTF-8 by default, but it's not the case...at least for HttpServletResponse objects. Anyway, do you know if it's possible to set up a default charset for the wjole tomcat response, instead of calling these two methods every time a request reach the servlet... ? I tried to define the CATALINA_OPTS, but perhaps the file encoding is different from the request/response encoding. CATALINA_OPTS=-Dfile.encoding=UTF-8 export LC_ALL CATALINA_OPTS -- Albrecht ANDRZEJEWSKI Créateur - Incubateur Technologique SITE-EERIE - Parc scientifique G. Besse *** http://haveacafe.wordpress.com/ Ce message a ete envoye par le serveur IMP de l'EMA. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
video/x-flv mime-mapping does not for Tomcat 5.5
we are using JBoss4.0.5. For flash video, we added mime-mapping extensionflv/extension mime-typevideo/x-flv/mime-type /mime-mapping in tomcat conf/web.xml. Restarted jboss. When uploading a foo.flv, uploadeFile.getContentType returns application/octet-stream, not video/x-flv. Could you please help me? Thanks, Dave
Re: Basic Tribes Questions
hi Mike, that's great. yes, the TCP failure detector could give multiple
DISAPPEARED messages, that is something I'm about to fix
Filip
Mike Wannamaker wrote:
Hi Filip,
I think I am seeing the message, it was just hidden amongst other log messages
I guess I missed it.
However I do see something else when I added the TcpFailureDetector to the
interceptor list, I see two DISAPPEARED messages?
Without TcpFailureDetector:
1) Start Server #1, then #2
2) Unplug #2 network
3) On #1 - #2 DISAPPEARED, on #2 - #1 DISAPPEARED
4) Reconnect #2 to network, on #1 - #2 SHUTDOWN;#2 ADDED, on #2 - #1
ADDED
Add TcpFailureDetector
1) Start Server #1, #2
2) Unplug #2 network
3) On #1 - #2 DISAPPEARED;#2 DISAPPEARED, on #2 - #1 DISAPPEARED;#1
DISAPPEARED
4) Reconnect #2 to network, on #1 - #2 SHUTDOWN;#2 ADDED, on #2 - #1
ADDED
I take it I get the 2 DISAPPEARED messages because I have another interceptor,
but is this the correct behaviour?
TIA
Mike
-Original Message-
From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
Sent: October 6, 2008 11:28 AM
To: Tomcat Users List
Subject: Re: Basic Tribes Questions
there are getters and setters for everything
and they are all documented here
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-channel.html
each component has getters/setters, for example, the multicast address
setAddress
getAddress
breakpoints might not work very well, since you are stopping one thread,
and not really emulating a real scenario.
again, sounds like you have a simple test case, if you can share that, I
can get more understanding, and help you further.
Filip
Mike Wannamaker wrote:
Hi Filip
Thanks for the info. However, I don't see the documentation for the
setters/getters you mention below?
Also I'm having issues while debugging. When I hit a breakpoint in my code and
while stepping thru code, I get DISAPPEARED/ADDED messages over and over on the
other server? I would think the heartbeat is running in a separate thread for
both send/receive? How to solve this, bump the heartbeat timeout?
TIA
Mike
-Original Message-
From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
Sent: October 3, 2008 2:51 PM
To: Tomcat Users List
Subject: Re: Basic Tribes Questions
answers inline
Mike Wannamaker wrote:
Hi, I am currently trying to use Tribes as the clustering layer on our server.
My startup code looks like this.
if(_tribesChannel == null)
{ // nothing to do if already running
try
{
_tribesChannel = new GroupChannel();
// must be done before start:
no need to use any properties, there are getters and setters for everything
and they are all documented here
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-channel.html
_tribesChannel.getMembershipService().getProperties().put(mcastPort,
String.valueOf(_mainPort));
_tribesChannel.getMembershipService().getProperties().put(mcastAddress,
_multicastIPAddr);
not sure what you are trying to do in the code below. if you wanna set
the port, then simply do it.
the membership will pick it up automatically
if(_ancillaryPort 0)
{
_tribesChannel.getMembershipService().getProperties().put(tcpListenPort,
String.valueOf(_ancillaryPort));
// hack alert: Default Tribes instantiation (Tomcat 6.0.16) does not
read value for tcpListenPort from properties.
// Therefore, set it directly
ChannelReceiver receiver =
_tribesChannel.getChannelReceiver();
if(receiver.getPort() != _ancillaryPort)
{
if(receiver instanceof ReceiverBase)
{
((ReceiverBase)receiver).setPort(_ancillaryPort);
}
}
}
_tribesChannel.addMembershipListener(_tribesMembershipListener);
_tribesChannel.addChannelListener(_tribesChannelListener);
_tribesChannel.start(CHANNEL_COMPONENTS);
}
catch(ChannelException ex)
{
try { _tribesChannel.stop(CHANNEL_COMPONENTS); }
catch(Throwable t) { /*gulp*/}
_tribesChannel = null;
throw new RuntimeException(ex); // todo, exception handling?
}
}
My Question is that when I start Server #1, then Server #2, then unplug Server
#2 network cable, Server #1 gets the DISAPPEARED message but Server #2 just
keeps logging the message below. As I write this it's at attempt #120. How do
I get this to notify on Server #2 that Server #1 has DISAPPEARED or can I set
the number of attempts to a maximum number before notifying?
the message you
Re: tomcat ROOT
Hi Markus, did you ever figure this out? I was looking in the archives of the tomcat mailing list and saw your query but it didn't seem to me that anyone answered it fully, at least not for me. I figured out that I could remove/rename the webapps/ROOT directory and deploy my war file as ROOT.war and then it would replace tomcat's web page at http://www.myhost.edu/ but I also have apache in front of tomcat and I don't understand how to set up the jkmount in my httpd.conf file to map apache's root to tomcat's root. Markus Lord wrote: I have apache acting as a proxy for my tomcat and I'm wondering how I can get this one application 'myapp' to show up without having the directory name in the url. So what I'm looking to do is have it as www.mysite.com instead of www.mysite.com/myapp. Thanks in advance. Markus - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Too many open files
Tomcat throws too many open files and when I do lsof I get bunch of: java14130 root 935u IPv4 30842592 TCP localhost:41971-localhost:http (CLOSE_WAIT) java14130 root 937u IPv4 30841213 TCP efeitws3.ptctax.intuit.com:41161-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 938u IPv4 30841214 TCP localhost:41162-localhost:http (CLOSE_WAIT) java14130 root 939u IPv4 30841220 TCP localhost:41165-localhost:http (CLOSE_WAIT) java14130 root 940u IPv4 30842516 TCP localhost:41927-localhost:http (CLOSE_WAIT) java14130 root 941u IPv4 30841226 TCP localhost:41168-localhost:http (CLOSE_WAIT) java14130 root 943u IPv4 30841899 TCP efeitws3.ptctax.intuit.com:41566-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 944u IPv4 30841694 TCP efeitws3.ptctax.intuit.com:41453-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 945u IPv4 30841695 TCP localhost:41454-localhost:http (CLOSE_WAIT) java14130 root 946u IPv4 30841900 TCP localhost:41567-localhost:http (CLOSE_WAIT) java14130 root 948u IPv4 30842415 TCP efeitws3.ptctax.intuit.com:41864-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 949u IPv4 30842416 TCP localhost:41865-localhost:http (CLOSE_WAIT) java14130 root 950u IPv4 30842419 TCP localhost:41867-localhost:http (CLOSE_WAIT) java14130 root 952u IPv4 30850596 TCP localhost:42484-localhost:http (CLOSE_WAIT) java14130 root 953u IPv4 30842760 TCP localhost:42058-localhost:http (CLOSE_WAIT) java14130 root 954u IPv4 30842596 TCP localhost:41974-localhost:http (CLOSE_WAIT) java14130 root 956u IPv4 30842093 TCP localhost:41676-localhost:http (CLOSE_WAIT) java14130 root 957u IPv4 30842195 TCP efeitws3.ptctax.intuit.com:41737-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 958u IPv4 30841730 TCP localhost:41467-localhost:http (CLOSE_WAIT) java14130 root 959u IPv4 30841737 TCP localhost:41472-localhost:http (CLOSE_WAIT) java14130 root 960u IPv4 30842196 TCP localhost:41738-localhost:http (CLOSE_WAIT) java14130 root 961u IPv4 30842528 TCP localhost:41933-localhost:http (CLOSE_WAIT) java14130 root 962u IPv4 30842363 TCP localhost:41836-localhost:http (CLOSE_WAIT) java14130 root 964u IPv4 30842365 TCP efeitws3.ptctax.intuit.com:41837-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 965u IPv4 30842366 TCP localhost:41838-localhost:http (CLOSE_WAIT) java14130 root 966u IPv4 30842367 TCP localhost:41839-localhost:http (CLOSE_WAIT) java14130 root 967u IPv4 30842371 TCP localhost:41841-localhost:http (CLOSE_WAIT) java14130 root 968u IPv4 30842465 TCP localhost:41895-localhost:http (CLOSE_WAIT) java14130 root 969u IPv4 30848501 TCP localhost:42415-localhost:http (CLOSE_WAIT) java14130 root 970u IPv4 30842533 TCP localhost:41936-localhost:http (CLOSE_WAIT) java14130 root 971u IPv4 30842468 TCP localhost:41898-localhost:http (CLOSE_WAIT) java14130 root 972u IPv4 30842534 TCP localhost:41937-localhost:http (CLOSE_WAIT) java14130 root 973u IPv4 30842765 TCP localhost:42062-localhost:http (CLOSE_WAIT) java14130 root 974u IPv4 30842472 TCP localhost:41901-localhost:http (CLOSE_WAIT) java14130 root 975u IPv4 30842122 TCP localhost:41694-localhost:http (CLOSE_WAIT) java14130 root 976u IPv4 30842123 TCP localhost:41695-localhost:http (CLOSE_WAIT) java14130 root 977u IPv4 30843217 TCP localhost:42188-localhost:http (CLOSE_WAIT) java14130 root 978u IPv4 30842125 TCP localhost:41696-localhost:http (CLOSE_WAIT) java14130 root 979u IPv4 30842126 TCP efeitws3.ptctax.intuit.com:41697-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 981u IPv4 30842128 TCP efeitws3.ptctax.intuit.com:41698-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 982u IPv4 30842129 TCP localhost:41699-localhost:http (CLOSE_WAIT) java14130 root 983u IPv4 30888558 TCP localhost:43218-localhost:http (CLOSE_WAIT) java14130 root 984u IPv4 30842617 TCP localhost:41986-localhost:http (CLOSE_WAIT) java14130 root 985u IPv4 30842618 TCP efeitws3.ptctax.intuit.com:41987-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 986u IPv4 30844067 TCP efeitws3.ptctax.intuit.com:42260-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 987u IPv4 30850599 TCP
Re: tomcat ROOT
- Original Message - From: Rusty Wright [EMAIL PROTECTED] To: Markus Lord [EMAIL PROTECTED]; Tomcat Users List users@tomcat.apache.org Sent: Tuesday, October 07, 2008 11:31 PM Subject: Re: tomcat ROOT Hi Markus, did you ever figure this out? I was looking in the archives of the tomcat mailing list and saw your query but it didn't seem to me that anyone answered it fully, at least not for me. I figured out that I could remove/rename the webapps/ROOT directory and deploy my war file as ROOT.war and then it would replace tomcat's web page at http://www.myhost.edu/ but I also have apache in front of tomcat and I don't understand how to set up the jkmount in my httpd.conf file to map apache's root to tomcat's root. Yes renaming a webapp to ROOT with a empty context path, makes it run as the root... Then... JkMount / worker1 Should make apache send it to your tomcat root --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Too many open files
- Original Message - From: Mohit Anchlia [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Tuesday, October 07, 2008 11:44 PM Subject: Too many open files Tomcat throws too many open files and when I do lsof I get bunch of: java14130 root 935u IPv4 30842592 TCP localhost:41971-localhost:http (CLOSE_WAIT) java14130 root 937u IPv4 30841213 TCP efeitws3.ptctax.intuit.com:41161-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 938u IPv4 30841214 TCP localhost:41162-localhost:http (CLOSE_WAIT) java14130 root 939u IPv4 30841220 TCP localhost:41165-localhost:http (CLOSE_WAIT) java14130 root 940u IPv4 30842516 TCP localhost:41927-localhost:http (CLOSE_WAIT) java14130 root 941u IPv4 30841226 TCP localhost:41168-localhost:http (CLOSE_WAIT) java14130 root 943u IPv4 30841899 TCP efeitws3.ptctax.intuit.com:41566-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 944u IPv4 30841694 TCP efeitws3.ptctax.intuit.com:41453-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 945u IPv4 30841695 TCP localhost:41454-localhost:http (CLOSE_WAIT) java14130 root 946u IPv4 30841900 TCP localhost:41567-localhost:http (CLOSE_WAIT) java14130 root 948u IPv4 30842415 TCP efeitws3.ptctax.intuit.com:41864-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 949u IPv4 30842416 TCP localhost:41865-localhost:http (CLOSE_WAIT) java14130 root 950u IPv4 30842419 TCP localhost:41867-localhost:http (CLOSE_WAIT) java14130 root 952u IPv4 30850596 TCP localhost:42484-localhost:http (CLOSE_WAIT) java14130 root 953u IPv4 30842760 TCP localhost:42058-localhost:http (CLOSE_WAIT) java14130 root 954u IPv4 30842596 TCP localhost:41974-localhost:http (CLOSE_WAIT) java14130 root 956u IPv4 30842093 TCP localhost:41676-localhost:http (CLOSE_WAIT) java14130 root 957u IPv4 30842195 TCP efeitws3.ptctax.intuit.com:41737-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 958u IPv4 30841730 TCP localhost:41467-localhost:http (CLOSE_WAIT) java14130 root 959u IPv4 30841737 TCP localhost:41472-localhost:http (CLOSE_WAIT) java14130 root 960u IPv4 30842196 TCP localhost:41738-localhost:http (CLOSE_WAIT) java14130 root 961u IPv4 30842528 TCP localhost:41933-localhost:http (CLOSE_WAIT) java14130 root 962u IPv4 30842363 TCP localhost:41836-localhost:http (CLOSE_WAIT) java14130 root 964u IPv4 30842365 TCP efeitws3.ptctax.intuit.com:41837-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 965u IPv4 30842366 TCP localhost:41838-localhost:http (CLOSE_WAIT) java14130 root 966u IPv4 30842367 TCP localhost:41839-localhost:http (CLOSE_WAIT) java14130 root 967u IPv4 30842371 TCP localhost:41841-localhost:http (CLOSE_WAIT) java14130 root 968u IPv4 30842465 TCP localhost:41895-localhost:http (CLOSE_WAIT) java14130 root 969u IPv4 30848501 TCP localhost:42415-localhost:http (CLOSE_WAIT) java14130 root 970u IPv4 30842533 TCP localhost:41936-localhost:http (CLOSE_WAIT) java14130 root 971u IPv4 30842468 TCP localhost:41898-localhost:http (CLOSE_WAIT) java14130 root 972u IPv4 30842534 TCP localhost:41937-localhost:http (CLOSE_WAIT) java14130 root 973u IPv4 30842765 TCP localhost:42062-localhost:http (CLOSE_WAIT) java14130 root 974u IPv4 30842472 TCP localhost:41901-localhost:http (CLOSE_WAIT) java14130 root 975u IPv4 30842122 TCP localhost:41694-localhost:http (CLOSE_WAIT) java14130 root 976u IPv4 30842123 TCP localhost:41695-localhost:http (CLOSE_WAIT) java14130 root 977u IPv4 30843217 TCP localhost:42188-localhost:http (CLOSE_WAIT) java14130 root 978u IPv4 30842125 TCP localhost:41696-localhost:http (CLOSE_WAIT) java14130 root 979u IPv4 30842126 TCP efeitws3.ptctax.intuit.com:41697-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 981u IPv4 30842128 TCP efeitws3.ptctax.intuit.com:41698-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 982u IPv4 30842129 TCP localhost:41699-localhost:http (CLOSE_WAIT) java14130 root 983u IPv4 30888558 TCP localhost:43218-localhost:http (CLOSE_WAIT) java14130 root 984u IPv4 30842617 TCP localhost:41986-localhost:http (CLOSE_WAIT) java14130 root 985u IPv4 30842618 TCP efeitws3.ptctax.intuit.com:41987-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 986u IPv4 30844067
Re: Too many open files
I can see you can't wait to hear the debate. Anyhow, I am using HttpClient from apache commons and I do have .getReleaseConnection(). On Tue, Oct 7, 2008 at 4:56 PM, Johnny Kewl [EMAIL PROTECTED] wrote: - Original Message - From: Mohit Anchlia [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Tuesday, October 07, 2008 11:44 PM Subject: Too many open files Tomcat throws too many open files and when I do lsof I get bunch of: java14130 root 935u IPv4 30842592 TCP localhost:41971-localhost:http (CLOSE_WAIT) java14130 root 937u IPv4 30841213 TCP efeitws3.ptctax.intuit.com:41161-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 938u IPv4 30841214 TCP localhost:41162-localhost:http (CLOSE_WAIT) java14130 root 939u IPv4 30841220 TCP localhost:41165-localhost:http (CLOSE_WAIT) java14130 root 940u IPv4 30842516 TCP localhost:41927-localhost:http (CLOSE_WAIT) java14130 root 941u IPv4 30841226 TCP localhost:41168-localhost:http (CLOSE_WAIT) java14130 root 943u IPv4 30841899 TCP efeitws3.ptctax.intuit.com:41566-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 944u IPv4 30841694 TCP efeitws3.ptctax.intuit.com:41453-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 945u IPv4 30841695 TCP localhost:41454-localhost:http (CLOSE_WAIT) java14130 root 946u IPv4 30841900 TCP localhost:41567-localhost:http (CLOSE_WAIT) java14130 root 948u IPv4 30842415 TCP efeitws3.ptctax.intuit.com:41864-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 949u IPv4 30842416 TCP localhost:41865-localhost:http (CLOSE_WAIT) java14130 root 950u IPv4 30842419 TCP localhost:41867-localhost:http (CLOSE_WAIT) java14130 root 952u IPv4 30850596 TCP localhost:42484-localhost:http (CLOSE_WAIT) java14130 root 953u IPv4 30842760 TCP localhost:42058-localhost:http (CLOSE_WAIT) java14130 root 954u IPv4 30842596 TCP localhost:41974-localhost:http (CLOSE_WAIT) java14130 root 956u IPv4 30842093 TCP localhost:41676-localhost:http (CLOSE_WAIT) java14130 root 957u IPv4 30842195 TCP efeitws3.ptctax.intuit.com:41737-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 958u IPv4 30841730 TCP localhost:41467-localhost:http (CLOSE_WAIT) java14130 root 959u IPv4 30841737 TCP localhost:41472-localhost:http (CLOSE_WAIT) java14130 root 960u IPv4 30842196 TCP localhost:41738-localhost:http (CLOSE_WAIT) java14130 root 961u IPv4 30842528 TCP localhost:41933-localhost:http (CLOSE_WAIT) java14130 root 962u IPv4 30842363 TCP localhost:41836-localhost:http (CLOSE_WAIT) java14130 root 964u IPv4 30842365 TCP efeitws3.ptctax.intuit.com:41837-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 965u IPv4 30842366 TCP localhost:41838-localhost:http (CLOSE_WAIT) java14130 root 966u IPv4 30842367 TCP localhost:41839-localhost:http (CLOSE_WAIT) java14130 root 967u IPv4 30842371 TCP localhost:41841-localhost:http (CLOSE_WAIT) java14130 root 968u IPv4 30842465 TCP localhost:41895-localhost:http (CLOSE_WAIT) java14130 root 969u IPv4 30848501 TCP localhost:42415-localhost:http (CLOSE_WAIT) java14130 root 970u IPv4 30842533 TCP localhost:41936-localhost:http (CLOSE_WAIT) java14130 root 971u IPv4 30842468 TCP localhost:41898-localhost:http (CLOSE_WAIT) java14130 root 972u IPv4 30842534 TCP localhost:41937-localhost:http (CLOSE_WAIT) java14130 root 973u IPv4 30842765 TCP localhost:42062-localhost:http (CLOSE_WAIT) java14130 root 974u IPv4 30842472 TCP localhost:41901-localhost:http (CLOSE_WAIT) java14130 root 975u IPv4 30842122 TCP localhost:41694-localhost:http (CLOSE_WAIT) java14130 root 976u IPv4 30842123 TCP localhost:41695-localhost:http (CLOSE_WAIT) java14130 root 977u IPv4 30843217 TCP localhost:42188-localhost:http (CLOSE_WAIT) java14130 root 978u IPv4 30842125 TCP localhost:41696-localhost:http (CLOSE_WAIT) java14130 root 979u IPv4 30842126 TCP efeitws3.ptctax.intuit.com:41697-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 981u IPv4 30842128 TCP efeitws3.ptctax.intuit.com:41698-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 982u IPv4 30842129 TCP localhost:41699-localhost:http (CLOSE_WAIT) java14130 root 983u IPv4 30888558 TCP
Re: Too many open files
- Original Message - From: Johnny Kewl [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, October 08, 2008 1:56 AM Subject: Re: Too many open files - Original Message - From: Mohit Anchlia [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Tuesday, October 07, 2008 11:44 PM Subject: Too many open files Tomcat throws too many open files and when I do lsof I get bunch of: java14130 root 935u IPv4 30842592 TCP localhost:41971-localhost:http (CLOSE_WAIT) java14130 root 937u IPv4 30841213 TCP efeitws3.ptctax.intuit.com:41161-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 938u IPv4 30841214 TCP localhost:41162-localhost:http (CLOSE_WAIT) java14130 root 939u IPv4 30841220 TCP localhost:41165-localhost:http (CLOSE_WAIT) java14130 root 940u IPv4 30842516 TCP localhost:41927-localhost:http (CLOSE_WAIT) java14130 root 941u IPv4 30841226 TCP localhost:41168-localhost:http (CLOSE_WAIT) java14130 root 943u IPv4 30841899 TCP efeitws3.ptctax.intuit.com:41566-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 944u IPv4 30841694 TCP efeitws3.ptctax.intuit.com:41453-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 945u IPv4 30841695 TCP localhost:41454-localhost:http (CLOSE_WAIT) java14130 root 946u IPv4 30841900 TCP localhost:41567-localhost:http (CLOSE_WAIT) java14130 root 948u IPv4 30842415 TCP efeitws3.ptctax.intuit.com:41864-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 949u IPv4 30842416 TCP localhost:41865-localhost:http (CLOSE_WAIT) java14130 root 950u IPv4 30842419 TCP localhost:41867-localhost:http (CLOSE_WAIT) java14130 root 952u IPv4 30850596 TCP localhost:42484-localhost:http (CLOSE_WAIT) java14130 root 953u IPv4 30842760 TCP localhost:42058-localhost:http (CLOSE_WAIT) java14130 root 954u IPv4 30842596 TCP localhost:41974-localhost:http (CLOSE_WAIT) java14130 root 956u IPv4 30842093 TCP localhost:41676-localhost:http (CLOSE_WAIT) java14130 root 957u IPv4 30842195 TCP efeitws3.ptctax.intuit.com:41737-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 958u IPv4 30841730 TCP localhost:41467-localhost:http (CLOSE_WAIT) java14130 root 959u IPv4 30841737 TCP localhost:41472-localhost:http (CLOSE_WAIT) java14130 root 960u IPv4 30842196 TCP localhost:41738-localhost:http (CLOSE_WAIT) java14130 root 961u IPv4 30842528 TCP localhost:41933-localhost:http (CLOSE_WAIT) java14130 root 962u IPv4 30842363 TCP localhost:41836-localhost:http (CLOSE_WAIT) java14130 root 964u IPv4 30842365 TCP efeitws3.ptctax.intuit.com:41837-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 965u IPv4 30842366 TCP localhost:41838-localhost:http (CLOSE_WAIT) java14130 root 966u IPv4 30842367 TCP localhost:41839-localhost:http (CLOSE_WAIT) java14130 root 967u IPv4 30842371 TCP localhost:41841-localhost:http (CLOSE_WAIT) java14130 root 968u IPv4 30842465 TCP localhost:41895-localhost:http (CLOSE_WAIT) java14130 root 969u IPv4 30848501 TCP localhost:42415-localhost:http (CLOSE_WAIT) java14130 root 970u IPv4 30842533 TCP localhost:41936-localhost:http (CLOSE_WAIT) java14130 root 971u IPv4 30842468 TCP localhost:41898-localhost:http (CLOSE_WAIT) java14130 root 972u IPv4 30842534 TCP localhost:41937-localhost:http (CLOSE_WAIT) java14130 root 973u IPv4 30842765 TCP localhost:42062-localhost:http (CLOSE_WAIT) java14130 root 974u IPv4 30842472 TCP localhost:41901-localhost:http (CLOSE_WAIT) java14130 root 975u IPv4 30842122 TCP localhost:41694-localhost:http (CLOSE_WAIT) java14130 root 976u IPv4 30842123 TCP localhost:41695-localhost:http (CLOSE_WAIT) java14130 root 977u IPv4 30843217 TCP localhost:42188-localhost:http (CLOSE_WAIT) java14130 root 978u IPv4 30842125 TCP localhost:41696-localhost:http (CLOSE_WAIT) java14130 root 979u IPv4 30842126 TCP efeitws3.ptctax.intuit.com:41697-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 981u IPv4 30842128 TCP efeitws3.ptctax.intuit.com:41698-10.10.81.94:webcache (CLOSE_WAIT) java14130 root 982u IPv4 30842129 TCP localhost:41699-localhost:http (CLOSE_WAIT) java14130 root 983u IPv4 30888558 TCP localhost:43218-localhost:http (CLOSE_WAIT) java14130 root 984u IPv4 30842617 TCP
Re: video/x-flv mime-mapping does not for Tomcat 5.5
- Original Message - From: Dave [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Tuesday, October 07, 2008 11:03 PM Subject: video/x-flv mime-mapping does not for Tomcat 5.5 we are using JBoss4.0.5. For flash video, we added mime-mapping extensionflv/extension mime-typevideo/x-flv/mime-type /mime-mapping in tomcat conf/web.xml. Restarted jboss. When uploading a foo.flv, uploadeFile.getContentType returns application/octet-stream, not video/x-flv. Could you please help me? -- Hi Dave... Dave not many clients (I think can do FLV)... so your browser probabaly doesnt know what it is, so the server cant sent it... my guess... I think flash files are actually WMV files and inside those files is the FLV format... I know on windows we had to jump thru hoops to make FLV's work... just on their own... I think you have to convert them to WMV's Have fun... --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- If you cant pay in gold... get lost... - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: video/x-flv mime-mapping does not for Tomcat 5.5
- Original Message - From: Johnny Kewl [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org; [EMAIL PROTECTED] Sent: Wednesday, October 08, 2008 2:25 AM Subject: Re: video/x-flv mime-mapping does not for Tomcat 5.5 - Original Message - From: Dave [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Tuesday, October 07, 2008 11:03 PM Subject: video/x-flv mime-mapping does not for Tomcat 5.5 we are using JBoss4.0.5. For flash video, we added mime-mapping extensionflv/extension mime-typevideo/x-flv/mime-type /mime-mapping in tomcat conf/web.xml. Restarted jboss. When uploading a foo.flv, uploadeFile.getContentType returns application/octet-stream, not video/x-flv. Could you please help me? -- Hi Dave... Dave not many clients (I think can do FLV)... so your browser probabaly doesnt know what it is, so the server cant sent it... my guess... I think flash files are actually WMV files and inside those files is the FLV format... I know on windows we had to jump thru hoops to make FLV's work... just on their own... I think you have to convert them to WMV's Have fun... SORRY NOT WMV. SWF its late... waiting for presidential debate ;) --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- If you cant pay in gold... get lost... - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Too many open files
- Original Message - From: Mohit Anchlia [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, October 08, 2008 2:11 AM Subject: Re: Too many open files I can see you can't wait to hear the debate. Anyhow, I am using HttpClient from apache commons and I do have .getReleaseConnection(). The brain surgeons are arriving... ... dont know if thats the cause but its possible Set the instance to null... HttpClient = null; when you done with it... they may do the trick... Have fun... --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- If you cant pay in gold... get lost... - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat default encoding character ? Dfile.encoding option mean ?
albrecht andrzejewski wrote: I ran accros the ml archives, and i find some useful posts. I've almost solved my problem: i can now display the accent (é è à) using request.setCharacterEncoding(UTF-8); response.setCharacterEncoding(UTF-8); It seems that the default charset for tomcat is ISO 8859 1 The j2ee javadoc says: If no charset is specified, ISO-8859-1 will be used. I was pretty sure that tomcat handles UTF-8 by default, but it's not the case...at least for HttpServletResponse objects. Anyway, do you know if it's possible to set up a default charset for the wjole tomcat response, instead of calling these two methods every time a request reach the servlet... ? I tried to define the CATALINA_OPTS, but perhaps the file encoding is different from the request/response encoding. CATALINA_OPTS=-Dfile.encoding=UTF-8 export LC_ALL CATALINA_OPTS Take the following with caution, because I do not really know the underlying reason in Tomcat : I have found that setting the LC_CTYPE environment variable to a UTF-8 locale (or inversely, to a ISO-8859-1 locale) prior to starting Tomcat influences the way in which *some* servlets are reading request bodies and/or encoding request responses. You can do this in the startup.sh script, or probably more correctly in the setenv.sh script, in the Tomcat/bin directory (that is, if your Tomcat is the canonical distribution; if your Tomcat comes from a pre-packaged version, it may not use these scripts for startup). Make sure to use a valid and installed locale. do locale -a choose in the list an installed locale which fits and says utf8 in the name and add it to the script (for example) : LC_CTYPE=en_US.utf8; export LC_CTYPE prior to starting Tomcat. (in the above, I am assuming Unix/Linux; under Windows it may not be feasible). One reason to be careful with this anyway, is that it may have unexpected consequences on other servlets. I believe this happens when the servlet itself is not specifying explicitly the encoding it uses for reading the request body or writing the response, and the JVM then defaults to the locale setting of the process that runs it and Tomcat. In other words, in my opinion your solution above of setting this explicitly in your servlet is the better one. Also make sure that all the html pages that you serve contain a tag like meta http-equiv=Content-Type content=text/html; charset=UTF-8/ If your html pages contain form tags, and you would like the browser to be nice and send you proper UTF-8 encoded form values when posting a form content, then add the following attributes to them, to try and convince the browser to do the right thing : form .. method=POST enctype=multipart/form-data accept-charset=UTF-8 And then, if you design and edit your html pages yourself, make sure that you use an editor that supports UTF-8, and save your pages as such. And then, verify at the browser level (for example with Firefox and the LiveHttpHeaders extension), that the browser is effectively receiving a HTTP header like Content-Type: text/html; charset=UTF-8 with every response from your server. Paranoia : since you cannot trust the user nor his browser anyway, you may still want to add in your forms a hidden input field, containing a set value that is a known string in UTF-8 with some accented characters. Then in your application, you could check if you really received that string as expected. If not, then something unexpected happened with the form encoding, and you should reject the data. Something thus like : input type=hidden value=ÁlélÜìÄ which will have a different string length depending on whether it is encoded as UTF-8 or iso-8859-1 (an é is 1 byte in iso-8859-1, but 2 bytes in Unicode/UTF-8). That is not really paranoia, it's experience. That was the practical bit. If you more general theorising, keep reading. In general, for historical reasons mostly, the default charset/encoding for HTML and HTTP is ISO-8859-1 (latin-1). This is not always clear in all RFCs that contribute to various aspects of web applications however, so there is a certain amount of confusion. For example, the RFCs concerning HTML are quite clear (iso-8859-1 by default), while the RFCs concerning HTTP URIs are more vague or mutually contradictory. In any case, it is (unfortunately) not Unicode/UTF-8 everywhere by default, despite the hopes and beliefs of some web developers. The fact that the internal Java charset is Unicode, and its default external charset/encoding is Unicode/UTF-8, tends to comfort some Java/Tomcat developers in the false belief that URLs also by default are UTF-8, while they are not (as far as I can determine, they are encoding-neutral). Some people also believe that UTF-8 and iso-8859-1 are identical anyway for the first 256 Unicode code points, so it doesn't really matter. But this is also incorrect (only the first 128 codes overlap), and it does matter for anyone trying to build
Re: tomcat ROOT
Johnny Kewl wrote: - Original Message - From: Rusty Wright [EMAIL PROTECTED] To: Markus Lord [EMAIL PROTECTED]; Tomcat Users List users@tomcat.apache.org Sent: Tuesday, October 07, 2008 11:31 PM Subject: Re: tomcat ROOT Hi Markus, did you ever figure this out? I was looking in the archives of the tomcat mailing list and saw your query but it didn't seem to me that anyone answered it fully, at least not for me. I figured out that I could remove/rename the webapps/ROOT directory and deploy my war file as ROOT.war and then it would replace tomcat's web page at http://www.myhost.edu/ but I also have apache in front of tomcat and I don't understand how to set up the jkmount in my httpd.conf file to map apache's root to tomcat's root. Yes renaming a webapp to ROOT with a empty context path, makes it run as the root... Then... JkMount / worker1 Should make apache send it to your tomcat root My naive question then would be : why keep Apache in front of Tomcat, if you are redirecting/proxying everything anyway ? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: video/x-flv mime-mapping does not for Tomcat 5.5
Johnny Kewl wrote: - Original Message - From: Dave [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Tuesday, October 07, 2008 11:03 PM Subject: video/x-flv mime-mapping does not for Tomcat 5.5 we are using JBoss4.0.5. For flash video, we added mime-mapping extensionflv/extension mime-typevideo/x-flv/mime-type /mime-mapping in tomcat conf/web.xml. Restarted jboss. When uploading a foo.flv, uploadeFile.getContentType returns application/octet-stream, not video/x-flv. Could you please help me? I think Johnny's talking nonsense. But he's gone watch the debate, so I can probably get away with this. Seriously, my guess : I think you are confusing what happens on the way in (browser - Tomcat) with what happens on the way out (Tomcat - browser). The mime-mappings above probably only tell Tomcat what it should put in the HTTP response headers as Content-type when *returning* such a file to the browser. On the way in, on the other hand, it is the browser that guesses the file type, and sends this to the server as part of the POST data. The server then just picks up what the browser says. If the browser doesn't know what the file is, it will probably in this case determine that the file is binary (not text), and since it does not know a precise type, it will send it with a type application/octet-stream, which is the standard safe Mime type for any binary file you do not really know the type of. Try the following : somewhere in your browser or your operating system, there must be a way to specify that ..for this file type .. do this. Do that for this file type, and then try to resubmit the same file to your Tomcat application and see what it says. If it then works, unfortunately that is only a solution for your own browser and your own workstation. In order to determine the file type correctly no matter which browser it comes from, you probably have to do it in your application. There exist standard modules/add-ons/libraries/subroutines in most programming languages, that can make guesses at the mime type of a file. Unfortunately in Java I personally don't know what it would be. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cannot seem to see deployed application
it's a clean download tar.gz from apache. markt-2 wrote: cooper5114 wrote: Apache Tomcat/5.5.26 OS = RH ES 5 Is this a clean Tomcat install from an Apache tar.gz distro or are you using RedHat packages? Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/cannot-seem-to-see-deployed-application-tp19856874p19870578.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
