DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid url-pattern in servlet mapping
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=13014. 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=13014 OS/390/USS - Invalid url-pattern in servlet mapping --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 06:50 --- What is the procedure for distributing a fix as described by Seyed Ali Madani ? The fix is for v4.0.6 but the problem is reported under v4.1.10. And shouldn't the fixed binary be distributed from Apache's web site instead of distributing it personnaly ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid url-pattern in servlet mapping
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=13014. 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=13014 OS/390/USS - Invalid url-pattern in servlet mapping --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 07:10 --- Usually, what happens is that someone contributes a patch. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: 4.0.7 release?
on 2002/10/24 1:12 AM, Henri Gomez [EMAIL PROTECTED] wrote: Do you plan to make scarab works with 4.1.x ? Read: http://scarab.tigris.org/faq.html Blame the Xerces team for breaking backwards compatibility. Bah. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: 4.0.7 release?
Jon Scott Stevens wrote: on 2002/10/24 1:12 AM, Henri Gomez [EMAIL PROTECTED] wrote: Do you plan to make scarab works with 4.1.x ? Read: http://scarab.tigris.org/faq.html Blame the Xerces team for breaking backwards compatibility. Bah. Ok, so we should wait an updated version of Scarab ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13011] - mod_jk2.c (CVS v 1.53) compile messages
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=13011. 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=13011 mod_jk2.c (CVS v 1.53) compile messages [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 08:55 --- These warning covers apr types and shouldn't be marked as error. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 10895] - access log contains scrambled text when using Coyote JK 2 connector
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=10895. 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=10895 access log contains scrambled text when using Coyote JK 2 connector [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 08:57 --- Didn't see such behaviour on my systems which use latest Apache 2.0 and jk2 -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Security Check in Classloader.
Jean-Francois Arcand wrote:
Hi,
In StandardClassLoader, starting line 815, the SecurityManager is invoked:
// (.5) Permission to access this class when using a SecurityManager
if (securityManager != null) {
int i = name.lastIndexOf('.');
if (i = 0) {
try {
securityManager.checkPackageAccess(name.substring(0,i));
} catch (SecurityException se) {
String error = Security Violation, attempt to use +
Restricted Class: + name;
System.out.println(error);
se.printStackTrace();
log(error);
throw new ClassNotFoundException(error);
}
}
}
Why are we calling the SecurityManager.checkPackageAccess in
StandardClassLoader? Since we give all permissions to
org.apache.catalina, I think this call is useless. This call is required
when invoked inside WebappClassLoader.
Because a paranoid Tomcat admin like me may not grant AllPermission to catalina
in their security policy.
Regards,
Glenn
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: 4.0.7 release?
I have scarab running in Tomcat 4.1.12. Though I can't say that we have tried all the features of scarab like XML import/export. Glenn Henri Gomez wrote: Jon Scott Stevens wrote: Can I get a 4.0.7 release? It has an important configuration bug fix that I need for Scarab. Hi Jon, I tried to use Scarab with 4.1.12 but it didn't works. Do you plan to make scarab works with 4.1.x ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: [JK2] RedHat 8.0 JNI totaly bogus
-Original Message- From: Henri Gomez I didn't tried RH 8.0 yet, but the experience I've got from RH 7.2 with JNI make me some serious headaches. Before launching Apache 2.0 you need : 1) set the LD_LIBRARY_PATH export LD_LIBRARY_PATH=$jre/bin:$jre/bin/classic:$LD_LIBRARY_PATH Thanks man, that's the cache! For 1.4.1/RH8: export LD_LIBRARY_PATH=$JAVA_HOME/jre/lib/i386:$JAVA_HOME/jre/lib/i386/client:$ LD_LIBRARY_PATH 2) make JDK use the non floating stacks export LD_ASSUME_KERNEL=2.2.5 No need for that to start the JVM, but will check how it works. But important: 'which java' _must_ point to the jre/bin/java so jre's path has to precede jdk one, like $JAVA_HOME/jre/bin:$JAVA_HOME/bin MT. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13040] - can't retrieve external context who's uri is a sub-dir of current context
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=13040.
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=13040
can't retrieve external context who's uri is a sub-dir of current context
--- Additional Comments From [EMAIL PROTECTED] 2002-10-24 09:33 ---
That doesn't fix it properly. To trigger the optimisation you would need to send
in the uri /store/ to get a match. Agreed that if we can ditch handling the
/store/common uri, we could make this work much easier.
--- ApplicationContext.java-2002-10-21 Mon Sep 23 11:23:16 2002
+++ ApplicationContext.java Thu Oct 24 10:30:56 2002
@@ -439,12 +439,13 @@
return (null);
// Return the current context if requested
-String contextPath = context.getPath();
-if (!contextPath.endsWith(/))
-contextPath = contextPath + /;
-if ((contextPath.length() 0) (uri.startsWith(contextPath))) {
-return (this);
-}
+ String contextPath = context.getPath();
+ if ( contextPath.equals( ) uri.equals( / ) ||
+!contextPath.equals( ) uri.equals( contextPath ) ) {
+ return (this);
+ }
+
+ System.out.println( context.getCrossContext() );
// Return other contexts only if allowed
if (!context.getCrossContext())
Martin Algesten
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [JK2] RedHat 8.0 JNI totaly bogus
Mladen Turk wrote: -Original Message- From: Henri Gomez I didn't tried RH 8.0 yet, but the experience I've got from RH 7.2 with JNI make me some serious headaches. Before launching Apache 2.0 you need : 1) set the LD_LIBRARY_PATH export LD_LIBRARY_PATH=$jre/bin:$jre/bin/classic:$LD_LIBRARY_PATH Thanks man, that's the cache! Did it works now ? For 1.4.1/RH8: export LD_LIBRARY_PATH=$JAVA_HOME/jre/lib/i386:$JAVA_HOME/jre/lib/i386/client:$ LD_LIBRARY_PATH 2) make JDK use the non floating stacks export LD_ASSUME_KERNEL=2.2.5 No need for that to start the JVM, but will check how it works. There is good information about floating stack in IBM SDK But important: 'which java' _must_ point to the jre/bin/java so jre's path has to precede jdk one, like $JAVA_HOME/jre/bin:$JAVA_HOME/bin Are you using IBM, Sun or Blackdown SDK ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid url-pattern in servlet mapping
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=13014. 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=13014 OS/390/USS - Invalid url-pattern in servlet mapping --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 09:48 --- Created an attachment (id=3596) attachment file #1 for binary fix of bug 13014 on tomcat 4.0.6 -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid url-pattern in servlet mapping
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=13014. 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=13014 OS/390/USS - Invalid url-pattern in servlet mapping --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 09:51 --- Created an attachment (id=3597) attachment file #2 for binary fix of bug 13014 on tomcat 4.0.6 -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: [JK2] RedHat 8.0 JNI totaly bogus
-Original Message- From: Henri Gomez Did it works now ? Yes. For 1.4.1/RH8: export LD_LIBRARY_PATH=$JAVA_HOME/jre/lib/i386:$JAVA_HOME/jre/lib/i386/client :$ LD_LIBRARY_PATH 2) make JDK use the non floating stacks export LD_ASSUME_KERNEL=2.2.5 No need for that to start the JVM, but will check how it works. There is good information about floating stack in IBM SDK Will check. But important: 'which java' _must_ point to the jre/bin/java so jre's path has to precede jdk one, like $JAVA_HOME/jre/bin:$JAVA_HOME/bin Are you using IBM, Sun or Blackdown SDK ? Sun's 1.4.1_01 Still, I found that JVM kills the process that started it when calling JNI_CreateJavaVM (that doesn't happens on WIN32, cause error is returned instead), if the jvm could not be loaded. Makes no sense at all. This forces Apache to restart the child process, calling create again, and all that is going in the infinite loop. Very bad :(. MT. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid url-pattern in servlet mapping
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=13014. 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=13014 OS/390/USS - Invalid url-pattern in servlet mapping --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 10:02 --- Hi all I wrote the detailed instructions for using binary fixes for tomact 4.0.6 in response to someone ask me in OE mailing list which appended below,and the attachments are also attached to bug 13014. and about the source of problem : It is created by URLDecode method,i mean everywhere this method is called without specifying the 8859_1 encoding it assumes the defult encoding that on OS/390 is IBM-1047 so I searched the entire source and found that it must be changed to URLDecode(,8859_1) in the following source files: org.apache.catalina.core.StandardContext.java org.apache.catalina.core.StandardContextMapper.java org.apache.catalina.authenticator.AuthenticatorBase.java org.apache.catalina.deploy.ErrorPage.java org.apache.catalina.deploy.SecurityCollection.java org.apache.catalina.deploy.FilterMap.java org.apache.catalina.deploy.LoginConfig.java Detailed instructions for binary fix 1. Download and unpack the jakarta-tomat-4.0.6.zip from : http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.6/bin/ (The jakarta-tomcat-4.0.6.tar.gz is defective and should not be used) 2. You should have JAVA 1.3 or greater on your system installed and the JAVA_HOME environment variable point to its installation path. 3. Using oeditascii utility (can get from IBM OS390 unix system services tools and toys home page) change the server.xml file in conf directory and set the port that tomcat listen for incomming requests on it,if you do not change this port the default will be 8080. 4. There are two attachments to this email ,you should ftp them to USS in binary format. 5. Remove the bin directory in the path you have installed Tomcat, and then untar the first attachment file bindir.tar for example if i installed the tomcat in /home/jakarta-tomcat-4.0.6 directory and also have ftpied the bindir.tar attachment file to this directory, i should run the following commands in OMVS shell: cd /home/jakarta-tomcat-4.0.6 pwd (ensure that you are in your tomcat installation path,to not delete system /bin directory accidentally) rm -rf bin tar xvf bindir.tar 6. Replace the catalina.jar file with the second attachment file , the catalina.jar file located in server/lib directory in your catalina installation path. (for example in /home/jakarta- tomcat-4.0.6/server/lib) 7. Export the environment variable CATALINA_HOME pointing to your tomcat installation directory . (for example: export CATALINA_HOME= /home/jakarta-tomcat-4.0.6) 8. change current directory to bin and run startup.sh shell script. for example: cd /home/jakarta-tomcat-4.0.6/bin ./startup.sh 9. you can then check tomcat with entering the following url in your browser: http://your- host- ip- address:8080 10. In the case of any problem refer to log files in logs directory in your installation path.(for example : /home/jakarta-tomcat-4.0.6/logs) I hope it would be useful. Thanks Ali Madani -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13907] - security manager does not give read permission on a context by default
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=13907. 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=13907 security manager does not give read permission on a context by default [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 10:03 --- I just tested the jsp you posted with a fresh build of Tomcat 4.1 from the CVS head (What will be Tomcat 4.1.13) and Jasper 2. The FilePermission read for the context directory is being granted automatically and the JSP works. This must be a problem in your local system configuration. Check the unix file ownerhsip and permissions for test2.new. Also try running Tomcat with java property -Djava.security.debug=access,failure defined and then check the security manager debug output. One final note, I would not grant the permission java.io.FilePermission ALL FILES, read; to a web application, I would consider that a security risk. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13924] New: - error-page directive does not always work correctly
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=13924. 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=13924 error-page directive does not always work correctly Summary: error-page directive does not always work correctly Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Under certain conditions, the default exception report is shown, instead of the location configured in the web.xml deployment descriptor. Unfortunately, the unit tests included with the tester application in the Tomcat sources test for neither of the two conditions under which the error occurs: 1) If the web.xml declares it wants to catch a subtype of ServletException, like this: error-page exception- typeorg.apache.tester.TesterServletException /exception-type location/ErrorPage04/location /error-page and the exception is thrown from a servlet, like this: throw new TesterServletException (new Tester2Exception(ErrorPage031 Threw Exception)); then we are not redirected to the given location, but the default Exception Report is shown instead. However, if the same exception is thrown from a JSP, like this % if( true ) throw new org.apache.tester.TesterServletException( new org.apache.tester.Tester2Exception(TesterPage031.jsp Threw Exception)); % then we are redirected correctly. 2) Conversely, if the web.xml declares it wants to catch an exception embedded in a ServletException, like this: error- page exception-typeorg.apache.tester.TesterException/exception-type location/ErrorPage04/location /error-page and the exception is thrown from a JSP, like this % if( true ) throw new javax.servlet.ServletException( new org.apache.tester.TesterException(TesterPage03.jsp Threw Exception)); % then we are not redirected to the given location, but the default Exception Report is shown instead. All this can be reproduced in the tester application: I have written - 2 Test pages TesterPage03.jsp and TesterPage031.jsp - the classes org.apache.tester.Tester2Exception.java, org.apache.tester.TesterServletException.java - a servlet org.apache.tester.ErrorPage031.java, and included the relevant configuration in the web.xml. Is there any way for me to attach my code to this bug report for you to use? I am using JDK 1.3.1. The behavior is independent of whether the web.xml conforms to the web- app_2_3.dtd or the web-app_2_2.dtd -- Sebastian Millies -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid url-pattern in servlet mapping
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=13014. 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=13014 OS/390/USS - Invalid url-pattern in servlet mapping --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 10:15 --- Remy Maucherat, what next ? How does it work ? Someone would pick up from Ali's suggested fix and incorporate into the next distribution ? Who ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13924] - error-page directive does not always work correctly
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=13924. 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=13924 error-page directive does not always work correctly --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 10:21 --- Created an attachment (id=3598) zip file containing code to reproduce bug 13924 in tester application -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid url-pattern in servlet mapping
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=13014. 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=13014 OS/390/USS - Invalid url-pattern in servlet mapping --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 10:35 --- There are obvious benefits to using the platform encoding to read the config files, so we'll have to consider if that kind of patch will be merged. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-5 build.properties.default
remm2002/10/24 04:48:51
Modified:.build.properties.default
Log:
- Update version numbers.
Revision ChangesPath
1.46 +8 -8 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- build.properties.default 17 Oct 2002 06:49:54 - 1.45
+++ build.properties.default 24 Oct 2002 11:48:51 - 1.46
-46,17 +46,17
# - Commons Beanutils, version 1.4 or later -
-commons-beanutils.home=${base.path}/commons-beanutils-1.4.1
+commons-beanutils.home=${base.path}/commons-beanutils-1.5
commons-beanutils.lib=${commons-beanutils.home}
commons-beanutils.jar=${commons-beanutils.lib}/commons-beanutils.jar
-commons-beanutils.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils/v1.4.1/commons-beanutils-1.4.1.tar.gz
+commons-beanutils.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils/v1.5/commons-beanutils-1.5.tar.gz
# - Commons Collections, version 2.0 or later -
-commons-collections.home=${base.path}/commons-collections-2.0
+commons-collections.home=${base.path}/commons-collections-2.1
commons-collections.lib=${commons-collections.home}
commons-collections.jar=${commons-collections.lib}/commons-collections.jar
-commons-collections.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-collections/v2.0/commons-collections-2.0.tar.gz
+commons-collections.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-collections/v2.1/commons-collections-2.1.tar.gz
# - Commons Launcher, version 20021012 or later -
-118,10 +118,10
activation.jar=${activation.lib}/activation.jar
# - Log4j -
-log4j.home=${base.path}/jakarta-log4j-1.2.6
+log4j.home=${base.path}/jakarta-log4j-1.2.7
log4j.lib=${log4j.home}
-log4j.jar=${log4j.lib}/dist/lib/log4j-1.2.6.jar
-log4j.loc=http://jakarta.apache.org/log4j/jakarta-log4j-1.2.6.tar.gz
+log4j.jar=${log4j.lib}/dist/lib/log4j-1.2.7.jar
+log4j.loc=http://jakarta.apache.org/log4j/jakarta-log4j-1.2.7.tar.gz
# - LogKit -
logkit.home=${base.path}/LogKit-1.1
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java
remm2002/10/24 04:55:57
Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch Compiler.java
Log:
- Port javac syncing patch.
Revision ChangesPath
No revision
No revision
1.18.2.7 +10 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.18.2.6
retrieving revision 1.18.2.7
diff -u -r1.18.2.6 -r1.18.2.7
--- Compiler.java 16 Sep 2002 13:39:20 - 1.18.2.6
+++ Compiler.java 24 Oct 2002 11:55:57 - 1.18.2.7
-109,6 +109,10
}
+// Some javac are not thread safe; use a lock to serialize compilation,
+static Object javacLock = new Object();
+
+
// - Instance Variables
-288,7 +292,9
includes.setName(ctxt.getJspPath());
try {
-javac.execute();
+synchronized(javacLock) {
+javac.execute();
+}
} catch (BuildException e) {
success = false;
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[JK2] Use lock file forJNI startup status WAS: [JK2] RedHat 8.0 JNI totaly bogus
I've made the abort and exit hook for JVM adding two aditional option parameters at the end of config ones. If the JVM isn't set properly (wrong LD_LIBRARY_PATH, PATH pointing to the java outside the jre, etc...) the CreateJavaVM calls the abort hook. I was assuming that this hook will act instead the real abort function, but seems that it is only atexit call, cause the real abort function is called after the abort hook. So the only way is IMO to use the some sort of a lock file that will be created when the abort hook is called from JVM initialization, thus preventing further CreateJavaVM invocations. Perhaps we can use the shm for that from parent process, but the env is created on child_init. Thoughts? MT. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[jakarta-tomcat-connectors] Bug patch
jk\native2\common\jk_msg_ajp.c ( function: jk2_msg_ajp_appendMap ) line: 224
...
for( i=0; i size; i++ ) {
char *name=map-nameAt( env, map, i );
- char *val=map-nameAt( env, map, i );
+ char *val=map-valueAt( env, map, i );
if( rc== JK_OK )
rc=msg-appendString( env, msg, name );
...
--
Good Luck,
Igor S. Petrenko
www.adminteractive.com
mailto:nofate;ukr.net #ICQ: 19254900
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: [jakarta-tomcat-connectors] Bug patch
-Original Message-
From: [EMAIL PROTECTED]
jk\native2\common\jk_msg_ajp.c ( function:
jk2_msg_ajp_appendMap ) line: 224
...
for( i=0; i size; i++ ) {
char *name=map-nameAt( env, map, i );
-char *val=map-nameAt( env, map, i );
+char *val=map-valueAt( env, map, i );
if( rc== JK_OK )
rc=msg-appendString( env, msg, name );
...
Don't know what version you are having, but be sure to use the latest
one from CVS.
It's already there :-).
--
Good Luck,
Same to you, and keep rolling patches ;)
MT.
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina/src/conf catalina.properties
remm2002/10/24 06:53:33
Modified:catalina/src/conf catalina.properties
Log:
- Since it didn't get vetoed, I'm going forward with the CL configurability feature.
- Adds new catalina.properties file which allows to configure the three Catalina
classloaders. This should allow to embed Tomcat in a more flexible way
without using the Embedded class.
- The functionality is far from being done. For example, it would be desirable to
be able to specify the configuration source (currently hardcoded to
conf/server.xml) in the properties file.
Revision ChangesPath
1.2 +3 -4 jakarta-tomcat-catalina/catalina/src/conf/catalina.properties
Index: catalina.properties
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/catalina.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- catalina.properties 17 Oct 2002 14:52:03 - 1.1
+++ catalina.properties 24 Oct 2002 13:53:33 - 1.2
-28,7 +28,7
# foo/*.jar: Add all the JARs of the specified folder as class
# repositories
# foo/bar.jar: Add bar.jar as a class repository
-common.loader=common/classes,common/lib/*.jar
+common.loader=${catalina.home}/common/classes,${catalina.home}/common/endorsed/*.jar,${catalina.home}/common/lib/*.jar
#
# List of comma-separated paths defining the contents of the server
-40,7 +40,7
# foo/*.jar: Add all the JARs of the specified folder as class
# repositories
# foo/bar.jar: Add bar.jar as a class repository
-server.loader=server/classes,server/lib/*.jar
+server.loader=${catalina.home}/server/classes,${catalina.home}/server/lib/*.jar
#
# List of comma-separated paths defining the contents of the shared
-52,5 +52,4
# foo/*.jar: Add all the JARs of the specified folder as class
# repositories
# foo/bar.jar: Add bar.jar as a class repository
-shared.loader=shared/classes,shared/lib/*.jar
-
+shared.loader=${catalina.home}/shared/classes,${catalina.home}/shared/lib/*.jar
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup catalina.properties CatalinaProperties.java Bootstrap.java ClassLoaderFactory.java
remm2002/10/24 06:53:22
Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java ClassLoaderFactory.java
Added: catalina/src/share/org/apache/catalina/startup
catalina.properties CatalinaProperties.java
Log:
- Since it didn't get vetoed, I'm going forward with the CL configurability feature.
- Adds new catalina.properties file which allows to configure the three Catalina
classloaders. This should allow to embed Tomcat in a more flexible way
without using the Embedded class.
- The functionality is far from being done. For example, it would be desirable to
be able to specify the configuration source (currently hardcoded to
conf/server.xml) in the properties file.
Revision ChangesPath
1.5 +57 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Bootstrap.java22 Oct 2002 20:25:29 - 1.4
+++ Bootstrap.java24 Oct 2002 13:53:22 - 1.5
@@ -71,6 +71,7 @@
import java.net.MalformedURLException;
import java.net.URL;
import java.util.ArrayList;
+import java.util.StringTokenizer;
import org.apache.catalina.loader.StandardClassLoader;
import org.apache.catalina.security.SecurityClassLoad;
@@ -101,6 +102,7 @@
protected ClassLoader catalinaLoader = null;
protected ClassLoader sharedLoader = null;
+protected static final String CATALINA_TOKEN = ${catalina.home};
public void setDebug( int debug ) {
this.debug=debug;
@@ -109,10 +111,15 @@
public void setArgs(String args[] ) {
this.args=args;
}
+
+
// --- Main Program
+
public void initClassLoaders() {
try {
+
+/*
File unpacked[] = new File[1];
File packed[] = new File[1];
File packed2[] = new File[2];
@@ -142,6 +149,13 @@
sharedLoader =
ClassLoaderFactory.createClassLoader(unpacked, packed,
commonLoader);
+*/
+
+ClassLoaderFactory.setDebug(debug);
+commonLoader = createClassLoader(common, null);
+catalinaLoader = createClassLoader(server, commonLoader);
+sharedLoader = createClassLoader(shared, commonLoader);
+
} catch (Throwable t) {
log(Class loader creation threw exception, t);
@@ -149,6 +163,45 @@
}
}
+
+
+private ClassLoader createClassLoader(String name, ClassLoader parent)
+throws Exception {
+
+String value = CatalinaProperties.getProperty(name + .loader);
+if ((value == null) || (value.equals()))
+return parent;
+
+ArrayList unpackedList = new ArrayList();
+ArrayList packedList = new ArrayList();
+
+StringTokenizer tokenizer = new StringTokenizer(value, ,);
+while (tokenizer.hasMoreElements()) {
+String repository = tokenizer.nextToken();
+boolean packed = false;
+if (repository.startsWith(CATALINA_TOKEN)) {
+repository = getCatalinaHome()
++ repository.substring(CATALINA_TOKEN.length());
+}
+if (repository.endsWith(*.jar)) {
+packed = true;
+repository = repository.substring
+(0, repository.length() - *.jar.length());
+}
+if (packed) {
+packedList.add(new File(repository));
+} else {
+unpackedList.add(new File(repository));
+}
+}
+
+File[] unpacked = (File[]) unpackedList.toArray(new File[0]);
+File[] packed = (File[]) packedList.toArray(new File[0]);
+
+return ClassLoaderFactory.createClassLoader(unpacked, packed, parent);
+
+}
+
// --- Main Program
1.2 +7 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java
Index: ClassLoaderFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ClassLoaderFactory.java 18 Jul 2002 16:47:48 - 1.1
+++
cvs commit: jakarta-tomcat-catalina/catalina build.xml
remm2002/10/24 06:53:45
Modified:catalina build.xml
Log:
- Since it didn't get vetoed, I'm going forward with the CL configurability feature.
- Adds new catalina.properties file which allows to configure the three Catalina
classloaders. This should allow to embed Tomcat in a more flexible way
without using the Embedded class.
- The functionality is far from being done. For example, it would be desirable to
be able to specify the configuration source (currently hardcoded to
conf/server.xml) in the properties file.
Revision ChangesPath
1.28 +4 -0 jakarta-tomcat-catalina/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- build.xml 18 Oct 2002 21:34:28 - 1.27
+++ build.xml 24 Oct 2002 13:53:45 - 1.28
-844,6 +844,8
fileset dir=${catalina.build}/server/classes
include name=org/apache/catalina/startup/Bootstrap.class /
include name=org/apache/catalina/startup/BootstrapService.class /
+include name=org/apache/catalina/startup/catalina.properties /
+include name=org/apache/catalina/startup/CatalinaProperties.class /
include name=org/apache/catalina/startup/ClassLoaderFactory.class /
include name=org/apache/catalina/startup/Tool.class /
include name=org/apache/catalina/loader/StandardClassLoader*.class /
-863,6 +865,8
exclude name=org/apache/naming/** /
exclude name=org/apache/catalina/startup/Bootstrap.class /
exclude name=org/apache/catalina/startup/BootstrapService.class /
+exclude name=org/apache/catalina/startup/catalina.properties /
+exclude name=org/apache/catalina/startup/CatalinaProperties.class /
exclude name=org/apache/catalina/startup/ClassLoaderFactory.class /
exclude name=org/apache/catalina/startup/Tool.class /
exclude name=org/apache/catalina/loader/StandardClassLoader*.class /
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13931] New: - How to Forward request between different web apps
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=13931. 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=13931 How to Forward request between different web apps Summary: How to Forward request between different web apps Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hie First of all i wanna ask a question and not report a bug. My Question is that i am having three webapps that are discovered at runtime(so there is no entry regarding them in server.xml)in my application and i want to pass the Session between the contexts(i.e. *webapps*). Please if someone can tell me where i will get sample code to code that stuff.. Since i know that we have to get the Context of the target webapps and then get request dispatcher object from there and do .Forward to send it.But coudnt find any sample code on how to go about that. Thanks a Lot in Advance Girish -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13931] - How to Forward request between different web apps
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=13931. 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=13931 How to Forward request between different web apps [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 14:04 --- Sorry, but the bug database is for bug reports only. Guidelines and tips: http://jakarta.apache.org/tomcat/bugreport.html -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Session restore classloading problem
Dear developers, (apologies for the expected crap formatting from outlook)
Just want to know if this is expected behavoir.
I've had some trouble with sessions being restored on tomcat restart when
data stored in the session is an object array.
e.g.
if (action != null action.equals(insert))
{
System.out.println(Action was insert - will create
a new one.);
SomeDataClass[] twoSize = new SomeDataClass[2];
twoSize[0] = new SomeDataClass();
twoSize[1] = new SomeDataClass();
session.setAttribute( data, twoSize);
}
else if (action != null action.equals(retrieve))
{
SomeDataClass[] twoArray =
(SomeDataClass[])session.getAttribute(data);
if (twoArray == null)
{
System.out.println(I did not get back an
object :-();
}
else
{
System.out.println(I got back the object:
+ twoArray.toString());
}
}
On restart of tomcat (with SomeDataClass[] in the session) I get the
following on startup, with the session data trashed:
2002-10-24 13:53:59 StandardManager[/test] Exception loading sessions from
persistent storage java.lang.ClassNotFoundException: [LSomeDataClass;
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav
a:1428)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav
a:1274)
at
org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectIn
putStream.java:119)
at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1503)
at
java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1425)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1550)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1261)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:322)
at
org.apache.catalina.session.StandardSession.readObject(StandardSession.java:
1357)
at
org.apache.catalina.session.StandardSession.readObjectData(StandardSession.j
ava:852)
at
org.apache.catalina.session.StandardManager.load(StandardManager.java:411)
at
org.apache.catalina.session.StandardManager.start(StandardManager.java:626)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3496)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:8
21)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579)
at
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.j
ava:257)
I am running:
Tomcat 4.1 win32 with apache2, default install, minus 8080 listener.
My question is - is this expected behavoir, or should the WebappClassLoader
be handling this compound type of array?
Thanks for any help,
Daniel Hams
DG Trade A4
European Commission
Tel: +32.2.299.96.81
Fax: +32.2.295.38.56
Email: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [5.0] Refactoring Bootstrap and BootstrapService
Costin Manolache wrote: It was about time ! I suppose we'll end up with Bootstrap + Catalina. What I would like is to have a similar bean/ant-like interface on both ( i.e. setter methods for all options configurable on command line + execute() pattern ). With the main distinction beeing that Bootstrap will be a class with no deps that'll create the loaders and use reflection on Catalina. Yes, I figured the bean like methods would be useful, and I plan to have some. Please take a look at my latest commit on catalina.xml ( the run/run-wait targets). And I hope the 'random method additions' are not mine :-) You're a suspect, I'm afraid. Some had your coding style ;-) Remy Costin Remy Maucherat wrote: ... as well as the Catalina and CatalinaService classes. The idea is to remove the *Service, and have only one set of classes (which would still handle all use cases). There has been a number of random method additions which make the whole thing a mess (IMO). For example, the Service version can be made to behave like the non-Service one. Kinda confusing ... This will likely break a few things. Please complain if you like the current mess better ;-) Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [5.0] Refactoring Bootstrap and BootstrapService
It was about time ! I suppose we'll end up with Bootstrap + Catalina. What I would like is to have a similar bean/ant-like interface on both ( i.e. setter methods for all options configurable on command line + execute() pattern ). With the main distinction beeing that Bootstrap will be a class with no deps that'll create the loaders and use reflection on Catalina. Please take a look at my latest commit on catalina.xml ( the run/run-wait targets). And I hope the 'random method additions' are not mine :-) Costin Remy Maucherat wrote: ... as well as the Catalina and CatalinaService classes. The idea is to remove the *Service, and have only one set of classes (which would still handle all use cases). There has been a number of random method additions which make the whole thing a mess (IMO). For example, the Service version can be made to behave like the non-Service one. Kinda confusing ... This will likely break a few things. Please complain if you like the current mess better ;-) Remy -- Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[5.0] Refactoring Bootstrap and BootstrapService
... as well as the Catalina and CatalinaService classes. The idea is to remove the *Service, and have only one set of classes (which would still handle all use cases). There has been a number of random method additions which make the whole thing a mess (IMO). For example, the Service version can be made to behave like the non-Service one. Kinda confusing ... This will likely break a few things. Please complain if you like the current mess better ;-) Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 13832] - handshake security error when user accessing http://localhost:8443
Amy Roh wrote: all rightmy bad...it's not REALLY a bug and is expected behavior. Our SQE person filed the bug internally and I wanted to put it on bugzilla so we can keep track before I take a look at it. It's my first time actually filing bug on bugzilla and I get shot down by Remy like this. sheesh. Thanks, Bill Remy! :-) Well, actually, there was a bug, although not really the one stated in the report. Sorry for being mean ;-) Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 13832] - handshake security error when user accessing http://localhost:8443
all rightmy bad...it's not REALLY a bug and is expected behavior. Our SQE person filed the bug internally and I wanted to put it on bugzilla so we can keep track before I take a look at it. It's my first time actually filing bug on bugzilla and I get shot down by Remy like this. sheesh. Thanks, Bill Remy! :-) [EMAIL PROTECTED] wrote: 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=13832. 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=13832 handshake security error when user accessing http://localhost:8443 --- Additional Comments From [EMAIL PROTECTED] 2002-10-22 09:44 --- Since I've been bad, I just committed a fix. I think it fixes the issues raised by Bill. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime PageContextImpl.java
costin 2002/10/24 12:18:55
Modified:jasper2/src/share/org/apache/jasper/runtime
PageContextImpl.java
Log:
Change the 'flush' to just a 'flushBuffer'.
This allows the container to deal with flushing the buffer (
wich is done automatically if the servlet doesn't explicitely
flush()/close() ). The container can attach the Content-Length
header which is usefull in many cases.
Revision ChangesPath
1.27 +11 -6
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java
Index: PageContextImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- PageContextImpl.java 4 Oct 2002 19:21:44 - 1.26
+++ PageContextImpl.java 24 Oct 2002 19:18:55 - 1.27
-162,7 +162,7
this.bufferSize = bufferSize;
this.autoFlush= autoFlush;
this.request = request;
- this.response = response;
+ this.response = response;
// setup session (if required)
if (request instanceof HttpServletRequest needsSession)
-209,7 +209,12
((JspWriterImpl)out).flushBuffer();
// push it into the including jspWriter
} else {
- out.flush();
+// Old code:
+ //out.flush();
+// Do not flush the buffer even if we're not included (i.e.
+// we are the main page. The servlet will flush it and close
+// the stream.
+((JspWriterImpl)out).flushBuffer();
}
} catch (IOException ex) {
loghelper.log(Internal error flushing the buffer in release());
-226,7 +231,7
depth = -1;
baseOut.recycle();
session = null;
-
+
attributes.clear();
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina/src/bin catalina.xml
costin 2002/10/24 12:10:30
Modified:catalina/src/bin catalina.xml
Log:
Merged the startup code from build2.xml. The 3 startup methods
are independent ( launcher, java exec and task ).
Of particular interest ( I think ) are the 2 run targets.
run will load catalina in-process and _return_ imediately after
the init block is done - i.e. you no longer need the sleep.
( same thing that is used for example by anteater to start tomcat33).
This is still not completed - and will need to be integrated with the
launcher.
Revision ChangesPath
1.5 +129 -32 jakarta-tomcat-catalina/catalina/src/bin/catalina.xml
Index: catalina.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/catalina.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- catalina.xml 14 Aug 2002 15:43:04 - 1.4
+++ catalina.xml 24 Oct 2002 19:10:30 - 1.5
-1,23 +1,18
!--
-
- XML file for launching Catalina applications using the Launcher.
-
- To run any of the applications in the JDB debugger, execute the Launcher with
- a -Ddebug=true argument.
-
- To run any of the applications in JPDA mode, execute the Launcher with a
- -Djpda=true argument.
-
+ XML file for launching Catalina applications using ant.
--
project name=Catalina Launcher default=catalina basedir=.
+ property file=${user.home}/.tomcat5.properties/
!-- Set the application home to the parent directory of this directory --
property name=catalina.home location=${basedir}/../
property name=bootstrap.jar location=${catalina.home}/bin/bootstrap.jar/
!-- Import the user's custom properties --
- property file=${catalina.home}/bin/catalina.properties/
+ property file=${catalina.home}/bin/catalina.properties/ !-- XXX shold it be
conf ?? --
+ property file=${catalina.home}/conf/catalina.properties/ !-- XXX shold it be
conf ?? --
+
!-- Set user configurable properties --
property name=jsse.home location=${catalina.home}/
-26,41 +21,82
property name=catalina.out location=${catalina.base}/logs/catalina.out/
property name=catalina.policy
location=${catalina.base}/conf/catalina.policy/
property name=catalina.jvm.args value=/
+
property name=catalina.source.path
value=${catalina.home}/../../jakarta-servletapi-5/src/share:${catalina.home}/../../jakarta-tomcat-jasper/jasper2/src/share:${catalina.home}/../../jakarta-tomcat-connectors/coyote/src/java:${catalina.home}/../../jakarta-tomcat-catalina/catalina/src/share/
+
!-- Build the classpath relative to the application home --
path id=base.class.path
pathelement location=${bootstrap.jar}/
pathelement
path=${jsse.home}/lib/jsse.jar:${jsse.home}/lib/jcert.jar:${jsse.home}/lib/jnet.jar/
/path
- !-- Build the sysproperties relative to the application home --
- syspropertyset id=base.sys.properties
-sysproperty key=java.endorsed.dirs file=${catalina.home}/common/endorsed/
-sysproperty key=java.io.tmpdir file=${catalina.tmpdir}/
-sysproperty key=catalina.home file=${catalina.home}/
-sysproperty key=catalina.base file=${catalina.base}/
- /syspropertyset
-
- !-- Build the standard jvmargs --
- jvmargset id=base.jvm.args
-jvmarg line=${catalina.jvm.args}/
-jvmarg value=-Xdebug if=jpda.settings/
-jvmarg value=-Xrunjdwp:${jpda.settings} if=jpda.settings/
-jvmarg value=-sourcepath if=jdb/
-jvmarg path=${catalina.source.path} if=jdb/
- /jvmargset
+ property name=basedir location=./
+
+ property name=tools.jar location=${java.home}/../lib/tools.jar /
+
+ path id=tomcatcp
+pathelement location=${catalina.home}/bin/bootstrap.jar/
+fileset dir=${catalina.home}/common/lib includes=*.jar/
+fileset dir=${catalina.home}/server/lib includes=*.jar/
+pathelement location=${catalina.home}/common/classes/
+!--
+ pathelement location=${ant.home}/lib/xercesImpl.jar /
+ pathelement location=${ant.home}/lib/xml-apis.jar /
+--
+pathelement location=${ant.home}/lib/ant.jar /
+pathelement location=${tools.jar} /
+ /path
+
+
+ !-- === Initialization/helpers == --
+
+
+ target name=init
+ description=Display configuration and conditional compilation flags
+ /target
+
+ target name=init-launcher
+!-- Build the sysproperties relative to the application home --
+syspropertyset id=base.sys.properties
+ sysproperty key=java.endorsed.dirs
file=${catalina.home}/common/endorsed/
+ sysproperty key=java.io.tmpdir file=${catalina.tmpdir}/
+ sysproperty key=catalina.home file=${catalina.home}/
+ sysproperty key=catalina.base file=${catalina.base}/
+/syspropertyset
Re: DO NOT REPLY [Bug 13907] - security manager does not give readpermission on a context by default
Aditya wrote: Glenn, On Thu, Oct 24, 2002 at 10:03:47AM -, [EMAIL PROTECTED] wrote: This must be a problem in your local system configuration. Check the unix file ownerhsip and permissions for test2.new. I've done that and the fact is that it works fine without the security manager so it's not a unix file ownership and permissions problem. Also try running Tomcat with java property -Djava.security.debug=access,failure defined and then check the security manager debug output. yup, done that and the output has nothing more than the failure of read permissions. I just tested the jsp you posted with a fresh build of Tomcat 4.1 from the CVS head (What will be Tomcat 4.1.13) and Jasper 2. The FilePermission read for the context directory is being granted automatically and the JSP works. I just read the 4.1.13 announcement from Remy and it has the following note: IMPORTANT NOTE: Security manager functionality is broken in this milestone. This will be fixed in the next milestone. This milestone will not be proposed for official release, and should be used for testing purposes only. so before I checkout a fresh copy from CVS, need I be worried about this? No, this is not related to your problem. The SecurityManager in 4.1.13 will throws security exception when you use: HttpServletRequest.setContentType() HttpServletRequest.getContentType() HttpServletRequest.getParameters() HttpServletRequest.getMimeHeaders() HttpServletRequest.getCharacterEncoding() HttpServletResponse.getContentType() HttpServletResponse.setContentType() HttpServetResponse.getHeaders() HttpServetResponse..getHeader() And it should *not*. -- Jeanfrancois Thanks, Adi -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: jasper questions
Remy Maucherat wrote: If we let the servlet wrapper deal with it - then we need a 'partial flush' in release() - which will just move the data to the parent buffer ( OutputBuffer from what I see ), but without calling flush on it. Remy, what do you think ? Yes, I think I agree. I rarely see any reason to flush, it just makes things slower. I think it's a very good idea to see *all* the code from Jasper 1 with a very critical eye and not assume it's there for a Good Reason ;-) Did you test it ? Does it work good ? (I don't see why it wouldn't, just wondering) It seems ok - I'm more worried about the spec implications, i.e. is the flush() in relase() implied by some of the spec - or javadoc ? My reading is not, but others understand the spec better. For now I'll just change PageContextImpl.release to do flushBuffer in both cases ( i.e. included or not ). This will empty the page buffers in the OutBuffer. My reading of the javadoc is that release() shouldn't do that ( but discard it )- but that's what has been done in the past and is the least risky. If we agree on the release() behavior, then we need to move the flushBuffer() in the calling code ( the generated servlet ), before release() is called. -- Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13942] New: - Modification of catalina.sh for additional CLASSPATH
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=13942.
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=13942
Modification of catalina.sh for additional CLASSPATH
Summary: Modification of catalina.sh for additional CLASSPATH
Product: Tomcat 4
Version: Unknown
Platform: All
URL: http://www.ccgb.umn.edu/~crow/docs/catalina-sh.txt
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Hello -
When we start up the Tomcat server, it would be quite useful for us to
be able to prepend additional information to the CLASSPATH variable. While
it is straightforward to do this by hacking catalina.sh, this seems a bit
messy. I would like to suggest that the standard distribution of catalina.sh
be modified to include lines of this form:
if [ x$AUX_CLASSPATH != x ]; then
CLASSPATH=${AUX_CLASSPATH}:$CLASSPATH
fi
after the call to setclasspath.sh.
This would allow isolation of this app-specific CLASSPATH stuff, and ease
the admin's task as new servlets are added. An example of this is shown
at http://www.ccgb.umn.edu/~crow/docs/catalina-sh.txt.
Thanks!
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: jasper questions
Any opinions ? This is a significant change - I won't do it unless I have some feedback. The issues is moving flush() out of PageContextImpl.release() and into the generated java code, just before calling releasePageContext(). My assertion is that release() shouldn't have the flush() as side effect. There is one major problem - doing a flush() is not enough to enable the Content-Length generation for JSPs, we need to either close() or let the data in the buffer so that the servlet wrapper will do the flush-and-close operation. The jsp page can be included - but I think close is disabled in included, so it won't affect anything. If we let the servlet wrapper deal with it - then we need a 'partial flush' in release() - which will just move the data to the parent buffer ( OutputBuffer from what I see ), but without calling flush on it. Remy, what do you think ? Costin Costin Manolache wrote: I'm trying to understand the last part of the JSP execution - and how the buffer is flushed and closed. Acording to javadocs, JspFactory.releasePageContext() should be invoked, and that will call PageContext.release(). In release() javadoc: * This method shall reset the internal state of a PageContext, releasing * all internal references, and preparing the PageContext for potential * reuse by a later invocation of initialize(). This method is typically * called from JspFactory.releasePageContext(). There is no mention that this method will flush the buffers as side effect. At least that's my reading. I think a more correct implementation would be to call out.flush()/out.close() explicitely and then call release(). The benefit would be that the connector will be able to automatically add Content-Length ( at least for small pages ), and that's usually good for performance or when talking with certain clients. ( that's what coyote does for servlets - but not for JSPs since flush() is called too early ). -- Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_vm_default.c
mturk 2002/10/24 08:37:18
Modified:jk/native2/common jk_vm_default.c
Log:
After guessing JVM check if the file is inside the
LD_LIBRARY_PATH.
Revision ChangesPath
1.23 +53 -6 jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c
Index: jk_vm_default.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- jk_vm_default.c 15 Oct 2002 13:59:49 - 1.22
+++ jk_vm_default.c 24 Oct 2002 15:37:18 - 1.23
-184,6 +184,24
}
#endif
+/* JVM hooks */
+static int jk2_jni_error_signaled = JK_FALSE;
+static int jk2_jni_error_code = 0;
+static int jk2_jni_abort_signaled = JK_FALSE;
+
+static void jk2_jni_error_hook(int code)
+{
+jk2_jni_error_signaled = JK_TRUE;
+jk2_jni_error_code = code;
+
+fprintf(stderr, JVM error hook called %d\n, code);
+}
+
+static void jk2_jni_abort_hook()
+{
+jk2_jni_abort_signaled = JK_TRUE;
+fprintf(stderr, JVM abort hook\n);
+}
/** Load the VM. Must be called after init.
*/
-400,9 +418,33
(char *)p-pstrdup( env, p, *current ) );
if( jvm!=NULL jk2_file_exists(env, jvm)) {
+char *ldlib;
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ jni.guessJvmDll() trying %s\n, jvm);
+/* Check if the LD_LIBRARY_PATH points to the discovered jvm.
+ * XXX only tested on Linux.
+ */
+ldlib = getenv(LD_LIBRARY_PATH);
+if (ldlib strlen(ldlib)) {
+char *token;
+
+token = strtok(ldlib, :);
+while (token != NULL) {
+if (strncmp(token, jvm, strlen(token)) == 0) {
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ jni.guessJvmDll() found %s in %s.\n, jvm,
token);
+return jvm;
+}
+token = strtok(NULL, :);
+}
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ jni.guessJvmDll() could not find %s in the
LD_LIBRARY_PATH\n,
+ jvm);
+return NULL;
+}
env-l-jkLog(env, env-l, JK_LOG_INFO,
- jni.guessJvmDll() %s\n, jvm);
-return jvm;
+ jni.guessJvmDll() LD_LIBRARY_PATH environment var is not
set\n);
+return NULL;
}
env-l-jkLog(env, env-l, JK_LOG_INFO,
-485,8 +527,6
return JK_ERR;
}
-vm_args.version = JNI_VERSION_1_2;
-vm_args.options = options;
for (classn = 0; classn jkvm-nClasspath; classn++)
classl += strlen(jkvm-classpath[classn]);
if (classl) {
-513,9 +553,16
vm.openJvm2() Classpath: %s\n, classpath);
options[optn++].optionString = classpath;
}
-
-vm_args.nOptions = optn;
+/* Set the abort and exit hooks */
+options[optn].optionString = exit;
+options[optn++].extraInfo = jk2_jni_error_hook;
+options[optn].optionString = abort;
+options[optn++].extraInfo = jk2_jni_abort_hook;
+
+vm_args.version = JNI_VERSION_1_2;
+vm_args.options = options;
+vm_args.nOptions = optn;
vm_args.ignoreUnrecognized = JNI_TRUE;
err=jni_create_java_vm(jvm, penv, vm_args);
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13692] - request.getCharacterEncoding() is NULL
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=13692. 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=13692 request.getCharacterEncoding() is NULL [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [5.0] Refactoring Bootstrap and BootstrapService
Remy Maucherat wrote: Costin Manolache wrote: It was about time ! I suppose we'll end up with Bootstrap + Catalina. What I would like is to have a similar bean/ant-like interface on both ( i.e. setter methods for all options configurable on command line + execute() pattern ). With the main distinction beeing that Bootstrap will be a class with no deps that'll create the loaders and use reflection on Catalina. Yes, I figured the bean like methods would be useful, and I plan to have some. IntrospectionUtils has a nice method to process command line arguments and call the setters automatically, if called from CLI. It's probably easier and keeps things in sync. Please take a look at my latest commit on catalina.xml ( the run/run-wait targets). And I hope the 'random method additions' are not mine :-) You're a suspect, I'm afraid. Some had your coding style ;-) My only defense is that I'm too confused by the Bootstrap/BotstrapService/Catalina/CatalinaService, and too old to change much of the coding style, but I'll try harder :-) Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Tomcat 4.1.x: Jasper 2 backwards compat with Jasper 1?
In Tomcat 4.1.x, is the Jasper 2 runtime supposed to be backwards compatible the Jasper 1 runtime (i.e., from Tomcat 4.0.x), so that existing precomiled JSPs using the Jasper 1 compiler would work as-is with Jasper 2 in Tomcat 4.1.x? Thanks, Eddie --- Remy Maucherat [EMAIL PROTECTED] wrote: A new test milestone of Tomcat 4.1 has just been released. Please help test this upcoming Tomcat release for compliance issues and other problems. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.13/ Significant changes over 4.1.12 include some performance improvements as well as bugfixes. The full list of changes is available in the release notes. http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.13/RELEASE-NOTES IMPORTANT NOTE: Security manager functionality is broken in this milestone. This will be fixed in the next milestone. This milestone will not be proposed for official release, and should be used for testing purposes only. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 13907] - security manager does not give read permission on a context by default
Glenn, On Thu, Oct 24, 2002 at 10:03:47AM -, [EMAIL PROTECTED] wrote: This must be a problem in your local system configuration. Check the unix file ownerhsip and permissions for test2.new. I've done that and the fact is that it works fine without the security manager so it's not a unix file ownership and permissions problem. Also try running Tomcat with java property -Djava.security.debug=access,failure defined and then check the security manager debug output. yup, done that and the output has nothing more than the failure of read permissions. I just tested the jsp you posted with a fresh build of Tomcat 4.1 from the CVS head (What will be Tomcat 4.1.13) and Jasper 2. The FilePermission read for the context directory is being granted automatically and the JSP works. I just read the 4.1.13 announcement from Remy and it has the following note: IMPORTANT NOTE: Security manager functionality is broken in this milestone. This will be fixed in the next milestone. This milestone will not be proposed for official release, and should be used for testing purposes only. so before I checkout a fresh copy from CVS, need I be worried about this? Thanks, Adi -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13941] New: - reload is VERY slow
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=13941. 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=13941 reload is VERY slow Summary: reload is VERY slow Product: Tomcat 4 Version: 4.0 Beta 1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] after I created a webapp and added that to server.xml with a reloadable=true attribute, it takes about 10 seconds or so for my servlet changes to be picked up 10s is *TOO* long. This should be configurable -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Package Protection: which one?
Jean-Francois Arcand wrote: Hi, testing package protection, I have come to the following conclusion: Packages that we can protect against access -- o.a.catalina o.a.jasper o.a.jsp o.a.jk Packages that we can protect against definition -- o.a.catalina o.a.jasper o.a.jsp o.a.jk o.a.coyote Package that could be protected, but need to change: --- o.a.naming Naming is designed to be secure as is, and shouldn't need protection. o.a.coyote The implementations are protected by facades which have no useful methods for an attacker. o.a.tomcat.util I think this is safe too. If we decide to fully protect o.a.coyote, that means that every calls to CoyoteRequestFacade and CoyoteResponseFacade will need to runs under a doPrivilege blocks (every call that use o.a.tomcat.util). Then o.a.tomcat.util could be protected (only if o.a.coyote is). I made a wrong recommendation last week when I said that o.a.coyote can be protected (rule #1 test using the jakarta workspace, not with your local workspace). Testing with basic servlet prove me the contrary (see 4.1.13 release notesguilty!). I've committed in both Tomcat 4 and 5 the proper protection configuration. I would like to have recommendations based on which package should be protected. Based on the list I will audit package that stay unprotected. I don't think being paranoid would be very useful given that there are facades which are supposed to get the job done. Of course, I'm not the one making the audit, so I don't know for sure. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Package Protection: which one?
Hi, testing package protection, I have come to the following conclusion: Packages that we can protect against access -- o.a.catalina o.a.jasper o.a.jsp o.a.jk Packages that we can protect against definition -- o.a.catalina o.a.jasper o.a.jsp o.a.jk o.a.coyote Package that could be protected, but need to change: --- o.a.naming o.a.coyote o.a.tomcat.util If we decide to fully protect o.a.coyote, that means that every calls to CoyoteRequestFacade and CoyoteResponseFacade will need to runs under a doPrivilege blocks (every call that use o.a.tomcat.util). Then o.a.tomcat.util could be protected (only if o.a.coyote is). I made a wrong recommendation last week when I said that o.a.coyote can be protected (rule #1 test using the jakarta workspace, not with your local workspace). Testing with basic servlet prove me the contrary (see 4.1.13 release notesguilty!). I've committed in both Tomcat 4 and 5 the proper protection configuration. I would like to have recommendations based on which package should be protected. Based on the list I will audit package that stay unprotected. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Package Protection: which one?
Remy Maucherat wrote: Jean-Francois Arcand wrote: Hi, testing package protection, I have come to the following conclusion: Packages that we can protect against access -- o.a.catalina o.a.jasper o.a.jsp o.a.jk Packages that we can protect against definition -- o.a.catalina o.a.jasper o.a.jsp o.a.jk o.a.coyote Package that could be protected, but need to change: --- o.a.naming Naming is designed to be secure as is, and shouldn't need protection. o.a.coyote The implementations are protected by facades which have no useful methods for an attacker. o.a.tomcat.util I think this is safe too. If we decide to fully protect o.a.coyote, that means that every calls to CoyoteRequestFacade and CoyoteResponseFacade will need to runs under a doPrivilege blocks (every call that use o.a.tomcat.util). Then o.a.tomcat.util could be protected (only if o.a.coyote is). I made a wrong recommendation last week when I said that o.a.coyote can be protected (rule #1 test using the jakarta workspace, not with your local workspace). Testing with basic servlet prove me the contrary (see 4.1.13 release notesguilty!). I've committed in both Tomcat 4 and 5 the proper protection configuration. I would like to have recommendations based on which package should be protected. Based on the list I will audit package that stay unprotected. I don't think being paranoid would be very useful given that there are facades which are supposed to get the job done. Of course, I'm not the one making the audit, so I don't know for sure. Remy Well, maybe I paranoid (OK I paranoid).but I would prefer protecting all packages and implement the appropriate doPrivileged block. This way we avoid situations like: (1) a new committer add a class to an unprotected package and open a security hole. A good example is, in Tomcat 4, o.a.c.util is not protected because there is no sensitive classes (right Glenn?). But let's say in two year we need to add a class and actual committers are gone because their stock options make them rich (OK I paranoid again :-) ) (2) a hacker breaks a facade and accesses some confidential data. Actually, (2) seems the easiest way to do something bad (and from SUN security group, the most frequent security issue). I must admit that since I'm working on the audit (3 weeks), I did not found any facade that contains a potientally security issues...but IMBW, I'm not an hacker. I would like a decision to protect/not protect a package as soon as possible, since I will not audit a package that is protected (I will just add the appropriate doPrivilege block). And not protecting a package make my life easier since I don't have to implement doPrivileged blocks and try to find every situation when a doPrivileged block is requiredShould we vote? -- Jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Problems mirroring the tomcat distribution site...
send_files failed to open /builds/jakarta-tomcat-4.0/archives/v4.0.5/bin/hotfix/13365.zip.asc: Permission denied send_files failed to open /builds/jakarta-tomcat-4.0/release/v4.0.5/bin/hotfix/13365.zip.asc: Permission denied send_files failed to open /builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/netware/mod_jk_1.3.n lm.asc: Permission denied send_files failed to open /builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/netware/mod_jk_2.0.4 2.nlm.asc: Permission denied send_files failed to open /builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/netware/nsapi_rd.nlm .asc: Permission denied Can you guys (remm and mmanders) make sure you have the privileges set corretly? Please (to the list) when updating stuff in /build make sure the correct privileges are set as that stuff is mirrored... Pier -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: 4.0.7 release?
Scarab only works in Tomcat 4.1.x if you use JDK 1.4.x. It does not work with JDK 1.3.x If you can get Scarab to work with Tomcat 4.1.x on JDK 1.3.x, let me know how you got it to work and I will immediately switch Scarab to use Tomcat 4.1.x. Otherwise, I would appreciate it if someone would please do a release of Tomcat 4.0.7 with the latest Coyote as soon as possible. Scarab won't be updated to use Xerces 2.x until SourceCast uses Xerces 2.x and I'm not sure when that will happen. Yes, I know that Scarab is open source and shouldn't have such a requirement, but the fact of the matter is that CollabNet is paying for 99% of Scarab's development and my paycheck, so I do as they say. =) I'm starting to sound like Pier. =) -jon on 2002/10/24 2:06 AM, Glenn Nielsen [EMAIL PROTECTED] wrote: I have scarab running in Tomcat 4.1.12. Though I can't say that we have tried all the features of scarab like XML import/export. Glenn Henri Gomez wrote: Jon Scott Stevens wrote: Can I get a 4.0.7 release? It has an important configuration bug fix that I need for Scarab. Hi Jon, I tried to use Scarab with 4.1.12 but it didn't works. Do you plan to make scarab works with 4.1.x ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Bootstrap.java Catalina.java BootstrapService.java CatalinaService.java
remm2002/10/24 15:06:04
Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java Catalina.java
Removed: catalina/src/share/org/apache/catalina/startup
BootstrapService.java CatalinaService.java
Log:
- Remove the *Service classes.
- The basic functionality appears to be working. The Windows service
will need to be tested and updated (tomorrow).
Revision ChangesPath
1.6 +243 -112
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Bootstrap.java24 Oct 2002 13:53:22 - 1.5
+++ Bootstrap.java24 Oct 2002 22:06:04 - 1.6
-91,76 +91,54
public final class Bootstrap {
+
+// -- Constants
+
+
+protected static final String CATALINA_TOKEN = ${catalina.home};
+
+
+// --- Static Variables
+
+
+/**
+ * Daemon object used by main.
+ */
+private static Bootstrap daemon = null;
+
+
+// -- Variables
+
+
/**
* Debugging detail level for processing the startup.
*/
protected int debug = 0;
-protected String args[];
-// Construct the class loaders we will need
+
+/**
+ * Daemon reference.
+ */
+private Object catalinaDaemon = null;
+
+
protected ClassLoader commonLoader = null;
protected ClassLoader catalinaLoader = null;
protected ClassLoader sharedLoader = null;
-protected static final String CATALINA_TOKEN = ${catalina.home};
-
-public void setDebug( int debug ) {
-this.debug=debug;
-}
-
-public void setArgs(String args[] ) {
-this.args=args;
-}
+// Private Methods
-// --- Main Program
-
-public void initClassLoaders() {
+private void initClassLoaders() {
try {
-
-/*
-File unpacked[] = new File[1];
-File packed[] = new File[1];
-File packed2[] = new File[2];
-ClassLoaderFactory.setDebug(debug);
-
-unpacked[0] = new File(getCatalinaHome(),
- common + File.separator + classes);
-packed2[0] = new File(getCatalinaHome(),
- common + File.separator + endorsed);
-packed2[1] = new File(getCatalinaHome(),
- common + File.separator + lib);
-commonLoader =
-ClassLoaderFactory.createClassLoader(unpacked, packed2, null);
-
-unpacked[0] = new File(getCatalinaHome(),
- server + File.separator + classes);
-packed[0] = new File(getCatalinaHome(),
- server + File.separator + lib);
-catalinaLoader =
-ClassLoaderFactory.createClassLoader(unpacked, packed,
- commonLoader);
-
-unpacked[0] = new File(getCatalinaBase(),
- shared + File.separator + classes);
-packed[0] = new File(getCatalinaBase(),
- shared + File.separator + lib);
-sharedLoader =
-ClassLoaderFactory.createClassLoader(unpacked, packed,
- commonLoader);
-*/
-
ClassLoaderFactory.setDebug(debug);
commonLoader = createClassLoader(common, null);
catalinaLoader = createClassLoader(server, commonLoader);
sharedLoader = createClassLoader(shared, commonLoader);
-
} catch (Throwable t) {
-
log(Class loader creation threw exception, t);
System.exit(1);
-
}
}
-203,84 +181,237
}
-// --- Main Program
+/**
+ * Initialize daemon.
+ */
+private void init()
+throws Exception {
-public void execute() {
-// Set the debug flag appropriately
-for (int i = 0; i args.length; i++) {
-if (-debug.equals(args[i]))
-setDebug( 1 );
-}
-
-
cvs commit: jakarta-tomcat-catalina/catalina build.xml
remm2002/10/24 15:11:03
Modified:catalina build.xml
Log:
- Remove the *Service classes.
- The basic functionality appears to be working. The Windows service
will need to be tested and updated (tomorrow).
Revision ChangesPath
1.29 +0 -2 jakarta-tomcat-catalina/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- build.xml 24 Oct 2002 13:53:45 - 1.28
+++ build.xml 24 Oct 2002 22:11:03 - 1.29
-843,7 +843,6
manifest=etc/bootstrap.MF
fileset dir=${catalina.build}/server/classes
include name=org/apache/catalina/startup/Bootstrap.class /
-include name=org/apache/catalina/startup/BootstrapService.class /
include name=org/apache/catalina/startup/catalina.properties /
include name=org/apache/catalina/startup/CatalinaProperties.class /
include name=org/apache/catalina/startup/ClassLoaderFactory.class /
-864,7 +863,6
exclude name=org/apache/catalina/launcher/** /
exclude name=org/apache/naming/** /
exclude name=org/apache/catalina/startup/Bootstrap.class /
-exclude name=org/apache/catalina/startup/BootstrapService.class /
exclude name=org/apache/catalina/startup/catalina.properties /
exclude name=org/apache/catalina/startup/CatalinaProperties.class /
exclude name=org/apache/catalina/startup/ClassLoaderFactory.class /
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13954] New: - invalid session passed in HttpBindingEvent on valueUnbound
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=13954.
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=13954
invalid session passed in HttpBindingEvent on valueUnbound
Summary: invalid session passed in HttpBindingEvent on
valueUnbound
Product: Tomcat 4
Version: 4.0.4 Final
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
When a timeout occurs, the HttpSession passed into valueUnbound() via the
HttpBindingEvent contains an already invalidated HttpSession. Since there is
no lifecycle of an HttpSession defined in the servlet spec, I an guessing this
is open to implementor's to decide. I would *expect* all listeners to have
their valueUnbound() methods called before the session they were attached to is
actually invalidated by the Web Container.
A stacktrace below shows the timeline of events:
--
(D)-255- | Thu Oct 24 14:36:52 MDT 2002 | OnlineMonitor | valueUnbound |
36838.1035489988143 | Entering
java.lang.Exception: getAttribute: Session already invalidated
at com.vergecorp.util.Log.error(Log.java:445)
at net.ejip.monitor.online.OnlineMonitor.valueUnbound
(OnlineMonitor.java:69)
at org.apache.catalina.session.StandardSession.removeAttribute
(StandardSession.java:1073)
at org.apache.catalina.session.StandardSession.expire
(StandardSession.java:596)
at org.apache.catalina.session.StandardManager.processExpires
(StandardManager.java:755)
at org.apache.catalina.session.StandardManager.run
(StandardManager.java:832)
at java.lang.Thread.run(Thread.java:536)
(E) | Thu Oct 24 14:36:52 MDT 2002 | OnlineMonitor | valueUnbound |
36838.1035489988143 | getAttribute: Session already invalidated
StandardSession.expire() code has the setValid(true) method called too
early It should really be called after all of the valueUnbound() methods
are called. For instance, right before the expiring=false is set near the
bottom of the method.
/**
* Perform the internal processing required to invalidate this session,
* without triggering an exception if the session has already expired.
*/
public void expire() {
// Mark this session as being expired if needed
if (expiring)
return;
expiring = true;
setValid(false);
// Remove this session from our manager's active sessions
if (manager != null)
manager.remove(this);
// Unbind any objects associated with this session
String keys[] = keys();
for (int i = 0; i keys.length; i++)
removeAttribute(keys[i]);
// Notify interested session event listeners
fireSessionEvent(Session.SESSION_DESTROYED_EVENT, null);
// Notify interested application event listeners
// FIXME - Assumes we call listeners in reverse order
StandardContext context = (StandardContext) manager.getContainer();
Object listeners[] = context.getApplicationListeners();
if (listeners != null) {
HttpSessionEvent event =
new HttpSessionEvent(getSession());
for (int i = 0; i listeners.length; i++) {
int j = (listeners.length - 1) - i;
if (!(listeners[j] instanceof HttpSessionListener))
continue;
HttpSessionListener listener =
(HttpSessionListener) listeners[j];
try {
context.fireContainerEvent(beforeSessionDestroyed,
listener);
listener.sessionDestroyed(event);
context.fireContainerEvent(afterSessionDestroyed,
listener);
} catch (Throwable t) {
context.fireContainerEvent(afterSessionDestroyed,
listener);
// FIXME - should we do anything besides log these?
log(sm.getString(standardSession.sessionEvent), t);
}
}
}
// We have completed expire of this session
expiring = false;
if ((manager != null) (manager instanceof ManagerBase)) {
recycle();
}
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13955] New: - getScheme() and getRequestURL() always return http with JDK 1.3.1
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=13955. 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=13955 getScheme() and getRequestURL() always return http with JDK 1.3.1 Summary: getScheme() and getRequestURL() always return http with JDK 1.3.1 Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We have a servlet that uses the HttpServletRequest.getRequestURL() method to determine the URL it was called from. We are using mod_jk connector between Apache web server and Tomcat and are running Apache version 1.3.22 with SSL. If we run Tomcat 4.1.12 with JDK 1.4 the getScheme() method returns https when we invoke the servlet through https and returns http when we invoke it through http. But if we run Tomcat 4.1.12 with JDK 1.3.1, the getScheme() method returns http no matter whether you invoke it using http or https. The getPort () returns the port number correctly (80 or 443) but the getScheme function returns wrong value for https. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Package Protection: which one?
Hello Jean and company, Funny you bring up this issue. I opened a Tomcat Bugzilla (#12968) to suggest protecting o.a.c/o.a.j but Glenn didn't agree with my intentions. You can refer to the Bugzilla description thread for details: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12968 I concur that protecting server-specific packages such as o.a.c and o.a.j is the way to go, since they are intended to be inaccessible by untrusted code. Regards, -Eddie --- Jean-Francois Arcand [EMAIL PROTECTED] wrote: Remy Maucherat wrote: Jean-Francois Arcand wrote: Hi, testing package protection, I have come to the following conclusion: Packages that we can protect against access -- o.a.catalina o.a.jasper o.a.jsp o.a.jk Packages that we can protect against definition -- o.a.catalina o.a.jasper o.a.jsp o.a.jk o.a.coyote Package that could be protected, but need to change: --- o.a.naming Naming is designed to be secure as is, and shouldn't need protection. o.a.coyote The implementations are protected by facades which have no useful methods for an attacker. o.a.tomcat.util I think this is safe too. If we decide to fully protect o.a.coyote, that means that every calls to CoyoteRequestFacade and CoyoteResponseFacade will need to runs under a doPrivilege blocks (every call that use o.a.tomcat.util). Then o.a.tomcat.util could be protected (only if o.a.coyote is). I made a wrong recommendation last week when I said that o.a.coyote can be protected (rule #1 test using the jakarta workspace, not with your local workspace). Testing with basic servlet prove me the contrary (see 4.1.13 release notesguilty!). I've committed in both Tomcat 4 and 5 the proper protection configuration. I would like to have recommendations based on which package should be protected. Based on the list I will audit package that stay unprotected. I don't think being paranoid would be very useful given that there are facades which are supposed to get the job done. Of course, I'm not the one making the audit, so I don't know for sure. Remy Well, maybe I paranoid (OK I paranoid).but I would prefer protecting all packages and implement the appropriate doPrivileged block. This way we avoid situations like: (1) a new committer add a class to an unprotected package and open a security hole. A good example is, in Tomcat 4, o.a.c.util is not protected because there is no sensitive classes (right Glenn?). But let's say in two year we need to add a class and actual committers are gone because their stock options make them rich (OK I paranoid again :-) ) (2) a hacker breaks a facade and accesses some confidential data. Actually, (2) seems the easiest way to do something bad (and from SUN security group, the most frequent security issue). I must admit that since I'm working on the audit (3 weeks), I did not found any facade that contains a potientally security issues...but IMBW, I'm not an hacker. I would like a decision to protect/not protect a package as soon as possible, since I will not audit a package that is protected (I will just add the appropriate doPrivilege block). And not protecting a package make my life easier since I don't have to implement doPrivileged blocks and try to find every situation when a doPrivileged block is requiredShould we vote? -- Jeanfrancois __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13956] New: - XSI Namespace Declaration Causing JSP Compile 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=13956. 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=13956 XSI Namespace Declaration Causing JSP Compile Errors Summary: XSI Namespace Declaration Causing JSP Compile Errors Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I use XML Spy to create my xml-valid JSPs by providing sun's schema...XML Spy produces a page similar to this: jsp:root xmlns:xtags=http://jakarta.apache.org/taglibs/xtags-1.0; xmlns:jsp=http://java.sun.com/JSP/Page; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/JSP/Page http://java.sun.com/dtd/jspxml.xsd; /jsp:root This, to the best of my knowledge is the correct way to declare a JSP. I have been using these pages since Tomcat 3.x (bundled with JBoss). When migrating these pages to Tomcat 4.1.12 I started receiving compile errors for every page that contains: xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/JSP/Page http://java.sun.com/dtd/jspxml.xsd; The compile error is found at the end of my entry. If I remove this entry the page compiles just fine. Are these invalid namespace declarations that Tomcat was mistakingly allowing before or does the new compiler introduced in 4.1.x have a bug? I have a work-around for this problem (simply remove the declarations), but I am concerned about other namespace entries that may cause a problem. Thanx, Aaron Roller org.apache.jasper.JasperException: Unable to compile class for JSP at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:479) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:469) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at
mavenize tomcat
Hi all, Let me just explain a few things first: 1) I stopped checking out Tomcat from CVS the minute I had to download or check out in concert with (the servlet-api) more than five files and had to setup so many properties that the build refused to run. The time commitment was not worth it to me, so I just started downloading the releases 2) I am an active Maven user - I have three projects using Maven. They aren't as complex as Tomcat, but do do some interesting things for Webapps I would like Tomcat to become easy to build again, when someone decided it was no longer a wise idea to keep the jars in CVS they should have had a reasonable replacement, they didn't and its been painful ever since. I would also like Tomcat to become easy to add documentation to without worrying whether or not something that should have been there (the javadocs for example) was actually there without question. So, If I can get significant developer buy-in I would be willing to cut a version or two of the maven project descriptor for those of us who would like it to be easy again ;-). If not, that's fine. -warner +warner onstine+ -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: mavenize tomcat
Warner Onstine wrote: So, If I can get significant developer buy-in I would be willing to cut a version or two of the maven project descriptor for those of us who would like it to be easy again ;-). If not, that's fine. As long as you don't change build.xml or the gump descriptors - I'm ok. FYI, tomcat5 does have a 'download' target that gets you all the jars, and an 'update' that gets you all the cvs repositories that you need. That's what I use, and it's not that bad ( even if slow ) -- Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: mavenize tomcat
From: news [mailto:news;main.gmane.org]On Behalf Of Costin Manolache Sent: Friday, October 25, 2002 1:51 AM Warner Onstine wrote: So, If I can get significant developer buy-in I would be willing to cut a version or two of the maven project descriptor for those of us who would like it to be easy again ;-). If not, that's fine. As long as you don't change build.xml or the gump descriptors - I'm ok. FYI, tomcat5 does have a 'download' target that gets you all the jars, and an 'update' that gets you all the cvs repositories that you need. That's what I use, and it's not that bad ( even if slow ) 4.1.X too, is just to set 1 property, ant download; ant; Just all, Another time thanks JFC ;) Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
luehe 2002/10/24 17:57:31
Modified:jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
Minor wording change for jsp.error.taglibDirective.absUriCannotBeResolved code
Revision ChangesPath
1.49 +2 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- messages.properties 23 Oct 2002 19:26:37 - 1.48
+++ messages.properties 25 Oct 2002 00:57:31 - 1.49
-246,7 +246,7
jsp.warning.unknown.element.in.variable=Warning: Unknown element {0} in variable
tld.error.variableNotAllowed=It is an error for a tag that has one or more variable
subelements to have a TagExtraInfo class that returns a non-null object.
jsp.error.tldInWebDotXmlNotFound=Could not locate TLD {1} for URI {0} specified in
web.xml
-jsp.error.taglibDirective.absUriCannotBeResolved=This absolute uri ({0}) cannot be
resolved in either web.xml or the jar files deployed with this application
+jsp.error.taglibDirective.absUriCannotBeResolved=The absolute uri: {0} cannot be
resolved in either web.xml or the jar files deployed with this application
jsp.error.taglibDirective.missing.location=Neither 'uri' nor 'tagdir' attribute
specified in taglib directive
jsp.error.invalid.tagdir=Tag file directory {0} does not start with
\/WEB-INF/tags\
jsp.error.unterminated.user.tag=Unterminated user-defined tag: ending tag {0} not
found or incorrectly nested
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13959] New: - The jasper.classpath in build.xml should include ${ant.jar} for the javadoc task.
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=13959.
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=13959
The jasper.classpath in build.xml should include ${ant.jar} for the javadoc task.
Summary: The jasper.classpath in build.xml should include
${ant.jar} for the javadoc task.
Product: Tomcat 4
Version: Nightly Build
Platform: All
OS/Version: All
Status: NEW
Severity: Minor
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I ran into a minor problem while compiling Tomcat 4.1.12 when the \jasper
directory was compiled during the 'ant dist' task. The org.apache.ant classes
could not be found. This issue was corrected by adding:
pathelement location=${ant.jar}/
to the
path id=jasper.classpath
...
/path
element.
Y'll are doing great work. Thanks!
david medinets
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: mavenize tomcat
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 24, 2002 4:50 PM Subject: Re: mavenize tomcat Warner Onstine wrote: So, If I can get significant developer buy-in I would be willing to cut a version or two of the maven project descriptor for those of us who would like it to be easy again ;-). If not, that's fine. As long as you don't change build.xml or the gump descriptors - I'm ok. With the new Maven, it isn't necessary, it now only uses Ant under the covers with Jelly and Werkz tags doing the work with the POM (Project Object Model). FYI, tomcat5 does have a 'download' target that gets you all the jars, and an 'update' that gets you all the cvs repositories that you need. That's what I use, and it's not that bad ( even if slow ) Interesting, sounds like it is duplicating what Maven can do as it stores all the jars in a common repository. -warner -- Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13960] New: - Incompatible Javadoc Comments in EmbededServletOptions.java
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=13960.
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=13960
Incompatible Javadoc Comments in EmbededServletOptions.java
Summary: Incompatible Javadoc Comments in
EmbededServletOptions.java
Product: Tomcat 4
Version: Nightly Build
Platform: All
OS/Version: All
Status: NEW
Severity: Minor
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
While compiling Tomcat v4.1.12, I received serveral Javadoc errors in
org/apache/jasper/EmbededServletOptions.java. I updated several comments to
avoid using the question mark punctuation which javadoc doesn't like. I don't
have the cvs diff program, so I'm simply including the updated comments and
their associated class elements.
In org/apache/jasper/EmbededServletOptions.java - Please change the comments
for the following variables so the first sentence is found correctly.
/**
* Toggles support for large files. What this essentially
* means is that we generated code so that the HTML data in a JSP
* file is stored separately as opposed to those constant string
* data being used literally in the generated servlet.
*/
public boolean largeFile = false;
/**
* Toggles support for mapped files. This will generate
* servlet that has a print statement per line of the JSP file.
* This seems like a really nice feature to have for debugging.
*/
public boolean mappedFile = false;
/**
* Toggles stack traces and such displayed in the client's
* browser. If this is false, such messages go to the standard
* error or a log file if the standard error is redirected.
*/
public boolean sendErrorToClient = false;
/**
* Toggles including debugging information in the class file.
*/
public boolean classDebugInfo = true;
/**
* Toggles the JSP reloading check.
*/
public boolean reloading = true;
/**
* Specifies the directory for the generated servlets.
*/
public File scratchDir;
/**
* Specifies the classpath to use while compiling generated servlets.
*/
public String classpath = null;
/**
* Getter method to see if generated code is being kept.
*/
public boolean getKeepGenerated() {
return keepGenerated;
}
/**
* Getter method to see if we supporting large files.
*/
public boolean getLargeFile() {
return largeFile;
}
/**
* Getter method to determine if we supporting HTML mapped servlets.
*/
public boolean getMappedFile() {
return mappedFile;
}
/**
* Getter method to determine if errors should be sent to client or thrown
into stderr.
*/
public boolean getSendErrorToClient() {
return sendErrorToClient;
}
/**
* Getter method to determine if class filesshould be compiled with debug
information.
*/
public boolean getClassDebugInfo() {
return classDebugInfo;
}
/**
* Getter method to determine if Jasper is being used in development mode?
*/
public boolean getDevelopment() {
return development;
}
/**
* Getter method to determine JSP reloading.
*/
public boolean getReloading() {
return reloading;
}
/**
* Getter method to determine the scratch dir.
*/
/**
* Getter method to determine the classpath used while compiling the
servlets
* generated from JSP files.
*/
public String getClassPath() {
return classpath;
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13961] New: - Incompatible Javadoc Comments in JspRuntimeContext.java
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=13961. 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=13961 Incompatible Javadoc Comments in JspRuntimeContext.java Summary: Incompatible Javadoc Comments in JspRuntimeContext.java Product: Tomcat 4 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In org/apache/jasper/compiler/JspRuntimeContext.java - JspRuntimeContext method To avoid internationalization error messages, change first line comment from: * Class for tracking JSP compile time file dependencies when the * lt;%@include file=...%gt; directive is used. to * Class for tracking JSP compile time file dependencies when the * %@include file=...% directive is used. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 13907] - security manager does not give readpermission on a context by default
Aditya wrote: Glenn, On Thu, Oct 24, 2002 at 10:03:47AM -, [EMAIL PROTECTED] wrote: This must be a problem in your local system configuration. Check the unix file ownerhsip and permissions for test2.new. I've done that and the fact is that it works fine without the security manager so it's not a unix file ownership and permissions problem. Also try running Tomcat with java property -Djava.security.debug=access,failure defined and then check the security manager debug output. yup, done that and the output has nothing more than the failure of read permissions. I just tested the jsp you posted with a fresh build of Tomcat 4.1 from the CVS head (What will be Tomcat 4.1.13) and Jasper 2. The FilePermission read for the context directory is being granted automatically and the JSP works. I just read the 4.1.13 announcement from Remy and it has the following note: IMPORTANT NOTE: Security manager functionality is broken in this milestone. This will be fixed in the next milestone. This milestone will not be proposed for official release, and should be used for testing purposes only. so before I checkout a fresh copy from CVS, need I be worried about this? Tomcat and Jasper1/Jasper2 have granted web applications and JSP pages read access to their own context directory since the SecurityManager was first implemented years ago. I don't recall there ever being a bug with this or that it has changed. I was just verifying that the code hadn't been inadvertently broken. Gettting the latest version from CVS won't fix your problem. I still think the problem is somewhere in your configuration. You might try posting the SecurityManager debug output when the FilePermission read is denied. Including the stack trace and the ProtectionDomain which failed. Regards, Glenn -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13962] New: - Incompatible Javadoc Comments in org/apache/jasper/logging/Logger.java
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=13962. 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=13962 Incompatible Javadoc Comments in org/apache/jasper/logging/Logger.java Summary: Incompatible Javadoc Comments in org/apache/jasper/logging/Logger.java Product: Tomcat 4 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In org/apache/jasper/logging/Logger.java - setTimestampFormat method. To avoid an issue with the question mark in the first comment. Using the following comment: /** * Setter method to control the format used when printing * the timestamp. Note that timestamping might not be used. * See java.text.SimpleDateFormat. * * Default = -MM-dd hh:mm:ss. Special case: msec = raw * number of msec since epoch, very efficient but not * user-friendly **/ public void setTimestampFormat(String value) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13963] New: - Incompatible Javadoc Comments in org/apache/jasper/compiler/Node.java
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=13963.
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=13963
Incompatible Javadoc Comments in org/apache/jasper/compiler/Node.java
Summary: Incompatible Javadoc Comments in
org/apache/jasper/compiler/Node.java
Product: Tomcat 4
Version: Nightly Build
Platform: Other
OS/Version: Other
Status: NEW
Severity: Minor
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
A space was added to the comment incorrectly for the getParentRoot method. The
corrected comment is:
/**
* @return The enclosing root to this root. Usually represents the
* page that includes this one.
*/
public Root getParentRoot() {
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13964] New: - Incompatible Javadoc Comments in jasper\runtime\BodyContentImpl.java
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=13964.
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=13964
Incompatible Javadoc Comments in jasper\runtime\BodyContentImpl.java
Summary: Incompatible Javadoc Comments in
jasper\runtime\BodyContentImpl.java
Product: Tomcat 4
Version: Nightly Build
Platform: Other
OS/Version: Other
Status: NEW
Severity: Minor
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The code used @returns instead of @return. The following snippet shows the
corrected code.
/**
* Return the value of this BodyJspWriter as a Reader.
* Note: this is after evaluation!! There are no scriptlets,
* etc in this stream.
*
* @return the value of this BodyJspWriter as a Reader
*/
public Reader getReader() {
return new CharArrayReader (cb, 0, nextChar);
}
/**
* Return the value of the BodyJspWriter as a String.
* Note: this is after evaluation!! There are no scriptlets,
* etc in this stream.
*
* @return the value of the BodyJspWriter as a String
*/
public String getString() {
return new String(cb, 0, nextChar);
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13965] New: - Need a way to globally configure Jasper options
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=13965. 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=13965 Need a way to globally configure Jasper options Summary: Need a way to globally configure Jasper options Product: Tomcat 4 Version: 4.1.13 Platform: Other OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I set up 4.1.13 today, added the enablePooling=false param to $CATALINA_HOME/conf/web.xml, and pointed the docBase to my old Servlet 2.2/Jsp 1.1 application. Tomcat then choose to compile all of my jsp-file servlets with the default enablePooling=true, with not very happy results :(. I know that there is the work-around of adding the enablePooling=false param to all of my jsp-file servlets, but it would be nice if there was an easier way to do this. For this particular application, I don't believe that I'll be actually gaining (and may even lose) by trading syncs for gc. I'll still want pooling off even after the taglib is lifecycle-compliant. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: 4.0.7 release?
Jon Scott Stevens wrote: Scarab only works in Tomcat 4.1.x if you use JDK 1.4.x. It does not work with JDK 1.3.x If you can get Scarab to work with Tomcat 4.1.x on JDK 1.3.x, let me know how you got it to work and I will immediately switch Scarab to use Tomcat 4.1.x. I am running scarab B13 using Tomcat 4.1.x, JDK 1.3.1, and the SecurityManager. I would have to go back and look at my config to see how I am doing it. Once again, we are just testing scarab and working through how we want to configure modules, attributes, etc. for our needs. Wemay not have tried whatever feature causes the problem. Do you have an example of how to trigger it? Regards, Glenn -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Catalina.sh on Tru64 Unix v 5.1 Problem
Dear All,
I have extract jakarta-tomcat-4.1.12 on my Tru64 Unix v 5.1 (DEC Alpha).
The problem is catalina.sh couldn't work.
./catalina.sh start
Using CATALINA_BASE: /var/jakarta-tomcat-4.1.12
Using CATALINA_HOME: /var/jakarta-tomcat-4.1.12
Using CATALINA_TMPDIR: /var/jakarta-tomcat-4.1.12/temp
Using JAVA_HOME: /usr/opt/java140
catalina.out:
usage: java org.apache.catalina.startup.Catalina [ -config {pathname} ] [ -debug ] [
-nonaming ] { start | stop }
But Tomcat can start if i run directly using the following command:
/usr/opt/java140/bin/java
-Djava.endorsed.dirs=/var/jakarta-tomcat-4.1.12/bin:/var/jakarta-tomcat-4.1.12/common/endorsed
-classpath
/usr/opt/java140/lib/tools.jar:/var/jakarta-tomcat-4.1.12/bin/bootstrap.jar
-Dcatalina.base=/var/jakarta-tomcat-4.1.12 -Dcatalina.home=/var/jakarta-tomcat-4.1.12
-Djava.io.tmpdir=/var/jakarta-tomcat-4.1.12/temp org.apache.catalina.startup.Bootstrap
start
My Questions:
1. How to fix the catalina.sh?
This problem occur when i run on my DEC Tru64 Unix.
2. Is there any /etc/rc.d/init.d/tomcat4 (start|stop|restart) available
for Tru64 Unix?
TIA,
Yon
_
Get [EMAIL PROTECTED] at http://www.dugem.com
_
Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB,
POP more! http://www.everyone.net/selectmail?campaign=tag
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13965] - Catalina.sh correction request for Tru64 Unix
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=13965.
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=13965
Catalina.sh correction request for Tru64 Unix
[EMAIL PROTECTED] changed:
What|Removed |Added
Component|Jasper 2|Catalina
Keywords||PatchAvailable
Summary|Need a way to globally |Catalina.sh correction
|configure Jasper options|request for Tru64 Unix
--- Additional Comments From [EMAIL PROTECTED] 2002-10-25 04:51 ---
Dear All,
I have extract jakarta-tomcat-4.1.12 on my Tru64 Unix v 5.1 (DEC Alpha).
The
problem is catalina.sh couldn't work.
./catalina.sh start
Using CATALINA_BASE:
/var/jakarta-tomcat-4.1.12
Using CATALINA_HOME: /var/jakarta-tomcat-4.1.12
Using
CATALINA_TMPDIR: /var/jakarta-tomcat-4.1.12/temp
Using JAVA_HOME:
/usr/opt/java140
catalina.out:
usage: java
org.apache.catalina.startup.Catalina [ -config {pathname} ] [ -debug ] [ -nonaming ] {
start | stop
}
But Tomcat can start if i run directly using the following
command:
/usr/opt/java140/bin/java -Djava.endorsed.dirs=/var/jakarta-tomcat-
4.1.12/bin:/var/jakarta-tomcat-4.1.12/common/endorsed -classpath
/usr/opt/java140/lib/tools.jar:/var/jakarta-tomcat-4.1.12/bin/bootstrap.jar -
Dcatalina.base=/var/jakarta-tomcat-4.1.12 -Dcatalina.home=/var/jakarta-tomcat-4.1.12 -
Djava.io.tmpdir=/var/jakarta-tomcat-4.1.12/temp org.apache.catalina.startup.Bootstrap
start
My Questions:
How to fix the catalina.sh?
This problem occur when i run on my
DEC Tru64 Unix.
TIA,
Yon
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-4.0 build.xml
billbarker2002/10/24 22:44:37
Modified:.build.xml
Log:
Change the download target for commons-logging commons-dbcp to do a download
instead of a cvs build.
These two have been released now (and are set correctly in build.properties.sample).
The download target should get the targeted version.
Revision ChangesPath
1.77 +6 -31 jakarta-tomcat-4.0/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/build.xml,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- build.xml 30 Sep 2002 10:46:06 - 1.76
+++ build.xml 25 Oct 2002 05:44:37 - 1.77
-464,25 +464,11
param name=destfile value=${commons-digester.jar}/
/antcall
-!-- we need the release to happend, in the meantime use cvs...
+!-- Commons Logging--
antcall target=downloadgz
param name=sourcefile value=${commons-logging.loc}/
param name=destfile value=${commons-logging.jar}/
/antcall
---
-antcall target=cvsbuild
- param name=location value=${commons-logging.loc}/
- param name=subdir value=${commons-logging.home}/
- param name=destfile value=${commons-logging.jar}/
-/antcall
-copy
- file=${commons-logging.home}/dist/commons-logging.jar
- tofile=${commons-logging.jar}
-/
-copy
- file=${commons-logging.home}/dist/commons-logging-api.jar
- tofile=${commons-logging-api.jar}
-/
antcall target=downloadgz
param name=sourcefile value=${regexp.loc}/
-502,7 +488,6
param name=destfile value=${xmlParserAPIs.jar}/
/antcall
!-- commons- daemons/dbcp/pool need something different. --
-
antcall target=cvsbuild
param name=location value=${commons-daemon.loc}/
param name=subdir value=${commons-daemon.home}/
-514,21 +499,11
param name=destfile value=${commons-pool.jar}/
/antcall
-!-- commons-dbcp needs pool and ../LICENSE --
-!-- That is ugly XXX needs a review --
-copy file=LICENSE tofile=../LICENSE/
-antcall target=cvsbuild
- param name=location value=${commons-dbcp.loc}/
- param name=subdir value=${commons-dbcp.home}/
- param name=destfile value=${commons-dbcp.jar}/
- param name=name value=commons-dbcp/
-/antcall
-!-- Dbcp does not put commons-dbcp.jar in ${commons-dbcp.home} --
-copy
- file=${commons-dbcp.home}/dist/commons-dbcp.jar
- tofile=${commons-dbcp.jar}
-/
-
+antcall target=downloadzip
+ param name=sourcefile value=${commons-dbcp.loc} /
+ param name=destfile value=${commons-dbcp.jar} /
+ param name=destdir value=${commons-dbcp.home} /
+/antcall
antcall target=downloadgz
param name=sourcefile value=${commons-modeler.loc}/
param name=destfile value=${commons-modeler.jar}/
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[4.1.13] New test milestone released
A new test milestone of Tomcat 4.1 has just been released. Please help test this upcoming Tomcat release for compliance issues and other problems. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.13/ Significant changes over 4.1.12 include some performance improvements as well as bugfixes. The full list of changes is available in the release notes. http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.13/RELEASE-NOTES IMPORTANT NOTE: Security manager functionality is broken in this milestone. This will be fixed in the next milestone. This milestone will not be proposed for official release, and should be used for testing purposes only. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
javadocs - please!!!!!!!!!!!!!!!
Ok, I have now waited for over a week to see the javadocs back on the web-site or in the 4.1.12 build. Could someone please just build the docs and put them on the site? And don't tell me to build them myself. I can't put them on the site, someone who is in charge of the site needs to do this. I'm not the only one asking for this (and I also thinks it's ridiculous that there is a broken link on the site, we're developers haven't we heard of QA?). If you guys were using something like Maven this wouldn't be an issue - it automatically includes the javadoc as part of the documentation (and it makes it a heck of a lot easier to build large projects, one reason I won't ever check tomcat out again until it's build process is easier). -warner +warner onstine+ -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
