Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteRequest.java

[Remy Maucherat]

Bill Barker wrote:
I'm -1 on this patch unless you can explain what the bug exactly was,
and how the recycling couldn't properly reset the facade.
I'm not really happy with the patch either.  I'll postpone adding my (since
it's the second, binding) -1 until you provide a better explaination.
Well, I have no idea what the bug report mentioned looks like, so I 
can't provide a real evaluation. However, what I'm now pretty sure about 
is that the patch is possibly unsafe.

Note: AFAIK, one -1 is enough.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk 1.2.4 release Monday 6/9

[Glenn Nielsen]

A bug was reported with the linux build with Apache 2.0.46 with libtool.
This has been fixed and an updated mod_jk 1.2.4 source distribution for testing
is available at:
http://cvs.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.4-src.tar.gz

Thanks Henri and JF for taking care of this.

Glenn

Glenn Nielsen wrote:
So far there have been no problems reported with mod_jk 1.2.4 except for
one minor documentation typo which has been fixed.
If I don't see any problems reported from further testing before Monday
I will make the mod_jk 1.2.4 source release and announcement.
Thanks for all the help testing.

Once the release is announced binaries can be and installed in
the release directory.
Regards,

Glenn



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteRequest.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
jfarcand2003/06/05 20:03:33

  Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
  Log:
  When the SecurityManager is turned on, the facade is never properly garbaged. Bugtraq 48
  66915 demonstrates a case where CoyoteRequestFacade is re-used with a request object equ
  als to null (the getAttribute throws NPE). The bug also exists in Tomcat 4.1.x. (should
  I port the patch?)
  
  Also, the way response are recycled may also produce the same behaviour, althrough I can
  't reproduce the exception.
Ok, I thought about it a bit more.

To give you more detail, the code in recycle() is:

if ((Constants.SECURITY) && (facade != null)) {
facade.clear();
facade = null;
}
Doing a clear forces the facade to dump its pointer to the request, so 
you can't hold to the reference and invoke methods on it (you get NPEs). 
What you did leads possibly to the creation of multiple facades, and 
only the last one will be cleared. All others will still have a pointer 
to the real request object, so could be used by a rogue thread to access 
data randomly. As I don't quite remember if the last facade would be 
given to the webapp (it could well be), your patch opens a potential 
secuity problem.
To summarize, there's no point in facading for security (the security 
manager will already protect from casting and method invocation) unless 
you guarantee that all facades are disassociated from the underlying 
request object.

So, I'm confirming my -1 for the patch.

Maybe you could post details on the bugs you're trying to fix. If it's 
valid (I doubt it, all the similar NPEs I've seen were invalid), then 
we'll need to find a safe solution.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java

[Bill Barker]

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, June 05, 2003 11:32 PM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java


> [EMAIL PROTECTED] wrote:
> > jfarcand2003/06/05 20:03:33
> >
> >   Modified:catalina/src/share/org/apache/coyote/tomcat5
> > CoyoteRequest.java
> >   Log:
> >   When the SecurityManager is turned on, the facade is never properly
garbaged. Bugtraq 48
> >   66915 demonstrates a case where CoyoteRequestFacade is re-used with a
request object equ
> >   als to null (the getAttribute throws NPE). The bug also exists in
Tomcat 4.1.x. (should
> >   I port the patch?)
> >
> >   Also, the way response are recycled may also produce the same
behaviour, althrough I can
> >   't reproduce the exception.
>
> I'm not sure I understand what was going on, and I have no access to
> bugtraq. I believe the NPE occurred because of an access beyond the
> useful lifecycle of the request.
> The facade should be set to null when recycling the request, so this is
> supposed to take care of the problem. BTW, there's no guarantee that
> getRequest will be called just once during the processing of the request.
>
> I'm -1 on this patch unless you can explain what the bug exactly was,
> and how the recycling couldn't properly reset the facade.
>

I'm not really happy with the patch either.  I'll postpone adding my (since
it's the second, binding) -1 until you provide a better explaination.

> 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: cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java

[Remy Maucherat]

Jan Luehe wrote:
Bill,


SSLAuthenticator makes a request for a special Request attribute
("org.apache.coyote.request.X509Certificate"), which fires off an Action
hook (ACTION_REQ_SSL_CERTIFICATE) to renegotiate the handshake if necessary.
I changed TC 5 a little while back to do a lazy-evaluation of the SSL
attributes.  If you are seeing problems, that might be where.


Well, the reason I was still using the (supposedly deprecated)
CertificatesValve was because it was still being added to the pipeline
in ContextConfig. I'm going to change ContextConfig as follows:
Index: ContextConfig.java
===
RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.25
diff -u -r1.25 ContextConfig.java
--- ContextConfig.java  14 May 2003 17:42:55 -  1.25
+++ ContextConfig.java  5 Jun 2003 23:08:13 -
@@ -497,7 +497,7 @@
 Valve certificates = null;
 try {
 Class clazz =
-Class.forName("org.apache.catalina.valves.CertificatesValve");
+Class.forName("org.apache.catalina.authenticator.SSLAuthenticator");
 certificates = (Valve) clazz.newInstance();
 } catch (Throwable t) {
 return; // Probably JSSE classes not present
Even with this fix in place, the SSLAuthenticator's authenticate() method
was still not being invoked, because 
org.apache.catalina.authenticator.AuthenticatorBase
currently does not consider the CLIENT-CERT authentication constraint at
all.
After fixing this, the SSL handshake does get renegotiated in the way you
described, but for some reason the connection then times out. I'm still investigating.
Thanks for putting me on the right track, Bill!

Jan

P.S.: I'm also +1 for removing the CertificatesValve, since it is
confusing to have several valves essentially doing the same thing.
There's no need to hardcode the authenticator, you only need to add it 
in startup.Authenticators.properties, and it will be added in the 
pipeline as needed. It's already there, BTW, so I don't quite see what's 
going on (but it should be fixed there, no harcoding required).

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteRequest.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
jfarcand2003/06/05 20:03:33

  Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
  Log:
  When the SecurityManager is turned on, the facade is never properly garbaged. Bugtraq 48
  66915 demonstrates a case where CoyoteRequestFacade is re-used with a request object equ
  als to null (the getAttribute throws NPE). The bug also exists in Tomcat 4.1.x. (should
  I port the patch?)
  
  Also, the way response are recycled may also produce the same behaviour, althrough I can
  't reproduce the exception.
I'm not sure I understand what was going on, and I have no access to 
bugtraq. I believe the NPE occurred because of an access beyond the 
useful lifecycle of the request.
The facade should be set to null when recycling the request, so this is 
supposed to take care of the problem. BTW, there's no guarantee that 
getRequest will be called just once during the processing of the request.

I'm -1 on this patch unless you can explain what the bug exactly was, 
and how the recycling couldn't properly reset the facade.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] More dependencies

[Costin Manolache]

Remy Maucherat wrote:

> In this email, I forgot to speak about other commons (and others)
> dependencies. Thanks for all the volunteering, BTW, it really helps
> (damn day job ...) :)

+1 :-)


> JMX: I think we should try to ship with JMX 1.2 + a JSR 160
> implementation if possible. I really hope MX4J will be able to provide
> that.

I think we must ship with JMX1.2 - AFAIK MX4J is close, but it may be better
to use JMX-RI for this one. If I remember the terms on the licence are
different from the previous one - but someone should confirm if we can
redistribute it.


> Tyrex: This project seems dead (unfortunately) :-( We could replace it
> with some other TM, or (I like that one better) not provide an object
> factory implementation for UserTransaction by default, and let third
> parties provide it. That model seems to work great for J2EE providers
> (JOTM, OpenEJB, etc).

+1 on no TM. If someone needs a TM - he can choose whatever fits. This will
also reduce the size of tomcat :-)


> Struts: We need 1.1 ! (I think the rest of the world does also :-D)
> 
> Watchdog: (to the Sun folks) Where is Watchdog 5 (or whatever it's called)
> ?
> 
> Remy

Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] More dependencies

[Costin Manolache]

Bill Barker wrote:

> I know that at one point there was a problem if you enabled the JMX consol
> (e.g. set mx.port=9000 in jk2.properties).  I don't remember if that's
> been fixed.

I think the bug was in our code - i.e. we didn't call stop. I remember
fixing it in jk, if you start the adapter using jk2.properties it should
work. 

Costin


> 
> But the short answer is, yes the HttpAdapter creates non-daemon threads.
> 
> - Original Message -
> From: "Tim Funk" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Thursday, June 05, 2003 2:12 PM
> Subject: Re: [5.0] More dependencies
> 
> 
>> When I was testing with the HttpAdapter and Sun's JMX 1.2ri, on shutdown
> of
>> tomcat the JVM did not die. If I removed the jar - all was OK. (But of
> course
>> I lost HttpAdapter functionality) Does anyone know if Sun's HttpAdapter
>> creates non-daemon threads? Of course the problem might be in tomcat too,
> I'm
>> sorry for not doing much debugging on this yet.
>>
>> Unfortunately, I was using cygwin and you can't get JVM stacktraces with
> cygwin.
>>
>> Time permitting, I will try testing this on linux box tonight to see what
>> threads are keeping the JVM alive. (Or *gasp* - go back to using the bat
> files)
>>
>> -Tim
>>
>> Remy Maucherat wrote:
>> >
>> > JMX: I think we should try to ship with JMX 1.2 + a JSR 160
>> > implementation if possible. I really hope MX4J will be able to provide
>> > that.
>> >
>> >
>> > 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]

DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=7831

[PATCH] JNDIRealm does not work with CLIENT-CERT auth method





--- Additional Comments From [EMAIL PROTECTED]  2003-06-05 12:57 ---
@marek:
I am not happy with this. I think a correct implementation should not use the 
Cert-Subject for the username.

I have implemented my own JNDIRealm which tries to lookup a user with the 
certificate and uses the name found for the principal-object.

So it makes no difference which certificate the user uses, or if you use BASIC 
Authentication with my JNDIRealm, for the application it is almost always the 
same user.

The dark side of this solution is, that it depends on how the LDAP-Server saves 
certificates. My solution currently works with Windows Active Directory, 
however, it should be easy to adopt it.

I have tried to discuss this on tomcat-dev (search "CLIENT-CERT and JNDI"), but 
no one has answered yet.

I am looking forward to share my thoughts.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=7831

[PATCH] JNDIRealm does not work with CLIENT-CERT auth method





--- Additional Comments From [EMAIL PROTECTED]  2003-06-05 12:37 ---
CLIENT-CERT authentication is done via SSLAuthenticator class which
executes RealmBase.authenticate(X509Certifcate[] certs) method.
This method uses getPrincipal(String username) method to return principal for 
given username. If this returs null SSLAutheticator denies to authenticate user.
For SSLAuthenticator it is only important to check if user exists in realm and
find roles becues AUTHENTICATION is done SSLAuthenticator (checking validity
od certificate)
This is my implementation for JDBCRealm.getPrincipal which works :
(If you want to consult this patch please mail me)

/**
 * Return the Principal associated with the given user name.
 * This method is used in RealmBase.authenticate(X509Certificate[] creds)
 * which is then used in SSLAuthenticator to authenticate
 * with client with CLIENT-CERT method
 * Absence of this method (returning null) makes CLEINT-CERT authorization 
 * impossible. 
 *
 * @author Marek Mosiewicz <[EMAIL PROTECTED]>
 */
protected Principal getPrincipal(String username) {
Connection dbConnection = null;

try {
// Ensure that we have an open database connection
dbConnection = open();
  
String dbCredentials = null;  
PreparedStatement stmt = credentials(dbConnection, username);
ResultSet rs = stmt.executeQuery();
  while (rs.next()) {
dbCredentials = rs.getString(1).trim();
  }
  rs.close();
  if (dbCredentials == null) {
return (null);
}
  // Accumulate the user's roles
ArrayList list = new ArrayList();
  stmt = roles(dbConnection, username);
  rs = stmt.executeQuery();
  while (rs.next()) {
list.add(rs.getString(1).trim());
  }
  rs.close();
dbConnection.commit();

// Release the database connection we just used
release(dbConnection);

// Create and return a suitable Principal for this user
return (new GenericPrincipal(this, username, null, list));
} catch (SQLException e) {
// 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 "null" principal
return (null);
}
}

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP] Build timed out - jk

[Craig McClanahan]

This email is autogenerated from the output from:



Buildfile: build.xml

init:
 [echo] /home/rubys
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk
 [echo] linux=true solaris=${solaris} win32=${win32} hpux=${hpux} 
netware=${netware}

apache20:

apache13:

iis:

netscape:

jni:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni
   [so] Compiling 4 out of 4
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_map.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_pool.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_util.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c
Linking /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni/jni_connect.so
/home/rubys/bin/timeout: timed out

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP] Build Failure - tomcat-catalina

[Craig McClanahan]

This email is autogenerated from the output from:



Buildfile: build.xml

flags:

flags.display:
 [echo] --- Build environment for Catalina ---
 [echo] If ${property_name} is displayed, then the property is not set)
 [echo] --- Build options ---
 [echo] full.dist=${full.dist}
 [echo] build.sysclasspath=only
 [echo] compile.debug=${compile.debug}
 [echo] compile.deprecation=${compile.deprecation}
 [echo] compile.optimize=${compile.optimize}
 [echo] --- Ant Flags ---
 [echo] 

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse JSSE14Support.java

[billbarker]

billbarker2003/06/05 20:25:30

  Modified:util/java/org/apache/tomcat/util/net/jsse JSSE14Support.java
  Log:
  Add more logging.  No functional change.
  
  Revision  ChangesPath
  1.5   +2 -0  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14Support.java
  
  Index: JSSE14Support.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14Support.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- JSSE14Support.java17 Apr 2003 08:11:46 -  1.4
  +++ JSSE14Support.java6 Jun 2003 03:25:30 -   1.5
  @@ -174,6 +174,8 @@
return null;
}
}
  + if(logger.isTraceEnabled())
  + logger.trace("Cert #" + i + " = " + x509Certs[i]);
}
if(x509Certs.length < 1)
return null;
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java

[jfarcand]

jfarcand2003/06/05 20:03:33

  Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
  Log:
  When the SecurityManager is turned on, the facade is never properly garbaged. 
Bugtraq 48
  66915 demonstrates a case where CoyoteRequestFacade is re-used with a request object 
equ
  als to null (the getAttribute throws NPE). The bug also exists in Tomcat 4.1.x. 
(should
  I port the patch?)
  
  Also, the way response are recycled may also produce the same behaviour, althrough I 
can
  't reproduce the exception.
  
  Revision  ChangesPath
  1.8   +6 -7  
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
  
  Index: CoyoteRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- CoyoteRequest.java5 Jun 2003 19:47:41 -   1.7
  +++ CoyoteRequest.java6 Jun 2003 03:03:33 -   1.8
  @@ -597,9 +597,9 @@
* is the facade.  This method must be implemented by a subclass.
*/
   public ServletRequest getRequest() {
  -if (facade == null) {
  +if (facade == null || Constants.SECURITY) {
   facade = new CoyoteRequestFacade(this);
  -}
  +} 
   return (facade);
   }
   
  @@ -728,7 +728,6 @@
* Set the Wrapper within which this Request is being processed.  This
* must be called as soon as the appropriate Wrapper is identified, and
* before the Request is ultimately passed to an application servlet.
  - *
