Re: Admin application creates duplicate "secure" attribute in server.xml
Peter, Many thanks for finding and fixing the bug, however we are currently running 5.0.28, and not likely to upgrade until summer. Can you describe enough about the problem that I could track it down and create a local fix / work around until then? Peter Rossbach wrote: Yes the wrong saving SSL Connector is a bug and I fix it for Tomcat 5.5.x. The old StandardServer saving code was strange. The new StoreConfig module has a flexible customizable API to store server.xml and context.xml. You can activate the new saving module with This listener register a new MBean with more options to save the tomcat configurations. Give 5.5.9 a try ... :-) Peter Jeffrey Barnett schrieb: Mike, unfortunately I'm only gotten better at restoring server.xml after it has been corrupted. You are the first person from the tomcat-user list to even confirm that the problem exits on other sites.. One consultant I consulted said that they had never heard of the problem, but that we were also the first site he had worked with that actually used the admin function actively, By the way, just for the record, not only the secure attribute, but also the protocol attribute is duplicated, right? And only on the SSL connector. Mike Dippold wrote: I just wanted to check to see if you have figured anything out with the tomcat admin ssl duplicate problem. I have tried it on 5.0.28 and also 5.5.7 and every time I change a datasource or anything else, it corrupts the xml. Thanks, Mike Dippold - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Admin application creates duplicate "secure" attribute in server.xml
Mike, unfortunately I'm only gotten better at restoring server.xml after it has been corrupted. You are the first person from the tomcat-user list to even confirm that the problem exits on other sites.. One consultant I consulted said that they had never heard of the problem, but that we were also the first site he had worked with that actually used the admin function actively, By the way, just for the record, not only the secure attribute, but also the protocol attribute is duplicated, right? And only on the SSL connector. Mike Dippold wrote: I just wanted to check to see if you have figured anything out with the tomcat admin ssl duplicate problem. I have tried it on 5.0.28 and also 5.5.7 and every time I change a datasource or anything else, it corrupts the xml. Thanks, Mike Dippold - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Admin application creates duplicate "secure" attribute in server.xml
More info: Apparently the manual change didn't fix things after all. The server starts, and some webapps run, but those using ssl get the following error message: Connection refused when attempting to contact :8443 The full service definition follows: Jeffrey Barnett wrote: We have recently upgraded from Tomcat 4 to Tomcat 5.0.27. Now whenever we use the Admin application to alter webapp context parameters the new server.xml that gets written out contains an extra 'secure="true"' attribute at the end of the ssl , which causes the server to fail with a SEVERE: Parse Fatal Error on restart. Removing the extra attribute manually allows the server to be started, but is operationally unacceptable. Where is the extra attribute coming from (is there a template somewhere)? How can we stop this from happening? Why is a new server.xml created at all? (Nothing is changed but the addition of the incorrect attribute) Here is the exception: Jan 29, 2005 7:30:54 AM org.apache.commons.digester.Digester fatalError SEVERE: Parse Fatal Error at line 22 column 221: Attribute "secure" was already specified for element "Connector". org.xml.sax.SAXParseException: Attribute "secure" was already specified for element "Connector". And here is the offending element (second attribute highlighted): - 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]
Use of Admin application creates duplicate "secure" attribute in server.xml
We have recently upgraded from Tomcat 4 to Tomcat 5.0.27. Now whenever we use the Admin application to alter webapp context parameters the new server.xml that gets written out contains an extra 'secure="true"' attribute at the end of the ssl , which causes the server to fail with a SEVERE: Parse Fatal Error on restart. Removing the extra attribute manually allows the server to be started, but is operationally unacceptable. Where is the extra attribute coming from (is there a template somewhere)? How can we stop this from happening? Why is a new server.xml created at all? (Nothing is changed but the addition of the incorrect attribute) Here is the exception: Jan 29, 2005 7:30:54 AM org.apache.commons.digester.Digester fatalError SEVERE: Parse Fatal Error at line 22 column 221: Attribute "secure" was already specified for element "Connector". org.xml.sax.SAXParseException: Attribute "secure" was already specified for element "Connector". And here is the offending element (second attribute highlighted): - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Location of third party jar files.
That was my point earlier. Or is there something so inherently wrong with using /common/lib that you would forgo the pooling option? Mike Curwen wrote: I believe you'd *need* to put them there (common/lib) if you were using a container-managed connection pool. -Original Message- From: Jeffrey Barnett [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 08, 2004 1:18 PM To: Tomcat Users List Subject: Re: Location of third party jar files. I believe Yoav said earlier it was OK to put JDBC drivers into common/lib. Or did I misunderstand, there was a bit of back and forth on the topic. Search Archives for "Tomcat 4.1: JSP pages don't always compile the first time?" Shapira, Yoav wrote: Hi, The right and best way is to include copies of them in your WEB-INF/lib directory. Don't symlink, don't put them in common/lib or shared/lib, don't put them on the bootstrap classpath. Yoav Shapira Millennium Research Informatics -Original Message- From: Kyle A. Boyd [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 08, 2004 1:19 PM To: [EMAIL PROTECTED] Subject: Location of third party jar files. We are using a couple of third party jar files. I can only get our application to see them if I add them to the tomcat/common/lib/ directory. This is inconvenient for our setup. Is there any other way for Tomcat to find the jar files in the classpath (works with Tomcat 3.2), a .xml file, or with a symbolic link? We are using Tomcat 5.0.27. Thanks, Kyle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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] - 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]
Re: Location of third party jar files.
I believe Yoav said earlier it was OK to put JDBC drivers into common/lib. Or did I misunderstand, there was a bit of back and forth on the topic. Search Archives for "Tomcat 4.1: JSP pages don't always compile the first time?" Shapira, Yoav wrote: Hi, The right and best way is to include copies of them in your WEB-INF/lib directory. Don't symlink, don't put them in common/lib or shared/lib, don't put them on the bootstrap classpath. Yoav Shapira Millennium Research Informatics -Original Message- From: Kyle A. Boyd [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 08, 2004 1:19 PM To: [EMAIL PROTECTED] Subject: Location of third party jar files. We are using a couple of third party jar files. I can only get our application to see them if I add them to the tomcat/common/lib/ directory. This is inconvenient for our setup. Is there any other way for Tomcat to find the jar files in the classpath (works with Tomcat 3.2), a .xml file, or with a symbolic link? We are using Tomcat 5.0.27. Thanks, Kyle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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]
Re: Tomcat 4.1: JSP pages don't always compile the first time?
But if the webapps are all using a common connection pool, wouldn't there need to be a single driver jar? Where would it go, if not in $CATALINA_HOME/common/lib ? Shapira, Yoav wrote: Hi, It applies to APIs bundled in the J2SDK and the J2EE SDK. So servlet.jar, jsp-api.jar, jta.jar, jmx.jar, things like that, but not standard.jar, JDBC drivers, etc. As a rule of thumb: if tomcat bundles a library, don't package a different version of the same library with your webapp. Yoav Shapira Millennium Research Informatics -Original Message----- From: Jeffrey Barnett [mailto:[EMAIL PROTECTED] Sent: Friday, September 03, 2004 2:16 PM To: Tomcat Users List Subject: Re: Tomcat 4.1: JSP pages don't always compile the first time? Does this warning/suggestion apply just to jsp-api.jar or to all the jsp jars (e.g.jstl.jar, standard.jar,...) as well? Shapira, Yoav wrote: Hi, You have mismatched versions of the Servlet API jars around. There should be only one, in tomcat's common repository. Don't ship the servlet or JSP API jars with your webapps. And if you stored references to objects from old versions of these APIs in your Sessions, junk the session repository (session.ser). Yoav Shapira Millennium Research Informatics -Original Message- From: Richard Mundell [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 11:09 AM To: [EMAIL PROTECTED] Subject: Tomcat 4.1: JSP pages don't always compile the first time? We have a large JSP-based application which we're noting some first time compilation problems. When we deploy the .war file (with the "work" cache deleted and Tomcat freshly started) some of our pages (but not all) fail to compile upon the first access with the error below. If you simply refresh the page through the web browser it then compiles fine, and is fine from that point onwards. It always happens with the same pages. These pages have includes of other JSP pages, but these have all already been correctly compiled and previously accessed. Can anyone give me any ideas on this? I can't find anything similar after trawling the search engines? Thanks, Richard javax.servlet.ServletException: (class: org/apache/jsp/OrderManagementComments_jsp, method: SortBasket signature: (Ljavax/servlet/http/HttpSession;)V) Incompatible type for getting or setting field at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl ic a tionFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF il t erChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV al v e.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex t. i nvokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav a: 4 80) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV al v e.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex t. i nvokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav a: 4 80) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java: 23 9 7) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j av a :180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex t. i nvokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche rV a lve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex t. i nvokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j av a :171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex t. i nvokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav a: 4 80) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve . java:174) at org.apache.catalina
Re: Tomcat 4.1: JSP pages don't always compile the first time?
Does this warning/suggestion apply just to jsp-api.jar or to all the jsp jars (e.g.jstl.jar, standard.jar,...) as well? Shapira, Yoav wrote: Hi, You have mismatched versions of the Servlet API jars around. There should be only one, in tomcat's common repository. Don't ship the servlet or JSP API jars with your webapps. And if you stored references to objects from old versions of these APIs in your Sessions, junk the session repository (session.ser). Yoav Shapira Millennium Research Informatics -Original Message- From: Richard Mundell [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 11:09 AM To: [EMAIL PROTECTED] Subject: Tomcat 4.1: JSP pages don't always compile the first time? We have a large JSP-based application which we're noting some first time compilation problems. When we deploy the .war file (with the "work" cache deleted and Tomcat freshly started) some of our pages (but not all) fail to compile upon the first access with the error below. If you simply refresh the page through the web browser it then compiles fine, and is fine from that point onwards. It always happens with the same pages. These pages have includes of other JSP pages, but these have all already been correctly compiled and previously accessed. Can anyone give me any ideas on this? I can't find anything similar after trawling the search engines? Thanks, Richard javax.servlet.ServletException: (class: org/apache/jsp/OrderManagementComments_jsp, method: SortBasket signature: (Ljavax/servlet/http/HttpSession;)V) Incompatible type for getting or setting field at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic a tionFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil t erChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVal v e.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. i nvokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 4 80) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextVal v e.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. i nvokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 4 80) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:23 9 7) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav a :180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. i nvokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherV a lve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. i nvokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav a :171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. i nvokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 4 80) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve . java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. i nvokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 4 80) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:458) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) at java.lang.Thread.run(Thread.java:484) This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PR
Re: Binding DataSources to Contexts in Tomcat 4.06/4.1
I'm sure your explanation as well as a (re) reading of the How To will allow me to correct the problem. Thanks very much! I'd like a little more explanation however about your advice on using DefaultContext. In addition to the advantage of having a single place to add, remove, and change resources and resource parameters (e.g. passwords), I THOUGHT I was sharing a single copy of the resources. I understand now that a separate copy is created for every application. But what I don't understand is how putting every resource in every "actual" context is better. If I have 5 applications, each of whose "actual" context contain 10 connections, won't I still have 50 connections? Shapira, Yoav wrote: You realize that by placing a Resource in DefaultContext you ensure that a separate copy is created for each Context, right? That means if you configure for 10 max connections and have 5 Contexts, you will have 5 DataSources with 50 total max connections possible. Unless this is really what you want, consider having the DataSource defined in the actual Context element instead of DefaultContext. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding DataSources to Contexts in Tomcat 4.06/4.1
In both servers the Resource declarations are in the
block. All DataSources are shared by all webapps. I do not have a
resource-ref declaration in either web.xml ... I'll go look that up and
remedy. What is the purpose of the factory parameter, and what is an
appropriate value?
thx
Shapira, Yoav wrote:
Hi,
Where in server.xml is your Resource declaration? Is there a matching
resource-ref in your web.xml? (It's required). You also probably want
a factory parameter, as mentioned in the JNDI DataSources how-to.
Yoav Shapira
Millennium Research Informatics
-Original Message-----
From: Jeffrey Barnett [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 19, 2004 2:04 PM
To: Tomcat Users List
Subject: Binding DataSources to Contexts in Tomcat 4.06/4.1
I have a servlet that contains the following code in its init() method:
public void init(ServletConfig config) throws ServletException {
super.init(config);
try {
Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");
System.out.println("Context loaded: " );
ds = (DataSource) envCtx.lookup("ReportsDB");
System.out.println("DataSource found: " + ds.toString());
con = ds.getConnection();
con1 = ds.getConnection();
} catch(Exception e) {
System.err.println("Init Error " + e.getMessage());
}
System.out.println("Init Complete");
}
the server.xml file contains:
type="javax.sql.DataSource"/>
maxActive100
maxIdle10
maxWait1
useruser
passwordpassword
driverClassName
oracle.jdbc.driver.OracleDriver
driverName
jdbc:oracle:thin:@myhost.edu:1521:LIBR
When I deploy the servlet on my development server (Tomcat 4.06) it
runs
without error and reports "Init Complete" in the localhost log.
The same code and xml deployed on a test server (tomcat 4.1.12) a
naming
exception is thrown and the catch block reports "Init Error Name
ReportsDB is not bound in this Context".
Is there a difference between the two releases that would explain this,
or are other settings involved in "binding" that I should be examining?
All suggestions gratefully accepted :-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business communication, and
may contain information that is confidential, proprietary and/or privileged. This
e-mail is intended only for the individual(s) to whom it is addressed, and may not be
saved, copied, printed, disclosed or used by anyone else. If you are not the(an)
intended recipient, please immediately delete this e-mail from your computer system
and notify the sender. Thank you.
-
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]
Binding DataSources to Contexts in Tomcat 4.06/4.1
I have a servlet that contains the following code in its init() method:
public void init(ServletConfig config) throws ServletException {
super.init(config);
try {
Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");
System.out.println("Context loaded: " );
ds = (DataSource) envCtx.lookup("ReportsDB");
System.out.println("DataSource found: " + ds.toString());
con = ds.getConnection();
con1 = ds.getConnection();
} catch(Exception e) {
System.err.println("Init Error " + e.getMessage());
}
System.out.println("Init Complete");
}
the server.xml file contains:
maxActive100
maxIdle10
maxWait1
useruser
passwordpassword
driverClassName
oracle.jdbc.driver.OracleDriver
driverName
jdbc:oracle:thin:@myhost.edu:1521:LIBR
When I deploy the servlet on my development server (Tomcat 4.06) it runs
without error and reports "Init Complete" in the localhost log.
The same code and xml deployed on a test server (tomcat 4.1.12) a naming
exception is thrown and the catch block reports "Init Error Name
ReportsDB is not bound in this Context".
Is there a difference between the two releases that would explain this,
or are other settings involved in "binding" that I should be examining?
All suggestions gratefully accepted :-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative causes of msg 404 "resource not avaialble"?
Answering my own question for the benefit of anyone searching the archive. Here is what was caught in the log: 2004-08-18 13:29:56 Starting $Id: ExportSerials.java,v 1.2 2004/08/16 21:01:41 dir = /export/home/tomcat/jakarta-tomcat-4.1.12/webapps/SerialsAnalysis/ Init Error Name jdbc is not bound in this Context ... So the reason the servlet class was not found was that it was never initialized. Next question, what does it mean that jdbc is not bound? Jeffrey Barnett wrote: Yes to both no luck. I'm thinking that somehow WEB-INF/classes is not getting into the CLASSPATH. Is there a way to check this at run time? Dennis Dai wrote: Have you tried reloading the context or restarting tomcat on your department test server? On 8/17/2004 2:04 PM, Jeffrey Barnett wrote: PPS: The rest of the webapp runs normally. Jeffrey Barnett wrote: PS: Server is 4.1.12 Jeffrey Barnett wrote: I recently added a servlet to an existing webapp in WEB-INF/classes. and added the corresponding and tags to web.xml. When I try it out on my desktop server it works fine, but when I redeploy to the department test server I get 404 error. Is there some other configuration/deployment step I am missing? - 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]
Re: Alternative causes of msg 404 "resource not avaialble"?
Yes to both no luck. I'm thinking that somehow WEB-INF/classes is not getting into the CLASSPATH. Is there a way to check this at run time? Dennis Dai wrote: Have you tried reloading the context or restarting tomcat on your department test server? On 8/17/2004 2:04 PM, Jeffrey Barnett wrote: PPS: The rest of the webapp runs normally. Jeffrey Barnett wrote: PS: Server is 4.1.12 Jeffrey Barnett wrote: I recently added a servlet to an existing webapp in WEB-INF/classes. and added the corresponding and tags to web.xml. When I try it out on my desktop server it works fine, but when I redeploy to the department test server I get 404 error. Is there some other configuration/deployment step I am missing? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative causes of msg 404 "resource not avaialble"?
PPS: The rest of the webapp runs normally. Jeffrey Barnett wrote: PS: Server is 4.1.12 Jeffrey Barnett wrote: I recently added a servlet to an existing webapp in WEB-INF/classes. and added the corresponding and tags to web.xml. When I try it out on my desktop server it works fine, but when I redeploy to the department test server I get 404 error. Is there some other configuration/deployment step I am missing? - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative causes of msg 404 "resource not avaialble"?
PS: Server is 4.1.12 Jeffrey Barnett wrote: I recently added a servlet to an existing webapp in WEB-INF/classes. and added the corresponding and tags to web.xml. When I try it out on my desktop server it works fine, but when I redeploy to the department test server I get 404 error. Is there some other configuration/deployment step I am missing? - 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]
Alternative causes of msg 404 "resource not avaialble"?
I recently added a servlet to an existing webapp in WEB-INF/classes. and added the corresponding and tags to web.xml. When I try it out on my desktop server it works fine, but when I redeploy to the department test server I get 404 error. Is there some other configuration/deployment step I am missing? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
