Re: users Digest 22 Nov 2010 20:46:42 -0000 Issue 10094
Nicholas Sushkin nsush...@openfinance.com 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 Connector ... / for the non-SSL connector. Robedan drobe...@cesco.net 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 jianglei...@gmail.com 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: welcome-file-list welcome-fileindex.jsp/welcome-file /welcome-file-list In the index.jsp, I use the jsp:forward tag to forward the request to a struts action: jsp:forward page=welcome.do/ 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: jianglei...@gmail.com - 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 Host for processing, or default host of the Engine. 2) If useIPVHosts=true, then IP address of request determines Host for processing, providing the IP is provided as the host name, or Alias. If not found, then default host of Engine applies. The actual rule is that Tomcat uses the value of request.getLocalName() to determine the Host. 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 Host 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 chuck.caldar...@unisys.com 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 ch...@christopherschultz.net 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 ch...@christopherschultz.net 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 a...@ice-sa.com 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 andrew.br...@gmail.com 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 chuck.caldar...@unisys.com 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 ch...@christopherschultz.net 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: check number of http connection in tomcat
Caldarale, Charles R chuck.caldar...@unisys.com 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: Access to Tomcat's MBeans
Pid p...@pidster.com 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: 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 wojciech.kedz...@gemalto.com 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: Tomcat threads
Caldarale, Charles R chuck.caldar...@unisys.com 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: Tomcat threads
Caldarale, Charles R chuck.caldar...@unisys.com 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: Updating CRL in Tomcat 6 without taking it down
Praveen Pat epoch.ti...@gmail.com 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: Connector protocol=org.apache.coyote.http11.Http11Protocol port=8443 SSLEnabled=true maxThreads=150 scheme=https secure=true clientAuth=true sslProtocol=TLS keystoreFile=one.mamoi.semdev.com.pkcs12 keystoreType=PKCS12 keystorePass=changeit truststoreFile=server.truststore truststorePass=changeit truststoreType=JKS crlFile=SEMDEV TEST CA.crl / 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: Tomcat Security
ronald.wagen...@quicknet.nl 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: Apache / mod_proxy / Tomcat
André Warnier a...@ice-sa.com 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 Connector / 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: Ajp port in use - tomcat using next available port
Mark Thomas ma...@apache.org 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 Connectors, 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 scott.hamil...@plateau.com 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 ma...@apache.org 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 Connector ... /, and only configure Host .../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 a...@ice-sa.com 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: Logging all traffics to Tomcat servers
Christopher Schultz ch...@christopherschultz.net 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 a...@ice-sa.com 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: Using RemoteAddressValve with an Apache mod_proxy_balancer
André Warnier a...@ice-sa.com 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: 'Parametrizing' context.xml?
Mario Splivalo mario.spliv...@megafon.hr wrote in message
news:4b27994e.5080...@megafon.hr...
Bill Barker wrote:
Mario Splivalo mario.spliv...@megafon.hr 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:
context-param
param-namebaseprefix/param-name
param-value${BPVAL}/param-value
/context-param
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: [OT - question] Limit user sessions in tomcat
Caldarale, Charles R chuck.caldar...@unisys.com 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 mario.spliv...@megafon.hr 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:
context-param
param-namebaseprefix/param-name
param-value${BPVAL}/param-value
/context-param
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 ch...@christopherschultz.net 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 Connector /). 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: !-- Define a server-auth SSL HTTP/1.1 Connector on port 8442 -- Connector port=8442 maxHttpHeaderSize=8192 SSLEnabled=true 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 Connector attributes again. maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true scheme=https secure=true clientAuth=false sslProtocol=TLS / !-- Define a mutual-auth SSL HTTP/1.1 Connector on port 8443 -- Connector port=8443 maxHttpHeaderSize=8192 SSLEnabled=true 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 vletitchev...@teledyne.com 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 rajat_gupt...@infosys.com 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.property. 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 a...@ice-sa.com 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). spec-quote spec=rfc2616 section=5.2 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. /spec-quote - 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 arthur.hu...@innovations.de 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) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1233) at
Re: Tomcat in Embedded mode
ivelin.vel...@gmail.com 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:
Connector protocol=com.myfirm.mypackage.MyHttp11ProtocolHandler ... /
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 ch...@christopherschultz.net 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: Tomcat really need Shutdown port
Mark Thomas ma...@apache.org 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 pid 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: SSL Configuration Question
Christopher Schultz ch...@christopherschultz.net 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: How to set up tomcat and truststore
Luciana Moreira Sa de Souza Signed by - PrivaSphere AG s...@privasphere.com 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 madscient...@microneil.com 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).
Host name=someplace appBase=/home/someplace/webapps
unpackWARs=true autoDeploy=true
xmlValidation=false xmlNamespaceAware=false
Context
path=
docBase=/home/someplace/www.someplace.com
reloadable=true/
NB: Context 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.
snip/
First access after what? Tomcat restart? Webapp restart?
Thought I was clear on that, sorry. First request after restarting tomcat.
snip/
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.
snip/
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 ;).
Best,
_M
Re: Expecting jsp:param - Porting resin jsp pages to tomcat, dreamweaver editable sections / comments
Christopher Schultz ch...@christopherschultz.net 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 ch...@christopherschultz.net 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 jsp:param / in the body of a jsp:include 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 jsp:include does:
Syntax
[...]
jsp:include page=urlSpec flush=true|false
{ jsp:param / }*
/jsp:include
There, no other content appears to be allowed. However, other sections
of the JSP specification are less ambiguous. For instance, section 5.15
(jsp:text) 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 jsp:text 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:
jsp:text
!-- This is a SGML-style comment --
/jsp:text
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:
jsp:text
This is some content ${foo.content 3}
/jsp:text
fails, but haven't tested it.
The error is:
Exception: org.apache.jasper.JasperException: /test.jsp(3,0) 'amp;lt;',
when appears in the body of amp;lt;jsp:textamp;gt;, must be
encapsulated within a CDATA
Stack Trace:
org.apache.jasper.JasperException: /test.jsp(3,0) apos;amp;lt;apos;,
when appears in the body of amp;lt;jsp:textamp;gt;, 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 jsp:include.
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 ch...@christopherschultz.net 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 jsp:param / in the body of a jsp:include 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 a...@ice-sa.com 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 Listener 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: blocked / hanging on call to HandlerRequest.checkRequest
Simon Papillon simon.papil...@gmail.com 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) at java.lang.Thread.run(Thread.java:619) .etc here is a typical reading from the JK
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 miguel.or...@macneillgroup.com 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: Error when starting ASF Tomcat on iSeries
Mark Thomas ma...@apache.org 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 ch...@christopherschultz.net 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
Christopher Schultz ch...@christopherschultz.net 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 ch...@christopherschultz.net 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
muthu.chan...@sectra.se 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 ch...@christopherschultz.net
To:
Tomcat Users List users@tomcat.apache.org
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 ch...@christopherschultz.net 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: 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 a...@startforce.com 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: how to unwrap a Request from RequestFacade
Christopher Schultz ch...@christopherschultz.net 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: query on tomcat connector
Bhuvanesh Pattanashetti bhuva...@gmail.com 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 martin.grot...@javakaffee.de 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 techat...@yahoo.com 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 ? extends Certificate 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)
uma...@comcast.net 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) anpar...@cisco.com 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 ch...@christopherschultz.net 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/somePathInfoamp;withMoreInfo/ Shouldn't that be /index.cfm/somePathInfoamp%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 ch...@christopherschultz.net 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 ygl...@gmail.com 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% jsp:forward page=/FormProcessor jsp:param name=o value=action1 / /jsp:forward 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 jsp:param 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 email_danie...@yahoo.com.br 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 amich...@amichais.net 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 susumu.sai.2...@gmail.com 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 ch...@christopherschultz.net 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: Periodic slow response to initial call to HttpServletRequest.getParameter()
Mark Thomas ma...@apache.org 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: chunked encoding
André Warnier a...@ice-sa.com 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: Tomcat maxThreads Issue
Caldarale, Charles R chuck.caldar...@unisys.com wrote in message news:0aae5ab84b013e45a7b61cb66943c17228fc438...@usea-exch7.na.uis.unisys.com... From: Jones, Keven [mailto:keven.jo...@ncr.com] Subject: RE: Tomcat maxThreads Issue Connector port=8011 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: Problem with overriding the default servlet on tc 6.0.18
Joseph S j...@selectacast.net wrote in message news:4a2da6d6.50...@selectacast.net... I have this in the web.xml of my application: servlet-mapping servlet-name MyServlet /servlet-name url-pattern / /url-pattern /servlet-mapping 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 welcome-file-list before doing Servlet mapping so that the correct servlet is invoked for the welcome file. Incidentally I discovered you can't welcome-file-list by having an empty element, you have to have at least one welcome-file 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): welcome-file-list welcome-fileindex.doesnotexist/welcome-file /welcome-file-list For the benifit of the archives, this of course assumes that you have set replaceWelcomeFiles=true in the Context ... / element. - 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 n0...@yahoo.com 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: Authentication from the browser
Alec Swan alecs...@gmail.com wrote in message news:34abb48b0906021503t158542a5ube612b5ccfad0...@mail.gmail.com... On Tue, Jun 2, 2009 at 2:34 PM, Jonathan Mast jhmast.develo...@gmail.comwrote: 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 alecs...@gmail.com 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 alecs...@gmail.com 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?
johnrock johnpi...@yahoo.com wrote in message news:23787784.p...@talk.nabble.com... Running tomcat 6.0.18 server.xml has the following listener's enabled by default: !--APR library loader. Documentation at /docs/apr.html -- Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / If you are not using APR, than you don't need this (and removing it gets rid of a message at startup). !--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -- Listener className=org.apache.catalina.core.JasperListener / 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. !-- JMX Support for the Tomcat server. Documentation at /docs/non-existent.html -- Listener className=org.apache.catalina.mbeans.ServerLifecycleListener / 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. Listener 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: Apache Portable Runtime ?
Caldarale, Charles R chuck.caldar...@unisys.com 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?
Christopher Schultz ch...@christopherschultz.net 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: Upload stop after 30 minutes: Processing of multipart/form-data request failed. Stream ended unexpectedly
Patrick Herber patrick.her...@ticino.com 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: Connector port=80 protocol=HTTP/1.1 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). IfModule mod_proxy_ajp.c ProxyRequests Off ProxyTimeout 3600 This looks a lot like 30min ;) Location / ProxyPass ajp://localhost:8009/ ProxyPassReverse ajp://localhost:8009/ /Location /IfModule Connector port=8009 protocol=AJP/1.3 connectionTimeout=60 connectionUploadTimeout=360 disableUploadTimeout=true redirectPort=8443 / Or IfModule mod_proxy_http.c ProxyRequests Off ProxyTimeout 3600 Location / ProxyPass http://localhost:8080/ ProxyPassReverse http://localhost:8080/ /Location /IfModule Connector port=8080 protocol=HTTP/1.1 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 d...@inbox.ru 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 julian.d...@cbc.ca 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 dcker...@verizon.net 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 kramasun...@yahoo.com 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 Connector protocol=com.myfirm.mypackage.MyProtocolHandler ... / 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 pjm...@yahoo.com wrote in message
news:402632.36770...@web44811.mail.sp1.yahoo.com...
Hi
I want a parameter such as the following:
Parameter name=companyName value=My Company, Incorporated
override=false/
If you set a system property via -DcompanyName=My Company, Incorporated,
then you can do:
Parameter name=companyName value=${companyName} override=false /
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 techat...@yahoo.com 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-userm=120092922008604w=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 sg...@gmx.net 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 sunny_ajm...@infosys.com 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 eddieyeew...@hotmail.com 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 saju.kandat...@nokia.com 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 Connector port=3D8080 address=3Dserdev41 connectionTimeout=3D5000 mi= nProcessors=3D5 maxProcessors=3D100 protocol=3DHTTP/1.1 redirectPort= =3D8443 / Connector port=3D8081 maxThreads=3D150 protocol=3Dorg.apache.coyote.= http11.Http11NioProtocol connectionTimeout=3D2 redirectPort=3D8343= / !--Connector port=3D8082 protocol=3Dorg.apache.coyote.http11. Http11Ap= rProtocol enableLookups=3Dfalse redirectPort=3D8543 connectionTimeout= =3D2/-- Connector port=3D8083 protocol=3DAJP/1.3 redirectPort=3D8943 / Connector address=3Dserdev41 redirectPort=3D8643 channelNioSocket.soT= imeout=3D60 protocol=3DAJP/1.3 port=3D0 channelNioSocket.port=3D= 8084 channelNioSocket.maxThreads=3D150 channelNioSocket.maxSpareThreads= =3D50 channelNioSocket.minSpareThreads=3D25 channelNioSocket.bufferSize= =3D16384/ 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 IfModule mod_proxy.c ProxyRequests off Proxy * Order deny,allow Allow from all /Proxy ProxyPreserveHost On ProxyPass/proxy ajp://serdev41:8084 ProxyPassReverse /proxy ajp://serdev41:8084 /IfModule 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 bhuva...@gmail.com 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. Connector 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 wbar...@wilshire.com 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 bhuva...@gmail.com 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 bhuva...@gmail.com 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: Getting the tomcat server IP
Natalie Forood nfor...@yahoo.com 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
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. epicwin...@hotmail.com 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: WEB-INF/classes vs WEB-INF/lib/classes.jar file
André Warnier a...@ice-sa.com 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.
context-param
param-nameconfig-file-location/param-name
param-value/filesystem/path or URL or
some-other-location/param-value
/context-param
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
context-param
param-nameconfig-file-location/param-name
param-value${my.config.file.location}/param-value
/context-param
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: 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 ada...@adverticum.com 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/JavaVM.framework/Versions/1.6/Home/../Libraries/ libclassic.dylib 19/01/2009 15:45:11 69429
Re: WARNING: Error sending end packet - ajp
Jim Goodspeed goodspeeds...@gmail.com 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: Connector port=8009 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 Proxy * Order deny,allow Allow from all /Proxy ProxyPass /lexmaint ! Proxy balancer://app1 BalancerMember ajp://server1:8009 route=app1-a loadfactor=5 BalancerMember ajp://server2:8009 route=app1-b loadfactor=5 /Proxy Location / ProxyPass balancer://app1/ stickysession=JSESSIONID /Location - 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 goodspeeds...@gmail.com 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 Proxy * Order deny,allow Allow from all /Proxy ProxyPass /maint ! Proxy balancer://app1 BalancerMember ajp://server1.domain.com:8009 route=app1-a loadfactor=5 BalancerMember ajp://server1.domain.com:8009 route=app1-b loadfactor=5 /Proxy Location / ProxyPass balancer://app1/ stickysession=JSESSIONID /Location My AJP config from the server.xml file is below: Connector port=8009 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: Execution of filter before request listener
Andrew Feller afel...@lsu.edu 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: 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 zia.si...@gmail.com 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: ssl
Michael Rooz michaelr...@gmail.com 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 Connector .../ 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: Acting on threads by socket events.
uprooter uproo...@gmail.com 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: Tomcat 6 classloading and the Servlet 2.5 API spec
peter_f...@blm.gov 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: mod_jk: Expected behaviour for ajp-pool currentThreadCount
Michael Echerer m...@tngtech.com 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 Connector protocol=AJP/1.3 ... / 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
Re: Restricting IP address and redirecting
Flemion Shafeeq flem...@hulmail.harvard.edu 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: Tomcat caching of static resources?
Caldarale, Charles R [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] From: David Smith [mailto:[EMAIL PROTECTED] Subject: Tomcat caching of static resources? is it possible to cache static images and .js files in Tomcat? Think about what you just asked for: how would caching static resources in the server avoid them being downloaded by the browser? It's the browser that must cache the information to avoid the redundant downloads. There are settings in Tomcat that control server-side caching of static resources (i.e. Tomcat serves up an in-memory copy of frequently requested static resources). I really can't recommend this for large .js files on a production server however. If you must do this, check out the Tomcat docs for configuring a Resources .../ element. However, the OP is probably better off enabling the sendfile options on either the NIO or APR Connector. When i look at the browser cache it looks like the browser is downloading all page assets for every call, including some very large .js files. As stated in one of the (correct) responses to the article you referenced: So the first thing is to get control of the cache headers. Without them, the cache can not know what to do. What are you doing to control the headers? What headers are being used for the large .js files? The article is referring to the fact that Tomcat adds cache headers by default to any page protected by a security-constraint to prevent someone else from stealing it from an intermediate proxy. The default settings are extremely aggressive, resulting in regular posts on this list of the form My secured pdf file can't be displayed in IE. If the article applies to the OP, it may just be easier to move the .js files to a non-secured location. If you take the advice in the article, then you are telling Tomcat that the webapp programmer is taking full control of the cache headers, so you are on your own in terms of security. but the solution didn't resolve the problem (especially if deploying via war files) The original author of the article is clearly unfamiliar with Tomcat, caching, and security (e.g., not knowing where a context.xml file goes, and erroneously stating it doesn't work with a .war file). i cant believe there isn't a standard Tomcat configuration for this? For what? Caching static resources on the server end doesn't alter the amount of network traffic generated. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache 5.5 on SSL - errors- ResourceStart GetConfigured
Installing the keystore is almost certainly not what you want to do if you are fronting with Apache. You need to configure Apache to do the SSL using the mod_ssl docs. If (as it seems from the log) you are using AJP/1.3 (aka mod_jk/mod_proxy_ajp), then no additional configuration may be required in server.xml (and probably at most setting the redirectPort on the Connector protocol=AJP/1.3 ... / element). You will need to copy the JkMount etc. statements to the SSL VHost in httpd.conf). Instead, it looks like you created an unused HTTP/1.1 Connector that speaks SSL. Of course, Tomcat won't care about this. Also, Tomcat quietly ignores configuration options that it doesn't understand, so configuring a keystore on the AJP/1.3 Connector will also not trigger an error. The errors below are likely caused by having backup copies of ROOT.xml in $CATALINA_HOME/conf/Catalina/localhost. If so, just change the extension to something other than .xml (e.g. Copy of Root.bak) and the errors should go away. Matt Moreira [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] A previously-working Apache build running non-SSL was switched to receive SSL traffic. The keystore has been installed, and I've modified the server.xml (which may not be correct, but I do not see where the application complains about it). In an order to cut down on some of the log chatter I removed some backup folders, which actually now show up as errors in addition to the ResourceStart and GetConfigured errors. I can add these folders back in, but do not see how the application needs them. Here is the catalina log: Dec 8, 2008 4:39:39 PM org.apache.coyote.http11.Http11AprProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 Dec 8, 2008 4:39:39 PM org.apache.coyote.http11.Http11AprProtocol init INFO: Initializing Coyote HTTP/1.1 on http-443 Dec 8, 2008 4:39:39 PM org.apache.coyote.ajp.AjpAprProtocol init INFO: Initializing Coyote AJP/1.3 on ajp-8009 Dec 8, 2008 4:39:39 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 375 ms Dec 8, 2008 4:39:39 PM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Dec 8, 2008 4:39:39 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.23 Dec 8, 2008 4:39:39 PM org.apache.catalina.core.StandardHost start INFO: XML validation disabled Dec 8, 2008 4:39:39 PM org.apache.catalina.realm.JAASRealm setUseContextClassLoader INFO: Setting useContextClassLoader = false Dec 8, 2008 4:39:39 PM org.apache.catalina.core.StandardContext resourcesStart SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Document base D:\Portal\liferay433\webapps\Copy of ROOT does not exist or is not a readable directory at org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.jav a:141) at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext. java:3855) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4024 ) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.ja va:760) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java: 626) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java :553) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:31 1) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSu pport.java:120) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022) at org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:448) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) Dec 8, 2008 4:39:39 PM org.apache.catalina.core.StandardContext start SEVERE: Error in resourceStart() Dec 8, 2008 4:39:39 PM org.apache.catalina.core.StandardContext start SEVERE: Error getConfigured Dec 8, 2008 4:39:39 PM org.apache.catalina.core.StandardContext start SEVERE: Context [/Copy of ROOT]