* @param wrapper The newly associated Wrapper
*/
   public void setWrapper(Wrapper wrapper) {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves CertificatesValve.java

[billbarker]

billbarker2003/06/05 19:46:41

  Modified:catalina/src/share/org/apache/catalina/startup
ContextConfig.java
  Removed: catalina/src/share/org/apache/catalina/valves
CertificatesValve.java
  Log:
  Removing CertificatesValve, since the HttpConnector isn't supported here.
  
  It doesn't do anything with the CoyoteConnector, and could cause problems trying to 
use Tomcat with a non-Sun 1.4 JVM.
  
  Revision  ChangesPath
  1.26  +1 -81 
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.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- ContextConfig.java14 May 2003 17:42:55 -  1.25
  +++ ContextConfig.java6 Jun 2003 02:46:41 -   1.26
  @@ -445,82 +445,6 @@
   
   }
   
  -
  -/**
  - * Create and deploy a Valve to expose the SSL certificates presented
  - * by this client, if any.  If we cannot instantiate such a Valve
  - * (because the JSSE classes are not available), silently continue.
  - * This is only instantiated for those Contexts being served by
  - * a Connector with secure set to true.
  - */
  -private void certificatesConfig() {
  -
  -// Only install this valve if there is a Connector installed
  -// which has secure set to true.
  -boolean secure = false;
  -Container container = context.getParent();
  -if (container instanceof Host) {
  -xmlValidation = ((Host)container).getXmlValidation();
  -xmlNamespaceAware = ((Host)container).getXmlNamespaceAware();
  -container = container.getParent();
  -}
  -if (container instanceof Engine) {
  -Service service = ((Engine)container).getService();
  -// The service can be null when Tomcat is run in embedded mode
  -if (service == null) {
  -secure = true;
  -} else {
  -Connector [] connectors = service.findConnectors();
  -for (int i = 0; i < connectors.length; i++) {
  -secure = connectors[i].getSecure();
  -if (secure) {
  -break;
  -}
  -}
  -}
  -}
  -if (!secure) {
  -return;
  -}
  -
  -// Validate that the JSSE classes are present
  -try {
  -Class clazz = this.getClass().getClassLoader().loadClass
  -("javax.net.ssl.SSLSocket");
  -if (clazz == null)
  -return;
  -} catch (Throwable t) {
  -return;
  -}
  -
  -// Instantiate a new CertificatesValve if possible
  -Valve certificates = null;
  -try {
  -Class clazz =
  -Class.forName("org.apache.catalina.valves.CertificatesValve");
  -certificates = (Valve) clazz.newInstance();
  -} catch (Throwable t) {
  -return; // Probably JSSE classes not present
  -}
  -
  -// Add this Valve to our Pipeline
  -try {
  -if (context instanceof ContainerBase) {
  -Pipeline pipeline = ((ContainerBase) context).getPipeline();
  -if (pipeline != null) {
  -((ContainerBase) context).addValve(certificates);
  -log.info(sm.getString
  -("contextConfig.certificatesConfig.added"));
  -
  -}
  -}
  -} catch (Throwable t) {
  -log.error(sm.getString("contextConfig.certificatesConfig.error"), t);
  -ok = false;
  -}
  -
  -}
  -
   private static Digester patchXerces(Digester digester){
   // This feature is needed for backward compatibility with old DDs
   // which used Java encoding names such as ISO8859_1 etc.
  @@ -799,10 +723,6 @@
   if (ok) {
   validateSecurityRoles();
   }
  -
  -// Configure a certificates exposer valve, if required
  -if (ok)
  -certificatesConfig();
   
   // Configure an authenticator if we need one
   if (ok)
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native configure.in

[jfclere]

jfclere 2003/06/05 02:15:37

  Modified:jk/native configure.in
  Log:
  Fix the error when using apxs of Apache-2.0: Use apache libtool instead system.
  The error was:
  +++
  libtool: link: `../common/jk_ajp12_worker.lo' is not a valid libtool
  object
  +++
  
  Revision  ChangesPath
  1.24  +2 -1  jakarta-tomcat-connectors/jk/native/configure.in
  
  Index: configure.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/configure.in,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- configure.in  27 May 2003 13:04:46 -  1.23
  +++ configure.in  5 Jun 2003 09:15:37 -   1.24
  @@ -103,6 +103,7 @@
APXSCFLAGS="`${APXS} -q CFLAGS` `${APXS} -q EXTRA_CFLAGS`"
APXSCPPFLAGS="`${APXS} -q EXTRA_CPPFLAGS`"
   APACHE_CONFIG_VARS=${apache_dir}/build/config_vars.mk
  +LIBTOOL=`$APXS -q LIBTOOL`
   fi
   AC_MSG_RESULT([building connector for \"$WEBSERVER\"])
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Commons dependencies

[Remy Maucherat]

Shapira, Yoav wrote:
Howdy,

The Commons web pages have some notes for doing Commons releases at:

http://jakarta.apache.org/commons/releases.html
Those instructions seem clear enough.  I volunteer to be the release
manager for modeler 1.0 ;)
+1. Thanks a lot for the help :)

There seem to be no bugs open for modeler in Bugzilla ("Zarro Boogs
found" ;)), so the next step is a release vote it appears...
Probably.
Costin didn't mention anything, so except Amy's one line patch there's 
(so far) nothing to do to the code.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20491] - Connection: Close header ignored

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20491

Connection: Close header ignored

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-06-05 06:06 ---
AFAIK, this works correctly with the CoyoteConnector.  The HttpConnector is 
deprecated, and won't be fixed.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse JSSE13Factory.java JSSE14Factory.java JSSEFactory.java JSSEImplementation.java

[billbarker]

billbarker2003/06/04 22:16:25

  Modified:util/java/org/apache/tomcat/util/net/jsse
JSSEImplementation.java
  Added:   util/java/org/apache/tomcat/util/net/jsse JSSE13Factory.java
JSSE14Factory.java JSSEFactory.java
  Log:
  Yet another re-factoring to support JSSE 1.1.x better.
  
  Removing the introspection from the per-connection, and moving it into a Factory 
method (that depends on the JVM version).
  
  Revision  ChangesPath
  1.7   +24 -45
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSEImplementation.java
  
  Index: JSSEImplementation.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSEImplementation.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- JSSEImplementation.java   27 Apr 2003 05:28:55 -  1.6
  +++ JSSEImplementation.java   5 Jun 2003 05:16:25 -   1.7
  @@ -65,8 +65,6 @@
   import org.apache.tomcat.util.net.ServerSocketFactory;
   import java.io.*;
   import java.net.*;
  -import java.lang.reflect.Constructor;
  -import javax.net.ssl.SSLSocket;
   
   /* JSSEImplementation:
   
  @@ -77,18 +75,33 @@
   
   public class JSSEImplementation extends SSLImplementation
   {
  -static final String JSSE14SocketFactory = 
  -"org.apache.tomcat.util.net.jsse.JSSE14SocketFactory";
  -static final String JSSE14Support = 
  -"org.apache.tomcat.util.net.jsse.JSSE14Support";
  +static final String JSSE14Factory = 
  +"org.apache.tomcat.util.net.jsse.JSSE14Factory";
  +static final String JSSE13Factory = 
  +"org.apache.tomcat.util.net.jsse.JSSE13Support";
   static final String SSLSocketClass = "javax.net.ssl.SSLSocket";
   
   static org.apache.commons.logging.Log logger = 
   org.apache.commons.logging.LogFactory.getLog(JSSEImplementation.class);
   
  +private JSSEFactory factory;
  +
   public JSSEImplementation() throws ClassNotFoundException {
   // Check to see if JSSE is floating around somewhere
  -Class.forName("javax.net.ssl.SSLServerSocketFactory");
  +Class.forName(SSLSocketClass);
  + if( JdkCompat.isJava14() ) {
  + try {
  + Class factcl = Class.forName(JSSE14Factory);
  + factory = (JSSEFactory)factcl.newInstance();
  + } catch(Exception ex) {
  + factory = new JSSE13Factory();
  + if(logger.isDebugEnabled()) {
  + logger.debug("Error getting factory: " + JSSE14Factory, ex);
  + }
  + }
  + } else {
  + factory = new JSSE13Factory();
  + }
   }
   
   
  @@ -96,47 +109,13 @@
 return "JSSE";
   }
 
  -public ServerSocketFactory getServerSocketFactory()
  -{
  -ServerSocketFactory ssf = null;
  -if( JdkCompat.isJava14() ) {
  -try {
  -Class ssfCl = Class.forName(JSSE14SocketFactory);
  -ssf =(ServerSocketFactory)ssfCl.newInstance();
  -} catch(Exception ex) {
  -if(logger.isDebugEnabled())
  -logger.debug("Error finding " + JSSE14SocketFactory, ex);
  -ssf = new JSSESocketFactory();
  -}
  -} else {
  -ssf = new JSSESocketFactory();
  -}
  +public ServerSocketFactory getServerSocketFactory()  {
  +ServerSocketFactory ssf = factory.getSocketFactory();
   return ssf;
   } 
   
  -public SSLSupport getSSLSupport(Socket s)
  -{
  -SSLSupport ssls = null;
  -if( JdkCompat.isJava14() ) {
  -try {
  -Class sslsCl = Class.forName(JSSE14Support);
  -Class [] cparams = new Class[1];
  -cparams[0] = Class.forName(SSLSocketClass);
  -Constructor sslc = sslsCl.getConstructor(cparams);
  -Object [] params = new Object[1];
  -params[0] = s;
  -ssls = (SSLSupport)sslc.newInstance(params);
  -} catch(Exception ex) {
  -if(logger.isDebugEnabled())
  -logger.debug("Unable to get " + JSSE14Support, ex);
  -ssls = new JSSESupport((SSLSocket)s);
  -}
  -} else {
  -ssls = new JSSESupport((SSLSocket)s);
  -}
  +public SSLSupport getSSLSupport(Socket s) {
  +SSLSupport ssls = factory.getSSLSupport(s);
   return ssls;
   }
  -
  -
  -
   }
  
  
  
  1.1  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE13Factory.java
  
  Index: JSSE13Factory.java
  ===
  /*
   * 
   *
   

RE: [5.0] Commons dependencies

[Costin Manolache]

Shapira, Yoav wrote:

> 
> Howdy,
> 
>>The Commons web pages have some notes for doing Commons releases at:
>>
>>  http://jakarta.apache.org/commons/releases.html
> 
> Those instructions seem clear enough.  I volunteer to be the release
> manager for modeler 1.0 ;)

+1 :-)


> There seem to be no bugs open for modeler in Bugzilla ("Zarro Boogs
> found" ;)), so the next step is a release vote it appears...

Yes. There is one problem that Amy reported few weeks ago - I don't know 
how it was resolved.


Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20491] New: - Connection: Close header ignored

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20491

Connection: Close header ignored

   Summary: Connection: Close header ignored
   Product: Tomcat 4
   Version: 4.1.24
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Referencing this copy of the HTTP 1.1 specification

http://www.zvon.org/tmRFC/RFC2616/Output/index.html

Per sections 8.1.2.1 and 14.10 any client not supporting persistent HTTP 
connections should send a "Connection: close" header.

Per section 4.2 header field names are case-insensitive but header field values 
are not specified.  It may therefore be assumed that the intent is to support 
case-sensitive header field values at the discretion of the implementing 
application.

We've found a product (formerly Cisco uOne) which implements an HTTP client 
which uses the slightly incorrect syntax of "Connection: Close" (note the upper 
case 'C').  While this does not quite comply with the HTTP 1.1 spec which 
refers to use of the string "close" only the HTTP 1.1 spec never makes mention 
of requiring that "close" be lower case.  Clearly the use of "Close" is a poor 
implementation but it would seem that Tomcat 4.1 is unnecessarily picky here.

Per section 19.3 it is recommended that applications be "tolerant of deviations 
whenever those deviations can be interpreted unambiguously".  I think that 
applies in this case and thus I suggest making Tomcat 4.x tolerant of the HTTP 
header "Connection: Close".

Below is a patch for jakarta-tomcat-
4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java.  
It may not be the ideal way to implement the fix as perhaps adding alternative 
case-insensitive comparison methods to the HttpHeader class would be more 
elegant.

RCS file: /home/cvspublic/jakarta-tomcat-
4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
retrieving revision 1.46
diff -r1.46 HttpProcessor.java
680,681c680,681
< if (header.valueEquals
< (DefaultHeaders.CONNECTION_CLOSE_VALUE)) {
---
> if (value.equalsIgnoreCase(
> new String(DefaultHeaders.CONNECTION_CLOSE_VALUE))) {

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17867] - new virtual host doesn't work after restart

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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





--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 23:27 ---
Well, I couldn't leave the site down long enough to show any body.  So, I
brought it back up.  But, I have to reconfigure every reboot.  Anyways, I guess
I'll bite the bullet and start looking at the start up code for catalina.  I'm a
software engineer and programmer, and java happens to be my forte.  I'll let you
know if I find the problem.  I haven't had a reply as of yet, and I'm not
exactly sure how to get involved in the dev process.  If I find an issue who
should I contact to get it in the code base?  Well, that's it for now.  It's
either I fix it or just use a different server.  But, I really like tomcat.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Tomcat 5] JSR-045 SMAP & class file disagreement

[Todd Williams]

We're working to support source-level JSP debugging
for Tomcat 5 using its JSR-045 support.  However,
we've been unsuccessful at getting this to work
because the line to code index map that we retrieve
from our SourceDebugExtension JDWP request
does not agree with the  SMAP that was generated
when my example JSP was compiled.  The SMAP appears
to be correct but for whatever reason the line
mapping returned from the JVM has little in common
with the SMAP.  Perhaps there's something we're missing
and are not properly requesting that the SMAP be
placed in the class file?

We've tried searching the documentation, Google,
Usenet, and the Tomcat mail lists and bugzilla to no avail.
We've already gotten our debugging implementation working
properly with WebLogic 7.0 and 8.1 so I have a high degree
of confidence that once this mapping issue is
resolved we'll also have a source-level JSP debugging
solution for Tomcat 5 also.  We really want to have an open
source option available for JSP debugging and right
now we're so close so any help or information at all is
GREATLY appreciated.

Here are the details of our test environment:
Platform: Window 2000, latest SP
JDK: 1.4.1_02-b06
Tomcat: Version 5.0.2 (alpha)
Tomcat 5 JSP servlet settings from web.xml:

jsp
org.apache.jasper.servlet.JspServlet

logVerbosityLevel
WARNING


classdebuginfo
true


suppressSmap
false


dumpSmap
true


development
true

3




For the test, we attempt to set a breakpoint on line 18, which
according to the SMAP corresponds to line 62 of the servlet.
Here's the test JSP, with line numbers for convenience.
1  
2  <%@ page language="java" import="java.lang.*,java.util.*" %>
3  <%
4  String path = request.getContextPath();
5  String basePath =
"http://"+request.getServerName()+":"+request.getServerPort()+path+"/";
6  %>
7  
8   
9  
10  My JSP 'TestJSP.jsp' starting page
11 
12
13 
14 <%
15Date date = new Date();
16out.println("Current time is: " + date);
17  out.println(".  ");
18  date = new Date();
19  out.println("Now the time is " + date);
20  out.println(".  ");
21  %>
22  This is my test JSP page. 
23  
24  


Here's the SMAP generated by Tomcat:
SMAP
C:\dev\ApacheGroup\Tomcat
5.0.2alpha\work\Catalina\localhost\TomcatTest\org\apache\jsp\TomcatTestJSP_j
sp.java
JSP
*S JSP
*F
+ 0 TomcatTestJSP.jsp
/TomcatTestJSP.jsp
*L
1:42
4,3:45
7:49
8:50
9:51
9:52
9:53
10:54
10:55
11:56
13:57
15,7:59
22:67
22:68
23:69
24:70
*E


Here's the generated servlet.  As you can see,
line 62 is correct for the breakpont request from
line 18 of the JSP file.
1 package org.apache.jsp;
2
3 import javax.servlet.*;
4 import javax.servlet.http.*;
5 import javax.servlet.jsp.*;
6 import java.lang.*;
7 import java.util.*;
8
9 public final class TomcatTestJSP_jsp extends
org.apache.jasper.runtime.HttpJspBase
10implements org.apache.jasper.runtime.JspSourceDependent {
11
12  private static java.util.Vector _jspx_dependants;
13
14  public java.util.List getDependants() {
15return _jspx_dependants;
16  }
17
18  public void _jspService(HttpServletRequest request,
HttpServletResponse response)
19throws java.io.IOException, ServletException {
20
21JspFactory _jspxFactory = null;
22PageContext pageContext = null;
23HttpSession session = null;
24ServletContext application = null;
25ServletConfig config = null;
26JspWriter out = null;
27Object page = this;
28JspWriter _jspx_out = null;
29
30
31try {
32  _jspxFactory = JspFactory.getDefaultFactory();
33  response.setContentType("text/html;charset=ISO-8859-1");
34  pageContext = _jspxFactory.getPageContext(this, request,
response,
35 null, true, 8192, true);
36  application = pageContext.getServletContext();
37  config = pageContext.getServletConfig();
38  session = pageContext.getSession();
39  out = pageContext.getOut();
40  _jspx_out = out;
41
42  out.write("\r\n");
43  out.write("\r\n");
44
45String path = request.getContextPath();
46String basePath =
"http://"+request.getServerName()+":"+request.getServerPort()+path+"/";
47
48  out.write("\r\n");
49  out.write("\r\n\t");
50  out.write("\r\n\t\t");
51  out.write("\t\t\r\n\t\t");
54  out.write("My JSP 'TestJSP.jsp' starting page");
55  out.write("\r\n\t");
56  out.write("\r\n\r\n\t");
57  out.write("\r\n\t  ");
58
59Date date = new Date();
60out.println("Current time is: " + date);
61  out.println(".  ");
62 

cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml tomcat-docs.xsl

[remm]

remm2003/06/04 14:57:36

  Modified:webapps/docs changelog.xml tomcat-docs.xsl
  Log:
  - Update changelog.
  - Implement bug links (link to the bug description in BZ).
  
  Revision  ChangesPath
  1.3   +9 -0  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- changelog.xml 4 Jun 2003 18:15:19 -   1.2
  +++ changelog.xml 4 Jun 2003 21:57:35 -   1.3
  @@ -42,6 +42,15 @@
   
   
   
  +  
  +  Add caching mechanism for invocation of methods using privileged actions
  +  (jfarcand)
  +  
  +  
  +  20380: AccessLogValve incorrectly calculates timezone, 
  +  16374: Date in file name configurable, 16400:
  +  Allow logging to be conditional (funkman)
  +  
 
 W3C Extended Log File Format support (funkman)
 
  
  
  
  1.5   +8 -1  jakarta-tomcat-catalina/webapps/docs/tomcat-docs.xsl
  
  Index: tomcat-docs.xsl
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/tomcat-docs.xsl,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- tomcat-docs.xsl   3 Jun 2003 20:32:55 -   1.4
  +++ tomcat-docs.xsl   4 Jun 2003 21:57:35 -   1.5
  @@ -22,6 +22,7 @@
 
 
 
  +  
   
 
 
  @@ -410,6 +411,12 @@
   
 
   
  +  
  +
  +  
  +  
  +  
  +  
 
   
 
  
  
  

-
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 ApplicationFilterConfig.java

[jfarcand]

jfarcand2003/06/04 14:18:19

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterConfig.java
  Log:
  Add caching mechanism to improve performance. Instead of creating a Method object 
each
  time the filter/servlet is invoked, use the cached object previously created.
  
  Note: this apply only when the security manager is turned on.
  
  Revision  ChangesPath
  1.6   +7 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterConfig.java
  
  Index: ApplicationFilterConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterConfig.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- ApplicationFilterConfig.java  20 Mar 2003 23:31:47 -  1.5
  +++ ApplicationFilterConfig.java  4 Jun 2003 21:18:18 -   1.6
  @@ -295,7 +295,8 @@
if( System.getSecurityManager() != null) {
   try{
   SecurityUtil.doAsPrivilege("destroy",
  -   filter);  
  +   filter); 
  +SecurityUtil.remove(filter);
   } catch(java.lang.Exception ex){
   log.error("ApplicationFilterConfig.doAsPrivilege", ex);
   }
  @@ -337,6 +338,7 @@
   try{
   SecurityUtil.doAsPrivilege("destroy",
  filter);  
  +SecurityUtil.remove(filter);
   } catch(java.lang.Exception ex){
   log.error("ApplicationFilterConfig.doAsPrivilege", ex);
   }
  
  
  

-
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 StandardWrapper.java

[jfarcand]

jfarcand2003/06/04 14:17:13

  Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
  Log:
  Add caching mechanism to improve performance. Instead of creating a Method object 
each
  time the filter/servlet is invoked, use the cached object previously created.
  
  Note: this apply only when the security manager is turned on.
  
  Revision  ChangesPath
  1.28  +6 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
  
  Index: StandardWrapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- StandardWrapper.java  15 May 2003 20:49:05 -  1.27
  +++ StandardWrapper.java  4 Jun 2003 21:17:12 -   1.28
  @@ -1254,6 +1254,7 @@
   if( System.getSecurityManager() != null) {
   SecurityUtil.doAsPrivilege("destroy",
  instance);
  +SecurityUtil.remove(instance);   
   } else {
   instance.destroy();
   }
  @@ -1297,6 +1298,7 @@
   if( System.getSecurityManager() != null) {
   SecurityUtil.doAsPrivilege("destroy",
  ((Servlet) instancePool.pop()));
  +SecurityUtil.remove(instance);   
   } else {
   ((Servlet) instancePool.pop()).destroy();
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security SecurityUtil.java

[jfarcand]

jfarcand2003/06/04 14:15:39

  Modified:catalina/src/share/org/apache/catalina/security
SecurityUtil.java
  Log:
  Add caching mechanism to improve performance. Instead of creating a Method object 
each time the filter/servlet is invoked, use the cached object previously created.
  
  Note: this apply only when the security manager is turned on.
  
  Revision  ChangesPath
  1.4   +137 -16   
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityUtil.java
  
  Index: SecurityUtil.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityUtil.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- SecurityUtil.java 21 Oct 2002 14:22:54 -  1.3
  +++ SecurityUtil.java 4 Jun 2003 21:15:39 -   1.4
  @@ -62,6 +62,7 @@
   import java.io.IOException;
   import java.lang.reflect.Method;
   import java.lang.reflect.InvocationTargetException;
  +import java.util.HashMap;
   import java.security.AccessController;
   import java.security.Principal;
   import java.security.PrivilegedActionException;
  @@ -73,6 +74,8 @@
   import javax.servlet.ServletException;
   import javax.servlet.UnavailableException;
   
  +import org.apache.tomcat.util.buf.MessageBytes;
  +
   import org.apache.catalina.util.StringManager;
   
   /**
  @@ -88,6 +91,21 @@
   
   public final class SecurityUtil{
   
  +private final static int INIT= 0;
  +private final static int SERVICE = 1;
  +private final static int DOFILTER = 1;
  +private final static int DESTROY = 2;
  +
  +private final static String INIT_METHOD = "init";
  +private final static String DOFILTER_METHOD = "doFilter";
  +private final static String SERVICE_METHOD = "service";
  +private final static String DESTROY_METHOD = "destroy";
  +   
  +/**
  + * Cache every object for which we are creating method on it.
  + */
  +private static HashMap objectCache = new HashMap();
  +
   private static org.apache.commons.logging.Log log=
   org.apache.commons.logging.LogFactory.getLog( SecurityUtil.class );
   
  @@ -137,7 +155,7 @@
* @param methodName the method to apply the security restriction
* @param targetObject the Servlet on which the method will be 
called.
* @param targetType Class array used to instanciate a 
Method object.
  - * @param targetObject Object array contains the runtime 
parameters instance.
  + * @param targetArgumentst Object array contains the runtime 
parameters instance.
* @param principal the Principal to which the security privilege 
apply..
*/
   public static void doAsPrivilege(final String methodName, 
  @@ -145,8 +163,25 @@
final Class[] targetType,
final Object[] targetArguments,
Principal principal) throws 
java.lang.Exception{
  -   final Method method = targetObject.getClass().getMethod(methodName, 
targetType);   
  -   execute(method, targetObject, targetArguments, principal);
  +Method method = null;
  +Method[] methodsCache = null;
  +if(objectCache.containsKey(targetObject)){
  +methodsCache = (Method[])objectCache.get(targetObject);
  +method = findMethod(methodsCache, methodName);
  +if (method == null){
  +method = createMethodAndCacheIt(methodsCache,
  +methodName,
  +targetObject,
  +targetType);
  +}
  +} else {
  +method = createMethodAndCacheIt(methodsCache,
  +methodName,
  +targetObject,
  +targetType); 
  +}
  +
  +execute(method, targetObject, targetArguments, principal);
   }

   
  @@ -169,13 +204,32 @@
*
* @param methodName the method to apply the security restriction
* @param targetObject the Filter on which the method will be 
called.
  + * @param targetType Class array used to instanciate a 
Method object.
  + * @param targetArgumentst Object array contains the runtime 
parameters instance.
*/
   public static void doAsPrivilege(final String methodName, 
final Filter targetObject, 
final Class[] targetType,
final Object[] targetArguments) throws 
java.lang.Exception{
  -   final Method method = targetObject.getClass().getMethod(methodName, 
target

DO NOT REPLY [Bug 19145] - http to https redirect fails on non-standard ports

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=19145

http to https redirect fails on non-standard ports





--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 20:49 ---
Here is the response from telnet...

HTTP/1.1 302 Moved Temporarily
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Location: https://localhost:8443/hello1/greeting
Content-Type: text/plain
Content-Length: 0
Date: Wed, 04 Jun 2003 20:02:25 GMT
Server: Apache Coyote/1.0

...but I don't think that problem is with the initial redirect.

When the initial redirect happens in IE, I am prompted to accept the self-
signed certificate that I created for development.  The problem happens after 
the subsequent redirect to the FORM-style authentication login page...

Here is a little more background...

The resource that I'm requesting is configured to be CONFIDENTIAL and require 
(FORM-based) authentication.  So this is the request/response story-board that 
I would expect...

1a) Request: http://localhost:8080/hello1/greeting
1b) Response: 302, https://localhost:8443/hello1/greeting
2a) Request: https://localhost:8443/hello1/greeting
2b) Response: 302, https://localhost:8443/hello1/login.jsp
3a) Request: https://localhost:8443/hello1/login.jsp
3b) Response: 200 https://localhost:8443/hello1/login.jsp

I am speculating about steps 2b, 3a, and 3b because I am not sure how to go 
about snooping HTTPS requests.  (I tried using SSH a la PuTTY, but I couldn't 
get it to work.)

It works if I disable either the auth-constraint or the transport-constraint 
(thus changing the story-board).  It also works if I enter into the original 
story-board at 2a instead of 1a when both the auth-constraint and transport-
constraint are enabled.

It also works fine in IE if I use BASIC authentication instead of FORM 
authentication.

It looks like the problem happens when IE receives two subsequent 302 
responses.  In the case of the second 302 response, the port specified in the 
response is not used by IE in the subsequent request; it uses the default port 
for the protocol.  In other words, I suspect that Internet Explorer isn't using 
the port specified in 2b in its request of 3a, which would explain why having 
the second Coyote connector on port 443 allowed Internet Explorer to work.  

I should also add that I downloaded Mozilla Firebird and it was successfully 
redirected to the correct page.  It definitely looks to be an Internet Explorer 
related bug.  :-(

Thanks for your help, Remy.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [5.0] Commons dependencies

[Shapira, Yoav]

Howdy,

>> The Commons web pages have some notes for doing Commons releases at:
>>
>>   http://jakarta.apache.org/commons/releases.html
>
>Despite the fact that they're flagged as "beta", IMHO the instructions
here
>are better:
>
>http://jakarta.apache.org/commons/releases/

Excellent: thank you for posting the link.  I will look at both sets of
instructions (and give feedback if I run into anything).

First, I'm waiting for my jakarta.apache.org account to be setup and
jakarta-site(2) commit privileges.

Thanks,

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Commons dependencies

[Martin Cooper]

"Craig R. McClanahan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
>
> On Wed, 4 Jun 2003, Shapira, Yoav wrote:
>
> > Date: Wed, 4 Jun 2003 09:05:22 -0400
> > From: "Shapira, Yoav" <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: Tomcat Developers List <[EMAIL PROTECTED]>
> > Subject: RE: [5.0] Commons dependencies
> >
> >
> > Howdy,
> >
> > >>>- modeler: Basis for Tomcat 5 JMX features, with a lot of new
> > >>>impressively efficient functionality since release 1.0; again, a
> > >>>critical component [Costin (do you have enough time to continue being
> > >>>the RM of that component ?)]
> > >>
> > >>
> > >> I have very little free time - if anyone could do the release it
> > would be
> > >> great. There are no changes from M1 - I'll check bugzilla to see what
> > >> remains to be done.
> > >
> > >Ok, I undertsand; too bad :-(
> > >Any volunteers ? (again, this is a critical item)
> >
> > What needs to be done?  I haven't worked with modeler itself, nor been a
> > release manager before, but I'm willing to give it a shot...
> >
>
> The Commons web pages have some notes for doing Commons releases at:
>
>   http://jakarta.apache.org/commons/releases.html

Despite the fact that they're flagged as "beta", IMHO the instructions here
are better:

http://jakarta.apache.org/commons/releases/

--
Martin Cooper


>
> > Yoav Shapira
> >
>
> Craig




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] fileupload 1.0 RC 1 API breakage

[Joe Germuska]

At 7:38 -0500 6/4/03, Glenn Nielsen wrote:
Was this really necessary?  The email below went to both the commons-dev and
tomcat -dev lists.  If Remy was pointing the finger at anyone, it was at his
fellow Tomcat Developers.  Thats how I interpreted it.
Martin has been busting his tail trying to get FileUpload released so 
that Struts can make a full 1.1 release, and I'm sure he's just a 
little frustrated that other projects which have a dependency on the 
library aren't participating very much in the bug cleanup, or, 
apparently, the commons-dev mailing list where this was discussed 
thoroughly before the change happened.  In fact, Martin was reluctant 
to remove the deprecated methods completely, and other developers 
here on commons-dev pointed out that there is no guarantee of API in 
unreleased software.

When I read the message from Remy, I read it as a jab at FileUpload. 
And since Martin has basically been a one-man FileUpload team for 
several weeks (while being busy in his real life), he took it 
personally.  Rereading Remy's message, I can see why Glenn read it as 
being "spoken to" the tomcat-dev list, with commons-dev as more of a 
'cc'.  But that's not how I read it originally.

I'd think at least one committer on any major open-source project 
should be committed to monitoring the status of each library that 
project depends on -- if someone had been doing that, this would not 
have been a surprise.

Just a bystander...
Joe
--
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time." 
	--Jaron Lanier

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [5.0] Commons dependencies

[Shapira, Yoav]

Howdy,

>The Commons web pages have some notes for doing Commons releases at:
>
>  http://jakarta.apache.org/commons/releases.html

Those instructions seem clear enough.  I volunteer to be the release
manager for modeler 1.0 ;)

There seem to be no bugs open for modeler in Bugzilla ("Zarro Boogs
found" ;)), so the next step is a release vote it appears...

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] fileupload 1.0 RC 1 API breakage

[David Graham]

FileUpload.setRepositoryPath(String) and FileItem(String) were removed from 
the fileupload RC 1 release, which breaks the Tomcat 4.1.x and 5.0.x build. 
The first method has no apparent replacement (but I didn't try to dig 
around).

This is clearly an unacceptable situation from the Tomcat perspective :-( 
I'm hoping there can be positive solutions to the problem ...
There is absolutely no API guarantee between beta releases.  Martin has 
posted several messages to commons-dev about the changes and has apparently 
even posted a patch for Tomcat.  Instead of complaining about one broken 
build you should be thanking Martin for being the sole developer on 
FileUpload.

David

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves mbeans-descriptors.xml ExtendedAccessLogValve.java AccessLogValve.java

[funkman]

funkman 2003/06/04 09:58:21

  Modified:catalina/src/share/org/apache/catalina/valves
mbeans-descriptors.xml ExtendedAccessLogValve.java
AccessLogValve.java
  Log:
  Fix bz - 20380 AccessLogValve incorrectly calculates timezone
  Enc bz - 16374 Date in file name configurable
  Enc bz - 16400 Allow logging to be conditional
  
  Revision  ChangesPath
  1.3   +13 -1 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/mbeans-descriptors.xml
  
  Index: mbeans-descriptors.xml
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/mbeans-descriptors.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- mbeans-descriptors.xml1 Jun 2003 20:57:00 -   1.2
  +++ mbeans-descriptors.xml4 Jun 2003 16:58:21 -   1.3
  @@ -38,13 +38,21 @@
  type="boolean"/>
   
   
   
   
  +
  +
  +
  +
 
   
 
  +
  +
   
   %r - First line of the request
* %s - HTTP status code of the response
  - * %S - User session ID 
  + * %S - User session ID
* %t - Date and time, in Common Log Format format
* %u - Remote user that was authenticated
* %U - Requested URL path
* %v - Local server name
* %D - Time taken to process the request, in millis
  -  * 
  + * %T - Time taken to process the request, in seconds
  + * 
* In addition, the caller can specify one of the following aliases for
* commonly utilized patterns:
* 
* common - %h %l %u %t "%r" %s %b
  - * combined - 
  + * combined -
*   %h %l %u %t "%r" %s %b "%{Referer}i" "%{User-Agent}i"
* 
*
  @@ -140,6 +142,13 @@
* 
* 
*
  + * 
  + * Conditional logging is also supported. This can be done with the
  + * condition property.
  + * If the value returned from ServletRequest.getAttribute(condition)
  + * yields a non-null value. The logging will be skipped.
  + * 
  + *
* @author Craig R. McClanahan
* @author Jason Brittain
* @version $Revision$ $Date$
  @@ -227,12 +236,12 @@
* The prefix that is added to log file filenames.
*/
   private String prefix = "access_log.";
  -
  +
   
   /**
* Should we rotate our log file? Default is true (like old behavior)
*/
  -private boolean rotatable = true;
  +private boolean rotatable = true;
   
   
   /**
  @@ -282,6 +291,12 @@
   
   
   /**
  + * Time taken formatter for 3 decimal places.
  + */
  + private DecimalFormat timeTakenFormatter = null;
  +
  +
  +/**
* A date formatter to format a Date into a year string in the format
* "".
*/
  @@ -326,6 +341,17 @@
   private long rotationLastChecked = 0L;
   
   
  +/**
  + * Are we doing conditional logging. default false.
  + */
  +private String condition = null;
  +
  +
  +/**
  + * Date format to place in log file name. Use at your own risk!
  + */
  +private String fileDateFormat = null;
  +
   // - Properties
   
   
  @@ -425,21 +451,21 @@
* Should we rotate the logs
*/
   public boolean isRotatable() {
  - 
  +
   return rotatable;
  - 
  +
   }
  - 
  - 
  +
  +
   /**
* Set the value is we should we rotate the logs
*
* @param rotatable true is we should rotate.
*/
   public void setRotatable(boolean rotatable) {
  - 
  +
   this.rotatable = rotatable;
  - 
  +
   }
   
   
  @@ -487,6 +513,45 @@
   }
   
   
  +/**
  + * Return whether the attribute name to look for when
  + * performing conditional loggging. If null, every
  + * request is logged.
  + */
  +public String getCondition() {
  +
  +return condition;
  +
  +}
  +
  +
  +/**
  + * Set the ServletRequest.attribute to look for to perform
  + * conditional logging. Set to null to log everything.
  + *
  + * @param condition Set to null to log everything
  + */
  +public void setCondition(String condition) {
  +
  +this.condition = condition;
  +
  +}
  +
  +/**
  + *  Return the date format date based log rotation.
  + */
  +public String getFileDateFormat() {
  +return fileDateFormat;
  +}
  +
  +
  +/**
  + *  Set the date format date based log rotation.
  + */
  +public void setFileDateFormat(String fileDateFormat) {
  +this.fileDateFormat =  fileDateFormat;
  +}
  +
   // - Public Methods
   
   
  @@ -514,6 +579,12 @@
   long t2=System.currentTimeMillis();
   long time=t2-t1;
   
  +if (condition!=null &&
  +null!=request.getRequest().getAt

Re: [5.0] fileupload 1.0 RC 1 API breakage

[David Graham]

One last note: IMO, as a rule (and esp in the commons), you should make 
every effort to avoid breaking the API between a beta and a final.
FileUpload did not go final, if went to RC1.  Changes between RCs and final 
could be considered inappropriate but not from beta to RC.

See the Release Types > Beta Releases section here:
http://jakarta.apache.org/commons/versioning.html
David

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [5.0] Commons dependencies

[Craig R. McClanahan]

On Wed, 4 Jun 2003, Shapira, Yoav wrote:

> Date: Wed, 4 Jun 2003 09:05:22 -0400
> From: "Shapira, Yoav" <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: RE: [5.0] Commons dependencies
>
>
> Howdy,
>
> >>>- modeler: Basis for Tomcat 5 JMX features, with a lot of new
> >>>impressively efficient functionality since release 1.0; again, a
> >>>critical component [Costin (do you have enough time to continue being
> >>>the RM of that component ?)]
> >>
> >>
> >> I have very little free time - if anyone could do the release it
> would be
> >> great. There are no changes from M1 - I'll check bugzilla to see what
> >> remains to be done.
> >
> >Ok, I undertsand; too bad :-(
> >Any volunteers ? (again, this is a critical item)
>
> What needs to be done?  I haven't worked with modeler itself, nor been a
> release manager before, but I'm willing to give it a shot...
>

The Commons web pages have some notes for doing Commons releases at:

  http://jakarta.apache.org/commons/releases.html

> Yoav Shapira
>

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

[remm]

remm2003/06/04 11:15:19

  Modified:webapps/docs changelog.xml
  Log:
  - Add a changelog for TC 5.0.3-dev.
  
  Revision  ChangesPath
  1.2   +362 -4jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- changelog.xml 3 Jun 2003 20:32:55 -   1.1
  +++ changelog.xml 4 Jun 2003 18:15:19 -   1.2
  @@ -13,39 +13,397 @@
   
   
   
  -
  +
   
 
   
  +
  +
  +  
  +  Upgrade to commons-fileupload 1.0 RC 1, submitted by Martin Cooper 
  +  (billbarker)
  +  
  +  
  +  Fix the netbuild (remm)
  +  
  +  
  +  Specification schema changes, submitted by Mark Roth (kinman)
  +  
  +  
  +  Many tag handling specification clarifications, submitted by Mark Roth 
  +  (kinman)
  +  
  +
  +
  +
 
   
 
   
   
  +
  +  
  +  W3C Extended Log File Format support (funkman)
  +  
  +  
  +  Refactor FORM using a forward, based on the patch by Jeff Tulley (remm)
  +  
  +  
  +  Properly set the wrapped request dispatcher state, submitted by Jan Luehe
  +  (remm)
  +  
  +  
  +  Have all contexts inherit Embedded's logger (luehe)
  +  
  +  
  +  Add logging of unexpected exceptions occuring during reference resolution
  +  (remm)
  +  
  +  
  +  unbindClassLoader was thorwing NPE when newly added context 
  +  was removed (amyroh)
  +  
  +  
  +  Fix Gump failure by copying the Ant JAR manually (jfarcand)
  +  
  +  
  +  Update confidential HTTPS redirection without using an actual URL,
  +  which has a hard JSSE dependency (remm)
  +  
 
 Include updated clustering code (fhanik, remm)
 
  +  
  +  Remove useless typecasts in the main processing pipeline, and make
  +  critical methods final, to enforce the Catalina design pattern (remm)
  +  
  +  
  +  Request dispatcher optimizations, based on the belief that wrapping 
  +  is only needed (if at all) for the special attributes (remm)
  +  
  +  
  +  Major filter mapping optimization, using simple String region matching,
  +  as well as synchronization removal (remm)
  +  
  +  
  +  Add new callback on the container interface to process any background
  +  task the container may have (backgroundProcess), as well as a new
  +  backgroundProcessor attribute (default value: 10s for the engine
  +  container, and -1 for all others, so that only the engine has an
  +  associated thread) (remm)
  +  
 
 Refactor application reloading, deployment handling and session 
 expiration to be able to use a single thread per Catalina engine, opposed
 to one thread per feature per webapp or virtual host; this should save
  -  resources and make Tomcat suitable for large scale webhosting (remm)
  +  resources and make Tomcat suitable for large scale web hosting; 
  +  individual containers can still "own" their own reloading thread 
  +  if they need to (remm)
 
  +  
  +  Fix a bug where the context is not registered again in JMX after a 
  +  stop/start, which would break mapping (remm)
  +  
  +  
  +  Implement context reloading as stop, followed by start, in an attempt
  +  to avoid code duplication and clear user confusion on what a reload 
  +  exactly does (remm)
  +  
  +  
  +  Pass the request URI as a parameter to the request dispatcher, as this 
  +  avoids rebuilding it (remm)
  +  
  +  
  +  Unify the way we shutdown the server, and fix a classloading problem 
  +  when the digester file are under common/lib instead of server/lib 
  +  (jfarcand)
  +  
  +  
  +  Do not register a StandardContext instance when the context is stopped 
  +  (undeployed) (remm)
  +  
  +  
  +  Remove the old Catalina mapper (remm)
  +  
  +  
  +  Swicth to the "new" mapper for request dispatcher mapping (remm)
  +  
  +  
  +  20018: ErrorPage directive doesn't work for http error codes 
  +  (400,500,..) (remm)
  +  
 
  -  Request dispatcher optimizations (remm)
  +  Remove synchronized block on the request dispatcher wrapper request,
  +  submitted by Remy Maucherat (jfarcand)
 
  +  
  +  Allow the getAttribute() method access to the wrapped request object 
  +  (like setAttribute/removeAttribute) (jfarcand)
  +  
 
  -  Upgrade to commons-fileupload 1.0 RC 1 (remm)
  +  Add the rest of missing attributes for j2eeType=WebModule and Servlet
  +  (amyroh)
   

cvs commit: jakarta-tomcat-5 build.properties.default

[remm]

remm2003/06/04 11:14:27

  Modified:.build.properties.default
  Log:
  - The nighlies rool out to quickly to link to them :-(
  
  Revision  ChangesPath
  1.92  +3 -3  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.91
  retrieving revision 1.92
  diff -u -r1.91 -r1.92
  --- build.properties.default  4 Jun 2003 08:20:43 -   1.91
  +++ build.properties.default  4 Jun 2003 18:14:26 -   1.92
  @@ -163,8 +163,8 @@
   # - Commons FileUpload, version 1.0-20030531 or later -
   commons-fileupload.home=${base.path}/commons-fileupload-1.0-rc1
   commons-fileupload.lib=${commons-fileupload.home}
  -commons-fileupload.jar=${commons-fileupload.lib}/commons-fileupload-1.0-dev.jar
  
-commons-fileupload.loc=http://www.apache.org/dist/jakarta/commons/nightly/fileupload/commons-fileupload-20030531.tar.gz
  +commons-fileupload.jar=${commons-fileupload.lib}/commons-fileupload-1.0-rc1.jar
  
+commons-fileupload.loc=http://www.apache.org/dist/jakarta/commons/fileupload/commons-fileupload-1.0-rc1.tar.gz
   
   
   # - Java Management Extensions (JMX), JMX RI 1.0.1 or later or MX4J 1.1 or 
later -
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] fileupload 1.0 RC 1 API breakage

[Remy Maucherat]

Glenn Nielsen wrote:
Martin Cooper wrote:

Get your own act together, Tomcat developers, before you start pointing
the finger at those of us who really try hard to maintain compatibility
across Jakarta projects.
Was this really necessary?  The email below went to both the commons-dev 
and
tomcat -dev lists.  If Remy was pointing the finger at anyone, it was at 
his
fellow Tomcat Developers.  Thats how I interpreted it.

We (tomcat devs) will fix use of FileUpload in Tomcat and move on, no 
big deal.
Sorry for the tone of the original email; I wasn't upset anyway, it was 
just a quickly drafted email this morning before leaving to work (having 
no access to my Apache email during the day).

BTW, I am not subscribed to commons-dev. I saw about the new Disk* 
classes browsing archives, but didn't do a parallel.

One last note: IMO, as a rule (and esp in the commons), you should make 
every effort to avoid breaking the API between a beta and a final.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Commons dependencies

[Remy Maucherat]

Jan Luehe wrote:
Remy & others,


Here's the list of the components which will need to be released as
stable before Tomcat 5.0 gets stable. I'm associating a proposed "owner"
for the component, based on past interactions with the components.
- el: Core JSP 2.0 feature; this is a critical component, and needs to
get released simultaneaously with Tomcat 5; I think a RM is needed for
that component [Kin-Man, Jan, Craig ?]


I'll take this one. What exactly does being a RM involve?
In order:
- post a release plan (and have people vote)
- tag and release a beta
- fix BZ items
- propose and vote for a final
- tag and release a final
There are plenty of examples on how to package a release in commons, 
since there are so many components having already been released.

If everything else fails, do what people usually do: ask Craig :-D

commons-el currently has version 1.0, and it's been tagged with
TOMCAT_5_0_2.
Well, as far as I am concerned, commons-el 1.0 does not exist yet ;-)

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20463] - Jasper2 ant task generate invalid package name

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20463

Jasper2 ant task generate invalid package name

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 17:26 ---
This is a known problem and has been fixed in Tomcat 5.  The obvious workaround
is not to use paths that contain directories that are not legal Java identifier
names.  Since the fix in TC5 touches a lot files, not sure if the fix should be
back-ported to TC4, which is supposedly a stable release.  Resolved as WONTFIX,
unless someone else is willing to do the port.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 14281] - AccessLogValve doesn't export BytesSent info from servlets...

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14281

AccessLogValve doesn't export BytesSent info from servlets...

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 17:13 ---
This appears to be working fine for me. I think this was already fixed.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16400] - Allow AccessLogValve to ignore (not log) requests for particular URIs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=16400

Allow AccessLogValve to ignore (not log) requests for particular URIs

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 17:03 ---
done in 5, if stable - might be ported back to tomcat 4.1

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16374] - Make access log filename date format configurable in AccessLogValve

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=16374

Make access log filename date format configurable in AccessLogValve

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 17:02 ---
done in tomcat5. If stable in 5, might backport to 4.1

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20380] - AccessLogValve incorrectly calculates timezone

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20380

AccessLogValve incorrectly calculates timezone

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 17:01 ---
Fixed in tomcat5. If ok - will eventually backport to 4.1

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20263] - Tomcat 5.0.2 service does not survive logoff

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20263

Tomcat 5.0.2 service does not survive logoff





--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 16:43 ---
I will do a quick test and apply the change if successful. I also had a problem
that the service set as automatic wasn't started on startup.

BTW, does it mean that a Tomcat run in "GUI mode" with the systray icon will
also survive a logoff ? Otherwise, there won't been any way to kill it :-(

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Change docBase without losing requests?

[Matt Zimmerman]

On Tue, Jun 03, 2003 at 07:57:41PM +0200, Remy Maucherat wrote:

> Well, if you look at the (recent) archives for tomcat-dev, you'll see I'm
> working on a pretty extensive refactoring of the deployer in TC 5.  That
> should provide the features you mention. You can comment or contribute if
> you wish, of course.

Great, thanks for pointing me to this.  I'm pulling down TC 5 CVS now.

-- 
 - mdz

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Commons dependencies

[Jan Luehe]

Remy & others,

> Here's the list of the components which will need to be released as
> stable before Tomcat 5.0 gets stable. I'm associating a proposed "owner"
> for the component, based on past interactions with the components.
> 
> - el: Core JSP 2.0 feature; this is a critical component, and needs to
> get released simultaneaously with Tomcat 5; I think a RM is needed for
> that component [Kin-Man, Jan, Craig ?]

I'll take this one. What exactly does being a RM involve?
commons-el currently has version 1.0, and it's been tagged with
TOMCAT_5_0_2.


Jan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Commons dependencies

[Jean-Francois Arcand]

Remy Maucherat wrote:
Costin Manolache wrote:

Remy Maucherat wrote:


- modeler: Basis for Tomcat 5 JMX features, with a lot of new
impressively efficient functionality since release 1.0; again, a
critical component [Costin (do you have enough time to continue being
the RM of that component ?)]


I have very little free time - if anyone could do the release it would be
great. There are no changes from M1 - I'll check bugzilla to see what
remains to be done.


Ok, I undertsand; too bad :-(
Any volunteers ? (again, this is a critical item)
Yes, I can but I have very little experience . If you show me how or 
point me to some documentation, I can do it.

-- Jeanfrancois

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]

DO NOT REPLY [Bug 20483] New: - Visualization of Query using JSTL

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20483

Visualization of Query using JSTL

   Summary: Visualization of Query using JSTL
   Product: Tomcat 4
   Version: 4.1.24
  Platform: PC
   URL: http://www.mycgiserver.com/~fernans
OS/Version: Other
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When DBTags is used (of the package JSTL) to do a consultation, if this doesn't 
have registrations the code it is come back complete SQL

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

mod_jk 1.2.4 release Monday 6/9

[Glenn Nielsen]

So far there have been no problems reported with mod_jk 1.2.4 except for
one minor documentation typo which has been fixed.
If I don't see any problems reported from further testing before Monday
I will make the mod_jk 1.2.4 source release and announcement.
Thanks for all the help testing.

Once the release is announced binaries can be and installed in
the release directory.
Regards,

Glenn

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20476] - tomcat.exe does nothing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20476

tomcat.exe does nothing

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 14:50 ---
This is not the same exe wrapper as before (this one is procrun from the
commons-daemon project), and will be documented eventually. You can find some
instructions there in the meantime.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util CookieTools.java DateTool.java MimeHeaderField.java

[marcsaeg]

marcsaeg2003/06/04 07:25:51

  Modified:src/share/org/apache/tomcat/util Tag: tomcat_32
CookieTools.java DateTool.java MimeHeaderField.java
  Log:
  Fixed a thread synchronization bug that appears in MimeHeaderField.parseDate().
  The SimpleDateFormats in DateTool where exposed as public members that parseDate()
  reference directly with no synchronization.  The SimpleDateFormat methods are
  not thread safe.
  
  Tomcat 3.2.x is no longer being officially maintained.  There will be no
  more official releases of Tomcat 3.2.x.  To get these fixes you will need
  to build Tomcat from source.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.7.2.3   +5 -9  
jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/CookieTools.java
  
  Index: CookieTools.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/CookieTools.java,v
  retrieving revision 1.7.2.2
  retrieving revision 1.7.2.3
  diff -u -r1.7.2.2 -r1.7.2.3
  --- CookieTools.java  10 Nov 2000 23:37:25 -  1.7.2.2
  +++ CookieTools.java  4 Jun 2003 14:25:50 -   1.7.2.3
  @@ -135,13 +135,9 @@
if (version == 0) {
buf.append (";Expires=");
   if (cookie.getMaxAge() == 0)
  -DateTool.oldCookieFormat.format(new Date(1), buf,
  -new FieldPosition(0));
  +DateTool.formatOldCookie(new Date(1), buf);
   else
  -DateTool.oldCookieFormat.format
  -(new Date( System.currentTimeMillis() +
  -   cookie.getMaxAge() *1000L), buf,
  - new FieldPosition(0));
  +DateTool.formatOldCookie(new Date( System.currentTimeMillis() + 
cookie.getMaxAge() *1000L), buf);
} else {
buf.append (";Max-Age=");
buf.append (cookie.getMaxAge());
  
  
  
  1.2.2.2   +46 -17
jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/DateTool.java
  
  Index: DateTool.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/DateTool.java,v
  retrieving revision 1.2.2.1
  retrieving revision 1.2.2.2
  diff -u -r1.2.2.1 -r1.2.2.2
  --- DateTool.java 30 Jul 2001 00:57:34 -  1.2.2.1
  +++ DateTool.java 4 Jun 2003 14:25:50 -   1.2.2.2
  @@ -110,38 +110,67 @@
   
   /** DateFormat to be used to format dates
*/
  -public final static SimpleDateFormat rfc1123Format =
  - new SimpleDateFormat(RFC1123_PATTERN, LOCALE_US);
  +private final static SimpleDateFormat rfc1123Format = new 
SimpleDateFormat(RFC1123_PATTERN, LOCALE_US);
   
   /** DateFormat to be used to format old netscape cookies
*/
  -public final static SimpleDateFormat oldCookieFormat =
  - new SimpleDateFormat(OLD_COOKIE_PATTERN, LOCALE_US);
  +private final static SimpleDateFormat oldCookieFormat = new 
SimpleDateFormat(OLD_COOKIE_PATTERN, LOCALE_US);
   
  -public final static SimpleDateFormat rfc1036Format =
  - new SimpleDateFormat(rfc1036Pattern, LOCALE_US);
  +private final static SimpleDateFormat rfc1036Format = new 
SimpleDateFormat(rfc1036Pattern, LOCALE_US);
   
  -public final static SimpleDateFormat asctimeFormat =
  - new SimpleDateFormat(asctimePattern, LOCALE_US);
  +private final static SimpleDateFormat asctimeFormat = new 
SimpleDateFormat(asctimePattern, LOCALE_US);
   
   static {
  - rfc1123Format.setTimeZone(GMT_ZONE);
  - oldCookieFormat.setTimeZone(GMT_ZONE);
  - rfc1036Format.setTimeZone(GMT_ZONE);
  - asctimeFormat.setTimeZone(GMT_ZONE);
  +rfc1123Format.setTimeZone(GMT_ZONE);
  +oldCookieFormat.setTimeZone(GMT_ZONE);
  +rfc1036Format.setTimeZone(GMT_ZONE);
  +asctimeFormat.setTimeZone(GMT_ZONE);
   }
   
   private static String rfc1123DS;
   private static long   rfc1123Sec;
   
  +
  +public static Date rfc1123Parse(String dateString) throws ParseException
  +{
  +synchronized(rfc1123Format){
  +return rfc1123Format.parse(dateString);
  +}
  +}
  +
  +public static Date rfc1036Parse(String dateString) throws ParseException
  +{
  +synchronized(rfc1036Format){
  +return rfc1036Format.parse(dateString);
  +}
  +}
  +
  +public static Date asctimeParse(String dateString) throws ParseException
  +{
  +synchronized(asctimeFormat){
  +return asctimeFormat.parse(dateString);
  +}
  +}
  +
  +public static void formatOldCookie(Date d, StringBuffer buf)
  +{
  +synchronized(oldCookieFormat){
  +