Re: Valid values for digestEncoding attribute?
On 1/27/11 11:01 AM, Ing. Etienne V. Depasquale wrote: I beg pardon...I should have included the following extract from my context.xml file (with placeholders for database, user and password): Realm className=org.apache.catalina.realm.JDBCRealm debug=99 driverName=org.gjt.mm.mysql.Driver Are you really using such an old driver - I've got an internet archaeologist friend who'll want to look at this... What version of Tomcat/JVM do you have? connectionURL=jdbc:mysql://localhost:3306/databasename?user=usernameam p;password=userpassword userTable=users userNameCol=id userCredCol=passwd userRoleTable=userroles roleNameCol=role digest=MD5 digestEncoding=base64 / base64 is being rejected as a value for the digestEncoding attribute. That's not a valid value. The encoding, if I read the source correctly, should be UTF-8 or ISO-8859-1 or something similar. p Cheers, Etienne Good day, I am unable to identify valid values for the digestEncoding attribute to use with the Realm tag of my app's context.xml file. I've inspected RealmBase.java and JDBCRealm.java, apart from some googling, without finding anything suitable. Can anyone suggest a suitable reference? Cheers, Etienne - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Mod_JK inserted header case sensitivity issue
Chuck Thanks for your input, that's an option that has of course occurred to me, but sadly I'm not in a position to use a different webserver, and although I would agree that MOD_JK is HTTP spec-compliant I would have to say that it's not NSAPI spec-compliant, and it's an NSAPI version of the plugin after all, so I would export it to conform to the NSAPI spec. In it's current state it's broken, the way I see it there are 3 scenarios: 1. It's fixed by developers of MOD_JK. 2. Oracle decide to do an about-face and change there NSAPI spec. 3. I have to maintain my own fixed copy, other iPlanet users may experience same issue and go through the pain I did tracking this down. Any help appreciated as always :) Jon On Thu, Jan 27, 2011 at 3:11 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Jon Forster [mailto:deltaw...@gmail.com] Subject: Mod_JK inserted header case sensitivity issue the MODJK plugin inserts a Content-Length header using mixed-case ie: Content-Length: length (as defined in /native/common/jk_ajp_common.c), this is ignored by the webserver core as it's expecting inserted headers to be all lower-case Let me see if I've understood this properly: the iPlanet webserver is not spec-compliant because it insists that HTTP headers be lower case, and you want the mod_jk plugin to change its spec-compliant behavior to conform to the obvious design flaw in iPlanet? How about an alternative solution: eliminate the intermediate web server, or replace it with one that is spec-compliant (e.g, httpd). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Pid OpenSSO request for Tomcat Form Authentication that requires no password for third party SSO
On 1/27/11 3:57 PM, beau.hutche...@thomsonreuters.com wrote: Chris: Thanks for your reply. Currently I am using Tomcat 6.0.29 @Pid: Would you have any ideas on how to set something up like this? What details are you providing to Tomcat? If I read the thread correctly you've got a single parameter - how are you validating that to stop say, me, guessing at logins? p Beau -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 26, 2011 6:30 PM To: Tomcat Users List Subject: Re: Tomcat Form Authentication that requires no password for third party SSO Beau, On 1/26/2011 1:10 PM, beau.hutche...@thomsonreuters.com wrote: I am trying to integrate my application with an SSO partner application. What Tomcat version? I ask because Tomcat 7 includes the Servlet 3.0 programmatic login API. After successfully logging into the partner app, I will be redirected and only provided a username to log into my tomcat Form Authentication app. I am using a DataSourceRealm to check for both Users and User Roles. DataSourceRealm requires both username and password. I think JAASRealm might be able to help you. Also, one of the list contributors (Pid) is working on a realm to help with OpenSSO or something like that: he may have some ideas about how to set things up. Are there any suggestions as to how I can still authenticate() through the tomcat container without providing a password? Out of the box, I don't believe Tomcat can do this. -chris - 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 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Pid OpenSSO request for Tomcat Form Authentication that requires no password for third party SSO
Pid wrote: On 1/27/11 3:57 PM, beau.hutche...@thomsonreuters.com wrote: Chris: Thanks for your reply. Currently I am using Tomcat 6.0.29 @Pid: Would you have any ideas on how to set something up like this? What details are you providing to Tomcat? If I read the thread correctly you've got a single parameter - how are you validating that to stop say, me, guessing at logins? That's easy, as long as Tomcat accepts only connections from a source known to go through the aforementioned SSO. I have a similar setup at one of my customers. This is only an example : All users use a session on a specific Windows Terminal Server. In that session, they open a browser, which allows them to connect to Tomcat (*). Tomcat accepts only connections from the IP's of the Terminal Server. On the Terminal Server runs that nifty SSO mechanism which I mentioned in another message here. Somehow, that SSO detects the login page which the Tomcat authentication is sending back to the browser, fills-in the userid (**), and re-posts the login form to the server. The user is now logged-in and gets the application page. The user does not see anything. I know that it sounds a bit strange when one explains it like that, but it works. (**) the user-id being sent is the user's Windows Domain user-id, which has already been authenticated/verified, so it can be trusted. There is thus no need to verify it again in Tomcat. (*) Ok, I'm cheating : in my case, it is not Tomcat directly, but it is an Apache httpd front-ending for Tomcat, and connecting to it via mod_jk. mod_jk will pass on the httpd-level user-id, and Tomcat (with the 'tomcatAuthentication=false attribute on the AJP Connector), will accept that user-id as its own. At the Tomcat level, you would still have to do the isUserInRole part though. Now the question is : assuming that there is no httpd front-end and no mod_jk, can a similar mechanism work with Tomcat directly ? In other words, can the standard Tomcat form-based authentication work, if the login form is sent back with a non-blank userid, but with a blank password ? And could this authentication code be easily tweaked to bypass any verification of the received user-id ? And, to the original poster : apologies for somewhat hijacking your thread, but I am just trying to help finding the best method for you. I have a feeling that for this case, having to create a brand-new Authenticator is a bit heavy as a solution. It seems that it should be possible to at least crate some null Realm which always accepts any user-id and always returns OK. Or use whatever mechanism mod_jk is using to the same basic effect. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_JK inserted header case sensitivity issue
2011/1/28 Jon Forster deltaw...@gmail.com: 1. It's fixed by developers of MOD_JK. 2. Oracle decide to do an about-face and change there NSAPI spec. 3. I have to maintain my own fixed copy, other iPlanet users may experience same issue and go through the pain I did tracking this down. 4. You create an issue in Bugzilla and attach a patch there. That is how it usually goes. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_JK inserted header case sensitivity issue
On 01/28/2011 10:08 AM, Jon Forster wrote: I would have to say that it's not NSAPI spec-compliant, and it's an NSAPI version of the plugin after all, so I would export it to conform to the NSAPI spec. Is that somewhere officially documented. We do a whole sort of header manipulation for IIS, so we can do the same for NASPI if that happens to be a well-known feature :) Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat reuses threads and connection instances
On 1/26/11 11:37 PM, Christopher Schultz wrote: Blake, On 1/26/2011 4:05 PM, Blake McBride wrote: The first time a particular web service is called tomcat starts a thread to run it on and creates an instance of the class that implements the web service. All fine. However, if after the first call to the web service completes another call to the same web service occurs, tomcat reuses the same thread and the same instance. Of course this gives me old values for thread local storage and instance variables for that web service. Oh noes!!!111!!!ELEVEN Seriously, this is how the server world works. This is highly unexpected. Perhaps by you, but this behavior is entirely intentional. Is there a way to configure tomcat to have it give me a new instance of the web service class each time? That depends: when you say web service, what do you mean? Are you using a library like Apache Axis or do you have a (relatively) simple servlet handling the requests? The rules of thumb are: 1. Don't use ThreadLocal unless you a) Know what you're doing b) Clean up after yourself and c) Know what you're doing +1 Axis 1.4 has issues in this regard. p 2. Don't use any class members that aren't expected to be used for all requests for all time. Basically, that means don't use them. Instead, use locals in your service() (or doGet/doPost/whatever) method and/or use request attributes to store your data. In terms of the repeated thread use and thread local storage I have, for the time being, started manually resetting the thread local storage. Is there a conventional solution to this problem? Your thread should reset ThreadLocals when you're done using the thread: at the end of the request. Don't forget to handle error conditions and clean up in finally blocks. Why are you using ThreadLocals in the first place? The only legitimate uses I've seen for them are performance optimizations where the ThreadLocal actually /should/ outlive the request and weird stuff like passing data to Log4j loggers through lazy API (non-)usage. I'm not convinced ThreadLocals are a good idea at all. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Using logback for Tomcat internal logging
Hi, On 27 January 2011 15:17, Roy McMorran mcmor...@mdibl.org wrote: Can anyone point me to a document detailing how to replace Tomcat's internal logging (via JULI) with logback? Not for access logs, or the logging output of webapps, but the Tomcat internal logging that ordinarily goes to tomcat.log, etc. Something analogous to this doc I suppose: http://tomcat.apache.org/tomcat-6.0-doc/logging.html#Using_Log4j but for logback? Try here: https://github.com/grgrzybek/tomcat-slf4j-logback Many thanks. -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org -- Best Regards, Brett Delle Grazie - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Valid values for digestEncoding attribute?
Hello Pid :) Time is relative to environment I guess...so how old is old for you? I downloaded the jar file from MySQL's site about the middle of 2010 and the jar file structures the class under org/gjt/mm/mysql. As regards the encoding - right you are and wrong it is. I was misled by a posting on stackoverflow.com. The real problem lies in the fact that Tomcat does not specify any digest algorithm in the www-authenticate header of HTTP/1.1, which leads the browser to digest the password using MD5, regardless of the value of the digest attribute in the Realm tag. Cheers, Etienne -Original Message- From: Pid [mailto:p...@pidster.com] Sent: 28 January 2011 09:40 To: Tomcat Users List Subject: Re: Valid values for digestEncoding attribute? On 1/27/11 11:01 AM, Ing. Etienne V. Depasquale wrote: I beg pardon...I should have included the following extract from my context.xml file (with placeholders for database, user and password): Realm className=org.apache.catalina.realm.JDBCRealm debug=99 driverName=org.gjt.mm.mysql.Driver Are you really using such an old driver - I've got an internet archaeologist friend who'll want to look at this... What version of Tomcat/JVM do you have? connectionURL=jdbc:mysql://localhost:3306/databasename?user=usernameam p;password=userpassword userTable=users userNameCol=id userCredCol=passwd userRoleTable=userroles roleNameCol=role digest=MD5 digestEncoding=base64 / base64 is being rejected as a value for the digestEncoding attribute. That's not a valid value. The encoding, if I read the source correctly, should be UTF-8 or ISO-8859-1 or something similar. p Cheers, Etienne Good day, I am unable to identify valid values for the digestEncoding attribute to use with the Realm tag of my app's context.xml file. I've inspected RealmBase.java and JDBCRealm.java, apart from some googling, without finding anything suitable. Can anyone suggest a suitable reference? Cheers, Etienne - 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: Valid values for digestEncoding attribute?
Yes, I am using DIGEST authentication. But what about the www-authenticate HTTP/1.1 header that Tomcat sends over to the browser? Is it ignored by any browser, simply defaulting to MD5? Cheers, Etienne -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: 27 January 2011 22:56 To: Tomcat Users List Subject: Re: Valid values for digestEncoding attribute? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Etienne, Sure enough, when I reversed the saved password back to the MD5 hash, Tomcat authenticated my login, regardless of the SHA-1 attribute set in my Realm tag's digest attribute. Are you using DIGEST authentication? If so, all current web browsers only implement MD5 as the digest algorithm, since HTTP-AUTH-DIGEST doesn't provide any algorithm negotiation between the client and server. If you have a custom client, you may be able to use a different digest algorithm. Is this one application for programmatic authenticators as opposed to the default that ships with Tomcat? Not likely: Tomcat is configurable while most clients are not. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1B6ecACgkQ9CaO5/Lv0PAPkACfctQAY1P7fwdRGjIjhZi6QWwT 08YAoLPRaddCXJfJe/PGpwJ1OUZaNDpg =NKU1 -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
SSL not working
Hi, I did it now so many times - it always worked - configuring tomcat for SSL. Today: New server, new certificate. Create new keystore, imported root, intermediate and server certificate, configured the connector, same as usual. But... http does not work. No error in tomcats log, nothing. Browser says that it cannot load the page due to a connection problem, maybe security issue. How can I debug this ssl problem? Connector SSLEnabled=true clientAuth=want maxThreads=150 port=8443 protocol=org.apache.coyote.http11.Http11NioProtocol scheme=https secure=true sslProtocol=TLS keystoreFile=conf/tomcat.jks keystoreType=JKS keyAlias=tomcat keystorePass=changeit / Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java-process blocks cpu core to 100%
Sorry, not possible - it's running on a remote machine where I can just use the ibm package and in theirs JDK jstack is not included. Are there any other ways to get it via network? 2011/1/27 Christopher Schultz ch...@christopherschultz.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 1/26/2011 12:05 PM, Christoph Balthaus wrote: Connected by eclipse I discovered the following: when I suspend thread by thread, the load dropped when I suspend * Daemon Thread [Attach handler] (Suspended).* ... [Remote Java Application] IBM J9 VM[localhost:1] Thread [main] (Suspended) Daemon Thread [Signal Dispatcher] (Suspended) * Daemon Thread [Attach handler] (Suspended)* AttachHandler. setlastException(Exception) line: 449 AttachHandler.run() line: 165 Can you run jstack against this process instead of Eclipse's tool? Paste the entire trace unless it contains some sensitive information. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ArVkACgkQ9CaO5/Lv0PBY9QCdH1DoF2KTSQUN0dDZa5cJEK52 TC0AnjH1bsH8fa1n3bJeLeKLJ+km2cCA =wEUc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java-process blocks cpu core to 100%
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 1/28/2011 9:16 AM, Christoph Balthaus wrote: Sorry, not possible - it's running on a remote machine where I can just use the ibm package and in theirs JDK jstack is not included. Are there any other ways to get it via network? You could use JConsole remotely, but you need to have remote JMX configured for the JVM which would probably require a JVM restart. You can also send the process the SIGQUIT and it will emit a thread dump to stdout. If you don't have shell access, that might be difficult, too. This might be a good time to start testing a new Tomcat release for your environment: 6.0.18 is more than 2 years old and many performance and security fixes have gone into Tomcat since then. Warning: the NIO connector appears to be broken in 6.0.30 and looks like it will be in 6.0.31. Consider using 6.0.29 or waiting for 6.0.32 if you are using the NIO connector. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1C01wACgkQ9CaO5/Lv0PDSNgCgwGMWTsJWrnY8KKeupYK6aif2 adQAoK4e+Vj1hscTXP8Xt2jewD/bLr2p =/PRp -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Valid values for digestEncoding attribute?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Etienne, On 1/28/2011 7:59 AM, Ing. Etienne V. Depasquale wrote: Yes, I am using DIGEST authentication. But what about the www-authenticate HTTP/1.1 header that Tomcat sends over to the browser? Is it ignored by any browser, simply defaulting to MD5? I'm sorry, I misspoke. You're right: there is a way for the server to tell the client what kind of digest algorithm to use, but there is no /negotiation/: the server can't give the client a choice, and the client can't tell the server what algorithm it chose. The spec only defines MD5 as the default (and only choice for) algorithm so web browsers have only implemented MD5. If you can demonstrate that a web browser will use SHA-1 (which is, by the way, also a useless algorithm like MD5 these days), I'd be very happy to see it. I'm guessing that Firefox and Google Chrome are the only candidates for that kind of thing. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1C1I0ACgkQ9CaO5/Lv0PBo2wCeM8GswwNUimW/aQ2bJ/O4vOoW zooAn0uQTcu8D8gbb8TRklc0bmlvUXHl =Wong -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Valid values for digestEncoding attribute?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, On 1/28/2011 3:39 AM, Pid wrote: On 1/27/11 11:01 AM, Ing. Etienne V. Depasquale wrote: I beg pardon...I should have included the following extract from my context.xml file (with placeholders for database, user and password): Realm className=org.apache.catalina.realm.JDBCRealm debug=99 driverName=org.gjt.mm.mysql.Driver Are you really using such an old driver - I've got an internet archaeologist friend who'll want to look at this... FWIW, that class name is still valid, even on recent versions of the driver library. That's not a valid value. The encoding, if I read the source correctly, should be UTF-8 or ISO-8859-1 or something similar. +1 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1C1WMACgkQ9CaO5/Lv0PC4NwCcCEBk4oO9KShLX2qRWT4ikOLf Gx8AnRURe8LuOqnl/pFAf/LV/ZqObRmO =iuYj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Valid values for digestEncoding attribute?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Etienne, On 1/28/2011 7:55 AM, Ing. Etienne V. Depasquale wrote: The real problem lies in the fact that Tomcat does not specify any digest algorithm in the www-authenticate header of HTTP/1.1, which leads the browser to digest the password using MD5, regardless of the value of the digest attribute in the Realm tag. You should definitely log a bug in bugzilla for that: Tomcat should be sending the digest algorithm to the client for DIGEST authentication. Be sure you use a protocol analyzer to ensure that the WWW-Authenticate header doesn't contain the digest. Otherwise, you'll waste your time filing the bug only to have it marked as INVALID. Also, always test with the most recent version in your version line (you didn't say which you were using). Current versions are Tomcat 7.0.6, 6.0.30, and 5.5.31: http://tomcat.apache.org/whichversion.html - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1C1igACgkQ9CaO5/Lv0PDSBwCcDWdYZhmI1EGrMyKFnZg5Hq+d iLAAoKTUilFEIuAG3J8wO1P2dmwwqtXh =BX+3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: java-process blocks cpu core to 100%
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: java-process blocks cpu core to 100% Warning: the NIO connector appears to be broken in 6.0.30 and looks like it will be in 6.0.31. Clarification: the NIO connector is quite usable in 6.0.31, but will likely produce numerous spurious log entries; 6.0.32 should get rid of those. - 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.
RE: SSL not working
Probably a server config issue, and not SSL. Please provide details of the new environment. -Original Message- From: spr...@gmx.eu [mailto:spr...@gmx.eu] Sent: Friday, January 28, 2011 7:06 AM To: 'Tomcat Users List' Subject: SSL not working Hi, I did it now so many times - it always worked - configuring tomcat for SSL. Today: New server, new certificate. Create new keystore, imported root, intermediate and server certificate, configured the connector, same as usual. But... http does not work. No error in tomcats log, nothing. Browser says that it cannot load the page due to a connection problem, maybe security issue. How can I debug this ssl problem? Connector SSLEnabled=true clientAuth=want maxThreads=150 port=8443 protocol=org.apache.coyote.http11.Http11NioProtocol scheme=https secure=true sslProtocol=TLS keystoreFile=conf/tomcat.jks keystoreType=JKS keyAlias=tomcat keystorePass=changeit / Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL not working
I've been fooling around *a lot* lately with SSL, so I thought I'd give this a try. I'm not very experienced, but I'll offer my two cents. First of all, what version of Tomcat, Java, etc. are you running? Such a statement is *de rigueur* for practically any question to this forum. My system looks like ** Server: SuSE 11.3 (2.6.34.7-0.7-desktop #1 SMP PREEMPT 2010-12-13 11:13:53 +0100 i686 i686 i386 GNU/Linux) ** Tomcat 6.0.30 ** Java: JRE 1.5.0_22 (though my keystore was self-generated with JDK 1.6.0_23) That said, the connector you describe is working for me, even when I intentionally misname my keyAlias. However I have only one entry in my keystore. I'm guessing that it can screw up if you have more than one and you give the wrong alias. You're using a JSSE implementation, correct? Run $ keytool -list -keystore $CATALINA_HOME/conf/keystore.jks -v and see what you get. (BTW, my self-generated openssl can be read with $ keytool -printcert -file /srv/apache2/conf/server.crt -v I say this only because I've also been fiddling, successfully, with the APR and mod_jk connector.) On Fri, Jan 28, 2011 at 8:06 AM, spr...@gmx.eu wrote: Hi, I did it now so many times - it always worked - configuring tomcat for SSL. Today: New server, new certificate. Create new keystore, imported root, intermediate and server certificate, configured the connector, same as usual. But... http does not work. No error in tomcats log, nothing. Browser says that it cannot load the page due to a connection problem, maybe security issue. How can I debug this ssl problem? Connector SSLEnabled=true clientAuth=want maxThreads=150 port=8443 protocol=org.apache.coyote.http11.Http11NioProtocol scheme=https secure=true sslProtocol=TLS keystoreFile=conf/tomcat.jks keystoreType=JKS keyAlias=tomcat keystorePass=changeit / Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Hell hath no limits, nor is circumscrib'd In one self-place; but where we are is hell, And where hell is, there must we ever be --Christopher Marlowe, *Doctor Faustus* (v, 121-24)
RE: SSL not working
Hi, it is TC 7.0.5, Java 1.6_22. When I use a selfsigned certificate everything is fine - same server config, just the other certificate. So it must be something wrong with the certificate. But I have no clue what. How can I debug the SSL-Handshake process? The cert not working has: #7: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth clientAuth ] #8: ObjectId: 2.16.840.1.113730.1.1 Criticality=false NetscapeCertType [ SSL client SSL server ] So it should be the right type of cert. Thank you -Original Message- From: Thad Humphries [mailto:thad.humphr...@gmail.com] Sent: Freitag, 28. Januar 2011 16:47 To: Tomcat Users List Subject: Re: SSL not working I've been fooling around *a lot* lately with SSL, so I thought I'd give this a try. I'm not very experienced, but I'll offer my two cents. First of all, what version of Tomcat, Java, etc. are you running? Such a statement is *de rigueur* for practically any question to this forum. My system looks like ** Server: SuSE 11.3 (2.6.34.7-0.7-desktop #1 SMP PREEMPT 2010-12-13 11:13:53 +0100 i686 i686 i386 GNU/Linux) ** Tomcat 6.0.30 ** Java: JRE 1.5.0_22 (though my keystore was self-generated with JDK 1.6.0_23) That said, the connector you describe is working for me, even when I intentionally misname my keyAlias. However I have only one entry in my keystore. I'm guessing that it can screw up if you have more than one and you give the wrong alias. You're using a JSSE implementation, correct? Run $ keytool -list -keystore $CATALINA_HOME/conf/keystore.jks -v and see what you get. (BTW, my self-generated openssl can be read with $ keytool -printcert -file /srv/apache2/conf/server.crt -v I say this only because I've also been fiddling, successfully, with the APR and mod_jk connector.) On Fri, Jan 28, 2011 at 8:06 AM, spr...@gmx.eu wrote: Hi, I did it now so many times - it always worked - configuring tomcat for SSL. Today: New server, new certificate. Create new keystore, imported root, intermediate and server certificate, configured the connector, same as usual. But... http does not work. No error in tomcats log, nothing. Browser says that it cannot load the page due to a connection problem, maybe security issue. How can I debug this ssl problem? Connector SSLEnabled=true clientAuth=want maxThreads=150 port=8443 protocol=org.apache.coyote.http11.Http11NioProtocol scheme=https secure=true sslProtocol=TLS keystoreFile=conf/tomcat.jks keystoreType=JKS keyAlias=tomcat keystorePass=changeit / Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Hell hath no limits, nor is circumscrib'd In one self-place; but where we are is hell, And where hell is, there must we ever be --Christopher Marlowe, *Doctor Faustus* (v, 121-24) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
deploying a war file and starting the application
Hello all, hope all of you are having a good day.. I have downloaded and configured Tomcat 7. All appears to be working. I have deployed a war file that currently works with WebSphere 7 and WebLogic 11g. The first issue I had was with url-pattern. It appears that Tomcat requires they start with a slash (/). I made the change and I no longer receive any errors while starting Tomcat. The following image shows the startup window and that my war is being deployed. Within the webapps directory a directory containing my webapp is created. [cid:image001.png@01CBBEEA.D5E12D40] My initial servlet is called InitServlet and it is marked as load-on-startup (please see following image) . [cid:image002.png@01CBBEEB.02716910] During startup of my servlet I generate log files and these logs files should appear in C:\Downloads\tomcat-7\apache-tomcat-7.0.6\webapps\allMATCHWeb\logs on my local disk. After Tomcat is started I am able to access the manager and admin applications. Also within my web.xml I have a welcome file setup (see image below) [cid:image003.png@01CBBEEB.59FBD760] I have two questions 1) If I type http://localhost:7080/allMATCHWeb in to a browser shouldn't see this login.html page? I don't... however I can access it by http://localhost:7080/allMATCHWeb/login.html 2) The load-on-start InitServlet class is not being executed as I have no logs generated or any other startup items handled, any ideas? I have reviewed the Tomcat logs and have not found any errors or warning messages indicating any issue with class loading, security access, etc. Thanks in advance for any help/assistance you may be able to provide. Bob Jenkin This mail was sent via Mail-SeCure System.
RE: SSL not working
OK, i enabled ssl-debug an got this:
Using SSLEngineImpl.
http-8443-exec-6, READ: TLSv1 Handshake, length = 72
*** ClientHello, TLSv1
RandomCookie: GMT: 1296237960 bytes = { 29, 26, 93, 201, 51, 195, 57, 220,
172, 159, 182, 24, 23, 109, 229, 241, 219, 44, 93, 9, 215, 107, 176, 92,
192, 250, 134, 108 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA,
SSL_RSA_EXPORT1024_WITH_RC4_56_SHA, SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA,
SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5,
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA,
SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA]
Compression Methods: { 0 }
Unsupported extension type_65281, data: 00
***
http-8443-exec-6, fatal error: 40: no cipher suites in common
javax.net.ssl.SSLHandshakeException: no cipher suites in common
http-8443-exec-6, SEND TLSv1 ALERT: fatal, description = handshake_failure
http-8443-exec-6, WRITE: TLSv1 Alert, length = 2
http-8443-exec-6, fatal: engine already closed. Rethrowing
javax.net.ssl.SSLHandshakeException: no cipher suites in common
http-8443-exec-6, called closeOutbound()
http-8443-exec-6, closeOutboundInternal()
Using SSLEngineImpl.
http-8443-exec-7, READ: SSLv3 Handshake, length = 67
*** ClientHello, SSLv3
RandomCookie: GMT: 1296237960 bytes = { 167, 41, 66, 68, 100, 105, 126,
191, 190, 109, 143, 141, 122, 89, 201, 33, 1, 45, 228, 214, 141, 218, 73,
253, 8, 9, 118, 204 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA,
SSL_RSA_EXPORT1024_WITH_RC4_56_SHA, SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA,
SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5,
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA,
SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA, Unknown 0x0:0xff]
Compression Methods: { 0 }
***
http-8443-exec-7, fatal error: 40: no cipher suites in common
javax.net.ssl.SSLHandshakeException: no cipher suites in common
http-8443-exec-7, SEND SSLv3 ALERT: fatal, description = handshake_failure
http-8443-exec-7, WRITE: SSLv3 Alert, length = 2
http-8443-exec-7, fatal: engine already closed. Rethrowing
javax.net.ssl.SSLHandshakeException: no cipher suites in common
http-8443-exec-7, called closeOutbound()
http-8443-exec-7, closeOutboundInternal()
Using SSLEngineImpl.
http-8443-exec-8, called closeOutbound()
http-8443-exec-8, closeOutboundInternal()
http-8443-exec-8, SEND TLSv1 ALERT: warning, description = close_notify
http-8443-exec-8, WRITE: TLSv1 Alert, length = 2
When I open the cert I can see:
MD5: 3C:33:0A:7C:BC:8B:8D:9E:A5:C1:8C:49:F9:E1:84:0A
SHA1: 7F:02:49:61:4E:55:AE:11:F0:93:82:06:8A:44:95:56:2D:1E:0E:EB
Unterschrift-Algorithmusname: SHA1withRSA
Version: 3
So is my java runtime mising SHA1withRSA?
-Original Message-
From: spr...@gmx.eu [mailto:spr...@gmx.eu]
Sent: Freitag, 28. Januar 2011 18:35
To: 'Tomcat Users List'
Subject: RE: SSL not working
Hi,
it is TC 7.0.5, Java 1.6_22.
When I use a selfsigned certificate everything is fine - same
server config, just the other certificate. So it must be
something wrong with the certificate. But I have no clue what.
How can I debug the SSL-Handshake process?
The cert not working has:
#7: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
serverAuth
clientAuth
]
#8: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
SSL client
SSL server
]
So it should be the right type of cert.
Thank you
-Original Message-
From: Thad Humphries [mailto:thad.humphr...@gmail.com]
Sent: Freitag, 28. Januar 2011 16:47
To: Tomcat Users List
Subject: Re: SSL not working
I've been fooling around *a lot* lately with SSL, so I
thought I'd give this
a try. I'm not very experienced, but I'll offer my two cents.
First of all, what version of Tomcat, Java, etc. are you
running? Such a
statement is *de rigueur* for practically any question to
this forum. My
system looks like
** Server: SuSE 11.3 (2.6.34.7-0.7-desktop #1 SMP PREEMPT 2010-12-13
11:13:53 +0100 i686 i686 i386 GNU/Linux)
** Tomcat 6.0.30
** Java: JRE 1.5.0_22 (though my keystore was
self-generated with JDK
1.6.0_23)
That said, the connector you describe is working for me, even when I
intentionally misname my keyAlias. However I have only one
entry in my
keystore. I'm guessing that it can screw up if you have more
than one and
you give the wrong alias.
You're using a JSSE implementation, correct? Run
$ keytool -list -keystore $CATALINA_HOME/conf/keystore.jks -v
and see what you get.
(BTW, my self-generated openssl can be read with
$ keytool -printcert -file /srv/apache2/conf/server.crt -v
I say this only because I've also been fiddling,
successfully, with the APR
and mod_jk
RE: Pid OpenSSO request for Tomcat Form Authentication that requires no password for third party SSO
@Pid: The SSo third party app knows the SSO entry point into my Tomcat app. I am supplied an encrypted token which contains the username and my tomcat app has the libraries to unencrypt that token and unveil the username @Andre: Ideally it would seem most convenient to access j_security_check with a valid j_username and a j_password with a blank value, so then the tomcat container would generate the proper principal and roles information. I want to be able to use request.getRemoteUser() and request.isUserInRole(String role). It would seem that I can extend AuthenticatorBase and mimic everything that FormAuthenticator does except for the password query part. Or I can use a hack for the DataSourceRealm and use my UserName column for both the userCredCol and userNameCol values. Therefore no password to check for. Beau -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Friday, January 28, 2011 6:36 AM To: Tomcat Users List Subject: Re: Pid OpenSSO request for Tomcat Form Authentication that requires no password for third party SSO Pid wrote: On 1/27/11 3:57 PM, beau.hutche...@thomsonreuters.com wrote: Chris: Thanks for your reply. Currently I am using Tomcat 6.0.29 @Pid: Would you have any ideas on how to set something up like this? What details are you providing to Tomcat? If I read the thread correctly you've got a single parameter - how are you validating that to stop say, me, guessing at logins? That's easy, as long as Tomcat accepts only connections from a source known to go through the aforementioned SSO. I have a similar setup at one of my customers. This is only an example : All users use a session on a specific Windows Terminal Server. In that session, they open a browser, which allows them to connect to Tomcat (*). Tomcat accepts only connections from the IP's of the Terminal Server. On the Terminal Server runs that nifty SSO mechanism which I mentioned in another message here. Somehow, that SSO detects the login page which the Tomcat authentication is sending back to the browser, fills-in the userid (**), and re-posts the login form to the server. The user is now logged-in and gets the application page. The user does not see anything. I know that it sounds a bit strange when one explains it like that, but it works. (**) the user-id being sent is the user's Windows Domain user-id, which has already been authenticated/verified, so it can be trusted. There is thus no need to verify it again in Tomcat. (*) Ok, I'm cheating : in my case, it is not Tomcat directly, but it is an Apache httpd front-ending for Tomcat, and connecting to it via mod_jk. mod_jk will pass on the httpd-level user-id, and Tomcat (with the 'tomcatAuthentication=false attribute on the AJP Connector), will accept that user-id as its own. At the Tomcat level, you would still have to do the isUserInRole part though. Now the question is : assuming that there is no httpd front-end and no mod_jk, can a similar mechanism work with Tomcat directly ? In other words, can the standard Tomcat form-based authentication work, if the login form is sent back with a non-blank userid, but with a blank password ? And could this authentication code be easily tweaked to bypass any verification of the received user-id ? And, to the original poster : apologies for somewhat hijacking your thread, but I am just trying to help finding the best method for you. I have a feeling that for this case, having to create a brand-new Authenticator is a bit heavy as a solution. It seems that it should be possible to at least crate some null Realm which always accepts any user-id and always returns OK. Or use whatever mechanism mod_jk is using to the same basic effect. - 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
secure TLS renegotiation
Hello, Does Tomcat support the so called secure TLS renegotiation? If so, what should I configure to use it? Currently when connecting to my application using secure connection most browsers complain about my server software being very old and insecure because of the lack of this feature. I'm using Tomcat 6.0.29 on linux/freebsd. Thanks, Olaf
Re: secure TLS renegotiation
On 28/01/2011 19:00, Olaf Tomczak wrote: Hello, Does Tomcat support the so called secure TLS renegotiation? If so, what should I configure to use it? Currently when connecting to my application using secure connection most browsers complain about my server software being very old and insecure because of the lack of this feature. I'm using Tomcat 6.0.29 on linux/freebsd. Yes, if the JVM supports it. You'll probably need to enable Tomcat's allowLegacyRegenotiation feature else Tomcat will block all renegotiation. That needs a rename to allowRenegotiation in light of how Oracle decided to fix this. Unfortunately Oracle went for system wide system properties rather than providing an API to let folks control it per socket or connection. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Help needed on apache tomcat 7.0
hi, Actually, i am trying to include jar file in apache tomcat server so that i can access the classes of the jar file to use it in my jsp pages (web application). How can i do this ? Any help would be appreciated. Regards, Anup Niroula
Re: secure TLS renegotiation
Mark, 2011/1/28 Mark Thomas ma...@apache.org On 28/01/2011 19:00, Olaf Tomczak wrote: Hello, Does Tomcat support the so called secure TLS renegotiation? If so, what should I configure to use it? Currently when connecting to my application using secure connection most browsers complain about my server software being very old and insecure because of the lack of this feature. I'm using Tomcat 6.0.29 on linux/freebsd. Yes, if the JVM supports it. You'll probably need to enable Tomcat's allowLegacyRegenotiation feature else Tomcat will block all renegotiation. I googled allowLegacyRenegotiation and found this article: http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html It describes the following 2 system properties: sun.security.ssl.allowUnsafeRenegotiation - Introduced in Phase 1, this controls whether legacy (unsafe) renegotiations are permitted. sun.security.ssl.allowLegacyHelloMessages - Introduced in Phase 2, this allows the peer to handshake without requiring the proper RFC 5746 messages. Are these what you meant? Thanks for your help, Olaf That needs a rename to allowRenegotiation in light of how Oracle decided to fix this. Unfortunately Oracle went for system wide system properties rather than providing an API to let folks control it per socket or connection. 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: Help needed on apache tomcat 7.0
From: Anup Niroula [mailto:anup.niro...@gmail.com] Subject: Help needed on apache tomcat 7.0 Actually, i am trying to include jar file in apache tomcat server so that i can access the classes of the jar file to use it in my jsp pages (web application). How can i do this ? Long answer: read the servlet spec; it details exactly what the structure of a webapp is, including where to place jar files for the webapp. Short answer: in your webapp's WEB-INF/lib directory. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java-process blocks cpu core to 100%
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 1/28/2011 10:34 AM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: java-process blocks cpu core to 100% Warning: the NIO connector appears to be broken in 6.0.30 and looks like it will be in 6.0.31. Clarification: the NIO connector is quite usable in 6.0.31, but will likely produce numerous spurious log entries; 6.0.32 should get rid of those. Thanks for the clarification: I hadn't read Konstantin's comments on the subject until after I wrote my reply. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DHggACgkQ9CaO5/Lv0PAa1wCglsfJVrTpXU/oE8tKrxbzYNtf Qy4AnAgWfs9Xhgr1Ol/c6sy/wdK34nNO =ItQn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: deploying a war file and starting the application
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert, On 1/28/2011 1:09 PM, robert.jen...@surecomp.com wrote: I have downloaded and configured Tomcat 7. All appears to be working. Glad to hear it! I have deployed a war file that currently works with WebSphere 7 and WebLogic 11g. The first issue I had was with url-pattern. It appears that Tomcat requires they start with a slash (/). I made the change and I no longer receive any errors while starting Tomcat. This is a spec requirement, not a Tomcat requirement. Other containers may be more lenient. The following image shows the startup window and that my war is being deployed. Within the webapps directory a directory containing my webapp is created. Images are stripped from posts to the list. Can you post it somewhere online and give us a link? Or, just copy/paste any relevant content from your screen? My initial servlet is called InitServlet and it is marked as load-on-startup (please see following image) . Ditto. I have two questions 1) If I type http://localhost:7080/allMATCHWeb in to a browser shouldn’t see this login.html page? I don’t… however I can access it by http://localhost:7080/allMATCHWeb/login.html You'll have to provide your web.xml for us to know when you need authentication challenges. Are you using container-managed authentication? 2) The load-on-start InitServlet class is not being executed as I have no logs generated or any other startup items handled, any ideas? Again, including web.xml should help. Note that using an InitServlet hasn't been recommended since the addition of the ServletContextListener interface a long time ago. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DHsYACgkQ9CaO5/Lv0PBhSQCeNtR93FGfQecpwJ/n02ioUhpP x2MAn2WmpQ0vzJ3YAbrMQrE9SnMmOq++ =WYyb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: secure TLS renegotiation
On 28/01/2011 19:29, Olaf Tomczak wrote: Mark, 2011/1/28 Mark Thomas ma...@apache.org On 28/01/2011 19:00, Olaf Tomczak wrote: Hello, Does Tomcat support the so called secure TLS renegotiation? If so, what should I configure to use it? Currently when connecting to my application using secure connection most browsers complain about my server software being very old and insecure because of the lack of this feature. I'm using Tomcat 6.0.29 on linux/freebsd. Yes, if the JVM supports it. You'll probably need to enable Tomcat's allowLegacyRegenotiation feature else Tomcat will block all renegotiation. I googled allowLegacyRenegotiation and found this article: http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html It describes the following 2 system properties: sun.security.ssl.allowUnsafeRenegotiation - Introduced in Phase 1, this controls whether legacy (unsafe) renegotiations are permitted. sun.security.ssl.allowLegacyHelloMessages - Introduced in Phase 2, this allows the peer to handshake without requiring the proper RFC 5746 messages. Are these what you meant? That is what I meant for the Oracle part. You'll need to look at the Tomcat configuration docs for HTTP connector for allowLegacyRenegotiation Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: deploying a war file and starting the application
Christopher,
Thanks for your assistance.
Here is my web.xml
?xml version='1.0' encoding='UTF-8'?
web-app xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=2.5
id=web-app_1
display-nameallMATCHWeb/display-name
servlet
servlet-nameInitServlet/servlet-name
servlet-classcom.surecomp.allMATCH.client.InitServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
servlet-mapping
servlet-nameInitServlet/servlet-name
url-pattern/InitServlet/url-pattern
/servlet-mapping
welcome-file-list
welcome-file/login.html/welcome-file
/welcome-file-list
/web-app
This is the InitServlet class declaration
public class InitServlet extends javax.servlet.http.HttpServlet
implements javax.servlet.Servlet, Internationalizable
This is the start of init() method
public void init() throws ServletException {
synchronized (this) {
if (initialized || initializing) return;
initializing = true;
}
logger = new Logging();
contextPath = getServletContext().getRealPath(/);
contextPath = getPathWithSeparator(contextPath);
oLoaderStatic = new LoaderStatic();
try {
String sLogging = Configuration.getLogging();
Date date = new Date();
SimpleDateFormat formatter = new SimpleDateFormat(MMdd);
logger.setapplicationSegment(allMATCHWeb);
logger.setSite(Logging.Client);
logger.LogSetup(Configuration.getLoggingLocation().concat(//allMATCHWeb_ +
formatter.format(date) + .log),sLogging);
logger.log(Configuration loaded from the file:
[+Configuration.getPropertiesLocation()+]);
} catch (Throwable th) {
th.printStackTrace();
System.out.println(Error initializing logger.);
try {
logger.log(Error initializing logger.,th);
logger.close();
}
catch (Throwable t) {}
return;
}
Again, thanks for any insight or assistance...
Sincerely,
Robert Jenkin
Surecomp Services, Inc.
2 Hudson Place, 4th Floor
Hoboken, NJ 07030
Skype: robert.jenkin
Office: 201 217 1437 | Direct: 201 716 1219 | Mobile: 908 251 0537
http://www.Surecomp.com
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, January 28, 2011 2:54 PM
To: Tomcat Users List
Subject: Re: deploying a war file and starting the application
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert,
On 1/28/2011 1:09 PM, robert.jen...@surecomp.com wrote:
I have downloaded and configured Tomcat 7. All appears to be working.
Glad to hear it!
I have deployed a war file that currently works with WebSphere 7 and
WebLogic 11g.
The first issue I had was with url-pattern. It appears that Tomcat
requires they start with a slash (/). I made the change and I no longer
receive any errors while starting Tomcat.
This is a spec requirement, not a Tomcat requirement. Other containers
may be more lenient.
The following image shows the startup window and that my war is being
deployed. Within the webapps directory a directory containing my webapp
is created.
Images are stripped from posts to the list. Can you post it somewhere
online and give us a link? Or, just copy/paste any relevant content from
your screen?
My initial servlet is called InitServlet and it is marked as
load-on-startup (please see following image) .
Ditto.
I have two questions
1) If I type http://localhost:7080/allMATCHWeb in to a browser
shouldn’t see this login.html page? I don’t… however I can access it by
http://localhost:7080/allMATCHWeb/login.html
You'll have to provide your web.xml for us to know when you need
authentication challenges. Are you using container-managed authentication?
2) The load-on-start InitServlet class is not being executed as I
have no logs generated or any other startup items handled, any ideas?
Again, including web.xml should help. Note that using an InitServlet
hasn't been recommended since the addition of the ServletContextListener
interface a long time ago.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1DHsYACgkQ9CaO5/Lv0PBhSQCeNtR93FGfQecpwJ/n02ioUhpP
x2MAn2WmpQ0vzJ3YAbrMQrE9SnMmOq++
=WYyb
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
This mail was sent via Mail-SeCure System.
Re: deploying a war file and starting the application
On 28/01/2011 20:03, robert.jen...@surecomp.com wrote:
Christopher,
Thanks for your assistance.
Here is my web.xml
?xml version='1.0' encoding='UTF-8'?
web-app xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=2.5
id=web-app_1
That does not look quite right to me. I'd normally expect to see the
following:
web-app xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
version=2.5
Tomcat is usually pretty tolerant of that sort of thing but worth
checking anyway.
display-nameallMATCHWeb/display-name
servlet
servlet-nameInitServlet/servlet-name
servlet-classcom.surecomp.allMATCH.client.InitServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
servlet-mapping
servlet-nameInitServlet/servlet-name
url-pattern/InitServlet/url-pattern
/servlet-mapping
That looks OK. Not the recommended way to do things, but it should work.
welcome-file-list
welcome-file/login.html/welcome-file
As per the Servlet specification, welcome files should not have leading
'/' characters.
/welcome-file-list
/web-app
This is the InitServlet class declaration
public class InitServlet extends javax.servlet.http.HttpServlet
implements javax.servlet.Servlet, Internationalizable
This is the start of init() method
public void init() throws ServletException {
synchronized (this) {
if (initialized || initializing) return;
initializing = true;
}
logger = new Logging();
contextPath = getServletContext().getRealPath(/);
getRealPath() is not guaranteed to return a file system path. Also
writing log files inside the web app is usually a bad idea since you
lose the logs when the app is undeployed.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help needed on apache tomcat 7.0
Hi, Thank you for the reply. I am new to JSP and i am using tomcat server 7.0 for the first time. could you please tell me where can i find examples of web applications importing classes from jar file ? On Fri, Jan 28, 2011 at 1:46 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Anup Niroula [mailto:anup.niro...@gmail.com] Subject: Help needed on apache tomcat 7.0 Actually, i am trying to include jar file in apache tomcat server so that i can access the classes of the jar file to use it in my jsp pages (web application). How can i do this ? Long answer: read the servlet spec; it details exactly what the structure of a webapp is, including where to place jar files for the webapp. Short answer: in your webapp's WEB-INF/lib directory. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Help needed on apache tomcat 7.0
From: Anup Niroula [mailto:anup.niro...@gmail.com] Subject: Re: Help needed on apache tomcat 7.0 could you please tell me where can i find examples of web applications importing classes from jar file ? In several of the example webapps that come with the Tomcat distribution. Look in webapps/examples. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help needed on apache tomcat 7.0
Thanx On Fri, Jan 28, 2011 at 2:21 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Anup Niroula [mailto:anup.niro...@gmail.com] Subject: Re: Help needed on apache tomcat 7.0 could you please tell me where can i find examples of web applications importing classes from jar file ? In several of the example webapps that come with the Tomcat distribution. Look in webapps/examples. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: deploying a war file and starting the application
Mark,
That’s for input.. the initservlet is just a means to initialize the
application. The writing of a log file is not to a directory within tomcat. It
is a directory outside of the environment. This information (the directory
location) is supplied via property file. Which I doubt is being loaded.
Sincerely,
Robert Jenkin
Surecomp Services, Inc.
2 Hudson Place, 4th Floor
Hoboken, NJ 07030
Skype: robert.jenkin
Office: 201 217 1437 | Direct: 201 716 1219 | Mobile: 908 251 0537
http://www.Surecomp.com
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Friday, January 28, 2011 3:13 PM
To: Tomcat Users List
Subject: Re: deploying a war file and starting the application
On 28/01/2011 20:03, robert.jen...@surecomp.com wrote:
Christopher,
Thanks for your assistance.
Here is my web.xml
?xml version='1.0' encoding='UTF-8'?
web-app xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=2.5
id=web-app_1
That does not look quite right to me. I'd normally expect to see the
following:
web-app xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
version=2.5
Tomcat is usually pretty tolerant of that sort of thing but worth
checking anyway.
display-nameallMATCHWeb/display-name
servlet
servlet-nameInitServlet/servlet-name
servlet-classcom.surecomp.allMATCH.client.InitServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
servlet-mapping
servlet-nameInitServlet/servlet-name
url-pattern/InitServlet/url-pattern
/servlet-mapping
That looks OK. Not the recommended way to do things, but it should work.
welcome-file-list
welcome-file/login.html/welcome-file
As per the Servlet specification, welcome files should not have leading
'/' characters.
/welcome-file-list
/web-app
This is the InitServlet class declaration
public class InitServlet extends javax.servlet.http.HttpServlet
implements javax.servlet.Servlet, Internationalizable
This is the start of init() method
public void init() throws ServletException {
synchronized (this) {
if (initialized || initializing) return;
initializing = true;
}
logger = new Logging();
contextPath = getServletContext().getRealPath(/);
getRealPath() is not guaranteed to return a file system path. Also
writing log files inside the web app is usually a bad idea since you
lose the logs when the app is undeployed.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
This mail was sent via Mail-SeCure System.
RE: deploying a war file and starting the application
Mark,
I made the change regarding web-app in the web.xml and same results. The piece
I find most interesting is the lack of information. If tomcat is not able to
load my class (initservlet) or an error has occurred in the class I would
expect some type of logging indicating an error.
Sincerely,
Robert Jenkin
Surecomp Services, Inc.
2 Hudson Place, 4th Floor
Hoboken, NJ 07030
Skype: robert.jenkin
Office: 201 217 1437 | Direct: 201 716 1219 | Mobile: 908 251 0537
http://www.Surecomp.com
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Friday, January 28, 2011 3:13 PM
To: Tomcat Users List
Subject: Re: deploying a war file and starting the application
On 28/01/2011 20:03, robert.jen...@surecomp.com wrote:
Christopher,
Thanks for your assistance.
Here is my web.xml
?xml version='1.0' encoding='UTF-8'?
web-app xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=2.5
id=web-app_1
That does not look quite right to me. I'd normally expect to see the
following:
web-app xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
version=2.5
Tomcat is usually pretty tolerant of that sort of thing but worth
checking anyway.
display-nameallMATCHWeb/display-name
servlet
servlet-nameInitServlet/servlet-name
servlet-classcom.surecomp.allMATCH.client.InitServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
servlet-mapping
servlet-nameInitServlet/servlet-name
url-pattern/InitServlet/url-pattern
/servlet-mapping
That looks OK. Not the recommended way to do things, but it should work.
welcome-file-list
welcome-file/login.html/welcome-file
As per the Servlet specification, welcome files should not have leading
'/' characters.
/welcome-file-list
/web-app
This is the InitServlet class declaration
public class InitServlet extends javax.servlet.http.HttpServlet
implements javax.servlet.Servlet, Internationalizable
This is the start of init() method
public void init() throws ServletException {
synchronized (this) {
if (initialized || initializing) return;
initializing = true;
}
logger = new Logging();
contextPath = getServletContext().getRealPath(/);
getRealPath() is not guaranteed to return a file system path. Also
writing log files inside the web app is usually a bad idea since you
lose the logs when the app is undeployed.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
This mail was sent via Mail-SeCure System.
RE: deploying a war file and starting the application
From: robert.jen...@surecomp.com [mailto:robert.jen...@surecomp.com] Subject: RE: deploying a war file and starting the application the initservlet is just a means to initialize the application. Which, as Chris S noted earlier, should be done by a ServletContextListener, not a servlet. The writing of a log file is not to a directory within tomcat. That's good. Why do you have a reference to ServletContext#getRealPath()? That's very, very risky. - 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.
RE: deploying a war file and starting the application
From: Caldarale, Charles R Subject: RE: deploying a war file and starting the application The writing of a log file is not to a directory within tomcat. On rereading your original message, the above statement does not appear to be operative: During startup of my servlet I generate log files and these logs files should appear in C:\Downloads\tomcat-7\apache-tomcat-7.0.6\webapps\allMATCHWeb\logs on my local disk. Which should we believe? - 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.
war app, Tomcat, public IP and port 8080 - remote access
Hello I'm using tomcat 6.0.29, Sun Java JRE 1.6.0_21 and OS is CentOS 5.5 and I'm runnning (localhost) a war OK, through the port 8080. I have recently gotten a Public IP (eg 10.10.1.38) and I can also use my app with no problems locally and within a LAN through the same port (eg 10.10.1.38:8080/myApp); the problem comes when I try to access it from outside, if I type the Public IP 10.10.1.30 I know I reach it as I have a very simple html on my server and I can see it (ping also works OK), but then, when follow to type :8080/myAPP I don't have any luck; however, if I just type 10.10.1.38:8080I can see the tomcat first page (but again when I try to go to the manager page - for instance -, I have no luck. I have also checked if this port is opened, through iptables and a firewall GUI, and there was no rule or exception, but I explicitily add it to be opened. I also opened this port on my router (thomson TG585 v7). I suspect there is something missing in the server.xml which I have not modified since I installed tomcat. Here's my server.xml in case you guys need to take a look at it http://fpaste.org/kNwe/ Any guidance will be appreciated. Thanks -- Amílcar de León Think Freely http://www.antigualug.org
RE: deploying a war file and starting the application
From: robert.jen...@surecomp.com [mailto:robert.jen...@surecomp.com] Subject: RE: deploying a war file and starting the application If tomcat is not able to load my class (initservlet) or an error has occurred in the class I would expect some type of logging indicating an error. Make sure you look in _all_ the of the Tomcat-generated log files, not where you think you're writing logs for the webapp of interest. - 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.
RE: deploying a war file and starting the application
Chuck, I understand the ServletConextListener and will investigate the recommendation to see if ServletConextListener is compatible with WebSphere 7 and WebLogic 11g as well and if it is I will make the change. I make reference to getRealPath to load a property file. I have not had issue with this in other environments, not to say this is not a bad thing to do. Sincerely, Robert Jenkin Surecomp Services, Inc. 2 Hudson Place, 4th Floor Hoboken, NJ 07030 Skype: robert.jenkin Office: 201 217 1437 | Direct: 201 716 1219 | Mobile: 908 251 0537 http://www.Surecomp.com -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Friday, January 28, 2011 3:36 PM To: Tomcat Users List Subject: RE: deploying a war file and starting the application From: robert.jen...@surecomp.com [mailto:robert.jen...@surecomp.com] Subject: RE: deploying a war file and starting the application the initservlet is just a means to initialize the application. Which, as Chris S noted earlier, should be done by a ServletContextListener, not a servlet. The writing of a log file is not to a directory within tomcat. That's good. Why do you have a reference to ServletContext#getRealPath()? That's very, very risky. - 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. This mail was sent via Mail-SeCure System.
RE: deploying a war file and starting the application
From: robert.jen...@surecomp.com [mailto:robert.jen...@surecomp.com] Subject: RE: deploying a war file and starting the application I make reference to getRealPath to load a property file. It's definitely a bad thing to do. You should be using ServletContext#getResourceAsStream(). That will let your code avoid the assumption that there even is an underlying file system (nothing in the servlet spec requires it), or, if it exists, that the container will allow you to access the file system (the servlet spec only requires that the container provide access to a temporary work area). - 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.
Re: deploying a war file and starting the application
On 28/01/2011 20:54, Caldarale, Charles R wrote: From: robert.jen...@surecomp.com [mailto:robert.jen...@surecomp.com] Subject: RE: deploying a war file and starting the application I make reference to getRealPath to load a property file. It's definitely a bad thing to do. You should be using ServletContext#getResourceAsStream(). +1. That will also mean you app will work (well, that part of it at least) as an exploded directory or as a WAR file. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: deploying a war file and starting the application
I understand the issues and recommendations being made. But, possibly a little
more detail in the app is needed.
The web pages provided with the app are static and created in English. Upon
starting the web app new pages are created that are language based. When
deployed the war is always exploded so that access to the scripts, styles,
pages, etc. is available to the web app to make new ones and or modify existing
ones.
Data for the web pages is provided by means of web services where the client
browser IE/Firefox makes calls to web services for data (loading/saving) and
business logic.
Currently the same WAR produced by Ant build script is used in Websphere 7 and
WebLogic 11g without issue or modifications needed.
We have a customer that has asked me to support Tomcat (assume the cost of
Webshere/Weblogic is an issue).
Having provide a brief description of system. I have tried the following.
I have modified the InitServlet class (removed everything). The following is
the complete code of InitServlet
package com.surecomp.allMATCH.client;
import javax.servlet.ServletException;
import javax.servlet.ServletInputStream;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class InitServlet extends javax.servlet.http.HttpServlet implements
javax.servlet.Servlet {
public void destroy() {
}
public void init() throws ServletException {
System.out.println(Loaded);
}
}
I have compiled it and placed the class file into
C:\Downloads\tomcat-7\apache-tomcat-7.0.6\webapps\allMATCHWeb\WEB-INF\classes\com\surecomp\allMATCH\client
and I expected to see the System.out.println either on the screen or in some
log file. I do not see it anywhere.
Sincerely,
Robert Jenkin
Surecomp Services, Inc.
2 Hudson Place, 4th Floor
Hoboken, NJ 07030
Skype: robert.jenkin
Office: 201 217 1437 | Direct: 201 716 1219 | Mobile: 908 251 0537
http://www.Surecomp.com
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Friday, January 28, 2011 4:00 PM
To: Tomcat Users List
Subject: Re: deploying a war file and starting the application
On 28/01/2011 20:54, Caldarale, Charles R wrote:
From: robert.jen...@surecomp.com [mailto:robert.jen...@surecomp.com]
Subject: RE: deploying a war file and starting the application
I make reference to getRealPath to load a property file.
It's definitely a bad thing to do. You should be using
ServletContext#getResourceAsStream().
+1. That will also mean you app will work (well, that part of it at
least) as an exploded directory or as a WAR file.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
This mail was sent via Mail-SeCure System.
Re: deploying a war file and starting the application
On 28/01/2011 21:12, robert.jen...@surecomp.com wrote:
I have modified the InitServlet class (removed everything). The following is
the complete code of InitServlet
package com.surecomp.allMATCH.client;
import javax.servlet.ServletException;
import javax.servlet.ServletInputStream;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class InitServlet extends javax.servlet.http.HttpServlet implements
javax.servlet.Servlet {
public void destroy() {
}
public void init() throws ServletException {
System.out.println(Loaded);
}
}
I have compiled it and placed the class file into
C:\Downloads\tomcat-7\apache-tomcat-7.0.6\webapps\allMATCHWeb\WEB-INF\classes\com\surecomp\allMATCH\client
and I expected to see the System.out.println either on the screen or in some
log file. I do not see it anywhere.
web.xml is located where?
What is in the Tomcat log files?
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: deploying a war file and starting the application
The following is the directory layout C:\Downloads\tomcat-7\apache-tomcat-7.0.6 - root bin conf lib logs temp webapps allMATCHWeb documents images lib logs META-INFO output pages scripts WEB-INF classes lib web.xml xsl login.html docs examples host-manager ROOT Work This is the content of the web.xml ?xml version='1.0' encoding='UTF-8'? web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; version=2.5 display-nameallMATCHWeb/display-name servlet servlet-nameInitServlet/servlet-name servlet-classcom.surecomp.allMATCH.client.InitServlet/servlet-class load-on-startup1/load-on-startup /servlet servlet-mapping servlet-nameInitServlet/servlet-name url-pattern/InitServlet/url-pattern /servlet-mapping welcome-file-list welcome-filelogin.html/welcome-file /welcome-file-list /web-app The log files produced by Tomcat contain the following catalina.2011-01-28.log contains Jan 28, 2011 4:22:35 PM org.apache.catalina.core.AprLifecycleListener init INFO: Loaded APR based Apache Tomcat Native library 1.1.20. Jan 28, 2011 4:22:35 PM org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. Jan 28, 2011 4:22:36 PM org.apache.coyote.AbstractProtocolHandler init INFO: Initializing ProtocolHandler [http-apr-7080] Jan 28, 2011 4:22:36 PM org.apache.coyote.AbstractProtocolHandler init INFO: Initializing ProtocolHandler [ajp-apr-7009] Jan 28, 2011 4:22:36 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 1413 ms Jan 28, 2011 4:22:36 PM org.apache.catalina.core.StandardService startInternal INFO: Starting service Catalina Jan 28, 2011 4:22:36 PM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/7.0.6 Jan 28, 2011 4:22:36 PM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive allMATCHWeb.war Jan 28, 2011 4:22:53 PM org.apache.catalina.startup.TaglibUriRule body INFO: TLD skipped. URI: http://www.businessobjects.com/jsf/crystalreportsviewers is already defined Jan 28, 2011 4:22:53 PM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory docs Jan 28, 2011 4:22:54 PM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory examples Jan 28, 2011 4:22:54 PM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory host-manager Jan 28, 2011 4:22:54 PM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory manager Jan 28, 2011 4:22:54 PM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory ROOT Jan 28, 2011 4:22:54 PM org.apache.coyote.AbstractProtocolHandler start INFO: Starting ProtocolHandler [http-apr-7080] Jan 28, 2011 4:22:54 PM org.apache.coyote.AbstractProtocolHandler start INFO: Starting ProtocolHandler [ajp-apr-7009] Jan 28, 2011 4:22:54 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 18243 ms Host-manager.2011-01-28.log contains Jan 28, 2011 4:22:54 PM org.apache.catalina.core.StandardContext listenerStart FINE: Sending application start events Jan 28, 2011 4:22:54 PM org.apache.catalina.core.StandardContext filterStart FINE: Starting filters Jan 28, 2011 4:22:54 PM org.apache.catalina.core.StandardContext filterStart FINE: Starting filter 'CSRF' Localhost.2011-01-28.log contains Jan 28, 2011 4:22:53 PM org.apache.catalina.core.StandardContext listenerStart FINE: Sending application start events Jan 28, 2011 4:22:53 PM org.apache.catalina.core.StandardContext filterStart FINE: Starting filters Jan 28, 2011 4:22:54 PM org.apache.catalina.core.StandardContext listenerStart FINE: Sending application start events Jan 28, 2011 4:22:54 PM org.apache.catalina.core.StandardContext filterStart FINE: Starting filters Jan 28, 2011 4:22:54 PM org.apache.catalina.core.StandardContext listenerStart FINE: Configuring event listener class 'listeners.ContextListener' Jan 28, 2011 4:22:54 PM org.apache.catalina.core.StandardContext listenerStart FINE: Configuring event listener class 'listeners.SessionListener' Jan 28, 2011 4:22:54 PM org.apache.catalina.core.StandardContext listenerStart
RE: war app, Tomcat, public IP and port 8080 - remote access
From: Amilcar De Leon [mailto:ada...@antigualug.org] Subject: war app, Tomcat, public IP and port 8080 - remote access I have recently gotten a Public IP (eg 10.10.1.38) There's either a misconception or a terminology problem here: 10.x.x.x is *not* a public IP address; rather, it's one of the three ranges specifically reserved as /private/ IP addresses. the problem comes when I try to access it from outside What does outside mean in this context? when follow to type :8080/myAPP I don't have any luck; I don't recall any Tomcat or browser error message saying you have no luck; what _exactly_ happens? but again when I try to go to the manager page - for instance -, I have no luck. There's that no luck HTTP status again; I don't recall ever seeing that in the RFCs. Also, exactly what URL are you trying? There's no Tomcat URL that includes the phrase manager page; be precise. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: war app, Tomcat, public IP and port 8080 - remote access
I have my server configured with a static public IP like 211.210.19.11 (this is not my real one if you ask). There is another static public IP that came with the routher which is the same than the above, except for the last numer (eg 211.210.19.10). I'm giving this as I don't know if you'd need this info too. So, on my server, if I type, 211.210.19.11:8080/myAPP I can run my app OK. The same if I try from another computer within the same LAN (connected to the same router). When I try to access that same address from another computer out of the LAN (eg an internet coffee), I get the error connection time out. But if I only type 211.210.19.11:8080 I can see a page that says I'm sucessfully installed tomcat and links to the tomcat manager, tomcat documentation and others. An extra note, the first page of my app is a login page, and I can see it if I use the firefox addon calle Go2proxy, but then when I type the login info I gen again the connection time out error. Not sure if this is useful -- Amílcar de León Think Freely http://www.antigualug.org
RE: deploying a war file and starting the application
Well after playing with web.xml I got my app up and partly working in Tomcat 7. When I go to http://localhost:7080/allMATCHWeb the default page is loaded. My properties file is loaded and language based webpages generated, etc. Now my issue seems to be with web services. Again the web.xml contains the following for each webservice. servlet servlet-nameMessageServiceServlethttp/servlet-name servlet-classcom.surecomp.allMATCH.client.webservices.MessageService/servlet-class load-on-startup0/load-on-startup /servlet servlet-mapping servlet-nameMessageServiceServlethttp/servlet-name url-patternMessageService/url-pattern /servlet-mapping Now, these work for webshpere and weblogic, so I am assuming (bad thing I know) that the same would work for Tomcat. The log file is producing the following when deploying the services. INFO: Marking servlet MessageServiceServlethttp as unavailable Jan 28, 2011 5:59:40 PM org.apache.catalina.core.StandardContext loadOnStartup SEVERE: Servlet /allMATCHWeb threw load() exception java.lang.ClassCastException: com.surecomp.allMATCH.client.webservices.MessageService cannot be cast to javax.servlet.Servlet at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1048) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:996) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4741) at org.apache.catalina.core.StandardContext$3.call(StandardContext.java:5062) at org.apache.catalina.core.StandardContext$3.call(StandardContext.java:5057) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Jan 28, 2011 5:59:40 PM org.apache.catalina.core.ApplicationContext log Sincerely, Robert Jenkin Surecomp Services, Inc. 2 Hudson Place, 4th Floor Hoboken, NJ 07030 Skype: robert.jenkin Office: 201 217 1437 | Direct: 201 716 1219 | Mobile: 908 251 0537 http://www.Surecomp.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, January 28, 2011 2:54 PM To: Tomcat Users List Subject: Re: deploying a war file and starting the application -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert, On 1/28/2011 1:09 PM, robert.jen...@surecomp.com wrote: I have downloaded and configured Tomcat 7. All appears to be working. Glad to hear it! I have deployed a war file that currently works with WebSphere 7 and WebLogic 11g. The first issue I had was with url-pattern. It appears that Tomcat requires they start with a slash (/). I made the change and I no longer receive any errors while starting Tomcat. This is a spec requirement, not a Tomcat requirement. Other containers may be more lenient. The following image shows the startup window and that my war is being deployed. Within the webapps directory a directory containing my webapp is created. Images are stripped from posts to the list. Can you post it somewhere online and give us a link? Or, just copy/paste any relevant content from your screen? My initial servlet is called InitServlet and it is marked as load-on-startup (please see following image) . Ditto. I have two questions 1) If I type http://localhost:7080/allMATCHWeb in to a browser shouldn’t see this login.html page? I don’t… however I can access it by http://localhost:7080/allMATCHWeb/login.html You'll have to provide your web.xml for us to know when you need authentication challenges. Are you using container-managed authentication? 2) The load-on-start InitServlet class is not being executed as I have no logs generated or any other startup items handled, any ideas? Again, including web.xml should help. Note that using an InitServlet hasn't been recommended since the addition of the ServletContextListener interface a long time ago. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DHsYACgkQ9CaO5/Lv0PBhSQCeNtR93FGfQecpwJ/n02ioUhpP x2MAn2WmpQ0vzJ3YAbrMQrE9SnMmOq++ =WYyb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This mail was sent via Mail-SeCure System.
