SSL BIO/NIO setup with openssl CA puzzle
My production tomcat 7.0.26 (and its predecessors back as far as tc 5) have been running with its original SSL server certificate in a JKS keystore for many years. I decided to retire my ancient java-based Certificate Authority and create a new CA using openssl 1.0.1 under ubuntu linux. I followed the guidance in http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Edit_the_Tomcat_Configuration_File I thought it would be sensible to generate all my new certificates and keystores using only openssl, so that I could use the same procedures for java and non-java applications. This meant I needed to produce a PKCS12 keystore for tomcat to use. I hit a succession of problems and resolved them, so I thought it would be helpful to update the wiki once I had a keystore that worked properly (details of tips and gotchas available). There are a lot of variables that I've explored, but I haven't yet succeeded with my pure openssl approach. I do have a PKCS12 keystore that keytool (with the -storetype pkcs12 option) can list perfectly, but tomcat cannot open (with keystoreType=pkcs12 in the Connector). Both tomcat, and keytool are running from java-6-sun-1.6.0.26/jre/lib/i386. The log shows: 17-Oct-2012 15:33:51 org.apache.coyote.AbstractProtocol init SEVERE: Failed to initialize end point associated with ProtocolHandler [http-bio-443] java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big. at sun.security.util.DerInputStream.getLength(DerInputStream.java:544) To understand the problem better, I started again by using keytool -genkeypair and then -certreq. I issued the new certificate with openssl and then imported the certificate chain into the JKS keystore. At this point I don't actually have a problem, because both keytool and tomcat are satisfied with the new keystore and my production system has been converted successfully. I hit some problems with this second approach (keytool genkepair), and so I could add a few notes to the wiki entry. However, I'm bothered that I couldn't get the first approach to work (pure openssl with pkcs12). google throws up a lot of matches for the DerInputStream.getLength error - even one from Mark Thomas about tomcat 4! I found a lot of red herrings, and a few useful ideas, but nothing to resolve my problem. It isn't encouraging to see man pkcs12 ending with the sentence Some would argue that the PKCS#12 standard is one big bug :-), and yet JKS has to be a dead-end approach because it only applies to java. I have another system with java-7-openjdk-i386, but I haven't yet done any work on it. This openjdk does not ship with a keytool program, and so I presume it will use openssl. I wonder whether I have hit a sun java 6 (and 7?) bug that is of limited interest - does anyone have any thoughts? Thanks.. Brian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Implementing SSL and error invocating https://localhost:8443/ (Tomcat 7.0 on Windows 7)
Gabriel Huerta Araujo wrote: ... GRAVE: Failed to initialize end point associated with ProtocolHandler [http-bio-8443] java.io.IOException: La configuración SSL no es válida debido a No available certificate or key corresponds to the SSL cipher suites which are enabled. at org.apache.tomcat.util.net.jsse.JSSESocketFactory.checkConfig(JSSESocketFactory.java:822) ... Caused by: javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled. at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:310) at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:255) Hola. I'm not a specialist of SSL, but what the messages above are saying is that there is a mistmatch between the encryption/decryption methods that are available to the selected HTTPS Connector, and the one you used to create your certificate, with the result that the Connector cannot read the certificate. (Example : you encrypted your certificate using method A, but the Connector by default can only decrypt things using methods B, C or D). Or something of the kind. Therefor, the Connector does not start. Therefor, Tomcat is not listening on that port (8443). Therefor, when you try to connect to that port with IE, IE tells you that the server rejects a connection to that port. Unless I am mistaken, the connector you are using uses the Java-VM-provided SSL mechanisms. I would imagine that the Java JVM provides some encryption schemes by default, and some others optionally. There must be a parameter somewhere to enable/disable some of these schemes. It's more of a Java thing, but there may be a mention of this somewhere in the online Tomcat docs. Look for terms like DES, SHA*, Blowfish,.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL BIO/NIO setup with openssl CA puzzle
On Oct 26, 2012, at 5:11 AM, Brian Burch wrote: My production tomcat 7.0.26 (and its predecessors back as far as tc 5) have been running with its original SSL server certificate in a JKS keystore for many years. I decided to retire my ancient java-based Certificate Authority and create a new CA using openssl 1.0.1 under ubuntu linux. Just my $0.02, but if you are just using Java based applications, stick with keytool. It will save you time. I followed the guidance in http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Edit_the_Tomcat_Configuration_File I thought it would be sensible to generate all my new certificates and keystores using only openssl, so that I could use the same procedures for java and non-java applications. This meant I needed to produce a PKCS12 keystore for tomcat to use. I hit a succession of problems and resolved them, so I thought it would be helpful to update the wiki once I had a keystore that worked properly (details of tips and gotchas available). There are a lot of variables that I've explored, but I haven't yet succeeded with my pure openssl approach. I believe that what you are trying to do should work. It might be easier to debug if we could see a list of the commands that you've run. Maybe just copy and paste your shell session? I do have a PKCS12 keystore that keytool (with the -storetype pkcs12 option) can list perfectly, but tomcat cannot open (with keystoreType=pkcs12 in the Connector). Both tomcat, and keytool are running from java-6-sun-1.6.0.26/jre/lib/i386. The log shows: 17-Oct-2012 15:33:51 org.apache.coyote.AbstractProtocol init SEVERE: Failed to initialize end point associated with ProtocolHandler [http-bio-443] java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big. at sun.security.util.DerInputStream.getLength(DerInputStream.java:544) Please include your connector configuration. Dan To understand the problem better, I started again by using keytool -genkeypair and then -certreq. I issued the new certificate with openssl and then imported the certificate chain into the JKS keystore. At this point I don't actually have a problem, because both keytool and tomcat are satisfied with the new keystore and my production system has been converted successfully. I hit some problems with this second approach (keytool genkepair), and so I could add a few notes to the wiki entry. However, I'm bothered that I couldn't get the first approach to work (pure openssl with pkcs12). google throws up a lot of matches for the DerInputStream.getLength error - even one from Mark Thomas about tomcat 4! I found a lot of red herrings, and a few useful ideas, but nothing to resolve my problem. It isn't encouraging to see man pkcs12 ending with the sentence Some would argue that the PKCS#12 standard is one big bug :-), and yet JKS has to be a dead-end approach because it only applies to java. I have another system with java-7-openjdk-i386, but I haven't yet done any work on it. This openjdk does not ship with a keytool program, and so I presume it will use openssl. I wonder whether I have hit a sun java 6 (and 7?) bug that is of limited interest - does anyone have any thoughts? Thanks.. Brian - 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 BIO/NIO setup with openssl CA puzzle
Hi Dan if you reference this simple test.jsp does every version of every browser accept the cert as CA cert and properly installs your certificate? %@ page contentType=text/html% html head !-- wait 1 second then download and install cert -- meta http-equiv=refresh content=1; URL=http://DanMachine:8080/Danwebapp/DanCertificate.cer; /head body /body /html Martin Gainty __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Subject: Re: SSL BIO/NIO setup with openssl CA puzzle From: dmik...@vmware.com Date: Fri, 26 Oct 2012 08:24:44 -0400 To: users@tomcat.apache.org On Oct 26, 2012, at 5:11 AM, Brian Burch wrote: My production tomcat 7.0.26 (and its predecessors back as far as tc 5) have been running with its original SSL server certificate in a JKS keystore for many years. I decided to retire my ancient java-based Certificate Authority and create a new CA using openssl 1.0.1 under ubuntu linux. Just my $0.02, but if you are just using Java based applications, stick with keytool. It will save you time. I followed the guidance in http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Edit_the_Tomcat_Configuration_File I thought it would be sensible to generate all my new certificates and keystores using only openssl, so that I could use the same procedures for java and non-java applications. This meant I needed to produce a PKCS12 keystore for tomcat to use. I hit a succession of problems and resolved them, so I thought it would be helpful to update the wiki once I had a keystore that worked properly (details of tips and gotchas available). There are a lot of variables that I've explored, but I haven't yet succeeded with my pure openssl approach. I believe that what you are trying to do should work. It might be easier to debug if we could see a list of the commands that you've run. Maybe just copy and paste your shell session? I do have a PKCS12 keystore that keytool (with the -storetype pkcs12 option) can list perfectly, but tomcat cannot open (with keystoreType=pkcs12 in the Connector). Both tomcat, and keytool are running from java-6-sun-1.6.0.26/jre/lib/i386. The log shows: 17-Oct-2012 15:33:51 org.apache.coyote.AbstractProtocol init SEVERE: Failed to initialize end point associated with ProtocolHandler [http-bio-443] java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big. at sun.security.util.DerInputStream.getLength(DerInputStream.java:544) Please include your connector configuration. Dan To understand the problem better, I started again by using keytool -genkeypair and then -certreq. I issued the new certificate with openssl and then imported the certificate chain into the JKS keystore. At this point I don't actually have a problem, because both keytool and tomcat are satisfied with the new keystore and my production system has been converted successfully. I hit some problems with this second approach (keytool genkepair), and so I could add a few notes to the wiki entry. However, I'm bothered that I couldn't get the first approach to work (pure openssl with pkcs12). google throws up a lot of matches for the DerInputStream.getLength error - even one from Mark Thomas about tomcat 4! I found a lot of red herrings, and a few useful ideas, but nothing to resolve my problem. It isn't encouraging to see man pkcs12 ending with the sentence Some would argue that the PKCS#12 standard is one big bug :-), and
Re: tomcat 7 PermGen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ted, On 10/25/12 7:24 PM, Ted Smith wrote: After upgrading to 7, deploying a new war file often results in PermGen error, much more often than in 6.(with identical JVM settings) I have tried all those JVM settings for perm memory but no help. Is there any way to reduce the chance of PermGen errors? such as how deployment should be done, etc? There have been some recent changes involving JAR scanning that are actually mandated by the Servlet 3.0 spec even though many of us (myself included) disagree with the EG's decisions. Anyhow, you said that you were running 7.0.29: 7.0.30 fixes a bug in the way that JAR scanning is done which ends up wasting a ton of memory. Consider upgrading to 7.0.30 (or, better yet, 7.0.32) to see if that helps. http://issues.apache.org/bugzilla/show_bug.cgi?id=53535 Next, you can disable JAR scanning entirely if you'd like for various components. See http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html and search for jarsToSkip. I'm not sure if there is a way to skip such JARs only for specific web applications I think you may only affect the entire server. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCKokAACgkQ9CaO5/Lv0PAN8QCaA7OQ6UwC1L3/ibmUSy/FdO65 3n8AoJnoC0bmY8w/HEUMnnyFkRNas4W7 =/A4q -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Implementing SSL and error invocating https://localhost:8443/ (Tomcat 7.0 on Windows 7)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gabriel, On 10/25/12 5:42 PM, Gabriel Huerta Araujo wrote: Sorry I forgot to include what below command generates: openssl c_client -connect host:8443 Oops. That should have been s_client, but you already figured that out: I had to run it as: openssl s_client -connect host:8443 And this is what generates: gethostbyname failure connect:errno=1 What happens if you use the actual hostname of the server you are trying to contact? It probably can't connect because of connection refused (see other reply). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCKox0ACgkQ9CaO5/Lv0PCBjACePY9FW4XrWJ04o6vJzp/zqgVc ihAAoJ1peCXB+aAmaUHSrlQZZYdBjQo5 =RSR9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Implementing SSL and error invocating https://localhost:8443/ (Tomcat 7.0 on Windows 7)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gabriel,
On 10/25/12 5:32 PM, Gabriel Huerta Araujo wrote:
My web.xml's connector section originally was:
Connector SSLEnabled=true acceptCount=100 clientAuth=false
disableUploadTimeout=true enableLookups=false maxThreads=25
port=8443 keystoreFile=${user.home}/.keystore
keystorePass=my_key_pass
protocol=org.apache.coyote.http11.Http11NioProtocol
scheme=https secure=true sslProtocol=TLS /
and I had to replace for this (because I wanted to know at least
one message error, this way I could do something else):
Connector port=8443 maxThreads=200 scheme=https
secure=true SSLEnabled=true
keystoreFile=${user.home}/.keystore keystorePassmy_key_pass
clientAuth=false sslProtocol=TLS/
So that's pretty much identical as far as SSL configuration goes.
Below it is whar Tomcat reports:
25/10/2012 04:23:20 PM
org.apache.catalina.core.AprLifecycleListener init INFO: La
biblioteca nativa de Apache Tomcat basada en ARP que permite un
rendimiento óptimo en entornos de desarrollo no ha sido hallada en
java.library.path:
C:\jdk1.6.35\bin;C:\windows\Sun\Java\bin;C:\windows\system32;C:\windows;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\mingw\mingw64\bin;C:\Program
Files (x86)\ATI
Technologies\ATI.ACE\Core-Static;C:\jdk1.6.35\bin;C:\Spring\apache-maven-3.0.4\bin;C:\Program
Files (x86)\Liquid Technologies\Liquid XML Studio
2011\XmlDataBinder9\Redist9\cpp\win32\bin;C:\cygwin\bin\;C:\apache-ant-1.8.2/bin;C:\Program
Files (x86)\Microchip\MPLAB C32 Suite\bin;C:\Program Files
(x86)\QuickTime\QTSystem\;C:\Program
Files\TortoiseSVN\bin;C:\Program Files (x86)\CVSNT\;.
Okay, no APR. That's good, since you have a JSSE certificate
configuration.
25/10/2012 04:23:20 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [http-bio-8080] 25/10/2012
04:23:21 PM org.apache.coyote.AbstractProtocol init INFO:
Initializing ProtocolHandler [http-bio-8443] 25/10/2012 04:23:21
PM org.apache.coyote.AbstractProtocol init GRAVE: Failed to
initialize end point associated with ProtocolHandler
[http-bio-8443] java.io.IOException: La configuración SSL no es
válida debido a No available certificate or key corresponds to the
SSL cipher suites which are enabled.
So either you have failed to configure a set of cipher suites that are
compatible with the JRE or the certificate (not likely, since you have
accepted the default) or your certificate can't be loaded.
Caused by: javax.net.ssl.SSLException: No available certificate or
key corresponds to the SSL cipher suites which are enabled. at
com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:310)
at
com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:255)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.checkConfig(JSSESocketFactory.java:818)
... 20 more
It's odd that the cipher suite check is failing instead of something
earlier.
Are you sure that your keystore can be found under
${user.home}/.keystore? Are you sure that the password is correct? (I
would have expected a different kind of error if something were wrong
with that configuration, but it's worth double-checking).
You might have to set the keyAlias attribute in your Connector,
otherwise it will choose the first key read in the keystore as your
certificate. As your keystore contains these entries:
Su almacen de claves contiene 2 entradas
root, 24/10/2012, trustedCertEntry, Huella digital de certificado
(MD5): E2:FF:EB:EF:B5:FA:85:2F:B4:85:FC:1B:1E:0E:94:37 tomcat,
24/10/2012, trustedCertEntry, Huella digital de certificado (MD5):
E2:FF:EB:EF:B5:FA:85:2F:B4:85:FC:1B:1E:0E:94:37
...Tomcat may be choosing the first certificate when you really want
it to choose the second one. Try this:
Connector . keyAlias=tomcat /
See if that helps,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlCKpMkACgkQ9CaO5/Lv0PAvoQCgv1u4W7wXxlkKgYW+Rd6HHxEu
jW4An1iotoQTNxXuVzlxM/+w99PbuyFm
=BjW8
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL BIO/NIO setup with openssl CA puzzle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian, On 10/26/12 5:11 AM, Brian Burch wrote: I have another system with java-7-openjdk-i386, but I haven't yet done any work on it. This openjdk does not ship with a keytool program, and so I presume it will use openssl. I dunno about the i386 version, but I have /usr/bin/keytool installed by Debian package openjdk-7-jre-headless (x86_64). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCKqFYACgkQ9CaO5/Lv0PB7wACgoQsJwEBd0ZBbjDyEpcD9U+kq UZMAnj32nxYKFq6hK4zJZ7LDEEKAyOow =wZbM -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Implementing SSL and error invocating https://localhost:8443/ (Tomcat 7.0 on Windows 7)
Hi Christopher I do not understand what you mean with other reply, but I tried openssl s_client -host logangha -port 8443 connect: Connection refused connect:errno=111 Also I tried openssl s_client -connect logangha:8443 And generates same output: connect: Connection refused connect:errno=111 - Original Message - From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Friday, October 26, 2012 9:50:05 AM Subject: Re: Implementing SSL and error invocating https://localhost:8443/ (Tomcat 7.0 on Windows 7) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gabriel, On 10/25/12 5:42 PM, Gabriel Huerta Araujo wrote: Sorry I forgot to include what below command generates: openssl c_client -connect host:8443 Oops. That should have been s_client, but you already figured that out: I had to run it as: openssl s_client -connect host:8443 And this is what generates: gethostbyname failure connect:errno=1 What happens if you use the actual hostname of the server you are trying to contact? It probably can't connect because of connection refused (see other reply). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCKox0ACgkQ9CaO5/Lv0PCBjACePY9FW4XrWJ04o6vJzp/zqgVc ihAAoJ1peCXB+aAmaUHSrlQZZYdBjQo5 =RSR9 -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: Tomcat 7.0.30 CMA, clustering, and SSO
Haha, Scott you're here too? On Thu, Oct 25, 2012 at 2:06 PM, Scott Carlson scott.a.carl...@gmail.comwrote: We've setup TC 7.0.32 with Clustering and Tomcat Container Managed Authentication. HTTPSessions and SSOSessions are clustered across the wire. With logging turned way up, I can see the synchronization and I can see the sessions in the Tomcat Manager. When I kill -9 one of the tomcats, I'm automatically swapped to the other leg, and I'm still logged in. So it works, unless I do a catalina.sh shutdown. In that case, the SSO session is expired from the other leg. The HTTPSession is still there, but because the SSO session is expired, I'm forced to login again. This doesn't seem correct. The DeltaSession looks at the notifyCluster parameter before sending a message to expire the HTTPSession, but the ClusterSingleSignOn valve has already sent its message to expire the SSO session by then. So the SSO is missing for the session. When shutting down, the stack trace looks like this (with some relevant parameters replaced in line) isExpireSessionsOnShutdown() == false ClusterSingleSignOn.deregister(SSOID) line: 274 ClusterSingleSignOn(SingleSignOn).sessionEvent(SessionEvent) line: 247 DeltaSession(StandardSession).fireSessionEvent(Session.SESSION_DESTROYED_EVENT, null) line: 1752 DeltaSession(StandardSession).expire(true) line: 844 DeltaSession.expire(true, false) line: 462 DeltaManager.stopInternal() line: 967 DeltaManager(LifecycleBase).stop() line: 232 StandardContext.stopInternal() line: 5474 StandardContext(LifecycleBase).stop() line: 232 When doing a normal session invalidation (for logout), it ends up doing the same thing, which is correct. ClusterSingleSignOn.deregister(SSOID) line: 276 ClusterSingleSignOn(SingleSignOn).sessionEvent(SessionEvent) line: 247 DeltaSession(StandardSession).fireSessionEvent(Session.SESSION_DESTROYED_EVENT, null) line: 1752 DeltaSession(StandardSession).expire(true) line: 844 DeltaSession.expire(true, true) line: 462 DeltaSession.expire(true) line: 444 DeltaSession(StandardSession).expire() line: 742 DeltaSession(StandardSession).invalidate() line: 1253 StandardSessionFacade.invalidate() line: 190 So I can't just change the DeltaSession to ignore that event. I can't just have expire not call the super, or the HTTPSessionListeners would not be called. I think this is a bug, but I don't see even a good fix for it. Ideas? If this does look like a bug, I can log an issue for it. Relevant server.xml here: Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Valve className=org.apache.catalina.ha.authenticator.ClusterSingleSignOn / Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster channelSendOptions=8 Manager className=org.apache.catalina.ha.session.DeltaManager / Channel className=org.apache.catalina.tribes.group.GroupChannel /Channel Valve className=org.apache.catalina.ha.tcp.ReplicationValve filter= statistics=true / Valve className=org.apache.catalina.ha.session.JvmRouteBinderValve / ClusterListener className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener / ClusterListener className=org.apache.catalina.ha.session.ClusterSessionListener / /Cluster /Host The context XML just has a JDBCRealm realm configuration.
Tomcat 7 manager quirk?
Hey group, I'm working with Tomcat 7's manager application for text deployments. I am having a bit of a quirky issue here. I am deploying a web application that is approx 75MB as a war file that uses Tomcat's ROOT context. Is there a way that I can get tomcat to NOT start auto-deploying immediately when the manager is invoked with a deploy / update command? Something like a check to see if the web application has fully uploaded? Is there currently a work around for this? When I run the command: curl -k --upload-file ROOT.war https://[manageruser]:[pwd]@[fqd name]:8443/manager/text/deploy?path=/ROOTwar=ROOT.warupdate=true, I get many different exceptions. If I go to push the webapp as a new application, I an riddled with multiple exceptions: SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Invalid or unreadable WAR file : error in opening zip file at org.apache.naming.resources.WARDirContext.setDocBase(WARDirContext.java:141) SEVERE: Exception fixing docBase for context [] java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) and of course how could I forget SEVERE: Error deploying web application archive /opt/apache-tomcat-7.0.30/webapps/ROOT.war java.lang.IllegalArgumentException: addChild: Child name '' is not unique. A simple restart fixes this... but that's really counter intuitive and very invasive. Obviously there is something that I am doing wrong, but I can't figure it out. What I see happening is that TC is getting the file, and instead of waiting for the entire file (the web app is 75MB), tries to immediately redeploy it. 1 - Is there a way to force tomcat to wait until the uploading of the application is complete? 2 - If so, how?
Re: Implementing SSL and error invocating https://localhost:8443/ (Tomcat 7.0 on Windows 7)
I have followed below steps: 1.- Erase keytore keytool -delete -keystore .keystore -storepass x_men_gha 2.- List to verify if it has been deleted. keytool -list -storepass x_men_gha Tipo de almacÚn de claves: JKS Proveedor de almacÚn de claves: SUN Su almacÚn de claves contiene 0 entradas 3.- Create as stated: keytool -genkey -alias tomcat -keyalg RSA Escriba la contrase±a del almacÚn de claves: La contrase±a del almacÚn de claves es demasiado corta, debe tener al menos 6 ca racteres Escriba la contrase±a del almacÚn de claves: ┐Cußles son su nombre y su apellido? [Unknown]: Gabriel Huerta ┐Cußl es el nombre de su unidad de organizaci¾n? [Unknown]: Desarrollo ┐Cußl es el nombre de su organizaci¾n? [Unknown]: Hildebrando ┐Cußl es el nombre de su ciudad o localidad? [Unknown]: Queretaro ┐Cußl es el nombre de su estado o provincia? [Unknown]: Santiago ┐Cußl es el c¾digo de paÝs de dos letras de la unidad? [Unknown]: MX ┐Es correcto CN=Gabriel Huerta, OU=Desarrollo, O=Hildebrando, L=Queretaro, ST=Sa ntiago, C=MX? [no]: y Escriba la contrase±a clave para tomcat (INTRO si es la misma contrase±a que la del almacÚn de claves): 4.- List to verify it: C:\Users\Gabriel Huertakeytool -list Escriba la contrase±a del almacÚn de claves: Tipo de almacÚn de claves: JKS Proveedor de almacÚn de claves: SUN Su almacÚn de claves contiene entrada 1 tomcat, 26/10/2012, PrivateKeyEntry, Huella digital de certificado (MD5): 00:37:8B:7F:F1:A4:B6:EE:8F:00:69:95:0A:A8:AD:14 5.- Import certificate as stated for Tomcat documentation: For Verisign.com trial certificates go to: http://www.verisign.com/support/verisign-intermediate-ca/Trial_Secure_Server_Root/index.html Once there I followed instructions where says Click here to go to the Installation Instructions, basically I copied below message and pasted it into a file named certif.cer: -BEGIN CERTIFICATE- MIIEVzCCAz+gAwIBAgIQFoFkpCjKEt+rEvGfsbk1VDANBgkqhkiG9w0BAQUFADCB jDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTAwLgYDVQQL EydGb3IgVGVzdCBQdXJwb3NlcyBPbmx5LiAgTm8gYXNzdXJhbmNlcy4xMjAwBgNV BAMTKVZlcmlTaWduIFRyaWFsIFNlY3VyZSBTZXJ2ZXIgUm9vdCBDQSAtIEcyMB4X DTA5MDQwMTAwMDAwMFoXDTI5MDMzMTIzNTk1OVowgYwxCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEwMC4GA1UECxMnRm9yIFRlc3QgUHVycG9z ZXMgT25seS4gIE5vIGFzc3VyYW5jZXMuMTIwMAYDVQQDEylWZXJpU2lnbiBUcmlh bCBTZWN1cmUgU2VydmVyIFJvb3QgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMCJggWnSVAcIomnvCFhXlCdgafCKCDxVSNQY2jhYGZXcZsq ToJmDQ7b9JO39VCPnXELOENP2+4FNCUQnzarLfghsJ8kQ9pxjRTfcMp0bsH+Gk/1 qLDgvf9WuiBa5SM/jXNvroEQZwPuMZg4r2E2k0412VTq9ColODYNDZw3ziiYdSjV fY3VfbsLSXJIh2jaJC5kVRsUsx72s4/wgGXbb+P/XKr15nMIB0yH9A5tiCCXQ5nO EV7/ddZqmL3zdeAtyGmijOxjwiy+GS6xr7KACfbPEJYZYaS/P0wctIOyQy6CkNKL o5vDDkOZks0zjf6RAzNXZndvsXEJpQe5WO1avm8CAwEAAaOBsjCBrzAPBgNVHRMB Af8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjBtBggrBgEFBQcBDARhMF+hXaBbMFkw VzBVFglpbWFnZS9naWYwITAfMAcGBSsOAwIaBBSP5dMahqyNjmvDz4Bq1EgYLHsZ LjAlFiNodHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvLmdpZjAdBgNVHQ4E FgQUSBnnkm+SnTRjmcDwmcjWpYyMf2UwDQYJKoZIhvcNAQEFBQADggEBADuswa8C 0hunHp17KJQ0WwNRQCp8f/u4L8Hz/TiGfybnaMXgn0sKI8Xe79iGE91M7vrzh0Gt ap0GLShkiqHGsHkIxBcVMFbEQ1VS63XhTeg36cWQ1EjOHmu+8tQe0oZuwFsYYdfs n4EZcpspiep9LFc/hu4FE8SsY6MiasHR2Ay97UsC9A3S7ZaoHfdwyhtcINXCu2lX W0Gpi3vzWRvwqgua6dm2WVKJfvPfmS1mAP0YmTcIwjdiNXiU6sSsJEoNlTR9zCoo 4oKQ8wVoWZpbuPZb5geszhS7YsABUPIAAfF1YQCiMULtpa6HFzzm7sdf72N3HfwE aQNg95KnKGrrDUI= -END CERTIFICATE- Below are all instructions stated for this place which I have follwed: Installation Instructions For Microsoft Browsers 1.Click on the Secure Site Trial Root Certificate link above. 2.Save the certificate into a file with a .cer extension. 3.Open a Microsoft IE Browser. 4.Go to Tools Internet Options Content Certificates 5.Click Import. A certificate manager Import Wizard will appear. Click Next. 6.Browse to the location of the recently stored root (done in step 2). Select ALL files for file type. 7.Select the certificate and click Open. 8.Click Next. 9.Select Automatically select the certificate store based on the type of the certificate. Click Ok. 10.Click Next then Finish. 11.When prompted and asked if you wish to add the following certificate to the root store, click Yes. For last step I was not asked to add trial certificate to the root store. I did not do below steps(stated from Tomcat documentation), because these ones require keystore file: Import the Chain Certificate into your keystore keytool -import -alias root -keystore your_keystore_filename \ -trustcacerts -file filename_of_the_chain_certificate And finally import your new Certificate keytool -import -alias tomcat -keystore your_keystore_filename \ -file your_certificate_filename 6.- Restart tomcat: It did not generate any error, but when I open IE with link https://localhost:8443/ appears below message: There is a problem with the security certificate for this site Go to this website (not
Re: Implementing SSL and error invocating https://localhost:8443/ (Tomcat 7.0 on Windows 7)
On 27/10/2012 9:37 AM, Gabriel Huerta Araujo huert...@hildebrando.com wrote: I have followed below steps: 1.- Erase keytore keytool -delete -keystore .keystore -storepass x_men_gha 2.- List to verify if it has been deleted. keytool -list -storepass x_men_gha Tipo de almacÚn de claves: JKS Proveedor de almacÚn de claves: SUN Su almacÚn de claves contiene 0 entradas 3.- Create as stated: keytool -genkey -alias tomcat -keyalg RSA Escriba la contrase±a del almacÚn de claves: La contrase±a del almacÚn de claves es demasiado corta, debe tener al menos 6 ca racteres Escriba la contrase±a del almacÚn de claves: ┐Cußles son su nombre y su apellido? [Unknown]: Gabriel Huerta ┐Cußl es el nombre de su unidad de organizaci¾n? [Unknown]: Desarrollo ┐Cußl es el nombre de su organizaci¾n? [Unknown]: Hildebrando ┐Cußl es el nombre de su ciudad o localidad? [Unknown]: Queretaro ┐Cußl es el nombre de su estado o provincia? [Unknown]: Santiago ┐Cußl es el c¾digo de paÝs de dos letras de la unidad? [Unknown]: MX ┐Es correcto CN=Gabriel Huerta, OU=Desarrollo, O=Hildebrando, L=Queretaro, ST=Sa ntiago, C=MX? [no]: y Escriba la contrase±a clave para tomcat (INTRO si es la misma contrase±a que la del almacÚn de claves): 4.- List to verify it: C:\Users\Gabriel Huertakeytool -list Escriba la contrase±a del almacÚn de claves: Tipo de almacÚn de claves: JKS Proveedor de almacÚn de claves: SUN Su almacÚn de claves contiene entrada 1 tomcat, 26/10/2012, PrivateKeyEntry, Huella digital de certificado (MD5): 00:37:8B:7F:F1:A4:B6:EE:8F:00:69:95:0A:A8:AD:14 5.- Import certificate as stated for Tomcat documentation: For Verisign.com trial certificates go to: http://www.verisign.com/support/verisign-intermediate-ca/Trial_Secure_Server_Root/index.html Once there I followed instructions where says Click here to go to the Installation Instructions, basically I copied below message and pasted it into a file named certif.cer: -BEGIN CERTIFICATE- MIIEVzCCAz+gAwIBAgIQFoFkpCjKEt+rEvGfsbk1VDANBgkqhkiG9w0BAQUFADCB jDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTAwLgYDVQQL EydGb3IgVGVzdCBQdXJwb3NlcyBPbmx5LiAgTm8gYXNzdXJhbmNlcy4xMjAwBgNV BAMTKVZlcmlTaWduIFRyaWFsIFNlY3VyZSBTZXJ2ZXIgUm9vdCBDQSAtIEcyMB4X DTA5MDQwMTAwMDAwMFoXDTI5MDMzMTIzNTk1OVowgYwxCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEwMC4GA1UECxMnRm9yIFRlc3QgUHVycG9z ZXMgT25seS4gIE5vIGFzc3VyYW5jZXMuMTIwMAYDVQQDEylWZXJpU2lnbiBUcmlh bCBTZWN1cmUgU2VydmVyIFJvb3QgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMCJggWnSVAcIomnvCFhXlCdgafCKCDxVSNQY2jhYGZXcZsq ToJmDQ7b9JO39VCPnXELOENP2+4FNCUQnzarLfghsJ8kQ9pxjRTfcMp0bsH+Gk/1 qLDgvf9WuiBa5SM/jXNvroEQZwPuMZg4r2E2k0412VTq9ColODYNDZw3ziiYdSjV fY3VfbsLSXJIh2jaJC5kVRsUsx72s4/wgGXbb+P/XKr15nMIB0yH9A5tiCCXQ5nO EV7/ddZqmL3zdeAtyGmijOxjwiy+GS6xr7KACfbPEJYZYaS/P0wctIOyQy6CkNKL o5vDDkOZks0zjf6RAzNXZndvsXEJpQe5WO1avm8CAwEAAaOBsjCBrzAPBgNVHRMB Af8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjBtBggrBgEFBQcBDARhMF+hXaBbMFkw VzBVFglpbWFnZS9naWYwITAfMAcGBSsOAwIaBBSP5dMahqyNjmvDz4Bq1EgYLHsZ LjAlFiNodHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvLmdpZjAdBgNVHQ4E FgQUSBnnkm+SnTRjmcDwmcjWpYyMf2UwDQYJKoZIhvcNAQEFBQADggEBADuswa8C 0hunHp17KJQ0WwNRQCp8f/u4L8Hz/TiGfybnaMXgn0sKI8Xe79iGE91M7vrzh0Gt ap0GLShkiqHGsHkIxBcVMFbEQ1VS63XhTeg36cWQ1EjOHmu+8tQe0oZuwFsYYdfs n4EZcpspiep9LFc/hu4FE8SsY6MiasHR2Ay97UsC9A3S7ZaoHfdwyhtcINXCu2lX W0Gpi3vzWRvwqgua6dm2WVKJfvPfmS1mAP0YmTcIwjdiNXiU6sSsJEoNlTR9zCoo 4oKQ8wVoWZpbuPZb5geszhS7YsABUPIAAfF1YQCiMULtpa6HFzzm7sdf72N3HfwE aQNg95KnKGrrDUI= -END CERTIFICATE- Below are all instructions stated for this place which I have follwed: Installation Instructions For Microsoft Browsers 1.Click on the Secure Site Trial Root Certificate link above. 2.Save the certificate into a file with a .cer extension. 3.Open a Microsoft IE Browser. 4.Go to Tools Internet Options Content Certificates 5.Click Import. A certificate manager Import Wizard will appear. Click Next. 6.Browse to the location of the recently stored root (done in step 2). Select ALL files for file type. 7.Select the certificate and click Open. 8.Click Next. 9.Select Automatically select the certificate store based on the type of the certificate. Click Ok. 10.Click Next then Finish. 11.When prompted and asked if you wish to add the following certificate to the root store, click Yes. For last step I was not asked to add trial certificate to the root store. I did not do below steps(stated from Tomcat documentation), because these ones require keystore file: Import the Chain Certificate into your keystore keytool -import -alias root -keystore your_keystore_filename \ -trustcacerts -file filename_of_the_chain_certificate And finally import your new Certificate keytool -import -alias tomcat -keystore your_keystore_filename \ -file your_certificate_filename 6.- Restart tomcat: It did not generate any error, but when I open IE with link
Re: Implementing SSL and error invocating https://localhost:8443/ (Tomcat 7.0 on Windows 7)
This is my hosts file's content: 10.254.5.1 sigcbd01#10.192.19.1 sigc 10.254.4.63 sdswbd01#10.192.17.66sadigeo 10.254.2.248nsisba01 None of these IP's is my domain. How do I configure dns resolution for such name on my computer to point to the ip of my laptop? As I am testing I am using my laptop with Windows 7 installed. Regards. - Original Message - From: Igor Cicimov icici...@gmail.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, October 26, 2012 6:21:49 PM Subject: Re: Implementing SSL and error invocating https://localhost:8443/ (Tomcat 7.0 on Windows 7) On 27/10/2012 10:09 AM, Gabriel Huerta Araujo huert...@hildebrando.com wrote: I used logangha(which is my computer name) instead of localhost but again I had to click the Information bar to display the content (not recommended). So you got the cert for logangha??? Again, you should match the name of the domain you got the certificate for not the server name. Meaning you need dns resolution for that name on your server or local network to point to the ip of the server. Thats easy done in linux by editing the /etc/hosts file, not sure about windows. Google is your friend i think there should be simmilar file too. Regards. - Original Message - From: Igor Cicimov icici...@gmail.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, October 26, 2012 5:41:59 PM Subject: Re: Implementing SSL and error invocating https://localhost:8443/(Tomcat 7.0 on Windows 7) On 27/10/2012 9:37 AM, Gabriel Huerta Araujo huert...@hildebrando.com wrote: I have followed below steps: 1.- Erase keytore keytool -delete -keystore .keystore -storepass x_men_gha 2.- List to verify if it has been deleted. keytool -list -storepass x_men_gha Tipo de almacÚn de claves: JKS Proveedor de almacÚn de claves: SUN Su almacÚn de claves contiene 0 entradas 3.- Create as stated: keytool -genkey -alias tomcat -keyalg RSA Escriba la contrase±a del almacÚn de claves: La contrase±a del almacÚn de claves es demasiado corta, debe tener al menos 6 ca racteres Escriba la contrase±a del almacÚn de claves: ┐Cußles son su nombre y su apellido? [Unknown]: Gabriel Huerta ┐Cußl es el nombre de su unidad de organizaci¾n? [Unknown]: Desarrollo ┐Cußl es el nombre de su organizaci¾n? [Unknown]: Hildebrando ┐Cußl es el nombre de su ciudad o localidad? [Unknown]: Queretaro ┐Cußl es el nombre de su estado o provincia? [Unknown]: Santiago ┐Cußl es el c¾digo de paÝs de dos letras de la unidad? [Unknown]: MX ┐Es correcto CN=Gabriel Huerta, OU=Desarrollo, O=Hildebrando, L=Queretaro, ST=Sa ntiago, C=MX? [no]: y Escriba la contrase±a clave para tomcat (INTRO si es la misma contrase±a que la del almacÚn de claves): 4.- List to verify it: C:\Users\Gabriel Huertakeytool -list Escriba la contrase±a del almacÚn de claves: Tipo de almacÚn de claves: JKS Proveedor de almacÚn de claves: SUN Su almacÚn de claves contiene entrada 1 tomcat, 26/10/2012, PrivateKeyEntry, Huella digital de certificado (MD5): 00:37:8B:7F:F1:A4:B6:EE:8F:00:69:95:0A:A8:AD:14 5.- Import certificate as stated for Tomcat documentation: For Verisign.com trial certificates go to: http://www.verisign.com/support/verisign-intermediate-ca/Trial_Secure_Server_Root/index.html Once there I followed instructions where says Click here to go to the Installation Instructions, basically I copied below message and pasted it into a file named certif.cer: -BEGIN CERTIFICATE- MIIEVzCCAz+gAwIBAgIQFoFkpCjKEt+rEvGfsbk1VDANBgkqhkiG9w0BAQUFADCB jDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTAwLgYDVQQL EydGb3IgVGVzdCBQdXJwb3NlcyBPbmx5LiAgTm8gYXNzdXJhbmNlcy4xMjAwBgNV BAMTKVZlcmlTaWduIFRyaWFsIFNlY3VyZSBTZXJ2ZXIgUm9vdCBDQSAtIEcyMB4X DTA5MDQwMTAwMDAwMFoXDTI5MDMzMTIzNTk1OVowgYwxCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEwMC4GA1UECxMnRm9yIFRlc3QgUHVycG9z ZXMgT25seS4gIE5vIGFzc3VyYW5jZXMuMTIwMAYDVQQDEylWZXJpU2lnbiBUcmlh bCBTZWN1cmUgU2VydmVyIFJvb3QgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMCJggWnSVAcIomnvCFhXlCdgafCKCDxVSNQY2jhYGZXcZsq ToJmDQ7b9JO39VCPnXELOENP2+4FNCUQnzarLfghsJ8kQ9pxjRTfcMp0bsH+Gk/1 qLDgvf9WuiBa5SM/jXNvroEQZwPuMZg4r2E2k0412VTq9ColODYNDZw3ziiYdSjV fY3VfbsLSXJIh2jaJC5kVRsUsx72s4/wgGXbb+P/XKr15nMIB0yH9A5tiCCXQ5nO EV7/ddZqmL3zdeAtyGmijOxjwiy+GS6xr7KACfbPEJYZYaS/P0wctIOyQy6CkNKL o5vDDkOZks0zjf6RAzNXZndvsXEJpQe5WO1avm8CAwEAAaOBsjCBrzAPBgNVHRMB Af8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjBtBggrBgEFBQcBDARhMF+hXaBbMFkw VzBVFglpbWFnZS9naWYwITAfMAcGBSsOAwIaBBSP5dMahqyNjmvDz4Bq1EgYLHsZ LjAlFiNodHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvLmdpZjAdBgNVHQ4E FgQUSBnnkm+SnTRjmcDwmcjWpYyMf2UwDQYJKoZIhvcNAQEFBQADggEBADuswa8C 0hunHp17KJQ0WwNRQCp8f/u4L8Hz/TiGfybnaMXgn0sKI8Xe79iGE91M7vrzh0Gt ap0GLShkiqHGsHkIxBcVMFbEQ1VS63XhTeg36cWQ1EjOHmu+8tQe0oZuwFsYYdfs
Re: Tomcat 7 manager quirk?
Igor, I figured it out. If you set the deployOnStartup attribute to true, but the autoDeploy attribute to false, the war files that are in the webapps folder at the time of startup will load. Then you can run the manager via script (command line). Simply pass the undeploy command to the manager to the context you want to remove and let it finish. It will remove the war and the application directory. Then I ran the command to deploy again via curl. This time it waited until the entire war was uploaded before it deployed it. It took me a while to figure out it was a combination of deployOnStartup and autoDeploy. Of course there was ZERO incling that this was the problem and I had to re-re-re-read the docs very carefully to figure this out. Finally decided to try a hunch and it actually paid off. It might be a good idea to add this to the wiki or some place with common trouble shooting problems. Just my $.02. - Josh On Fri, Oct 26, 2012 at 6:37 PM, Igor Cicimov icici...@gmail.com wrote: On 27/10/2012 5:27 AM, Josh Gooding josh.good...@gmail.com wrote: Hey group, I'm working with Tomcat 7's manager application for text deployments. I am having a bit of a quirky issue here. I am deploying a web application that is approx 75MB as a war file that uses Tomcat's ROOT context. Is there a way that I can get tomcat to NOT start auto-deploying immediately when the manager is invoked with a deploy / update command? Something like a check to see if the web application has fully uploaded? Is there currently a work around for this? When I run the command: curl -k --upload-file ROOT.war https://[manageruser]:[pwd]@[fqd name]:8443/manager/text/deploy?path=/ROOTwar=ROOT.warupdate=true, I get many different exceptions. I dont think its tomcat fault it is you telling it to deploy with the above command while the upload is still in progress. You should search for some kind of delay or timeout in curl or find other way of doing this. If I go to push the webapp as a new application, I an riddled with multiple exceptions: SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Invalid or unreadable WAR file : error in opening zip file at org.apache.naming.resources.WARDirContext.setDocBase(WARDirContext.java:141) SEVERE: Exception fixing docBase for context [] java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) and of course how could I forget SEVERE: Error deploying web application archive /opt/apache-tomcat-7.0.30/webapps/ROOT.war java.lang.IllegalArgumentException: addChild: Child name '' is not unique. A simple restart fixes this... but that's really counter intuitive and very invasive. Obviously there is something that I am doing wrong, but I can't figure it out. What I see happening is that TC is getting the file, and instead of waiting for the entire file (the web app is 75MB), tries to immediately redeploy it. 1 - Is there a way to force tomcat to wait until the uploading of the application is complete? 2 - If so, how?
