Re: [ANN] Tomcat 4.1.22 Alpha released

2003-03-11 Thread Henri Gomez
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

2003-03-11 Thread Henri Gomez
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 ?

2003-03-11 Thread Henri Gomez
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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread bugzilla
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)

2003-03-11 Thread Uddhav Shirname
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)

2003-03-11 Thread Uddhav Shirname
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

2003-03-11 Thread Remy Maucherat
[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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread Costin Manolache
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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread Costin Manolache
[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 ?

2003-03-11 Thread Costin Manolache
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 ?

2003-03-11 Thread Henri Gomez
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

2003-03-11 Thread remm
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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread Amy Roh
 [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

2003-03-11 Thread Jason Corley

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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread Remy Maucherat
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

2003-03-11 Thread Remy Maucherat
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

2003-03-11 Thread Costin Manolache
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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread Amy Roh
 
 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

2003-03-11 Thread Glenn Nielsen
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

2003-03-11 Thread costin
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 ?

2003-03-11 Thread Glenn Nielsen
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

2003-03-11 Thread glenn
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

2003-03-11 Thread Filip Hanik
 -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

2003-03-11 Thread glenn
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

2003-03-11 Thread glenn
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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread Costin Manolache
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

2003-03-11 Thread Filip Hanik
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

2003-03-11 Thread David Graff
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

2003-03-11 Thread bugzilla
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

2003-03-11 Thread Keith Wannamaker
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

2003-03-11 Thread Costin Manolache
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

2003-03-11 Thread jfarcand
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)

2003-03-11 Thread Uddhav Shirname
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

2003-03-11 Thread Costin Manolache
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

2003-03-11 Thread costin
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

2003-03-11 Thread Bill Barker

- 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

2003-03-11 Thread costin
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

2003-03-11 Thread costin
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

2003-03-11 Thread costin
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

2003-03-11 Thread Muhammad Riyaz Ahsan
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/mbeans ServerLifecycleListener.java

2003-03-11 Thread costin
costin  2003/03/11 22:41:09

  Modified:catalina/src/share/org/apache/catalina/mbeans
ServerLifecycleListener.java
  Log:
  Deal with the case when Service is used to start the server ( no Server ).
  
  Remove one more use of the ServerFactory - we already know the Server ( its
  the lifecycle instance )
  
  Sorry for the extra diff - it seems they had some whitespaces and my editor
  removed them ( I'll try to fix that setting )
  
  Revision  ChangesPath
  1.7   +61 -58
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
  
  Index: ServerLifecycleListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- ServerLifecycleListener.java  10 Jan 2003 18:55:57 -  1.6
  +++ ServerLifecycleListener.java  12 Mar 2003 06:41:09 -  1.7
  @@ -227,6 +227,18 @@
   
   }
   
  +// We are embedded.
  +if( lifecycle instanceof Service ) {
  +try {
  +MBeanFactory factory = new MBeanFactory();
  +createMBeans(factory);
  +loadMBeanDescriptors();
  +createMBeans((Service)lifecycle);
  +} catch( Exception ex ) {
  +log.error(Create mbean factory);
  +}
  +}
  +
   /*
   // Ignore events from StandardContext objects to avoid
   // reregistering the context
  @@ -236,12 +248,27 @@
   */
   
   } else if (Lifecycle.STOP_EVENT.equals(event.getType())) {
  +try {
  +if (lifecycle instanceof Server) {
  +destroyMBeans((Server)lifecycle);
  +}
  +if (lifecycle instanceof Service) {
  +destroyMBeans((Service)lifecycle);
  +}
  +} catch (MBeanException t) {
   
  -if (lifecycle instanceof Server) {
  -destroyMBeans();
  -}
  +Exception e = t.getTargetException();
  +if (e == null) {
  +e = t;
  +}
  +log.error(destroyMBeans: MBeanException, e);
  +
  +} catch (Throwable t) {
   
  -// FIXME: RMI adaptor should be stopped; however, this is 
  +log.error(destroyMBeans: Throwable, t);
  +
  +}
  +// FIXME: RMI adaptor should be stopped; however, this is
   // undocumented in MX4J, and reports exist in the MX4J bug DB that
   // this doesn't work
   
  @@ -424,7 +451,7 @@
   (Globals.MBEAN_REGISTRY_ATTR,
MBeanUtils.createRegistry());
   context.getServletContext().setAttribute
  -(Globals.MBEAN_SERVER_ATTR, 
  +(Globals.MBEAN_SERVER_ATTR,
MBeanUtils.createServer());
   }
   
  @@ -464,9 +491,9 @@
   log.debug(Creating MBean for Valve  + cValves[l]);
   MBeanUtils.createMBean(cValves[l]);
   }
  -
  -}
  -
  +
  +}
  +
   // Create the MBeans for the NamingResources (if any)
   NamingResources resources = context.getNamingResources();
   createMBeans(resources);
  @@ -511,7 +538,7 @@
   
   }
   
  -
  +
   /**
* Create the MBeans for the specified ContextResourceLink entry.
*
  @@ -544,9 +571,9 @@
   if (log.isDebugEnabled())
   log.debug(Creating MBean for DefaultContext  + dcontext);
   MBeanUtils.createMBean(dcontext);
  -   
  +
   dcontext.addPropertyChangeListener(this);
  -
  +
   // Create the MBeans for the associated nested components
   Loader dLoader = dcontext.getLoader();
   if (dLoader != null) {
  @@ -554,21 +581,21 @@
   log.debug(Creating MBean for Loader  + dLoader);
   MBeanUtils.createMBean(dLoader);
   }
  - 
  +
   Manager dManager = dcontext.getManager();
   if (dManager != null) {
   if (log.isDebugEnabled())
   log.debug(Creating MBean for Manager  + dManager);
   MBeanUtils.createMBean(dManager);
   }
  -
  +
   // Create the MBeans for the NamingResources (if any)
   NamingResources resources = dcontext.getNamingResources();
   createMBeans(resources);
   
   }
  -
  -
  +
  +
   /**
* Create the MBeans for the specified Engine and its nested components.
*
  @@ -624,7 +651,7 @@
   

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java

2003-03-11 Thread costin
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

2003-03-11 Thread costin
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

2003-03-11 Thread costin
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

2003-03-11 Thread Costin Manolache
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

2003-03-11 Thread billbarker
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]