Possible manager bug with war file names?
I have an autobuild script that creates a timestamped war file (eg ore-200109131032). When I use manager to deploy the war, using the URL: [get] Getting: http://localhost:9080/manager/remove?path=/ore [get] Getting: http://localhost:9080/manager/install?path=/orewar=jar:file:F:\projects\ore \build\ore-local-200109251510.war!/ It deploys at the uri http://localhost:9080/ore as expected. However the war is extracted to the webapps directory as ore-local-200109251510 The major problem with this is that restarting the server results in a webapp at http://localhost:9080/ore-local-200109251510 not ORE as expected. Is this a known bug? chris. -- Chris Stevenson [EMAIL PROTECTED] http://sourceforge.net/projects/jtds
Re: JK in TC 4.0 ?
[EMAIL PROTECTED] wrote: On Sat, 22 Sep 2001, Remy Maucherat wrote: ballot [ ] +1. Integrate the mod_jk JARs with the Tomcat 4 distributions. I'll help testing / maintaining it. [ ] +0. Good idea. [ ] -0. Bad idea. [ ] -1. No, because: /ballot My vote: +1 (I'll update the build scripts, tag the j-t-c/util and j-t-c/jk repositories). +1 ( I'll help !). It's a good step toward working togheter. Costin +1 Jean-frederic
Tomcat4.0 and UserTransaction
hi, in my project i am trying to get an instance of javax.transaction.UserTransaction in tomcat4.0 using jndi. i have added the following tag in my server.xml for this regard as well as in web.xml as it is mentioned in the docs of tomcat4.0 Resource name=jta/UserTransaction auth=Container type=javax.transaction.UserTransaction/ when in my JSP application i try to retrieve the instance it throws an exception on browser that says Exception Report: javax.servlet.ServletException: Cannot create resource instance Root Cause:javax.naming.NamingException: Cannot create resource instance the code i hve written in jsp page is:: Context ctx1 = new InitialContext(); Context ctx2 = (Context)ctx1.lookup(java:comp/env); UserTransaction ut = (UserTransaction)ctx2.lookup(jta/UserTransaction); any idea what shud be done to mend this.. BTW i am using mysql as database and mysql's type 4 jdbc2.0 compliant driver. please suggest its urgent.. thanks in advance, sachin walia
DO NOT REPLY [Bug 3806] New: - ISAPI redirector plugin doesn't close response stream
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3806. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3806 ISAPI redirector plugin doesn't close response stream Summary: ISAPI redirector plugin doesn't close response stream Product: Tomcat 3 Version: 3.2.3 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connectors AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The ISAPI redirector plugin sends the response headers and data but then doesn't close the response stream(socket). The browser (IE 5.0/5.5) still waits for more data and, after his timeout has expired, shows an error page (Server not found). Reproducable with Tomcat's example servlets and JSPs. On Windows NT 4.0/2000 with IIS 3.0/4.0/5.0 and Tomcat 3.2.3.
CVS question: Almost off topic
I've committed a patch to the repository today, expecting an automatic e-mail to the tomcat-dev list when the commit happens. But it never did, although the commit went through OK. After searching the CVS manual for clues, I bumped into -i option for modules, but that seems like an admin/setup kind of thing. I must be doing something funny... Bojan PS. The commit was done with a simple: cvs -d [EMAIL PROTECTED]:/home/cvs commit -m Message File
RE: CVS question: Almost off topic
The cvs list is moderated. It takes a little time the first time ;) Don't worry, it'll get there. -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 25 September 2001 10:33 am To: Tomcat Dev List Subject: CVS question: Almost off topic I've committed a patch to the repository today, expecting an automatic e-mail to the tomcat-dev list when the commit happens. But it never did, although the commit went through OK. After searching the CVS manual for clues, I bumped into -i option for modules, but that seems like an admin/setup kind of thing. I must be doing something funny... Bojan PS. The commit was done with a simple: cvs -d [EMAIL PROTECTED]:/home/cvs commit -m Message File === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
tomcat hangging problem
Hello... Here is the description of current problem I try to solve... I have already mailed to tomcat-user, but since nobody has a beginning of an answer, and since we can't go on production launch anymore, I try here. environment: - AIX 4.3.3 SMP, - JRE 1.2.2 (several builds), then 1.3.0 - tomcat 3.2.1, 3.2.3 then 3.3.b2 (sorry, did not try 3.3.rc1 yet!) problem is: tomcat hangs after some time (may be 3 minutes or some hours). I mean tomcat is running (ps shows it), but no answer is received to requests when tomcat hangs (telnetting it with a http get request results in no response). Even a kill -3 does nothing. Strangely, problem occurs only on _some_ of AIX 4.3.3 machines where I run tomcat. Some machines, with same jre/tomcat/code, run with no problem (well, maybe problem would occur after a much longer time, I don't really know). And I did not met that on winNT4 (with a Sun jdk: I got to try with an ibm jvm). Note that I got a javacore twice, if somebody can interpret it... I wrote a simple servlet which shows tomcat hangging, if that can help: a singleton deals with doGet: first time it launches 'n' threads, each of them will http-request same singleton every 't' seconds and print result to stdout. other request to singleton only prints text/plain string to response's writer. Thanks -- Joseph Vallot This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: CVS question: Almost off topic
Morrison, John wrote: The cvs list is moderated. It takes a little time the first time ;) Don't worry, it'll get there. He, he, good one ;-) Bojan
DO NOT REPLY [Bug 3809] New: - Jar files in the wrong directories.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3809. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3809 Jar files in the wrong directories. Summary: Jar files in the wrong directories. Product: Tomcat 4 Version: 4.0 Final Platform: Other OS/Version: Other Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] According to the class loader documentation the common/lib directory should only contain the following jar files. jndi.jar naming.jar resources.jar servlet.jar But when I build a standard Tomcat distribution I get the following. activation.jar crimson.jar This should be in server/lib. jaxp.jarThis should be in server/lib. jdbc2_0-stdext.jar jndi.jar jta-spec1_0_1.jar ldap.jar mail.jar naming-common.jar Assuming this is naming.jar naming-resources.jarAssuming this is resources.jar servlet.jar tyrex-0.9.7.0.jar The ones which cause me most problems are crimson.jar and jaxp.jar as they conflict with the XML parser which I am trying to use and the documentation clearly states that Tomcat 4 will not make an XML parser visible to the web application. As this is something that we have a lot of problems with it is very important to us. Could you please move the above jar files into the correct place, especially crimson.jar and jaxp.jar and update the documentation to match what the distribution looks like.
Tomcat4.0 and javax.transaction.UserTransaction
hi, in my project i am trying to get an instance of javax.transaction.UserTransaction in tomcat4.0 using jndi. i have added the following tag in my server.xml for this regard as well an appropiate tag for this in WEB-INF/web.xml file which is conatined in my web application as it is mentioned in the docs of tomcat4.0 Resource name=jta/UserTransaction auth=Container type=javax.transaction.UserTransaction/ for server.xml for web-inf/web.xml following tag is added resource-ref res-ref-namejta/UserTransaction/res-ref-name res-typejavax.transaction.UserTransaction/res-type res-authContainer/res-auth /resource-ref when in my JSP application i try to retrieve the instance it throws an exception on browser that says Exception Report: javax.servlet.ServletException: Cannot create resource instance Root Cause:javax.naming.NamingException: Cannot create resource instance the code i hve written in jsp page is:: Context ctx1 = new InitialContext(); Context ctx2 = (Context)ctx1.lookup(java:comp/env); UserTransaction ut = (UserTransaction)ctx2.lookup(jta/UserTransaction); any idea what shud be done to mend this.. BTW i am using mysql as database and mysql's type 4 jdbc2.0 compliant driver. please suggest its urgent.. thanks in advance, sachin walia
Re: [PATCH] SSL how-to documentation
A quick look inside the source code of sun.security.provider.JavaKeyStore reveals the following line in the getPreKeyedHash() method: md.update(Mighty Aphrodite.getBytes(UTF8)); Background: They're storing a MD5 hash of the password in the keystore to ensure the keystore was not tampered. To make the MD5 hash harder to crack (assuming the cracker is not smart enough to itself study JDK sources), it is pre-keyed with the above tribute to Woody Allen. As it appears nowhere in the specs, a cleanroom JDK could use another string to pre-key the hash (potentially it could even not pre-key it at all). In this case, a keystore created with Sun JDK would appear tampered when opened by a JDK that pre-keys the hash with Everything You Always Wanted to Know About Sex. Attila. Christopher Cain wrote: Hi Patrick. Could you explain this a little further? Actually creating a keystore using keytool of course has nothing to do with Tomcat per se, so I assume you mean that the keystore created might not work with Tomcat. Under what conditions would a keystore generated by one JDK not work with another JDK? In testing, I was able to generate a keystore on a Windoze box with JDK 1.3.1, copy it over to a Linux box running 1.3.0, and successfully start up Tomcat and access a page over SSL. If you have a properly-formatted JKS store, why would it matter which JDK produced it? -- _ Patrick Luby Email: [EMAIL PROTECTED] Software Engineering Manager Phone: 408-863-3284 Sun Microsystems 901 San Antonio Road, UCUP01-103 Palo Alto, CA 94303-4900 _ - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */ smime.p7s
DO NOT REPLY [Bug 3810] New: - Filtering and forwarding doesn't follow spec
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3810. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3810 Filtering and forwarding doesn't follow spec Summary: Filtering and forwarding doesn't follow spec Product: Tomcat 4 Version: 4.0 Final Platform: All OS/Version: All Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] According to servlet 2.3 final specification (6.2.2) container must not wrap requests/responses submitted from filter or through RequestDispatcher due to reasons explained in the same section. However, current final version of Tomcat 4.0 does wrap supplied request with org.apache.catalina.core.ApplicationHttpRequest instance and response with org.apache.catalina.connector.HttpResponseFacade.
Re: [PATCH] SSL how-to documentation
Attila Szegedi wrote: A quick look inside the source code of sun.security.provider.JavaKeyStore reveals the following line in the getPreKeyedHash() method: md.update(Mighty Aphrodite.getBytes(UTF8)); Background: They're storing a MD5 hash of the password in the keystore to ensure the keystore was not tampered. To make the MD5 hash harder to crack (assuming the cracker is not smart enough to itself study JDK sources), it is pre-keyed with the above tribute to Woody Allen. As it appears nowhere in the specs, a cleanroom JDK could use another string to pre-key the hash (potentially it could even not pre-key it at all). In this case, a keystore created with Sun JDK would appear tampered when opened by a JDK that pre-keys the hash with Everything You Always Wanted to Know About Sex. And the keystorePass is in server.xml but that is well know. We should avoid things like security through obscurancy Attila. Christopher Cain wrote: Hi Patrick. Could you explain this a little further? Actually creating a keystore using keytool of course has nothing to do with Tomcat per se, so I assume you mean that the keystore created might not work with Tomcat. Under what conditions would a keystore generated by one JDK not work with another JDK? In testing, I was able to generate a keystore on a Windoze box with JDK 1.3.1, copy it over to a Linux box running 1.3.0, and successfully start up Tomcat and access a page over SSL. If you have a properly-formatted JKS store, why would it matter which JDK produced it? -- _ Patrick Luby Email: [EMAIL PROTECTED] Software Engineering Manager Phone: 408-863-3284 Sun Microsystems 901 San Antonio Road, UCUP01-103 Palo Alto, CA 94303-4900 _ - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
DO NOT REPLY [Bug 3809] - Jar files in the wrong directories.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3809. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3809 Jar files in the wrong directories. --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 06:47 --- This is also the cause of bug 3796
RE: [PATCH] SSL how-to documentation
-Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 25, 2001 9:22 AM To: [EMAIL PROTECTED] Subject: Re: [PATCH] SSL how-to documentation [Snip] And the keystorePass is in server.xml but that is well know. I hope to add to Tomcat 3.3 RC2 Christopher Cain's work for a run-time prompter that will prompt the user for the password when Tomcat starts up. Being barely able to keep my head above water on Tomcat 3.3 issues, I'm not sure what has been done for Tomcat 4.0 in this regard. Cheers, Larry
Re: [PATCH] SSL how-to documentation
Larry Isaacs wrote: -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 25, 2001 9:22 AM To: [EMAIL PROTECTED] Subject: Re: [PATCH] SSL how-to documentation [Snip] And the keystorePass is in server.xml but that is well know. I hope to add to Tomcat 3.3 RC2 Christopher Cain's work for a run-time prompter that will prompt the user for the password when Tomcat starts up. Being barely able to keep my head above water on Tomcat 3.3 issues, I'm not sure what has been done for Tomcat 4.0 in this regard. Actually, nothing has been done for 4.0 in this regard =) I got pretty close, but the amount of effort required to finally implement it is prohibitive. I decided to leave it alone for now, until LitterBox is born, which will remove all sensitive data from server.xml. - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
Re: [PATCH] SSL how-to documentation
jean-frederic clere wrote: And the keystorePass is in server.xml but that is well know. We should avoid things like security through obscurancy JF, I like you better and better every time you post :) - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
DO NOT REPLY [Bug 3809] - Jar files in the wrong directories.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3809. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3809 Jar files in the wrong directories. --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 08:58 --- The prescence of ldap.jar in common/lib is also causing problems. I initially got the following exception, which went away when I renamed ldap.jar to ldap.jar.backup: java.lang.NoClassDefFoundError: com/sun/jndi/toolkit/chars/CharacterEncoder at com.sun.jndi.ldap.Connection.init(Connection.java:180) at com.sun.jndi.ldap.LdapClient.init(LdapClient.java:81) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2329) at com.sun.jndi.ldap.LdapCtx.init(LdapCtx.java:211) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:79) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:665) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:246) at javax.naming.InitialContext.init(InitialContext.java:222) at javax.naming.InitialContext.init(InitialContext.java:198) at javax.naming.directory.InitialDirContext.init(InitialDirContext.java:83) at LDAPUserRegistry.init(LDAPUserRegistry.java:25) at InitServlet.init(InitServlet.java:33) at org.apache.catalina.core.StandardWrapper.load(Unknown Source) at org.apache.catalina.core.StandardContext.loadOnStartup(Unknown Source) at org.apache.catalina.core.StandardContext.start(Unknown Source) at org.apache.catalina.core.ContainerBase.addChild(Unknown Source) at org.apache.catalina.core.StandardHost.addChild(Unknown Source) at org.apache.catalina.core.StandardHost.install(Unknown Source) at org.apache.catalina.startup.HostConfig.deployApps(Unknown Source) at org.apache.catalina.startup.HostConfig.start(Unknown Source) at org.apache.catalina.startup.HostConfig.lifecycleEvent(Unknown Source) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.StandardEngine.start(Unknown Source) at org.apache.catalina.core.StandardService.start(Unknown Source) at org.apache.catalina.core.StandardServer.start(Unknown Source) at org.apache.catalina.startup.Catalina.start(Unknown Source) at org.apache.catalina.startup.Catalina.execute(Unknown Source) at org.apache.catalina.startup.Catalina.process(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Unknown Source)
DO NOT REPLY [Bug 3796] - XML Classloader problem has crept back in
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3796. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3796 XML Classloader problem has crept back in [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 09:09 --- *** This bug has been marked as a duplicate of 3809 ***
DO NOT REPLY [Bug 3809] - Jar files in the wrong directories.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3809. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3809 Jar files in the wrong directories. [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 09:09 --- *** Bug 3796 has been marked as a duplicate of this bug. ***
Tomcat 3.2.3 WAR files and 4.0
Are the Tomcat-3.2.3 Web-applications supposed to run as-is on Tomcat-4.0? I have one that doesn't. Thanks.. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
DO NOT REPLY [Bug 3809] - Jar files in the wrong directories.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3809. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3809 Jar files in the wrong directories. --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 09:19 --- The ldap problem happens with JDK 1.3+, and is fixed in the HEAD of the CVS. The workaround for the bug is relatively simple (I suppose you found it already): delete ldap.jar. We will document the new policy regarding the XML parser, but I'm afraid there are as many people if not more who had problems with the absence of a XML parser. Craig is working on this, so I'll leave the bug open.
cvs commit: jakarta-tomcat-4.0/catalina/src/conf server-noexamples.xml.config server.xml
ccain 01/09/25 09:35:15 Modified:catalina/src/conf server-noexamples.xml.config server.xml Log: Update the commented instructions for SSL (primarily to remove a now-extraneous step). Revision ChangesPath 1.4 +5 -4 jakarta-tomcat-4.0/catalina/src/conf/server-noexamples.xml.config Index: server-noexamples.xml.config === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server-noexamples.xml.config,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- server-noexamples.xml.config 2001/09/23 21:03:10 1.3 +++ server-noexamples.xml.config 2001/09/25 16:35:15 1.4 @@ -32,15 +32,16 @@ By default, a non-SSL HTTP/1.1 Connector is established on port 8080. You can also enable an SSL HTTP/1.1 Connector on port 8443 by following the instructions below and uncommenting the second Connector - entry. SSL support requires the following steps: + entry. SSL support requires the following steps (see the SSL Config + HOWTO in the Tomcat 4.0 documentation bundle for more detailed + instructions): * Download and install JSSE 1.0.2 or later, and put the JAR files into $JAVA_HOME/jre/lib/ext. - * Edit $JAVA_HOME/jre/lib/security/java.security and add - security.provider.2=com.sun.net.ssl.internal.ssl.Provider * Execute: %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA (Windows) $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA (Unix) - with a password value of changeit. + with a password value of changeit for both the certificate and + the keystore itself. By default, DNS lookups are enabled when a web application calls request.getRemoteHost(). This can have an adverse impact on 1.32 +5 -4 jakarta-tomcat-4.0/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v retrieving revision 1.31 retrieving revision 1.32 diff -u -r1.31 -r1.32 --- server.xml2001/09/23 21:03:10 1.31 +++ server.xml2001/09/25 16:35:15 1.32 @@ -32,15 +32,16 @@ By default, a non-SSL HTTP/1.1 Connector is established on port 8080. You can also enable an SSL HTTP/1.1 Connector on port 8443 by following the instructions below and uncommenting the second Connector - entry. SSL support requires the following steps: + entry. SSL support requires the following steps (see the SSL Config + HOWTO in the Tomcat 4.0 documentation bundle for more detailed + instructions): * Download and install JSSE 1.0.2 or later, and put the JAR files into $JAVA_HOME/jre/lib/ext. - * Edit $JAVA_HOME/jre/lib/security/java.security and add - security.provider.2=com.sun.net.ssl.internal.ssl.Provider * Execute: %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA (Windows) $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA (Unix) - with a password value of changeit. + with a password value of changeit for both the certificate and + the keystore itself. By default, DNS lookups are enabled when a web application calls request.getRemoteHost(). This can have an adverse impact on
Re: tomcat hangging problem
Hi Joseph, I assume this is happening only on SMP machines ( i.e. with multiple CPUs). My bet is that this is related with the VM/libraries. It can of course be a bug in tomcat, like a deadlock or something - but then it would fail on all SMP machines. Could you check with the 'latest' 1.3.0 and make sure you have all the patches installed ( pthred.so, etc ). Also, check the version of the libraries between the AIX machines that work and those that don't. If you get a core dump - again, this is a clear sign something is wrong with the VM/libraries. A java program shouldn't be able to coredump regardless of the code inside ( unless JNI is used ), and there's nothing we can do in tomcat ( even if we find a workaround, some user code can crash the server as well ). Is anyone else running SMP machines ? I remember long time ago a problem on linux/smp, but was solved by using a newer VM. Costin Here is the description of current problem I try to solve... I have already mailed to tomcat-user, but since nobody has a beginning of an answer, and since we can't go on production launch anymore, I try here. environment: - AIX 4.3.3 SMP, - JRE 1.2.2 (several builds), then 1.3.0 - tomcat 3.2.1, 3.2.3 then 3.3.b2 (sorry, did not try 3.3.rc1 yet!) problem is: tomcat hangs after some time (may be 3 minutes or some hours). I mean tomcat is running (ps shows it), but no answer is received to requests when tomcat hangs (telnetting it with a http get request results in no response). Even a kill -3 does nothing. Strangely, problem occurs only on _some_ of AIX 4.3.3 machines where I run tomcat. Some machines, with same jre/tomcat/code, run with no problem (well, maybe problem would occur after a much longer time, I don't really know). And I did not met that on winNT4 (with a Sun jdk: I got to try with an ibm jvm). Note that I got a javacore twice, if somebody can interpret it... I wrote a simple servlet which shows tomcat hangging, if that can help: a singleton deals with doGet: first time it launches 'n' threads, each of them will http-request same singleton every 't' seconds and print result to stdout. other request to singleton only prints text/plain string to response's writer. Thanks -- Joseph Vallot This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
DO NOT REPLY [Bug 3817] New: - classpath loading priority doesn't match docs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3817. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3817 classpath loading priority doesn't match docs Summary: classpath loading priority doesn't match docs Product: Tomcat 4 Version: 4.0 Final Platform: PC OS/Version: Windows 9x Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Placing a jar file that contains the Servlet 2.2 classes in $CATALINA_HOME/lib causes Tomcat to fail to display JSP pages. The documented class loading order in http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html is: * /WEB-INF/classes of your web application * /WEB-INF/lib/*.jar of your web application * Bootstrap classes of your JVM * System class loader classses (described above) * $CATALINA_HOME/common/classes * $CATALINA_HOME/common/*.jar * $CATALINA_HOME/classes * $CATALINA_HOME/lib/*.jar Since $CATALINA_HOME/lib is last in priority, shouldn't the Servlet 2.3 classes override the old Servlet classes in $CATALINA_HOME/lib? This may seem like a perverse thing to do, but it has to do with making a jar file that's easy to install and use in multiple environments. The error that Tomcat gives is: 2001-09-25 10:37:38 StandardWrapper[/tomcat-docs:invoker]: Loading container servlet invoker 2001-09-25 10:37:38 invoker: init 2001-09-25 10:37:38 StandardWrapper[/tomcat-docs:jsp]: Using Jasper classloader for servlet jsp 2001-09-25 10:37:38 StandardWrapper[/tomcat-docs:jsp]: Marking servlet jsp as unavailable 2001-09-25 10:37:38 StandardContext[/tomcat-docs]: Servlet /tomcat-docs threw load() exception javax.servlet.ServletException: Class org.apache.jasper.servlet.JspServlet is not a Servlet at org.apache.catalina.core.StandardWrapper.load(Unknown Source) at org.apache.catalina.core.StandardContext.loadOnStartup(Unknown Source) at org.apache.catalina.core.StandardContext.start(Unknown Source) at org.apache.catalina.core.ContainerBase.addChild(Unknown Source) at org.apache.catalina.core.StandardHost.addChild(Unknown Source) at org.apache.catalina.core.StandardHost.install(Unknown Source) at org.apache.catalina.startup.HostConfig.deployApps(Unknown Source) at org.apache.catalina.startup.HostConfig.start(Unknown Source) at org.apache.catalina.startup.HostConfig.lifecycleEvent(Unknown Source) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.StandardEngine.start(Unknown Source) at org.apache.catalina.core.StandardService.start(Unknown Source) at org.apache.catalina.core.StandardServer.start(Unknown Source) at org.apache.catalina.startup.Catalina.start(Unknown Source) at org.apache.catalina.startup.Catalina.execute(Unknown Source) at org.apache.catalina.startup.Catalina.process(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Unknown Source) - Root Cause - java.lang.ClassCastException: org.apache.jasper.servlet.JspServlet at org.apache.catalina.core.StandardWrapper.load(Unknown Source) at org.apache.catalina.core.StandardContext.loadOnStartup(Unknown Source) at org.apache.catalina.core.StandardContext.start(Unknown Source) at org.apache.catalina.core.ContainerBase.addChild(Unknown Source) at org.apache.catalina.core.StandardHost.addChild(Unknown Source) at org.apache.catalina.core.StandardHost.install(Unknown Source) at org.apache.catalina.startup.HostConfig.deployApps(Unknown Source) at org.apache.catalina.startup.HostConfig.start(Unknown Source) at org.apache.catalina.startup.HostConfig.lifecycleEvent(Unknown Source) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.StandardEngine.start(Unknown Source) at org.apache.catalina.core.StandardService.start(Unknown Source) at org.apache.catalina.core.StandardServer.start(Unknown Source) at org.apache.catalina.startup.Catalina.start(Unknown Source) at org.apache.catalina.startup.Catalina.execute(Unknown Source) at org.apache.catalina.startup.Catalina.process(Unknown
DO NOT REPLY [Bug 3818] New: - Slow start to Tomcat after executing startup.bat due to non fatal JIT error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3818. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3818 Slow start to Tomcat after executing startup.bat due to non fatal JIT error Summary: Slow start to Tomcat after executing startup.bat due to non fatal JIT error Product: Tomcat 4 Version: 4.0 Final Platform: PC OS/Version: Windows 9x Status: NEW Severity: Minor Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The following message appears several times in the DOS window over a period of around 30 secs before the server is ready to use. Starting service Tomcat-Standalone Apache Tomcat/4.0 A nonfatal internal JIT (3.10.107(x)) error 'Relocation error: NULL relocation target' has occurred in : 'org/apache/crimson/parser/Parser2.maybeComment (Z)Z': Interpreting method. Please report this error in detail to http://java.sun.com/cgi- bin/bugreport.cgi
DO NOT REPLY [Bug 3770] - HttpSessionListener.sessionCreated() called twice for each session
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3770. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3770 HttpSessionListener.sessionCreated() called twice for each session --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 11:48 --- On further experimentation, I noticed that this error only occurs when I define the tag library that contains the listener in the web.xml file with a taglib element. If I rely on auto-discovery of tag libraries, everything works fine. Most likely, the listener is registered once when the container processes the TLD it finds through auto-discovery, and then again when it finds the TLD through the web.xml definition. Checking whether a TLD has already been processed before registering listeners should fix the problem.
DO NOT REPLY [Bug 3799] - Setting null cookie value throws exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3799. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3799 Setting null cookie value throws exception [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Severity|Critical|Blocker Priority|Other |High
DO NOT REPLY [Bug 3822] New: - Drive letter causes a NumberFormatException when JSP compiler parses errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3822. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3822 Drive letter causes a NumberFormatException when JSP compiler parses errors Summary: Drive letter causes a NumberFormatException when JSP compiler parses errors Product: Tomcat 4 Version: 4.0 Release Candidate 2 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Got the following error on Win2K but not on Linux. It appears that the Jasper compiler misinterprets the driver letter (e.g., D) for the line number of an error message. Line 314 of org.apache.jasper.compiler.Compiler tries to identify a drive letter on Windows platforms by the existence of two colons in the error message, but there's no conditional to compensate for the extra colon when present. - Root Cause - java.lang.NumberFormatException: D at java.lang.Integer.parseInt(Integer.java:405) at java.lang.Integer.parseInt(Integer.java:454) at org.apache.jasper.compiler.Compiler.getJspLineErrors(Unknown Source) at org.apache.jasper.compiler.Compiler.compile(Unknown Source) at org.apache.jasper.servlet.JspServlet.loadJSP(Unknown Source) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessar y(Unknown Source) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(Unknow n Source) at org.apache.jasper.servlet.JspServlet.serviceJspFile(Unknown Source) at org.apache.jasper.servlet.JspServlet.service(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(Unknown Source) at org.apache.catalina.core.ApplicationDispatcher.doInclude(Unknown Sour ce) at org.apache.catalina.core.ApplicationDispatcher.include(Unknown Source ) at org.apache.jasper.runtime.JspRuntimeLibrary.include(Unknown Source) at org.apache.jsp.login$jsp._jspService(login$jsp.java:70) at org.apache.jasper.runtime.HttpJspBase.service(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(Unknow n Source) at org.apache.jasper.servlet.JspServlet.serviceJspFile(Unknown Source) at org.apache.jasper.servlet.JspServlet.service(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(Unknown Source) at org.apache.catalina.core.ApplicationDispatcher.doForward(Unknown Sour ce) at org.apache.catalina.core.ApplicationDispatcher.forward(Unknown Source ) at LoginServlet.doGet(LoginServlet.java:31) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unkn own Source) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Sour ce) at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline.invokeNext(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at org.apache.catalina.core.StandardContextValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline.invokeNext(Unknown Source) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Unknown So urce) at org.apache.catalina.core.StandardPipeline.invokeNext(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at org.apache.catalina.core.StandardContext.invoke(Unknown Source) at org.apache.catalina.core.StandardHostValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline.invokeNext(Unknown Source) at org.apache.catalina.valves.AccessLogValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline.invokeNext(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at org.apache.catalina.core.StandardEngineValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline.invokeNext(Unknown Source)
Tomcat/Apache config
We're running on RS/6000 server, AIX 4.3.3, Perl 5.6.1, Apache 1.3.12, Tomcat 3.2.3. We get almost all of the way through the installations, but we're unable to build the mod_jserv.so module. We get the following error when we try to build it: ld: 0711-244 ERROR: No csects or exported symbols have been saved. apxs:Break: Command failed with rc=524288 The mod_jserv.so gets built (well, somthing gets built!). I copied it to $APACHE_HOME/libexec. Yet, when I try to startup Apache with that module in the tomcat-apache.conf file, it won't start. I get: Can't locate API module structure `jserv_module' in file /usr/local/apache_1.3.12/libexec/mod_jserv.so: Function not implemented (js erv_module) apachectl start: httpd could not be started Any ideas? Any help you could provide would be greatly appreciated.
DO NOT REPLY [Bug 3817] - classpath loading priority doesn't match docs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3817. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3817 classpath loading priority doesn't match docs [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 12:19 --- http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html documents that the shared loader is between the common loader and the webapp loader. Since that's the behavior that's implemented, I don't see any problem. Don't put anything containing the old servlet API classes in any of the Catalina loaders.
Re: Tomcat 3.2.3 WAR files and 4.0
On Tue, 25 Sep 2001, Neeraj Vora wrote: Date: Tue, 25 Sep 2001 09:13:08 -0700 From: Neeraj Vora [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Tomcat 3.2.3 WAR files and 4.0 Are the Tomcat-3.2.3 Web-applications supposed to run as-is on Tomcat-4.0? I have one that doesn't. Thanks.. As long as your web apps are spec-compliant to the servlet 2.2 and JSP 1.1 specs, and don't rely on bugs or other non-spec behavior in 3.2.3, they should indeed work. Failure to do so is a bug in Tomcat 4. The most likely causes for problems: * Your web.xml has elements not in the order required by the DTD. Tomcat 3.2.3 accepted them anyway (even though it allowed non-portable apps). Tomcat 4.0 uses a validating XML parser, so your web.xml elements MUST match the required order. * Assumptions about the current working directory when running Tomcat. This is never portable, and you should design your applications not to rely on it. * Differences in the global class loading architectures. You'll need to be more explicit about what your WAR file does, and how it fails, to see if this is your issue. Craig
DO NOT REPLY [Bug 3823] New: - sendError and setStatus clear headers already set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3823. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3823 sendError and setStatus clear headers already set Summary: sendError and setStatus clear headers already set Product: Tomcat 4 Version: 4.0 Final Platform: All OS/Version: All Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have installed TC4 and have it working. I am moving an app that worked fine under TC3.3. My problem is that when I call: res.setHeader(WWW-Authenticate, BASIC realm=\ + domain +\); rese.sendError(res.SC_UNAUTHORIZED); in my servlet the authenticate header is stripped from the result. (examples follow) This occurs whether I make the request through IIS (actually PWS) or to TC directly via port 8080 The problem appears to be in org.apache.catalina.core.StandardWrapperValve.status() This is run to respond to status messages but it calls org.apache.catalina.connector.HttpResponseBase.reset(int status, String message) which in turn calls HttpResponse.reset() HttpResponseBase already resets the content or headers appropriately for the API methods called. status() does it again (in what I assume is a let's be sure it was done kind of way) but according to the spec that isn't appropriate. The spec doesn't specify that HttpResponse.sendError(int status) must clear the headers only that it must clear the buffer and set any appropriate headers. The spec does specify that HttpResponse.sendError(int status, String message) and HttpResponse.setStatus(int status) should return any headers already set. I believe the following would changes would restore spec compliance (at the risk of breaking what else I don't know) org.apache.catalina.connector.HttpResponseBase.reset(int status, String message) method to call resetBuffer() rather than reset() org.apache.catalina.core.StandardWrapperValve.custom(req, res, errorpage) on line 481 to call hres.resetBuffer() rather than hres.reset()
DO NOT REPLY [Bug 3817] - classpath loading priority doesn't match docs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3817. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3817 classpath loading priority doesn't match docs [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 12:52 --- Perhaps this is a documentation bug, but the list given on that doc page of the classloaders from the point of view of a web application does not say that the shared loader is between the webapp and common loaders. Rather, the common loader is between webapp and shared. webapp: /WEB-INF/classes of your web application webapp: /WEB-INF/lib/*.jar of your web application bootstrap: Bootstrap classes of your JVM system: System class loader classses (described above) common: $CATALINA_HOME/common/classes common: $CATALINA_HOME/common/*.jar shared: $CATALINA_HOME/classes shared: $CATALINA_HOME/lib/*.jar Or am I misunderstanding?
Re: Tomcat 3.2.3 WAR files and 4.0
Craig, Thanks for the info. Can you elaborate on the differences in the global class loading architectures? Seems like that is my problem. I'm getting the following error. The class it is complaining about is present in the WEB-INF/classes folder, but I don't understand why it is looking for it in the package org.apache.jsp. The same WAR file works without any problem on Tomcat-3.2.3. *** org.apache.jasper.JasperException: Unable to compile class for JSP An error occured between lines: 23 and 40 in the jsp file: /main2.jsp Generated servlet error: C:\jakarta-tomcat-4.0\work\localhost\SoftSyncWeb\main2$jsp.java:14: Class org.apache.jsp.VersionTreeNode not found. private String printNode (VersionTreeNode vtn, String indentation, String reqURI) ^ *** From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 WAR files and 4.0 Date: Tue, 25 Sep 2001 12:21:17 -0700 (PDT) On Tue, 25 Sep 2001, Neeraj Vora wrote: Date: Tue, 25 Sep 2001 09:13:08 -0700 From: Neeraj Vora [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Tomcat 3.2.3 WAR files and 4.0 Are the Tomcat-3.2.3 Web-applications supposed to run as-is on Tomcat-4.0? I have one that doesn't. Thanks.. As long as your web apps are spec-compliant to the servlet 2.2 and JSP 1.1 specs, and don't rely on bugs or other non-spec behavior in 3.2.3, they should indeed work. Failure to do so is a bug in Tomcat 4. The most likely causes for problems: * Your web.xml has elements not in the order required by the DTD. Tomcat 3.2.3 accepted them anyway (even though it allowed non-portable apps). Tomcat 4.0 uses a validating XML parser, so your web.xml elements MUST match the required order. * Assumptions about the current working directory when running Tomcat. This is never portable, and you should design your applications not to rely on it. * Differences in the global class loading architectures. You'll need to be more explicit about what your WAR file does, and how it fails, to see if this is your issue. Craig _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Re: Tomcat 3.2.3 WAR files and 4.0
Tomcat 4 puts the generated servlets for JSP pages it creates into package org.apache.jsp. Tomcat 3.2.3 did something different (which I don't remember precisely), but that's OK because the spec explicitly allows containers to put these classes wherever it wants. The line in question would appear to be something you've included in a scriptlet. The most likely explanation is that you didn't do an %@ page import=... % for the fully qualified class name of class VersionTreeNode, so the Java compiler followed the rules in the Java Language Specification, and assumed it was in the same class as the calling page. Craig On Tue, 25 Sep 2001, Neeraj Vora wrote: Date: Tue, 25 Sep 2001 13:03:44 -0700 From: Neeraj Vora [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 WAR files and 4.0 Craig, Thanks for the info. Can you elaborate on the differences in the global class loading architectures? Seems like that is my problem. I'm getting the following error. The class it is complaining about is present in the WEB-INF/classes folder, but I don't understand why it is looking for it in the package org.apache.jsp. The same WAR file works without any problem on Tomcat-3.2.3. *** org.apache.jasper.JasperException: Unable to compile class for JSP An error occured between lines: 23 and 40 in the jsp file: /main2.jsp Generated servlet error: C:\jakarta-tomcat-4.0\work\localhost\SoftSyncWeb\main2$jsp.java:14: Class org.apache.jsp.VersionTreeNode not found. private String printNode (VersionTreeNode vtn, String indentation, String reqURI) ^ *** From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 WAR files and 4.0 Date: Tue, 25 Sep 2001 12:21:17 -0700 (PDT) On Tue, 25 Sep 2001, Neeraj Vora wrote: Date: Tue, 25 Sep 2001 09:13:08 -0700 From: Neeraj Vora [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Tomcat 3.2.3 WAR files and 4.0 Are the Tomcat-3.2.3 Web-applications supposed to run as-is on Tomcat-4.0? I have one that doesn't. Thanks.. As long as your web apps are spec-compliant to the servlet 2.2 and JSP 1.1 specs, and don't rely on bugs or other non-spec behavior in 3.2.3, they should indeed work. Failure to do so is a bug in Tomcat 4. The most likely causes for problems: * Your web.xml has elements not in the order required by the DTD. Tomcat 3.2.3 accepted them anyway (even though it allowed non-portable apps). Tomcat 4.0 uses a validating XML parser, so your web.xml elements MUST match the required order. * Assumptions about the current working directory when running Tomcat. This is never portable, and you should design your applications not to rely on it. * Differences in the global class loading architectures. You'll need to be more explicit about what your WAR file does, and how it fails, to see if this is your issue. Craig _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
DO NOT REPLY [Bug 472] - A nonfatal internal JIT 3.10.107x error: NULL relocation target' has occurred in: 'org/apache/crimson/parser/Paser2.maybeComment ZZ': Interpreting method. BugRat Report#798
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=472. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=472 A nonfatal internal JIT 3.10.107x error: NULL relocation target' has occurred in: 'org/apache/crimson/parser/Paser2.maybeComment ZZ': Interpreting method. BugRat Report#798 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 13:25 --- *** Bug 3818 has been marked as a duplicate of this bug. ***
DO NOT REPLY [Bug 472] - A nonfatal internal JIT 3.10.107x error: NULL relocation target' has occurred in: 'org/apache/crimson/parser/Paser2.maybeComment ZZ': Interpreting method. BugRat Report#798
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=472. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=472 A nonfatal internal JIT 3.10.107x error: NULL relocation target' has occurred in: 'org/apache/crimson/parser/Paser2.maybeComment ZZ': Interpreting method. BugRat Report#798 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 13:25 --- *** Bug 3818 has been marked as a duplicate of this bug. ***
DO NOT REPLY [Bug 3799] - Setting null cookie value throws exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3799. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3799 Setting null cookie value throws exception [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 13:36 --- According to the Javadocs for Cookie, the proper way to delete a cookie is to set the max age to zero before adding it: Cookie cookie = new Cookie(foo, arbitrary value); cookie.setMaxAge(0); response.addCookie(cookie); Even if Tomcat is changed to not throw an NPE in this case, your cookie will still not be deleted.
DO NOT REPLY [Bug 3802] - Tomcat crashes without any error on HP UX 11
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3802. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3802 Tomcat crashes without any error on HP UX 11 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 13:40 --- Most likely it's a JVM problem. Make sure you have the latest patches for the OS, and the latest VM ( or latest stable VM ). There is nothing we can do in tomcat to 'crash' a vm - if any java code will crash the VM, the bug is in the VM ( and it can happen at any time, including user code )
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util CookieTools.java
craigmcc01/09/25 13:44:42
Modified:catalina/src/share/org/apache/catalina/util Tag:
tomcat_40_branch CookieTools.java
Log:
Port NPE avoidance on malformed cookies from the HEAD branch.
Revision ChangesPath
No revision
No revision
1.5.2.1 +12 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/CookieTools.java
Index: CookieTools.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/CookieTools.java,v
retrieving revision 1.5
retrieving revision 1.5.2.1
diff -u -r1.5 -r1.5.2.1
--- CookieTools.java 2001/09/05 18:35:32 1.5
+++ CookieTools.java 2001/09/25 20:44:42 1.5.2.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/CookieTools.java,v
1.5 2001/09/05 18:35:32 craigmcc Exp $
- * $Revision: 1.5 $
- * $Date: 2001/09/05 18:35:32 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/CookieTools.java,v
1.5.2.1 2001/09/25 20:44:42 craigmcc Exp $
+ * $Revision: 1.5.2.1 $
+ * $Date: 2001/09/25 20:44:42 $
*
*
*
@@ -108,9 +108,16 @@
// this part is the same for all cookies
-buf.append(URLEncoder.encode(cookie.getName()));
+String name = cookie.getName(); // Avoid NPE on malformed cookies
+if (name == null)
+name = ;
+String value = cookie.getValue();
+if (value == null)
+value = ;
+
+buf.append(URLEncoder.encode(name));
buf.append(=);
-maybeQuote(version, buf, URLEncoder.encode(cookie.getValue()));
+maybeQuote(version, buf, URLEncoder.encode(value));
// add version 1 specific information
if (version == 1) {
DO NOT REPLY [Bug 3817] - classpath loading priority doesn't match docs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3817. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3817 classpath loading priority doesn't match docs [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 13:45 --- There is a tree diagram which shows very clearly the class loader hierarchy. Bootstrap | System | Common / \ Catalina Shared / \ Webapp1 Webapp2 ... / / Jasper1 Jasper2 ...
DO NOT REPLY [Bug 3815] - JspServlets produces NullPointerException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3815. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3815 JspServlets produces NullPointerException --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 13:50 --- (Please ignore my last comment, I didn't read the source correctly.) My JSP was producing an ArrayStoreException because it had a bug, and I was running a stress test with JMeter with 10 concurrent threads. I have an errorpage set up for this app, so every thread invoking this page causes the errorpage to be produced. This is why the stack trace shows handlePageException - forward - etc. Unfortunately I did lots of tests and fixes and now I cannot reproduce the issue, even rolling back the code.
DO NOT REPLY [Bug 3784] - Long URLs cause ArrayIndexOutOfBoundsException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3784. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3784 Long URLs cause ArrayIndexOutOfBoundsException [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 14:03 --- Resolved in 3.3, we do resize the buffer.
Re: Tomcat 3.2.3 WAR files and 4.0
Craig, The class in question does not have any package associated with it so what do I do an import for? This worked without any problem in Tomcat-3.2.3. The class in question is present in the WEB-INF/classes folder. Thanks, Neeraj From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 WAR files and 4.0 Date: Tue, 25 Sep 2001 13:08:35 -0700 (PDT) Tomcat 4 puts the generated servlets for JSP pages it creates into package org.apache.jsp. Tomcat 3.2.3 did something different (which I don't remember precisely), but that's OK because the spec explicitly allows containers to put these classes wherever it wants. The line in question would appear to be something you've included in a scriptlet. The most likely explanation is that you didn't do an %@ page import=... % for the fully qualified class name of class VersionTreeNode, so the Java compiler followed the rules in the Java Language Specification, and assumed it was in the same class as the calling page. Craig On Tue, 25 Sep 2001, Neeraj Vora wrote: Date: Tue, 25 Sep 2001 13:03:44 -0700 From: Neeraj Vora [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 WAR files and 4.0 Craig, Thanks for the info. Can you elaborate on the differences in the global class loading architectures? Seems like that is my problem. I'm getting the following error. The class it is complaining about is present in the WEB-INF/classes folder, but I don't understand why it is looking for it in the package org.apache.jsp. The same WAR file works without any problem on Tomcat-3.2.3. *** org.apache.jasper.JasperException: Unable to compile class for JSP An error occured between lines: 23 and 40 in the jsp file: /main2.jsp Generated servlet error: C:\jakarta-tomcat-4.0\work\localhost\SoftSyncWeb\main2$jsp.java:14: Class org.apache.jsp.VersionTreeNode not found. private String printNode (VersionTreeNode vtn, String indentation, String reqURI) ^ *** From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 WAR files and 4.0 Date: Tue, 25 Sep 2001 12:21:17 -0700 (PDT) On Tue, 25 Sep 2001, Neeraj Vora wrote: Date: Tue, 25 Sep 2001 09:13:08 -0700 From: Neeraj Vora [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Tomcat 3.2.3 WAR files and 4.0 Are the Tomcat-3.2.3 Web-applications supposed to run as-is on Tomcat-4.0? I have one that doesn't. Thanks.. As long as your web apps are spec-compliant to the servlet 2.2 and JSP 1.1 specs, and don't rely on bugs or other non-spec behavior in 3.2.3, they should indeed work. Failure to do so is a bug in Tomcat 4. The most likely causes for problems: * Your web.xml has elements not in the order required by the DTD. Tomcat 3.2.3 accepted them anyway (even though it allowed non-portable apps). Tomcat 4.0 uses a validating XML parser, so your web.xml elements MUST match the required order. * Assumptions about the current working directory when running Tomcat. This is never portable, and you should design your applications not to rely on it. * Differences in the global class loading architectures. You'll need to be more explicit about what your WAR file does, and how it fails, to see if this is your issue. Craig _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
DO NOT REPLY [Bug 112] - TOMCAT_HOME defaults to /bin directory on Microsoft Windows BugRat Report#119
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=112. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=112 TOMCAT_HOME defaults to /bin directory on Microsoft Windows BugRat Report#119 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 14:19 --- This is resolved in 3.3.
DO NOT REPLY [Bug 112] - TOMCAT_HOME defaults to /bin directory on Microsoft Windows BugRat Report#119
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=112. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=112 TOMCAT_HOME defaults to /bin directory on Microsoft Windows BugRat Report#119 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 14:19 --- This is resolved in 3.3.
DO NOT REPLY [Bug 3823] - sendError and setStatus clear headers already set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3823. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3823 sendError and setStatus clear headers already set --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 14:24 --- Fixing this bug is quite risky, but we can try it and see what happens. In any case, a lot of headers need to be reset (content-length, content-encoding, transfer-encoding, ranges, etc etc), so that's why we were resetting everything. Even after the problem is fixed, it would be cleaner to write a realm implementation, instead of putting the authentication layer in the servlet.
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
remm01/09/25 14:55:39
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
- Fix a NPE when the class doesn't belong to a package.
Revision ChangesPath
1.18 +6 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- WebappClassLoader.java2001/09/24 22:09:29 1.17
+++ WebappClassLoader.java2001/09/25 21:55:39 1.18
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.17 2001/09/24 22:09:29 remm Exp $
- * $Revision: 1.17 $
- * $Date: 2001/09/24 22:09:29 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.18 2001/09/25 21:55:39 remm Exp $
+ * $Revision: 1.18 $
+ * $Date: 2001/09/25 21:55:39 $
*
*
*
@@ -123,7 +123,7 @@
*
* @author Remy Maucherat
* @author Craig R. McClanahan
- * @version $Revision: 1.17 $ $Date: 2001/09/24 22:09:29 $
+ * @version $Revision: 1.18 $ $Date: 2001/09/25 21:55:39 $
*/
public class WebappClassLoader
extends URLClassLoader
@@ -1762,6 +1762,8 @@
int pos = name.lastIndexOf('.');
if (pos != -1)
packageName = name.substring(0, pos);
+else
+return true;
if (packageName.equals(javax.servlet))
return false;
Re: Tomcat 3.2.3 WAR files and 4.0
Neeraj, tomcat generates java source code for a servlet based on the JSP. THis is a new class with a horrid name, but goes in the org.apache.jsp package. So just as if you were coding normally, you need to import whatever classes you need. cheers dim On Tue, 25 Sep 2001, Neeraj Vora wrote: Craig, The class in question does not have any package associated with it so what do I do an import for? This worked without any problem in Tomcat-3.2.3. The class in question is present in the WEB-INF/classes folder. Thanks, Neeraj From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 WAR files and 4.0 Date: Tue, 25 Sep 2001 13:08:35 -0700 (PDT) Tomcat 4 puts the generated servlets for JSP pages it creates into package org.apache.jsp. Tomcat 3.2.3 did something different (which I don't remember precisely), but that's OK because the spec explicitly allows containers to put these classes wherever it wants. The line in question would appear to be something you've included in a scriptlet. The most likely explanation is that you didn't do an %@ page import=... % for the fully qualified class name of class VersionTreeNode, so the Java compiler followed the rules in the Java Language Specification, and assumed it was in the same class as the calling page. Craig On Tue, 25 Sep 2001, Neeraj Vora wrote: Date: Tue, 25 Sep 2001 13:03:44 -0700 From: Neeraj Vora [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 WAR files and 4.0 Craig, Thanks for the info. Can you elaborate on the differences in the global class loading architectures? Seems like that is my problem. I'm getting the following error. The class it is complaining about is present in the WEB-INF/classes folder, but I don't understand why it is looking for it in the package org.apache.jsp. The same WAR file works without any problem on Tomcat-3.2.3. *** org.apache.jasper.JasperException: Unable to compile class for JSP An error occured between lines: 23 and 40 in the jsp file: /main2.jsp Generated servlet error: C:\jakarta-tomcat-4.0\work\localhost\SoftSyncWeb\main2$jsp.java:14: Class org.apache.jsp.VersionTreeNode not found. private String printNode (VersionTreeNode vtn, String indentation, String reqURI) ^ *** From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 WAR files and 4.0 Date: Tue, 25 Sep 2001 12:21:17 -0700 (PDT) On Tue, 25 Sep 2001, Neeraj Vora wrote: Date: Tue, 25 Sep 2001 09:13:08 -0700 From: Neeraj Vora [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Tomcat 3.2.3 WAR files and 4.0 Are the Tomcat-3.2.3 Web-applications supposed to run as-is on Tomcat-4.0? I have one that doesn't. Thanks.. As long as your web apps are spec-compliant to the servlet 2.2 and JSP 1.1 specs, and don't rely on bugs or other non-spec behavior in 3.2.3, they should indeed work. Failure to do so is a bug in Tomcat 4. The most likely causes for problems: * Your web.xml has elements not in the order required by the DTD. Tomcat 3.2.3 accepted them anyway (even though it allowed non-portable apps). Tomcat 4.0 uses a validating XML parser, so your web.xml elements MUST match the required order. * Assumptions about the current working directory when running Tomcat. This is never portable, and you should design your applications not to rely on it. * Differences in the global class loading architectures. You'll need to be more explicit about what your WAR file does, and how it fails, to see if this is your issue. Craig _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
remm01/09/25 14:57:56
Modified:catalina/src/share/org/apache/catalina/loader Tag:
tomcat_40_branch WebappClassLoader.java
Log:
- Fix a NPE when the class doesn't belong to a package.
Revision ChangesPath
No revision
No revision
1.15.2.3 +6 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.15.2.2
retrieving revision 1.15.2.3
diff -u -r1.15.2.2 -r1.15.2.3
--- WebappClassLoader.java2001/09/24 22:17:42 1.15.2.2
+++ WebappClassLoader.java2001/09/25 21:57:56 1.15.2.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.15.2.2 2001/09/24 22:17:42 remm Exp $
- * $Revision: 1.15.2.2 $
- * $Date: 2001/09/24 22:17:42 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.15.2.3 2001/09/25 21:57:56 remm Exp $
+ * $Revision: 1.15.2.3 $
+ * $Date: 2001/09/25 21:57:56 $
*
*
*
@@ -123,7 +123,7 @@
*
* @author Remy Maucherat
* @author Craig R. McClanahan
- * @version $Revision: 1.15.2.2 $ $Date: 2001/09/24 22:17:42 $
+ * @version $Revision: 1.15.2.3 $ $Date: 2001/09/25 21:57:56 $
*/
public class WebappClassLoader
extends URLClassLoader
@@ -1762,6 +1762,8 @@
int pos = name.lastIndexOf('.');
if (pos != -1)
packageName = name.substring(0, pos);
+else
+return true;
if (packageName.equals(javax.servlet))
return false;
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup ClassLoaderFactory.java
remm01/09/25 15:04:44
Modified:catalina/src/share/org/apache/catalina/startup
ClassLoaderFactory.java
Log:
- Shouldn't the CLs except the webapp CL be delegating ?
They were in non delegating mode, which could explain a lot of problems.
Revision ChangesPath
1.4 +6 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java
Index: ClassLoaderFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ClassLoaderFactory.java 2001/09/23 03:32:40 1.3
+++ ClassLoaderFactory.java 2001/09/25 22:04:44 1.4
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java,v
1.3 2001/09/23 03:32:40 craigmcc Exp $
- * $Revision: 1.3 $
- * $Date: 2001/09/23 03:32:40 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java,v
1.4 2001/09/25 22:04:44 remm Exp $
+ * $Revision: 1.4 $
+ * $Date: 2001/09/25 22:04:44 $
*
*
*
@@ -92,7 +92,7 @@
* /ul
*
* @author Craig R. McClanahan
- * @version $Revision: 1.3 $ $Date: 2001/09/23 03:32:40 $
+ * @version $Revision: 1.4 $ $Date: 2001/09/25 22:04:44 $
*/
public final class ClassLoaderFactory {
@@ -256,11 +256,12 @@
// Construct the class loader itself
String array[] = (String[]) list.toArray(new String[list.size()]);
-ClassLoader classLoader = null;
+StandardClassLoader classLoader = null;
if (parent == null)
classLoader = new StandardClassLoader(array);
else
classLoader = new StandardClassLoader(array, parent);
+classLoader.setDelegate(true);
return (classLoader);
}
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader StandardLoader.java
remm01/09/25 15:11:00 Removed: catalina/src/share/org/apache/catalina/loader StandardLoader.java Log: - Remove StandardLoader, which has been replaced by WebappLoader.
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorDispatcherValve.java ErrorReportValve.java
remm01/09/25 15:11:49 Added: catalina/src/share/org/apache/catalina/valves ErrorDispatcherValve.java ErrorReportValve.java Log: - Start experimenting with the error report / dispatcher refactoring. Not done yet, these are only skeleton classes. Revision ChangesPath 1.1 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java Index: ErrorDispatcherValve.java === /* * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v 1.1 2001/09/25 22:11:49 remm Exp $ * $Revision: 1.1 $ * $Date: 2001/09/25 22:11:49 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999-2001 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Tomcat, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * * [Additional notices, if required by prior licensing conditions] * */ package org.apache.catalina.valves; import java.io.IOException; import java.util.ArrayList; import java.util.Enumeration; import java.util.Iterator; import javax.servlet.ServletException; import javax.servlet.ServletRequest; import javax.servlet.ServletResponse; import javax.servlet.http.Cookie; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.catalina.Container; import org.apache.catalina.Context; import org.apache.catalina.HttpRequest; import org.apache.catalina.HttpResponse; import org.apache.catalina.Logger; import org.apache.catalina.Request; import org.apache.catalina.Response; import org.apache.catalina.Valve; import org.apache.catalina.ValveContext; import org.apache.catalina.connector.HttpResponseWrapper; import org.apache.catalina.util.StringManager; /** * pImplementation of a Valve that handles the error dispatch (that is, will * forward to the appropriate error page if necessary)./p * * pThis Valve should be attached at the Host level, although it will work * if attached to a Context./p * * pbWARNING/b: This valve is necessary for Servlet API compliance./p * * @author Remy Maucherat * @author Craig R. McClanahan * @version $Revision: 1.1 $ $Date: 2001/09/25 22:11:49 $ */ public class ErrorDispatcherValve
DO NOT REPLY [Bug 3810] - Filtering and forwarding doesn't follow spec
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3810. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3810 Filtering and forwarding doesn't follow spec [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|tomcat- |[EMAIL PROTECTED] |[EMAIL PROTECTED] |
DO NOT REPLY [Bug 3823] - sendError and setStatus clear headers already set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3823. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3823 sendError and setStatus clear headers already set --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 15:36 --- Overriding any already set headers can be done with the setHeader methods rather than addHeader methods. The spec is pretty clear on what should happen and the reference implementation should comply with the spec so whether it's risky or not (or my proposed fix works or not) shouldn't really make any difference to whether this bug gets assigned a high priority or not. FWIW I have a bunch of applications running using this and, while I may go to realm based security in the future, I don't want to have to change something thta isn't broken.
cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml
craigmcc01/09/25 16:31:09
Modified:tester/src/bin Tag: tomcat_40_branch tester.xml
tester/web/WEB-INF Tag: tomcat_40_branch web.xml
Added: tester/src/tester/org/apache/tester Tag: tomcat_40_branch
FilterRequest02.java FilterRequest02a.java
FilterResponse04.java FilterResponse04a.java
Log:
Add unit tests which prove that Tomcat 4 is correctly implementing Section
6.2 of the servlet spec. It is legal to use wrappers to implement the
required functionality, but if the application (filter or servlet) wraps
the request and response objects, those application wrapped instances must
be the ones that are passed on to the invoked servlet.
Revision ChangesPath
No revision
No revision
1.69.2.1 +52 -0 jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.69
retrieving revision 1.69.2.1
diff -u -r1.69 -r1.69.2.1
--- tester.xml2001/09/18 00:08:00 1.69
+++ tester.xml2001/09/25 23:31:09 1.69.2.1
@@ -381,6 +381,32 @@
inContent=FilterRequest01 Wrapped Stream PASSED
outContent=FILTERREQUEST01 WRAPPED STREAM PASSED/
+!-- == Servlet Sees Application Wrapper = --
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/FilterRequest02?wrap=false
+ outContent=FilterRequest02 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/WrappedFilterRequest02?wrap=true
+ outContent=FilterRequest02 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/FilterRequest02?wrap=falseamp;dispatch=F
+ outContent=FilterRequest02 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/WrappedFilterRequest02?wrap=trueamp;dispatch=F
+ outContent=FilterRequest02 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/FilterRequest02?wrap=falseamp;dispatch=I
+ outContent=FilterRequest02 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/WrappedFilterRequest02?wrap=trueamp;dispatch=I
+ outContent=FilterRequest02 PASSED/
+
/target
@@ -426,6 +452,32 @@
debug=${debug}
status=200
outContent=FILTERRESPONSE03 PASSED/
+
+!-- == Servlet Sees Application Wrapper = --
+
+tester host=${host} port=${port} protocol=HTTP/1.0
+ request=${context.path}/FilterResponse04?wrap=false debug=${debug}
+ outContent=FilterResponse04 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/WrappedFilterResponse04?wrap=true
+ outContent=FilterResponse04 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/FilterResponse04?wrap=falseamp;dispatch=F
+ outContent=FilterResponse04 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/WrappedFilterResponse04?wrap=trueamp;dispatch=F
+ outContent=FilterResponse04 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/FilterResponse04?wrap=falseamp;dispatch=I
+ outContent=FilterResponse04 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/WrappedFilterResponse04?wrap=trueamp;dispatch=I
+ outContent=FilterResponse04 PASSED/
/target
No revision
No revision
1.1.2.1 +126 -0
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Attic/FilterRequest02.java
1.1.2.1 +103 -0
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Attic/FilterRequest02a.java
1.1.2.1 +126 -0
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Attic/FilterResponse04.java
1.1.2.1 +103 -0
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Attic/FilterResponse04a.java
No revision
No revision
1.50.2.1 +60 -0 jakarta-tomcat-4.0/tester/web/WEB-INF/web.xml
Index: web.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/web/WEB-INF/web.xml,v
retrieving revision
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startupClassLoaderFactory.java
On 25 Sep 2001 [EMAIL PROTECTED] wrote: Date: 25 Sep 2001 22:04:44 - From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup ClassLoaderFactory.java remm01/09/25 15:04:44 Modified:catalina/src/share/org/apache/catalina/startup ClassLoaderFactory.java Log: - Shouldn't the CLs except the webapp CL be delegating ? They were in non delegating mode, which could explain a lot of problems. Yep, they should. This patch needs to be posted to tomcat_40_branch as well, because ClassLoaderFactory was added there as well. FYI, the previous behavior (before ClassLoaderFactory) was indeed to create delegating class loaders. Craig
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup ClassLoaderFactory.java
remm01/09/25 16:54:27
Modified:catalina/src/share/org/apache/catalina/startup Tag:
tomcat_40_branch ClassLoaderFactory.java
Log:
- Create CL in delegating mode.
Revision ChangesPath
No revision
No revision
1.1.2.3 +6 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java
Index: ClassLoaderFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- ClassLoaderFactory.java 2001/09/23 03:32:24 1.1.2.2
+++ ClassLoaderFactory.java 2001/09/25 23:54:26 1.1.2.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java,v
1.1.2.2 2001/09/23 03:32:24 craigmcc Exp $
- * $Revision: 1.1.2.2 $
- * $Date: 2001/09/23 03:32:24 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java,v
1.1.2.3 2001/09/25 23:54:26 remm Exp $
+ * $Revision: 1.1.2.3 $
+ * $Date: 2001/09/25 23:54:26 $
*
*
*
@@ -92,7 +92,7 @@
* /ul
*
* @author Craig R. McClanahan
- * @version $Revision: 1.1.2.2 $ $Date: 2001/09/23 03:32:24 $
+ * @version $Revision: 1.1.2.3 $ $Date: 2001/09/25 23:54:26 $
*/
public final class ClassLoaderFactory {
@@ -256,11 +256,12 @@
// Construct the class loader itself
String array[] = (String[]) list.toArray(new String[list.size()]);
-ClassLoader classLoader = null;
+StandardClassLoader classLoader = null;
if (parent == null)
classLoader = new StandardClassLoader(array);
else
classLoader = new StandardClassLoader(array, parent);
+classLoader.setDelegate(true);
return (classLoader);
}
DO NOT REPLY [Bug 3817] - classpath loading priority doesn't match docs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3817. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3817 classpath loading priority doesn't match docs [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 16:59 --- Fixed (in CVS). Thanks for the report.
Re: Tomcat 3.2.3 WAR files and 4.0
On Tue, 25 Sep 2001, Neeraj Vora wrote: Date: Tue, 25 Sep 2001 14:16:15 -0700 From: Neeraj Vora [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 WAR files and 4.0 Craig, The class in question does not have any package associated with it so what do I do an import for? This worked without any problem in Tomcat-3.2.3. The class in question is present in the WEB-INF/classes folder. JSP Spec 1.2 (Final Version), Section 8.2, says: The JSP Page implementation object [the base class for the servlet generated from your page] belongs to an implementation- dependent named package. The package used may vary between one JSP and another, so minimal assumptions should be made. The unnamed package should not be used without an explicit import of the class. The first part of this (about the base class being implementation dependent) was in JSP 1.1 (Section 3.2), but the second part (and in particular the last sentence) wasn't ... and this led to portability problems like the one you are observing because many people do not understand the implication. Classes in unnamed packages would happen to work without import *only* if your container did not put its generated servlets into a package at all (which is what Tomcat 3.2 did). Thus, your page was relying on a specific detail of Tomcat 3.2's behavior, and it would not be portable to most other Servlet 2.2 containers either. Thanks, Neeraj Craig
cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml
craigmcc01/09/25 17:23:28
Modified:tester/src/bin tester.xml
tester/web/WEB-INF web.xml
Added: tester/src/tester/org/apache/tester FilterRequest02.java
FilterRequest02a.java FilterResponse04.java
FilterResponse04a.java
Log:
Port the new unit tests for ensuring correct implementation of Servlet
2.3, Section 6.2.2.
Revision ChangesPath
1.70 +52 -0 jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.69
retrieving revision 1.70
diff -u -r1.69 -r1.70
--- tester.xml2001/09/18 00:08:00 1.69
+++ tester.xml2001/09/26 00:23:28 1.70
@@ -381,6 +381,32 @@
inContent=FilterRequest01 Wrapped Stream PASSED
outContent=FILTERREQUEST01 WRAPPED STREAM PASSED/
+!-- == Servlet Sees Application Wrapper = --
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/FilterRequest02?wrap=false
+ outContent=FilterRequest02 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/WrappedFilterRequest02?wrap=true
+ outContent=FilterRequest02 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/FilterRequest02?wrap=falseamp;dispatch=F
+ outContent=FilterRequest02 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/WrappedFilterRequest02?wrap=trueamp;dispatch=F
+ outContent=FilterRequest02 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/FilterRequest02?wrap=falseamp;dispatch=I
+ outContent=FilterRequest02 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/WrappedFilterRequest02?wrap=trueamp;dispatch=I
+ outContent=FilterRequest02 PASSED/
+
/target
@@ -426,6 +452,32 @@
debug=${debug}
status=200
outContent=FILTERRESPONSE03 PASSED/
+
+!-- == Servlet Sees Application Wrapper = --
+
+tester host=${host} port=${port} protocol=HTTP/1.0
+ request=${context.path}/FilterResponse04?wrap=false debug=${debug}
+ outContent=FilterResponse04 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/WrappedFilterResponse04?wrap=true
+ outContent=FilterResponse04 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/FilterResponse04?wrap=falseamp;dispatch=F
+ outContent=FilterResponse04 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/WrappedFilterResponse04?wrap=trueamp;dispatch=F
+ outContent=FilterResponse04 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/FilterResponse04?wrap=falseamp;dispatch=I
+ outContent=FilterResponse04 PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0 debug=${debug}
+ request=${context.path}/WrappedFilterResponse04?wrap=trueamp;dispatch=I
+ outContent=FilterResponse04 PASSED/
/target
1.2 +126 -0
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/FilterRequest02.java
1.2 +103 -0
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/FilterRequest02a.java
1.2 +126 -0
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/FilterResponse04.java
1.2 +103 -0
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/FilterResponse04a.java
1.51 +60 -0 jakarta-tomcat-4.0/tester/web/WEB-INF/web.xml
Index: web.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/web/WEB-INF/web.xml,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -r1.50 -r1.51
--- web.xml 2001/09/18 00:08:00 1.50
+++ web.xml 2001/09/26 00:23:28 1.51
@@ -149,6 +149,11 @@
/filter-mapping
filter-mapping
+filter-nameHttpFilter/filter-name
+url-pattern/WrappedFilterRequest02/url-pattern
+/filter-mapping
+
+filter-mapping
filter-nameUpperCaseFilter/filter-name
url-pattern/FilterResponse01/url-pattern
/filter-mapping
@@ -195,6 +200,11 @@
filter-mapping
filter-nameHttpFilter/filter-name
+
TC 3.3 + mod_jk + j_security_check
Unless this is now implemented automatically in mod_jk, I think it would be worth mentioning in mod_jk HOWTO about the need to JKMount j_security_check when form authentication is used in applications. I think I should be able to fake a paragraph about it (with examples). Bojan
DO NOT REPLY [Bug 3644] - Errors reloading resources from jars: possible JDK bug
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3644. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3644 Errors reloading resources from jars: possible JDK bug --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 17:37 --- Replicated the problem with JRE 1.3.1, Windows 2000.
cvs commit: jakarta-tomcat-4.0/catalina/src/conf server-noexamples.xml.config server.xml
ccain 01/09/25 17:52:35 Modified:catalina/src/conf Tag: tomcat_40_branch server-noexamples.xml.config server.xml Log: Fix the commented SSL examples in the 4.0 final branch as well. Revision ChangesPath No revision No revision 1.2.2.2 +5 -4 jakarta-tomcat-4.0/catalina/src/conf/server-noexamples.xml.config Index: server-noexamples.xml.config === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server-noexamples.xml.config,v retrieving revision 1.2.2.1 retrieving revision 1.2.2.2 diff -u -r1.2.2.1 -r1.2.2.2 --- server-noexamples.xml.config 2001/09/24 18:30:05 1.2.2.1 +++ server-noexamples.xml.config 2001/09/26 00:52:34 1.2.2.2 @@ -32,15 +32,16 @@ By default, a non-SSL HTTP/1.1 Connector is established on port 8080. You can also enable an SSL HTTP/1.1 Connector on port 8443 by following the instructions below and uncommenting the second Connector - entry. SSL support requires the following steps: + entry. SSL support requires the following steps (see the SSL Config + HOWTO in the Tomcat 4.0 documentation bundle for more detailed + instructions): * Download and install JSSE 1.0.2 or later, and put the JAR files into $JAVA_HOME/jre/lib/ext. - * Edit $JAVA_HOME/jre/lib/security/java.security and add - security.provider.2=com.sun.net.ssl.internal.ssl.Provider * Execute: %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA (Windows) $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA (Unix) - with a password value of changeit. + with a password value of changeit for both the certificate and + the keystore itself. By default, DNS lookups are enabled when a web application calls request.getRemoteHost(). This can have an adverse impact on 1.29.2.2 +5 -4 jakarta-tomcat-4.0/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v retrieving revision 1.29.2.1 retrieving revision 1.29.2.2 diff -u -r1.29.2.1 -r1.29.2.2 --- server.xml2001/09/24 18:30:05 1.29.2.1 +++ server.xml2001/09/26 00:52:34 1.29.2.2 @@ -32,15 +32,16 @@ By default, a non-SSL HTTP/1.1 Connector is established on port 8080. You can also enable an SSL HTTP/1.1 Connector on port 8443 by following the instructions below and uncommenting the second Connector - entry. SSL support requires the following steps: + entry. SSL support requires the following steps (see the SSL Config + HOWTO in the Tomcat 4.0 documentation bundle for more detailed + instructions): * Download and install JSSE 1.0.2 or later, and put the JAR files into $JAVA_HOME/jre/lib/ext. - * Edit $JAVA_HOME/jre/lib/security/java.security and add - security.provider.2=com.sun.net.ssl.internal.ssl.Provider * Execute: %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA (Windows) $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA (Unix) - with a password value of changeit. + with a password value of changeit for both the certificate and + the keystore itself. By default, DNS lookups are enabled when a web application calls request.getRemoteHost(). This can have an adverse impact on
Re: TC 3.3 + mod_jk + j_security_check
This is now implemented automatically in the ApacheConfig module. By default it does: JkMount /myapp/* ajp13 Turning this off (via forwardAll=false), then it outputs all of the defined mappings (including j_security_check for form auth contexts). - Original Message - From: Bojan Smojver [EMAIL PROTECTED] To: Tomcat Dev List [EMAIL PROTECTED] Sent: Tuesday, September 25, 2001 5:34 PM Subject: TC 3.3 + mod_jk + j_security_check Unless this is now implemented automatically in mod_jk, I think it would be worth mentioning in mod_jk HOWTO about the need to JKMount j_security_check when form authentication is used in applications. I think I should be able to fake a paragraph about it (with examples). Bojan ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config manager.xml
craigmcc01/09/25 18:37:15 Modified:webapps/tomcat-docs/config Tag: tomcat_40_branch manager.xml Log: Update the server configuration information about the Manager element to include information that used to be available on the JDBCStore-howto page. Revision ChangesPath No revision No revision 1.1.2.1 +284 -2jakarta-tomcat-4.0/webapps/tomcat-docs/config/manager.xml Index: manager.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/manager.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- manager.xml 2001/08/25 20:06:30 1.1 +++ manager.xml 2001/09/26 01:37:15 1.1.2.1 @@ -75,6 +75,14 @@ subsection name=Standard Implementation +pTomcat provides two standard implementations of strongManager/strong +for use - the default one stores active sessions, while the optional one +stores active sessions that have been swapped out (in addition to saving +sessions across a restart of Tomcat) in a storage location that is selected +via the use of an appropriate strongStore/strong nested element./p + +h3Standard Manager Implementation/h3 + pThe standard implementation of strongManager/strong is strongorg.apache.catalina.session.StandardManager/strong. It supports the following additional attributes (in addition to the @@ -95,7 +103,7 @@ /attribute attribute name=debug required=false -pThe level of debugging detail logged by this strongEngine/strong +pThe level of debugging detail logged by this strongManager/strong to the associated a href=logger.htmlLogger/a. Higher numbers generate more detailed output. If not specified, the default debugging detail level is zero (0)./p @@ -130,6 +138,110 @@ /attributes +h3Persistent Manager Implementation/h3 + +pemstrongWARNING - Use of this Manager implementation +has not been thoroughly tested, and should be considered experimental! +/strong/em/p + +pThe persistent implementation of strongManager/strong is +strongorg.apache.catalina.session.PersistentManager/strong. In +addition to the usual operations of creating and deleting sessions, a +codePersistentManager/code has the capability to swap active (but +idle) sessions out to a persistent storage mechanism, as well as to save +all sessions across a normal restart of Tomcat. The actual persistent +storage mechanism used is selected by your choice of a +strongStore/strong element nested inside the strongManager/strong +element - this is required for use of codePersistentManager/code./p + +pThis implementation of Manager supports the following attributes in +addition to the a href=#Common AttributesCommon Attributes/a +described earlier./p + +attributes + + attribute name=algorithm required=false +pName of the emMessage Digest/em algorithm used to calculate +session identifiers produced by this Manager. This value must +be supported by the codejava.security.MessageDigest/code class. +If not specified, the default value is MD5./p + /attribute + + attribute name=checkInterval required=false +pThe number of seconds between checks for expired sessions +for this Manager. The default value is 60 seconds./p + /attribute + + attribute name=className required=false +pJava class name of the implementation to use. This class must +implement the codeorg.apache.catalina.Manager/code interface. +You strongmust/strong specify +codeorg.apache.catalina.session.PersistentManager/code to use +this manager implementation./p + /attribute + + attribute name=debug required=false +pThe level of debugging detail logged by this strongManager/strong +to the associated a href=logger.htmlLogger/a. Higher numbers +generate more detailed output. If not specified, the default +debugging detail level is zero (0)./p + /attribute + + attribute name=entropy required=false +pA String value that is utilized when seeding the random number +generator used to create session identifiers for this Manager. +If not specified, a semi-useful value is calculated, but a long +String value should be specified in security-conscious +environments./p + /attribute + + attribute name=maxActiveSessions required=false +pThe maximum number of active sessions that will be created by +this Manager, or -1 (the default) for no limit./p + /attribute + +
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config manager.xml
craigmcc01/09/25 18:38:08 Modified:webapps/tomcat-docs/config manager.xml Log: Port Manager documentation update about JDBCStore. Revision ChangesPath 1.2 +284 -2jakarta-tomcat-4.0/webapps/tomcat-docs/config/manager.xml Index: manager.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/manager.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- manager.xml 2001/08/25 20:06:30 1.1 +++ manager.xml 2001/09/26 01:38:08 1.2 @@ -75,6 +75,14 @@ subsection name=Standard Implementation +pTomcat provides two standard implementations of strongManager/strong +for use - the default one stores active sessions, while the optional one +stores active sessions that have been swapped out (in addition to saving +sessions across a restart of Tomcat) in a storage location that is selected +via the use of an appropriate strongStore/strong nested element./p + +h3Standard Manager Implementation/h3 + pThe standard implementation of strongManager/strong is strongorg.apache.catalina.session.StandardManager/strong. It supports the following additional attributes (in addition to the @@ -95,7 +103,7 @@ /attribute attribute name=debug required=false -pThe level of debugging detail logged by this strongEngine/strong +pThe level of debugging detail logged by this strongManager/strong to the associated a href=logger.htmlLogger/a. Higher numbers generate more detailed output. If not specified, the default debugging detail level is zero (0)./p @@ -130,6 +138,110 @@ /attributes +h3Persistent Manager Implementation/h3 + +pemstrongWARNING - Use of this Manager implementation +has not been thoroughly tested, and should be considered experimental! +/strong/em/p + +pThe persistent implementation of strongManager/strong is +strongorg.apache.catalina.session.PersistentManager/strong. In +addition to the usual operations of creating and deleting sessions, a +codePersistentManager/code has the capability to swap active (but +idle) sessions out to a persistent storage mechanism, as well as to save +all sessions across a normal restart of Tomcat. The actual persistent +storage mechanism used is selected by your choice of a +strongStore/strong element nested inside the strongManager/strong +element - this is required for use of codePersistentManager/code./p + +pThis implementation of Manager supports the following attributes in +addition to the a href=#Common AttributesCommon Attributes/a +described earlier./p + +attributes + + attribute name=algorithm required=false +pName of the emMessage Digest/em algorithm used to calculate +session identifiers produced by this Manager. This value must +be supported by the codejava.security.MessageDigest/code class. +If not specified, the default value is MD5./p + /attribute + + attribute name=checkInterval required=false +pThe number of seconds between checks for expired sessions +for this Manager. The default value is 60 seconds./p + /attribute + + attribute name=className required=false +pJava class name of the implementation to use. This class must +implement the codeorg.apache.catalina.Manager/code interface. +You strongmust/strong specify +codeorg.apache.catalina.session.PersistentManager/code to use +this manager implementation./p + /attribute + + attribute name=debug required=false +pThe level of debugging detail logged by this strongManager/strong +to the associated a href=logger.htmlLogger/a. Higher numbers +generate more detailed output. If not specified, the default +debugging detail level is zero (0)./p + /attribute + + attribute name=entropy required=false +pA String value that is utilized when seeding the random number +generator used to create session identifiers for this Manager. +If not specified, a semi-useful value is calculated, but a long +String value should be specified in security-conscious +environments./p + /attribute + + attribute name=maxActiveSessions required=false +pThe maximum number of active sessions that will be created by +this Manager, or -1 (the default) for no limit./p + /attribute + + attribute name=maxIdleBackup required=false +pThe time interval (in seconds) since the last access to a session +before it is eligible for being persisted to the session store, or +
DO NOT REPLY [Bug 3712] - need to setup custom error page when somebody accesses stopped web application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3712. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3712 need to setup custom error page when somebody accesses stopped web application [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 18:49 --- Deferred until a later release (unless someone comes up with a patch that accomplishes this feature).
DO NOT REPLY [Bug 3776] - Illegal to flush within a custom tag exceptions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3776. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3776 Illegal to flush within a custom tag exceptions [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 18:57 --- Without seeing your stack trace, it is impossible to know what the problem is for certain. However, there was a significant change between 4.0-b7 and 4.0 final that *might* have been related. The JavaDocs for the PageContext.include() method include the statement: The current JspWriter out for this JSP is flushed as a side effect of this call, prior to processing the include. Tomcat 4.0-b7 did not correctly implement this method, because it didn't do the flush. Flushing the response was added in Release Candidate 1 in order to be compliant with the specification requirments. If you don't believe that this was the cause of your problem, please reopen this bug report - but in order to be able to debug it, you should provide an example JSP page that illustrates the problem, plus the stack trace that is generated. Without this, little useful debugging is possible.
[PATCH] TC4.0 Improvements in validator messages
This patch addresses the problems raised in bug#3367 and #3368. All
the messages from all validators are now displayed, without the stack
trace.
misto% pwd
/home/kchung/tomcat/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper
misto% cat JasperError.java
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.jasper;
/**
* Errors generated by the JSP engine. It differs from JasperException in
* that it does not print stack trace.
*
* @author Kin-man Chung
*/
public class JasperError extends org.apache.jasper.JasperException {
public JasperError(String reason) {
super(reason);
}
}
misto% runsocks cvs diff -u compiler/JspParseEventListener.java
Index: compiler/JspParseEventListener.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/J
spParseEventListener.java,v
retrieving revision 1.33
diff -u -r1.33 JspParseEventListener.java
--- compiler/JspParseEventListener.java 2001/07/25 01:08:13 1.33
+++ compiler/JspParseEventListener.java 2001/09/26 01:49:02
@@ -78,10 +78,10 @@
import javax.servlet.jsp.tagext.TagLibraryInfo;
import javax.servlet.jsp.tagext.ValidationMessage;
+import org.apache.jasper.JasperError;
import org.apache.jasper.JasperException;
import org.apache.jasper.Constants;
import org.apache.jasper.JspCompilationContext;
-
import org.apache.jasper.logging.Logger;
import org.xml.sax.Attributes;
@@ -1114,7 +1114,9 @@
* libraries used by the document.
*/
public void validate() throws JasperException {
+ StringBuffer errMessage = new StringBuffer();
Enumeration enum = libraries.getTagLibInfos();
+boolean hasErrors = false;
while (enum.hasMoreElements()) {
TagLibraryInfo tli = (TagLibraryInfo)enum.nextElement();
//@@@ remove cast when TagLibraryInfo is fixed in spec
@@ -1122,14 +1124,23 @@
ValidationMessage[] errors =
((TagLibraryInfoImpl)tli).validate(xo.getPageData());
if ((errors != null) (errors.length != 0)) {
- // for now just report the first error!
- String msg = errors[0].getMessage();
-throw new JasperException(
- Constants.getString(
-jsp.error.taglibraryvalidator.invalidpage,
- new Object[]{tli.getShortName(), msg}));
+
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config engine.xml host.xml logger.xml server.xml service.xml valve.xml
craigmcc01/09/25 19:28:07 Modified:webapps/tomcat-docs/config Tag: tomcat_40_branch engine.xml host.xml logger.xml server.xml service.xml valve.xml Log: A variety of documentation updates and clarifications to the Server Configuration Reference. PR: Bugzilla #3780 Submitted by: Dylan Schell [EMAIL PROTECTED] Revision ChangesPath No revision No revision 1.1.2.1 +4 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/config/engine.xml Index: engine.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/engine.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- engine.xml2001/08/25 01:14:13 1.1 +++ engine.xml2001/09/26 02:28:07 1.1.2.1 @@ -96,6 +96,10 @@ have a name that matches the name specified for the codedefaultHost/code attribute, listed above./p + pYou can optional nest a a href=defaultcontext.htmlDefaultContext/a + element inside this strongEngine/strong element, to define the default + characteristics of web applications that are automatically deployed./p + pYou can nest at most one instance of the following utility components by nesting a corresponding element inside your strongEngine/strong element:/p 1.2.2.1 +4 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/config/host.xml Index: host.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/host.xml,v retrieving revision 1.2 retrieving revision 1.2.2.1 diff -u -r1.2 -r1.2.2.1 --- host.xml 2001/08/27 20:22:37 1.2 +++ host.xml 2001/09/26 02:28:07 1.2.2.1 @@ -130,6 +130,10 @@ single a href=defaultcontext.htmlDefaultContext/a element that defines default values for subsequently deployed web applications./p + pYou can optional nest a a href=defaultcontext.htmlDefaultContext/a + element inside this strongHost/strong element, to define the default + characteristics of web applications that are automatically deployed./p + pYou can nest at most one instance of the following utility components by nesting a corresponding element inside your strongHost/strong element:/p 1.2.2.1 +8 -1 jakarta-tomcat-4.0/webapps/tomcat-docs/config/logger.xml Index: logger.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/logger.xml,v retrieving revision 1.2 retrieving revision 1.2.2.1 diff -u -r1.2 -r1.2.2.1 --- logger.xml2001/08/27 20:22:37 1.2 +++ logger.xml2001/09/26 02:28:07 1.2.2.1 @@ -23,6 +23,13 @@ In addition, Loggers associated with an Engine or a Host are automatically inherited by lower-level containers, unless explicitly overridden./p + pIf you are interested in producing access logs like a web server does + (for example, to run hit count analysis software), you will want to configure + an a href=valve.html#Access Log ValveAccess Log Valve/a component on + your a href=engine.html#Access LogsEngine/a, + a href=host.html#Access LogsHost/a, or + a href=context.html#Access LogsContext/a./p + pFor a more in-depth description of the class loader hierarchy that is implemented by Catalina, see strongFIXME - Reference/strong./p @@ -53,7 +60,7 @@ implement the codeorg.apache.catalina.Logger/code interface./p /attribute - attribute + attribute name=verbosity required=false pThe verbosity level for this logger. Messages with a higher verbosity level than the specified value will be silently ignored. Available levels are 0 (fatal messages only), 1 (errors), 2 1.2.2.1 +2 -3 jakarta-tomcat-4.0/webapps/tomcat-docs/config/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/server.xml,v retrieving revision 1.2 retrieving revision 1.2.2.1 diff -u -r1.2 -r1.2.2.1 --- server.xml2001/08/25 01:14:13 1.2 +++ server.xml2001/09/26 02:28:07 1.2.2.1 @@ -67,9 +67,8 @@ section name=Nested Components - pNo nested components may be embedded inside a strongServer/strong, - element, except for one or more a href=service.htmlService/a elements. - /p + pThe only components that may be nested inside a strongServer/strong + element are one or more a href=service.htmlService/a elements./p /section 1.2.2.1 +3 -4 jakarta-tomcat-4.0/webapps/tomcat-docs/config/service.xml Index: service.xml
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config engine.xml host.xml logger.xml server.xml service.xml valve.xml
craigmcc01/09/25 19:29:21 Modified:webapps/tomcat-docs/config engine.xml host.xml logger.xml server.xml service.xml valve.xml Log: Port documentation updates. Revision ChangesPath 1.2 +4 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/config/engine.xml Index: engine.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/engine.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- engine.xml2001/08/25 01:14:13 1.1 +++ engine.xml2001/09/26 02:29:21 1.2 @@ -96,6 +96,10 @@ have a name that matches the name specified for the codedefaultHost/code attribute, listed above./p + pYou can optional nest a a href=defaultcontext.htmlDefaultContext/a + element inside this strongEngine/strong element, to define the default + characteristics of web applications that are automatically deployed./p + pYou can nest at most one instance of the following utility components by nesting a corresponding element inside your strongEngine/strong element:/p 1.3 +4 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/config/host.xml Index: host.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/host.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- host.xml 2001/08/27 20:22:37 1.2 +++ host.xml 2001/09/26 02:29:21 1.3 @@ -130,6 +130,10 @@ single a href=defaultcontext.htmlDefaultContext/a element that defines default values for subsequently deployed web applications./p + pYou can optional nest a a href=defaultcontext.htmlDefaultContext/a + element inside this strongHost/strong element, to define the default + characteristics of web applications that are automatically deployed./p + pYou can nest at most one instance of the following utility components by nesting a corresponding element inside your strongHost/strong element:/p 1.3 +8 -1 jakarta-tomcat-4.0/webapps/tomcat-docs/config/logger.xml Index: logger.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/logger.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- logger.xml2001/08/27 20:22:37 1.2 +++ logger.xml2001/09/26 02:29:21 1.3 @@ -23,6 +23,13 @@ In addition, Loggers associated with an Engine or a Host are automatically inherited by lower-level containers, unless explicitly overridden./p + pIf you are interested in producing access logs like a web server does + (for example, to run hit count analysis software), you will want to configure + an a href=valve.html#Access Log ValveAccess Log Valve/a component on + your a href=engine.html#Access LogsEngine/a, + a href=host.html#Access LogsHost/a, or + a href=context.html#Access LogsContext/a./p + pFor a more in-depth description of the class loader hierarchy that is implemented by Catalina, see strongFIXME - Reference/strong./p @@ -53,7 +60,7 @@ implement the codeorg.apache.catalina.Logger/code interface./p /attribute - attribute + attribute name=verbosity required=false pThe verbosity level for this logger. Messages with a higher verbosity level than the specified value will be silently ignored. Available levels are 0 (fatal messages only), 1 (errors), 2 1.3 +2 -3 jakarta-tomcat-4.0/webapps/tomcat-docs/config/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/server.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- server.xml2001/08/25 01:14:13 1.2 +++ server.xml2001/09/26 02:29:21 1.3 @@ -67,9 +67,8 @@ section name=Nested Components - pNo nested components may be embedded inside a strongServer/strong, - element, except for one or more a href=service.htmlService/a elements. - /p + pThe only components that may be nested inside a strongServer/strong + element are one or more a href=service.htmlService/a elements./p /section 1.3 +3 -4 jakarta-tomcat-4.0/webapps/tomcat-docs/config/service.xml Index: service.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/service.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- service.xml 2001/08/25 01:14:13 1.2 +++ service.xml 2001/09/26 02:29:21 1.3 @@
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler TagBeginGenerator.java
craigmcc01/09/25 19:37:13
Modified:jasper/src/share/org/apache/jasper/compiler
TagBeginGenerator.java
Log:
Fix generated code for custom tag attributes of type Object, which are
required to accept a literal String value. Patch supplied by Kin-Man
Chung [EMAIL PROTECTED]
PR: Bugzilla #3707
Submitted by: Hans Bergsten [EMAIL PROTECTED]
Revision ChangesPath
1.16 +1 -1
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagBeginGenerator.java
Index: TagBeginGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagBeginGenerator.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- TagBeginGenerator.java2001/09/07 00:18:49 1.15
+++ TagBeginGenerator.java2001/09/26 02:37:13 1.16
@@ -301,7 +301,7 @@
} else if (c == Long.class) {
return new Long( + Long.valueOf(s).toString() + l);
} else if (c == Object.class) {
-return new String( + s + );
+return new String( + writer.quoteString(s) + );
} else {
return ( + c.getName() +
)JspRuntimeLibrary.getValueFromPropertyEditorManager( +
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler TagBeginGenerator.java
craigmcc01/09/25 19:38:06
Modified:jasper/src/share/org/apache/jasper/compiler Tag:
tomcat_40_branch TagBeginGenerator.java
Log:
Port fix for custom tag attributes of type Object.
PR: Bugzilla #3707
Submitted by: Hans Bergsten [EMAIL PROTECTED]
Revision ChangesPath
No revision
No revision
1.15.2.1 +1 -1
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagBeginGenerator.java
Index: TagBeginGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagBeginGenerator.java,v
retrieving revision 1.15
retrieving revision 1.15.2.1
diff -u -r1.15 -r1.15.2.1
--- TagBeginGenerator.java2001/09/07 00:18:49 1.15
+++ TagBeginGenerator.java2001/09/26 02:38:06 1.15.2.1
@@ -301,7 +301,7 @@
} else if (c == Long.class) {
return new Long( + Long.valueOf(s).toString() + l);
} else if (c == Object.class) {
-return new String( + s + );
+return new String( + writer.quoteString(s) + );
} else {
return ( + c.getName() +
)JspRuntimeLibrary.getValueFromPropertyEditorManager( +
DO NOT REPLY [Bug 3707] - Custom action attribute of type Object does not accept literal string value
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3707. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3707 Custom action attribute of type Object does not accept literal string value [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 19:46 --- Fixed in nightly build. Will be fixed in Tomcat 4.0.1.
Re: TC 3.3 + mod_jk + j_security_check
What if the only mapping is for instance: JkMount /*.jsp ajp13 Will it still work? Bojan Bill Barker wrote: This is now implemented automatically in the ApacheConfig module. By default it does: JkMount /myapp/* ajp13 Turning this off (via forwardAll=false), then it outputs all of the defined mappings (including j_security_check for form auth contexts). - Original Message - From: Bojan Smojver [EMAIL PROTECTED] To: Tomcat Dev List [EMAIL PROTECTED] Sent: Tuesday, September 25, 2001 5:34 PM Subject: TC 3.3 + mod_jk + j_security_check Unless this is now implemented automatically in mod_jk, I think it would be worth mentioning in mod_jk HOWTO about the need to JKMount j_security_check when form authentication is used in applications. I think I should be able to fake a paragraph about it (with examples). Bojan ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
DO NOT REPLY [Bug 3763] - Missing CATALINA_CLASSPATH env or Context/Classpath element
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3763. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3763 Missing CATALINA_CLASSPATH env or Context/Classpath element [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 19:50 --- People who understand enough about class paths to keep themselves out of trouble are also able to create their own customized versions of the catalina.bat and catalina.sh startup scripts. I'm sure such enterprising users will also maintain a place where current versions of such a script can be downloaded. It doesn't need to be changed in the standard distribution.
Re: DO NOT REPLY [Bug 3763] - Missing CATALINA_CLASSPATH env or Context/Classpath element
Quoting [EMAIL PROTECTED]: --- Additional Comments From [EMAIL PROTECTED] 2001-09-25 19:50 --- [snip] People who understand enough about class paths to keep themselves out of trouble are also able to create their own customized versions of the catalina.bat and catalina.sh startup scripts.. +1 - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
