Re: users Digest 22 Nov 2010 20:46:42 -0000 Issue 10094
"Nicholas Sushkin" wrote in message news:201011221714.26614.nsush...@openfinance.com... On Monday, November 22, 2010 15:46:42 users-digest-h...@tomcat.apache.org wrote: On behalf of the Tomcat committers I am pleased to announce that Christopher Schultz (schultz) has been voted in as a new Tomcat committer. Please join me in welcoming him. Mark Do you mean he wasn't?! Oh, I should've ignored all his posts! ;) That is the thing about Open Source. Anyone can download the code and look through it, learn it, and answer questions/supply patches. When we get tired of applying your patches, we say "do it yourself", and elect to committer ;). -- Nicholas Sushkin - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem redirecting http to https in Tomcat 4
Tomcat 4.x is well know to have problems with this when using a non-default SSL port with MSIE. However, it usually works ok with the default SSL port. I would check that you have the correct redirectPort defined in the for the non-SSL connector. "Robedan" wrote in message news:29151597.p...@talk.nabble.com... I have an application that has a Web interface using an embeded Tomcat 4 Server. I need to make it available to users over the Internet and want to secure it with SSL. It originally worked on port 8080 but I successfully modified the SERVER.XML to make it work over port 80. I also sucessfully created an SSL connector so that if you specify https://myserver.domain.com you can access the app over SSL on port 443. The final piece of the puzzle I've been struggling with is automatically redirecting http: requests to https: All the Tomcat forums say this is pretty simple, all you need to do is add a bit of code to either the server or app's web.xml: Protected Context /* CONFIDENTIAL When I enter this code and restart Tomcat, the app stops working on all ports. I just get a '404' resource not found on the default page or any other. I'm sure I'm missing something but I have no idea what. Are there Any Tomcat gurus out there that can point me in the right direction? -- View this message in context: http://old.nabble.com/Problem-redirecting-http-to-https-in-Tomcat-4-tp29151597p29151597.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
Re: the welcome file "index.jsp" returns an 302 redirection
"lei jiang" wrote in message news:aanlktin0dhodp9brzlx589xkvuz4dar0dnklry637...@mail.gmail.com... Hi, guys: I am using the Tomcat 5.0.28.0, and I put the my website into webapps directory. The welcome-file-list section likes this: index.jsp In the index.jsp, I use the jsp:forward tag to forward the request to a struts action: When I input "http://localhost:8080/mysite"; into the address bar of firefox and hit go button, the browser shows the correct page but the url in address bar changed to "http://localhost:8080/mysite/welcome.do"; I find that the tomcat returns a 302 redirection and then the tomcat returns the page generated by "welcome.do" action So what can we do to aviod the 302 redirection and let the address bar just show "http://localhost:8080/mysite";. What Pid said: Later versions than 5.0.x do an internal forward to the welcome-file, so the browser doesn't get to see the actual path to the welcome-file. There are a couple of other sordid hacks using servlet-mapping that I'll admit to using on currently unsupported versions of Tomcat. Thanks Regards -- Lei Jiang Member of SeedClass in the Department of Electronics and Information Engineering Member of Overseas group in Dian team Room 507, Building D7,1037 Luoyu Road, Wuhan 430074,P.R.China Mobile:+86-15926351274 Email: - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0 always uses default host in multi-host config
Allow me one more attempt at a clear doc? 1) If useIPVHosts=false (default), then the host header name determines for processing, or default host of the Engine. 2) If useIPVHosts=true, then IP address of request determines for processing, providing the IP is provided as the host name, or . If not found, then default host of Engine applies. The actual rule is that Tomcat uses the value of request.getLocalName() to determine the . So this is not completely true if you are using an AJP connector. In this case, Tomcat uses the ServerName for the VirtualHost that Apache picks. So if Apache is using named virtual hosts, they you get the one that it resolved to in Apache. If you are using a HTTP/1.1 connector, then this is the name that the IP address resolves to on the machine where Tomcat is running. The useIPVHosts=true is useful when running with an AJP connector if you have a lot of ServerAlias directives and/or change them often. It means that the admin only needs to make the change to Apache without having to make the corresponding change to Tomcat. 3) Nothing external to server.xml matters to Tomcat in resolving for processing. Well, not other than DNS resolution for a HTTP/1.1 connector when using true. If you change the DNS name of the machine, then you need to change server.xml as well. Does that sound accurate? Jeff (not the OP) *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and 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 or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Missing commons-el.jar causes NoClassDefFoundError org/apache/commons/el/ExpressionEvaluatorImpl
"Caldarale, Charles R" wrote in message news:99c8b2929b39c24493377ac7a121e21f98e46de...@usea-exch8.na.uis.unisys.com... From: Greg Bondy [mailto:gbo...@starmountsystems.com] Subject: Missing commons-el.jar causes NoClassDefFoundError org/apache/commons/el/ExpressionEvaluatorImpl (I was wondering when this would get transferred from the dev list :-) I am migrating from Tomcat 5.5.27 to 6.0.26. I found that an application I have running on 5.5.27 fails on 6.0.26 with the error: NoClassDefFoundError org/apache/commons/el/ExpressionEvaluatorImpl. I found that the class in question is located in commons-el.jar on 5.5.27 and that jar is missing from 6.0.26. Looks like that class was replaced by org.apache.jasper.el.ExpressionEvaluatorImpl, located in jasper.jar, probably to avoid conflicts with webapp usage of the same. No, it was because the Tomcat developers forked el development to Tomcat. After GlassFish forked, commons-el no longer had enough developers. The application is using Spring 3.0.1 and it appears that has a dependency on org.apache.commons.el.ExpressionEvaluatorImpl. I could not find any explicit reference to that class in the Spring code. Is it possible that there's a reference to it in your Spring configuration? Can you tell me the reason for removing commons-el.jar. Is there a better remedy to the NoClassDefFoundError problem other them copying the jar file from 5.5.27? Try it, but place it in your webapp's WEB-INF/lib directory, not in Tomcat's lib directory. - 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: a servlet-related Java question
"Christopher Schultz" wrote in message news:4bcf5f41.6060...@christopherschultz.net... -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 4/21/2010 3:46 PM, André Warnier wrote: Mark Thomas wrote: On 21/04/2010 20:24, André Warnier wrote: Mark Thomas wrote: ... I'd just use JAD and decompile it. Thanks. But although my intentions are not obnoxious nor illegal nor anything of the kind, I would not want to even come under suspicion of reverse-engineering. So is there something that just lists the standard calls/methods used in it ? No. You can see the methods it exposes, but not the methods it uses. Time to add some debug code to your wrapper to see what is being called? Mmmm. :-( How do I do that, assuming I do not know in advance which methods it calls ? Do I need to define all the methods of HttpServletRequest in my wrapper, just to make them trace their call ? Or does there exist some more dummy-user-friendly methodology ? It's pretty inaccessible for novice Java programmers, but you could use the "proxy" API which is jsut about the coolest thing available in Java IMO. This is how you do the wrapping of the request: import java.lang.reflect.Proxy; import java.lang.reflect.InvocationHandler; public class RequestMethodCallLogger implements InvocationHandler, Filter { public void doFilter(...) { HttpServletRequest wrappedRequest = Proxy.newProxyInstance(HttpServletRequest.class.getClassLoader(), new Class[] { HttpServletRequest.class }, this); chain.doFilter(wrappedRequest, response); } public Object invoke(Object proxy, Method method, Object[] args) { // Log to your favorite logger here return method.invoke(proxy, args); } } Basically, the Proxy class allows you to intercept the calls to interface methods. The implementation of the "invoke" method is just a pass-through to the "real" method after logging (an exercise left for the reader). This can be optimized a bit if you need to use it long-term, but the above is about as compact as it gets. If it does a forward or include done the line, this won't work with any remotely recent version of Tomcat. These versions enforce the spec requirement that the Request has to be a subclass of HttpServletWrapper wrapping the original request, or the original request. I'd still recommend the use of jad, honestly. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvPX0EACgkQ9CaO5/Lv0PCKVQCdG5SMXiySnsFEowVF7/44KM8s b7kAoIAGSzxOIWmKt4+z6ATkqslTl5uW =ykwF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat startup error
"Christopher Schultz" wrote in message news:4bbf945e.4050...@christopherschultz.net... -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harry, On 4/9/2010 2:01 PM, Harry Metske wrote: you are using some piece of software (com.mypkg.packaging.*) that is calling tomcat code. It expects to find a method in org.apache.tomcat.util.IntrospectionUtils that is no longer there in 6.0.26, which causes the NoSuchMethodError. Basically your embedder does not support this version of Tomcat, you should contact the vendor, they should do the recompile . It's interesting that the Java Runtime throws a NoSuchMethodError since the return type is not technically part of the method signature. I've never considered this before, and it totally makes sense because the return type really is an important part of the method. Just interesting to note that the effective method signature is not the same as the official one. Another thing to note is that the Tomcat folks have made an unstable change, here, by changing a public API. It would have been better to create a method with a new signature and deprecated the old one, while leaving it there. The Tomcat developers have always considered this to be part of the internal API, not the public API. This is true of most of the classes under the org.apache.tomcat package. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku/lF4ACgkQ9CaO5/Lv0PCHaQCguLBWWaK6kp+md88Hxo3dGZ4z itEAnjsMKVr6fWyJG44nbNJGFUKLDsU1 =ER++ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Enabling HTTP Put
"André Warnier" wrote in message news:4bb5a06e.4080...@ice-sa.com... Stacy Mobley wrote: Hi, I was wondering if there was a way to enable HTTP Put via the API's. What makes you think it is not enabled ? (at least, presuming you are talking about Tomcat) I've tried using ServletContext.setAttribute("readonly", "false") without any success. What would that have to do with "enabling" HTTP PUT requests ? I think that the OP wants to enable PUT in the DefaultServlet in an embedded configuration. If my psychic powers are even close, then the OP needs to override the settings for DefaultServlet in his own web.xml to enable it. It looks like it would be possible from the Embedding API, using a totally obscene combination of JMX and reflection ;). Tomcat itself does not forbid or disable any type of valid HTTP request, PUT included. Now, it is your responsibility to provide an application, within Tomcat, which can handle PUT requests. For an example, look at the DAV application usually distributed along with Tomcat. That one allows appropriate clients to upload files to a server, and this works among other things via PUT requests. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP java client
As far as I know, only Apache Jakarta-JMeter has a Java AJP client. You can look there for how to set one up. "Andrew Bruno" wrote in message news:t2o9b906c961003310002j519ef867p3ead196614483...@mail.gmail.com... Hello all, I have a situation where I wish to break up my web application, but wish to maintain the same domain as the front end URL. All customers log in via a single domain using their email address as a username. The email address gives them access to their customer repository data (lucene, etc), which is only accessible by that customer account. I would like to split the web app up, so that the front end server has smarts to know which backend tomcat server to redirect to. As far as I know, Apache AJP can be configured to redirect to different tomcat backend servers by implementing rules, ideally URL based. But for me, the URL is always the same. So, I was wondering if there was a way to code an AJP client inside a front end tomcat server, so that I could redirect to whatever backend server the business rules decided. 1. Login Screen on front end server 2. User attempts to log in, verify against DB, and then work out which back end tomcat server to AJP to. 3. All traffic goes via front server one to the decided backend server 2. any other ideas are also welcome Thanks Andrew - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Win7 calling native code via JNI
"Caldarale, Charles R" wrote in message news:99c8b2929b39c24493377ac7a121e21f96d2507...@usea-exch8.na.uis.unisys.com... From: Patrick Flaherty [mailto:pflah...@rampageinc.com] Subject: Win7 calling native code via JNI as soon as I call the dll's init function (CPPInit) it crashed the JVM. Are you using the same JVM when you run Tomcat as a service? The one in this crash is the 32-bit client, but you're on a 64-bit platform, and I wouldn't be surprised that the service is using a 64-bit server JVM (assuming you have one installed). It wouldn't even get that far if he tried to load a 32-bit dll in a 64-bit JVM. My guess is an incompatibility in the MSVCRT.dll versions. If you compile the JNI dll with a newer version of MSVC, then you can see weird crashes like this. If you look at the code you will see I try to create a file on the root of the C drive (remotedebug.txt) and Does the account you're running on have permission to do that? (Win7 is a tad picky about things like that.) - 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: org.apache.jk.config.ApacheConfig modJk
"Christopher Schultz" wrote in message news:4b9d8435.50...@christopherschultz.net... -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Todd, On 3/14/2010 1:41 PM, Todd Hicks wrote: This may be a question better suited for the dev list, but I thought I'd try here first. I've been troubleshooting a problem in one of my installations and was reviewing the documentation here: http://www.docjar.com/docs/api/org/apache/jk/config/ApacheConfig.html (the auto-config listener class) when it caught my attention that the path to the Apache mod_jk plugin file defaults to "modules/mod_jk.dll" on windows (if the modJk option isn't set), yet the Apache connector for windows is distributed as mod_jk-1.2.30-httpd-2.2.3.so (to be renamed to mod_jk.so). Is this just legacy and needs to be updated or am I missing something? Should I report this as a bug? The real bug is that the ApacheConfig class still hasn't been put out of its misery. Basically, nobody should ever use the ApacheConfig class because it re-writes your mod_jk.conf file every time Tomcat starts. This class has been removed from TC 7. And yes, is only somewhat works with the retired httpd 1.3.x version, so nobody should ever use it. You're better off reading the documentation for mod_jk and building your own configuration file. It's not hard to set up a mapping for simple things like *.jsp -> Tomcat and stuff like that. Once you've got the simple stuff working, extending your configuration to include more exotic options is still very easy. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkudhDUACgkQ9CaO5/Lv0PBUAQCfU6a4LrhrAZORb7zbzVIXRjOc msUAniENxyXg+emGX9Ha3JmeKJSjNFWl =uBUr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Access to Tomcat's MBeans
"Pid" wrote in message news:4b8e40b8.9070...@pidster.com... On 03/03/2010 06:32, Caldarale, Charles R wrote: From: Cummins College [mailto:cummins.grou...@gmail.com] Subject: Access to Tomcat's MBeans Could someone please help us how to access Tomcat's Mbeans using Java code. This is not a direct answer, but you could download the source for Lambda Probe (www.lambdaprobe.org) and see how it does it. Or examine the source code of the Manager app, which I believe does that. A good suggestion. If you are running with a SecurityManager, then you will probably be SOL (and rightly so). Otherwise, the main problem that has been reported here is to find the correct MBeanServer, so if you don't mind programming against Tomcat, using it's Registry class (http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/tomcat/util/modeler/Registry.html) saves pain if there are multiple MBeanServers, but this assumes that you are using TC 6.0.x. Otherwise, startup Tomcat once with remote JMX enabled, and browse with the remote client to find the ObjectNames that you want, and just use normal JMX calls. Otherwise, it's the same as anything p - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: check number of http connection in tomcat
"Caldarale, Charles R" wrote in message news:99c8b2929b39c24493377ac7a121e21f96cb875...@usea-exch8.na.uis.unisys.com... From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: check number of http connection in tomcat 1) the correct link is probably : http://XXXx:8080/manager That will get you a 404 (at least on non-stone-age Tomcats). The actual manager URL is: http://XXXx:8080/manager/html It's nice to see that 3.3.2 is still so popular. I've gotten two questions about it in one week :). Actually, the OP had the correct URL for TC 3.3.2. It's called admin there, but works more like the manager for TC 4.0+. Since it is from the stone-age, it has considerably less functionality. To answer the OP, the instructions are in the index.html file under the /webapps/admin directory. The short answer is that if you haven't changed the conf/apps-admin.xml (yes, TC 3.3 was the first one to have context configuration files), then you need to edit the conf/users/admin-users.xml to enable a user for the admin app. The file posted by the OP is in the wrong format (it is for TC 4.0+). Of course, one of the things that the TC 3.3 admin app lacks is the ability to show the number of connections, so this will likely be of little use to the OP ;). It mostly lets you start and stop webapps. Since it shares connectors with later Tomcat versions, this information is available via JMX however. - 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: Tomcat threads
"Caldarale, Charles R" wrote in message news:99c8b2929b39c24493377ac7a121e21f96cb817...@usea-exch8.na.uis.unisys.com... From: Bill Barker [mailto:billwbar...@verizon.net] Subject: Re: Tomcat threads basically the request is handed off to another thread and the original one returns to the pool. This also allows for two-way communication instead of relying on polling. What's required on the client end? You can't simply push HTML or other content to a browser. Is a specialized (or at least scripted) client required? Mostly useful for custom clients channeling under HTTP, but you could probably write a scripted client as well that works with it (haven't tried). The examples in Tomcat 7 are mostly server-push (e.g. fake stock ticker, chat). These are done by not completing the connection, and just pumping more data to a chunked response (so you get the spinning wheel the entire time the apps is running). They work in most browsers (only most, because I've only tested them in IE and FireFox). But as I said before, would probably help the OP, assuming that traffic isn't too great. - 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: Tomcat threads
"Caldarale, Charles R" wrote in message news:99c8b2929b39c24493377ac7a121e21f96cb817...@usea-exch8.na.uis.unisys.com... From: Bharath Vasudevan [mailto:bharath@gmail.com] Subject: Re: Tomcat threads If we get a request on a thread, let some other thread do the work for it and store the response info. The thread which does the work writes the response on that request. If the processing is fast, why would you go to the complexity and overhead of switching to another thread to process the request? You should also read the servlet spec, in particular SRV.2.3.3.3: "Implementations of the request and response objects are not guaranteed to be thread safe. This means that they should only be used within the scope of the request handling thread. "References to the request and response objects should not be given to objects executing in other threads as the resulting behavior may be nondeterministic. If the thread created by the application uses the container-managed objects, such as the request or response object, those objects must be accessed only within the servlet's service life cycle and such thread itself should have a life cycle within the life cycle of the servlet's service method because accessing those objects after the service method ends may cause undeterministic problems." The illogical behavior you're asking for simply isn't allowed. At least not until Tomcat 7 ;). In there, you can do exactly what the user is asking for using the AsyncContext. The details are in the Servlet 3.0 spec, but basically the request is handed off to another thread and the original one returns to the pool. This also allows for two-way communication instead of relying on polling. Of course Comet offers similar functionality in Tomcat 6 if you don't mind being bound to Tomcat. - 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: remote debug with tomcat 3.3.2
I'm pretty sure that I compiled the binary for 3.3.2 without debugging support. The only thing I can think of is to download the source release of 3.3.2 and compile it with debugging. At the time 3.3.2 was released, using a debugger in Java was so painful that almost nobody did it. "Kedzior Wojciech" wrote in message news:a8dd7b2abeb7b842af607d392ff73c7ee4834af...@croexcfwp03.gemalto.com... Hello, I'm having a problem with setting up a remote debug session to my Tomcat 3.3.2 Final. I am copying some classes I developed into the working directory of an application deployed on tomcat. I can connect to the remote debug port from eclipse but the debugger will not stop on any break points what so ever. Here is my environment: I specify the following system variables: JPDA_ADDRESS=8000 JPDA_TRANSPORT=dt_socket I start my Tomcat with the jpda start parameters. While tailing the logs I can see the following line: Listening for transport dt_socket at address: 8000 At this point I can connect to the remote debug port from Eclipse. I can see all the treads running within Tomcat, but my debug will not stop on any breakpoints. Even though the class I am trying to debug was created by me in Eclipse and I have the correct source. The classes were compiled using Java 1.5.0_09. Tomcat also uses the same version of Java. The tomcat is deployed on Linux RedHat 5. Eclipse version is 3.5.1 The complied classes have a reference to the .java file. To prove that the problem occurs with the entire deployment I obtained the sources for the deployed application, linked them in my eclipse and set some debug points. I know the flow goes through the line with break points because I used some dirty System.err output to prove this. One thing that may be a hint is that the Tomcat startup log shows the following line: EmbededTomcat: Startup time 45 The thing to note here is that I don't have control over the actual war file deployed in tomcat. I simply get the war from a different department in the company, deploy it, and write some classes that the deployed application will pick up and use. I have studied this Embedded Tomcat a little bit and I don't know if this could be a problem. Has someone experienced anything like this before? If so, I would appreciate it very much if you could shed some (even the dimmest) light onto this. Thanks, Wojtek Kedzior - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache / mod_proxy / Tomcat
"André Warnier" wrote in message news:4b6ca79c.3090...@ice-sa.com... Farid Izem wrote: Hi, I have setup an Apache Web Server in front of a Tomcat Web Container. Basically, All request are handle by Apache and passed to Tomcat using mod_proxy_ajp Apache is binded on the IP address of the computer, tomcat is binded on localhost:8009 When i take a look at the tomcat manager, i see that a lot of Tomcat Thread with the status keepalive from the same source IP address. The main configuration of : ProxyPass /webapp ajp://localhost:8009/webapps retry=30 ProxyPassReverse /webapp ajp://localhost:8009/webapps Would it be possible to free the connection from Apache Server to Tomcat server ? Netstat show a lot of established connections but there is not data sent. How could we free these keepalive connections that are being maintained between Apache and Tomcat. i tryied ProxyPass /webapp ajp://localhost:8009/webapps retry=30 disablereuse=On but this is not recognize. I don't know about the above settings. Apart from what Chuck mentioned, what is the setting, in the Apache httpd configuration, of the KeepAliveTimeout ? If you set that to 30 seconds, then it means that after the browser sent the last request that it is ever going to send, Apache will maintain the connection with the browser for 30 seconds, waiting for another request that will never come. That probably means that it will also maintain the connection with Tomcat, and thus that Tomcat will keep the corresponding thread waiting for the same time, all for nothing. Set KeepAliveTimeout to 3 for example, and see what happens. That will help Apache, but will have a relatively small effect on number of AJP/1.3 connections. That is because the AJP/1.3 connections are shared across different browser connections by design (and why not clearing data in a ThreadLocal can end up sharing data between users). And with the default settings, AJP/1.3 connections last forever. If someone actually cares about the number of connections (which some old Linux kernels do), then set a connectionTimeout to a reasonable value (say 5min) in the Tomcat tag in server.xml. That will cause Tomcat to close the connection when it times out, and Apache can establish a new connection when necessary. With mod_jk, this works best if you also configure it to use cping/cpong. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Security
wrote in message news:fb91a4c0c0682.4b6a8...@quicknet.nl... We are running a few web applications on Tomcat 6 on a Windows Server 2003 system in a Windows 2003 Active Directory Forest. How to make the Tomcat environment secure (hardening)? I read about security manager, but how to add the web applications in the cataline.policy? Is it possible to use Windows Authentication? Are there more possibilities? If they are your apps, then a security manager just adds overhead in production (although it's not a bad idea to run it in development). After all, you can just fire the developer that inserted a back door into the app ;). Ronald - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Updating CRL in Tomcat 6 without taking it down
"Praveen Pat" wrote in message news:4457dc171002041505p239b835p5107c8efa8f1d...@mail.gmail.com... Hello: I am running Tomcat 6 in SSL mode with ClientAuth=true. Here are my Connector Properties: The problem I have is how to update the CRL. If I do not update the CRL, Tomcat does not let any of my users in. It blocks all the users. To update the CRL, I have to stop the Tomcat, and I am trying to avoid it. This can't be done easily. The CRL file is read only when the Connector is initialized, it isn't tracked after that. It is possible to stop and start the Connector using JMX (or otherwise for Embedded), which is a little bit better than restarting Tomcat. But I haven't tried doing this myself, so there may be other issues that get in the way. Thanks in Advance. Regards, Praveen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Ajp port in use - tomcat using next available port
"Mark Thomas" wrote in message news:4b57bb79.3010...@apache.org... On 20/01/2010 17:08, Christopher Schultz wrote: Paul, On 1/20/2010 4:08 PM, Paul Guglielmino wrote: I'm setting up the server to only listen on an ajp port (8009). If I already have something listening on that port then tomcat starts listening on the next port number (8010). This doesn't happen if the shutdown port is already in use or if I try it with a http connector port that is in use. I don't seem any mention of this behavior in the docs. I do see an autobind option for clustering which will turn on behavior like this but I'm not using clustering. I don't see any mention of the auto-port-choosing for s, either. Are you doing this manually? It is an undocumented feature of the org.apache.jk.server.JkCoyoteHandler implementation. Setting maxPort to the same value as port should disable it. I think that mod_jk2 had logic to handle discovery. Granted, it isn't a very useful feature with mod_jk. Alternatively use the newer (and default in Tomcat 7) org.apache.coyote.ajp.AjpProtocol implementation. And currently the only pure Java implementation in Tomcat 7 :). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question about AJP Connector Configuration
"scotthamilton77" wrote in message news:26981946.p...@talk.nabble.com... > > Hi, > > I'm using Tomcat 6.0.20 fronted by Apache 2.2.10 with mod_proxy_ajp. I'm > trying to figure out some tuning/tweaks to our AJP connector, and have run > into some oddities I am not sure about and want to see if someone can shed > some light on this. > > The primary problem I'm trying to solve here is the effect of > keepAliveTimeout at the connector level. I'm reading > http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html and it tells me > that > this is "the number of milliseconds this Connector will wait for another > AJP > request before closing the connection. The default value is to use the > value > that has been set for the connectionTimeout attribute." > > Here's the kicker - I can't see where this ends up getting used - the > behavior of the connector threads (watching them thru jconsole for > instance) > doesn't seem to change no matter what I configure this to. Furthermore, > tracing thru the code, it looks like this setting is not even used (tho I > could be missing something here). The Connector class tries to do a > setProperty for keepAliveTimeout on the JkCoyoteHandler class instance, > which doesn't have a setter for this, so it goes into a properties map > which, if I am following the code right, never gets used (meaning this > particular keepAliveTimeout setting never gets pulled out). > Yes, the keepAliveTimeout is ignored by the JkCoyoteHandler AJP connector. Only the connectionTimeout is used. The documentation should be cleaned up, since it is currently a mix of options that are supported by the different AJP connectors but not necessarily by others. > I tried using tcnative under Windows to see if that made any difference, > and > indeed it does - setting a value for keepAliveTimeout DOES get set but > then > once that timeout occurs, my CPU utilization goes to 100% and my system > crawls to a halt until I kill the tomcat java process. > > So... can someone explain whether the connectionTimeout and > keepAliveTimeout > really do anything (useful) for AJP? What am I missing? > > Thanks in advance, > Scott > -- > View this message in context: > http://old.nabble.com/Question-about-AJP-Connector-Configuration-tp26981946p26981946.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
Re: Using RemoteAddressValve with an Apache mod_proxy_balancer
"Mark Thomas" wrote in message news:4b2e4e77.3000...@apache.org... > On 20/12/2009 16:04, André Warnier wrote: >> In other words : it seems that quite early in the request process, a >> decision is taken to *replace* the remote IP address as obtained from >> the socket, by the ultimate IP of the client for which this proxy >> request is being processed. This casts a doubt on the ability of even a >> servlet filter to obtain the IP address of the proxy server which has >> the real connection with Tomcat. >> >> >> All a bit beyond my dabbling capabilities, I'm afraid. > > This is one of those times where the solution will depend on the > protocol you are using. > Exactly. The AJP/1.3 protocol doesn't consider itself to be a proxy (and anyone old enough to remember it's predecessor mod_jserv will see why), but rather an integration of Tomcat with the native server (more like mod_fcgid).This means that last hop is considered to be the native server. The protocol itself is even transport agnostic, and in the past it has been possible to run Tomcat inside of IIS/Apache or even to use Unix Sockets. > The AJP connectors will report the client's IP address so you need an > alternative solution. Using the "request.secret" attribute is probably > the simplest fix although keep in mind that AJP is clear text so the > secret might not be that secret. > Yes, AJP/1.3 assumes that the connection between the native server and the Tomcat server is secured, so that if someone can sniff AJP/1.3 packets it means that the system is already badly compromised. If using mod_jk, then yes, the 'secret' is the simplest way to go. If using mod_proxy_ajp, then you need to head on over to submit a patch for httpd to add this configuration option (most of the active developers of mod_proxy_ajp lurk on this list if you need help, but d...@httpd.a.o is the official list for this). The table of 'names' for the two supported protocols is: Name HTTP/1.1 AJP/1.3 serverNameHost header Host header remoteName last proxy server (or client if no proxies) last proxy server before native server (or client) localName The name the connector is bound to name of native server (i.e. the ServerName) Which gives a third option to the OP, which is to use the useIPVHosts="true" option on the , and only configure s for the ones that he wants to allow to connect (and the default Host just returns 404 to every request). > The HTTP connectors will report the proxy's IP address so the > RemoteAddressValve can be used. > Note in Tomcat 7: > - where the RemoteIpValve is available you would need to make sure that > the RemoteAddressVlave was earlier in the pipeline than the RemoteIpValve > - you have the option of using Valves or Filters for this functionality > > HTH, > > 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: Using RemoteAddressValve with an Apache mod_proxy_balancer
"André Warnier" wrote in message news:4b2caede.6070...@ice-sa.com... > Bill Barker wrote: > ... >> If you have a svn checkout, then the command: >> svn diff LocalStrings_fr.properties > LocalStrings_fr.properties.patch >> will do it. Alternatively, Cygwin has a Unix/Linux like diff utility. >> >> Also, for a translation, it's probably not too bad if you just attach the >> fixed file. The developer who grabs this can then run the "svn diff" >> command to review it. But if it is either Mark or myself, then we >> probably won't really be questioning the translation ;). > I tried to submit a patch file. > I actually have an SVN client on my pc and it has a "generate patch" > option. Neat. > > Bugzilla : Bug 48413 has been added to the database > > > To get back to the main issue, as long as I anway get the hang of this > stuff, and have checked out the SVN of Tomcat anyway, > where in the /valves stuff do I find where it actually checks the "remote > IP" against which RemoteAddressValve operates ? > > And, supposing I were to tweak one or the other module, how do I create a > local version of Tomcat to test my changes on ? > This is exciting stuff... ;-) > Look at the BUILDING.txt file in the top level Tomcat directory. The only thing that it omits seems to be that the local Tomcat will be in the ${tomcat.source}/output/build directory. > If this is too vast as a question, just let me know and point me where to > get started maybe ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using RemoteAddressValve with an Apache mod_proxy_balancer
"André Warnier" wrote in message news:4b2bdc92.9050...@ice-sa.com... > Christopher Schultz wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Mark, >> >> On 12/18/2009 11:42 AM, Mark Thomas wrote: >>> On 18/12/2009 16:21, André Warnier wrote: or do I need some special editor or setting, or do I just convert these codes to their UTF-8 equivalents and submit it as such ? >>> You can use: >>> http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/native2ascii.html >>> to convert the file. You can then edit it and then convert it back >>> before submission. >> >> We use "Attesoro" for our projects: >> http://attesoro.org/ >> >> You'll need both the LocalStrings_fr.properties and >> LocalStrings.properties files in order to use it effectively. >> > I got it converted fine to something usable with the native2ascii.exe > utility, part of the Sun JDK 1.6 on my pc. > I have the fixed version. > Now I just need to figure out how to create the diff that Mark wants. > I know under Unix/Linux it's easy. On my WinXP workstation it requires a > bit more research.. If you have a svn checkout, then the command: svn diff LocalStrings_fr.properties > LocalStrings_fr.properties.patch will do it. Alternatively, Cygwin has a Unix/Linux like diff utility. Also, for a translation, it's probably not too bad if you just attach the fixed file. The developer who grabs this can then run the "svn diff" command to review it. But if it is either Mark or myself, then we probably won't really be questioning the translation ;). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Logging all traffics to Tomcat servers
"Christopher Schultz" wrote in message news:4b2aa7c4.1060...@christopherschultz.net... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Fidelis, > > On 12/17/2009 3:42 PM, Fidelis Mnyanyi wrote: >> Thanks Konstantin for your response. I tried to use AccessLogValve, >> but noticed I can only capture successful logins. I would like to be >> able to capture all unsuccessful attempts as well for security-audit >> reasons, is this possible through Tomcat? > > Really? Tomcat doesn't log requests to j_security_check through > AccessLogValve? > Unless you are configuring the FormAuthenticator your self, it should log j_security_check (since the default behavior is to add FormAuthenticator after any Valve in context.xml). > Note that AccessLogValve will not directly log "failed logins": it only > logs HTTP requests and their statuses, etc. You will have to deduce from > the status code what happened during the request. > In particular, a 302 status code means success, and a 200 status code means failure (or, rather, what ever status code the error page returns). > If you want to actually log failed logins, you'll need to use something > other than the standard realms Tomcat provides (except maybe > JAASRealm... I've never used that one but it appears that it is much > more flexible than the other realm implementations). > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAksqp8QACgkQ9CaO5/Lv0PATzACghn0Apk8uew1/et9QUK6t2HTW > InoAnAzcwEbLLnxwIfDUgLJUfwPdivrJ > =btRk > -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using RemoteAddressValve with an Apache mod_proxy_balancer
"André Warnier" wrote in message news:4b294eb6.4090...@ice-sa.com... > Martin B. Smith wrote: >> Howdy! >> >> I'm trying to ensure that only specific instances of Apache are allowed >> to proxy requests into my Tomcat 5.5.28 instances. Unfortunately, it >> looks like Tomcat is seeing the actual client IP making the original >> request to Apache. Does anyone have a configuration that only allows >> specific Apache (mod_)proxies to be serviced by Tomcat? >> > Of course if your are under Linux, you could use iptables to block > requests to port 8009, from hosts you don't like. > And if you are under Windows, you could use the Windows firewall or > filtering rules. > Probably even more efficient than doing this at the Tomcat level. Yes, but if the OP wants to block all access to Tomcat, it is even easier to just not have the worker configured on those Apaches that shouldn't contact it. As a result, I'm guessing that the OP wants to restrict access to certain webapps. The good news is that with the AJP connector, request.getLocalName() returns the name of the Apache server (as specified by the ServerName directive), not the Tomcat server. And request.getLocalAddr() returns the IP address of request.getLocalName() as it resolves on the Tomcat machine. With that information it isn't hard to write a Filter that does what you want. For the truely lazy, it would also be trivial to copy RemoteAddrValve to LocalAddrValve and have it check localAddr instead of remoteAddr. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT - question] Limit user sessions in tomcat
"Caldarale, Charles R" wrote in message news:99c8b2929b39c24493377ac7a121e21f9680850...@usea-exch8.na.uis.unisys.com... >> From: André Warnier [mailto:a...@ice-sa.com] >> Subject: Re: [OT - question] Limit user sessions in tomcat >> >> It would seem that there ought to be some low-level response-direction >> socket flag that should be available, to tell whether the receiving end >> has gone, without actually having to send anything from a higher-level >> code module. But getting to that low-level socket data does not seem >> to be so easy in Java, is it ? > >It's not hard in Java (Socket.getRemoteSocketAddress() or >Socket.isConnected() should work), but there's nothing in >the servlet spec >that allows a servlet thread to obtain for that information. Ideally, the >container (Tomcat) would >asynchronously monitor the socket status and set >some flag in the Request object for the webapp code to examine at >its >leisure. Might also be able to implement this with a new form of listener. > >I haven't looked at the Servlet 3 spec to see if anything is in there for >this rather common problem. > The Servlet 3 spec has something close: Asynchronous requests (which are sort of like Comet in TC 6). It's more designed to allow the servlet to push content to the client (think a JavaScript progress bar). > - 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: 'Parametrizing' context.xml?
"Mario Splivalo" wrote in message news:4b27994e.5080...@megafon.hr... > Bill Barker wrote: >> "Mario Splivalo" wrote in message >> news:4b266622.5060...@megafon.hr... >> >> Tomcat also supports ant-style variable replacement, so using that then >> Ken's example would look like: >> >> baseprefix >> ${BPVAL} >> >> >> where BPVAL is a Java system property (that can be set in >> catalina.properties for example). > > And, those can be used also in apps context.xml? > Yes, this should work in context.xml (and even server.xml). >> Of course, this only works for Tomcat. Ken's suggestion will work on any >> servlet container. > > Yes, in the long run I'll stick to those, but since we're only using > Tomcat for now it would be much easier not to fiddle with ant. > > Thank you all! > > Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 'Parametrizing' context.xml?
"Mario Splivalo" wrote in message news:4b266622.5060...@megafon.hr... > Is there a way to 'parametrize' context.xml, for instance, in a manner > one can 'parametrize' build.xml? > > For some webapplication in context.xml one puts, for instance, JDBC > specific stuff. But, several developers can have different 'properties' > for the database (different user accounts, and so on). > > Is there a way to parametrize those somehow, or each developer need to > have separate context.xml? > > Mike Tomcat also supports ant-style variable replacement, so using that then Ken's example would look like: baseprefix ${BPVAL} where BPVAL is a Java system property (that can be set in catalina.properties for example). Of course, this only works for Tomcat. Ken's suggestion will work on any servlet container. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JSSE question
"Christopher Schultz" wrote in message news:4b1ecba6.1030...@christopherschultz.net... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Vadim, > > On 12/7/2009 1:25 PM, Vadim Letitchevski wrote: >> openssl pkcs12 -export -in /etc/pki/tls/certs/localhost.crt -inkey >> /etc/pki/tls/private/localhost.key -out mycert.p12 -name tomcat -CAfile >> /etc/pki/tls/cacert.pem -caname root -chain >> >> I have used the password changeit. > > Note that you have created certificate in PKCS12 format, not a keystore. > You now need to take the next step in the SSL HOWTO which is to use the > Java 'keytool' utility to create a keystore. > Yes, the documentation in the SSL HOWTO is somewhat confusing :(. There are actually two separate examples there (one for PKCS12 and one for JKS), but it isn't very clear from reading the doc where one ends and the other begins. For PKCS12 you are done after creating the .p12 file (except for the undocumented part about adding the keystoreType to the ). If anybody wants to take a crack at cleaning this up (with bonus points for adding a PKCS11 example), patches are always welcome. >> Next I have edited server.xml to have these strings: >> >> >> >keystoreFile="conf/mycert.p12" keystorePass="changeit" > > If you are going to use the PKCS12 (.p12) format, you will probably have > to set keystoreType="PKCS12". Check the documentation for the > SSL-specific attributes again. > >>maxThreads="150" minSpareThreads="25" maxSpareThreads="75" >>enableLookups="false" disableUploadTimeout="true" >>scheme="https" secure="true" >>clientAuth="false" sslProtocol="TLS" /> >> >> >> >keystoreFile="conf/mycert.p12" keystorePass="changeit" >>truststoreFile="conf/mycert.p12" truststorePass="changeit" > > Although I don't think it will hurt to have both, your keystore and > truststore aren't the same thing. Check the documentation for these two > attributes. Again, you may need to use truststoreType="PKCS12" if you > want to use your .p12 file. > > Hope that helps, > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAksey6YACgkQ9CaO5/Lv0PBwWQCgj6T+m87bL49GXvON7dzIaklo > S74AnRnYM6IIuo8pMQe/bDAaSbwocXzg > =k45M > -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JSSE question
"Vadim Letitchevski" wrote in message news:e17da276f9a0c84fad22739de29c389005dafc3...@entmail01.tad.teledyne.com... >I am confused. Can Tomcat use only JKS keystore or it can also use pem or >some other certificate storages? > In the Tomcat docs (http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html), it shows how to use a PKCS12 keystore. At some point that should be updated to include an example for using a PKCS11 keystore. The actual answer is that the JSSE Connector can use any keystore format that is supported by your Java vendor. In particular, with the Sun JVM, you can't use PEM (however the APR Connector does use PEM). However, it is usually pretty easy to convert PEM to PKCS12 (see the link above for an example). > > Thanks > Vadim. > (310)765-3812 > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to set MaxThreads, MinSpareThreads on AJPconnector using Tomcat 5.5 API's
"Rajat Gupta05" wrote in message news:784ae6e0ec8c2343975b7ff4daeaa34b0ce6638...@blrkecmbx06.ad.infosys.com... >Hi, > >I am trying to create a AJP connector on Tomcat5.5 which is running in >Embedded mode by using following API's > > Embedded em = new Embedded(); // create new engine >StandardEngine engine = (StandardEngine) em.createEngine(); >engine.setName("Catalina"); >engine.setDefaultHost("localhost"); > >String ajp13_address = "127.0.0.1"; >String ajp13_protocol = "ajp13"; >org.apache.catalina.connector.Connector ajp13Connector = null; >ajp13Connector = em.createConnector(ajp13_address, ajp13_port, >ajp13_protocol); > >With Tomcat5.0 there were methods available in CoyotoConnector through >which we could set the MinProcessors and >MaxProcessers which are similar >to MinSpareThreads and MaxThreads in tomcat5.5. > You use the setProperty method on the Connector Object (the names are the same as in the Tomcat docs for setting it via server.xml). So something like: ajp13Connector.setProperty("maxThread", "200"); ajp13Connector.setProperty("minSpareThreads", "25"); >In tomcat5.5 how do I set these values, Can you I use >ChannelSocket/ChannelNioSocket for the same? What is >difference between >these two? > ChannelSocket is the standard Java AJP/1.3 Channel for 5.5.x. With this channel, the Threads will block after handling a request waiting for the next request on that particular Socket to come from Apache (or until it hits the connectionTimeout, which ever happens first). ChannelNioSocket is the experimental (due to a lack of community interest) non-blocking Java Channel. It works somewhat like the APR AJP/1.3 Connector in that Threads return to the pool after processing a request. Then when another request comes in from Apache on a Socket, it gets a Thread from the pool, and uses it to process the request. This means that the only active Tomcat Threads are those that are processing requests, so depending on your site's traffic pattern means that you can possibly handle a big pool of Socket connections between Apache and Tomcat with relatively few Threads. To use this one, you would specify an ajp13_port value of 0 in the createConnector call above, and use: ajp13Connector.setProperty("channelNioSocket.port","8009"); // required ajp13Connector.setProperty("channelNioSocket.maxThreads", "200"); ... Property name are generally the same as for ChannelSocket, but prefixed with channelNioSocket.. >Please let me know if there is other alternative as well available. > >Thanks >Rajat > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
"André Warnier" wrote in message news:4b119016.2020...@ice-sa.com... > Pid wrote: >> On 28/11/2009 12:56, André Warnier wrote: >>> ;-) >>> I just wanted, once, to use a subject line with capitals and an >>> exclamation mark. >>> >>> It seems however that in this particular case, neither Tomcat nor Apache >>> httpd follow the rules, when they default to the .. default virtual host >>> in the case where they cannot find a match between the Host: header and >>> one of their defined virtual hosts. >>> Doesn't the following say that they MUST return a 400 status ? >>> >>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.2 >> >> "An origin server that does not allow resources to differ by the >> requested host MAY ignore the Host header field value when determining >> the resource identified by an HTTP/1.1 request" >> >> ? >> > You are quoting selectively. The same line continues with > "(But see section 19.6.1.1 for other requirements on Host support in > HTTP/1.1.)" > which section 19.6.1.1 is quite stern about the fact that HTTP 1.1 servers > MUST support the Host: header properly. > So I persist. Well, for IP-based VHosts (common for httpd), Pid is correct since the server uses the IP address that recieved the request to determine where it goes. For name-based VHosts (the default for Tomcat), both Tomcat and httpd are still in the clear since every host is valid on the server (the ones not explicitly configured match the default host). 3. If the host as determined by rule 1 or 2 is not a valid host on the server, the response MUST be a 400 (Bad Request) error message. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with mod_proxy_ajp and Apache 2
"ArthIT" wrote in message news:26531167.p...@talk.nabble.com... > > Hi, > > we are facing some weird problems at one of our customers. > Our application is running on a tomcat server behind a Apache2 Webserver > which does SSL. > The servers are connected with mod_proxy_ajp. > The network is a slow 2MBit WAN which is used to capacity. > > Within this infrastructure we periodically get Broken Pipe Exceptions > which > are caused by an IOException in JKInputStream. > > Conspicuous is the following: When an IOException occurs in most of the > cases (not in all) it is followed by another one, exactly 30seconds later. > I think Apache tries to resend the request to tomcat after a timout is > reached. > > The IOExceptions in JKInputStream are thrown on AjaxRequests only > (realised > with wicktes AjaxFormSubmittingBehavior), which are done on every "onblur" > javascript event. Our app contains pretty complex forms, with many input > fields (>200). If one is tabbing fast through the form many ajax events > are > fired... > > I tried to reproduce this at our companies network with FireFox Network > throttling plugin (500Byte/s up and download), without luck. > > Note: > The customer uses IE6 and IE7. > This problem arises at the special WAN Network only. Our customer has > another internal production system (same application) at a LAN network, > which does not face these Exceptions. > > > Does anybody has a hint or idea what could be going on? That would be > great! > Many thanks in advance to everybody who investigates on this. > The first Exception below is harmless, since it is just Tomcat trying to tell Apache that it is ready for the next request, but Apache has stopped listening. It just results in the Thread going back to the pool. The second Exception below is from Tomcat requesting the POST body from Apache, but not getting it. My best guess is that Apache is timing out when trying to read the request body from the WAN. It then tells mod_proxy_ajp that it couldn't get the data it wants. Then mod_proxy_ajp thinks that the client has gone away, so signals this to Tomcat by closing the connection. This results in the second Exception below when Tomcat is trying to read from a closed connection. The Apache logs would be the place to look for more information. > See bellow the stack traces: > > catalina.out: > 20.11.2009 10:22:29 org.apache.jk.core.MsgContext action > WARNUNG: Error sending end packet > java.net.SocketException: Broken pipe > at java.net.SocketOutputStream.socketWrite0(Native Method) > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) > at java.net.SocketOutputStream.write(SocketOutputStream.java:136) > at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:537) > at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:127) > at org.apache.jk.core.MsgContext.action(MsgContext.java:305) > at org.apache.coyote.Response.action(Response.java:183) > at org.apache.coyote.Response.finish(Response.java:305) > at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:205) > at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) > at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) > at > org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) > at > org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) > at java.lang.Thread.run(Thread.java:595) > > application.log: > 2009-11-20 10:22:29,042 WARN [TP-Processor2] > org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/customer] > - > Exception thrown whilst processing POSTed parameters > java.io.IOException > at org.apache.jk.common.JkInputStream.receive(JkInputStream.java:205) > at org.apache.jk.common.JkInputStream.doRead(JkInputStream.java:179) > at org.apache.coyote.Request.doRead(Request.java:419) > at > org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:264) > at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:403) > at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:279) > at > org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:193) > at org.apache.catalina.connector.Request.readPostBody(Request.java:2420) > at > org.apache.catalina.connector.Request.parseParameters(Request.java:2399) > at org.apache.catalina.connector.Request.getParameter(Request.java:1005) > at > org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:353) > at > COM.customer.foo.servlets.WrappedRequest.getParameter(WrappedRequest.java:134) > at > org.apache.wicket.protocol.http.servlet.ServletWebRequest.getParameter(ServletWebRequest.java:105) > at > org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.decode(WebRequestCodingStrategy.java:198) > at org.apache.wicket.Request.getRequestParameters(Request.java:171) >
Re: Tomcat in Embedded mode
wrote in message news:887c111b0911241208v65192e8fp20e0730fb09ff...@mail.gmail.com... > Hi guys, > > I spent my day into struggling with Tomcat 6 and I just wanted to ask you > for some ideas and whether what I'm doing seems right to you. > > So, I'm trying to port a legacy application which is using Tomcat 5.0.28 > to > Tomcat 6.0.20. > While most of the Tomcat 5.0.28 properties are read from the server.xml, > some of the Connector properties(keyStore, keyPass, protocols, connector > address, port ...) are retrieved from other configuration files which are > in > fact related to the application. > Using Tomcat 5.0.28 this is implemented by providing a custom > implementation > for the CoyoteConnector and CoyoteServerSocketFactory. > > Obviously, I can't do this with Tomcat6. > What I intend to do is write a class that extends the Catalina class (so > that the Digester can read my server.xml file) and then just overwrite the > addConnector method in order to overwrite the Connector properties "on the > fly" and the load method ( so that I can push my implementation in the > digester). > If all you want is to customize the Connector, then it is much easier to simply put into server.xml: Then, if I understand what you want, something like: public void init() throws Exception { fixupSettings(); // your method to make configuration changes super.init(); // let Tomcat handle the rest } should work for you. > Then in order to use the Bootstrap (to load classes), I'll have to extend > it > so that I can change the Catalina implementation with my own. > Then for starting tomcat I'll use my bootstrap. > > Please, have in mind that I really don't like this hacky approach. > However, > I can't do much to change it since I'm not the one who tells the > requirements. > > So, what do you think? Some easier way to achieve this? > > Thanks, > Ivelin > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client certificate chains with mod_jk
"Christopher Schultz" wrote in message news:4b070643.1070...@christopherschultz.net... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Rainer, > > On 11/20/2009 1:09 PM, Rainer Jung wrote: >> On 20.11.2009 17:20, Christopher Schultz wrote: >>> I'm having trouble getting a client certificate chain sent to Tomcat via >>> mod_jk. Apache httpd 2.2.9, mod_jk 1.2.28, Tomcat 5.5.27. >> >> Off by one? >> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=39637 >> >> indicates you'll need 5.5.28 ... > > Ugh! I didn't even think that a bug/incomplete feature in Tomcat could > be the reason. I just assumed that my configuration was wrong. I'll test > in 5.5.28. > Yes, the AJP/1.3 protocol was developed way back in the days of Servlet 2.2. In the 2.2 spec, only the client cert was exposed to the servlet. It wasn't until Servlet 2.3 that the chain was exposed, but it took a long time after that to add it to AJP/1.3. > Thanks, > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAksHBkMACgkQ9CaO5/Lv0PBLRACfSrHRGFhvyiyqB5BgUnsP7apj > 1XMAnj/ngKlJ82zbSWPpjflTl8M7jOIh > =jYdV > -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL Configuration Question
"Christopher Schultz" wrote in message news:4afdb50c.70...@christopherschultz.net... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Liav, > > On 11/13/2009 10:48 AM, Liav Ezer wrote: >> I need help configuring my http connector to be a secure one via SSL. > > Are you expecting to use tcnative in order to use an "APR" connector, or > do you want to use the plain-old Java HTTP connector? If you don't know > what I'm talking about, you want the Java one. It's important to > differentiate because the configurations are done differently. > >> I have the purchased certificate's (from a CA which i don't know who is) >> products in 4 different files: >> >> xxx.domainname.com.cer -> I don't know what is this file.. > > Neither do I. Look at the date stamps to see if it's relevant. > >> xxx.domainname.com.key -> I believe this is the encrypted key for the >> certificate > > Hopefully, you created this file yourself and haven't given it to > anyone. It should be a /private/ RSA key. > >> xxx.domainname.com.csr -> I believe this is the request > > .csr files are typically "certificate request" files, so yet, that seems > reasonable. > >> xxx.domainname.com.crt -> I believe this is the actual certificate >> issed >> by the CA > > Generally, .crt files are the actual certificates. They are usually > encrypted with a passphrase and can be unlocked using the .key file above. > Urm, usually the .crt files are not encrypted (since they are sent to anybody that asks for them by the web server). They are usually base64 encoded (since the actual data is binary). >> 1. What should i write at the keystoreFile? - Which of the 4 files i have >> do >> i need to point to? >> 2. What do i write in the keystorePass attribute? > > That depends on whether you are using APR or not. See above. > >> 3. What should i do with the rest of those 4 files? > > xxx.domainname.com.key - keep this in a safe place, preferably /not/ on > your production server. > > xxx.domainname.com.csr - You can probably discard this file, but it > might be worth keeping around alongside your .key file. > > xxx.domainname.com.cer - It depends on what this file is. It might even > be a certificate file that has no password (which would be useful if you > were using Apache httpd, but you didn't mention that so I suspect it's > not useful to have such a certificate laying around). > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkr9tQwACgkQ9CaO5/Lv0PBsYwCguvk35Bo0kLXB1UYrYr2iIAX7 > JKYAnjViDJDfcUrz4BeYnr351+v4i8us > =BPyj > -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat really need Shutdown port
"Mark Thomas" wrote in message news:4afdf745.6000...@apache.org... > Caldarale, Charles R wrote: >>> From: Mark Thomas [mailto:ma...@apache.org] >>> Subject: Re: Tomcat really need Shutdown port >>> >>> If you set the shutdown port to -1 then the standard process >>> kill (ie kill -15 on linux) will perform a standard, >>> perfectly safe shutdown identical to what you would get if >>> the shutdown script worked (which it won't without a shutdown >>> port) >> >> Good to know. Anything equivalent for Windows? > > CTRL-C if running in a console. If running as a service, I don't *think* > the > shutdown port is used but you'd have to check. I'd test it / check the > source > myself, but I'm in the middle of something else I need to finish at the > moment. > On *nix, jsvc doesn't use the shutdown port (it has it's own signal handling to do a clean shutdown). On Windows, you need the shutdown port (so that anybody with physical access to the machine can shutdown the service by using the scripts). This is because tomcatN.exe doesn't keep a thread alive on it's own after starting Tomcat, so there are no non-daemon threads left and Tomcat shuts down. > Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to set up tomcat and truststore
"Luciana Moreira Sa de Souza Signed by - PrivaSphere AG" wrote in message news:4afaead4.30...@privasphere.com... > Hi Jorge, thx for your quick reply. > > Maybe I did not explain my problem well enough, so let me elaborate it a > bit more. > > In our platform clients can upload their self-signed certificates to allow > them to login to our platform. > > If we add all client certificates to the static truststore file as per > "|truststoreFile|" of > http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html#Edit%20the%20Tomcat%20Configuration%20File > > we end up having a scalability problem during handshake. This happens > since the server must inform which client certificates issuers are > accepted by the server, so having >50'000 self-signed DNs concatenated as > a string doesn't really vouch for a quick TLS handshake. This is the > reason why we do a second level authentication in our own realm > implementation or the application layer against our own dynamic > truststore. But for this to be possible, an initial handshake must occur > where the client provides his certificate to the platform. > > So, we split authentication into two steps: > i) establish a secure tunnel without the harmful renegotiation to someone > ii) once that is done, ensure the "someone" is who we like without the > need for TLS-renegotiation > > On the application layer we can get the client certificate chain through: > X509Certificate certs[] = (X509Certificate[]) > request.getAttribute(org.apache.catalina.Globals.CERTIFICATES_ATTR); > > And then we validate it against our own truststore. The main problem is > reaching this stage with any client certificate. > > So my question is: > 1) is the above mentioned "|truststoreFile|" attribute mandatory or not? It is mandatory if you want to use the default JSSE connector. It's not needed if you use the APR connector, and set SSLVerifyClient="optionalNoCA" (see http://tomcat.apache.org/tomcat-5.5-doc/apr.html for more details). However, this prompts for a cert the first time that the client connects, and there is currently no option to ask for a cert later if they don't supply one on the initial connection. > 2) is there a way to tell the JSSESupport class not to send the issuer-DN > list, but a wildcard for any issuer? > (perhaps this could just be a "*" in the "|truststoreFile|" attribute, > anyway it would be great to know whether this is a mandatory attribute or > an optional one Not to my knowledge. The JSSESupport class entirely relies on the underlying JSSE in the JVM. It doesn't touch the SSL layer by itself. It might be possible to implement a custom TrustManagerFactory that does this, but I haven't looked into it. > ==> pls document in the above cited howto.html) > > Best regards, > Luciana Moreira > > > -- > This message has been signed by the PrivaSphere Mail Signature Service. > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - access denied exception ONE TIME after each restart, then all ok... Why? & How to make it stop?
"Pete McNeil" wrote in message news:4aeba53e.3090...@microneil.com... > Christopher Schultz wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Pete, >> >> On 10/30/2009 7:59 PM, Pete McNeil wrote: >> >>> Fresh install of Tomcat6 on fresh install of ubuntu. >>> >> >> Be specific: exactly which version of Tomcat 6? >> > > Using CATALINA_BASE: /usr/share/tomcat6 > Using CATALINA_HOME: /usr/share/tomcat6 > Using CATALINA_TMPDIR: /usr/share/tomcat6/temp > Using JRE_HOME: /usr > Server version: Apache Tomcat/6.0.18 > Server built: Feb 27 2009 06:50:18 > Server number: 6.0.0.0 > OS Name:Linux > OS Version: 2.6.24-24-xen > Architecture: amd64 > JVM Version:1.6.0_0-b14 > JVM Vendor: Sun Microsystems Inc. > > >From the code, it looks like it should work in this version (at least with the standard Tomcat distro). But it is possible that it was fixed in 6.0.19 (it's too long ago to remember the change log entry there, and I don't feel like researching). >> >>> >>unpackWARs="true" autoDeploy="true" >>>xmlValidation="false" xmlNamespaceAware="false"> >>>>> path="" >>> docBase="/home/someplace/www.someplace.com" >>> reloadable="true"/> >>> >> >> NB: should be in a context.xml file on the disk, not in your >> server.xml file. >> > > Tried that -- couldn't make it work. I want this to be the default > application on this server and I want to host it from a specific user > directory. This seems to be the recommended way to do that, and it works. > > > >> First access after what? Tomcat restart? Webapp restart? >> > > Thought I was clear on that, sorry. First request after restarting tomcat. > > >> That's interesting that this exception happens only once, given that >> each time it should attempt to load the same class. >> >> Given the exception, I suspect it's an incorrectly-configured >> SecurityManager. > > It gets to try again when generating the error page (at which point only trusted Tomcat code is on the stack). > I have seen suggestions that this might be some kind of timing issue with > the security manager. > > I've also received the following suggestion directly (off list): > > $CATALINA_HOME/conf/catalina.policy > grant codeBase "file:${catalina.home}/lib/tomcat-coyote.jar" { > { >//set coyote perms >permission java.lang.RuntimePermission > "accessClassInPackage.org.apache.coyote.*"; > } > In the default policy files, it should already have AllPermision. So this should do nothing. > > === > > In the mean time I was trying to solve something else and stumbled upon > fixing this issue at the same time... However I don't pretend to > completely understand it and I'm sure the underlying issue isn't resolved > since it wasn't really addressed. I will dig deeper tomorrow and try to > find the answer. I hope also that this thread will eventually show the > answer for others to find. > > My temporary solution was to add the following to > /etc/tomcat6/policy.d/50local.policy > > grant codeBase "file:/home/someplace/www.someplace.com/-" { >permission java.security.AllPermission; > }; > > > > I am porting this app from a different resin based server to a new tomcat > based server. My previous server did not have a security manager. The > other problem I was attempting to solve was a security issue where a tool > we built in a .jar was not able to connect to one of our servers. I tried > to grant specific permissions for that jar - - and the result was nothing > would work... > > I finally granted all permissions (I know this is heavy handed) to the > app's root and not only did it solve my server access problem, but the > problem that started this thread also went away. Now that I have this in > place the first request after a tomcat restart does not create an error. > Or just edit the startup script to run without a SecurityManager. > > > I read that a grant read entry is created automatically for any app that > is deployed. > I read in other places that this kind of thing might be a timing issue. > I wonder if the error occurred because the automatically generated grant > read entry was not in place for the first request after a tomcat restart; > and that my heavy-handed grant for the entire app has "hidden" this > problem because my entry is always in place as tomcat comes up. > > Those are my thoughts. > > I look forward to eliminating the mystery and finding the correct solution > (even if what I have now seems to work). > It's trying to load a Tomcat internal class (ironically a PrivilegedAction), and the default policy file doesn't allow access to Tomcat internal classes from untrusted code. Tomcat is supposed to load that class at startup (at which point it can be used in untrusted code). Since hitting any servlet that calls flush first should trigger this, anybody with too much time on their hands can test it ;
Re: Expecting "jsp:param" - Porting resin jsp pages to tomcat, dreamweaver editable sections / comments
"Christopher Schultz" wrote in message news:4ae758a0.5050...@christopherschultz.net... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Bill, > > On 10/26/2009 9:44 PM, Bill Barker wrote: >> "Christopher Schultz" wrote in message >>> On the other hand, shouldn't the JSP compiler pass-through everything >>> except for directives? HTML is a common enough use case for JSP that >>> SGML comments ought to be tolerated in these cases. >> >> Except for the fact that section 5.4 of the (2.1) JSP spec precludes >> having >> anything except in the body of a element. >> Allowing template text in there is then a Container-specific feature and >> so >> renders the webapp non-portable. > > I read 5.4 and while the text doesn't say anything about this, the > formal syntax of does: > > " > Syntax > [...] > > { }* > > " > > There, no other content appears to be allowed. However, other sections > of the JSP specification are less ambiguous. For instance, section 5.15 > () specifically says: > > " > No subelements may appear within jsp:text; for example the following > fragment is invalid and must generate a translation error. > " > > The closest 5.4 comes is this: > > " > A jsp:include action may have jsp:param subelements that can provide > values for some parameters in the request to be used for the inclusion. > " > > Back to section 5.15, this is an interesting tidbit: > > " > When within a JSP document, of course, the body content needs to > additionally conform to the constraints of being a well-formed XML > document, so the following example, although valid in a JSP page is > invalid in a JSP document: > " > > The above is not qualified by anything mentioning the difference between > .jsp and .jspx files or anything like that. I would expect that any > SGML-style comments within a element would, in fact, be > ignored by the JSP processor when producing output since it presupposes > XML semantics. Instead, the JSP compiler (in my 5.5.26 environment) > produces an error for this document: > > > > Within the spec, "JSP document" is the same as ".jspx", whereas "JSP page" is the same as ".jsp". I've confirmed that this example causes an exception in 6.0 (using latest checkout from svn) when used in ".jsp" syntax (it works fine in ".jspx" syntax, and just outputs a blank line). Since SGML comments are simply template text in ".jsp" syntax, it looks like you have found a bug. This would be especially true if: This is some content ${foo.content < 3} fails, but haven't tested it. > > The error is: > > Exception: org.apache.jasper.JasperException: /test.jsp(3,0) '<', > when appears in the body of <jsp:text>, must be > encapsulated within a CDATA > Stack Trace: > org.apache.jasper.JasperException: /test.jsp(3,0) '<', > when appears in the body of <jsp:text>, must be > encapsulated within a CDATA > org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40) > > This error seems consistent with the "no subelements" clause in S.5.15, > but I see no such restriction placed on . > >> It would be a bug if the error happened for a page in XML syntax however. > > I think the JSP specification has a little multiple-personality disorder > when it comes to XML-looking-syntax versus actual XML syntax. It's > unfortunate, since it can really confuse people. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrnWJ8ACgkQ9CaO5/Lv0PBhkgCdHL88GleiLT4mo4wf2K3q9DTD > zB8An1Lk12w/HqvPZYPxbWERfJSJauln > =4VVb > -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Expecting "jsp:param" - Porting resin jsp pages to tomcat, dreamweaver editable sections / comments
"Christopher Schultz" wrote in message news:4ae5cabb.7070...@christopherschultz.net... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Konstantin, > >> Those are NOT comments. The JSP comments are <%-- --%>. >> >> I think that if you switch to XML syntax for JSP pages (using jspx >> files instead of jsp), those will be treated as XML comments and >> properly ignored. > > Apologies for not thinking about that: Pete, if you're not using XML > syntax (as I expected you were), then your complaint is not valid: your > JSP is /not/ an XML document. > > If you use .jspx (I think?), then XML syntax will be acceptable. > >> So I am sure that the above is not a Tomcat bug. > > On the other hand, shouldn't the JSP compiler pass-through everything > except for directives? HTML is a common enough use case for JSP that > SGML comments ought to be tolerated in these cases. > Except for the fact that section 5.4 of the (2.1) JSP spec precludes having anything except in the body of a element. Allowing template text in there is then a Container-specific feature and so renders the webapp non-portable. It would be a bug if the error happened for a page in XML syntax however. > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrlyrsACgkQ9CaO5/Lv0PDDGACglcZR5X+kwfi1y2w82Sb5nuW5 > hioAn1I2ZY0r3CZSanzU9TpMyHEXWfTr > =XZ+i > -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk with Apache HTTP server version 2.2 and Tomcat 6.0
"André Warnier" wrote in message news:4ac3d26d.4000...@ice-sa.com... > François Gravel wrote: >> Greetings, >> I'm a newbie trying my hand at setting up a local PHP and Java >> development >> environment. I use a laptop with Windows XP SP3. >> >> Both service are running fine locally, after install. I will describe >> what >> I did as I followed the procedure to have mod_jk handle the communication >> between them (from >> http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html). I >> got >> the binary for Windows (mod_jk-1.2.28-httpd-2.2.3.so). >> >> Then I created a workers.properties file which I placed in a folder I >> created at $TOMCAT_HOME/conf/jk; the file content is: >> worker.list=worker1 >> worker.worker1.type=ajp13 >> worker.worker1.host=localhost >> worker.worker1.port=8009 > > So far, so good. >> >> I copied the file mod_jk-1.2.28-httpd-2.2.3.so to $HTTPD_HOME/modules and >> renamed it mod_jk.so. It was suggested at this point to also modify >> Apache's httpd.conf file. I imagine that meant to add a line to have the >> module loaded by Apache (I added "LoadModule mod_jk modules/mod_jk.so"). > > That's wrong, and probably the cause of the following messages. > It should be : > LoadModule jk_module modules/mod_jk.so > >> Doing this, however, leads to an intriguing message if you try to test >> the >> configuration: "Can't locate API module structure 'mod_jk' in file >> $HTTPD_HOME/modules/mod_jk.so: No error." Is it an error or not, I'm not >> sure, but since I'm not done with the procedure, I keep going. >> > Rectify the above, and then try again. There may be other problems, but > solve that one first. > >> I then went through the steps to use Tomcat to auto-configure. > > As far as I remember, that is not a very good idea either anymore. I > think I remember Rainer admitting that the mod_jk auto-configuration was > somewhat broken. > Yes, the auto-configure was written for Apache 1.3.x. And even then, it is almost alway necessary to modify the output file by hand. Nobody has felt the itch to get it to work with Apache 2.x, much less with newer versions of mod_jk. The result is that this feature will be gone in Tomcat 7. > So I've >> added the line "Include $TOMCAT_HOME/conf/jk/mod_jk.conf-auto" to the >> file $HTTPD_HOME/conf/httpd.conf. >> >> I also added the listener by way of the line "> className="org.apache.jk.config.ApacheConfig" modJk="/path/to/mod_jk.so" >> />" >> in the file $TOMCAT_HOME/conf/server.xml. >> >> Then I re-started Tomcat to generate mod_jk.conf-auto: it is of note to >> specify that the name of the file is "mod_jk.conf" and not >> "mod_jk.conf-auto". >> >> Finally, I modified the Apache webserver configuration file >> $HTTPD_HOME/conf/httpd.conf to include the simple configuration example. >> >> The end result being a failure to start the Apache 2.2 server: testing >> the >> configuration reveals the same error listed above: "Can't locate API >> module >> structure 'mod_jk' in file $HTTPD_HOME/modules/mod_jk.so: No error." >> >> Please, I've spent hours getting to this point, but I have no idea how to >> get around this error. Thank you, >> > > See above. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache/Tomcat with SSL
The most common cause of this is that you haven't copied your JkMount etc configuration statements to the SSL VirtualHost. In this case, mod_jk doesn't think that it should be serving the .jsp file, so Apache (httpd) serves it instead. Since httpd knows nothing about JSP, it just serves it as a text file. As other people have pointed out, unless you really know what you are doing, it is generally a bad idea to share the httpd DocumentRoot with the Tomcat webapps directory. And even if you do really know what you are doing, it is a significant amount of extra work to secure this configuration. "Miguel Ortiz" wrote in message news:bb7ef21e0428a445b16e49e814926426048...@macg-exch02.macneillgroup.local... I recently setup a SSL cert on our Apache/Tomcat server. When I load our page, I can see the "lock" in my browser with all the SSL info, but the page only loads as a the jsp script and not the full page. Is there some configuration setting that I have missed. I can provide snippets from the server.xml, httpd.conf, and ssl.conf. Thanks in advance. Miguel Ortiz Network Engineer x4818 wk: 954-331-4818 bbry: 954-649-1863 miguel.or...@macneillgroup.com This email and any files transmitted with it are the confidential property of Focus Holdings, LLC and its subsidiaries, and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: blocked / hanging on call to HandlerRequest.checkRequest
"Simon Papillon" wrote in message news:e9cf50b20909280512o2905849fref38fc97a06dd...@mail.gmail.com... > Hi > > I'm running tomcat 5.5.25 on debian sarge 32 bit linux (2.6.8 kernel) > with ~ 1.5GB ram on a pentium 4 2GHz > with a mysql db 5.0.27 > > I've got a configuration with apache mod_jk 1.2.25 balancing to 2 > tomcats which are both running running on jdk 1.6.0_16 -Xmx=256M > > periodically, generally at busy times, looking at the "JK Status > Manager" the busy count on one of the tomcats will go up and the > requests channelled through that container will start to hang, the > busy count will steadily increase the throughput will drop > dramatically (i.e. the Acc column in jk_status will stop incrementing > by 30 every 10secs and go down to like 4), > > This will continue until I either stop that tomcat member through the > JK Status Manager - by editing the worker settings or the thread count > goes up to over the number of permitted apache requests (at 150 at the > moment) and apache is restarted automatically by an out of process > monitoring app. > > If I stop the tomcat instance through the JK Status Manager, then the > busy count will gradually (over a period of 5 - 10 mins) decrease and > get to 0. > > I took a thread dump by tee-ing the output of catalina.out and then > sending a "kill -SIGQUIT pid" when it was in the described busy state > and lots of threads > > The crux of that seemed to be a lot of threads blocked / waiting for > lock on a lock / monitor held in the HandlerRequest.checkRequest here > is the printout of the thread holding the lock which is in the > RUNNABLE state: > If you just want the problem to go away, then look for the attribute "request.registerRequests" in http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html . If that is set to "false", then there is no locking within the checkRequest method. You lose that ability to get stats for the request threads via JMX (including the manager status page), but that method also quits being a bottleneck if you get a flood of new requests. > > > "TP-Processor65" daemon prio=10 tid=0x08bc9400 nid=0x54bd runnable > [0x55dd] > java.lang.Thread.State: RUNNABLE > at java.lang.Class.getMethod(Class.java:1605) > at > org.apache.commons.modeler.BaseModelMBean.setManagedResource(BaseModelMBean.java:764) > at > org.apache.commons.modeler.ManagedBean.createMBean(ManagedBean.java:393) > at > org.apache.commons.modeler.Registry.registerComponent(Registry.java:835) > at > org.apache.jk.common.ChannelSocket.registerRequest(ChannelSocket.java:466) > at > org.apache.jk.common.HandlerRequest.checkRequest(HandlerRequest.java:357) > - locked <0x4490ee38> (a java.lang.Object) > at > org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:367) > at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:261) > at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) > at > org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) > at > org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) > at java.lang.Thread.run(Thread.java:619) > > then lots of the following types of threads (e.g. 35) all blocked > > "TP-Processor63" daemon prio=10 tid=0x09ddc800 nid=0x549f waiting for > monitor entry [0x55d3] > java.lang.Thread.State: BLOCKED (on object monitor) > at > org.apache.jk.common.HandlerRequest.checkRequest(HandlerRequest.java:357) > - waiting to lock <0x4490ee38> (a java.lang.Object) > at > org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:367) > at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:261) > at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) > at > org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) > at > org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) > at java.lang.Thread.run(Thread.java:619) > > "TP-Processor62" daemon prio=10 tid=0x09dd4c00 nid=0x549e waiting for > monitor entry [0x55ce] > java.lang.Thread.State: BLOCKED (on object monitor) > at > org.apache.jk.common.HandlerRequest.checkRequest(HandlerRequest.java:357) > - waiting to lock <0x4490ee38> (a java.lang.Object) > at > org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:367) > at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:261) > at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) > at > org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) > at > org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) >
Re: Error when starting ASF Tomcat on iSeries
"Mark Thomas" wrote in message news:4aba56f3.3000...@apache.org... > John McCleskey wrote: >> I'm trying to start ASF Tomcat on an iSeries running Webfacing, but my >> server is throwing a java exception in the java log file. The error is: >> >> java.lang.NullPointerException >> >> org/apache/tomcat/context/AutoSetup.engineInit(Lorg/apache/tomcat/core/ContextManager;)V+86 >> (AutoSetup.java:118) >> >> org/apache/tomcat/core/ContextManager.init()V+55 >> (ContextManager.java:444) >> >> org/apache/tomcat/startup/Tomcat.execute([Ljava/lang/String;)V+128 >> (Tomcat.java:201) >> >> org/apache/tomcat/startup/Tomcat.main([Ljava/lang/String;)V+8 >> (Tomcat.java:247) >> >> org/apache/tomcat/service/StartupThread.run()V+6 (JNIEndpoint.java:216) >> >> I'm using java 1.3. > > Those classes are not in any of the current codebases. At a guess you > are using Tomcat 3. That hasn't been supported for many years. You need > to upgrade to a supported version. > +1 This stack trace doesn't even correspond to Tomcat 3.3.x. It looks like it is Tomcat 3.2.x, which hasn't been supported in a really long time (like from about the time that the first Tomcat 4.0 came out). Of course, JNIEndpoint died with Tomcat 3.3.x (but support for it in mod_jk died out much earlier). So add mod_jk to the components to modernize. > Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security Constraint conflict
"Christopher Schultz" wrote in message news:4ab3f5f1.5060...@christopherschultz.net... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Peter, > > On 9/18/2009 4:34 PM, Peter Holcomb wrote: >> Thanks for your response. I've read through the example in 13.7.2 of >> the spec > > Which version of the spec? I don't see a section 13.8 at all in either > 2.4 or 2.5 of the spec. I see the heading "Combining Constraints" listed > under 12.7.1. > >> but I don't think I'm understanding how the union works. > > I think Tim is incorrect, here. Neither the url-pattern nor the > http-methods overlap, therefore no combining should occur. > I haven't checked the Servlet 3 spec, but with earlier versions, the union process is to give you the *least* restrictive checking (i.e. you just have to pass one constraint to pass). And, yes, the url-patterns in this case overlap since '/*' and '*.xhtml' both apply to /myapp/foobar.xhtml. There is no provision for 'best match' on url-pattern like there is for servlet-mapping. So Tim is right, and Tomcat is doing what the spec says it should do. Complaints would have to be sent to the Servlet spec expert group ;). >> According to my thought process, the url patterns are: >> >> *.xhtml - access precluded >> >> /* PUT,DELETE,TRACE,OPTIONS - access precluded > > The example I see in 12.7.2 seems to support your expectations. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqz9fEACgkQ9CaO5/Lv0PCyhQCghhbzT4ruq1in03G4GTbsI2DD > v7UAmgKCOefa4O0gcDBTsnDHHePDDSY9 > =UViR > -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: how to unwrap a Request from RequestFacade
wrote in message news:of85b6a7da.49853bd1-on85257627.006211ee-85257627.00657...@sectra.se... > Thanks Chris. Still not having any luck. Let me give you the snippet of > the code so that you can understand the problem better: > > I have a servlet like this > > protected void doGet(HttpServletRequest request, HttpServletResponse > response) throws ServletException, IOException { > > // some code > > >RequestFacade rf = (RequestFacade) request;// this > throws a class cast exception >Request realRequest = new > MyRequestFacade().getRequest(rf); > Context ctx = _realRequest.getContext(); > StandardManager sessionMgr = (StandardManager) > ctx.getManager(); > sessionMgr.getActiveSessions(); > > } > > > When I debug I see that the request object coming into doGet method of the > servlet is RequestFacade but I can't assign it directly to a RequestFacade > object or can't type cast it. Although when I type cast it I don't get any > compilation error but at runtime it throws as a ClassCastException. > > Am I doing something stupid here? :-( Looks simple it is so frustrating as > when I debug I can open the RequestFacade object and see the Request > Object, Context, Manager and all the information I need but I don't know > how to access it. > > Any thoughts from fresh pair eyes? > Yes, TC 5.5 still has the server ClassLoader, so the RequestFacade is loaded in a ClassLoader that isn't the parent of your ClassLoader. You need to do one or more of the following: 1) upgrade to TC 6.0 so that the Request and RequestFacade are in your ClassLoader hierarchy (in the default settings) 2) declare your webapp 'privileged' in your context.xml (giving access to the server ClassLoader). 3) I think all the info that you want is exposed by JMX, so use JMX to retrieve it. 4) use introspection to grab the fields. On 5.5 this will be painful, since you have to use introspection everywhere (none of the classes will be in your ClassLoader hierachy) 5) change your catalina.properties file to have the same hierachy as TC 6 (but will get over-written on upgrades). > Thanks, > -- > Muthu Chandir > Sectra North America, Inc. > Phone: (800)307-4425 ext 222 > Email: mu-...@sectra.com > > > > From: > Christopher Schultz > To: > Tomcat Users List > Date: > 09/04/2009 10:28 AM > Subject: > Re: how to unwrap a Request from RequestFacade > > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Bill, > > On 9/3/2009 10:47 PM, Bill Barker wrote: >> "Christopher Schultz" wrote in message >> news:4aa03ca3.4010...@christopherschultz.net... >> Muthu, >> >> On 9/3/2009 11:17 AM, muthu.chan...@sectra.se wrote: >>>>> I am using tomcat 5.5 and just wanted to write a simple servlet to > get >>>>> some information using StandardManager such as activeSessions, >>>>> expriedSessions, sessionCounter etc.. I am not that familiar with > these >>>>> classes. I noticed when the request comes into my servlet it comes as >>>>> RequestFacade where the org.apache.catalina.connector.Request is > wrapped >>>>> inside it. I haven't figured out how to unwrap the Request object so > that >>>>> I can get the Context from which I can get the Manager > (StandardManager) >>>>> to access the information I need. Any help with a snippet of code to > get >>>>> the Request Object from RequestFacade will be appreciated. >> >> Maybe try something like this: >> >> public class SneekyRequestFacade >> extends RequestFacade >> { >> public SneekyRequestFacade() { super(null); } >> >> public Request getRequest(RequestFacade rf) >> { >>return rf.request; >> } >> } >> >> Now: >> >> RequestFacade rf = ...; // get your requestfacade >> Request req = new SneekyRequestFacade().getRequest(rf); >> >> I think that ought to do it. Isn't OO abuse great? >> >> >>> It is great ;). But you save a couple of lines by just doing straight >>> introspection. > > I had thought about that, but I thought the JVM prevented code from > getting-around access privileges by using introspection. Or is that only > when a SecurityManager is running? > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqhImUACgkQ9CaO5/Lv0PDVkgCaA9UWhDHNXKdfN2mSPZN1lauK > Z3oAnRphaMCX6vkmjvLH+t/tmUIxp52m > =qxEb > -END PGP SIGNATURE- > > - > 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: how to unwrap a Request from RequestFacade
"Christopher Schultz" wrote in message news:4aa12265.3020...@christopherschultz.net... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Bill, > > On 9/3/2009 10:47 PM, Bill Barker wrote: >> "Christopher Schultz" wrote in message >> news:4aa03ca3.4010...@christopherschultz.net... >> Muthu, >> >> On 9/3/2009 11:17 AM, muthu.chan...@sectra.se wrote: >>>>> I am using tomcat 5.5 and just wanted to write a simple servlet to >>>>> get >>>>> some information using StandardManager such as activeSessions, >>>>> expriedSessions, sessionCounter etc.. I am not that familiar with >>>>> these >>>>> classes. I noticed when the request comes into my servlet it comes as >>>>> RequestFacade where the org.apache.catalina.connector.Request is >>>>> wrapped >>>>> inside it. I haven't figured out how to unwrap the Request object so >>>>> that >>>>> I can get the Context from which I can get the Manager >>>>> (StandardManager) >>>>> to access the information I need. Any help with a snippet of code to >>>>> get >>>>> the Request Object from RequestFacade will be appreciated. >> >> Maybe try something like this: >> >> public class SneekyRequestFacade >> extends RequestFacade >> { >> public SneekyRequestFacade() { super(null); } >> >> public Request getRequest(RequestFacade rf) >> { >>return rf.request; >> } >> } >> >> Now: >> >> RequestFacade rf = ...; // get your requestfacade >> Request req = new SneekyRequestFacade().getRequest(rf); >> >> I think that ought to do it. Isn't OO abuse great? >> >> >>> It is great ;). But you save a couple of lines by just doing straight >>> introspection. > > I had thought about that, but I thought the JVM prevented code from > getting-around access privileges by using introspection. Or is that only > when a SecurityManager is running? > No, without a SecurityManager, you can do pretty much anything with introspection by at most calling field.setAccessible(true). This is how the WebappClassLoader nulls out static fields when you undeploy a webapp. It's also a big part of the reason that the server ClassLoader went away by default, since it didn't really stop anyone from accessing Tomcat core classes. > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqhImUACgkQ9CaO5/Lv0PDVkgCaA9UWhDHNXKdfN2mSPZN1lauK > Z3oAnRphaMCX6vkmjvLH+t/tmUIxp52m > =qxEb > -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: how to unwrap a Request from RequestFacade
"Christopher Schultz" wrote in message news:4aa03ca3.4010...@christopherschultz.net... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Muthu, > > On 9/3/2009 11:17 AM, muthu.chan...@sectra.se wrote: >> I am using tomcat 5.5 and just wanted to write a simple servlet to get >> some information using StandardManager such as activeSessions, >> expriedSessions, sessionCounter etc.. I am not that familiar with these >> classes. I noticed when the request comes into my servlet it comes as >> RequestFacade where the org.apache.catalina.connector.Request is wrapped >> inside it. I haven't figured out how to unwrap the Request object so that >> I can get the Context from which I can get the Manager (StandardManager) >> to access the information I need. Any help with a snippet of code to get >> the Request Object from RequestFacade will be appreciated. > > Maybe try something like this: > > public class SneekyRequestFacade > extends RequestFacade > { > public SneekyRequestFacade() { super(null); } > > public Request getRequest(RequestFacade rf) > { >return rf.request; > } > } > > Now: > > RequestFacade rf = ...; // get your requestfacade > Request req = new SneekyRequestFacade().getRequest(rf); > > I think that ought to do it. Isn't OO abuse great? > It is great ;). But you save a couple of lines by just doing straight introspection. > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqgPKMACgkQ9CaO5/Lv0PBmaACgvmnqSUh8xEhziGwDNE4SbVwQ > ytQAnA2u2nUwb4XXtqLZqFa92oFDiBn2 > =PCPu > -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jsvc will not start on Snow Leopard & Tomcat 6
There is a patch in https://issues.apache.org/jira/browse/DAEMON-98, but I don't know if is the same issue. There are a couple of other OS/X related issues there as well. "bemaniac" wrote in message news:25285131.p...@talk.nabble.com... > > > I tried running ldd, but I guess that command doesn't exist in OS X Snow > Leopard. Is there another command I can try? > > I've looked in the directory it is looking in to find > "libjvm_compat.dylib", > and the only thing similar that's in there is "libjvm.dylib". > It doesn't really matter, since jsvc dynamically loads the libjvm, so it wouldn't show up anyway. Probably the best thing to do is to try and run jsvc with the -debug flag and post the resulting output. If you are feeling like hacking around yourself, the reference to libjvm_campat.dylib is at line 142 of java.c. > > > Christopher Schultz-2 wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> bemaniac, >> >> On 9/3/2009 12:48 PM, bemaniac wrote: >>> When I install jsvc, even >>> though it appears to compile properly, it always fails to start. When I >>> check the catalina.out log, it gives the following message: >>> >>> 02/09/2009 16:46:42 30987 jsvc error: Cannot load required shell library >>> /Library/Java/Home/../Libraries/libjvm_compat.dylib >>> 02/09/2009 16:46:42 30986 jsvc error: Service exit with a return value >>> of >>> 1 >>> >>> Looking in my frameworks, it looks like "libjvm_compat.dylib" doesn't >>> exist, >>> but "libjvm.dylib" does exist, though I'm not sure if that's what it >>> should >>> be looking for. >> >> Hmm. I wonder how you were able to link against libjvm_compat.dylib >> during compilation. I wonder if your Java install is no longer sane. >> What version are you running? >> >> What do you get when you run: >> >> $ ldd jsvc >> >> ? >> >> If libjvm_compat.dylib isn't listed there, try: >> $ ldd -v jsvc >> >> ...and see which library jsvc uses that uses libjvm_compat.dylib >> >> Hope that helps, >> - -chris >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.9 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkqgP+0ACgkQ9CaO5/Lv0PBAswCguIwWgZh/zzfXS+yKcsgEHP23 >> fQcAn1AE1ap8EO1UHAzvLtiOG2bx/7eE >> =D/Hj >> -END PGP SIGNATURE- >> >> - >> 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://www.nabble.com/jsvc-will-not-start-on-Snow-Leopard---Tomcat-6-tp25279897p25285131.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
Re: query on tomcat connector
"Bhuvanesh Pattanashetti" wrote in message news:bce69da80909021136n22683ee8jeb4cf1ca927e2...@mail.gmail.com... > Hello, > > i wanted to create a https connector element at code level(not from > server.xml). > using > http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/connector/Connector.html > with protocol as Http11NioProtocol. > > I was not getting how to relate connector object and "keystore file and > keypassword" > You should use the setAttribute method for anything that doesn't have it's own setter. The 'name' is whatever is in the Tomcat docs for that particular connector. > Any suggestions? > > thanks.. > Bhuvan > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to set header (directly) before response is committed
"Martin Grotzke" wrote in message news:1251665502.4485.70.ca...@localhost.localdomain.tld... >On Sun, 2009-08-30 at 14:57 -0400, Christopher Schultz wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 > > > >Martin, > > >> On 8/30/2009 1:50 PM, Martin Grotzke wrote: > >> I found the ActionHook within the coyote response, so I'd try to wrap > > >this and intercept the action with ActionCode.ACTION_COMMIT. > > > > > >Is this the correct approach for solving this problem? > > > >Sounds like it has a decent chance of working. Have you tried it? >Not yet, but I'll start this evening hopefully. > Yes, this should work. It is the contract for ACTION_COMMIT that it sends the headers down the wire regardless of which Connector you are using. >> > >Doing this kind of thing is always a risky proposition, since there are >> lots of cases to test. >Hmm, which cases do you have in mind? > The main one I'd worry about is that it isn't guaranteed that ACTION_COMMIT won't be invoked more than once on a request (although it is rare), so you need to be able to handle this case. The second time it is called, the o.a.coyote.Response object will show itself as committed, so that is all you need to check. I'd keep a reference to the Response in my ActionHookWrapper to keep my sanity, but it should also be the 'param' value to the action method (but I haven't check if this is true in all Connectors). The other one would be that Tomcat reuses instances of it's low-level internal objects. So the Valve that wraps the ActionHook needs to check that it isn't re-wrapping an instance of your ActionHookWrapper. >> > >> Any other thoughts on this? > > >> Two related thoughts: > > > >1. Do you need all of the content to be generated before this header is > > set? If so, you'll need another strategy for 100% response buffering > > in order to meet your needs (say, calculating a cryptographic hash of > > the response content to include in a header). > > > >2. If you don't need #1, then why do you want to delay the header > > setting as long as possible? >To answer this, I need some more words. Basically, I'd like to add the >cookie only under certain conditions, but then after all session >modifications are definitely done. So what am I trying to do in more >detail? > >I'm creating the memcached-session-manager ([1]) as a session-failover >solution when running on tomcat. The memcached-session-manager is >basically storing a session additionally in a memcached node after the >request was processed - as a backup of the session. Normally, the >session is read from the jvm local session map. But if a request shall >be served for an unknown session id, the session is looked up in the >memcached and restored if found. Sessions are still kept locally to have >only one roundtrip to memcached for each request. As there might be >several memcached nodes used for session backup, the memcached node is >encoded in the session id, so that the appropriate memcached node is >selected for backup or restore. >In the case of a memcached failover, the memcached-session-manager >selects another memcached node for session backup, and changes the >session id accordingly. To let the client know that the session id has >changed, it must send a new JSESSIONID cookie with the new session id. > >So for this case, I want to defer the memcached-failure detection as >long as possible, until the response is committed. If I have a memcached >node in failure state, the response will also get a cookie with the new >session id, and at the end of the request the session id will be >migrated to the new memcached node. > >Cheers, >Martin > > >[1] http://code.google.com/p/memcached-session-manager/ > > > > >> - -chris >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.9 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkqay5wACgkQ9CaO5/Lv0PCUMQCgrJVkybrwNQY8CmWdDRnrvS2c >> XK0AnijgEiYnHEQtkFeGMIKErHcBciAt >> =HgEA >> -END PGP SIGNATURE- >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >-- >Martin Grotzke >http://www.javakaffee.de/blog/ > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client SSL certificate chain in Tomcat 6 when using AJP
"atul" wrote in message news:216148.14679...@web36801.mail.mud.yahoo.com... > I've a setup where Apache 2.2 is fronting Tomcat 6.0.20. They are talking > AJP/1.3 > Using mod_proxy_ajp. > I've a URL protected by client SSL. Apache prompts for client certificate > and I can get to the cert in my webapp (servlet). > However, when the cert have intermediate CAs, I still only get the leaf > cert and Not the cert-chain in my tomcat webapp ! > > Could not find a setting on apache (mod_proxy_ajp) to send cert-chain. > And even if it did, the tomcat code looks like it only wants to get single > cert! > org.apache.jk.core.MsgContext public void action(ActionCode actionCode, > Object param) {... > >} else if( actionCode==ActionCode.ACTION_REQ_SSL_ATTRIBUTE ) { >Request req=(Request)param; > >// Extract SSL certificate information (if requested) >MessageBytes certString = > (MessageBytes)req.getNote(WorkerEnv.SSL_CERT_NOTE); >if( certString != null && !certString.isNull() ) { >ByteChunk certData = certString.getByteChunk(); >ByteArrayInputStream bais = >new ByteArrayInputStream(certData.getBytes(), > certData.getStart(), > certData.getLength()); > >// Fill the first element. >X509Certificate jsseCerts[] = null; >try { >CertificateFactory cf = >CertificateFactory.getInstance("X.509"); >X509Certificate cert = (X509Certificate) >cf.generateCertificate(bais); >jsseCerts = new X509Certificate[1]; >jsseCerts[0] = cert; >} catch(java.security.cert.CertificateException e) { >log.error("Certificate convertion failed" , e ); >return; >} > Can possibly change it to something like (assuming the cert-chain gets passed in WorkerEnv.SSL_CERT_NOTE) >Collection certCollection = > cf.generateCertificates(bais); >X509Certificate [] certs = new > X509Certificate[certCollection.size()]; >int i = 0; >for (Certificate cert: certCollection) { >certs[i] = (X509Certificate)cert; >i++; >} > > > I tried it w/ Tomcat 5.5.27 as well with similar result. > Also, tried with original Java connector > org.apache.jk.server.JkCoyoteHandle & the new > org.apache.coyote.ajp.AjpProtocol with similar results. > > Seems like a bug ?? Or am I missing anything ? > Yes, it's a bug. Specifically https://issues.apache.org/bugzilla/show_bug.cgi?id=39637. With mod_jk, the "JkOptions +ForwardSSLCertChain" directive works. I'm too lazy to see if it has been implemented in mod_proxy_ajp. > Any prompt help is appreciated. > > > Thanks > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IP-based virtual hosting with Tomcat(6)
wrote in message news:2139500381.6699651248905929000.javamail.r...@sz0016a.emeryville.ca.mail.comcast.net... >All the vHosts are to be situated on the same server. >The server may be addressed using any loopback address >or any non-loopback addressed configured on the NICs of the >server. > >Hence I have the mapping > 127.0.0.9 -> vhost1 > 127.0.0.10 -> vhost 2 > >Let's say that a request arrives at address 10.1.1.1 (configured >as an external address of this server). > >Which vHost would serve this request? With the default Connector configuration, whichever vHost matches the Host: header sent by the client. If useIPVHosts=true in the Connector, whichever vHost matches the DNS name of the address of the IP address that the request was recieved on. >/U - 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: SSL mode configurations
If you are using mod_jk, then you need to configure SSL for Apache httpd. Go to http://httpd.apache.org and pick the documentation for your version from the menu on the left. "Anisha Parveen -X (anparvee - Infosys at Cisco)" wrote in message news:1b800a37d721054e9757581a51d11a85915...@xmb-bgl-419.cisco.com... Hi all, I want to configure SSL mode in my tomcat. I have cross checked my configurations with the default ss.conf. Everything seems fine. But https://localhost does not work. I use mod_jk for apache-tomcat connection. I am a beginner here and dont have much knowledge on same. Kindly let me know how to check what is the issue. I have followed the steps for SSL certificates and have obtained them. If some one could point me to a working configuration sample/ tutorial, i t would be highly useful for me to figure out what went wrong.. Thanks in advance, Anisha - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: request.getPathInfo() gets truncated when ";" is present
"Christopher Schultz" wrote in message news:4a68cd5b.2090...@christopherschultz.net... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Peter, > > On 7/23/2009 3:41 PM, Peter J. Farrell wrote: >> /index.cfm/somePathInfo&withMoreInfo/ > > Shouldn't that be /index.cfm/somePathInfo&%3BwithMoreInfo/ > > ? > > If you try the above URL, does it work? > > java.net.URLEncoder will encode ";" as "%3B". > > See the URL Specification (RFC 1738, > http://www.ietf.org/rfc/rfc1738.txt), section 2.2 "URL Character > Encoding Issues > ": > > " > Many URL schemes reserve certain characters for a special meaning: > their appearance in the scheme-specific part of the URL has a > designated semantics. If the character corresponding to an octet is > reserved in a scheme, the octet must be encoded. The characters ";", > "/", "?", ":", "@", "=" and "&" are the characters which may be > reserved for special meaning within a scheme. No other characters may > be reserved within a scheme. > " > > The HTTP specification does not specifically say that semi-colons are > reserved, but perhaps the common interpretation of the URL spec is such > that semi-colons should always be encoded. > Actually it does, just by reference. Section 3.2.1 of RFC 2616 defers to RFC 2396. And section 3.3 of that RFC gives a special meaning to ';'. Tomcat doesn't handle this correctly according the the RFC, but no developer/contributor has had enough of an itch to fix it. But I doubt that fixing it would help the OP much. The fully compliant Tomcat would have to remove anything after a ';' (including the ';') up until the next '/' (if any) for the purpose of mapping the request. It should then re-include them in the various parts of the request URI (except for ";jsessionid"). So it's a lot of work to implement an archane feature that has plenty of work arounds. > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkpozVsACgkQ9CaO5/Lv0PBnLwCfXFSSIDAnRR0BurRKeS0ub/v9 > 3UYAoJ1gp5oIqnJw2WgHx9LdVzqqAOAI > =rpT0 > -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Symlinks inside WEB-INF/classes not working for me
"Christopher Schultz" wrote in message news:4a5be03c.7050...@christopherschultz.net... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > David, > > On 7/13/2009 8:50 PM, David Smith wrote: >> If you look at all the third party repackages of tomcat that fail, >> you'll see a theme -- symlinks cause problems in java. I would highly >> recommend you find a way to maintain that config file via the build >> system and have a copy in each of the webapps. Either that or put a >> copy in tomcat's lib folder where it becomes accessible to all webapps >> in the environment. > > While I agree with your recommendation for using a more sophisticated > build/deployment process, I disagree with your reasoning. Java and/or > Tomcat should not have any problem reading files via symlinks. As far as > I know, Java's I/O API does not have the ability to distinguish between > symbolic and hard links. I suspect the problem lies elsewhere. > My first guess is that there is a SecurityManager lurking somewhere to stop the OP from doing: ln -s /etc/passwd > It's possible that the native part of the ClassLoader has some objection > to symlinked files, but I can't imagine that to be true. > > I have never had any problems with symlinks from Java programs in the > past. That doesn't mean that I've seen everything, though. > > John, what is the actual error when the file cannot be found? What > happens if you try to open the file using a FileInputStream instead of > the ClassLoader? > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkpb4DwACgkQ9CaO5/Lv0PA3MACdERUerLlhWtgnMlI6ruGLor4/ > UHgAn1myPgqBIMbvMoWJylPdi1fdCteQ > =t8RA > -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jsp:forward adds params to query-string
"Yves Glodt" wrote in message news:abd6c6120907070628v26c8b1d3jbd7e31708e30d...@mail.gmail.com... > Hi, > > I have a simple jsp-page whose only purpose is to jsp:forward to my > main controller-servlet, here it is: > > <%@ page session="true" %> > <%@ page language="java" contentType="text/html; charset=UTF-8" > pageEncoding="UTF-8"%> > > > > > The problem I have is that the request comes as POST to the servlet, > but without the "o"-parameter. > The o-param instead comes as query-string o=action1 > Yes, this is what is specified in the Servlet spec. A adds the parameter to the query-string. > Note that the post-request comes from an external URL. > > Does jsp:foward not preserve the original request? I would like to keep > all POST > The POST parameters will still be available. What the Servlet will see (using request.getParameter(String) and friends) is the union of the query-string parameters and the POST parameters. Of course, u could have found this out faster by testing it yourself ;). > Best regards, > Yves - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Changing url rewriting behaviour (';jsessionid')
"Daniel Henrique Alves Lima" wrote in message news:1246314288.10803.6.ca...@magnaopus.no-ip.biz... > Yes ! > > Now imagine my frustration with ooffice escaping a ';' :-( > > Browser, wget and other applications seems to work ok with URL encoded > jsessionid. > The custom valve isn't that complicated (but of course, it ties you to Tomcat, and may need to be updated when you change from major releases). It would probably look something like: public class MySessionValve extends ValveBase { public void invoke(Request request, Response response) throws IOException, ServletException { String sessionID = getSessionId(request); if(sessionID != null) { request.setRequestedSessionId(sessionID); } getNext().invoke(request, response); } private String getSessionId(Request request) { // Logic to extract the sessionID from the request here } } On all supported versions of Tomcat, this will be invoked before authentication (or at least if you don't make major changes to the configuration). If this was my project, I'd probably take the big one-time pain of creating a Tag to decide how to encode links (based on user-agent or otherwise) and change all my pages to use it. Otherwise, a Filter that wraps the response and overrides getWriter is probably easier than trying to wrap the TC internal Response. > > On Tue, 2009-06-30 at 00:00 +0200, André Warnier wrote: >> Daniel Henrique Alves Lima wrote: >> ... >> Hi. >> If I understand what you are trying to do : >> 1) a client enters your application, authenticates, navigates, and >> displays a result html page. >> 2) on this page, is a button that says "get this page as PDF" >> 3) the client clicks on that button, and is supposed to receive the same >> page, but this time as a PDF. >> 4) At the server side, you want to use OOo to create the PDF version >> from the html page >> 5) and OOo is capable, given a URL, to retrieve this page, and then >> given appropriate commands, to return a PDF version of the page. >> 6) But OOo has trouble with the "jsessionid" part of the URL, although >> it needs it in order to retrieve the page on behalf of the client. >> Right ? >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > -- > "If there must be trouble, let it be in my day, > that my child may have peace." > > Thomas Paine - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bizarre NoClassDefFoundError
"A. Rothman" wrote in message news:965599.49.1245887723160.javamail.sys...@endor... > > Yes, I've compared both the generated java files and corresponding > compiled class files from when it works and when it doesn't work - they > are identical. I think the problem is not with the bean sources, jsps, > configuration, permissions, file locations, classpaths, etc. - because > all of these remain constant, and as such do not explain why it would > work ok in the cases where it does. You're right about having to set up > tomcat from scratch from the official sources to be certain it's not the > distro's fault - but here too the chances of a distro's repackaging of > tomcat causing a bizarre edge case in classloading during initialization > seem slim. > > I'm inclined to think this may actually be a tomcat bug - since the > errors are influenced by which jsp is the first one loaded by tomcat (a > user-generated race condition of sorts), and not by their content or > configuration. To be certain, I'd have to set it up for a debug, which > I'll do (along with running it from the original sources first, of > course) if there is no other choice, as it can be very time consuming. I > just thought I'd run it by the experts here to see if there's some known > issue, or something about the tomcat internals which I'm unaware of, or > just something obvious and silly I've missed. > It actually looks a lot like a permissions issue, since the Bean class will be loaded in trusted (Tomcat) code when the page recompiles and will then be available for everyone else to use. You could try setting up a copy of your Tomcat (on, say a developement box) that doesn't use a SecurityManager and see if you can reproduce the problem there. You might also get some more information by setting: org.apache.catalina.loader.level=FINEST in your conf/logging.properties file on a system using a SecurityManager (very much not recommended for an active production system). > I appreciate the help and suggestions from everyone here - thanks :-) > > Amichai > > > Caldarale, Charles R wrote: >>> From: A. Rothman [mailto:amich...@amichais.net] >>> Subject: Re: Bizarre NoClassDefFoundError >>> >>> Any other thoughts? >>> >> >> You could actually try a real Tomcat, rather than just browsing someone's >> likely incomplete list of what has been changes. >> >> Have you compared the failing generated .java file with the one that >> works? >> >> - 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: SSLImplementation
"Susumu Sai" wrote in message news:7d50e06a0906231422q734e985dybc92648f59fae...@mail.gmail.com... >I have confirmed that SSLImplementation attribute works in Connector >of server.xml file (Refer to >http://mail-archives.apache.org/mod_mbox/tomcat-users/200609.mbox/%3c6244765.p...@talk.nabble.com%3e). >But I just don't understand why SSLImplementation attribute is not >included in Tomcat 6.0 document - >http://tomcat.apache.org/tomcat-6.0-doc/config/http.html. Mistake or >any reason? TC 6.0 only supports one type of SSLImplementation out-of-the-box (JSSE). So anyone that wants to use this attribute has to already know enough about Tomcat internals to write their own SSLImplementation. Including it in the docs would just confuse 99.99% of users. But, yes, the hook is there for anyone that wants to plug in their favorite SSL library. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: chunked encoding
"Christopher Schultz" wrote in message news:4a32c4e3.6060...@christopherschultz.net... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Anthony, > > On 6/12/2009 1:47 PM, Anthony J. Biacco wrote: >> Well, they used to be static JS files, then we decide we wanted more >> flexibility in the content that went into them, so we stuck them in a >> database and decided to generate them as needed. > > Er.. SELECT LENGTH(content), content FROM content_table? > > Or are you saying that you get some kind of template from the database > and fill-in the details dynamically. > > I have to imagine that you could figure out the length of this data > before you start streaming it back to the client. In that case, you > simply have to provide your own Content-Length header. > > This just sounds like you're making it harder than it is. > Generally going to agree with Chris here that you're making it harder than it is. If you are sending files on the order of about 12Kb (as specified in another post), then just put a Filter in front of it that wraps the response and the wrapper buffers the content, and then sets the content-length header when control returns to the Filter. I did one of these as a toy a few years back (meaning that the coding style is awful), but it worked fine. Of course, this doesn't work well if you expect to send multi MB sized files. > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkoyxOMACgkQ9CaO5/Lv0PD/GQCgwEZm3lMeEoSww1P/4gBysiQi > 8lcAnitGUVWQNzCA2LNVT+jwdnAZDQAF > =tS84 > -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: chunked encoding
"André Warnier" wrote in message news:4a317d8d.3060...@ice-sa.com... > Anthony J. Biacco wrote: >> No dice. I tried a bufferSize of 16384 and an 11K response still got >> chunked. Even tried using packetSize and max_packet_size (mod_jk). >> > I think we need Rainer here. > No, the various AJP Connectors don't auto-set the content-length header (unlike the HTTP/1.1 Connectors). They just pass on (or not) the value set by the Servlet. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Periodic slow response to initial call to HttpServletRequest.getParameter()
"Mark Thomas" wrote in message news:4a31874f.8040...@apache.org... > Brian Harper wrote: >> Questions: >> 1. When is my servlet instantiated by Tomcat and its doPost method >> called? > Once the headers have been received and Tomcat can map the request. > But it is instantiated only for the first request, unless it specifies load-on-startup, then it is instantiated when the webapp is loaded. >> Does this happen before the entire body of the request has been >> received? > Yes. > >> In which case perhaps the delays are simply due to slow client >> connections? > Maybe. > >> 2. What is Tomcat doing when the first call to getParameter is made? >> What kind of parsing does it have to do to respond? > It has to read all of the POST body and parse it. > >> 3. Any ideas why we'd see such long response times on occasion, but not >> consistently? > Slow clients is one option. Clients that specify an invalid content > length could be another. Tomcat might be hanging around waiting for the > extra data that never arrives. Eventually a time-out kicks in. I'd need > to check the source to see exactly how this is handled. I can't remember > if Tomcat abandons the request, ignores the missing data or does > something else. > Using AJP, the handling of the content-length is done by httpd. Unless it is so slow that the connectionTimeout kicks in, Tomcat won't timeout on reading the body (but httpd probably will). But, this isn't a content-length issue (I looked at the code), since what would happen then is that no POST parameters would be available. Also, the AJP/1.3 protocol tells mod_jk/mod_proxy_ajp to send the (by default) first 8Kb of the body to Tomcat without Tomcat asking. So, unless the body is really big, the gap is probably between the client and httpd. But to do more than guess, the OP would need to follow Rainer's suggestion, and provide DEBUG level logs. > Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat maxThreads Issue
"Caldarale, Charles R" wrote in message news:0aae5ab84b013e45a7b61cb66943c17228fc438...@usea-exch7.na.uis.unisys.com... >> From: Jones, Keven [mailto:keven.jo...@ncr.com] >> Subject: RE: Tomcat maxThreads Issue >> >> > enableLookups="false" protocol="AJP/1.3" redirectPort="8443" >> maxThreads="400" connectionTimeout="2"/> > >The syntax is ok, but I'd have to look at the code to see if >connectionTimeout applies to anything other than the first >request coming >through. (AJP connections are intended to be persistent.) > No, connectionTimeout applies to all requests. Any time that the Connector thread doesn't hear from httpd within 20 seconds (with this configuration) it will hang up and return to the pool. Note: this value also applies to reads from the request body. But I think almost all connections can send the default 8Kb in 20 seconds. The value for connectionTimeout looks low except for high-traffic sites (would go for something more like 5 minutes for a moderate traffic site). That would allow traffic spikes to die out without forcing unnecessary reconnections. You may also want to configure cping/cpong on the Apache side to aid mod_jk to detect that the connection has timed out. > - Chuck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: implementing a Manager - how do I get a reference to it?
"Nolan Johnson" wrote in message news:291765.23953...@web38808.mail.mud.yahoo.com... > > I'm implementing a Manager (session management) that stores sessions on > shared servers (that is, a distributed manager, but not the default one > that comes with tomcat). A key difference between the implementation that > I'm working on and the ClusteredManager is that the entire session is > distributed when it changes, rather than sending individual parameters > around over the network. > > The problem that I'm having is that the Manager needs to be notified when > the request has finished with the session. I'm aware that I can create a > ServletRequestListener, and I think that the requestDestroyed method would > be a reasonable time for me to be telling the manager that it should > distribute the session. However, I can't for the life of me figure out > how to get a reference to the Manager from a ServletRequestListener. > > I've tried: > - having the ServletRequestListener also be a ServletContextListener, but > I can't navigate to the manager from there. > - finding the Manager through the session, but that's a > StandardSessionFacade, which doesn't reveal the manager. > - having the ServletRequestListener also be a ContainerListener, but I > can't make the same instance of the Listener be registered as both (since > registerting a ServletRequestListener through the StandardContext doesn't > allow me to register an object, I can only tell it what class to use). > > Any suggestions? Either for how I can have my ServletRequestListener get > a reference to the Manager, or for other strategies for knowing when the > Request is finished with the Session so that I can distribute it. > Since you are already programming against Tomcat internals, the simplest is probably to write a Valve instead of a ServletRequestListener. The Valve will have access to all Tomcat internal Objects, and so could get to the Manager fairly simplily. > Thanks. > > Nolan > > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with overriding the default servlet on tc 6.0.18
"Joseph S" wrote in message news:4a2da6d6.50...@selectacast.net... >I have this in the web.xml of my application: > > > > MyServlet > > >/ > > > > > Which works fine, except for requests without pathinfo (i.e. > http://servername/ ). That still seems to be handled by the default > tomcat servlet, which is serving up the index.jsp that I no longer want to > use. Am I doing something wrong or is this a bug? > This is a feature. Tomcat needs to process the before doing Servlet mapping so that the correct servlet is invoked for the welcome file. > Incidentally I discovered you can't by having an empty > element, you have to have at least one in there or the > default servlet will use the one in $CATALINA_BASE/conf/web.xml . Bug or > feature? I'd say an enhancement rather than a bug, since you can always do (as you have discovered): index.doesnotexist For the benifit of the archives, this of course assumes that you have set replaceWelcomeFiles="true" in the element. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authentication from the browser
"Alec Swan" wrote in message news:34abb48b0906021503t158542a5ube612b5ccfad0...@mail.gmail.com... > On Tue, Jun 2, 2009 at 2:34 PM, Jonathan Mast > wrote: > >> Alec, so basically members of your client company should be able to have >> direct access to a servlet that is otherwise restricted to a handful of >> users who must authenicate themselves with a username/password login, >> right? >> > > Yes, this is exactly what we need. > Awhile back, I had a request to do something similar. However, in this case the (then) client was providing a portal that their users logged onto, and proxied to our app. What we did is to clone the webapp and make the clone authenticate with CLIENT-CERT. The client portal would then proxy to the clone and provide the same certificate for all users that it had authenticated (which Tomcat then accepted). In this case, even if a blackhat could find the URL for the clone, she still couldn't get in. > >> >> One solution to this situation would be to create a simple servlet that >> sniffs incoming request IPs, if they match the range/set of IPs of your >> client, then you bypass the authenication mechanism of your existing >> servlet >> and give them a full view of whatever goodies your servlet has. If >> incoming >> requests don't match the IPs then bounce them off somewhere. >> >> However this approach is not a complete solution, a very interested party >> could observe your system and deduce that it was based upon privileged >> IPs >> and then spoof them. It all depends upon how important this servlet is >> you >> and your organization. If it is absolutely mission critical, then you'll >> want to use SSL and require logins. > > > The servlet is not mission critical and provides only read-only access. I > like this idea, but as Hassaan pointed out it does not allow our customer > users to access this page if they are outside of the VPN. > > > >> >> >> On Tue, Jun 2, 2009 at 4:01 PM, Alec Swan wrote: >> >> > I may not be explaining it clearly. >> > >> > We have one corporate customer who is putting a link to our servlet on >> > their >> > intranet web page. Therefore, we know the domain name of the users who >> need >> > custom authentication. We can also tell the customer to put whatever we >> > need >> > in the link, such as HTTP headers. >> > >> > Does this give you enough information to propose a solution? >> > >> > >> > On Tue, Jun 2, 2009 at 12:22 PM, Hassan Schroeder < >> > hassan.schroe...@gmail.com> wrote: >> > >> > > On Tue, Jun 2, 2009 at 11:03 AM, Alec Swan >> > > wrote: >> > > > Hassan, I don't think that the goals are contradictory, because >> > > > each >> > goal >> > > > applies to its own group of users: our customer users and everybody >> > else. >> > > > Customer users should not have to enter user name and password, but >> > > > everybody else should. >> > > >> > > IOW, you want it protected, and you want it openly accessable. >> > > Sorry, that sounds contradictory to me :-) >> > > >> > > If you have "a customer who would like to put a link on a web page" >> > > to your servlet, that servlet's URL is now "in the wild" -- anyone >> > > who >> > > finds it can access it. >> > > >> > > > I am glad that you made me think about this, because maybe it is >> > possible >> > > to >> > > > extend Tomcat authentication to also use client IP address or >> > > > domain? >> > > >> > > How would you know a priori the IP or domain of the clients? >> > > >> > > -- >> > > Hassan Schroeder hassan.schroe...@gmail.com >> > > >> > > - >> > > 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: Which listeners required in server.xml?
"Christopher Schultz" wrote in message news:4a20aa17.2050...@christopherschultz.net... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > John, > > On 5/29/2009 6:08 PM, johnrock wrote: >> I am using standalone tomcat (no apache) without SSL, without APR, I am >> not >> using any manager or host-manager applications .. > > Adding the APR library will give you a significant performance > improvement even with the plain-old HTTP connector. It might be worth > installing APR and leaving that listener in there. > Urm, and u are basing this on what? A low-traffic dynamic site should see next to nothing using APR, and could even lose (given the interlocks to JNI). It all depends on who is smarter, the JVM developer, or the APR develper for CentOS. Again, to the OP, profile both configurations for your OS, and make the decision then. > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkogqhcACgkQ9CaO5/Lv0PDCKwCfRq5BCxjaog1MQYTqbMzY7zpc > r4AAn0cu/kmZmWNq+stofg9zLEXeDP0p > =/Oi6 > -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Portable Runtime ?
"Caldarale, Charles R" wrote in message news:0aae5ab84b013e45a7b61cb66943c17228f1795...@usea-exch7.na.uis.unisys.com... >> From: johnrock [mailto:johnpi...@yahoo.com] >> Subject: Re: Apache Portable Runtime ? >> >> Given that, is it still a preferred idea to install APR? > >Your best bet is to measure the performance of your webapp with and without >APR. Since you're not using SSL and >have limited static content, I >suspect you won't see much of a difference. > I agree with Chuck. The performance of APR against the other connectors varies a lot depending on the OS (e.g. last time I saw numbers, which was a while ago, APR for dynamic content was slower on Windows). If you don't expect to be handling a lot of concurrent connections with HTTP only than APR doesn't offer a lot of benifits. >> Is installing the APR considered a 'must do' for anyone >> looking to maximize the performance of Tomcat in production? >> Or is this something in the category of 'not neccessary/ >> adviseable unless you need it'? > >I'd put it in the latter category, unless you measure a noticeable >throughput gain with it. Including APR does reduce portability, since >you'll need a different native library for each platform, including just >going from a 32- to 64-bit JVM. > >- 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: Which listeners required in server.xml?
"johnrock" wrote in message news:23787784.p...@talk.nabble.com... > > Running tomcat 6.0.18 server.xml has the following listener's enabled by > default: > > > > SSLEngine="on" /> > If you are not using APR, than you don't need this (and removing it gets rid of a message at startup). > > > If you are never going to use JSP pages, can probably remove it. However, it's pretty light-weight so would leave it in just so that I don't have to spend time with any weird errors. > > /> This looks like it is left over from the admin webapp (RIP). It doesn't look like it does anything particularly useful anymore, but again the warning about weird errors. > className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> > Also left over from the admin webapp (RIP). This one really doesn't do anything particularly useful anymore, so it is safe to remove. It should probably be removed from the distribution as well (at least for TC 7), since it was a bad idea in the first place. > I am using standalone tomcat (no apache) without SSL, without APR, I am > not > using any manager or host-manager applications .. > > Do I need these listeners or can I remove some/all of them? > > -- > View this message in context: > http://www.nabble.com/Which-listeners-required-in-server.xml--tp23787784p23787784.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
Re: Upload stop after 30 minutes: Processing of multipart/form-data request failed. Stream ended unexpectedly
"Patrick Herber" wrote in message news:4a19b564.8030...@ticino.com... > Hello > > I've made some more tests and after reading the Book "*Tomcat, The > definitive Guide*" I discovered the existence of a parameter called > "*connectionUploadTimeout*" (below I join the description of this > property taken from this book). > I've changed the configuration of the HTTP connector and now uploading > big files directly on tomcat (without Apache HTTP) works without problems: > > connectionTimeout="60" >connectionUploadTimeout="360" >disableUploadTimeout="true" >redirectPort="8443" /> > > However, if I reset our original configuration with Tomcat behind an > Apache HTTP connected with mod_proxy_ajp (or mod_proxy_http) I get the > same Exception as before (the Upload stops after 30 minutes). > > >ProxyRequests Off >ProxyTimeout 3600 This looks a lot like 30min ;) > >ProxyPass ajp://localhost:8009/ >ProxyPassReverse ajp://localhost:8009/ > > > > connectionTimeout="60" >connectionUploadTimeout="360" >disableUploadTimeout="true" >redirectPort="8443" /> > > Or > > >ProxyRequests Off >ProxyTimeout 3600 > >ProxyPass http://localhost:8080/ >ProxyPassReverse http://localhost:8080/ > > > > connectionTimeout="60" >connectionUploadTimeout="360" >disableUploadTimeout="true" >redirectPort="8443" /> > > I've tried setting the "timeout" parameter in the ProxyPass instruction > to one hour: > > ProxyPass ajp://localhost:8009/ timeout=3600 > > But it did not help... > Do you have any suggestion? > > Thanks a lot for your attention and your help > Patrick > > > Here the description of the three properties copied from the Book > "Tomcat, The definitive Guide" (O'Reilly, Jason Brittain with Ian F. > Darwin). I missed these information in the official Tomcat documentation > (didn't I see it?): > > *disableUploadTimeout* > Should Tomcat use the regular connectionTimeout for request socket > connections even for long servlet requests, such as uploads? Setting > disableUploadTimeout to true allows long requests to servlets to > continue without the Connector closing the connection. Setting it to > false means that a longer connection timeout (connectionUploadTimeout's > value) will be used for requests to servlets. Setting it to false means > that the lower connection timeout specified in the connectionTimeout > attribute will be applied to all types of requests. > The default for this attribute is not consistent between Connector > implementations and versions of Tomcat. We strongly suggest that you > explicitly set it to either true or false. > > *connectionTimeout* > The Connector may wait a configurable number of milliseconds from the > time the client's request TCP socket is accepted until the request > method line is sent to Tomcat. > The default is 1 minute. 6 > > *connectionUploadTimeout* > By default, Connectors keep request socket connections open while Tomcat > processes the request, until the connectionTimeout of 1 minute has > passed. At that point, the Connector will close the socket. But, this > causes trouble if the request was for a long running servlet, such as a > file upload. During requests that map to servlets, Tomcat will use a > longer timeout, specified by the connectionUploadTimeout attribute in > milliseconds. > The default is 30 milliseconds (5 minutes). 30 > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 - not started AJP/NIO on CentOS
"Dmitriy Repin" wrote in message news:4a167e1a.30...@inbox.ru... > Tomcat 6.0.18 > JDK 1.6.0_13 > > I want to use AJP/NIO connector, but it didn't started on CentOS > (neither Intel no AMD platform). > > May 22, 2009 10:07:52 AM > org.apache.catalina.startup.SetAllPropertiesRule begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'channelNioSocket.port' to '8009' did not find a matching > property. > May 22, 2009 10:07:52 AM > org.apache.catalina.startup.SetAllPropertiesRule begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'channelNioSocket.maxThreads' to '97' did not find a matching > property. > May 22, 2009 10:07:52 AM > org.apache.catalina.startup.SetAllPropertiesRule begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'channelNioSocket.maxSpareThreads' to '50' did not find a > matching property. > May 22, 2009 10:07:52 AM > org.apache.catalina.startup.SetAllPropertiesRule begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'channelNioSocket.minSpareThreads' to '25' did not find a > matching property. > May 22, 2009 10:07:52 AM > org.apache.catalina.startup.SetAllPropertiesRule begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'channelNioSocket.bufferSize' to '16384' did not find a > matching property. > May 22, 2009 10:07:52 AM org.apache.tomcat.util.net.NioSelectorPool > getSharedSelector > INFO: Using a shared selector for servlet write/read > May 22, 2009 10:07:52 AM org.apache.coyote.http11.Http11NioProtocol init > INFO: Initializing Coyote HTTP/1.1 on http-8080 > May 22, 2009 10:07:52 AM org.apache.coyote.ajp.AjpAprProtocol init > INFO: Initializing Coyote AJP/1.3 on ajp-0 It seems that you have the AJP/APR connector configured. But still follow Chuck's advice and post your server.xml > May 22, 2009 10:07:52 AM org.apache.catalina.startup.Catalina load > INFO: Initialization processed in 1357 ms > May 22, 2009 10:07:52 AM org.apache.catalina.core.StandardService start > INFO: Starting service Catalina > May 22, 2009 10:07:52 AM org.apache.catalina.core.StandardEngine start > INFO: Starting Servlet Engine: Apache Tomcat/6.0.18 > May 22, 2009 10:07:59 AM org.apache.catalina.core.ApplicationContext log > INFO: quartz: Quartz Initializer Servlet loaded, initializing Scheduler... > May 22, 2009 10:07:59 AM org.apache.coyote.http11.Http11NioProtocol start > INFO: Starting Coyote HTTP/1.1 on http-8080 > May 22, 2009 10:07:59 AM org.apache.coyote.ajp.AjpAprProtocol start > INFO: Starting Coyote AJP/1.3 on ajp-0 > May 22, 2009 10:07:59 AM org.apache.catalina.startup.Catalina start > INFO: Server startup in 6751 ms > > But it works fine on Solaris 10, Ubuntu and Windows XP. > > May 7, 2009 3:16:23 PM org.apache.tomcat.util.net.NioSelectorPool > getSharedSelector > INFO: Using a shared selector for servlet write/read > May 7, 2009 3:16:23 PM org.apache.coyote.http11.Http11NioProtocol init > INFO: Initializing Coyote HTTP/1.1 on http-8080 > May 7, 2009 3:16:23 PM org.apache.catalina.startup.Catalina load > INFO: Initialization processed in 837 ms > May 7, 2009 3:16:23 PM org.apache.catalina.core.StandardService start > INFO: Starting service Catalina > May 7, 2009 3:16:23 PM org.apache.catalina.core.StandardEngine start > INFO: Starting Servlet Engine: Apache Tomcat/6.0.18 > May 7, 2009 3:16:26 PM org.apache.coyote.http11.Http11NioProtocol start > INFO: Starting Coyote HTTP/1.1 on http-8080 > May 7, 2009 3:16:26 PM org.apache.jk.common.ChannelSocket init > INFO: JK: ajp13 disabling channelSocket > May 7, 2009 3:16:26 PM org.apache.jk.common.ChannelNioSocket init > INFO: JK: ajp13 listening on /0.0.0.0:8009 > May 7, 2009 3:16:26 PM org.apache.jk.server.JkMain start > INFO: Jk running ID=0 time=0/27 config=null > May 7, 2009 3:16:27 PM org.apache.catalina.startup.Catalina start > INFO: Server startup in 3694 ms > > Any idea? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: xml validation on -- good idea or not?
"Julian Dunn" wrote in message news:4a14199c.4caf.003...@cbc.ca... > > Hi, > > Is it a good idea to run with xmlValidation="true" in server.xml? > In a development enviroment, it can be helpful (especially if you change web.xml often). I would generally discurage it in a production environment since the app will take slightly longer to load. > I had this on for a while, but then it mysteriously stopped working -- > the container could no longer validate DTDs, refused to load webapps, > etc. > And another good reason to not use it in production ;). > What does xmlValidation="true" actually do? > Xie is basically right, except that Tomcat *should* be using the schemas that it ships with. So not having an internet connection is not supposed to be a problem. > I am using Tomcat 5.5.23. > > - Julian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance on socket reads
"David kerber" wrote in message news:4a0dbf88.6030...@verizon.net... > Christopher Schultz wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> David, >> >> On 5/15/2009 12:22 PM, David kerber wrote: >> >>> But the code works; it just seems to be a little slow. >>> >> >> Gotcha. How slow are we talking, here? I'm not sure whether the >> underlying InputStream, here, is buffering, but you could try: >> > Not noticeably slow from a human watching it viewpoint, but when I do a > thread dump, I see quite a few of the threads waiting on the .read() > statement. "quite a few" in the case of the one I did just now (the > busiest time of day for this app) means 12 out of the total of 75 > http-processorXXX threads. > >> iStream = new BufferedInputStream(req.getInputStream()); >> >> ... to see if that improves things at all. >> > I was wondering about that, too. I couldn't see anything that > specifically said whether the InputStream from an HttpServletRequest was > buffered or not, but the implication from some reading about a 3rd party > BufferedServletInputStream is that TC 4.x and later provide a buffer for > it. > Yes, the TC implementation of the ImputStream from the Request is buffered (although it doesn't extend BufferedInputStream). It is possible that wrapping it in a BufferedInputStream could even slow the app down (by making it wait until all the data is available). >> >>> At this point, [the data is] still encrypted, and a string may not >>> properly >>> handle some of the bytes. >>> >> >> Oh, right. I forgot you were sending encrypted data. >> >> I think you may have better luck reading until there is no more input, >>> What method would you suggest? Create the byte array long enough to >>> handle any possible input and then read without specifying the length? >>> >> >> Something like that. After thinking a bit about it, specifying more >> bytes to read than are available either blocks (waiting for more data >> that will come) or returns after reading fewer bytes (because the stream >> is closed and there's no more to read). Your code should be pretty good >> as-is. >> > > Thanks, > D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector for diameter protocol
"kramasundar" wrote in message news:23519306.p...@talk.nabble.com... > > Hi, > > I am trying to port our existing plain old java diameter ( > http://en.wikipedia.org/wiki/Diameter_(protocol) Diameter wiki page ) > server > on top of tomcat. > > I am new to J2EE/Tomcat. > > Since Diameter is quite different from HTTP it is bit difficult to get > started with doing things. As far as i have read, it seems that i need a > "protocol handler" for Diameter protocol and feed it into tomcat. Could > any > one of you please direct me to some documents/references that describes > how > to develop custom protocol handlers for non HTTP protocols like > Sip/Diameter/Radius. > Such support as there is amounts to HTTP under Diameter ;) Well, there isn't much documentation outside of the JavaDocs and the code. Probably the place to start is http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/coyote/package-summary.html. You are correct that you need to create a ProtocolHandler. This classs is responsible for accepting requests, and passing them off to a Thread to handle them (more on that later). There are ThreadPool classes, and Executor support classes lying around that you might be able to use for the thread management (e.g. browse the org.apache.tomcat.util.net package to see if anything works for you). The Object in the thread then has to parse the request according to the protocol, and fill in a Request object (from org.apache.coyote), and initialize a Response object (same package). Look at the existing Connectors (especially MemoryConnector, which is the simplest) for how to do this. It then passes these off to the Adapter that Tomcat will pass to your ProtocolHandler. That will run it through your Servlet, and pump the data back to the client. You will possibly need InputBuffer and OutputBuffer implementations to do the protocol translation. I guess the last thing is that you enable it via and any attributes in in ... will be passed to your ProtocolHandler JavaBean style. > Thanks, > Ramsundar > -- > View this message in context: > http://www.nabble.com/Connector-for-diameter-protocol-tp23519306p23519306.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
Re: Parameter value based on server
"Paul M" wrote in message news:402632.36770...@web44811.mail.sp1.yahoo.com... >Hi > >I want a parameter such as the following: >override="false"/> If you set a system property via -DcompanyName="My Company, Incorporated", then you can do: Tomcat will expand the ${companyName} to the value of the system property when it parses the xml file. And, no, the property name doesn't have to be the same as the Parameter name. This is a Tomcat feature, but since you are putting it in a Tomcat configuration file, I'm going to guess that that won't bother you. >to have different values on different tomcat servers. Say 3 applications on >2 different tomcat boxes, all of which will use >element companyName. >However, companyName will be different on the two boxes. > >I thought of putting this in the context.xml or web.xml file. >However, my understanding is that these files are used by Servlets only? >I have a "helper class" that will need different name,value pairs on >different boxes. >What solutions are available? What solutions should I investigate? > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Force getting Client Cert from browser
"i_am" wrote in message news:23286972.p...@talk.nabble.com... > > Thanks Charles. > Ok getting back to it after a looong break... > > I looked at the ssl traces and looks like client is sending server an > Alert > (21) Warning (close notify) but, > server (tomcat) seems to ignore it! > Is there a way (config) to force tomcat to renegotiate ? Nope. Tomcat relies on the underlying JVM implementation for secure sockets for the most part. > I even tried to invoke Tomcat action code ACTION_REQ_SSL_CERTIFICATE > which, > I thought should force renegotiation but still does not. As you have found out, this will only force renegotiation if the client cert is missing. Anyway, most browsers treat CLIENT-CERT like BASIC and just resend the credentials. > I still see the same behavior where Tomcat just uses cached certificate!!! > > Versions : Tomcat 5.5.27 with Java 1.6.0_11 on SLES10. > > Any help is appreciated... > > Thanks > > > > > Caldarale, Charles R wrote: >> >>> From: atul [mailto:techat...@yahoo.com] >>> Subject: Re: Force getting Client Cert from browser >>> >>> I tried invalidating httpsession but that didnt work. >> >> I'm a bit surprised at that, but I haven't gone through the code enough >> to >> figure out why that didn't work. There's a tangentially related thread >> here: >> http://marc.info/?l=tomcat-user&m=120092922008604&w=2 >> >>> Also, in a deployment where if a machine is shared by >>> multiple users and user1 forgets to close the browser before >>> leaving, the user can log right in as user1. >> >> A problem in any environment that has shared access points, not unique to >> using certificates for client authentication. >> >> - 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: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> > > -- > View this message in context: > http://www.nabble.com/Force-getting-Client-Cert-from-browser-tp20155194p23286972.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
Re: Gzip compression take 2
By any chance are you using the APR connector? If so, it will use sendfile (unless explicitly disabled) for large static files which bypasses the connector compression logic. "Michael" wrote in message news:49de445c.3050...@gmx.net... > Hi folks, > > I recently had a discussion with Chuck about, in my opion, the faultly > gzip compression filter in the Connector. Unfortunately, the discussion > ended without a solution for the problem. > Basically, Tomcat fails to compress anything else but JSPs regardless > whether I set compressableMimeType or not. > > I am on Tomcat 5.5.27, WinXP SP2. I even scanned through Tomcat code but > wasn't able to track the problem. > > Is anyone able to receive compressed JS or CSS files, which are servered > from static files? > > Thanks, > > Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Where to Place .dll files in TOMCAT?
"ajmerasunny" wrote in message news:22766008.p...@talk.nabble.com... > > Hi All, > I have a java web application running on TOMCAT 6.0 which is > accessing > few .dll files.I am getting "UnsatisfiedLinkError" while running my > application. I have copied these .dll files in System32 folder. Could > anyone > please tell me where should i place these .dll files to get my app > working. > > Please help. If you are running as a service, using the standard Tomcat wrapper, then you should place the dll files in the same directory as tomcat6.exe (usually %CATALINA_HOME%\bin). If you are running from the startup.bat script, then they need to be somewhere on the %PATH%. I wouldn't recommend placing dll files in System32 unless absolutely there is no other option. However, if it isn't working with the dll files in System32, then you are missing dll files that they depend on in the %PATH% (aka dll-hell ;). > > Regards, Sunny > -- > View this message in context: > http://www.nabble.com/Where-to-Place-.dll-files-in-TOMCAT--tp22766008p22766008.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
Re: tomcat connect 1.2.28 compatability
Yes, it is backwards compatible with all TC versions as far back as 3.3.x. "Eddie Yee" wrote in message news:blu149-w24ea136d1830a46009d015de...@phx.gbl... Hi I'm running Tomcat 5.5.25 (eventually I'll be upgrading to the latest, but due to my development team, I won't be able to quickly). I was wondering if the new 1.2.28 is backwards compatible with Tomcat 5.5.25. I'd really like to use some of the new features before upgrading to the newer Tomcat. Thanks, Eddie _ Quick access to Windows Live and your favorite MSN content with Internet Explorer 8. http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=B037MSN55C0701A - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SEVERE: BAD packet singnature 18245
"Saju K K" wrote in message news:22656151.p...@talk.nabble.com... > > On configuring nio/ajp I am getting and error org.apache.common.MsgApj > p= > rocessHeader " SEVER: BAD packet singnature 18245" > > We are using jdk 1.5.0_14/ apache-tomcat-6.0.18 / redhat linux 2.6.9 . > I have tried configuring the following one at a time and it is working > fine= > . In order to have a high performance proxy we want to configure both > nio/= > ajp and http/ajp together in tomcat and make it listen to apache http > serve= > r on 8080. > > > Tomcat server.xml > > mi= > nProcessors=3D"5" maxProcessors=3D"100" protocol=3D"HTTP/1.1" > redirectPort= > =3D"8443" /> protocol=3D"org.apache.coyote.= http11.Http11NioProtocol" > connectionTimeout=3D"2" redirectPort=3D"8343= " /> redirectPort=3D"8943" /> redirectPort=3D"8643" channelNioSocket.soT= imeout=3D"60" > protocol=3D"AJP/1.3" port=3D"0" channelNioSocket.port=3D"= 8084" > channelNioSocket.maxThreads=3D"150" channelNioSocket.maxSpareThreads= > =3D"50" channelNioSocket.minSpareThreads=3D"25" > channelNioSocket.bufferSize= > =3D"16384"/> > Going to have to agree with André here. You have extra spaces in both the address and port attributes, which should prevent the NIO/AJP connector from starting at all. But it seems that it is starting. It looks like you are using mod_proxy_ajp instead of mod_jk. If this is the case, then the worker.properties file won't be read. Note that the NIO/AJP connector is currently considered "experimental" by the TC developers, since it hasn't had the amount of testing that the other connectors have. That is why there is no offical documentation for it. If, despite the above warning, you want to continue using it, then set the logging level for the category org.apache.jk to FINE, and post the results here. I'll be more than happy to look into it if I have a test case. > worker.properties > > worker.list=3Dworker1,worker2,worker3 > workers.tomcat_home=3D/opt/www/tomcat-6.0/apache-tomcat-6.0.18 > workers.java_home=3D/root/softwares/jdk1.5.0_14 > ps=3D/ > # Define Node1 > # modifies the host as your host IP or DNS name. > > worker.worker1.port=3D8083 > worker.worker1.host=3Dserdev41 > worker.worker1.type=3Dajp13 > worker.worker1.lbfactor=3D1 > worker.worker1.connection_pool_size=3D150 > worker.worker1.connection_pool_timeout=3D600 > worker.worker1.socket_keepalive=3D1 > > worker.worker2.port=3D8080 > worker.worker2.host=3Dserdev41 > worker.worker2.type=3Dajp13 > worker.worker2.lbfactor=3D2 > worker.worker2.connection_pool_size=3D150 > worker.worker2.connection_pool_timeout=3D600 > worker.worker2.socket_keepalive=3D1 > > worker.worker3.port=3D8084 > worker.worker3.host=3Dserdev41 > worker.worker3.type=3Dajp13 > worker.worker3.lbfactor=3D3 > worker.worker3.connection_pool_size=3D150 > worker.worker3.connection_pool_timeout=3D600 > worker.worker3.socket_keepalive=3D1 > > mod_jk.conf > > LoadModule jk_module modules/mod_jk.so > JkWorkersFile conf/workers.properties > JkLogFile logs/mod_jk.log > JkLogLevel info > JkLogStampFormat "[%a %b %d %H: %M: %S %Y]" > JkRequestLogFormat "%w %V %T" > JkMount /* worker3 > > > Httpd.conf > >ProxyRequests off > >Order deny,allow >Allow from all > >ProxyPreserveHost On >ProxyPass/proxy ajp://serdev41:8084 >ProxyPassReverse /proxy ajp://serdev41:8084 > > Include conf/mod_jk.conf > LoadModule proxy_module modules/mod_proxy.so > LoadModule proxy_http_modulemodules/mod_proxy_http.so > > > On making a request I am getting we are getting the above mentioned error > = > ,what could be the problem for this > > Thanks in advance > > -- > View this message in context: > http://www.nabble.com/SEVERE%3A--BAD-packet-singnature-18245-tp22656151p22656151.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
Re: Cofiguring tomcat for trial certificate by trusted authorities like verisign not working.
"Bhuvanesh Pattanashetti" wrote in message news:bce69da80903122202i384a040cj66e5089fc14f6...@mail.gmail.com... > HI All,thanks all for your suggestions. :-) > > Here are following some more details. > > I m using > > - tomcat 6.0, > - JDK 1.6, > - no i m not using keystore. > - I m running on Xp with Spring-DM framework. > connector is as follows. > >port="8443" minSpareThreads="5" maxSpareThreads="75" > enableLookups="true" disableUploadTimeout="true" > acceptCount="100" maxThreads="200" > scheme="https" secure="true" SSLEnabled="true" > keyAlias="aliasName" > keystoreFile="KEeySrotePath" keystorePass="password" > clientAuth="false" sslProtocol="TLS"/> > ^ If you remove the keyAlias from | it will probably just work. > I have generated the keystore using keytool. > Please suggest me further. > > > > > > On Fri, Mar 13, 2009 at 7:51 AM, Bill Barker wrote: > >> Willing to try and play psychic ;). >> >> Procedure 1 is what you want. But the keystore must be the same one that >> you used to create the CSR you sent to Verisign. This is by far the >> second >> most common mistake that people make when setting up Tomcat to use SSL. >> As >> Chuck suggested, check if you are using APR (the SSL configuration >> options >> are different, and APR can't use a JKS keystore). This is the most >> common >> mistake. Verisign has an intermediate cert as well. You'll likely need >> to >> import that as well. And of course, import the Verisign root cert. >> >> >> "Bhuvanesh Pattanashetti" wrote in message >> news:bce69da80903120948v7c2f1693md9db7e74e6e3f...@mail.gmail.com... >> > Hi all, >> > I m trying to set up the SSL for tomcat server. I wanted to know what >> > exactly is the procedure. >> > here is what i have followed. >> > >> > Procedure 1. >> > >> > 1. Created my own keystore. >> > 2. Imported the trial certificate (provided by Verisign ) into the >> > keystore. >> > 3. Added a ssl connector component in to the conf/server.xml into >> tomcat >> > configuration file. >> > 4. Started the Server, When tried accessing connector port from >> browser, >> > I got cannot display the webpage. >> > 5. >> > >> > procedure 2 : >> > >> > 1. Created my own keystore. >> > 2. Imported the trial certificate (provided by Verisign ) into the >> > keystore. >> > 3. Imported the trial certificate (provided by Verisign ) into the >> > cacerts from jre/lib/security/cacerts. >> > 4. Added a ssl connector component in to the conf/server.xml into >> tomcat >> > configuration file mentioning keyAlias pointing to imported >> > certificate >> > alias. >> > 5. Started the Server, at start up i got the folliwing exception >> > >> > java.io.IOException: Alias name mykeyalias does not identify a key >> entry >> > >> > I had importing the root certificate or intrmediate certificate first >> > before >> > importing trial verisign certificate suggested by tomcat. >> > But none of the things are working :-( please suggest me. >> > thanks in advance. >> > Bhuvan P >> > >> >> >> >> >> - >> 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: Cofiguring tomcat for trial certificate by trusted authorities like verisign not working.
Willing to try and play psychic ;). Procedure 1 is what you want. But the keystore must be the same one that you used to create the CSR you sent to Verisign. This is by far the second most common mistake that people make when setting up Tomcat to use SSL. As Chuck suggested, check if you are using APR (the SSL configuration options are different, and APR can't use a JKS keystore). This is the most common mistake. Verisign has an intermediate cert as well. You'll likely need to import that as well. And of course, import the Verisign root cert. "Bhuvanesh Pattanashetti" wrote in message news:bce69da80903120948v7c2f1693md9db7e74e6e3f...@mail.gmail.com... > Hi all, > I m trying to set up the SSL for tomcat server. I wanted to know what > exactly is the procedure. > here is what i have followed. > > Procedure 1. > > 1. Created my own keystore. > 2. Imported the trial certificate (provided by Verisign ) into the > keystore. > 3. Added a ssl connector component in to the conf/server.xml into tomcat > configuration file. > 4. Started the Server, When tried accessing connector port from browser, > I got cannot display the webpage. > 5. > > procedure 2 : > > 1. Created my own keystore. > 2. Imported the trial certificate (provided by Verisign ) into the > keystore. > 3. Imported the trial certificate (provided by Verisign ) into the > cacerts from jre/lib/security/cacerts. > 4. Added a ssl connector component in to the conf/server.xml into tomcat > configuration file mentioning keyAlias pointing to imported certificate > alias. > 5. Started the Server, at start up i got the folliwing exception > > java.io.IOException: Alias name mykeyalias does not identify a key entry > > I had importing the root certificate or intrmediate certificate first > before > importing trial verisign certificate suggested by tomcat. > But none of the things are working :-( please suggest me. > thanks in advance. > Bhuvan P > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem using chunked encoding - request thread cleanup
"Santosh Gangadhar" wrote in message news:6a0454270903060913x1e8a7914qbf9de52744236...@mail.gmail.com... > On Fri, Mar 6, 2009 at 8:50 PM, Caldarale, Charles R < > chuck.caldar...@unisys.com> wrote: > >> > From: Santosh Gangadhar [mailto:sant...@wirkle.com] >> > Subject: Re: Problem using chunked encoding - request thread cleanup >> > >> > But the client keeps running because Tomcat as such does >> > not close the stream. >> >> Perhaps I'm missing something, but why would Tomcat ever close the >> chunked-encoding input stream? Isn't it the responsibility of the client >> to >> indicate there's no more data and close the stream? >> >> - 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 >> >> The client is pushing an mjpeg stream to a servlet on the server. Its >> upto > the server when to stop pushing the stream. The client cannot indicate > when > to end the stream. May be HTTP is not being used aptly here. But still, is > there a way for the servlet to end the stream. ServletInputStream.close() > does not help either. > Thanks, > Santosh. > No currently released version of Tomcat does what you want. But the upcoming 6.0.19 release will if the Servlet sends back a status code that will cause it to close the connection to the client (e.g. HttpServletResponse.SC_REQUEST_ENTITY_TOO_LARGE), or throws an Exception that isn't handled by an error page. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Unix daemon fails to compile
"Rusty Wright" wrote in message news:49aece04.8040...@gmail.com... > jsvc is part of Apache Commons isn't it? Have you tried their mailing > list? > > http://commons.apache.org/daemon/mail-lists.html > Won't be much of a help, since the committers that work on jsvc hang out here as well. > > Jeffrey Trimble wrote: >> I'm running an IBM POWER server, AIX 5.3 and having the following error >> appear when configuring >> jsvc. >> >> checking for gcc option to accept ISO C89... none needed >> checking for ranlib... ranlib >> *** Host support *** >> checking C flags dependant on host system type... failed >> configure: error: Unsupported operating system "aix5.3.0.0" >> >> So, is there a switch that I need to enter to make it configure >> correctly? I've never had >> to set CFLAGS before, so any assistance would be nice. >> To get this up and running, you need to modify src/native/unix/support/apsupport.m4 to include aix*). Then from src/native/unix run the command: $ support/buildconf.sh to regenerate the configure file (requires that autoconf is installed). If you get it working, then please open an issue at https://issues.apache.org/jira for commons-daemon, and attach a patch. The other *nix should give you an idea of what needs to be set. I don't have access to an aix box, so can't be of more help than this. It's possible that one of the other developers does, in which case I'm guessing that they will chime in. >> TIA, >> >> >> Jeffrey Trimble >> System LIbrarian >> William F. Maag Library >> Youngstown State University >> 330.941.2483 (Office) >> jtrim...@cc.ysu.edu >> http://www.maag.ysu.edu >> http://digital.maag.ysu.edu >> >> >> >> >> - >> 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: Getting the tomcat server IP
"Natalie Forood" wrote in message news:206003.52131...@web35302.mail.mud.yahoo.com... > Hello, > > Can you tell me how I can get the IP address of the interface that is > running Tomcat? I can't use localhost, I need the IP of the physical > interface. > request.getLocalAddr() returns the IP address that the request was recieved on. Note that if you are using AJP/1.3 than this is the IP address that Apache recieved the request on. > Thanks, > Natalie - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WEB-INF/classes vs WEB-INF/lib/classes.jar file
"André Warnier" wrote in message news:498ad66a.4080...@ice-sa.com... > Mikolaj Rydzewski wrote: >> André Warnier wrote: >>> if I have a webapp consistig of just a couple of classes and a >>> WEB-INF/web.xml config file, but this web.xml file contains some >>> parameters that are "each-client-dependent", and some customers are >>> insisting to receive the updates as a war file, how can I achieve that ? >>> >>> Someone earlier here mentioned that you could put the settings in a file >>> outside the application, but that is not possible in this case, or is it >>> ? >> You can have web.xml parameter, e.g. >> >> >>config-file-location >>/filesystem/path or URL or >> some-other-location >> >> >> And then you can retrieve parameter value, thus, read config file. >> Idea is, that param-value is the same for every client/build. E.g. points >> to configuration file in $CATALINA_HOME/conf. So you can have one war >> file and client dependant configurations. >> >> > Ok, that would work if you wrote the webapp yourself, and all the filters > that go with it. It would however not work if there are some > customer-specific parameters in web.xml, that are outside of your control. > (I'm thinking for example of a UrlRewrite or jCIFS filter) > > Would there be a way to create a war file that does not contain a > WEB-INF/web.xml file, but maybe contains a "soft link" to a whole web.xml > file located somewhere else ? > > The basic idea is : I could still give my customer a war-file that he can > deploy containing my updated classes of jars or whatever, but it would not > overwrite his customer-specific web.xml when he deploys it. > > I think this issue is so general/generic that there must exist some way, > no ? This is totally Tomcat specific, so won't necessarily port if you decide to change containers (but without looking probably still works for GlassFish and JBoss). Tomcat does Ant style variable replacement when parsing web.xml (both the one in conf and the one in WEB-INF). So something like config-file-location ${my.config.file.location} will work if the System property my.config.file.location is set by the startup script/Windows service manager. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WEB-INF/classes vs WEB-INF/lib/classes.jar file
ignoring the maven fanatics, Tomcat's classloader searches the WEB-INF/classes directory before the WEB-INF/lib/*.jar. This means that it is sometimes nice to use WEB-INF/classes for a development server. But for a production server you won't see much difference. wrote in message news:blu145-w4482e2db3f2697c2cf7c5dc3...@phx.gbl... Is there any advantage why I should not just jar all my class files and put them in WEB-INF/lib rather than exploding the jar file to the classes directory? I like developing with the classes and I understand it is nice to let tomcat deploy a .war file but it also creates some problems for me because i deploy to multiple production servers with different settings that get overwritten every time my war file is expanded. _ Windows Live: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_022009 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jsvc error with tomcat and java 1.6 on os x
There are some recent fixes to jsvc on OS/X in the commons SVN repository, but they haven't been released yet. You could try those and see if it helps. There is more info from the commons developer's list archive at http://markmail.org/message/z7klsse5tylcv5es. "Adam Dajka" wrote in message news:319cb12e-01f5-49c1-ac99-e67b8cb0d...@adverticum.com... > Dear List! > > I have an issue with both tomcat5 and tomcat6 on os x leopard when trying > to use java 1.6. > > When I set JAVA_JVM_VERSION=1.6 in setenv.sh starting tomcat fails. > > I get the error message from jsvc into catalina.err: > 14/01/2009 13:06:42 1465 jsvc error: Cannot dynamically link to / > System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/../ > Libraries/libclient.dylib > 14/01/2009 13:06:42 1465 jsvc error: no additional message > 14/01/2009 13:06:42 1464 jsvc error: Service exit with a return value of > 1 > > jsvc debug says: > Starting Tomcat...19/01/2009 15:45:11 69429 jsvc debug: +-- DUMPING > PARSED COMMAND LINE ARGUMENTS -- > 19/01/2009 15:45:11 69429 jsvc debug: | Detach: True > 19/01/2009 15:45:11 69429 jsvc debug: | Show Version:No > 19/01/2009 15:45:11 69429 jsvc debug: | Show Help: No > 19/01/2009 15:45:11 69429 jsvc debug: | Check Only: Disabled > 19/01/2009 15:45:11 69429 jsvc debug: | Stop:False > 19/01/2009 15:45:11 69429 jsvc debug: | Wait:0 > 19/01/2009 15:45:11 69429 jsvc debug: | Run as service: No > 19/01/2009 15:45:11 69429 jsvc debug: | Install service: No > 19/01/2009 15:45:11 69429 jsvc debug: | Remove service: No > 19/01/2009 15:45:11 69429 jsvc debug: | JVM Name:"null" > 19/01/2009 15:45:11 69429 jsvc debug: | Java Home: "/System/ > Library/Frameworks/JavaVM.framework/Versions/1.6/Home" > 19/01/2009 15:45:11 69429 jsvc debug: | PID File:"/opt/local/ > share/java/tomcat6/logs/tomcat5.pid" > 19/01/2009 15:45:11 69429 jsvc debug: | User Name: "www" > 19/01/2009 15:45:11 69429 jsvc debug: | Extra Options: 7 > 19/01/2009 15:45:11 69429 jsvc debug: | "-verbose" > 19/01/2009 15:45:11 69429 jsvc debug: | "- > Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager" > 19/01/2009 15:45:11 69429 jsvc debug: | "-Djava.class.path=:/opt/ > local/share/java/tomcat6/bin/bootstrap.jar:/opt/local/share/java/ > tomcat6/bin/commons-logging-api.jar" > 19/01/2009 15:45:11 69429 jsvc debug: | "-Dcatalina.home=/opt/local/ > share/java/tomcat6" > 19/01/2009 15:45:11 69429 jsvc debug: | "-Dcatalina.base=/opt/local/ > share/java/tomcat6" > 19/01/2009 15:45:11 69429 jsvc debug: | "-Djava.io.tmpdir=/opt/local/ > share/java/tomcat6/temp" > 19/01/2009 15:45:11 69429 jsvc debug: | "-Djava.endorsed.dirs=/opt/ > local/share/java/tomcat6/endorsed" > 19/01/2009 15:45:11 69429 jsvc debug: | Class Invoked: > "org.apache.catalina.startup.Bootstrap" > 19/01/2009 15:45:11 69429 jsvc debug: | Class Arguments: 1 > 19/01/2009 15:45:11 69429 jsvc debug: | "start" > 19/01/2009 15:45:11 69429 jsvc debug: > +--- > 19/01/2009 15:45:11 69430 jsvc debug: user changed to 'www' > 19/01/2009 15:45:11 69429 jsvc debug: User 'www' validated > 19/01/2009 15:45:11 69429 jsvc debug: Attempting to locate Java Home in > /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home > 19/01/2009 15:45:11 69429 jsvc debug: Attempting to locate VM > configuration file /System/Library/Frameworks/JavaVM.framework/ > Versions/1.6/Home/jre/lib/jvm.cfg > 19/01/2009 15:45:11 69429 jsvc debug: Attempting to locate VM > configuration file /System/Library/Frameworks/JavaVM.framework/ > Versions/1.6/Home/lib/jvm.cfg > 19/01/2009 15:45:11 69429 jsvc debug: Found VM configuration file at / > System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/lib/jvm.cfg > 19/01/2009 15:45:11 69429 jsvc debug: Found VM client definition in > configuration > 19/01/2009 15:45:11 69429 jsvc debug: Checking library /System/Library/ > Frameworks/JavaVM.framework/Versions/1.6/Home/../Libraries/ > libclient.dylib > 19/01/2009 15:45:11 69429 jsvc debug: Found VM jvm definition in > configuration > 19/01/2009 15:45:11 69429 jsvc debug: Checking library /System/Library/ > Frameworks/JavaVM.framework/Versions/1.6/Home/../Libraries/libjvm.dylib > 19/01/2009 15:45:11 69429 jsvc debug: Found VM hotspot definition in > configuration > 19/01/2009 15:45:11 69429 jsvc debug: Checking library /System/Library/ > Frameworks/JavaVM.framework/Versions/1.6/Home/../Libraries/ > libhotspot.dylib > 19/01/2009 15:45:11 69429 jsvc debug: Found VM server definition in > configuration > 19/01/2009 15:45:11 69429 jsvc debug: Checking library /System/Library/ > Frameworks/JavaVM.framework/Versions/1.6/Home/../Libraries/ > libserver.dylib > 19/01/2009 15:45:11 69429 jsvc debug: Found VM classic definition in > configuration > 19/01/2009 15:45:11 69429 jsvc debug: Checking library /System/Library/ > Frameworks/J
Re: WARNING: Error sending end packet - ajp
"Jim Goodspeed" wrote in message news:84347690901081130k2b5e952agd426dd757e60d...@mail.gmail.com... > Hi, > > I am getting the following WARNING message in my catalina.out file. I am > currently running Apache 2.2.10, Tomcat 6.0.16 and Sun's JDK 1.6.0_07. I > can't tell if this is causing a problem or not. Thanks in advance for the > help. > Other than taking up disc space, it isn't causing a problem. It just means that Apache dropped the connection before Tomcat could send it's message saying that it was ready for another request. The result will be that Tomcat will simply send the thread back to it's pool to wait for another connection. If you upgrade your Tomcat version, that message will be logged at DEBUG level (and so shouldn't show up with a production configuration). > > Jan 8, 2009 1:40:10 PM org.apache.jk.core.MsgContext action > WARNING: Error sending end packet > java.net.SocketException: Broken pipe >at java.net.SocketOutputStream.socketWrite0(Native Method) >at > java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) >at java.net.SocketOutputStream.write(SocketOutputStream.java:136) >at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:531) >at > org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:121) >at org.apache.jk.core.MsgContext.action(MsgContext.java:304) >at org.apache.coyote.Response.action(Response.java:183) >at org.apache.coyote.Response.finish(Response.java:305) >at > org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:195) >at > org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) >at > org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) >at > org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) >at > org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) >at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) >at java.lang.Thread.run(Thread.java:619) > > > My AJP configuration is the following in my server.xml file: > > enableLookups="false" redirectPort="8445" debug="0" >maxThreads="200" minSpareThreads="10" maxSpareThreads="25" >acceptCount="100" connectionTimeout="2" > protocol="AJP/1.3" /> > > Apache is load balancing two tomcat servers with the following > configuration: > >ProxyRequests Off >ProxyPreserveHost On > > >Order deny,allow >Allow from all > > >ProxyPass /lexmaint ! > > >BalancerMember ajp://server1:8009 route=app1-a loadfactor=5 >BalancerMember ajp://server2:8009 route=app1-b loadfactor=5 > > > >ProxyPass balancer://app1/ stickysession=JSESSIONID > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Execution of filter before request listener
"Andrew Feller" wrote in message news:c58792ad.5de8%afel...@lsu.edu... > PROBLEM > Tomcat is executing a Filter before the registered ServletRequestListener > > ENVIRONMENT > Tomcat 6.0.18, Windows Vista, JDK 1.6.0_10 > > CONTEXT > We have a filter setup to intercept forwards. When an unauthenticated user > comes in, Tomcat forwards them to our login servlet. The filter intercepts > this forward, however the request listener has not been executed. > > EXPECTED BEHAVIOR > It seems like the ServletRequestListener should have been executed prior > to > the filter. Is this a bug or part of the specification? It is a bit of a grey area in the spec, but IMHO it is a bug. When forwarding to the login-page, Tomcat bypasses normal request processing (including calling ServletRequestListeners). I'd go ahead and file a bug report for it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WARNING: processCallbacks status 2
"Jim Goodspeed" wrote in message news:84347690901051317o3824afa1t7de752b2026a1...@mail.gmail.com... >I am seeing the following Warning in my catalina.out log file - it is being > spit out every couple of seconds. It's not causing a problem that I can > see, but I'm curious as to why it is happening. > > Jan 5, 2009 3:27:09 PM org.apache.jk.common.ChannelSocket > processConnection > WARNING: processCallbacks status 2 > > I am using Tomcat 5.5.9, Apache 2.2.10, Java 1.5.0_14 running on RHEL 4. > I > know that my version of Tomcat is old - we have plans to upgrade to the > latest soon (java as well), but for now I am stuck with 5.5.9. > Yeah, this should probably be lowered to DEBUG level logging. It usually happens when Apache drops the connection before Tomcat can send the "I'm ready for the next request" message. As such, it is pretty harmless (other than disk space). After this, Tomcat will just send the Thread back to it's pool to await another connection. > We have two tomcat servers load balanced (config below) > > ProxyRequests Off >ProxyPreserveHost On > > >Order deny,allow >Allow from all > > >ProxyPass /maint ! > > >BalancerMember ajp://server1.domain.com:8009 route=app1-a > loadfactor=5 >BalancerMember ajp://server1.domain.com:8009 route=app1-b > loadfactor=5 > > > >ProxyPass balancer://app1/ stickysession=JSESSIONID > > > > My AJP config from the server.xml file is below: > >enableLookups="false" redirectPort="8468" debug="0" >maxThreads="200" minSpareThreads="10" maxSpareThreads="25" >acceptCount="100" connectionTimeout="2" > protocol="AJP/1.3" /> > > > > As I said, I don't think this is causing a problem other than it is > filling > up my log files, but I'd like to get to the bottom of it. > > > > > Thank you. > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 error
I've confirmed that yes, this is a bug in 5.5.x. Go ahead and enter in a bug report at http://issues.apache.org/bugzilla. I haven't checked on 6.x and 7.x. The problem is that the compiler optimizes out references to o.a.coyote.Constants so the class isn't loaded in trusted code (with the default catalina.policy). As a result of a recent security fix (and ironically only when running with a SecurityManager), the class is loaded now by un-trusted code, resulting in the exception below. To reproduce, simply have a JSP page bigger than 16kb and run with a SecurityManager with the default catalina.policy settings (or possibly modifying for read access to logging.properties only). Then access this page as your first request after starting Tomcat. "zia mohades" wrote in message news:ee00484d0812231256g1185ae42r4b977bb236009...@mail.gmail.com... Hi steve, first before telling what I have done in regards to your previous email, I need to inform about this issue: 1) when I restart the server and try to access the website: http://localhost:8080/ I get this error: *** HTTP Status 500 - -- type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.coyote) java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) java.security.AccessController.checkPermission(AccessController.java:546) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512) sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:273) java.lang.ClassLoader.loadClass(ClassLoader.java:299) java.lang.ClassLoader.loadClass(ClassLoader.java:299) java.lang.ClassLoader.loadClass(ClassLoader.java:251) java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffer.java:452) org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1617) org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:967) org.apache.coyote.Response.action(Response.java:181) org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.java:576) org.apache.coyote.Response.doWrite(Response.java:560) org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:361) org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:323) org.apache.tomcat.util.buf.IntermediateOutputStream.write(C2BConverter.java:236) sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272) sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:276) sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122) java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212) org.apache.tomcat.util.buf.WriteConvertor.flush(C2BConverter.java:185) org.apache.tomcat.util.buf.C2BConverter.flushBuffer(C2BConverter.java:128) org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:536) org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:256) org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:456) org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:143) org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119) org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:326) org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:342) org.apache.jsp.index_jsp._jspService(index_jsp.java:50) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:597) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAsPrivileged(Subject.java:517) org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162)note The full stack trace of the root cause is available in the Apache Tomcat/5.5 logs. *
Re: Acting on threads by socket events.
"uprooter" wrote in message news:21057805.p...@talk.nabble.com... > > Hello. > I'm trying to overcome 2 of tomcat limitations that prevent me from > rolling > my project on it. > The limitations are: > 1. Tomcat can't detect a lost of connection while the server is > processing. Can't be done unless the servlet periodically writes (and flushes) to the OutputStream. > 2. If I want my servlet to halt the processing but and keep the connection > open tomcat will just halt that > thread and not use it for another processing. > This is the Comet API. It is available with TC 6. > How can I implement a supervisor or an observer that can act on tomcat > threads according to socket events ? > > > > -- > View this message in context: > http://www.nabble.com/Acting-on-threads-by-socket-events.-tp21057805p21057805.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
Re: ssl
"Michael Rooz" wrote in message news:3df1c6c00812170307m3252f89p8c58b8373142...@mail.gmail.com... > Hi, > > I've successfully configured Tomcat to use Client Authentication. > Evidently > for Tomcat to reflect updates made to the truststore, it needs to be > restarted. > > How can I get Tomcat to reload its truststore without performing a > restart? > Well, you can stop and start the Connector (e.g. via JMX). But Tomcat will never re-load the truststore while the Connector is running on it's own. Of course, if you are using a dynamic truststore (e.g. card-based), then this shouldn't be a problem. In general, it is very rarely that you need to update the truststore since it just contains the trusted CA certs. Adding a user from a trusted CA doesn't require an update, since the user's cert will be accepted at the SSL layer. > > > If this requires writing a custom connector that would for example > reinitialize the SSLContext, where can I find some documentation that can > be of some help/guidance? > Not sure if this can be done from the APR Connector, but for the Java Connectors you need to create your own SSLImplementation (from o.a.t.u.net) and configure it with sSSImplementation="com.myfirm.mypackage.MySSLImplementation" on the element. There is some information in the archives for this list, but otherwise the Tomcat JavaDocs and/or source code. > > > Thanks, > > -MIke > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 classloading and the Servlet 2.5 API spec
wrote in message news:of14e2cc5d.7f3b739a-on87257520.0059a8c8-87257520.005b2...@blm.gov... > > I'm trying to clarify something about Tomcat 6 compliance to the Servlet > 2.5 spec. The spec (section 9.7.2) says: > > "The container should not allow applications to override or access the > container's implementation classes." > > In Tomcat 5 it looks like this was handled by having separate "common", > "shared" and "server" directories and the catalina.properties file > specified the classloader configuration such that application code > couldn't > get to the "server" classes and jars. In Tomcat 6, everything is rolled > into a single "lib" directory. The catalina.properties file can be > modified > to make things like the older Tomcat versions, but out of the box it looks > to me like an application could get to the catalina jar files. > > Going by a literal reading of the spec, Tomcat 6 is still technically > compliant (the spec says "should not", not "must not") but all the same it > seems a little strange that this was changed, unless there's something I'm > missing. Does Tomcat 6 have some other mechanism in place to make sure > that > applications can't access the container classes and worse, make changes to > the container's data at run time? For a long time, the Tomcat developers realized that since Java provides introspection, there was really no additional protection provided by classloader segregation if you are not using a SecurityManager sandbox. As a result, they simplified the classloader structure by default and left it up to the admin to configure the sandbox as necessary. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting IP address and redirecting
"Flemion Shafeeq" wrote in message news:5.2.1.1.2.2008123217.02090...@hulmail.harvard.edu... > Hi, > We restrict IP addresses to our application using RemoteAddressValve. > But we have a requirement of redirecting the request to a customized html > static page when we get request from such denied IP's. > How do i do this. > Is it possible to customize this class to do this redirection and deploy > it > in the tomcat application? Tomcat is open-source, so it is always possible to customize it any way you like ;). If your webapp never sends a 403 (Forbidden) response (e.g. you don't authenticate users), then you could do it by specifying a custom error-page for the error code 403. If you send a 403 response for other reasons, then it is likely that it will be easier to roll-your-own Filter based on the code from RemoteAddressValve. > Please help. we are using tomcat 5.5 > Thanks > Flemion. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk: Expected behaviour for ajp-pool currentThreadCount
"Michael Echerer" wrote in message news:49426119.3060...@tngtech.com... > Hello, > > I'm currently analysing issues with a quite old Tomcat 5.5.17, mod_jk > 1.2.15 and Apache 2.0.55 loadbalanced setup with 4 Apaches (worker.c) > and 4 Tomcats. > > Questions are: > * Can anyone explain why Apache SYN requests to Tomcat don't get > answered (probably this happens only if maxClients exceeds Tomcat AJP > pool sizes). That is the most likely reason, but there are other possibilities that should show up in your Tomcat logs. > * Shouldn't the AJP thread pool shrink to maxSpareThreads, if idle, or > will threads stay open if Apache ever requested them? > With the default settings, the threads will stay open if Apache ever requested them. With a version this old, you probably want to specify a connectionTimeout="xx" in the element to allow threads to die if they aren't reused in a timely manor. In this case, you probably also want to configure mod_jk to use CPING/CPONG so that it can detect that the thread went away. Of course upgrading Tomcat makes available the APR and (experimental) NIO AJP/1.3 connectors, which allow a huge number of connections without tying up threads. > Currently there are 4 Apaches, 2 with > > StartServers 2 > MaxClients 300 > MinSpareThreads 25 > MaxSpareThreads 75 > ThreadsPerChild 25 > MaxRequestsPerChild 0 > > and 2 more with > > StartServers 2 > MaxClients 200 > MinSpareThreads 25 > MaxSpareThreads 75 > ThreadsPerChild 25 > MaxRequestsPerChild 0 > > that have problems with hung SYN requests when getting near the 4 > Tomcat's default AJP thread pool size of 200. > > Current guess was that it's simply a bad idea to have 2*300+2*200=1000 > maxClients on Apache side and just 4*200=800 AJP threads (if evenly > balanced) on Tomcat side. > With the default settings, yes this is a bad idea ;). You need to have at least as many AJP threads as maxClients+1 in the default case. > So firstly increased Tomcat threads to maxThreads=500 to find some peak. > All other AJP connector settings are default, resp. not defined. > > Meanwhile we log the JMX currentThreadCount for the AJP-Pools and the > thread count only increases. However even after peak hours the > currentThreadCount does not decrease. However would expect to get back > to the maxSpareThreads default of 50 during night time. > See above. The thread count will never go down without specifying a connectionTimeout. > Can anyone explain why the AJP thread count stays high? I saw that one > could configure mod_jk connection_pool_timeout which is not done yet. > Could that be the reason for the thread pool never reducing the thread > count even though the AJP thread pool has a maxSpareThread setting (i.e. > doesn't this have an effect without pool timeout?)? > I've never tried to do this on the mod_jk side, but the archives suggest it doesn't work well. > What could be the reason for SYN requests of the Apache that never get > answered by Tomcat? > That the thread-pool is exhausted is the most common reason. But since the default AJP Connector answers the request on the current thread and spawns another thread to go back and listen for connections there are other reasons (e.g. an OOME when spawning the thread) why it might fail. However it should say in the Tomcat logs what the problem is. > Thanks, > Michael Echerer > > > -- > TNG Technology Consulting GmbH, Betastr. 13a, D-85774 Unterföhring > Geschäftsführer: Henrik Klagges, Gerhard Müller, Christoph Stock > Amtsgericht München, HRB 135082 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org