Need help on SSL problem on new server after move from existing server
Hi, After moving to a new server, I am getting the error: SSL received a record that exceeded the maximum permissible length. I installed Tomcat 6.0.29 on a new machine and copied over the webapps folder and the keystore from the old 5.5.23 machine. Then I modified server.xml to include the various contexts from the old server as well as the port 80 and port 443 connectors and also changed the keystore path for the port 443 SSL connector so it was pointing to the keystore. As far as I know, all the SSL configuration on the server is contained within the connector definition, included below: Connector port=443 address=10.171.10.119 debug=4 maxHttpHeaderSize=8192 enableLookups=false tcpNoDelay=true maxThreads=150 minSpareThreads=25 maxSpareThreads=75 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true keystoreFile=/usr/local/java/keystore2010 keystorePass=xx scheme=https secure=true clientAuth=false sslProtocol=TLS / This connector works perfectly with Tomcat 5.5.23. Are there changes need for 6.0.29? Any ideas about what's going on? Thanks, Rob Tanner Linfield College
Re: Need help on SSL problem on new server after move from existing server
That was a simple enough fix. Thank you. ~ Rob On 10/11/11 10:31 AM, Mark Thomas ma...@apache.org wrote: On 11/10/2011 18:23, Rob Tanner wrote: Hi, After moving to a new server, I am getting the error: SSL received a record that exceeded the maximum permissible length. I installed Tomcat 6.0.29 on a new machine and copied over the webapps folder and the keystore from the old 5.5.23 machine. Then I modified server.xml to include the various contexts from the old server as well as the port 80 and port 443 connectors and also changed the keystore path for the port 443 SSL connector so it was pointing to the keystore. As far as I know, all the SSL configuration on the server is contained within the connector definition, included below: Connector port=443 address=10.171.10.119 debug=4 maxHttpHeaderSize=8192 enableLookups=false tcpNoDelay=true maxThreads=150 minSpareThreads=25 maxSpareThreads=75 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true keystoreFile=/usr/local/java/keystore2010 keystorePass=xx scheme=https secure=true clientAuth=false sslProtocol=TLS / This connector works perfectly with Tomcat 5.5.23. Are there changes need for 6.0.29? Yes. Any ideas about what's going on? http://tomcat.apache.org/migration.html#Migrating_from_5.5.x_to_6.0.x 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: Java update from Apple broke Tomcat
Rick, Yep, extraneous jar files that didn't belong there. Don't know why it worked before the upgrade and not after, but the problem was easy enough to fix once it was identified. Everything works now. -- Rob On 11/1/10 3:48 PM, Richard G Curry rgcu...@jcpenney.com wrote: Did you check you classpath? __ _ «€»¥«€»§«€»¥«€»§«€»¥«€»§«€»¥«€»§«€»¥«€»§«€»¥«€»§«€»¥«€»§«€»¥«€»§«€»¥«€» __ _ Rick Curry Common Services - Software Development E2 - 066, MS 5210 972-431-9178 (Voice) 972-585-7585 (Pager) To send a (short) Text Message to my Pager: 9725857...@page.metrocall.com -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Monday, November 01, 2010 5:28 PM To: Tomcat Users List Subject: Re: Java update from Apple broke Tomcat On 01/11/2010 17:55, Rob Tanner wrote: Hi, While I run production on Linux servers, I do my development on my iMac. Last week, I ran the most recent Apple Java upgrade , and now Tomcat (which is a critical part of my development environment) won't start up. I get the error: Nov 1, 2010 8:58:54 AM org.apache.catalina.startup.Bootstrap initClassLoaders SEVERE: Class loader creation threw exception java.lang.NoSuchFieldError: IS_DIR at org.apache.catalina.startup.Bootstrap.createClassLoader(Bootstrap.java:167) at org.apache.catalina.startup.Bootstrap.initClassLoaders(Bootstrap.java:92) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:207) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:391) Other details: java version 1.6.0_22 Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode) Tomcat version: 6.0.18 and 6.0.29 both fail to start, throwing the same exception From the error, it appears that things are missing from the update (or at least one field is). Has anyone else seen this? Is there a known work-around? I updated too. Works just fine for me, on various 6.0.x and 7.0 trunk. p The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient, you are hereby notified that your access is unauthorized, and any review, dissemination, distribution or copying of this message including any attachments is strictly prohibited. If you are not the intended recipient, please contact the sender and delete the material from any computer. - 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
Java update from Apple broke Tomcat
Hi, While I run production on Linux servers, I do my development on my iMac. Last week, I ran the most recent Apple Java upgrade , and now Tomcat (which is a critical part of my development environment) won't start up. I get the error: Nov 1, 2010 8:58:54 AM org.apache.catalina.startup.Bootstrap initClassLoaders SEVERE: Class loader creation threw exception java.lang.NoSuchFieldError: IS_DIR at org.apache.catalina.startup.Bootstrap.createClassLoader(Bootstrap.java:167) at org.apache.catalina.startup.Bootstrap.initClassLoaders(Bootstrap.java:92) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:207) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:391) Other details: java version 1.6.0_22 Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode) Tomcat version: 6.0.18 and 6.0.29 both fail to start, throwing the same exception From the error, it appears that things are missing from the update (or at least one field is). Has anyone else seen this? Is there a known work-around? Thanks, Rob Tanner Linfield College
Re: Java update from Apple broke Tomcat
Chris, Normally, I let Eclipse start and stop Tomcat for me. It only knows about 6.0.18 and that's the only version I have on my workstation until this morning when I downloaded 6.0.29 to see if there was any possibility that I could have corrupted my existing server. I left 6.0.29 with its default configuration. I tried starting both 6.0.18 and 6.0.29 (not at the same time of course) simply via the bin/catalina.sh shell script and both version fail identically with the same IS_DIR exception ~ Rob On 11/1/10 1:20 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob, On 11/1/2010 1:55 PM, Rob Tanner wrote: Nov 1, 2010 8:58:54 AM org.apache.catalina.startup.Bootstrap initClassLoaders SEVERE: Class loader creation threw exception java.lang.NoSuchFieldError: IS_DIR at org.apache.catalina.startup.Bootstrap.createClassLoader(Bootstrap.java:167) You can check the code here: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_29/java/org/apa che/catalina/startup/Bootstrap.java There is only one instance of IS_DIR in that file. IS_DIR is a protected static member of the ClassLoaderFactory class in the same package. An upgrade of only Java should not have caused this error. Are you working with more than one version of Tomcat at the same time by any chance? How do you start Tomcat? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzPISIACgkQ9CaO5/Lv0PBqIwCfbLkz/3vKSz/Dp/SbAp9x0ePB x0oAnR3nMqHn4oAi9AnGYHswuqQg8xMf =X/Cp -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
How Do I do (Can I do) Apache like redirects in Tomcat
Hi, I would like to setup an HTTPS connector in Tomcat (v 5.5.23) that listens on port 28080. That part's easy enough and there is already a certificate installed. Here's the part I'm having trouble with. Whenever a browser send a GET request to that port, I need to return a redirect to an entirely different server (different IP, etc) listening on port 28443. I cannot figure out anyway to do that. Any ideas? Thanks, Rob -- Rob Tanner UNIX Services Manager Linfield College, McMinnville OR
sun-web.xml file in Tomcat
Hi, I need to make my applications function in both Tomcat and Glassfish. In Tomcat the context root is simply the path in the context declaration in server.xml. In Glassfish, the default is the application name. In order to get Glassfish to assign the correct context root I have included a file called sun-web.xml in WEB-INF along with the standard web.xml. My question is: will this file which Tomcat doesn't know anything about cause any problems with Tomcat or will Tomcat simply ignore it? Thanks, Rob - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sun-web.xml file in Tomcat
Thanks!! Christopher Schultz said the following on 10/23/2007 11:59 AM: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob, Rob Tanner wrote: I need to make my applications function in both Tomcat and Glassfish. In Tomcat the context root is simply the path in the context declaration in server.xml. In Glassfish, the default is the application name. In order to get Glassfish to assign the correct context root I have included a file called sun-web.xml in WEB-INF along with the standard web.xml. My question is: will this file which Tomcat doesn't know anything about cause any problems with Tomcat or will Tomcat simply ignore it? Tomcat should ignore this file. I'm guessing that the Glassfish and Tomcat devs both know about each others' app-server-specific config files, and try not to step on each others' toes. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHkSi9CaO5/Lv0PARAhhcAKCAlL60hdMi4qbZ/hQxdOE3JPk3vwCfR+q7 5uoDWxgHrzKV3bDZ40j9szk= =gC/3 -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How do I run Tomcat as a non-root user?
Hi, How do I run Tomcat as a non-root user? I need to be able to bind to ports 80 443 which are privileged ports. I know that with straight Apache the user that it runs as is configured in httpd.conf. It starts up as root, binds to the ports and then drops its privileges. However, I'm running Tomcat as stand-alone. So, is there some mechanism in Tomcat to accomplish the same thing? Thanks, Rob -- Rob Tanner UNIX Services Manager Linfield College, McMinnville OR - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do I run Tomcat as a non-root user?
Marcus, I downloaded it and also applied the patch to eliminate the Cannot execute JSVC executor process error. But here's the catch, and maybe you know the answer. The machine and the OS (Fedora) are 64bit but the Java runtime is 32bit. In order for jsvc to make use of the shared libs, it has to be 32 bit as well. So, I build it like this: CFLAGS=-m32 CPPFLAGS=-m32 CCASFLAGS=-m32 LDFLAGS=-L/usr/lib -L/lib \ ./configure --build=i686-pc-linux-gnu \ But at the end of the make, I get gcc -L/usr/lib -L/lib -ldl -lpthread jsvc-unix.o libservice.a -o ../jsvc /usr/bin/ld: skipping incompatible /usr/lib/libdl.so when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib/libdl.a when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /usr/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc /usr/bin/ld: warning: i386 architecture of input file `jsvc-unix.o' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(arguments.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(debug.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(help.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(home.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(java.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(location.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(replace.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(dso-dlfcn.o)' is incompatible with i386:x86-64 output And I end up with an ELF 64-bit LSB executable that gets an immediate segmentation fault. Any ideas how to build it right. Thanks, Rob Markus Schönhaber said the following on 10/10/2007 09:11 AM: Rob Tanner schrieb: How do I run Tomcat as a non-root user? I need to be able to bind to ports 80 443 which are privileged ports. I know that with straight Apache the user that it runs as is configured in httpd.conf. It starts up as root, binds to the ports and then drops its privileges. However, I'm running Tomcat as stand-alone. So, is there some mechanism in Tomcat to accomplish the same thing? Yes, jsvc[1]. The sources should be in the bin/ directory of your Tomcat installation. Regards mks [1] http://commons.apache.org/daemon/jsvc.html - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do I run Tomcat as a non-root user?
Marcus, I was able to resolve the make by doing the last compile step manually. As far as why a 32 bit JVM or a 64 bit machine, that only applies to my development system (which is my desktop). Our production servers are 32 bit systems. The problem with a 64 bit JVM on my development box is that MyEclipse (unless it's changed and I'm unaware) does not behave dependably in 64 bit. Using 32 bit, my Java development is rock-solid, so why change. -- Rob Markus Schönhaber said the following on 10/10/2007 02:01 PM: Rob Tanner wrote: I downloaded it and also applied the patch to eliminate the Cannot execute JSVC executor process error. Why didn't you use the sources you already had? But here's the catch, and maybe you know the answer. The machine and the OS (Fedora) are 64bit but the Java runtime is 32bit. In order for jsvc to make use of the shared libs, it has to be 32 bit as well. So, I build it like this: [...] And I end up with an ELF 64-bit LSB executable that gets an immediate segmentation fault. Any ideas how to build it right. You could set up a cross-compiler/cross-toolchain that is able to create 32-bit binaries or compile it on a 32-bit machine. Either way, you'll have to install the 32-bit versions of the dependent libraries as well (or create a static binary). But first and foremost: what's the point in running Tomcat in a 32-bit JVM on 64-bit machine? Use a 64-bit JVM and save yourself a lot of trouble. Regards mks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Having security (SSL) issues moving tomcat from one host computer to another
Hi, I'm wondering if any has ever seen this and how did they fix it. I have a production tomcat server (v5.5.23) that I need to move to another host system. I copied over the full installation and made sure I was using the same version of the runtime (jdk1.5.0_03). But when I try to access a secured page on the new host I get the following it fails and I get the following StackTrace in tomcat.log: DEBUG http-10.171.255.17-443-Processor25 org.apache.tomcat.util.net.PoolTcpEndpoint - Handshake failed javax.net.ssl.SSLException: Error generating DH server key exchange at com.sun.net.ssl.internal.ssl.Handshaker.throwSSLException(Handshaker.java:907) at com.sun.net.ssl.internal.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:556) at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:178) at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:815) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1025) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1038) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:120) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:521) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:595) Caused by: java.security.InvalidKeyException: No installed provider supports this key: sun.security.rsa.RSAPrivateCrtKeyImpl at java.security.Signature$Delegate.chooseProvider(Signature.java:1059) at java.security.Signature$Delegate.engineInitSign(Signature.java:1109) at java.security.Signature.initSign(Signature.java:503) at com.sun.net.ssl.internal.ssl.HandshakeMessage$DH_ServerKeyExchange.init(HandshakeMessage.java:671) at com.sun.net.ssl.internal.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:550) ... 11 more Caused by: java.security.NoSuchAlgorithmException: NONEwithRSA Signature not available at java.security.Signature.getInstance(Signature.java:208) at com.sun.net.ssl.internal.ssl.JsseJce.getSignature(JsseJce.java:104) at com.sun.net.ssl.internal.ssl.RSASignature.init(RSASignature.java:45) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:350) at java.lang.Class.newInstance(Class.java:303) at java.security.Provider$Service.newInstance(Provider.java:1075) at java.security.Signature$Delegate.newInstance(Signature.java:941) at java.security.Signature$Delegate.chooseProvider(Signature.java:1035) ... 15 more The JDKs on both the current production host system (which works) and the host I'm moving to are identical (I double checked security.providers in jre/lib/security/java.security) and just in case I screwed up the certificate and went to Thawte and reissued it. The reference above to NONEwithRSA makes no sense to me. The certificate is a PKCS#7 chain and the signature algorithms are SHA1withRSA and MD5withRSA. Where does the NONEwithRSA come from? The only difference between the two hosts machine is the OS. The current production machine is RedHat v9 (just a bit out of date) and the new box is running Fedora Core 7. I don't know whether that's a difference that makes a difference or not, but I thought I would mention it anyway. I've been hitting my head against a wall for two days now, and I need SSL working before I can switch over to the new box. As you can weell imagine, this is driving me crazy. Any ideas? Thanks, Rob -- Rob Tanner UNIX Services Manager Linfield College, McMinnville OR
Tomcat continues to display default home page even after I've replaced it
Hi, I installed Tomcat 5.5.23 stand-alone and then replaced the default index.jsp home page (webapps/ROOT/index.jsp) with a different a different jsp. But, no matter what I do, I still get the default Tomcat home page and not the pager I replaced it with. At first I thought it was my browser caching simply caching the original page. I cleared cache and that made no difference, so I tried wget, a command line utility that knows nothing about caching. I still got the default Tomcat home page. I tried using wget from a different machine -- same results. I could see from doing a ps -ef | grep java that I wasn't running a second Tomcat process and just to make sure that I was actually talking to the server I thought I was talking to, I killed the Tomcat process and tried again. This time I got a Connection refused, meaning that no other server was answering the GET requests. I restarted Tomcat and once again got the original default home page instead of the actual index.jsp that replaced it. Can anyone tell me where this content is coming from? Thanks, Rob smime.p7s Description: S/MIME Cryptographic Signature
Re: Tomcat continues to display default home page even after I've replaced it
Let me wipe the egg off my face and say thanks. -- Rob On 06/17/2007 03:35 PM, Mark Thomas wrote: Rob Tanner wrote: Can anyone tell me where this content is coming from? Try reading the page. The explanation is right there in the middle. To see your new page, remove the mapping. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Problem with Tomcat 5.5.23 when displaying to frames
Hi, This one is weird and makes no sense to me. I am moving from a Tomcat 3.x (front ended by Apache) production environment to apache-tomcat-5.5.23 running standalone. My apps, which are all interactive tools, are displayed in frame-sets containing either one or two frames. Each application has one frame that takes a long time to come up or even possibly times out. The old production system using an apache connector did not have that problem, and my development system, also running 5.5.23 standalone, does not have that problem. The only significant difference between the production and development systems (as far as I'm aware) is that I'm directly on the development system's console (it's my desktop) while the soon to be new production is in the server room. I don't believe that it related to system or networking resources in general as the production system also handles our primary apache web server and that runs lickity split. The log files don't give me a clue of even where to look. Could it be related to the version of Java 5. My development machine is running jdk1.5.0_08 and the production box is running jdk1.5.0_0, but I can't imagine that that's the issue. Also, I'm not specifically setting any run time arguments so both the production and development machines should be running default. Both system are running Linux although the production box is an older version of the OS. Any ideas about what might be the cause of this problem? Thanks, Rob smime.p7s Description: S/MIME Cryptographic Signature
Re: Can't seem to get logging to work in Tomcat 5.5.9
Georg,
Finally kind of solved my problem. First, I went to a fresh install of
5.5.23 and then added the log4j.properties file in
${CATALINA_HOME}/common/classes and the log4j jar file in
${CATALINA_HOME}/common/lib. No go. So, thinking maybe the
documentation was wrong, I moved the properties file to
${CATALINA_HOME}/conf. Again, no go. The I copied it back to
common/classes and therefore unintentionally left a copy in conf. And
suddenly things started working. Of course, log level DEBUG is not
terribly helpful in most cases (too much data) and so I modified the
properties file, switching it to INFO and things broke. Then I
remembered the copy in conf and changed it. What seems to be happening
and makes no logical sense is that so long as I have identical copies of
the log4j.properties file in conf and common/classes, everything works.
I'm sure that somewhere, something is screwed up, but I have no idea
what. Weird!
-- Rob
On 05/31/2007 02:59 PM, Georg Sauer-Limbach wrote:
Hi Rob,
check catalina.out, there should be some message of
log4j complaining if it has been loaded but cannot work.
You may also add -Dlog4.debug to the java command line,
this makes log4j output debug messages on stdout.
If you don't see any output of log4j, then I'd suggest
calling java with -verbose:class, this makes java
print information about every class it loads and from
which source it loaded it. Grep for log4j to see if it
is at all loaded.
Georg
Rob Tanner wrote:
Hi,
I was originally planning to move to Tomcat 6 but backed off for a
number of reasons. Now I have Tomcat 5.5.9 installed an working, except
for logging (and one other problem that I might be able to resolve on my
own if only I could get logging to work).
I have never configured Tomcat to log using log4j (Tomcat 4.x's built-in
was sufficient). Following the instructions on the website
(http://tomcat.apache.org/tomcat-5.5-doc/logging.html), I creating a
log4j.properties file and placed it in common/classes -- the only change
I made on the example on the webpage was to replace a variable with an
absolute path:
log4j.rootLogger=DEBUG, R
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=/var/apache/jakarta-tomcat-5.5.9/logs/tomcat.log
log4j.appender.R.MaxFileSize=10MB
log4j.appender.R.MaxBackupIndex=10
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n
I then put log4j-1.2.7.jar and commons-logging-1.1.jar jarfiles in
common/lib and started Tomcat. The instructions don't say anything about
doing anything else and I've not done very much with log4j other than
use it to enable syslog logging in various applications, but it's not
working.
Any ideas?
Thanks,
Rob
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
Can't seem to get logging to work in Tomcat 5.5.9
Hi, I was originally planning to move to Tomcat 6 but backed off for a number of reasons. Now I have Tomcat 5.5.9 installed an working, except for logging (and one other problem that I might be able to resolve on my own if only I could get logging to work). I have never configured Tomcat to log using log4j (Tomcat 4.x's built-in was sufficient). Following the instructions on the website (http://tomcat.apache.org/tomcat-5.5-doc/logging.html), I creating a log4j.properties file and placed it in common/classes -- the only change I made on the example on the webpage was to replace a variable with an absolute path: log4j.rootLogger=DEBUG, R log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.File=/var/apache/jakarta-tomcat-5.5.9/logs/tomcat.log log4j.appender.R.MaxFileSize=10MB log4j.appender.R.MaxBackupIndex=10 log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n I then put log4j-1.2.7.jar and commons-logging-1.1.jar jarfiles in common/lib and started Tomcat. The instructions don't say anything about doing anything else and I've not done very much with log4j other than use it to enable syslog logging in various applications, but it's not working. Any ideas? Thanks, Rob -- Rob Tanner UNIX Services Manager Linfield College, McMinnville OR smime.p7s Description: S/MIME Cryptographic Signature
Re: Can't seem to get logging to work in Tomcat 5.5.9
Tim, Right now I'm running Tomcat as root so that it can grab ports 80 and 443 (I understand there is a work around for that, but I'm not there yet) and so permissions is not an issue. I also wondered whether the file had to already exist before it could log to it. So I touched the file and that made no difference. Also, I tried removing the tomcat-juli.jar file from $CATALINA_HOME/bin and that made no difference. Just looking at the startup script, I don't think JULI conflicts with log4j -- i.e., it doesn't look like if you use one you can't use the other. -- Rob Tim Lucia said the following on 05/25/2007 03:59 PM: Your configuration file is valid. Does the user Tomcat runs as have write permission along the output path? You could try using /tmp as a test. If it is not permissions, then it could be a classpath issue, but your notes lead me to believe that not to be the case (i.e., you put them where they should be. You may (I'm fuzzy on this) have to rename the tomcat-juli.jar file, or otherwise change the startup script(s) so that it doesn't use the juli logger. HTH, Tim -Original Message- From: Rob Tanner [mailto:[EMAIL PROTECTED] Sent: Friday, May 25, 2007 6:36 PM To: Tomcat Users List Subject: Can't seem to get logging to work in Tomcat 5.5.9 Hi, I was originally planning to move to Tomcat 6 but backed off for a number of reasons. Now I have Tomcat 5.5.9 installed an working, except for logging (and one other problem that I might be able to resolve on my own if only I could get logging to work). I have never configured Tomcat to log using log4j (Tomcat 4.x's built-in was sufficient). Following the instructions on the website (http://tomcat.apache.org/tomcat-5.5-doc/logging.html), I creating a log4j.properties file and placed it in common/classes -- the only change I made on the example on the webpage was to replace a variable with an absolute path: log4j.rootLogger=DEBUG, R log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.File=/var/apache/jakarta-tomcat-5.5.9/logs/tomcat.log log4j.appender.R.MaxFileSize=10MB log4j.appender.R.MaxBackupIndex=10 log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n I then put log4j-1.2.7.jar and commons-logging-1.1.jar jarfiles in common/lib and started Tomcat. The instructions don't say anything about doing anything else and I've not done very much with log4j other than use it to enable syslog logging in various applications, but it's not working. Any ideas? Thanks, Rob -- Rob Tanner UNIX Services Manager Linfield College, McMinnville OR - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Problem deploying existing webapp in new Tomcat container
Since it's your favorite subject... :-)
Following the directions in the context.html doc (the fisrt URL below),
and not changing the default values for engine and host, the first thing
I did was to add the path ${CATALINA_HOME}/conf/Catalina/localhost. I
created one xml file named: mailtools#aliases.xml since the context path
is multi-level (the path is /mailtools/aliases -- I presume that's
what was meant by multi-level in the doc) for the first webapp and
accntManager.xml for the seconf app.
The first app (mailtools#aliases.xml) still continues to fail as below:
SEVERE: Allocate exception for servlet GroupAliasManager
javax.servlet.ServletException: Error instantiating servlet class
GroupAliasManager
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1127)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:806)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:129)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
The second app, that was working properly when I configured it's context
in server.xml now fails to load:
java.lang.IllegalArgumentException: Document base
/var/apache/apache-tomcat-6.0.13/webapps/accntManager does not exist or
is not a readable directory.
The specified docBase is AccountManager not accntManager. The latter is
the context path. Although, when I rename the actual directory
accntManager it works. It clearly misreading something which tells me
that I'm clearly misunderstanding something.
Here are the two files:
Context crossContext=true debug=0
docBase=AccountManager path=/accntManager reloadable=true
Logger className=org.apache.catalina.logger.FileLogger
prefix=localhost_accntmanager_log. suffix=.txt
timestamp=true/
/Context
::
mailtools#aliases.xml
::
Context crossContext=true debug=0
docBase=GroupAliases path=/mailtools/aliases reloadable=true
Logger className=org.apache.catalina.logger.FileLogger
prefix=localhost_aliases_log. suffix=.txt
timestamp=true/
/Context
Thanks,
Rob
Caldarale, Charles R said the following on 05/16/2007 03:19 PM:
From: Rob Tanner [mailto:[EMAIL PROTECTED]
Subject: Re: Problem deploying existing webapp in new Tomcat container
As far as server.xml, how else does one specify the specifics, such as
the path variable?
(Here we go again... my favorite subject :-)
First, read the doc:
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
Note the following extracts from the Introduction and the description of
the path attribute:
For Tomcat 6, unlike Tomcat 4.x, it is NOT recommended to place
Context elements directly in the server.xml file. This is because it
makes modifing the Context configuration more invasive since the main
conf/server.xml file cannot be reloaded without restarting Tomcat.
The value of this field must not be set except when statically defining
a Context in server.xml, as it will be inferred from the filenames used
for either the .xml context file or the docBase.
Nor should you be specifying a docBase. Put the Context elements where
they belong - in META-INF/context.xml of each webapp - and remove the
path and docBase attributes.
Also, reading this part of the doc:
http://tomcat.apache.org/tomcat-6.0-doc/logging.html
would show you that the Logger element is no longer used.
- 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.
--
Rob Tanner
UNIX Services Manager
Linfield College, McMinnville OR
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Problem deploying existing webapp in new Tomcat container
I also found this log, and I assume it's related to the problem:
WARNING: A docBase /var/apache/apache-tomcat-6.0.13/webapps/GroupAliases
inside the host appBase has been specified, and will be ignored
You can see in the dump of mailtools#aliases.xml that indeed I do
specify a docBase. In Tomcat 4 that was correct but now that's wrong??
Makes no sense.
-- Rob
Rob Tanner said the following on 05/17/2007 10:09 AM:
Since it's your favorite subject... :-)
Following the directions in the context.html doc (the fisrt URL
below), and not changing the default values for engine and host, the
first thing I did was to add the path
${CATALINA_HOME}/conf/Catalina/localhost. I created one xml file
named: mailtools#aliases.xml since the context path is multi-level
(the path is /mailtools/aliases -- I presume that's what was meant
by multi-level in the doc) for the first webapp and accntManager.xml
for the seconf app.
The first app (mailtools#aliases.xml) still continues to fail as below:
SEVERE: Allocate exception for servlet GroupAliasManager
javax.servlet.ServletException: Error instantiating servlet class
GroupAliasManager
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1127)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:806)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:129)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
The second app, that was working properly when I configured it's
context in server.xml now fails to load:
java.lang.IllegalArgumentException: Document base
/var/apache/apache-tomcat-6.0.13/webapps/accntManager does not exist
or is not a readable directory.
The specified docBase is AccountManager not accntManager. The latter
is the context path. Although, when I rename the actual directory
accntManager it works. It clearly misreading something which tells
me that I'm clearly misunderstanding something.
Here are the two files:
Context crossContext=true debug=0
docBase=AccountManager path=/accntManager reloadable=true
Logger className=org.apache.catalina.logger.FileLogger
prefix=localhost_accntmanager_log. suffix=.txt
timestamp=true/
/Context
::
mailtools#aliases.xml
::
Context crossContext=true debug=0
docBase=GroupAliases path=/mailtools/aliases reloadable=true
Logger className=org.apache.catalina.logger.FileLogger
prefix=localhost_aliases_log. suffix=.txt
timestamp=true/
/Context
Thanks,
Rob
Caldarale, Charles R said the following on 05/16/2007 03:19 PM:
From: Rob Tanner [mailto:[EMAIL PROTECTED]
Subject: Re: Problem deploying existing webapp in new Tomcat container
As far as server.xml, how else does one specify the specifics, such as
the path variable?
(Here we go again... my favorite subject :-)
First, read the doc:
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
Note the following extracts from the Introduction and the description of
the path attribute:
For Tomcat 6, unlike Tomcat 4.x, it is NOT recommended to place
Context elements directly in the server.xml file. This is because it
makes modifing the Context configuration more invasive since the main
conf/server.xml file cannot be reloaded without restarting Tomcat.
The value of this field must not be set except when statically defining
a Context in server.xml, as it will be inferred from the filenames used
for either the .xml context file or the docBase.
Nor should you be specifying a docBase. Put the Context elements where
they belong - in META-INF/context.xml of each webapp - and remove the
path and docBase attributes.
Also, reading this part of the doc:
http://tomcat.apache.org/tomcat-6.0-doc/logging.html
would show you that the Logger element is no longer used.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
Problem deploying existing webapp in new Tomcat container
Hi, I am in the process of upgrading my Tomcat environment. On a new server I installed Sun Java jdk1.6.0 and apache-tomcat-6.0.13. I copied over the server.xml config for the first web aplication as well as the JAR file and everything worked fine. When I did the same for the second application, this is the entire error message. Problem is that it doesn't give me the slightest clue as to the cause of the problem, or why the one app works and this one doesn't. May 16, 2007 1:58:45 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Allocate exception for servlet GroupAliasManager javax.servlet.ServletException: Error instantiating servlet class GroupAliasManager at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1127) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:806) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:129) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) Any ideas? Thanks, Rob -- Rob Tanner UNIX Services Manager Linfield College, McMinnville OR smime.p7s Description: S/MIME Cryptographic Signature
Re: Problem deploying existing webapp in new Tomcat container
I meant WAR file not JAR. As far as server.xml, how else does one specify the specifics, such as the path variable? Here are the two application contexts: Context crossContext=true debug=0 docBase=AccountManager path=/accntManager reloadable=true Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_accntmanager_log. suffix=.txt timestamp=true/ /Context Context crossContext=true debug=0 docBase=GroupAliases path=/mailtools/aliases reloadable=true Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_aliases_log. suffix=.txt timestamp=true/ /Context The AccountManager app works fine, but the GroupAliases generates this error: May 16, 2007 3:04:06 PM org.apache.catalina.core.ApplicationContext log INFO: Marking servlet GroupAliasManager as unavailable May 16, 2007 3:04:06 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Allocate exception for servlet GroupAliasManager javax.servlet.ServletException: Error instantiating servlet class GroupAliasManager at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1127) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:806) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:129) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) -- Rob Caldarale, Charles R said the following on 05/16/2007 02:32 PM: From: Rob Tanner [mailto:[EMAIL PROTECTED] Subject: Problem deploying existing webapp in new Tomcat container I installed Sun Java jdk1.6.0 and apache-tomcat-6.0.13. I copied over the server.xml config for the first web aplication as well as the JAR file and everything worked fine. That sounds a bit scary, since webapps are not supposed to be configured in server.xml anymore, and they should be packaged in .war files, not JARs. You need to at least post your config, since that's likely where the problem is. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Running stand-alone Tomcat and Apache on the same server, port 80
Hi, In Apache, you can run multiple servers (and virtual servers) all listening on port 80 by having multiple IP addresses. I would like to do the same thing except I want to run Tomcat and Apache on the same physical machine, both listening on port 80. I've been through the documentation on server.xml, and while I can specify specific ports, I do not see any mechanism to specify which of the machine's several IPs it should listen on. Can I do that, and if so, how do I do that? Thanks, Rob -- Rob Tanner UNIX Services Manager Linfield College, McMinnville OR smime.p7s Description: S/MIME Cryptographic Signature
Re: Running stand-alone Tomcat and Apache on the same server, port 80
Thanks! The problem with the documentation (for me at least) is that sometimes you already have to know what your looking for to find it in the docs. So now I do. Thank you. -- Rob Caldarale, Charles R said the following on 05/15/2007 11:21 AM: From: Rob Tanner [mailto:[EMAIL PROTECTED] Subject: Running stand-alone Tomcat and Apache on the same server, port 80 I've been through the documentation on server.xml, and while I can specify specific ports, I do not see any mechanism to specify which of the machine's several IPs it should listen on. Look at the address attribute of the Connector element. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: How do I force redirects from http: to https:
Chuck, Thanks! Redirects are now working. -- Rob Caldarale, Charles R said the following on 05/01/2007 10:44 AM: From: Rob Tanner [mailto:[EMAIL PROTECTED] Subject: How do I force redirects from http: to https: I have a redirectPort=443 argument in the port 80 connector description in server.xml, but that doesn't seem to be doing anything. It won't until you specify a security constraint for the webapps (or portions thereof) that need to be protected. You need to become familiar with the servlet spec, especially section 12. You can find the spec here: http://jcp.org/aboutJava/communityprocess/mrel/jsr154/index.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Can't get apache and Tomcat to talk
I'm running a new install Fedora Core 5 and rebuilding my development system. I'm running Apache/2.2.2 (part of the FC5 distro) and Tomcat-4.1.32. I downloaded the version 1.2.18 tomcat connector kit and followed the instructions in BUILD.txt to compile and install the mod_jk.so connector. I installed one of my development apps and added the context configuration to the server.xml file, and when I try to get to it through apache, the cursor just spins and I get no log entries of any kind, neither in the apache logs nor the tomcat logs. I can, however, point my browser to port 8009 and bring up the newly installed app.All the gory details are below. Other than maybe that's the wrong connector, any idea what might be wrong? In the server.xml file, the only change I have made from the distribution is to add this context: Context crossContext=true debug=0 docBase=AccountManager path=/accntManager reloadable=true Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_accntmanager_log. suffix=.txt timestamp=true/ Parameter name=UniAccnt value=/datatel/development/coldev17 override=false/ Parameter name=AdminAddresses value=[EMAIL PROTECTED] override=false/ /Context I also created this workers.properties file in the tomcat conf directory: workers.tomcat_home=/var/apache-tomcat-4.1.32 workers.java_home=/usr/java/j2sdk1.4.2_12 ps=/ worker.list=ajp13 worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOST] Can't get apache and Tomcat to talk
(Grrr! I hit send when I meant save -- the first posting is incomplete) I'm running a new install Fedora Core 5 and rebuilding my development system. I'm running Apache/2.2.2 (part of the FC5 distro) and Tomcat-4.1.32. I downloaded the version 1.2.18 tomcat connector kit and followed the instructions in BUILD.txt to compile and install the mod_jk.so connector. I installed one of my development apps and added the context configuration to the server.xml file, and when I try to get to it through apache, the cursor just spins and I get no log entries of any kind, neither in the apache logs nor the tomcat logs. I can, however, point my browser to port 8009 and bring up the newly installed app.All the gory details are below. Any idea what might be wrong? In the server.xml file, the only change I have made from the distribution is to add this context: Context crossContext=true debug=0 docBase=AccountManager path=/accntManager reloadable=true Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_accntmanager_log. suffix=.txt timestamp=true/ Parameter name=UniAccnt value=/datatel/development/coldev17 override=false/ Parameter name=AdminAddresses value=[EMAIL PROTECTED] override=false/ /Context I also created this workers.properties file in the tomcat conf directory: workers.tomcat_home=/var/apache-tomcat-4.1.32 workers.java_home=/usr/java/j2sdk1.4.2_12 ps=/ worker.list=ajp13 worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 And finally, the following configuration detail was added to apache's httpd.conf file. Tomcat and apache were than both restarted. LoadModule jk_module modules/mod_jk.so JkWorkersFile /var/apache-tomcat-4.1.32/conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevel info JkMount /*.jsp ajp13 JkMount /accntManager/* ajp13 Any suggestions here would be greatly appreciated. Thanks, Rob Tanner Linfield College - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [REPOST] Can't get apache and Tomcat to talk
Brian, Adding the Listener ... / parameter you suggest generates a java.lang.ClassNotFoundException: org.apache.jk.config.ApacheConfig. Where should I find the jarfile containing that class? It's new to me and I know I'm not using that listener in my install of Tomcat-4.1.31 on another machine. And when I modify the AJP/1.3 connector to include the line: protocol=AJP/1.3. I presume the two errors are related. Is this something new in 4.1.32? Thanks, Rob brian bay wrote: Do you have a Listener set up in your tomcat server.xml? Inside of EngineHost Listener className=org.apache.jk.config.ApacheConfig modJk=/usr/lib/apache2/modules/mod_jk.so workersConfig=/etc/apache2/workers.properties/ I placed my workers.properties file in the apache dir. Inside of Service Connector port=8080 redirectPort=8443 minSpareThreads=25 connectionTimeout=2 maxSpareThreads=75 maxThreads=125 /Connector Connector port=8009 redirectPort=8443 connectionTimeout=-1 protocol=AJP/1.3 /Connector I assume you have installed mod_jk.so to the modules dir? - Brian On 9/15/06, Martin Gainty [EMAIL PROTECTED] wrote: # Defines a worker named remote that uses the ajpv13 protocol to forward requests to a Tomcat process in workers.properties worker.remote.type=ajp13 worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 * This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: Rob Tanner [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, September 15, 2006 2:33 PM Subject: [REPOST] Can't get apache and Tomcat to talk (Grrr! I hit send when I meant save -- the first posting is incomplete) I'm running a new install Fedora Core 5 and rebuilding my development system. I'm running Apache/2.2.2 (part of the FC5 distro) and Tomcat-4.1.32. I downloaded the version 1.2.18 tomcat connector kit and followed the instructions in BUILD.txt to compile and install the mod_jk.so connector. I installed one of my development apps and added the context configuration to the server.xml file, and when I try to get to it through apache, the cursor just spins and I get no log entries of any kind, neither in the apache logs nor the tomcat logs. I can, however, point my browser to port 8009 and bring up the newly installed app.All the gory details are below. Any idea what might be wrong? In the server.xml file, the only change I have made from the distribution is to add this context: Context crossContext=true debug=0 docBase=AccountManager path=/accntManager reloadable=true Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_accntmanager_log. suffix=.txt timestamp=true/ Parameter name=UniAccnt value=/datatel/development/coldev17 override=false/ Parameter name=AdminAddresses value=[EMAIL PROTECTED] override=false/ /Context I also created this workers.properties file in the tomcat conf directory: workers.tomcat_home=/var/apache-tomcat-4.1.32 workers.java_home=/usr/java/j2sdk1.4.2_12 ps=/ worker.list=ajp13 worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 And finally, the following configuration detail was added to apache's httpd.conf file. Tomcat and apache were than both restarted. LoadModule jk_module modules/mod_jk.so JkWorkersFile /var/apache-tomcat-4.1.32/conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevel info JkMount /*.jsp ajp13 JkMount /accntManager/* ajp13 Any suggestions here would be greatly appreciated. Thanks, Rob Tanner Linfield College - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: [REPOST] Can't get apache and Tomcat to talk
Mark, Thank you. That took care of the problem. -- Rob On 09/15/2006 05:28 PM, Mark Thomas wrote: Rob Tanner wrote: Brian, Adding the Listener ... / parameter you suggest generates a java.lang.ClassNotFoundException: org.apache.jk.config.ApacheConfig. Where should I find the jarfile containing that class? It's new to me and I know I'm not using that listener in my install of Tomcat-4.1.31 on another machine. And when I modify the AJP/1.3 connector to include the line: protocol="AJP/1.3". I presume the two errors are related. Is this something new in 4.1.32? There is a bug in 4.1.32 that breaks the configuration of the AJP connector. Use 4.1.34 instead. That will work with your 4.1.31 config. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Having trouble getting an Apache connector to work
Thanks! That makes it usable. I'll keep an eye out for 4.1.33. -- Rob On 08/15/2006 07:58 PM, Mark Thomas wrote: Mark Thomas wrote: I am now seeing the same thing on my dev box. I'm looking in to it and will let you know. My bad. If you use protocolHandler rather than protocolHandlerClassName in the AJP connector things should work as you expect. This is a coding bug rather than a doc bug and is enough to keep 4.1.32 as a beta. 4.1.33 will follow shortly. I am aiming to resolve the only outstanding TC4 bug (40252) before I do the 4.1.33 release. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Logging of request parameters -- how do I turn off
Hi. I've noticed that request parameters are being written to the file catalina.out (using Tomcat 4.1.31). For the most part I don't really care, but when forms include passwords and those plaintext password gets written into the file I do. I've never intentionally turned that capability on. How do I turn it off? Thanks, Rob -- Rob Tanner UNIX Services Manager Linfield College, McMinnville OR - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Having trouble getting an Apache connector to work
Hi, I'm building a new development system. I can access my applications directly from my browser 0n port 8009, but not through Apache. I'm have j2sdk1.4.2_12 and apache-tomcat-4.1.32 installed. The version of Apache is 2.0.54 (from the FC4 distro). I built the connector from the tomcat-connectors-1.2.18-src, using the included directions. The workers.properties file: worker.list=ajp13 worker.ajp13.host=localhost worker.ajp13.port=8009 worker.ajp13.type=ajp13 The httpd.conf file: LoadModule jk_module modules/mod_jk.so JkWorkersFile /var/apache-tomcat-4.1.32/conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevelinfo JkMount /*.jsp ajp13 JkMount /accntManager/* ajp13 When I attempt to access the servlet via Apache, the page just keeps loading forever (oodly enough, it doesn't even timeout). Any ideas? Thanks, Rob -- Rob Tanner Linfield College - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Having trouble getting an Apache connector to work
Mark, The distinction does not appear to be the case. On my old development system which does work, I can go via apache or directly to port 8009 and they both work. -- Rob Mark Thomas wrote: Rob Tanner wrote: Hi, I'm building a new development system. I can access my applications directly from my browser 0n port 8009, but not through Apache. If it works through a browser you must have the connector configured for http. You need to configure it for ajp for it to work with the Apache connector. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Having trouble getting an Apache connector to work
This is the snippet where the connectors are defined. It is identical to my older development system and it's pretty much the Tomcat comes out of the box (or the tarball): !-- Define a non-SSL Coyote HTTP/1.1 Connector on port 8080 -- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8080 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 useURIValidationHack=false disableUploadTimeout=true / !--Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8080 enableLookups=true redirectPort=8443 acceptCount=100 connectionTimeout=2 useURIValidationHack=false disableUploadTimeout=true / -- !-- Note : To disable connection timeouts, set connectionTimeout value to 0 -- !-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -- !-- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8443 enableLookups=true scheme=https secure=true acceptCount=100 useURIValidationHack=false disableUploadTimeout=true clientAuth=false sslProtocol=TLS / -- !-- Define a Coyote AJP/1.3 Connector on port 8009 -- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 enableLookups=true redirectPort=8443 connectionTimeout=0 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler / On 08/14/2006 05:50 PM, Yassine ELassad (YEL) wrote: Hi Rob, I'm just curious to know how you manage to access your application from port 8009 via browser while your Config shows : worker.ajp13.port=8009 either you specified the wrong port number for the http connector or you stated the wrong one. AFAIK the port 8009 is used by mod_jk to communicates with Apache and since your page keeps loading for ever i assume you create a kind of loop request - Apache port 80 - mod_jk - 8009 tomcat 8009 can you please provide a snippet of your server.xml where your jk connector is defined and where you http connectors is defined too. here are configurations that do works for me you can adjust them for your needs: http://tomcat.anfatech.com/cocoon/tomcat/g12/19.html Greetings Yassine Elassad 00 49 221 800 8961 00 49 160 6223 9000 Cologne, Germany On 8/15/06, Rob Tanner [EMAIL PROTECTED] wrote: Hi, I'm building a new development system. I can access my applications directly from my browser 0n port 8009, but not through Apache. I'm have j2sdk1.4.2_12 and apache-tomcat-4.1.32 installed. The version of Apache is 2.0.54 (from the FC4 distro). I built the connector from the tomcat-connectors-1.2.18-src, using the included directions. The workers.properties file: worker.list=ajp13 worker.ajp13.host=localhost worker.ajp13.port=8009 worker.ajp13.type=ajp13 The httpd.conf file: LoadModule jk_module modules/mod_jk.so JkWorkersFile /var/apache-tomcat-4.1.32/conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevelinfo JkMount /*.jsp ajp13 JkMount /accntManager/* ajp13 When I attempt to access the servlet via Apache, the page just keeps loading forever (oodly enough, it doesn't even timeout). Any ideas? Thanks, Rob -- Rob Tanner Linfield College - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can't start new install of TOMCAT
Hi, I installed Tomcat 4.1.32 on my new development box, and copied the 4.1.31 server.xml file over from my old development system. But I can't get tomcat to start. The error is: LifecycleException: Coyote connector has not been started. I'm using j2sdk1.4.2_12 is that makes any difference. Here is the output from catalina.log: Starting service Tomcat-Standalone Apache Tomcat/4.1.32 Catalina.start: LifecycleException: Context startup failed due to previous errors LifecycleException: Context startup failed due to previous errors at org.apache.catalina.core.StandardContext.start(StandardContext.java:3700) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1147) at org.apache.catalina.core.StandardHost.start(StandardHost.java:696) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1147) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:310) at org.apache.catalina.core.StandardService.start(StandardService.java:449) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2212) at org.apache.catalina.startup.Catalina.start(Catalina.java:458) at org.apache.catalina.startup.Catalina.execute(Catalina.java:345) at org.apache.catalina.startup.Catalina.process(Catalina.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:150) Stopping service Tomcat-Standalone Catalina.stop: LifecycleException: Coyote connector has not been started LifecycleException: Coyote connector has not been started at org.apache.coyote.tomcat4.CoyoteConnector.stop(CoyoteConnector.java:1381) at org.apache.catalina.core.StandardService.stop(StandardService.java:498) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:2247) at org.apache.catalina.startup.Catalina.start(Catalina.java:489) at org.apache.catalina.startup.Catalina.execute(Catalina.java:345) at org.apache.catalina.startup.Catalina.process(Catalina.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:150) I don't remember having this kind of a problem when I initially installed 4.1.31 and I don't remember doing anything special to get it up and going. Any ideas? Thanks, Rob -- Rob Tanner Linfield College - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
