Tomcat not resolving host name when using ant tasks...otherwise all is fine
As my tomcat is behind a firewall and not publicly visible (I use Apache connector) I had selected localhost as the engine name and host name. All of my tomcat functionality is working: manager, admin, jsps under docroot, axis, struts, blah blah. My tomcat version is 4.1.27, and it is using an internal ip of 192.168.1.2 and internal hostname of mother. For some reason, when I attempt using the tomcat ant list task from a remote laptop, I get the message: tools\build.xml [177] java.net.ProtocolException: Server redirected too many times (20) It doesn't work whether I give a url of "http://mother:8080/manager"; or "http://192.168.1.2:8080/manager";. I have tried changing engine's defaultHost and host names to "localhost", "mother", and "192.168.1.2" to no avail. Yet I can remotely (via internal lan) issue the manager list command from any of my web browsers and it works just fine. The following is output from catalina_ log: 2003-11-14 12:46:06 StandardEngine[Standalone]: Mapping server name 'mother' 2003-11-14 12:46:06 StandardEngine[Standalone]: Trying a direct match Based on my understanding of host mapping, if request doesn't match a specific host name, then defaultHost property of engine is used. This doesn't seem to be happening though. It seems the ant task functionality has worked before and as far I know I haven't made any server.xml changes that would cause it to cease working. It's wierd that I can invoke this same url from browser and data is returned. Any ideas? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems with tomcat server hostname mapping and ant tasks...server redirect problems
As my tomcat is behind a firewall and not publicly visible (I use Apache connector) I had selected localhost as the engine name and host name. All of my tomcat functionality is working: manager, admin, jsps under docroot, axis, struts, blah blah. My tomcat version is 4.1.27, and it is using an internal ip of 192.168.1.2 and internal hostname of mother. For some reason, when I attempt using the tomcat ant list task from a remote laptop, I get the message: tools\build.xml [177] java.net.ProtocolException: Server redirected too many times (20) It doesn't work whether I give a url of "http://mother:8080/manager"; or "http://192.168.1.2:8080/manager";. I have tried changing engine's defaultHost and host names to "localhost", "mother", and "192.168.1.2" to no avail. Yet I can remotely (via internal lan) issue the manager list command from any of my web browsers and it works just fine. The following is output from catalina_ log: 2003-11-14 12:46:06 StandardEngine[Standalone]: Mapping server name 'mother' 2003-11-14 12:46:06 StandardEngine[Standalone]: Trying a direct match Based on my understanding of host mapping, if request doesn't match a specific host name, then defaultHost property of engine is used. This doesn't seem to be happening though. It seems the ant task functionality has worked before and as far I know I haven't made any server.xml changes that would cause it to cease working. It's wierd that I can invoke this same url from browser and data is returned. Any ideas? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can use Ant to deploy to localhost
Steven Woody wrote: I'v not managed to deploy an application to Tomcat using Ant's task. It always reports a UnknownHostNameException. I'v checked the 'url' property, that is 'http://localhost:8080/manager', and be sure that is right. What do I do? -- Steven Woody [EMAIL PROTECTED] I've had localhost expanded to localhost.localdomain...make sure this is in your hosts file too. mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Defining JNDI DataSource...why decl'd/def'd in server.xml and not in web.xml.
I like to make my web applications and their corresponding installations/deployments as modular/atomic as possible. I like hot deployments, etc, etc. Unfortunately, every application I've seen that uses Tomcat JNDI DataSources requires hand-editing of server.xml...and then a reference to the resource in web.xml of web application. Why can't I describe the JNDI DataSource in the web.xml of my web application? I didn't notice this possibility in dtd for web.xml. As an example, I recently installed JUDDI, a Java application that manages a uddi registry. It came as a self-contained web application (directory or .war), and after dropping it into webapps directory...I still had to hand-edit server.xml to describe its connection to database and it was done in a context only applying to juddi web app. This seems error-prone and just not clean/modular. I would understand defining JNDI datasources available to ALL web applications via Tomcat's admin or via the server.xmlbut why when it's per web application? Please correct my thinking... thanks in advance, mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk problem with serving jsp from apache root dir...from tomcat alias dir is ok
This has to be brain freeze of something...this s/be so simple...and probably is. I'm running tomcat 4.1.24-LE-jdk14 and Apache 1.3.27. I've got jsps coming up on the web server port (via alias'd tomcat examples dir), in addition to default of tomcat 8080 port...of course. However, when I added the following: JkMount /*.jsp ajp13 to my mod_jk.conf, which is Included at the end of my httpd.conf, it doesn't seem to work. I get an http 404 740 error (requested resource is not available). I put a HelloWorld.jsp into the web root of one of my virtual hosts and it can't be pulled up. I've copied it as a .txt file, which is returned just fine, and have double-checked permissions. I can't seem to dish up jsps located directly under my server root...why? mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_jk problem with serving jsp from apache root dir...from tomcat alias dir is ok
I 'figured' out the problem I was having...or at least got things working. In addition to: JkMount /*.jsp ajp13 I also had to add a servlet context to server.xml: Originally docBase said ROOT, which I guess is Tomcat's root dir as opposed to DocumentRoot in Apache. I thought it might be cleaner to place individual 'markup' files (jsp, html, php) under Apache, and only webapps and possibly servlets under Tomcat. I didn't seem to think a servlet context was needed for stuff under apache, just for webapps...my mistake. Most of my work has been with webapps, and to Apache's credit, I haven't had a whole lot of problems up till now...with cocoon, apache, tomcat, etc. I'm putting my server into a sort of test mode now, and am creating samples of various 'similar' web pages using different web technologies (jsp, php, cocoon). For this reason I wanted the files placed singlely under my apache root, rather than tomcat using webapps/etc. mike -Original Message- From: Mike Klein [mailto:[EMAIL PROTECTED] Sent: Sunday, August 10, 2003 9:30 PM To: [EMAIL PROTECTED] Subject: mod_jk problem with serving jsp from apache root dir...from tomcat alias dir is ok This has to be brain freeze of something...this s/be so simple...and probably is. I'm running tomcat 4.1.24-LE-jdk14 and Apache 1.3.27. I've got jsps coming up on the web server port (via alias'd tomcat examples dir), in addition to default of tomcat 8080 port...of course. However, when I added the following: JkMount /*.jsp ajp13 to my mod_jk.conf, which is Included at the end of my httpd.conf, it doesn't seem to work. I get an http 404 740 error (requested resource is not available). I put a HelloWorld.jsp into the web root of one of my virtual hosts and it can't be pulled up. I've copied it as a .txt file, which is returned just fine, and have double-checked permissions. I can't seem to dish up jsps located directly under my server root...why? mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
