Re: [ANN] Tomcat 4.1.22 Alpha released
Costin Manolache wrote: Henri Gomez wrote: Henri Gomez wrote: Remy Maucherat wrote: Tomcat 4.1.22 Alpha is now available for testing. Changes over 4.1.21 include: - Fix for mangling with JSPC - Fix precompilation with tag libraries packaged in JARs - Fix JDBC store thread safety bug which was causing improper session access The release notes include the full list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.22-alpha/ I've got very strange problem when building 4.1.22, some jar are corrupted !!! BTW, I'm using ant 1.5.2 (maybe a problem with it ?) The problem came from the fact I built ant 1.5.2 with jikes 1.18 and IBM SDK 1.4.0 on linux. I rebuilt ant 1.5.2 with IBM SDK 1.3.1 and no more problems. False alert (but may be Costin could forward it to ant-dev since I didn't track this list right now). There is a problem with ant1.5.2 with WinZip - a new release will be made soon to fix it. I don't know what ant can do wrt the compiler. I don't know either but ant 1.5.2 rebuilt with SDK 1.3.1 didn't produce corrupted jars. BTW, there is still the problem when building tomcat 4 with jikes : build-main: [javac] Compiling 170 source files to /usr/src/redhat/BUILD/tomcat4-4.1.21/jakarta-tomcat-4.1.21-src/webapps/build/admin/WEB-INF/classes [javac] Found 2 semantic errors compiling /usr/src/redhat/BUILD/tomcat4-4.1.21/jakarta-tomcat-4.1.21-src/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java: [javac]129. mBServer = servlet.getServer(); [javac]^---^ [javac] *** Semantic Error: You need to modify your classpath, sourcepath, bootclasspath, and/or extdirs setup. Package javax/sql could not be found in: [javac] /opt/IBMJava2-131/jre/lib/ext/ibmjcaprovider.jar [javac] /opt/IBMJava2-131/jre/lib/ext/jaas.jar [javac] /opt/IBMJava2-131/jre/lib/ext/jaas_lm.jar [javac] /opt/IBMJava2-131/jre/lib/ext/comm.jar [javac] /opt/IBMJava2-131/jre/lib/ext/indicim.jar [javac] /usr/src/redhat/BUILD/tomcat4-4.1.21/jakarta-tomcat-4.1.21-src/webapps/build/admin/WEB-INF/classes [javac] /usr/share/java/commons-modeler.jar [javac] /usr/share/java/mx4j-jmx.jar [javac] /usr/share/java/regexp-1.2.jar [javac] /usr/share/java/servletapi4.jar [javac] /usr/share/java/struts.jar [javac] /usr/share/java/commons-beanutils.jar [javac] /usr/share/java/ant/junit.jar [javac] /usr/share/java/ant/jaxp_transform_impl.jar [javac] /usr/share/java/ant/jasper331p2.jar [javac] /usr/share/java/ant/GenJar-1.0.0.jar [javac] /usr/share/java/ant/ant-translator-1.0b2.jar [javac] /usr/share/java/xml-commons-apis.jar [javac] /usr/share/java/jaxp_parser_impl.jar [javac] /usr/share/java/ant-optional.jar [javac] /usr/share/java/ant.jar [javac] /usr/share/java/xalan-j2.jar [javac] /opt/IBMJava2-131/lib/tools.jar [javac] /opt/IBMJava2-131/jre/lib/rt.jar [javac] /usr/src/redhat/BUILD/tomcat4-4.1.21/jakarta-tomcat-4.1.21-src/webapps/admin/WEB-INF/classes [javac] . [javac]129. mBServer = servlet.getServer(); [javac]^---^ [javac] *** Semantic Error: Type javax.sql.DataSource was not found. BUILD FAILED file:/usr/src/redhat/BUILD/tomcat4-4.1.21/jakarta-tomcat-4.1.21-src/webapps/admin/build.xml:196: Compile failed; see the compiler error output for details. Didn't works for 4.1.21 and 4.1.22 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK2 for AOLserver 4.0
Alexander Leyke wrote: Hello, I am a developer at AOL and have been recently working on a JK2 family module for AOLserver. The module is ready now and I'd like to take steps necessary to contribute the sources to Tomcat project. I read the guidelines for contribution, but still am a bit confused about the process, e.g., -- should I formulate proposal to a PMC? Not necessary, just send the updated sources in this list and use the standard ASF licence header. -- do I need write permission to CVS to make the submission or posting an archive with instructions to tomcat-dev list is the way to go? Only commiters have cvs write access. -- how do I interact with Decision Makers should the code manifest any deficiency? Since you'll became our AOL specialist, you'll be the one to which bug reports on JK2/AOL will be adressed ;) Please advise. In the meantime, some details about this software Name: nsjk2 (libnsjk2.so) Versions: Tomcat 4.1.18, AOLserver 4.0(beta) Tested on OS: Solaris 2.7 Compiles under: Forte 6, GCC Functional Summary: -- adds support for Java Servlets and JSP to AOLserver environment; -- supports virtual servers -- when Tomcat runs in-process and talks with JK2 via JNI channel, Java servlets can access native dynamic content mechanism (ADP) and evaluate Tcl scripts or include ADP pages. Source files affected: jakarta-tomcat-connectors-src/jk/build.properties jtc-src/jk/native2/build.xml jtc-src/jk/native2/server (adds aolserver directory with C and Java sources) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat as it's own apache subproject ?
Did some of you ever think that Tomcat could became a direct Apache subproject, like ant ? It seems Maven follow the same way. As such having Tomcat as a direct Apache projects will allow a Tomcat PMC ? Costin, Remy, other commiters, what do you think ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17867] New: - new virtual host doesn't work after restart
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=17867. 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=17867 new virtual host doesn't work after restart Summary: new virtual host doesn't work after restart Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] While I'm testing new host with new context in current session, it works. after restart it reports an error HTTP Status 500 - No Context configured to process this request - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17860] - JAVA_ENDORSED_DIRS overrides jdk1.4's default java.endorsed.dirs property
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=17860. 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=17860 JAVA_ENDORSED_DIRS overrides jdk1.4's default java.endorsed.dirs property --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 12:21 --- I think you are correct in preserving the endorsed dirs property but it should give precedence to Catalina THEN to the J2SDK property. JAVA_ENDORSED_DIRS=$BASEDIR/common/endorsed:$BASEDIR/bin:$JAVA_HOME/jre/li b/endorsed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17860] - JAVA_ENDORSED_DIRS overrides jdk1.4's default java.endorsed.dirs property
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=17860. 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=17860 JAVA_ENDORSED_DIRS overrides jdk1.4's default java.endorsed.dirs property [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 12:24 --- This is equivalent to asking why the system CLASSPATH is ignored. You're free to hack the startup script, but this won't go into the main distribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17873] New: - jar_cache files that are deleted are kept open by the tomcat java process
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=17873. 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=17873 jar_cache files that are deleted are kept open by the tomcat java process Summary: jar_cache files that are deleted are kept open by the tomcat java process Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This leads to an out of file descriptor error on our setup, we have 10 webapps deployed and ca 40 jar files in each web app. I know that I can raise the file descriptor limit on Linux, but I still don't see why these file handles should be kept open if the files don't exist.. In our setup with 10 webapps on one tomcat server it holds 274 open file descriptors to jar_cache files, when the default limit on Linux then is ca 1000 open files pr process this is a significant %. example listing from proc/pid/fd ls -l | grep .tmp /proc/1040/fd lr-x--1 tomcat users 64 Mar 11 13:53 990 - /home/tomcat/tomcat/temp/jar_cache49400.tmp (deleted) lr-x--1 tomcat users 64 Mar 11 13:53 991 - /home/tomcat/tomcat/temp/jar_cache49402.tmp (deleted) lr-x--1 tomcat users 64 Mar 11 13:53 992 - /home/tomcat/tomcat/temp/jar_cache49405.tmp (deleted) lr-x--1 tomcat users 64 Mar 11 13:53 993 - /home/tomcat/tomcat/temp/jar_cache49403.tmp (deleted) lr-x--1 tomcat users 64 Mar 11 13:53 994 - /home/tomcat/tomcat/temp/jar_cache49404.tmp (deleted) lr-x--1 tomcat users 64 Mar 11 13:53 995 - /home/tomcat/tomcat/temp/jar_cache49410.tmp (deleted) lr-x--1 tomcat users 64 Mar 11 13:53 996 - /home/tomcat/tomcat/temp/jar_cache49406.tmp (deleted) lr-x--1 tomcat users 64 Mar 11 13:53 997 - /home/tomcat/tomcat/temp/jar_cache49407.tmp (deleted) lr-x--1 tomcat users 64 Mar 11 13:53 998 - /home/tomcat/tomcat/temp/jar_cache49408.tmp (deleted) lr-x--1 tomcat users 64 Mar 11 13:53 999 - /home/tomcat/tomcat/temp/jar_cache49409.tmp (deleted) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JDBCRealm getPassword() unimplemented in Tomcat 4.1.18 (returns null)
Hi, I am unable to authenticate using digest authentication. I browsed through the code and found that getPassword() method in JDBCRealm returns null (harcoded). I am using the following configuration. Am I missing something somewhere? server.xml: -- Realm className=org.apache.catalina.realm.JDBCRealm debug=99 digest=MD5 driverName=oracle.jdbc.driver.OracleDriver connectionURL=jdbc:oracle:thin:@lohgad:1521:dsoft connectionName=uddhav connectionPassword=uddhav userTable=tab_users userNameCol=user_name userCredCol=user_pass userRoleTable=tab_user_roles roleNameCol=role_name / web.xml: - login-config auth-methodDIGEST/auth-method realm-nameOnJava Application/realm-name /login-config - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBCRealm getPassword() unimplemented in Tomcat 4.1.18 (returns null)
Hi,
I have implemeted the methods getPassword() and getPrincipal() in
JDBCRealm. Digest authentication works for me with these changes. One thing
that still doest work is if I have stored the password in encrypted form in
the database. I have doubts if this will always work in the scenario where
the password has been persisted using say SHA and the web authentication
utilises MD5. Will the responseDigest send by client and the one generated
at the server match?
Following are the chages I have made. I am new to this forum, can somebody
guide me on how these changes can be committed if approved. Thanks.
/**
* Return the password associated with the given principal's user name.
*/
protected String getPassword(String username) {
Connection dbConnection = null;
String dbCredentials = null;
try {
// Ensure that we have an open database connection
dbConnection = open();
// Look up the user's credentials
PreparedStatement stmt = credentials(dbConnection, username);
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
dbCredentials = rs.getString(1).trim();
}
rs.close();
if (dbCredentials == null) {
return (null);
}
// Release the database connection we just used
release(dbConnection);
} catch (SQLException e) {
e.printStackTrace();
// Log the problem for posterity
log(sm.getString(jdbcRealm.exception), e);
// Close the connection so that it gets reopened next time
if (dbConnection != null)
close(dbConnection);
}
return (dbCredentials);
// return (null); // earlier code
}
/**
* Return the Principal associated with the given user name.
*/
protected Principal getPrincipal(String username) {
Connection dbConnection = null;
GenericPrincipal principal = null;
try {
String credentials = getPassword(username);
// Ensure that we have an open database connection
dbConnection = open();
// Accumulate the user's roles
ArrayList list = new ArrayList();
PreparedStatement stmt = roles(dbConnection, username);
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
list.add(rs.getString(1).trim());
}
rs.close();
dbConnection.commit();
// Create and return a suitable Principal for this user
principal = (new GenericPrincipal(this, username, credentials,
list));
// Release the database connection we just used
release(dbConnection);
} catch (SQLException e) {
e.printStackTrace();
// Log the problem for posterity
log(sm.getString(jdbcRealm.exception), e);
// Close the connection so that it gets reopened next time
if (dbConnection != null)
close(dbConnection);
}
return (principal);
// return (null); // earlier code
}
- Original Message -
From: Uddhav Shirname [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 7:07 PM
Subject: JDBCRealm getPassword() unimplemented in Tomcat 4.1.18 (returns
null)
Hi,
I am unable to authenticate using digest authentication. I browsed
through the code and found that getPassword() method in JDBCRealm returns
null (harcoded). I am using the following configuration. Am I missing
something somewhere?
server.xml:
--
Realm
className=org.apache.catalina.realm.JDBCRealm
debug=99
digest=MD5
driverName=oracle.jdbc.driver.OracleDriver
connectionURL=jdbc:oracle:thin:@lohgad:1521:dsoft
connectionName=uddhav
connectionPassword=uddhav
userTable=tab_users
userNameCol=user_name
userCredCol=user_pass
userRoleTable=tab_user_roles
roleNameCol=role_name /
web.xml:
-
login-config
auth-methodDIGEST/auth-method
realm-nameOnJava Application/realm-name
/login-config
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/webapps/admin/valve accessLogValve.jspremoteAddrValve.jsp remoteHostValve.jsp requestDumperValve.jsp singleSignOnValve.jsp
[EMAIL PROTECTED] wrote: amyroh 2003/03/11 06:15:45 Modified:webapps/admin banner.jsp webapps/admin/WEB-INF/classes/org/apache/webapp/admin Lists.java TomcatTreeBuilder.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector AddConnectorAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/context AddContextAction.java DeleteContextAction.java EditContextAction.java SaveContextAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/host EditHostAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/logger AddLoggerAction.java DeleteLoggerAction.java EditLoggerAction.java LoggerForm.java SaveLoggerAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm AddRealmAction.java DeleteRealmAction.java EditRealmAction.java RealmForm.java SaveJDBCRealmAction.java SaveJNDIRealmAction.java SaveMemoryRealmAction.java SaveUserDatabaseRealmAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources ListDataSourcesAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service EditServiceAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/valve AddValveAction.java DeleteValveAction.java DeleteValvesAction.java EditValveAction.java SaveAccessLogValveAction.java SaveRemoteAddrValveAction.java SaveRemoteHostValveAction.java SaveRequestDumperValveAction.java SaveSingleSignOnValveAction.java ValveForm.java ValveUtil.java webapps/admin/context context.jsp webapps/admin/logger logger.jsp webapps/admin/realm jdbcRealm.jsp jndiRealm.jsp memoryRealm.jsp userDatabaseRealm.jsp webapps/admin/valve accessLogValve.jsp remoteAddrValve.jsp remoteHostValve.jsp requestDumperValve.jsp singleSignOnValve.jsp Log: Update create/remove/edit for context, logger, realm, and valve to support the new jsr77 name for context. Need to test all the component ops more tomorrow... Amy, could you talk to someone before making that sort of changes ? The idea is that the stable branch is stable, and that big changes will bring no interesting feature except instability. Why didn't you start doing them in the 5.0 branch and then eventually port them ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17878] New: - JSPC not working properly with package names
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=17878. 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=17878 JSPC not working properly with package names Summary: JSPC not working properly with package names Product: Tomcat 4 Version: 4.1.22 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] JSPC is creating .java files with package names based on directory structure, but when I go to a jsp page via my web app it still wants the package to be org.apache.jsp so I get an error will all jsp pages. If I set the package to be org.apache.jsp in jspc then it just prepends that to the rest of the package name so /test/test.jsp becomes org.apache.jsp.test.test_jsp.java is there a way around this without mapping all my jsp pages in the web.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17878] - JSPC not working properly with package names
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=17878. 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=17878 JSPC not working properly with package names --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 15:03 --- Created an attachment (id=5262) ant script to show problem - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17878] - JSPC not working properly with package names
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=17878. 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=17878 JSPC not working properly with package names --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 15:04 --- If you run the following ant script in your examples webapp directory, then try to go to any example jsp page you get the following error javax.servlet.ServletException: org/apache/jsp/numguess_jsp (wrong name: jsp/num/numguess_jsp) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17878] - JSPC not working properly with package names
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=17878. 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=17878 JSPC not working properly with package names [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 15:04 --- John, I always find your bug reports frustrating. Please use the Ant build scrtipt included in the documentation, and add the mappings. The behavior you report is completely normal. Please do not reopen this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17878] - JSPC not working properly with package names
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=17878. 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=17878 JSPC not working properly with package names --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 15:17 --- Sorry Remy I read the release notes and they said nothing about changes to the way JSPC functions. So now the only way you can use JspC is by mapping all the jsp pages. This seems like a poor solution if you have 1000+ jsp pages as your web.xml seems to become unmanagable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK2 for AOLserver 4.0
Alexander Leyke wrote: I am a developer at AOL and have been recently working on a JK2 family module for AOLserver. The module is ready now and I'd like to take steps necessary to contribute the sources to Tomcat project. I read the Just send the patches and the new files. You can open an enhancement request in bugzilla and attach them. If you are willing to maintain the code and stick around for a while - you may want to send more patches, and you can become a committer. -- how do I interact with Decision Makers should the code manifest any deficiency? That's the biggest issue - you'll be the decision maker for this code :-) If it becomes clear that you are willing to fix the bugs and maintain the code, and want to get more involved in the tomcat community - you'll be proposed as committer ( and become an official decision maker :-). Source files affected: jakarta-tomcat-connectors-src/jk/build.properties jtc-src/jk/native2/build.xml jtc-src/jk/native2/server (adds aolserver directory with C and Java sources) Sounds good. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17878] - JSPC not working properly with package names
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=17878. 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=17878 JSPC not working properly with package names --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 15:22 --- I don't agree. The changlog and the announcement explicitely mention JSPC changes. The big change is that the files are packaged properly now. The wb.xml generation is automatic, and can be inserted easily into the XML by Ant. Please read the documentation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17878] - JSPC not working properly with package names
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=17878. 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=17878 JSPC not working properly with package names --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 15:30 --- This is all the release notes say about JspC [4.1.22] JspC: Add package name mangling for Java keywords. [4.1.22] JspC: Add documentation. now the change log and javadocs do have more but the release notes should point out a change in functionality. My problem with this implementation of jspc is now jspc does not generate jsp pages in the same manner as going to a web page and clicking on the jsp. (which is why the mappings are now needed) If JspC is supposed to be a precompiler for jsp pages I would expect it to work in the same manner that going to the web page would work. but if this is the way the communtity wants it to work that is fine.. the beauty of opensouce is I can change some code to work the way I want. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans MBeanFactory.java ServerLifecycleListener.java
[EMAIL PROTECTED] wrote:
amyroh 2003/03/10 19:25:52
Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanFactory.java ServerLifecycleListener.java
Log:
Set to use JSR77 names as default.
Please make sure tomcat 5 is also updated.
I would do it in reverse - first tc5 and then backport.
Costin
Revision ChangesPath
1.41 +11 -8
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanFactory.java
Index: MBeanFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanFactory.java,v
retrieving revision 1.40 retrieving revision 1.41
diff -u -r1.40 -r1.41
--- MBeanFactory.java 19 Sep 2002 22:55:48 - 1.40
+++ MBeanFactory.java 11 Mar 2003 03:25:52 - 1.41
@@ -1227,13 +1227,16 @@
*
* @exception Exception if a component cannot be removed
*/
-public void removeContext(String name) throws Exception {
+public void removeContext(String name, String pname) throws
Exception {
// Acquire a reference to the component to be removed
ObjectName oname = new ObjectName(name);
-String serviceName = oname.getKeyProperty(service);
-String hostName = oname.getKeyProperty(host);
-String contextName = getPathStr(oname.getKeyProperty(path));
+ObjectName poname = new ObjectName(pname);
+String serviceName = poname.getKeyProperty(service);
+String hostName = poname.getKeyProperty(host);
+String pathname = oname.getKeyProperty(name);
+String path = pathname.substring(pathname.lastIndexOf('/'));
+String contextName = getPathStr(path);
Server server = ServerFactory.getServer();
Service service = server.findService(serviceName);
Engine engine = (Engine) service.getContainer();
1.38 +5 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
Index: ServerLifecycleListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
retrieving revision 1.37 retrieving revision 1.38
diff -u -r1.37 -r1.38
--- ServerLifecycleListener.java12 Feb 2003 22:11:27 - 1.37
+++ ServerLifecycleListener.java11 Mar 2003 03:25:52 - 1.38
@@ -367,6 +367,7 @@
try {
+setJsr77Names(true);
MBeanFactory factory = new MBeanFactory();
createMBeans(factory);
createMBeans(ServerFactory.getServer());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat as it's own apache subproject ?
Henri Gomez wrote: Did some of you ever think that Tomcat could became a direct Apache subproject, like ant ? It seems Maven follow the same way. As such having Tomcat as a direct Apache projects will allow a Tomcat PMC ? Costin, Remy, other commiters, what do you think ? I'm personally -1 ( quite strongly ), but if the majority believes otherwise I can change my vote to -0. I think jakarta is a good home for tomcat, and it's getting better. Most projects that are still in jakarta are 'close' enough to tomcat - taglibs, struts, commons, slide, velocity/turbine, log4j, etc - we do have a lot of things in common and I think we would benefit far more from staying close to those projects and sharing the same community. My understanding is that Jakarta will move into this direction - to become a single community, with most committers in the jakarta PMC. It'll mean that struts or taglib committers will be able to vote or even commit code to tomcat. ( key committers from all other projects already do ). I think this is great, and I hope that one day we'll have one jakarta release with all the technology that remains part of jakarta. Beeing in the same community can only increase the quality of the code and the cross-polination. Of course - this is majority vote, and I have only one vote. Regarding PMC - there are already quite a few tomcat committers in jakarta PMC, and the intention is to get everyone who is active. Last round included release managers from all jakarta projects - but the process just started. BTW - we can leave at any time, I think it may be worth it to see how this big community works out. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat as it's own apache subproject ?
Costin Manolache wrote: Henri Gomez wrote: Did some of you ever think that Tomcat could became a direct Apache subproject, like ant ? It seems Maven follow the same way. As such having Tomcat as a direct Apache projects will allow a Tomcat PMC ? Costin, Remy, other commiters, what do you think ? I'm personally -1 ( quite strongly ), but if the majority believes otherwise I can change my vote to -0. I think jakarta is a good home for tomcat, and it's getting better. Most projects that are still in jakarta are 'close' enough to tomcat - taglibs, struts, commons, slide, velocity/turbine, log4j, etc - we do have a lot of things in common and I think we would benefit far more from staying close to those projects and sharing the same community. My understanding is that Jakarta will move into this direction - to become a single community, with most committers in the jakarta PMC. It'll mean that struts or taglib committers will be able to vote or even commit code to tomcat. ( key committers from all other projects already do ). I think this is great, and I hope that one day we'll have one jakarta release with all the technology that remains part of jakarta. Beeing in the same community can only increase the quality of the code and the cross-polination. Of course - this is majority vote, and I have only one vote. Regarding PMC - there are already quite a few tomcat committers in jakarta PMC, and the intention is to get everyone who is active. Last round included release managers from all jakarta projects - but the process just started. BTW - we can leave at any time, I think it may be worth it to see how this big community works out. I agree with you jakarta community is larger and better to keep in touch with it. I wanted to get opinions since being a Top Project seems to be in 'the air du temp' (ant/maven...) Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 .cvsignore
remm2003/03/11 09:21:16 Modified:..cvsignore Log: - Add embed to the ignore list. Revision ChangesPath 1.4 +1 -0 jakarta-tomcat-5/.cvsignore Index: .cvsignore === RCS file: /home/cvs/jakarta-tomcat-5/.cvsignore,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- .cvsignore9 Oct 2002 10:06:34 - 1.3 +++ .cvsignore11 Mar 2003 17:21:15 - 1.4 @@ -1,4 +1,5 @@ build +embed dist release build.properties - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17878] - JSPC not working properly with package names
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=17878. 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=17878 JSPC not working properly with package names --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 17:36 --- Yes, the dev community wanted to have JSPC being modified that way. As for precompiling to the webapp work dir, I was explained that it wasn't supposed to work that way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/webapps/admin/valve accessLogValve.jsp remoteAddrValve.jsp remoteHostValve.jsp requestDumperValve.jsp singleSignOnValve.jsp
[EMAIL PROTECTED] wrote: amyroh 2003/03/11 06:15:45 Modified:webapps/admin banner.jsp webapps/admin/WEB-INF/classes/org/apache/webapp/admin Lists.java TomcatTreeBuilder.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector AddConnectorAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/context AddContextAction.java DeleteContextAction.java EditContextAction.java SaveContextAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/host EditHostAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/logger AddLoggerAction.java DeleteLoggerAction.java EditLoggerAction.java LoggerForm.java SaveLoggerAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm AddRealmAction.java DeleteRealmAction.java EditRealmAction.java RealmForm.java SaveJDBCRealmAction.java SaveJNDIRealmAction.java SaveMemoryRealmAction.java SaveUserDatabaseRealmAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources ListDataSourcesAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service EditServiceAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/valve AddValveAction.java DeleteValveAction.java DeleteValvesAction.java EditValveAction.java SaveAccessLogValveAction.java SaveRemoteAddrValveAction.java SaveRemoteHostValveAction.java SaveRequestDumperValveAction.java SaveSingleSignOnValveAction.java ValveForm.java ValveUtil.java webapps/admin/context context.jsp webapps/admin/logger logger.jsp webapps/admin/realm jdbcRealm.jsp jndiRealm.jsp memoryRealm.jsp userDatabaseRealm.jsp webapps/admin/valve accessLogValve.jsp remoteAddrValve.jsp remoteHostValve.jsp requestDumperValve.jsp singleSignOnValve.jsp Log: Update create/remove/edit for context, logger, realm, and valve to support the new jsr77 name for context. Need to test all the component ops more tomorrow... Amy, could you talk to someone before making that sort of changes ? The idea is that the stable branch is stable, and that big changes will bring no interesting feature except instability. Why didn't you start doing them in the 5.0 branch and then eventually port them ? OK. I can change 5 first and port them to 4 after I'm done with 5. I figured it won't make a big difference if I'm going to do both of them anyway. Do you want me to revert the changes and work on 5 fist? The changes are mostly done. Better yet, do we want to use the new name for tomcat 4 at all? Maybe I should just make the changes to 5 only? Thanks, Amy Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More Clustering Features - feedback wanted
Absolutely. I might use the admin app just for that feature (course I'm just a user not a committer). Jason -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 2:58 PM To: Tomcat Developers List Subject: More Clustering Features - feedback wanted hey yaall, so I have the basic replication implemented, I'm gonna write some test contexts and also submit a tcp loadbalancer (java) so that people can really play around with it. For the next set of features I was actually thinking of distributed deployment, currently TC5 will let you deploy a WAR through an admin app (correct?), I wanted to extend that so that you can deploy the same WAR to all the nodes in the cluster in the same way. Is this something that would be useful? Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17892] New: - contextDestroyed not given time and finalizers not called on shutdown
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=17892. 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=17892 contextDestroyed not given time and finalizers not called on shutdown Summary: contextDestroyed not given time and finalizers not called on shutdown Product: Tomcat 4 Version: 4.0 Beta 1 Platform: PC OS/Version: Windows XP Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a contextDestroyed() method in a servlet. It may take it up to a couple of seconds to do its job. Sometimes it completes, but more often the web app is destroyed before it is done. I also have a finalize method in a class for an asynchronous thread (not a servlet). The finalize never gets called. In both of the above I have System.out.println() stmts to determine the progress. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More Clustering Features - feedback wanted
Filip Hanik wrote: hey yaall, so I have the basic replication implemented, I'm gonna write some test contexts and also submit a tcp loadbalancer (java) so that people can really play around with it. Sounds good :) For the next set of features I was actually thinking of distributed deployment, currently TC5 will let you deploy a WAR through an admin app (correct?), I wanted to extend that so that you can deploy the same WAR to all the nodes in the cluster in the same way. You mean the manager webapp, right ? Is this something that would be useful? That seems useful to me. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/webapps/admin/valve accessLogValve.jspremoteAddrValve.jsp remoteHostValve.jsp requestDumperValve.jsp singleSignOnValve.jsp
Amy Roh wrote: [EMAIL PROTECTED] wrote: Amy, could you talk to someone before making that sort of changes ? The idea is that the stable branch is stable, and that big changes will bring no interesting feature except instability. Why didn't you start doing them in the 5.0 branch and then eventually port them ? OK. I can change 5 first and port them to 4 after I'm done with 5. I figured it won't make a big difference if I'm going to do both of them anyway. Do you want me to revert the changes and work on 5 fist? The changes are mostly done. Better yet, do we want to use the new name for tomcat 4 at all? Maybe I should just make the changes to 5 only? I don't see anything you get in return for changing the names. Sure, it's more consistent, but it doesn't help stability (hopefully, 4.1.x has now entered the mature phase of its lifecycle), so I don't see any incentive. The changes can be easily reverted based on the TOMCAT_4_1_22 tag. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans MBeanFactory.java ServerLifecycleListener.java
Amy Roh wrote:
[EMAIL PROTECTED] wrote:
amyroh 2003/03/10 19:25:52
Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanFactory.java ServerLifecycleListener.java
Log:
Set to use JSR77 names as default.
Please make sure tomcat 5 is also updated.
Of course I was planning to do so. ;-)
Question:
Is there a way to get the service name from jsr77 context name?
Currently, it's not included in its object name
We could expose it as an attribute if you need it ( short term ).
Don't ask me - I didn't wrote JSR77, just implemented it for tomcat :-)
The service name should just go away - we should stop using it in all names.
The DOMAIN in the JMX name should be identical with the Engine name and the
service name.
The only purpose of service name is to allow multiple tomcat instances in
the same JVM. The only sane way to support this is by using a different JMX
domain name for different instances.
In particular ( if you look at the mod_jk proxy ) it should be possible to
create proxies for remote tomcat instances - they would appear in the JMX
space as if they were engines in the same VM, so admin could work on a whole
cluster ( well, not easily - but doable ).
Having a Service name that is different from the Engine name doesn't make
sense IMO, it just creates confusion. Given that Service is not used in
Embeded, the name of the service shouldn't even matter - no code should
ever care or touch Server or Service interfaces, since the code would break
in Embeded. The only use of Service and Server should be in standalone,
when starting tomcat.
BTW, the use of the static field and ServerFactory is pretty bad IMO -
in tomcat5 at least we should just use JMX and get the server by name
( using the domain name of the current component, and the defined name
of the component ).
For now - just avoid using the Server/Service where you can, and assume a
single name will be used - and it'll match the domain name.
Costin
Thanks,
Amy
I would do it in reverse - first tc5 and then backport.
Costin
Revision ChangesPath
1.41 +11 -8
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanFactor
y.java
Index: MBeanFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/M
BeanFactory.java,v
retrieving revision 1.40 retrieving revision 1.41
diff -u -r1.40 -r1.41
--- MBeanFactory.java 19 Sep 2002 22:55:48 - 1.40
+++ MBeanFactory.java 11 Mar 2003 03:25:52 - 1.41
@@ -1227,13 +1227,16 @@
*
* @exception Exception if a component cannot be removed
*/
-public void removeContext(String name) throws Exception {
+public void removeContext(String name, String pname) throws
Exception {
// Acquire a reference to the component to be removed
ObjectName oname = new ObjectName(name);
-String serviceName = oname.getKeyProperty(service);
-String hostName = oname.getKeyProperty(host);
-String contextName =
getPathStr(oname.getKeyProperty(path));
+ObjectName poname = new ObjectName(pname);
+String serviceName = poname.getKeyProperty(service);
+String hostName = poname.getKeyProperty(host);
+String pathname = oname.getKeyProperty(name);
+String path = pathname.substring(pathname.lastIndexOf('/'));
+String contextName = getPathStr(path);
Server server = ServerFactory.getServer();
Service service = server.findService(serviceName);
Engine engine = (Engine) service.getContainer();
1.38 +5 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/ServerLifec
ycleListener.java
Index: ServerLifecycleListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/S
erverLifecycleListener.java,v
retrieving revision 1.37 retrieving revision 1.38
diff -u -r1.37 -r1.38
--- ServerLifecycleListener.java12 Feb 2003 22:11:27 -
1.37
+++ ServerLifecycleListener.java11 Mar 2003 03:25:52 -
1.38
@@ -367,6 +367,7 @@
try {
+setJsr77Names(true);
MBeanFactory factory = new MBeanFactory();
createMBeans(factory);
createMBeans(ServerFactory.getServer());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17900] New: - keys() will not return first session
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17900.
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=17900
keys() will not return first session
Summary: keys() will not return first session
Product: Tomcat 4
Version: 4.1.22
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I want to thank Glenn for implementing my patch to the keys() method. But in the
process of doing so, a minor new bug was introduced.
The patch contains a line of the form:
if (rst != null) {
which was changed to
if (rst != null rst.next()) {
When we hit the while(rst.next()) loop, the first record will be skipped.
Perhaps that should be,
if (rst != null !rst.isAfterLast()) {
instead?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/webapps/admin/valve accessLogValve.jsp remoteAddrValve.jsp remoteHostValve.jsp requestDumperValve.jsp singleSignOnValve.jsp
I don't see anything you get in return for changing the names. Sure, it's more consistent, but it doesn't help stability (hopefully, 4.1.x has now entered the mature phase of its lifecycle), so I don't see any incentive. The changes can be easily reverted based on the TOMCAT_4_1_22 tag. What's the easiest way to revert with a given tag? Amy Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More Clustering Features - feedback wanted
Filip Hanik wrote: hey yaall, so I have the basic replication implemented, I'm gonna write some test contexts and also submit a tcp loadbalancer (java) so that people can really play around with it. For the next set of features I was actually thinking of distributed deployment, currently TC5 will let you deploy a WAR through an admin app (correct?), I wanted to extend that so that you can deploy the same WAR to all the nodes in the cluster in the same way. Is this something that would be useful? That could be useful. When doing this you might want to consider that some installations might put the Host application base dir on a file server and just NFS mount that directory on all the Tomcat servers in the cluster. Its the manager application that administers contexts not the admin application. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_ajp13.c
costin 2003/03/11 16:41:32
Modified:jk/native2/common jk_worker_ajp13.c
Log:
Check for null - because in C you don't get NullPointerExceptions :-)
Revision ChangesPath
1.47 +1 -1 jakarta-tomcat-connectors/jk/native2/common/jk_worker_ajp13.c
Index: jk_worker_ajp13.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_ajp13.c,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- jk_worker_ajp13.c 4 Mar 2003 23:59:23 - 1.46
+++ jk_worker_ajp13.c 12 Mar 2003 00:41:32 - 1.47
@@ -656,7 +656,7 @@
if (err!=JK_OK)
return err;
-if (w-channel-status) {
+if ((w!=NULL) (w-channel!=NULL) (w-channel-status!=NULL)) {
err = w-channel-status(env, w, w-channel);
if (err!=JK_OK) {
jk2_worker_ajp13_done( env, w, e);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat as it's own apache subproject ?
Henri Gomez wrote: Did some of you ever think that Tomcat could became a direct Apache subproject, like ant ? It seems Maven follow the same way. As such having Tomcat as a direct Apache projects will allow a Tomcat PMC ? Costin, Remy, other commiters, what do you think ? That is a tempting idea. I thought about this some when I saw other projects getting bumped up to a top level project with their own PMC. Currently I don't see what moving Tomcat to its own top level project would gain for us, except perhaps more overhead. I have no problems at this time being under the umbrella of the Jakarta PMC. And as others have mentioned, Tomcat is the cornerstone project used for launching the Jakarta project. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java
glenn 2003/03/11 17:19:03
Modified:catalina/src/share/org/apache/catalina/session
JDBCStore.java
Log:
Fix Bug 17900, first session skipped
Revision ChangesPath
1.11 +7 -10
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/JDBCStore.java
Index: JDBCStore.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/JDBCStore.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- JDBCStore.java4 Mar 2003 04:09:17 - 1.10
+++ JDBCStore.java12 Mar 2003 01:19:03 - 1.11
@@ -461,16 +461,13 @@
preparedKeysSql.setString(1, getName());
rst = preparedKeysSql.executeQuery();
-if (rst != null rst.next()) {
-ArrayList tmpkeys = new ArrayList();
+ArrayList tmpkeys = new ArrayList();
+if (rst != null) {
while(rst.next()) {
tmpkeys.add(rst.getString(1));
}
-keys = (String[])
-tmpkeys.toArray(new String[tmpkeys.size()]);
-} else {
-keys = new String[0];
}
+keys = (String[]) tmpkeys.toArray(new String[tmpkeys.size()]);
} catch(SQLException e) {
log(sm.getString(getStoreName()+.SQLException, e));
} finally {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: More Clustering Features - feedback wanted
-Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 4:36 PM To: Tomcat Developers List Subject: Re: More Clustering Features - feedback wanted Filip Hanik wrote: hey yaall, so I have the basic replication implemented, I'm gonna write some test contexts and also submit a tcp loadbalancer (java) so that people can really play around with it. For the next set of features I was actually thinking of distributed deployment, currently TC5 will let you deploy a WAR through an admin app (correct?), I wanted to extend that so that you can deploy the same WAR to all the nodes in the cluster in the same way. Is this something that would be useful? That could be useful. When doing this you might want to consider that some installations might put the Host application base dir on a file server and just NFS mount that directory on all the Tomcat servers in the cluster. yeah, but that would be a single point of failure. I'm sure I can make this configurable, if they want to read the data from a single disk, then I can have them do that, otherwise the cluster can stream over the bytes. of course doing that I'm only going to support packaged .war files in the first release :) Its the manager application that administers contexts not the admin application. got it! thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session JDBCStore.java
glenn 2003/03/11 17:21:58
Modified:catalina/src/share/org/apache/catalina/session
JDBCStore.java
Log:
Fix Bug 17900, first session skipped
Revision ChangesPath
1.5 +7 -10
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/JDBCStore.java
Index: JDBCStore.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/JDBCStore.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JDBCStore.java4 Mar 2003 04:31:47 - 1.4
+++ JDBCStore.java12 Mar 2003 01:21:58 - 1.5
@@ -461,16 +461,13 @@
preparedKeysSql.setString(1, getName());
rst = preparedKeysSql.executeQuery();
-if (rst != null rst.next()) {
-ArrayList tmpkeys = new ArrayList();
+ArrayList tmpkeys = new ArrayList();
+if (rst != null) {
while(rst.next()) {
tmpkeys.add(rst.getString(1));
}
-keys = (String[])
-tmpkeys.toArray(new String[tmpkeys.size()]);
-} else {
-keys = new String[0];
}
+keys = (String[]) tmpkeys.toArray(new String[tmpkeys.size()]);
} catch(SQLException e) {
log(sm.getString(getStoreName()+.SQLException, e));
} finally {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
glenn 2003/03/11 17:23:35 Modified:.RELEASE-NOTES-4.1.txt Log: Update release notes Revision ChangesPath 1.63 +5 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt Index: RELEASE-NOTES-4.1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.62 retrieving revision 1.63 diff -u -r1.62 -r1.63 --- RELEASE-NOTES-4.1.txt 8 Mar 2003 14:20:44 - 1.62 +++ RELEASE-NOTES-4.1.txt 12 Mar 2003 01:23:35 - 1.63 @@ -719,6 +719,10 @@ Grant web applications a FilePermission to read the web application context directory in addition to its contents. +[4.1.23] #17900 + JDBCStore + Fix bug where first session in result set was skipped. + Coyote Bug Fixes: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17900] - keys() will not return first session
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17900. 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=17900 keys() will not return first session [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 01:27 --- Argh! Thanks for reporting this. A bug fix patch has been committed. Will be available in Tomcat 4.1.23 release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JAAS Auth
Hi, I'm close to get JAAS realm and the memory LoginModule working - if I remember correctly we agreed to make JAAS the default for 5.0 ( I don't remember any objections ). I never tried it in 4.x - but from the code and code I strongly doubt it works. There is one change I would like to make. As you know, JAAS login modules return a Subject and a set of Principals. There is no clear way to decide which Principals are Roles - so we currently require the user to configure the realm with the list of classes that are role principals. In addition to that, I would like to support a different pattern - used in JBoss - which seems much cleaner and logical. If a Principal of type java.security.acl.Group is found - named Roles - we'll treat all the Principlas in that Group as roles. ( the old mechanism should still be supported, of course ) The other problem: I think we should move the catalina-indepedent JAAS code in a separate module, for example j-t-c/jaas. That would include SimplePrincipal, MemoryLoginModule - and eventually JNDI/JDBC/etc LoginModules if anyone has the time to make the conversion. It's not a big priority, but it'll clean up the code deps and maybe the code could be reused. Opinions ? Votes ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JAAS Auth
Just an FYI: In JBoss JAAS doesn't really work as expected, if you log in under a context say mywar | -protected -unprotected then getPrincipal() returns null for the unprotected subcontext(directory), but returns the principal under the secured subcontext. we don't want that to happen to us, do we :)) Filip -Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 5:31 PM To: [EMAIL PROTECTED] Subject: JAAS Auth Hi, I'm close to get JAAS realm and the memory LoginModule working - if I remember correctly we agreed to make JAAS the default for 5.0 ( I don't remember any objections ). I never tried it in 4.x - but from the code and code I strongly doubt it works. There is one change I would like to make. As you know, JAAS login modules return a Subject and a set of Principals. There is no clear way to decide which Principals are Roles - so we currently require the user to configure the realm with the list of classes that are role principals. In addition to that, I would like to support a different pattern - used in JBoss - which seems much cleaner and logical. If a Principal of type java.security.acl.Group is found - named Roles - we'll treat all the Principlas in that Group as roles. ( the old mechanism should still be supported, of course ) The other problem: I think we should move the catalina-indepedent JAAS code in a separate module, for example j-t-c/jaas. That would include SimplePrincipal, MemoryLoginModule - and eventually JNDI/JDBC/etc LoginModules if anyone has the time to make the conversion. It's not a big priority, but it'll clean up the code deps and maybe the code could be reused. Opinions ? Votes ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAAS Auth
Costin, Sorry to mail you directly, but this doesn't seem like a major group discussion kind of thing. At work I'm doing a project that has an interesting set of criteria for user authentication that I haven't really seen a way to do with JAAS readily. Basically it boils down to this, a user has a userid, a password, and a potential 'secondary' password. What I haven't been able to figure out is if there would be a way through realms to implement this type of authentication scheme. This is really just a wonder how it could be done question and if you have no time to possibly give me some thoughts no big deal. Thanks for any ideas on how this /might/ be done if you get some time. --Dave - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 20:31 Subject: JAAS Auth Hi, I'm close to get JAAS realm and the memory LoginModule working - if I remember correctly we agreed to make JAAS the default for 5.0 ( I don't remember any objections ). I never tried it in 4.x - but from the code and code I strongly doubt it works. There is one change I would like to make. As you know, JAAS login modules return a Subject and a set of Principals. There is no clear way to decide which Principals are Roles - so we currently require the user to configure the realm with the list of classes that are role principals. In addition to that, I would like to support a different pattern - used in JBoss - which seems much cleaner and logical. If a Principal of type java.security.acl.Group is found - named Roles - we'll treat all the Principlas in that Group as roles. ( the old mechanism should still be supported, of course ) The other problem: I think we should move the catalina-indepedent JAAS code in a separate module, for example j-t-c/jaas. That would include SimplePrincipal, MemoryLoginModule - and eventually JNDI/JDBC/etc LoginModules if anyone has the time to make the conversion. It's not a big priority, but it'll clean up the code deps and maybe the code could be reused. Opinions ? Votes ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14616] - Redirects should be issued prior to authentication challenges
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=14616.
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=14616
Redirects should be issued prior to authentication challenges
--- Additional Comments From [EMAIL PROTECTED] 2003-03-12 02:39 ---
Proposed patch (against TOMCAT_4_1_18):
Index:
catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
===
RCS file: /home/cvs/jakarta-tomcat-
4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,
v
retrieving revision 1.35
diff -u -r1.35 AuthenticatorBase.java
--- catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
16 Nov 2002 04:49:22 - 1.35
+++ catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
12 Mar 2003 02:34:45 -
@@ -443,6 +443,17 @@
}
HttpRequest hrequest = (HttpRequest) request;
HttpResponse hresponse = (HttpResponse) response;
+
+// Do not authenticate prior to redirects for trailing slashes,
+// at least for the root of the context
+String requestURI = hrequest.getDecodedRequestURI();
+String contextPath = this.context.getPath();
+if (requestURI.charAt(requestURI.length() - 1) != '/'
+requestURI.equals(contextPath)) {
+context.invokeNext(request, response);
+return;
+}
+
if (debug = 1)
log(Security checking request +
((HttpServletRequest) request.getRequest()).getMethod() + +
@@ -473,8 +484,6 @@
// Special handling for form-based logins to deal with the case
// where the login form (and therefore the j_security_check URI
// to which it submits) might be outside the secured area
-String contextPath = this.context.getPath();
-String requestURI = hrequest.getDecodedRequestURI();
if (requestURI.startsWith(contextPath)
requestURI.endsWith(Constants.FORM_ACTION)) {
if (!authenticate(hrequest, hresponse, config)) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
4.1 authentication bug / bug 14616
Greetings, I brought this up in November. Remy and I have a disagreement on how important fixing this bug is. I want to see if there is a quorum of other committers who understand the problem and think it should be fixed prior to the next stable build release of 4.1. The immediate problem is that current Tomcat behavior causes browsers to submit auth credentials to webapps other than the webapp who originally sent the 401 challenge. Most web servers, like Apache, are careful to redirect for trailing slashes before challenging for authentication. Tomcat does this backward. The result is the client will usually cache the need for auth for the entire domain and not just a single webapp. Here is a repeat of the scenario I mentioned in November http://marc.theaimsgroup.com/?l=tomcat-devm=103673355109222w=2 Context path=/foo docBase=foo / Context path=/bar docBase=bar / foo and bar web.xml protected with security-constraint web-resource-collection web-resource-namename /web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint /security-constraint Current behavior: Request Response GET /foo401 (at this point browsers will send credentials to any url in this domain) GET /foo with auth 301 redirect to /foo/ GET /foo/ 200 GET /bar with auth ^ Correct behavior: GET /foo301 redirect to /foo/ GET /foo/ 401 GET /foo/ with auth 200 GET /bar without auth My proposed patch is attached to bug 14616 http://issues.apache.org/bugzilla/show_bug.cgi?id=14616 While this does not cover the case of subdirectories within a context, it does fix the most egregious case for context roots. Please comment if you are not comfortable with credentials being inadvertently shared between all webapps on a given domain. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JAAS Auth
Filip Hanik wrote: Just an FYI: In JBoss JAAS doesn't really work as expected, if you log in under a context say mywar | -protected -unprotected then getPrincipal() returns null for the unprotected subcontext(directory), but returns the principal under the secured subcontext. we don't want that to happen to us, do we :)) I don't think we'll be affected :-), but it may fix the jboss bug ( if they switch to using the built-in tomcat JAAS realm ) Costin Filip -Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 5:31 PM To: [EMAIL PROTECTED] Subject: JAAS Auth Hi, I'm close to get JAAS realm and the memory LoginModule working - if I remember correctly we agreed to make JAAS the default for 5.0 ( I don't remember any objections ). I never tried it in 4.x - but from the code and code I strongly doubt it works. There is one change I would like to make. As you know, JAAS login modules return a Subject and a set of Principals. There is no clear way to decide which Principals are Roles - so we currently require the user to configure the realm with the list of classes that are role principals. In addition to that, I would like to support a different pattern - used in JBoss - which seems much cleaner and logical. If a Principal of type java.security.acl.Group is found - named Roles - we'll treat all the Principlas in that Group as roles. ( the old mechanism should still be supported, of course ) The other problem: I think we should move the catalina-indepedent JAAS code in a separate module, for example j-t-c/jaas. That would include SimplePrincipal, MemoryLoginModule - and eventually JNDI/JDBC/etc LoginModules if anyone has the time to make the conversion. It's not a big priority, but it'll clean up the code deps and maybe the code could be reused. Opinions ? Votes ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session StandardSession.java
jfarcand2003/03/11 19:53:15
Modified:catalina/src/share/org/apache/catalina/session
StandardSession.java
Log:
Forgot to commit this one. Add a doPrivileged block.
Revision ChangesPath
1.14 +18 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java
Index: StandardSession.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- StandardSession.java 19 Feb 2003 00:33:27 - 1.13
+++ StandardSession.java 12 Mar 2003 03:53:15 - 1.14
@@ -73,7 +73,9 @@
import java.io.ObjectOutputStream;
import java.io.Serializable;
import java.lang.reflect.Method;
+import java.security.AccessController;
import java.security.Principal;
+import java.security.PrivilegedAction;
import java.util.ArrayList;
import java.util.Enumeration;
import java.util.HashMap;
@@ -551,8 +553,18 @@
*/
public HttpSession getSession() {
-if (facade == null)
-facade = new StandardSessionFacade(this);
+if (facade == null){
+if (System.getSecurityManager() != null){
+final StandardSession fsession = this;
+facade = (StandardSessionFacade)AccessController.doPrivileged(new
PrivilegedAction(){
+public Object run(){
+return new StandardSessionFacade(fsession);
+}
+});
+} else {
+facade = new StandardSessionFacade(this);
+}
+}
return (facade);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBCRealm getPassword() unimplemented in Tomcat 4.1.18 (returns null)
Hi,
Does JDBCRealm realm work for DIGEST authentication scheme(I have
passwords stored in cleartext form. JDBCRealm works with BASIC
authenctication scheme though)? I find the corresponding coding partially
implemented. IF it works for for someone, could you please guide me on how
you made it possible.
Thanks,
Uddhav
- Original Message -
From: Uddhav Shirname [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 7:53 PM
Subject: Re: JDBCRealm getPassword() unimplemented in Tomcat 4.1.18 (returns
null)
Hi,
I have implemeted the methods getPassword() and getPrincipal() in
JDBCRealm. Digest authentication works for me with these changes. One
thing
that still doest work is if I have stored the password in encrypted form
in
the database. I have doubts if this will always work in the scenario where
the password has been persisted using say SHA and the web authentication
utilises MD5. Will the responseDigest send by client and the one generated
at the server match?
Following are the chages I have made. I am new to this forum, can somebody
guide me on how these changes can be committed if approved. Thanks.
/**
* Return the password associated with the given principal's user
name.
*/
protected String getPassword(String username) {
Connection dbConnection = null;
String dbCredentials = null;
try {
// Ensure that we have an open database connection
dbConnection = open();
// Look up the user's credentials
PreparedStatement stmt = credentials(dbConnection, username);
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
dbCredentials = rs.getString(1).trim();
}
rs.close();
if (dbCredentials == null) {
return (null);
}
// Release the database connection we just used
release(dbConnection);
} catch (SQLException e) {
e.printStackTrace();
// Log the problem for posterity
log(sm.getString(jdbcRealm.exception), e);
// Close the connection so that it gets reopened next time
if (dbConnection != null)
close(dbConnection);
}
return (dbCredentials);
// return (null); // earlier code
}
/**
* Return the Principal associated with the given user name.
*/
protected Principal getPrincipal(String username) {
Connection dbConnection = null;
GenericPrincipal principal = null;
try {
String credentials = getPassword(username);
// Ensure that we have an open database connection
dbConnection = open();
// Accumulate the user's roles
ArrayList list = new ArrayList();
PreparedStatement stmt = roles(dbConnection, username);
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
list.add(rs.getString(1).trim());
}
rs.close();
dbConnection.commit();
// Create and return a suitable Principal for this user
principal = (new GenericPrincipal(this, username, credentials,
list));
// Release the database connection we just used
release(dbConnection);
} catch (SQLException e) {
e.printStackTrace();
// Log the problem for posterity
log(sm.getString(jdbcRealm.exception), e);
// Close the connection so that it gets reopened next time
if (dbConnection != null)
close(dbConnection);
}
return (principal);
// return (null); // earlier code
}
- Original Message -
From: Uddhav Shirname [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 7:07 PM
Subject: JDBCRealm getPassword() unimplemented in Tomcat 4.1.18 (returns
null)
Hi,
I am unable to authenticate using digest authentication. I browsed
through the code and found that getPassword() method in JDBCRealm
returns
null (harcoded). I am using the following configuration. Am I missing
something somewhere?
server.xml:
--
Realm
className=org.apache.catalina.realm.JDBCRealm
debug=99
digest=MD5
driverName=oracle.jdbc.driver.OracleDriver
connectionURL=jdbc:oracle:thin:@lohgad:1521:dsoft
connectionName=uddhav
connectionPassword=uddhav
userTable=tab_users
userNameCol=user_name
userCredCol=user_pass
userRoleTable=tab_user_roles
roleNameCol=role_name /
web.xml:
-
login-config
auth-methodDIGEST/auth-method
realm-nameOnJava Application/realm-name
/login-config
Re: 4.1 authentication bug / bug 14616
I think it is reasonable to fix it. This can be serious - if someone relies on application isolation ( like a hosting environment ), the consequences can be really bad, with one webapp guessing the credentials of another one. The fix seems reasonably simple and clean. Costin Keith Wannamaker wrote: Greetings, I brought this up in November. Remy and I have a disagreement on how important fixing this bug is. I want to see if there is a quorum of other committers who understand the problem and think it should be fixed prior to the next stable build release of 4.1. The immediate problem is that current Tomcat behavior causes browsers to submit auth credentials to webapps other than the webapp who originally sent the 401 challenge. Most web servers, like Apache, are careful to redirect for trailing slashes before challenging for authentication. Tomcat does this backward. The result is the client will usually cache the need for auth for the entire domain and not just a single webapp. Here is a repeat of the scenario I mentioned in November http://marc.theaimsgroup.com/?l=tomcat-devm=103673355109222w=2 Context path=/foo docBase=foo / Context path=/bar docBase=bar / foo and bar web.xml protected with security-constraint web-resource-collection web-resource-namename /web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint /security-constraint Current behavior: Request Response GET /foo401 (at this point browsers will send credentials to any url in this domain) GET /foo with auth 301 redirect to /foo/ GET /foo/ 200 GET /bar with auth ^ Correct behavior: GET /foo301 redirect to /foo/ GET /foo/ 401 GET /foo/ with auth 200 GET /bar without auth My proposed patch is attached to bug 14616 http://issues.apache.org/bugzilla/show_bug.cgi?id=14616 While this does not cover the case of subdirectories within a context, it does fix the most egregious case for context roots. Please comment if you are not comfortable with credentials being inadvertently shared between all webapps on a given domain. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ContainerBase.java
costin 2003/03/11 22:04:31
Modified:catalina/src/share/org/apache/catalina/core
ContainerBase.java
Log:
Forgive duplicated start() calls. Nobody is hurt
Revision ChangesPath
1.8 +25 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java
Index: ContainerBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ContainerBase.java16 Feb 2003 19:44:47 - 1.7
+++ ContainerBase.java12 Mar 2003 06:04:31 - 1.8
@@ -93,8 +93,10 @@
import org.apache.catalina.Request;
import org.apache.catalina.Response;
import org.apache.catalina.Valve;
+import org.apache.catalina.valves.ValveBase;
import org.apache.catalina.util.LifecycleSupport;
import org.apache.catalina.util.StringManager;
+import org.apache.commons.modeler.Registry;
/**
@@ -1189,9 +1191,10 @@
public synchronized void start() throws LifecycleException {
// Validate and update our current component state
-if (started)
-throw new LifecycleException
-(sm.getString(containerBase.alreadyStarted, logName()));
+if (started) {
+log.info(sm.getString(containerBase.alreadyStarted, logName()));
+return;
+}
// Notify our interested LifecycleListeners
lifecycle.fireLifecycleEvent(BEFORE_START_EVENT, null);
@@ -1330,11 +1333,19 @@
public synchronized void addValve(Valve valve) {
pipeline.addValve(valve);
+// If we are registered and the valve is not - create a default name
+//if( domain != null valve instanceof ValveBase
+//((ValveBase)valve).getObjectName()==null ) {
+//try {
+//ObjectName oname=((ValveBase)valve).createObjectName(domain,
this.getObjectName());
+//Registry.getRegistry().registerComponent(valve, oname,
valve.getClass().getName());
+//} catch( Throwable t ) {
+//log.info( Can't register valve + valve , t );
+//}
+//}
fireContainerEvent(ADD_VALVE_EVENT, valve);
-
}
-
/**
* pReturn the Valve instance that has been distinguished as the basic
* Valve for this Pipeline (if any).
@@ -1367,6 +1378,14 @@
public synchronized void removeValve(Valve valve) {
pipeline.removeValve(valve);
+//if( domain != null valve instanceof ValveBase ) {
+//try {
+//ObjectName oname=((ValveBase)valve).getObjectName();
+//Registry.getRegistry().getMBeanServer().unregisterMBean(oname);
+//} catch( Throwable t ) {
+//log.info( Can't unregister valve + valve , t );
+//}
+//}
fireContainerEvent(REMOVE_VALVE_EVENT, valve);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 4.1 authentication bug / bug 14616
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 8:52 PM Subject: Re: 4.1 authentication bug / bug 14616 I think it is reasonable to fix it. This can be serious - if someone relies on application isolation ( like a hosting environment ), the consequences can be really bad, with one webapp guessing the credentials of another one. The fix seems reasonably simple and clean. Except that it isn't really a fix. Like Remy, I'd like to see a more general fix (e.g. using the new 5.0 Mapper). However, I won't -1 if Keith wants to commit his patch. It does fix the worst-case condition. Costin Keith Wannamaker wrote: Greetings, I brought this up in November. Remy and I have a disagreement on how important fixing this bug is. I want to see if there is a quorum of other committers who understand the problem and think it should be fixed prior to the next stable build release of 4.1. The immediate problem is that current Tomcat behavior causes browsers to submit auth credentials to webapps other than the webapp who originally sent the 401 challenge. Most web servers, like Apache, are careful to redirect for trailing slashes before challenging for authentication. Tomcat does this backward. The result is the client will usually cache the need for auth for the entire domain and not just a single webapp. Here is a repeat of the scenario I mentioned in November http://marc.theaimsgroup.com/?l=tomcat-devm=103673355109222w=2 Context path=/foo docBase=foo / Context path=/bar docBase=bar / foo and bar web.xml protected with security-constraint web-resource-collection web-resource-namename /web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint /security-constraint Current behavior: Request Response GET /foo401 (at this point browsers will send credentials to any url in this domain) GET /foo with auth 301 redirect to /foo/ GET /foo/ 200 GET /bar with auth ^ Correct behavior: GET /foo301 redirect to /foo/ GET /foo/ 401 GET /foo/ with auth 200 GET /bar without auth My proposed patch is attached to bug 14616 http://issues.apache.org/bugzilla/show_bug.cgi?id=14616 While this does not cover the case of subdirectories within a context, it does fix the most egregious case for context roots. Please comment if you are not comfortable with credentials being inadvertently shared between all webapps on a given domain. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java
costin 2003/03/11 22:24:15
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
- forgive duplicated start()
- remove unused imports ( thanks Idea )
- Add support for a defaultWebXml configuration option. It adds a bit
more flexibility ( you could configure different defaults for different sets of
webapps )
and reduces the dependency on catalina.base env.
- stop using catalina.base if engine.baseDir is set - we should do a grep and
make sure catalina.base system property is never used ( otherwise it's almost
impossible to support the original goal of multiple engines in a vm )
- few fixes in jmx registration. Create a host automatically if none set
( using the hostname from the jsr77 name of the context )
- implement destroy for jmx deregistration
- moved methods from mbeans - so all the JMX model is in StandardContext, we
can remove the extra wrapper
Revision ChangesPath
1.25 +89 -36
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- StandardContext.java 11 Mar 2003 19:39:06 - 1.24
+++ StandardContext.java 12 Mar 2003 06:24:15 - 1.25
@@ -1,7 +1,4 @@
/*
- * $Header$
- * $Revision$
- * $Date$
*
*
*
@@ -92,23 +89,7 @@
import org.apache.naming.resources.ProxyDirContext;
import org.apache.naming.resources.WARDirContext;
import org.apache.naming.resources.DirContextURLStreamHandler;
-import org.apache.catalina.Container;
-import org.apache.catalina.ContainerListener;
-import org.apache.catalina.Context;
-import org.apache.catalina.Host;
-import org.apache.catalina.Globals;
-import org.apache.catalina.InstanceListener;
-import org.apache.catalina.Lifecycle;
-import org.apache.catalina.LifecycleEvent;
-import org.apache.catalina.LifecycleException;
-import org.apache.catalina.LifecycleListener;
-import org.apache.catalina.Loader;
-import org.apache.catalina.Mapper;
-import org.apache.catalina.Pipeline;
-import org.apache.catalina.Request;
-import org.apache.catalina.Response;
-import org.apache.catalina.Valve;
-import org.apache.catalina.Wrapper;
+import org.apache.catalina.*;
import org.apache.catalina.startup.ContextConfig;
import org.apache.catalina.startup.TldConfig;
import org.apache.catalina.mbeans.MBeanUtils;
@@ -263,6 +244,10 @@
*/
private String displayName = null;
+/** Override the default web xml location. ContextConfig is not configurable
+ * so the setter is not used.
+ */
+private String defaultWebXml;
/**
* The distributable flag for this web application.
@@ -765,6 +750,22 @@
}
+public String getDefaultWebXml() {
+return defaultWebXml;
+}
+
+/** Set the location of the default web xml that will be used.
+ * If not absolute, it'll be made relative to the engine's base dir
+ * ( which defaults to catalina.base system property ).
+ *
+ * XXX If a file is not found - we can attempt a getResource()
+ *
+ * @param defaultWebXml
+ */
+public void setDefaultWebXml(String defaultWebXml) {
+this.defaultWebXml = defaultWebXml;
+}
+
public long getStartupTime() {
return startupTime;
}
@@ -3726,9 +3727,10 @@
*/
public synchronized void start() throws LifecycleException {
-if (started)
-throw new LifecycleException
-(sm.getString(containerBase.alreadyStarted, logName()));
+if (started) {
+log.info(sm.getString(containerBase.alreadyStarted, logName()));
+return;
+}
String logName=tomcat. + getParent().getName() + . +
(.equals(getName()) ? ROOT : getName()) + .Context;
@@ -4156,9 +4158,12 @@
* entire servlet container (i.e. the Engine container if present).
*/
protected File engineBase() {
-
-return (new File(System.getProperty(catalina.base)));
-
+String base=System.getProperty(catalina.base);
+if( base == null ) {
+StandardEngine eng=(StandardEngine)this.getParent().getParent();
+base=eng.getBaseDir();
+}
+return (new File(base));
}
@@ -4373,7 +4378,7 @@
// Create this directory if necessary
File dir = new File(workDir);
if (!dir.isAbsolute()) {
-File catalinaHome =
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardHost.java
costin 2003/03/11 22:28:55
Modified:catalina/src/share/org/apache/catalina/core
StandardHost.java
Log:
- remove unused imports
- switch to commons-logging
- lazy creation of the deployer. I did it because of some class loader problems ( but
the problem was elsewere ) - however it is good because we may use a different
mechanism.
The deployment should be done using JMX - registering / unregistering mbeans
with JSR77 names should be enough.
- moved the extra JMX getters from the wrapper in mbeans/
- when the host mbean is created directly by JMX, register with the engine
Revision ChangesPath
1.4 +80 -35
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHost.java
Index: StandardHost.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHost.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- StandardHost.java 15 Jan 2003 03:40:42 - 1.3
+++ StandardHost.java 12 Mar 2003 06:28:55 - 1.4
@@ -1,8 +1,4 @@
/*
- * $Header$
- * $Revision$
- * $Date$
- *
*
*
* The Apache Software License, Version 1.1
@@ -66,26 +62,18 @@
import java.io.IOException;
-import java.net.JarURLConnection;
import java.net.URL;
-import javax.servlet.ServletContext;
-import javax.servlet.ServletException;
-import javax.servlet.http.HttpServletRequest;
-import javax.servlet.http.HttpServletResponse;
+import javax.management.ObjectName;
+import javax.management.MBeanServer;
import org.apache.catalina.Container;
import org.apache.catalina.Context;
import org.apache.catalina.DefaultContext;
import org.apache.catalina.Deployer;
-import org.apache.catalina.Globals;
-import org.apache.catalina.HttpRequest;
import org.apache.catalina.Host;
-import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleException;
-import org.apache.catalina.LifecycleListener;
-import org.apache.catalina.Request;
-import org.apache.catalina.Response;
import org.apache.catalina.Valve;
import org.apache.catalina.valves.ErrorDispatcherValve;
+import org.apache.catalina.valves.ValveBase;
/**
@@ -160,7 +148,7 @@
* The codeDeployer/code to whom we delegate application
* deployment requests.
*/
-private Deployer deployer = new StandardHostDeployer(this);
+private Deployer deployer = null;
/**
@@ -176,7 +164,6 @@
private String errorReportValveClass =
org.apache.catalina.valves.ErrorReportValve;
-
/**
* The descriptive information string for this implementation.
*/
@@ -336,7 +323,6 @@
return (this.defaultContext);
}
-
/**
* Return the Java class name of the Context implementation class
* for new web applications.
@@ -665,14 +651,14 @@
*/
public Context map(String uri) {
-if (debug 0)
-log(Mapping request URI ' + uri + ');
+if (log.isDebugEnabled())
+log.debug(Mapping request URI ' + uri + ');
if (uri == null)
return (null);
// Match on the longest possible context path prefix
-if (debug 1)
-log( Trying the longest context path prefix);
+if (log.isTraceEnabled())
+log.trace( Trying the longest context path prefix);
Context context = null;
String mapuri = uri;
while (true) {
@@ -687,8 +673,8 @@
// If no Context matches, select the default Context
if (context == null) {
-if (debug 1)
-log( Trying the default context);
+if (log.isTraceEnabled())
+log.trace( Trying the default context);
context = (Context) findChild();
}
@@ -699,8 +685,8 @@
}
// Return the mapped Context (if any)
-if (debug 0)
-log( Mapped to context ' + context.getPath() + ');
+if (log.isDebugEnabled())
+log.debug( Mapped to context ' + context.getPath() + ');
return (context);
}
@@ -822,7 +808,7 @@
*/
public void install(String contextPath, URL war) throws IOException {
-deployer.install(contextPath, war);
+getDelegateDeployer().install(contextPath, war);
}
@@ -853,7 +839,7 @@
*/
public synchronized void install(URL config, URL war) throws IOException {
-deployer.install(config, war);
+getDelegateDeployer().install(config, war);
}
@@ -867,7 +853,7 @@
*/
public Context
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappLoader.java
costin 2003/03/11 22:33:37
Modified:catalina/src/share/org/apache/catalina/loader
WebappLoader.java
Log:
Few getters ( Remy: don't panic, I'm not changing the loader ! ).
The array will collect the loaders that are set into the class loader
and allow JMX to view the actual classpath ( if the loader is registered ).
I also added a bit more info in case something is missing.
Knowing the exact classpath of a webapp can be extremely usefull when debugging
strange bugs...
Revision ChangesPath
1.9 +48 -10
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java
Index: WebappLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- WebappLoader.java 8 Mar 2003 17:01:20 - 1.8
+++ WebappLoader.java 12 Mar 2003 06:33:37 - 1.9
@@ -1,7 +1,4 @@
/*
- * $Header$
- * $Revision$
- * $Date$
*
*
*
@@ -82,6 +79,7 @@
import java.net.URLStreamHandlerFactory;
import java.security.Permission;
import java.util.jar.JarFile;
+import java.util.ArrayList;
import javax.servlet.ServletContext;
import javax.naming.NamingException;
import javax.naming.Binding;
@@ -103,6 +101,8 @@
import org.apache.catalina.Logger;
import org.apache.catalina.util.LifecycleSupport;
import org.apache.catalina.util.StringManager;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
/**
@@ -126,7 +126,6 @@
public class WebappLoader
implements Lifecycle, Loader, PropertyChangeListener, Runnable {
-
// --- Constructors
@@ -271,6 +270,11 @@
private String threadName = WebappLoader;
+// Classpath set in the loader
+private String classpath=null;
+
+// repositories that are set in the loader, for jmx
+private ArrayList loaderRepositories;
// - Properties
@@ -347,6 +351,7 @@
/**
* Return the DefaultContext with which this Loader is associated.
+ * XXX What is that ???
*/
public DefaultContext getDefaultContext() {
@@ -527,6 +532,7 @@
if (started (classLoader != null)) {
classLoader.addRepository(repository);
+if( loaderRepositories != null ) loaderRepositories.add(repository);
setClassPath();
}
@@ -549,6 +555,8 @@
return ((String[])repositories.clone());
}
+/** Extra repositories for this loader
+ */
public String getRepositoriesString() {
StringBuffer sb=new StringBuffer();
for( int i=0; irepositories.length ; i++ ) {
@@ -557,6 +565,30 @@
return sb.toString();
}
+public String[] getLoaderRepositories() {
+if( loaderRepositories==null ) return null;
+String res[]=new String[ loaderRepositories.size()];
+loaderRepositories.toArray(res);
+return res;
+}
+
+public String getLoaderRepositoriesString() {
+String repositories[]=getLoaderRepositories();
+StringBuffer sb=new StringBuffer();
+for( int i=0; irepositories.length ; i++ ) {
+sb.append( repositories[i]).append(:);
+}
+return sb.toString();
+}
+
+/** Classpath, as set in org.apache.catalina.jsp_classpath context
+ * property
+ *
+ * @return
+ */
+public String getClasspath() {
+return classpath;
+}
/**
* Has the internal repository associated with this Loader been modified,
@@ -639,7 +671,6 @@
* @exception LifecycleException if a lifecycle error occurs
*/
public void start() throws LifecycleException {
-
// Validate and update our current component state
if (started)
throw new LifecycleException
@@ -649,9 +680,10 @@
lifecycle.fireLifecycleEvent(START_EVENT, null);
started = true;
-if (container.getResources() == null)
+if (container.getResources() == null) {
+log.info(No resources for + container);
return;
-
+}
// Register a stream handler factory for the JNDI protocol
URLStreamHandlerFactory streamHandlerFactory =
new DirContextURLStreamHandlerFactory();
@@ -964,11 +996,13 @@
if (servletContext == null)
return;
+loaderRepositories=new ArrayList();
Problems in installing DBPrism on Tomcat
I am trying to intall DBPrism for Tomcat.
The installation instruction says
build dpls.ear, executing $PRISM_HOME/applications/build_dpls.sh (or .bat on
windows)
extract dpls.war, unziping dpls.ear file generated into $PRISM_HOME/bin.
Move to the directory $TOMCAT_HOME/webapps and execute jar xvf
$PRISM_HOME/bin/dpls.ear dpls.war
Copy classes12.jar, from $ORACLE_HOME/jdbc/lib to $TOMCAT_HOME/common/lib
start Tomcat, excecuting bin/catalina.sh run
enjoy DBPrism, loading the demo page at
http://localhost:8080/dpls/sample/demo.startup
I have an ORANT installation but I cannot locate classes12.jar, from
$ORACLE_HOME/jdbc/lib instead I find
classes102.zip and classes111.zip
Can somebody tell me where to locate classes12.jar.
Thanks are regards.
Riyaz
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2003 10:29 AM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core
StandardHost.java
costin 2003/03/11 22:28:55
Modified:catalina/src/share/org/apache/catalina/core
StandardHost.java
Log:
- remove unused imports
- switch to commons-logging
- lazy creation of the deployer. I did it because of some class loader
problems ( but
the problem was elsewere ) - however it is good because we may use a
different mechanism.
The deployment should be done using JMX - registering / unregistering
mbeans
with JSR77 names should be enough.
- moved the extra JMX getters from the wrapper in mbeans/
- when the host mbean is created directly by JMX, register with the engine
Revision ChangesPath
1.4 +80 -35
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Standard
Host.java
Index: StandardHost.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cor
e/StandardHost.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- StandardHost.java 15 Jan 2003 03:40:42 - 1.3
+++ StandardHost.java 12 Mar 2003 06:28:55 - 1.4
@@ -1,8 +1,4 @@
/*
- * $Header$
- * $Revision$
- * $Date$
- *
*
*
* The Apache Software License, Version 1.1
@@ -66,26 +62,18 @@
import java.io.IOException;
-import java.net.JarURLConnection;
import java.net.URL;
-import javax.servlet.ServletContext;
-import javax.servlet.ServletException;
-import javax.servlet.http.HttpServletRequest;
-import javax.servlet.http.HttpServletResponse;
+import javax.management.ObjectName;
+import javax.management.MBeanServer;
import org.apache.catalina.Container;
import org.apache.catalina.Context;
import org.apache.catalina.DefaultContext;
import org.apache.catalina.Deployer;
-import org.apache.catalina.Globals;
-import org.apache.catalina.HttpRequest;
import org.apache.catalina.Host;
-import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleException;
-import org.apache.catalina.LifecycleListener;
-import org.apache.catalina.Request;
-import org.apache.catalina.Response;
import org.apache.catalina.Valve;
import org.apache.catalina.valves.ErrorDispatcherValve;
+import org.apache.catalina.valves.ValveBase;
/**
@@ -160,7 +148,7 @@
* The codeDeployer/code to whom we delegate application
* deployment requests.
*/
-private Deployer deployer = new StandardHostDeployer(this);
+private Deployer deployer = null;
/**
@@ -176,7 +164,6 @@
private String errorReportValveClass =
org.apache.catalina.valves.ErrorReportValve;
-
/**
* The descriptive information string for this implementation.
*/
@@ -336,7 +323,6 @@
return (this.defaultContext);
}
-
/**
* Return the Java class name of the Context implementation class
* for new web applications.
@@ -665,14 +651,14 @@
*/
public Context map(String uri) {
-if (debug 0)
-log(Mapping request URI ' + uri + ');
+if (log.isDebugEnabled())
+log.debug(Mapping request URI ' + uri + ');
if (uri == null)
return (null);
// Match on the longest possible context path prefix
-if (debug 1)
-log( Trying the longest context path prefix);
+if (log.isTraceEnabled())
+log.trace( Trying the longest context path prefix);
Context context = null;
String mapuri = uri;
while (true) {
@@ -687,8 +673,8 @@
// If no Context matches, select the default Context
if (context == null) {
-if (debug 1)
-log( Trying the default context);
+
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java
costin 2003/03/11 23:12:28
Modified:catalina/src/share/org/apache/catalina/startup
ContextConfig.java
Log:
- cleanup imports
- use a normal properties for authenticators - what's with the resource bundle ???
- use the cleaner API in digester to use the thread CL
- remove the debug message for timing - the info will be visible in JMX
- use getBaseDir and check the engine - instead of system property ( that's the
fallback)
- use the container class loader when loading the default web.xml
Revision ChangesPath
1.20 +59 -48
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
Index: ContextConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- ContextConfig.java5 Mar 2003 21:42:22 - 1.19
+++ ContextConfig.java12 Mar 2003 07:12:28 - 1.20
@@ -67,19 +67,13 @@
import java.io.FileNotFoundException;
import java.io.InputStream;
import java.io.IOException;
-import java.lang.reflect.InvocationTargetException;
-import java.lang.reflect.Method;
import java.net.JarURLConnection;
-import java.net.MalformedURLException;
import java.net.URL;
-import java.util.ArrayList;
import java.util.Enumeration;
import java.util.HashSet;
import java.util.Iterator;
-import java.util.MissingResourceException;
-import java.util.ResourceBundle;
import java.util.Set;
-import java.util.Stack;
+import java.util.Properties;
import java.util.jar.JarEntry;
import java.util.jar.JarFile;
import javax.naming.NamingException;
@@ -94,9 +88,7 @@
import org.apache.catalina.Connector;
import org.apache.catalina.Container;
import org.apache.catalina.Context;
-import org.apache.catalina.DefaultContext;
import org.apache.catalina.Engine;
-import org.apache.catalina.Globals;
import org.apache.catalina.Host;
import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
@@ -108,12 +100,8 @@
import org.apache.catalina.Wrapper;
import org.apache.catalina.core.ContainerBase;
import org.apache.catalina.core.StandardContext;
+import org.apache.catalina.core.StandardEngine;
import org.apache.catalina.deploy.ApplicationParameter;
-import org.apache.catalina.deploy.ContextEjb;
-import org.apache.catalina.deploy.ContextEnvironment;
-import org.apache.catalina.deploy.ContextLocalEjb;
-import org.apache.catalina.deploy.ContextResource;
-import org.apache.catalina.deploy.ContextResourceLink;
import org.apache.catalina.deploy.ErrorPage;
import org.apache.catalina.deploy.FilterDef;
import org.apache.catalina.deploy.FilterMap;
@@ -121,10 +109,8 @@
import org.apache.catalina.deploy.SecurityConstraint;
import org.apache.catalina.util.StringManager;
import org.apache.catalina.util.SchemaResolver;
-import org.apache.catalina.valves.ValveBase;
import org.apache.commons.digester.Digester;
import org.xml.sax.InputSource;
-import org.xml.sax.EntityResolver;
import org.xml.sax.SAXNotRecognizedException;
import org.xml.sax.SAXNotSupportedException;
import org.xml.sax.SAXParseException;
@@ -151,7 +137,7 @@
* the name of the implemented authentication method, and the value is
* the fully qualified Java class name of the corresponding Valve.
*/
-private static ResourceBundle authenticators = null;
+private static Properties authenticators = null;
/**
@@ -169,7 +155,7 @@
/**
* The default web application's deployment descriptor location.
*/
-private String defaultWebXml = Constants.DefaultWebXml;
+private String defaultWebXml = null;
/**
@@ -244,7 +230,7 @@
* Return the location of the default deployment descriptor
*/
public String getDefaultWebXml() {
-
+if( defaultWebXml == null ) defaultWebXml=Constants.DefaultWebXml;
return (this.defaultWebXml);
}
@@ -334,6 +320,10 @@
((StandardContext) context).setReplaceWelcomeFiles(true);
}
webDigester.clear();
+//ClassLoader cl=Thread.currentThread().getContextClassLoader();
+//if( cl!=null )
+//webDigester.setClassLoader(cl);
+webDigester.setUseContextClassLoader(true);
webDigester.push(context);
webDigester.parse(is);
} else {
@@ -361,10 +351,9 @@
webRuleSet.recycle();
long t2=System.currentTimeMillis();
-if( (t2-t1 ) 200 )
-log.debug(Processed + url ++ (
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm GenericPrincipal.java
costin 2003/03/11 23:14:18
Modified:catalina/src/share/org/apache/catalina/realm
GenericPrincipal.java
Log:
- more info in toString()
- constructor without realm
Revision ChangesPath
1.2 +26 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/GenericPrincipal.java
Index: GenericPrincipal.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/GenericPrincipal.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- GenericPrincipal.java 18 Jul 2002 16:47:54 - 1.1
+++ GenericPrincipal.java 12 Mar 2003 07:14:18 - 1.2
@@ -123,9 +123,21 @@
if (this.roles.length 0)
Arrays.sort(this.roles);
}
-
}
+public GenericPrincipal(String name, String password,
+List roles) {
+
+super();
+this.name = name;
+this.password = password;
+if (roles != null) {
+this.roles = new String[roles.size()];
+this.roles = (String[]) roles.toArray(this.roles);
+if (this.roles.length 0)
+Arrays.sort(this.roles);
+}
+}
// - Properties
@@ -160,6 +172,10 @@
return (this.realm);
}
+void setRealm( Realm realm ) {
+this.realm=realm;
+}
+
/**
* The set of roles associated with this user.
@@ -196,7 +212,11 @@
StringBuffer sb = new StringBuffer(GenericPrincipal[);
sb.append(this.name);
-sb.append(]);
+sb.append(();
+for( int i=0;iroles.length; i++ ) {
+sb.append( roles[i]).append(,);
+}
+sb.append()]);
return (sb.toString());
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml
costin 2003/03/11 23:21:52 Modified:catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml Log: A bigger change - expose more info to JMX. Some features may break in /admin, I'll do more tests. - ClassNameMBean is no longer needed, the method is in modeler. - added the operations ( init/start/etc ) - use the right JMX1.2 names ( they are also the right JMX1.1 names - since this is a clarification ). It seems MX4J still works.. - added some attributes that were missing - fixed some names that generate conflicts when implementing in the base classes ( resources - resourceNames ). The problem is that the return type is different and the method already exists. - start to switch to the real object instead of using the decorator wrapper - removed the DTD - I don't know why but sometimes the resolve didn't worked and it connected to the site. Revision ChangesPath 1.18 +289 -80 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml Index: mbeans-descriptors.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- mbeans-descriptors.xml19 Feb 2003 21:06:40 - 1.17 +++ mbeans-descriptors.xml12 Mar 2003 07:21:52 - 1.18 @@ -1,18 +1,7 @@ ?xml version=1.0? -!DOCTYPE mbeans-descriptors PUBLIC - -//Apache Software Foundation//DTD Model MBeans Configuration File - http://jakarta.apache.org/commons/dtds/mbeans-descriptors.dtd; - -!-- - Descriptions of JMX MBeans for Catalina - - $Id$ - -- - mbeans-descriptors mbean name=AccessLogValve -className=org.apache.catalina.mbeans.ClassNameMBean description=Valve that generates a web server access log domain=Catalina group=Valve @@ -57,7 +46,6 @@ mbean name=BasicAuthenticator -className=org.apache.catalina.mbeans.ClassNameMBean description=An Authenticator and Valve implementation of HTTP BASIC Authentication domain=Catalina @@ -92,7 +80,6 @@ mbean name=CertificatesValve -className=org.apache.catalina.mbeans.ClassNameMBean description=Valve that exposes SSL certificate information domain=Catalina group=Valve @@ -111,7 +98,6 @@ mbean name=ContextConfig -className=org.apache.catalina.mbeans.ClassNameMBean description=Startup event listener for a Context that configures the properties of that Context, and the associated defined servlets @@ -322,6 +308,11 @@ description=Should Tomcat ignore setting a timeout for uploads? type=boolean/ +operation name=start description=Start impact=ACTION returnType=void / +operation name=stop description=Stop impact=ACTION returnType=void / +operation name=init description=Init impact=ACTION returnType=void / +operation name=destroy description=Destroy impact=ACTION returnType=void / + /mbean @@ -398,7 +389,6 @@ mbean name=DigestAuthenticator -className=org.apache.catalina.mbeans.ClassNameMBean description=An Authenticator and Valve implementation of HTTP DIGEST Authentication domain=Catalina @@ -432,7 +422,6 @@ /mbean mbean name=EngineConfig -className=org.apache.catalina.mbeans.ClassNameMBean description=Startup event listener for a Engine that configures the properties of that Engine, and the associated defined contexts @@ -453,7 +442,6 @@ mbean name=ErrorReportValve -className=org.apache.catalina.mbeans.ClassNameMBean description=Implementation of a Valve that outputs HTML error pages domain=Catalina group=Valve @@ -472,7 +460,6 @@ mbean name=ErrorDispatcherValve -className=org.apache.catalina.mbeans.ClassNameMBean description=Implementation of a Valve that handles the error dispatch domain=Catalina @@ -492,7 +479,6 @@ mbean name=FileLogger -className=org.apache.catalina.mbeans.ClassNameMBean description=Implementation of Logger that appends log messages to a file domain=Catalina @@ -532,7 +518,6 @@ /mbean
Re: 4.1 authentication bug / bug 14616
Bill Barker wrote: I think it is reasonable to fix it. This can be serious - if someone relies on application isolation ( like a hosting environment ), the consequences can be really bad, with one webapp guessing the credentials of another one. The fix seems reasonably simple and clean. Except that it isn't really a fix. Like Remy, I'd like to see a more general fix (e.g. using the new 5.0 Mapper). However, I won't -1 if Keith wants to commit his patch. It does fix the worst-case condition. Let's call it a small improvement :-) Costin Costin Keith Wannamaker wrote: Greetings, I brought this up in November. Remy and I have a disagreement on how important fixing this bug is. I want to see if there is a quorum of other committers who understand the problem and think it should be fixed prior to the next stable build release of 4.1. The immediate problem is that current Tomcat behavior causes browsers to submit auth credentials to webapps other than the webapp who originally sent the 401 challenge. Most web servers, like Apache, are careful to redirect for trailing slashes before challenging for authentication. Tomcat does this backward. The result is the client will usually cache the need for auth for the entire domain and not just a single webapp. Here is a repeat of the scenario I mentioned in November http://marc.theaimsgroup.com/?l=tomcat-devm=103673355109222w=2 Context path=/foo docBase=foo / Context path=/bar docBase=bar / foo and bar web.xml protected with security-constraint web-resource-collection web-resource-namename /web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint /security-constraint Current behavior: Request Response GET /foo401 (at this point browsers will send credentials to any url in this domain) GET /foo with auth 301 redirect to /foo/ GET /foo/ 200 GET /bar with auth ^ Correct behavior: GET /foo301 redirect to /foo/ GET /foo/ 401 GET /foo/ with auth 200 GET /bar without auth My proposed patch is attached to bug 14616 http://issues.apache.org/bugzilla/show_bug.cgi?id=14616 While this does not cover the case of subdirectories within a context, it does fix the most egregious case for context roots. Please comment if you are not comfortable with credentials being inadvertently shared between all webapps on a given domain. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteAdapter.java
billbarker2003/03/11 23:50:38
Modified:coyote/src/java/org/apache/coyote/tomcat5 CoyoteAdapter.java
Log:
Port cookie-validitity check from 4.1 branch.
Revision ChangesPath
1.12 +18 -12
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java
Index: CoyoteAdapter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- CoyoteAdapter.java28 Feb 2003 10:49:06 - 1.11
+++ CoyoteAdapter.java12 Mar 2003 07:50:38 - 1.12
@@ -341,6 +341,7 @@
Cookie[] cookies = new Cookie[count];
+int idx=0;
for (int i = 0; i count; i++) {
ServerCookie scookie = serverCookies.getCookie(i);
if (scookie.getName().equals(Globals.SESSION_COOKIE_NAME)) {
@@ -357,15 +358,20 @@
.getRequestedSessionId());
}
}
-Cookie cookie = new Cookie(scookie.getName().toString(),
- scookie.getValue().toString());
-cookie.setPath(scookie.getPath().toString());
-cookie.setVersion(scookie.getVersion());
-String domain = scookie.getDomain().toString();
-if (domain != null) {
-cookie.setDomain(scookie.getDomain().toString());
+try {
+Cookie cookie = new Cookie(scookie.getName().toString(),
+ scookie.getValue().toString());
+cookie.setPath(scookie.getPath().toString());
+cookie.setVersion(scookie.getVersion());
+String domain = scookie.getDomain().toString();
+if (domain != null) {
+cookie.setDomain(scookie.getDomain().toString());
+}
+cookies[idx++] = cookie;
+} catch(Exception ex) {
+log(Bad Cookie Name: + scookie.getName() +
+ /Value: + scookie.getValue(),ex);
}
-cookies[i] = cookie;
}
request.setCookies(cookies);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
