Re: [BUG] jk2 jni doesn't work

[jean-frederic clere]

Mladen Turk wrote:
> This is the classloader problem.
> 
> Think that Bill Baker is solving this, but until then add the
> commons-logging.jar to the loaded classes when started inprocess:
> 
> OPT=-Djava.class.path=${TOMCAT_HOME}\bin\tomcat-jni.jar;${TOMCAT_HOME}\s
> erver\lib\commons-logging.jar

I do not like this work-around: we will have end with a huge classpath.

> 
> Adding commons-logging to the classpath solves the JNI problem.
> 
> Bill, when can ve expect this will get solved?
> 
> 
> 
> 
>>java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
>>  at org.apache.jk.apr.AprImpl.(AprImpl.java:348)
>>java.lang.NoClassDefFoundError
>>
>>
> 
> 
> MT.
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java

[jean-frederic clere]

Bob Herrmann wrote:
> On Wed, 2002-09-18 at 13:58, Remy Maucherat wrote:
> 
>>Remy Maucherat wrote:
>>
>>>[EMAIL PROTECTED] wrote:
>>>
>>>
bobh2002/09/18 09:44:35

  Modified:.gump.xml
   coyote/src/java/org/apache/coyote Request.java
   http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  - This associates the socket with the Request.  This is so the
  CertificatesValve.verify() can tell where (which socket) the Request
  is comeing from.  Without this association, CertificatesValve.verify()
  returns with no SSL Handshake.
  - this change is in part based on feed back from; Vivek N. Yingxian
  Wang (JSSE), Craig M., Qingqing Ouyang
>>>
>>>
>>>-1 (ie, revert this).
>>>
>>>The socket should already have been associated with the request, but as 
>>>a note. It is available, and accessible.
>>
>>Ok, I checked it, and the socket os not currently associated with the 
>>request (I thought it was). OTOH, you shouldn't add a field for socket 
>>in the request (native webservers don't have the notion of a Java 
>>socket). Instead, use one of the notes.
> 
> 
> Ok, 
>   - change Http11Processor to use a note
>   - change Request.java to it's original form
>   - change the CertificatesValve.verify()
> 
> Does that sound about right?

For me: yes.

> 
> Cheers,
> -bob
> 
> 
>>Remy
>>
>>
>>--
>>To unsubscribe, e-mail:   
>>For additional commands, e-mail: 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Bug in DateTool in tomcat connector util?

[Hugh J. L.]

Just viewed DateTool in CVS. Yes, "format" also has
thread problem and need fix. But, has "parse" been
fixed? I didn't see any change about it in v1.7.

--- Bill Barker <[EMAIL PROTECTED]> wrote:
> I just checked in a fix for the "format" side
> (setting the "Last-Modified"
> header).  This one is much harder to hit, but that
> doesn't mean that you
> can't.  The "parse" side (getting the
> "If-Modified-Since" header) has been
> fixed in the nightly for quite some time now.
> 
> - Original Message -
> From: "Hugh J. L." <[EMAIL PROTECTED]>
> To: "Tomcat Developers List"
> <[EMAIL PROTECTED]>
> Sent: Tuesday, September 17, 2002 7:12 PM
> Subject: Bug in DateTool in tomcat connector util?
> 
> 
> > Hi,
> >
> > I found a bug (?) when i was testing tomcat3.3
> using
> > MS web stress tool. I set up large amount of
> > concurrent requests for static files, each with
> header
> > If-Modified-Since which is newer than actual
> > last-modified-time of those requested files. I
> should
> > have got 304 response for ALL requests in this
> case,
> > however, i got many 304, a few 200, and even
> > NumberFormatException occasionally. This didn't
> happen
> > if i tested using only one client thread. I looked
> > into java.text.SimpleDateFormat and suspected it
> was
> > possibly a synchronization problem. Then I added
> > synchronization control to DateTool.parse(String,
> > DateFormat[]) as below and the problem was solved:
> >
> > synchronized(format[i]) {
> > date = format[i].parse(dateString);
> > }


__
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12795] - activation.jar in common/lib gives javax/activation/DataSource errors

[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=12795

activation.jar in common/lib gives javax/activation/DataSource errors





--- Additional Comments From [EMAIL PROTECTED]  2002-09-19 06:42 ---
There should be no difference in behavior between 4.1 and 4.0 regarding
activation.jar. If you have insights on what should be done to avoid the
problem, please let me know.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java

[remm]

remm2002/09/18 23:40:49

  Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  - Revert patch.
  
  Revision  ChangesPath
  1.36  +1 -3  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- Http11Processor.java  18 Sep 2002 16:44:35 -  1.35
  +++ Http11Processor.java  19 Sep 2002 06:40:49 -  1.36
  @@ -602,10 +602,8 @@
   http11 = true;
   http09 = false;
   contentDelimitation = false;
  -if (sslSupport != null) {
  +if (sslSupport != null)
   request.scheme().setString("https");
  -request.setSocket( socket );
  -}
   
   MessageBytes protocolMB = request.protocol();
   if (protocolMB.equals(Constants.HTTP_11)) {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Request.java

[remm]

remm2002/09/18 23:39:43

  Modified:coyote/src/java/org/apache/coyote Request.java
  Log:
  - Revert patch.
  
  Revision  ChangesPath
  1.15  +0 -16 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
  
  Index: Request.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- Request.java  18 Sep 2002 16:44:35 -  1.14
  +++ Request.java  19 Sep 2002 06:39:43 -  1.15
  @@ -73,8 +73,6 @@
   import org.apache.tomcat.util.http.ContentType;
   import org.apache.tomcat.util.http.Cookies;
   
  -import java.net.Socket;
  -
   /**
* This is a low-level, efficient representation of a server request. Most 
* fields are GC-free, expensive operations are delayed until the  user code 
  @@ -186,9 +184,6 @@
   
   private Response response;
   private ActionHook hook;
  -
  -private Socket socket;
  -
   // - Properties
   
   
  @@ -208,21 +203,10 @@
   return headers;
   }
   
  -/* Used to associate this Request with a socket.  Used later to do
  -   SSL related stuff. */
  -public Socket getSocket() {
  -return this.socket;
  -}
  -
  -public void setSocket(Socket socket) {
  -this.socket = socket;
  -}
  -
   
   public UDecoder getURLDecoder() {
   return urlDecoder;
   }
  -
   
   //  Request data 
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Fw: [BUG] jk2 jni doesn't work

[Bill Barker]

Erm, somehow the reply-to didn't take.

- Original Message -
From: "Bill Barker" <[EMAIL PROTECTED]>
To: "Mladen Turk" <[EMAIL PROTECTED]>
Sent: Wednesday, September 18, 2002 11:08 PM
Subject: Re: [BUG] jk2 jni doesn't work


>
> - Original Message -
> From: "Mladen Turk" <[EMAIL PROTECTED]>
> To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>
> Cc: "Bill Barker" <[EMAIL PROTECTED]>
> Sent: Wednesday, September 18, 2002 10:43 PM
> Subject: RE: [BUG] jk2 jni doesn't work
>
>
> > This is the classloader problem.
> >
> > Think that Bill Baker is solving this, but until then add the
> > commons-logging.jar to the loaded classes when started inprocess:
> >
> > OPT=-Djava.class.path=${TOMCAT_HOME}\bin\tomcat-jni.jar;${TOMCAT_HOME}\s
> > erver\lib\commons-logging.jar
> >
> > Adding commons-logging to the classpath solves the JNI problem.
> >
> > Bill, when can ve expect this will get solved?
> >
>
> Urm, it's really a separate issue.  Last week I converted some of the 3.3
> classes to using c-l, but trusted too much that if it compiles, then it
will
> run.  Since tonight I wanted to focus on the JSSE client-cert problem, I
> just patched the startup scripts so that the 3.3.2-dev nightly would still
> work.
>
> However, I have no problem taking a look at the Jk2 ClassLoader issue at
the
> same time that I try to work out why 3.3.2-dev broke.
>
> >
> >
> > >
> > > java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
> > > at org.apache.jk.apr.AprImpl.(AprImpl.java:348)
> > > java.lang.NoClassDefFoundError
> > >
> > >
> >
> > MT.
> >
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12387] - JSP Compilation errors: jars in WEB-INF/lib and classes in WEB-INF/classes not in classpath

[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=12387

JSP Compilation errors: jars in WEB-INF/lib and classes in WEB-INF/classes not in 
classpath

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-09-19 06:35 ---
*** Bug 12792 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12792] - login.jsp of admin webapp won't compile when tomcat is run as NT Service from D drive

[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=12792

login.jsp of admin webapp won't compile when tomcat is run as NT Service from D drive

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-09-19 06:35 ---


*** This bug has been marked as a duplicate of 12387 ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java

[Remy Maucherat]

Bill Barker wrote:
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 18, 2002 9:44 AM
> Subject: cvs commit:
> jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
> Http11Processor.java
> 
> 
> 
>>bobh2002/09/18 09:44:35
>>
>>  Modified:.gump.xml
>>   coyote/src/java/org/apache/coyote Request.java
>>   http11/src/java/org/apache/coyote/http11
>>Http11Processor.java
>>  Log:
>>  - This associates the socket with the Request.  This is so the
>>  CertificatesValve.verify() can tell where (which socket) the Request
>>  is comeing from.  Without this association, CertificatesValve.verify()
>>  returns with no SSL Handshake.
>>  - this change is in part based on feed back from; Vivek N. Yingxian
>>  Wang (JSSE), Craig M., Qingqing Ouyang
>>
> 
> 
> I'm -1 on this, since having a socket in the Request makes no sense for Jk2.
> CertificatesValve is only for use with the deprecated HttpConnector.  With
> Coyote, the SSL handling has moved to the connector (where it belonged in
> the first place).

I agree. I forgot this was done through a notification, and 99% of the 
code was already there. Thanks for adding the clientauth support and 
removing the need for hacks. I will revert the changes to 
Http11Processor and Request.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/conf workers2.properties

[mturk]

mturk   2002/09/18 23:28:24

  Modified:jk/conf  workers2.properties
  Log:
  Add the commons-logging.jar to the classpath. This is temporary workaround
  to enable channelJni until the classloader code gets fixed.
  
  Revision  ChangesPath
  1.16  +1 -1  jakarta-tomcat-connectors/jk/conf/workers2.properties
  
  Index: workers2.properties
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/conf/workers2.properties,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- workers2.properties   11 Jul 2002 11:40:48 -  1.15
  +++ workers2.properties   19 Sep 2002 06:28:24 -  1.16
  @@ -68,7 +68,7 @@
   [vm:]
   info=Parameters used to load a JVM in the server process
   #JVM=C:\jdk\jre\bin\hotspot\jvm.dll
  
-OPT=-Djava.class.path=${TOMCAT_HOME}/lib/tomcat-jni.jar;${TOMCAT_HOME}/lib/tomcat.jar
  
+OPT=-Djava.class.path=${TOMCAT_HOME}/lib/tomcat-jni.jar;${TOMCAT_HOME}/server/lib/commons-logging.jar
   OPT=-Dtomcat.home=${TOMCAT_HOME}
   OPT=-Dcatalina.home=${TOMCAT_HOME}
   OPT=-Xmx128M
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeansMBeanFactory.java

[Remy Maucherat]

Amy Roh wrote:
> MBeanFactory.createStandardContext() still throws 
> "java.lang.IllegalArgumentException: Document base .\webapps\newpath 
> does not exist or is not a readable directory" after recent change in 
> StandardContext.  Is there something else missing that is preventing 
> host.addChild(newContext) to work?

I do not understand the problem, or what is wrong. BTW, before the 
change, the context was never properly initialized.

The contexts which are in the host appbase will be automatically 
deployed, so I barely see a use case for that.

This is working fine for me in all useful cases, so I will not fix it.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ChannelJni.java

[mturk]

mturk   2002/09/18 23:26:52

  Modified:jk/java/org/apache/jk/common ChannelJni.java
  Log:
  Add the INFO log message when the channel is initialized.
  
  Revision  ChangesPath
  1.14  +3 -1  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelJni.java
  
  Index: ChannelJni.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelJni.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- ChannelJni.java   11 Jun 2002 00:11:03 -  1.13
  +++ ChannelJni.java   19 Sep 2002 06:26:52 -  1.14
  @@ -91,7 +91,9 @@
   if( apr==null ) return;
   
   // We'll be called from C. This deals with that.
  -apr.addJkHandler( "channelJni", this );
  +apr.addJkHandler( "channelJni", this );
  +log.info("JK2: listening on channel.jni:jni" );
  +
   if( next==null ) {
   if( nextName!=null ) 
   setNext( wEnv.getHandler( nextName ) );
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/apr AprImpl.java

[mturk]

mturk   2002/09/18 23:26:17

  Modified:jk/java/org/apache/jk/apr AprImpl.java
  Log:
  Add LogFactory to the class. This will prevent starting in case of error
  in the classloader code.
  
  Revision  ChangesPath
  1.26  +3 -0  jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprImpl.java
  
  Index: AprImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprImpl.java,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- AprImpl.java  14 Jul 2002 13:30:04 -  1.25
  +++ AprImpl.java  19 Sep 2002 06:26:17 -  1.26
  @@ -244,6 +244,7 @@
   
   initialize();
   jkSetAttribute(0, 0, "channel:jni", "starting");
  +log.info("JK2: Initialized apr" );
   } catch( Throwable t ) {
   throw new IOException( t.getMessage() );
   }
  @@ -336,4 +337,6 @@
   ex.printStackTrace();
   }
   }
  +private static org.apache.commons.logging.Log log=
  +org.apache.commons.logging.LogFactory.getLog( AprImpl.class );
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [BUG] jk2 jni doesn't work

[Mladen Turk]

This is the classloader problem.

Think that Bill Baker is solving this, but until then add the
commons-logging.jar to the loaded classes when started inprocess:

OPT=-Djava.class.path=${TOMCAT_HOME}\bin\tomcat-jni.jar;${TOMCAT_HOME}\s
erver\lib\commons-logging.jar

Adding commons-logging to the classpath solves the JNI problem.

Bill, when can ve expect this will get solved?



> 
> java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
>   at org.apache.jk.apr.AprImpl.(AprImpl.java:348)
> java.lang.NoClassDefFoundError
> 
> 

MT.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[billbarker]

billbarker2002/09/18 22:09:28

  Modified:util/java/org/apache/tomcat/util/net JSSESocketFactory.java
  Log:
  Fix problem with JSSE not honoring "clientauth".
  
  Now there should be now reason for anyone to believe that CertificatesValve should 
be used ever with the CoyoteConnector. :-)
  
  Revision  ChangesPath
  1.3   +16 -2 
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/JSSESocketFactory.java
  
  Index: JSSESocketFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/JSSESocketFactory.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JSSESocketFactory.java18 Sep 2002 15:10:04 -  1.2
  +++ JSSESocketFactory.java19 Sep 2002 05:09:28 -  1.3
  @@ -161,7 +161,18 @@
   
//determine whether we want client authentication
// the presence of the attribute enables client auth
  - clientAuth = null != (String)attributes.get("clientauth");
  + String clientAuthStr=(String)attributes.get("clientauth");
  + if(clientAuthStr != null){
  + if(clientAuthStr.equals("true")){
  + clientAuth=true;
  + } else if(clientAuthStr.equals("false")) {
  + clientAuth=false;
  + } else {
  + throw new IOException("Invalid value '" +
  +   clientAuthStr + 
  +   "' for 'clientauth' parameter:");
  + }
  + }
   
String keyPass=(String)attributes.get("keypass");
if( keyPass==null) keyPass=defaultKeyPass;
  @@ -224,11 +235,14 @@
   public Socket acceptSocket(ServerSocket socket)
throws IOException
   {
  + SSLSocket asock = null;
try {
  - return socket.accept();
  +  asock = (SSLSocket)socket.accept();
  +  asock.setNeedClientAuth(clientAuth);
} catch (SSLException e){
  throw new SocketException("SSL handshake error" + e.toString());
}
  + return asock;
   }

   /** Set server socket properties ( accepted cipher suites, etc)
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat/src/shell tomcat.bat tomcat.sh

[billbarker]

billbarker2002/09/18 21:21:17

  Modified:src/shell tomcat.bat tomcat.sh
  Log:
  Temporary stop-gap until I work out all of the ClassLoader issues.
  
  Revision  ChangesPath
  1.47  +2 -2  jakarta-tomcat/src/shell/tomcat.bat
  
  Index: tomcat.bat
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/shell/tomcat.bat,v
  retrieving revision 1.46
  retrieving revision 1.47
  diff -u -r1.46 -r1.47
  --- tomcat.bat28 Mar 2002 02:29:00 -  1.46
  +++ tomcat.bat19 Sep 2002 04:21:17 -  1.47
  @@ -97,7 +97,7 @@
   
   :setClasspath
   
  -set CLASSPATH=%TOMCAT_INSTALL%\lib\tomcat.jar
  +set 
CLASSPATH=%TOMCAT_INSTALL%\lib\tomcat.jar;%TOMCAT_INSTALL%\lib\common\commons-logging.jar
   
   rem - Execute The Requested Command -
   
  
  
  
  1.34  +2 -2  jakarta-tomcat/src/shell/tomcat.sh
  
  Index: tomcat.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/shell/tomcat.sh,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- tomcat.sh 18 Apr 2002 13:58:01 -  1.33
  +++ tomcat.sh 19 Sep 2002 04:21:17 -  1.34
  @@ -117,7 +117,7 @@
   
   oldCP=$CLASSPATH
   unset CLASSPATH
  -CLASSPATH=${TOMCAT_INSTALL}/lib/tomcat.jar
  
+CLASSPATH=${TOMCAT_INSTALL}/lib/tomcat.jar:${TOMCAT_INSTALL}/lib/common/commons-logging.jar
   
   # Ignore previous CLASSPATH
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: 4.1.10 tarball is borked.

[Jon Scott Stevens]

on 2002/9/18 3:35 PM, "Ian Darwin" <[EMAIL PROTECTED]> wrote:

> Well I guess it must be, it's on gnu.org.

http://www.gnu.org/manual/tar/html_node/tar_toc.html

-jon


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina build.xml

[glenn]

glenn   2002/09/18 18:12:00

  Modified:catalina build.xml
  Log:
  Add a README file to the distribution temp directory so it is always created
  
  Revision  ChangesPath
  1.129 +4 -0  jakarta-tomcat-4.0/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
  retrieving revision 1.128
  retrieving revision 1.129
  diff -u -r1.128 -r1.129
  --- build.xml 16 Sep 2002 15:36:54 -  1.128
  +++ build.xml 19 Sep 2002 01:12:00 -  1.129
  @@ -759,6 +759,10 @@
 
   
   
  +
  +
  +
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/temp README.txt

[glenn]

glenn   2002/09/18 18:09:44

  Added:   catalina/src/temp README.txt
  Log:
  Add a README file to the distribution temp directory so it is always created
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-4.0/catalina/src/temp/README.txt
  
  Index: README.txt
  ===
  This temp directory is used by the JVM for temporary file storage.
  The JVM is configured to use this as its java.io.tmpdir in the
  catalina.sh and catalina.bat scripts.  Tomcat is configured to use
  this temporary directory rather than its default for security reasons.
  The temp directory must exist for Tomcat to work correctly.
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/temp - New directory

[glenn]

glenn   2002/09/18 18:08:49

  jakarta-tomcat-4.0/catalina/src/temp - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12795] New: - activation.jar in common/lib gives javax/activation/DataSource errors

[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=12795

activation.jar in common/lib gives javax/activation/DataSource errors

   Summary: activation.jar in common/lib gives
javax/activation/DataSource errors
   Product: Tomcat 4
   Version: 4.1.10
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In tomcat 4.1.10, the file activation.jar in the common/lib directory has to be
moved (not copied) to the jre/lib/ext directory of the java installation, or
else the use of javax.mail.Session objects (and possibly others) in servlets
gives exceptions.

Example:

When calling new MimeMessage(), this exception results:


java.lang.NoClassDefFoundError: javax/activation/DataSource
at AcceptMailForm.sendMessage(AcceptMailForm.java:136)
at AcceptMailForm.processRequest(AcceptMailForm.java:86)
at AcceptMailForm.doPost(AcceptMailForm.java:116)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.
java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193


If I recall, this problem had existed previously in 3.X versions.

In versions 4.0.X this issue was fixed and activation.jar didn't need to be
moved to the java extensions folder.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12794] New: - jsp:plugin produces unuseable tag

[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=12794

jsp:plugin produces unuseable  tag

   Summary: jsp:plugin produces unuseable  tag
   Product: Tomcat 4
   Version: 4.1.10
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In tomcat 4.1.10, the applet parameters 

are translated to



instead of



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] catalina DateTool thread safety issue

[Steve Downey]

This patch mirrors that in connectors. DateTool in catalina util is largely 
obsolete, in any case. The patch cuts out unused code.



? share/org/apache/catalina/startup/CatalinaService.java.smd
Index: share/org/apache/catalina/util/CookieTools.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CookieTools.java,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 CookieTools.java
--- share/org/apache/catalina/util/CookieTools.java	18 Jul 2002 16:47:45 -	1.1.1.1
+++ share/org/apache/catalina/util/CookieTools.java	18 Sep 2002 23:35:05 -
@@ -143,10 +143,10 @@
 if (version == 0) {
 buf.append (";Expires=");
 if (cookie.getMaxAge() == 0)
-DateTool.oldCookieFormat.format(new Date(1), buf,
+DateTool.formatOldCookie(new Date(1), buf,
 new FieldPosition(0));
 else
-DateTool.oldCookieFormat.format
+DateTool.formatOldCookie
 (new Date( System.currentTimeMillis() +
cookie.getMaxAge() *1000L), buf,
  new FieldPosition(0));
Index: share/org/apache/catalina/util/DateTool.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/DateTool.java,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 DateTool.java
--- share/org/apache/catalina/util/DateTool.java	18 Jul 2002 16:47:45 -	1.1.1.1
+++ share/org/apache/catalina/util/DateTool.java	18 Sep 2002 23:35:05 -
@@ -79,55 +79,34 @@
  */
 public class DateTool {
 
-private static StringManager sm =
-StringManager.getManager("org.apache.catalina.util");
-
 /** US locale - all HTTP dates are in english
  */
 public final static Locale LOCALE_US = Locale.US;
 
 /** GMT timezone - all HTTP dates are on GMT
  */
-public final static TimeZone GMT_ZONE = TimeZone.getTimeZone("GMT");
-
-/** format for RFC 1123 date string -- "Sun, 06 Nov 1994 08:49:37 GMT"
- */
-public final static String RFC1123_PATTERN =
-"EEE, dd MMM y HH:mm:ss z";
-
-// format for RFC 1036 date string -- "Sunday, 06-Nov-94 08:49:37 GMT"
-private final static String rfc1036Pattern =
-"E, dd-MMM-yy HH:mm:ss z";
-
-// format for C asctime() date string -- "Sun Nov  6 08:49:37 1994"
-private final static String asctimePattern =
-"EEE MMM d HH:mm:ss y";
+private final static TimeZone GMT_ZONE = TimeZone.getTimeZone("GMT");
 
 /** Pattern used for old cookies
  */
 public final static String OLD_COOKIE_PATTERN = "EEE, dd-MMM- HH:mm:ss z";
 
-/** DateFormat to be used to format dates
- */
-public final static DateFormat rfc1123Format =
-new SimpleDateFormat(RFC1123_PATTERN, LOCALE_US);
-
 /** DateFormat to be used to format old netscape cookies
  */
-public final static DateFormat oldCookieFormat =
+private final static DateFormat oldCookieFormat =
 new SimpleDateFormat(OLD_COOKIE_PATTERN, LOCALE_US);
 
-public final static DateFormat rfc1036Format =
-new SimpleDateFormat(rfc1036Pattern, LOCALE_US);
-
-public final static DateFormat asctimeFormat =
-new SimpleDateFormat(asctimePattern, LOCALE_US);
-
 static {
-rfc1123Format.setTimeZone(GMT_ZONE);
 oldCookieFormat.setTimeZone(GMT_ZONE);
-rfc1036Format.setTimeZone(GMT_ZONE);
-asctimeFormat.setTimeZone(GMT_ZONE);
+}
+
+public static StringBuffer formatOldCookie(
+  Date d,
+  StringBuffer buf,
+  FieldPosition fieldPosition) {
+  synchronized (oldCookieFormat) {
+return oldCookieFormat.format(d, buf, fieldPosition);
+  }
 }
 
 }



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12792] - login.jsp of admin webapp won't compile when tomcat is run as NT Service from D drive

[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=12792

login.jsp of admin webapp won't compile when tomcat is run as NT Service from D drive





--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 23:16 ---
Created an attachment (id=3125)
patch for JspRuntimeContext.java

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12792] New: - login.jsp of admin webapp won't compile when tomcat is run as NT Service from D drive

[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=12792

login.jsp of admin webapp won't compile when tomcat is run as NT Service from D drive

   Summary: login.jsp of admin webapp won't compile when tomcat is
run as NT Service from D drive
   Product: Tomcat 4
   Version: 4.1.10
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


jsp files that import java classes from other packages will not compile in the
following situation:

Tomcat 4 running as a NT Service
Tomcat 4 installed on D: drive

The problem is that the classpath does not contain the correct path entries. 
The classloader is returning URLs of this form:
file:/d:\tomcat-4.1\server\webapps\admin\WEB-INF\lib.  The / after file: causes
that path to not be included in the classpath since the Ant PathTokenizer does
not understand that path.

I have a patch to JspRuntimeContext.java that corrects the problem.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: 4.1.10 tarball is borked.

[Ian Darwin]

On September 17, 2002 09:20 pm, Jon Scott Stevens wrote:
> > Er, you mean perhaps that BSD tar doesn't yet support the
> > non-standard GNU extensions?
>
> Like being able to support simple things like directory paths longer than
> 255 characters? If it isn't a standard, it should be!

Err, I think you mean > 100, up to 255 chars.  The Posix standard supports this too,
but in a different way (of course). GNU claims they were there first, but I know POSIX
used to have stuff in committee for a long time, so it's hard to know who was "really"
first. In the article you point out:

> Interesting history on the issue...

> http://www.gnu.org/manual/tar/html_node/tar_117.html#SEC112

They admit that they aren't POSIX conformant, and claim that they will be, and will
do it in a different way than GNUtar does at present. Do you know if this article
is up to date? Well I guess it must be, it's on gnu.org.  

Obviously it would be good if all tars could read each others' archives.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Volunteer Needed] - TOMCAT-DEV Moderation

[Craig R. McClanahan]

Ignacio Ortega (better known around here as "nacho" because of his
username :-), who already moderates TOMCAT-USER, was the first gracious
volunteer, so he's got the ball now.

Thanks for everyone's willingness to help!

Craig

On Wed, 18 Sep 2002, Shannon Lal wrote:

> Date: Wed, 18 Sep 2002 21:16:18 +
> From: Shannon Lal <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: [Volunteer Needed] - TOMCAT-DEV Moderation
>
>
> I would be interested in helping out.
>
> Let me know what you to be done.
>
> Nin
>
> >From: ed banfa <[EMAIL PROTECTED]>
> >Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> >To: Tomcat Developers List <[EMAIL PROTECTED]>
> >Subject: Re: [Volunteer Needed] - TOMCAT-DEV Moderation
> >Date: Wed, 18 Sep 2002 13:41:42 -0700 (PDT)
> >
> >
> >I would be honoured to serve you in any way I can
> >Best Wishes
> >Edward Banfa
> >
> >  "Craig R. McClanahan" wrote:I need a volunteer to take over moderation of
> >the TOMCAT-DEV mailing list.
> >Basically, this involves replying "yes" or "no" to a message from the
> >mailing list server when non-subscribers attempt to post. Most of this
> >kind of mail falls into the following categories:
> >
> >* Spam
> >
> >* Bug reports from non-subscribers (should be moderated through)
> >
> >* User questions (should be redirected to TOMCAT-USER).
> >
> >Besides the fact that my primary job responsibilities are no longer
> >focused on Tomcat development, I'm going to be travelling next week
> >(JavaOne Japan) and will be unable to perform moderation duties in a
> >timely manner.
> >
> >Any takers?
> >
> >Craig McClanahan
> >
> >
> >
> >--
> >To unsubscribe, e-mail:
> >For additional commands, e-mail:
> >
> >
> >
> >-
> >Do you Yahoo!?
> >Yahoo! News - Today's headlines
>
>
>
>
> _
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Jasper 2 Question

[Lenny Karpel]

I use IntelliJ's IDEA product for Tomcat relared development .. I noted the
following statement in thier bugs mailing list with regards to debugging JSP
from thier IDE:


"As for Tomcat 4.1.x support, I'm afraid we are out-of-luck here. Tomcat
4.0.4 used to generate useful comments in the servlet code, that allowed the
integration plugin to map jsp line numbers to servlet line numbers. But from
the new version of Tomcat (Jasper2 in particular), this functionality is
missing. At least I haven't been able to find anything to enable comment
generation, and nobody from Tomcat user-list answered my question about
this."

 

Is this really true ?? Will this be fixed ??

Re: [Volunteer Needed] - TOMCAT-DEV Moderation

[Shannon Lal]

I would be interested in helping out.

Let me know what you to be done.

Nin

>From: ed banfa <[EMAIL PROTECTED]>
>Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]>
>To: Tomcat Developers List <[EMAIL PROTECTED]>
>Subject: Re: [Volunteer Needed] - TOMCAT-DEV Moderation
>Date: Wed, 18 Sep 2002 13:41:42 -0700 (PDT)
>
>
>I would be honoured to serve you in any way I can
>Best Wishes
>Edward Banfa
>
>  "Craig R. McClanahan" wrote:I need a volunteer to take over moderation of 
>the TOMCAT-DEV mailing list.
>Basically, this involves replying "yes" or "no" to a message from the
>mailing list server when non-subscribers attempt to post. Most of this
>kind of mail falls into the following categories:
>
>* Spam
>
>* Bug reports from non-subscribers (should be moderated through)
>
>* User questions (should be redirected to TOMCAT-USER).
>
>Besides the fact that my primary job responsibilities are no longer
>focused on Tomcat development, I'm going to be travelling next week
>(JavaOne Japan) and will be unable to perform moderation duties in a
>timely manner.
>
>Any takers?
>
>Craig McClanahan
>
>
>
>--
>To unsubscribe, e-mail:
>For additional commands, e-mail:
>
>
>
>-
>Do you Yahoo!?
>Yahoo! News - Today's headlines




_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12553] - Responses are truncated when served through mod_jk

[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=12553

Responses are truncated when served through mod_jk





--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 20:59 ---
Saw this same problem when trying to use either mod_jk and
mod_jk2 with apache 2.0.39 on solaris. It seems to be a problem
with HTTP/1.0 requests (Netscape 4.x browsers). Only the first
8192 or 16384 bytes would be sent. Newer browsers worked ok.

Apache 2.0.40 fixed this problem.

In the release notes for apache 2.0.40 at
http://www.apache.org/dist/httpd/CHANGES_2.0

[ *) Fixed the Content-Length filter so that HTTP/1.0 requests to
[ CGI scripts would not result in a truncated response.
[ [Ryan Bloom, Justin Erenkrantz, Cliff Woolley]

For solaris a rebuild of mod_jk was necessary. Not
sure of requirements for NT4. Also cannot confirm that
this fix works for NT4.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Volunteer Needed] - TOMCAT-DEV Moderation

[ed banfa]

I would be honoured to serve you in any way I can
Best Wishes
Edward Banfa
 
 "Craig R. McClanahan" wrote:I need a volunteer to take over moderation of the 
TOMCAT-DEV mailing list.
Basically, this involves replying "yes" or "no" to a message from the
mailing list server when non-subscribers attempt to post. Most of this
kind of mail falls into the following categories:

* Spam

* Bug reports from non-subscribers (should be moderated through)

* User questions (should be redirected to TOMCAT-USER).

Besides the fact that my primary job responsibilities are no longer
focused on Tomcat development, I'm going to be travelling next week
(JavaOne Japan) and will be unable to perform moderation duties in a
timely manner.

Any takers?

Craig McClanahan



--
To unsubscribe, e-mail: 
For additional commands, e-mail: 



-
Do you Yahoo!?
Yahoo! News - Today's headlines

DO NOT REPLY [Bug 12787] - request.getRequestURI() returns garbage when included in some tags

[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=12787

request.getRequestURI() returns garbage when included in some tags





--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 20:39 ---
Created an attachment (id=3123)
test case for this bug, this only uses custom tags and should be able to run without 
anything else.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12787] New: - request.getRequestURI() returns garbage when included in some tags

[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=12787

request.getRequestURI() returns garbage when included in some tags

   Summary: request.getRequestURI() returns garbage when included in
some tags
   Product: Tomcat 4
   Version: 4.1.10
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


if a tag that implements BodyTagSupport retuns EVAL_PAGE_INCLUDE from its
doStartTag() method, and then it contains a tag that performs a
pageContext.include() call that invokes a servlet, most of the calls to the
request object methods produce bogus results.  for eg. getRequestURI() will
return what looks like a fragment of the webpage being processed.  subsequent
calls to import (either via a custom tag doing pageRequest.include() or jstl
tags like c:import) will also fail.  if, however, EVAL_BODY_TAG (deprecated) or
EVAL_BODY_BUFFERED are returned from doStartTag(), everything works as expected.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java

[Bill Barker]

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, September 18, 2002 12:34 PM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
Http11Processor.java


>
>
> On Wed, 18 Sep 2002, Bill Barker wrote:
>
> > Date: Wed, 18 Sep 2002 12:06:50 -0700
> > From: Bill Barker <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: Tomcat Developers List <[EMAIL PROTECTED]>
> > Subject: Re: cvs commit:
> > jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
> > Http11Processor.java
> >
> >
> > - Original Message -
> > From: <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, September 18, 2002 9:44 AM
> > Subject: cvs commit:
> > jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
> > Http11Processor.java
> >
> >
> > > bobh2002/09/18 09:44:35
> > >
> > >   Modified:.gump.xml
> > >coyote/src/java/org/apache/coyote Request.java
> > >http11/src/java/org/apache/coyote/http11
> > > Http11Processor.java
> > >   Log:
> > >   - This associates the socket with the Request.  This is so the
> > >   CertificatesValve.verify() can tell where (which socket) the Request
> > >   is comeing from.  Without this association,
CertificatesValve.verify()
> > >   returns with no SSL Handshake.
> > >   - this change is in part based on feed back from; Vivek N. Yingxian
> > >   Wang (JSSE), Craig M., Qingqing Ouyang
> > >
> >
> > I'm -1 on this, since having a socket in the Request makes no sense for
Jk2.
> > CertificatesValve is only for use with the deprecated HttpConnector.
With
> > Coyote, the SSL handling has moved to the connector (where it belonged
in
> > the first place).
> >
>
> The current Tomcat standalone implementation does not appear to meet the
> spec requirements for exposing a certificate chain, or for implementing
> CLIENT-CERT authentication.  For the latter, the container needs to
> challenge the client to send a certificate if they didn't do so already.
>
> How do you propose to meet those requirements for Tomcat stand-alone
> without access to the underlying SSL socket?  (For the connectors, you'll
> obviously need to provide an alternative solution to meet the spec
> requirements).

The correct place to fix it is
o.a.t.u.net.JSSESupport.getPeerCertificateChain (called from
o.a.c.http11.Http11Processor.action).  The code there was so heavily cribbed
from CertificatesValve, that I should probably add you to the @author. :-)

I'm strongly against reverting TC 4/5 back to only supporting JSSE (which
would be the effect of requiring CertificatesValve).

>
> Craig
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [ADDON] Jk2 uriMap using pcre (someone willing to check)

[Ian Darwin]

> > The reason for using pcre was simple (?). It is well tested library, and
> > our uri mapping code is basically tries to be something like that on the
> > lower scale, not to mention the  increased power.

It's too bad there's not a C mapping into jakarta-oro, so we could "use our own"
instead of depending on something with such a curious blend of license terms :-)



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java

[Craig R. McClanahan]

On Wed, 18 Sep 2002, Bill Barker wrote:

> Date: Wed, 18 Sep 2002 12:06:50 -0700
> From: Bill Barker <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: cvs commit:
> jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
> Http11Processor.java
>
>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 18, 2002 9:44 AM
> Subject: cvs commit:
> jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
> Http11Processor.java
>
>
> > bobh2002/09/18 09:44:35
> >
> >   Modified:.gump.xml
> >coyote/src/java/org/apache/coyote Request.java
> >http11/src/java/org/apache/coyote/http11
> > Http11Processor.java
> >   Log:
> >   - This associates the socket with the Request.  This is so the
> >   CertificatesValve.verify() can tell where (which socket) the Request
> >   is comeing from.  Without this association, CertificatesValve.verify()
> >   returns with no SSL Handshake.
> >   - this change is in part based on feed back from; Vivek N. Yingxian
> >   Wang (JSSE), Craig M., Qingqing Ouyang
> >
>
> I'm -1 on this, since having a socket in the Request makes no sense for Jk2.
> CertificatesValve is only for use with the deprecated HttpConnector.  With
> Coyote, the SSL handling has moved to the connector (where it belonged in
> the first place).
>

The current Tomcat standalone implementation does not appear to meet the
spec requirements for exposing a certificate chain, or for implementing
CLIENT-CERT authentication.  For the latter, the container needs to
challenge the client to send a certificate if they didn't do so already.

How do you propose to meet those requirements for Tomcat stand-alone
without access to the underlying SSL socket?  (For the connectors, you'll
obviously need to provide an alternative solution to meet the spec
requirements).

Craig



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf DateTool.java

[Steve Downey]

On Wednesday 18 September 2002 08:34 am, Henri Gomez wrote:
> > The upshot is that DateFormats need to be either thread local, or created
> > new each time.
>
> Created each time is exactly what we want to avoid ;)
Sacrificing correctness for speed isn't a great trade-off. After all, if it 
doesn't have to work, I can make it a LOT faster.

In this case, it looks like the problem with SimpleDateFormat is manageable 
with synchronization. SDF can leak some of its internal state with 
get/setCalendar. Since in the connectors DateTool, the formatter instance is 
private, and get/setCalendar is never called, syncing on the instance should 
be sufficient.

It looks like the same problem exists in catalina's DateTool.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12786] New: - Catalina stops if webapp doesn't exist

[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=12786

Catalina stops if webapp doesn't exist

   Summary: Catalina stops if webapp doesn't exist
   Product: Tomcat 4
   Version: 4.1.10
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If a webapp that is mapped in server.xml doesn't exist, tomcat stops. This 
doesn't happen in 4.0.4.

Stack trace:
java.lang.IllegalArgumentException: Document 
base /opt/tomcat41/work/webapp/client1 does not exist o
r is not a readable directoryat 
org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:187)
at org.apache.catalina.core.StandardContext.start
(StandardContext.java:3398)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardEngine.start
(StandardEngine.java:347)
at org.apache.catalina.core.StandardService.start
(StandardService.java:497)
at org.apache.catalina.core.StandardServer.start
(StandardServer.java:2191)
at org.apache.catalina.startup.Catalina.start(Catalina.java:510)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/defaultcontext SaveDefaultContextAction.java

[amyroh]

amyroh  2002/09/18 12:16:07

  Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/context
SaveContextAction.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/defaultcontext
SaveDefaultContextAction.java
  Log:
  Fix to make the treenodes names unique.
  
  Revision  ChangesPath
  1.3   +6 -6  
jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/context/SaveContextAction.java
  
  Index: SaveContextAction.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/context/SaveContextAction.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- SaveContextAction.java16 Sep 2002 04:46:18 -  1.2
  +++ SaveContextAction.java18 Sep 2002 19:16:07 -  1.3
  @@ -248,8 +248,8 @@
   mBServer.invoke(fname, operation,
   values, createStandardManagerTypes);
   
  -// Add the new Default Context to our tree control node
  -addToTreeControlNode(oname, "DefaultContext", parentName, 
  +// Add the new Context to our tree control node
  +addToTreeControlNode(oname, cObjectName, parentName, 
   resources, session); 
   
   } catch (Exception e) {
  
  
  
  1.2   +5 -5  
jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/defaultcontext/SaveDefaultContextAction.java
  
  Index: SaveDefaultContextAction.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/defaultcontext/SaveDefaultContextAction.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SaveDefaultContextAction.java 16 Sep 2002 04:48:38 -  1.1
  +++ SaveDefaultContextAction.java 18 Sep 2002 19:16:07 -  1.2
  @@ -247,7 +247,7 @@
   //values, createStandardManagerTypes);
   
   // Add the new Default Context to our tree control node
  -addToTreeControlNode(oname, "DefaultContext", 
  +addToTreeControlNode(oname, cObjectName, 
   parentName, resources, session);
   
   } catch (Exception e) {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/defaultcontext SaveDefaultContextAction.java

[amyroh]

amyroh  2002/09/18 12:15:52

  Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/context
SaveContextAction.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/defaultcontext
SaveDefaultContextAction.java
  Log:
  Fix to make the treenodes names unique.
  
  Revision  ChangesPath
  1.8   +6 -6  
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/context/SaveContextAction.java
  
  Index: SaveContextAction.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/context/SaveContextAction.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- SaveContextAction.java14 Sep 2002 23:37:39 -  1.7
  +++ SaveContextAction.java18 Sep 2002 19:15:51 -  1.8
  @@ -249,8 +249,8 @@
   mBServer.invoke(fname, operation,
   values, createStandardManagerTypes);
   
  -// Add the new Default Context to our tree control node
  -addToTreeControlNode(oname, "DefaultContext", parentName, 
  +// Add the new Context to our tree control node
  +addToTreeControlNode(oname, cObjectName, parentName, 
   resources, session);
   
   } catch (Exception e) {
  
  
  
  1.3   +5 -5  
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/defaultcontext/SaveDefaultContextAction.java
  
  Index: SaveDefaultContextAction.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/defaultcontext/SaveDefaultContextAction.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- SaveDefaultContextAction.java 13 Sep 2002 01:35:35 -  1.2
  +++ SaveDefaultContextAction.java 18 Sep 2002 19:15:51 -  1.3
  @@ -247,7 +247,7 @@
   //values, createStandardManagerTypes);
   
   // Add the new Default Context to our tree control node
  -addToTreeControlNode(oname, "DefaultContext", 
  +addToTreeControlNode(oname, cObjectName, 
   parentName, resources, session);
   
   } catch (Exception e) {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10558] - encodeURL form submit doesn't include hidden form variables

[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=10558

encodeURL form submit doesn't include hidden form variables

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Connector:Coyote HTTP/1.1   |Catalina

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java

[Bill Barker]

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 18, 2002 9:44 AM
Subject: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
Http11Processor.java


> bobh2002/09/18 09:44:35
>
>   Modified:.gump.xml
>coyote/src/java/org/apache/coyote Request.java
>http11/src/java/org/apache/coyote/http11
> Http11Processor.java
>   Log:
>   - This associates the socket with the Request.  This is so the
>   CertificatesValve.verify() can tell where (which socket) the Request
>   is comeing from.  Without this association, CertificatesValve.verify()
>   returns with no SSL Handshake.
>   - this change is in part based on feed back from; Vivek N. Yingxian
>   Wang (JSSE), Craig M., Qingqing Ouyang
>

I'm -1 on this, since having a socket in the Request makes no sense for Jk2.
CertificatesValve is only for use with the deprecated HttpConnector.  With
Coyote, the SSL handling has moved to the connector (where it belonged in
the first place).


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11868] - The Tomcat service terminated unexpectedly

[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=11868

The Tomcat service terminated unexpectedly





--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 19:02 ---
This is a known problem with jdk1.2. You need to add -xrs to your options or 
upgrade to jdk1.3

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf DateTool.java

[Bill Barker]

The "less paranoid" is only because I already had checked that rfc1123Format
wasn't used elsewhere, and there where no other locks on DateTool.class. :)

Eventually I intend to move everyone to thread-local and (hopefully)
deprecate the one-parameter format1123 method.  It should be easy for TC 4 &
5 (since only Coyote can use it).  A bit more work for 3.3.

- Original Message -
From: "Steve Downey" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, September 18, 2002 5:15 AM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf DateTool.java


OK, ignore my last message.

But, it's not just less paranoid. It's more correct. If rfc1123Format were
used elsewhere, the lock on Class.DateTool would not be sufficient.

Actually, refreshing my memory on this bug, synchronization is insufficient.

http://developer.java.sun.com/developer/bugParade/bugs/4228335.html

The upshot is that DateFormats need to be either thread local, or created
new
each time.

On Wednesday 18 September 2002 12:20 am, [EMAIL PROTECTED] wrote:
> billbarker2002/09/17 21:20:24
>
>   Modified:util/java/org/apache/tomcat/util/buf DateTool.java
>   Log:
>   A little less paraniod than the last one, but functionally the same.
>
>   Revision  ChangesPath
>   1.7   +6 -2
>
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/DateTool.jav
>a
>
>   Index: DateTool.java
>   ===
>   RCS file:
>
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/Da
>teTool.java,v retrieving revision 1.6
>   retrieving revision 1.7
>   diff -u -r1.6 -r1.7
>   --- DateTool.java 18 Sep 2002 03:50:04 - 1.6
>   +++ DateTool.java 18 Sep 2002 04:20:24 - 1.7
>   @@ -141,8 +141,12 @@
>// Called from MessageBytes.setTime
>/**
> */
>   -public static synchronized String format1123( Date d ) {
>   - return format1123(d, rfc1123Format);
>   +public static String format1123( Date d ) {
>   + String dstr=null;
>   + synchronized(rfc1123Format) {
>   + dstr = format1123(d, rfc1123Format);
>   + }
>   + return dstr;
>}
>
>public static String format1123( Date d,DateFormat df ) {


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeansMBeanFactory.java

[Amy Roh]

MBeanFactory.createStandardContext() still throws 
"java.lang.IllegalArgumentException: Document base .\webapps\newpath 
does not exist or is not a readable directory" after recent change in 
StandardContext.  Is there something else missing that is preventing 
host.addChild(newContext) to work?

Thanks,
Amy


[EMAIL PROTECTED] wrote:
> remm2002/09/18 03:04:38
> 
>   Modified:catalina/src/share/org/apache/catalina/mbeans
> MBeanFactory.java
>   Log:
>   - Contexts created were not properly configured. Now, they are deployed in the
> same way they would be if they were read from server.xml.
>   
>   Revision  ChangesPath
>   1.39  +9 -4  
>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.38
>   retrieving revision 1.39
>   diff -u -r1.38 -r1.39
>   --- MBeanFactory.java   13 Sep 2002 01:35:22 -  1.38
>   +++ MBeanFactory.java   18 Sep 2002 10:04:38 -  1.39
>   @@ -102,6 +102,7 @@
>import org.apache.catalina.realm.MemoryRealm;
>import org.apache.catalina.realm.UserDatabaseRealm;
>import org.apache.catalina.session.StandardManager;
>   +import org.apache.catalina.startup.ContextConfig;
>import org.apache.catalina.valves.AccessLogValve;
>import org.apache.catalina.valves.RemoteAddrValve;
>import org.apache.catalina.valves.RemoteHostValve;
>   @@ -825,6 +826,8 @@
>path = getPathStr(path);
>context.setPath(path);
>context.setDocBase(docBase);
>   +ContextConfig contextConfig = new ContextConfig();
>   +context.addLifecycleListener(contextConfig);
>
>// Add the new instance to its parent component
>ObjectName pname = new ObjectName(parent);
>   @@ -832,6 +835,8 @@
>Service service = server.findService(pname.getKeyProperty("service"));
>Engine engine = (Engine) service.getContainer();
>Host host = (Host) engine.findChild(pname.getKeyProperty("host"));
>   +
>   +// Add context to the host
>host.addChild(context);
>
>// Return the corresponding MBean name
>   
>   
>   
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java

[Bob Herrmann]

On Wed, 2002-09-18 at 13:58, Remy Maucherat wrote:
> Remy Maucherat wrote:
> > [EMAIL PROTECTED] wrote:
> > 
> >> bobh2002/09/18 09:44:35
> >>
> >>   Modified:.gump.xml
> >>coyote/src/java/org/apache/coyote Request.java
> >>http11/src/java/org/apache/coyote/http11
> >> Http11Processor.java
> >>   Log:
> >>   - This associates the socket with the Request.  This is so the
> >>   CertificatesValve.verify() can tell where (which socket) the Request
> >>   is comeing from.  Without this association, CertificatesValve.verify()
> >>   returns with no SSL Handshake.
> >>   - this change is in part based on feed back from; Vivek N. Yingxian
> >>   Wang (JSSE), Craig M., Qingqing Ouyang
> > 
> > 
> > -1 (ie, revert this).
> > 
> > The socket should already have been associated with the request, but as 
> > a note. It is available, and accessible.
> 
> Ok, I checked it, and the socket os not currently associated with the 
> request (I thought it was). OTOH, you shouldn't add a field for socket 
> in the request (native webservers don't have the notion of a Java 
> socket). Instead, use one of the notes.

Ok, 
  - change Http11Processor to use a note
  - change Request.java to it's original form
  - change the CertificatesValve.verify()

Does that sound about right?

Cheers,
-bob

> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12784] - Tomcat 4.1.10 does not follow symlinks in a webapp

[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=12784

Tomcat 4.1.10 does not follow symlinks in a webapp

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 18:08 ---
Note bug 11501 and bug 12076

Thanks Remy, I'll be more vigilant on the query page and check mailing lists in
the future.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12784] - Tomcat 4.1.10 does not follow symlinks in a webapp

[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=12784

Tomcat 4.1.10 does not follow symlinks in a webapp

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 18:00 ---
This will be partially fixed in 4.1.11, as discussed. Please try not to file
duplicates.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java

[Remy Maucherat]

Remy Maucherat wrote:
> [EMAIL PROTECTED] wrote:
> 
>> bobh2002/09/18 09:44:35
>>
>>   Modified:.gump.xml
>>coyote/src/java/org/apache/coyote Request.java
>>http11/src/java/org/apache/coyote/http11
>> Http11Processor.java
>>   Log:
>>   - This associates the socket with the Request.  This is so the
>>   CertificatesValve.verify() can tell where (which socket) the Request
>>   is comeing from.  Without this association, CertificatesValve.verify()
>>   returns with no SSL Handshake.
>>   - this change is in part based on feed back from; Vivek N. Yingxian
>>   Wang (JSSE), Craig M., Qingqing Ouyang
> 
> 
> -1 (ie, revert this).
> 
> The socket should already have been associated with the request, but as 
> a note. It is available, and accessible.

Ok, I checked it, and the socket os not currently associated with the 
request (I thought it was). OTOH, you shouldn't add a field for socket 
in the request (native webservers don't have the notion of a Java 
socket). Instead, use one of the notes.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [ADDON] Jk2 uriMap using pcre (someone willing to check)

[Mladen Turk]

> -Original Message-
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] 
> > 
> > [uri:/examples/(?!\w*\.(gif|jpg)$)]
> > info=Map the whole webapp except *.gif and *.jpg files
> > 
> > [uri:/\w+\.jsp$]
> > info=Map the extension
> 
> Yipeee! :) Really nice, i suppouse that every part of the 
> uri including the VS name would a RE, right? 
> 
> 

Yes I've added the possibility to check the context prior the
prefixMatch meaning that you can have

[uri:/.*]
context=/examples

And it will still belongs to the /examples context not the default one.

The other option is:

[uri:!/examples/.*(\.gif$)]

Meaning that uri /examples/what.ever.gif wil _not_ be mapped.

Right now the uri has to begin with the forward slash, but think we can
change that, cause right now it is used to distinguish the host name.

MT.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
> bobh2002/09/18 09:44:35
> 
>   Modified:.gump.xml
>coyote/src/java/org/apache/coyote Request.java
>http11/src/java/org/apache/coyote/http11
> Http11Processor.java
>   Log:
>   - This associates the socket with the Request.  This is so the
>   CertificatesValve.verify() can tell where (which socket) the Request
>   is comeing from.  Without this association, CertificatesValve.verify()
>   returns with no SSL Handshake.
>   - this change is in part based on feed back from; Vivek N. Yingxian
>   Wang (JSSE), Craig M., Qingqing Ouyang

-1 (ie, revert this).

The socket should already have been associated with the request, but as 
a note. It is available, and accessible.

Thanks,
Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12784] New: - Tomcat 4.1.10 does not follow symlinks in a webapp

[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=12784

Tomcat 4.1.10 does not follow symlinks in a webapp

   Summary: Tomcat 4.1.10 does not follow symlinks in a webapp
   Product: Tomcat 4
   Version: 4.1.10
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Whereas 4.0.4 did.  To test:  
1. shutdown Tomcat if running.
2. move $CATALINA_HOME/webapps/ROOT/index.jsp to ~/index.jsp.
3. ln -s ~/index.jsp $CATALINA_HOME/webapps/ROOT/index.jsp
4. start up Tomcat and navitage to http://localhost:8080 (or whatever)

I am experiencing difficulty loading jar files from my WEBINF/lib directory
which are symlinks.  Here is what my logfile says:

2002-09-18 13:37:56 ContextConfig[/steeltorch] Exception processing JAR at
resource path /WEB-INF/lib/jaxen-full.jar
javax.servlet.ServletException: Exception processing JAR at resource path
/WEB-INF/lib/jaxen-full.jar
   at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:930)
   at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868)
   at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647)
   at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243)

*snip*
- Root Cause -
java.lang.IllegalArgumentException: Invalid TLD resource path
/WEB-INF/lib/jaxen-full.jar
   at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:898)
   at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868)
   at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647)
   at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243)

-
This works fine if the file is *NOT* a symlink.  I could not find anything that
describes a "follow symlinks" directive for Tomcat, such as there is for Apache.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12783] - Coyote Connector and HTTP 1.0 Keep-Alive

[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=12783

Coyote  Connector and HTTP 1.0 Keep-Alive

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 17:50 ---
HTTP/1.0 keep alive does not work correctly with the Coyote version included in
Tomcat 4.0.4.

However, if IE sends the Connection: keep-alive header and the servlet properly
does content delimitation, then the connection will be persisted. If IE doesn't
like that, then it's IE's problem (use it in HTTP/1.1 mode).

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [BUG] jk2 jni doesn't work

[Mladen Turk]

> -Original Message-
> From: Mladen Turk [mailto:[EMAIL PROTECTED]] 
> 
> 
> OK this is a release showstopper!
> 
> 
> IMHO the reason is missing org.apache.commons.logging.LogFactory,
> perhaps not loaded by the jni channel.
> If someone more familiar with that can dig into and trace the 
> problem it would be great, or I'll simply delete all that 
> 'unnecessary' *.Log stuff, and use the System.err.
> 

Perhaps this will help:

I've added the following to the AprImpl.java


import org.apache.commons.logging.*;

public class AprImpl extends JkHandler {
...

private static Log log = LogFactory.getLog( AprImpl.class );

}

And On starting TC I'm getting the following in the error.log:

java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.apache.jk.apr.AprImpl.(AprImpl.java:348)
java.lang.NoClassDefFoundError


MT.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12778] - NoSuchMethod Excp on putValue() and setAttribute methods of HttpSession

[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=12778

NoSuchMethod Excp on putValue() and setAttribute methods of HttpSession

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 17:41 ---
Please make sure you do not have an old version of the servlet API classes in
your system classpath or in your webapp repositories.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12778] - NoSuchMethod Excp on putValue() and setAttribute methods of HttpSession

[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=12778

NoSuchMethod Excp on putValue() and setAttribute methods of HttpSession





--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 17:39 ---
*** Bug 12777 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12777] - NoSuchMethod Exception

[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=12777

NoSuchMethod Exception

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 17:39 ---


*** This bug has been marked as a duplicate of 12778 ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12783] New: - Coyote Connector and HTTP 1.0 Keep-Alive

[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=12783

Coyote  Connector and HTTP 1.0 Keep-Alive

   Summary: Coyote  Connector and HTTP 1.0 Keep-Alive
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


User Agent: IE (version 4.0+)
Type of Request: POST
Protocol: HTTP/1.0
The servlet is properly setting the content-length.

If these conditions are met, IE will block for the period of time specified in 
the connectionTimeout parameter. This is due to the following lines in 
Http11Processor.prepareResponse method:

(Aprox lines: 857 - 862)
int contentLength = response.getContentLength();
if (contentLength != -1) {
outputBuffer.addActiveFilter
(outputFilters[Constants.IDENTITY_FILTER]);
contentDelimitation = true;
}
   
And a little further down:

(Aprox lines: 880 - 884)
if ((entityBody) && (!contentDelimitation)) {
// Mark as close the connection after the request, and add the 
// connection: close header
keepAlive = false;
}

By setting countDelimitation to true the keepAlive variable remains true and 
the Coyote Connector will try to reuse the connection. Unfortunately IE doesn't 
display the response but rather waits for the connection to be closed (Even 
though IE sent Keep-Alives:True in the headers).

The current workaround involves not setting the content length for HTTP/1.0 
connections. 

A quick fix inside the coyote code would be to detect the User-Agent and if is 
IE and the protocol is HTTP/1.0 close the connection.

Note that it works fine if instead of POST a GET is sent.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[Volunteer Needed] - TOMCAT-DEV Moderation

[Craig R. McClanahan]

I need a volunteer to take over moderation of the TOMCAT-DEV mailing list.
Basically, this involves replying "yes" or "no" to a message from the
mailing list server when non-subscribers attempt to post.  Most of this
kind of mail falls into the following categories:

  * Spam

  * Bug reports from non-subscribers (should be moderated through)

  * User questions (should be redirected to TOMCAT-USER).

Besides the fact that my primary job responsibilities are no longer
focused on Tomcat development, I'm going to be travelling next week
(JavaOne Japan) and will be unable to perform moderation duties in a
timely manner.

Any takers?

Craig McClanahan



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [ADDON] Jk2 uriMap using pcre (someone willing to check)

[Ignacio J. Ortega]

> De: Henri Gomez [mailto:[EMAIL PROTECTED]]
> Enviado el: 18 de septiembre de 2002 14:41

> >>
> >> Do you means that APR/APR-UTIL is a pre-requisite for ALL servers
> >> implementations ?
> > 
> > 
> > Yes. It would be.
> 
> That's partially bad, since we'll have with jk2 many questions about
> how to build apr/apr-util for platform (just remember webapp)
> 

Well, right now it's a matter of have the 2 dlls inthe same dir wher
it's i_r2.dll, not a very cumbersome nor very strange for a Win32 user,i
dont see a problem at all, and for the Win32 purist sake, we are Apache
so i dont see anything very bad and/or eat our own dogfood ..

Saludos ,
Ignacio J. Ortega


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [ADDON] Jk2 uriMap using pcre (someone willing to check)

[Ignacio J. Ortega]

> De: Mladen Turk [mailto:[EMAIL PROTECTED]]
> Enviado el: 17 de septiembre de 2002 19:20

> 
> [uri:/examples/(?!\w*\.(gif|jpg)$)]
> info=Map the whole webapp except *.gif and *.jpg files
> 
> [uri:/\w+\.jsp$]
> info=Map the extension

Yipeee! :) Really nice, i suppouse that every part of the uri
including the VS name would a RE, right? 


Saludos ,
Ignacio J. Ortega

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10982] - JNDI URL Handler class is missing in naming-resources.jar

[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=10982

JNDI URL Handler class is missing in naming-resources.jar

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Priority|Other   |Medium

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java

[bobh]

bobh2002/09/18 09:44:35

  Modified:.gump.xml
   coyote/src/java/org/apache/coyote Request.java
   http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  - This associates the socket with the Request.  This is so the
  CertificatesValve.verify() can tell where (which socket) the Request
  is comeing from.  Without this association, CertificatesValve.verify()
  returns with no SSL Handshake.
  - this change is in part based on feed back from; Vivek N. Yingxian
  Wang (JSSE), Craig M., Qingqing Ouyang
  
  Revision  ChangesPath
  1.8   +1 -0  jakarta-tomcat-connectors/gump.xml
  
  Index: gump.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/gump.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- gump.xml  7 Sep 2002 15:17:19 -   1.7
  +++ gump.xml  18 Sep 2002 16:44:35 -  1.8
  @@ -55,6 +55,7 @@
   
  
  +  
   
   
   
  
  
  
  1.14  +16 -0 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
  
  Index: Request.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- Request.java  9 Apr 2002 18:19:27 -   1.13
  +++ Request.java  18 Sep 2002 16:44:35 -  1.14
  @@ -73,6 +73,8 @@
   import org.apache.tomcat.util.http.ContentType;
   import org.apache.tomcat.util.http.Cookies;
   
  +import java.net.Socket;
  +
   /**
* This is a low-level, efficient representation of a server request. Most 
* fields are GC-free, expensive operations are delayed until the  user code 
  @@ -184,6 +186,9 @@
   
   private Response response;
   private ActionHook hook;
  +
  +private Socket socket;
  +
   // - Properties
   
   
  @@ -203,10 +208,21 @@
   return headers;
   }
   
  +/* Used to associate this Request with a socket.  Used later to do
  +   SSL related stuff. */
  +public Socket getSocket() {
  +return this.socket;
  +}
  +
  +public void setSocket(Socket socket) {
  +this.socket = socket;
  +}
  +
   
   public UDecoder getURLDecoder() {
   return urlDecoder;
   }
  +
   
   //  Request data 
   
  
  
  
  1.35  +3 -1  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- Http11Processor.java  8 Jul 2002 16:50:46 -   1.34
  +++ Http11Processor.java  18 Sep 2002 16:44:35 -  1.35
  @@ -602,8 +602,10 @@
   http11 = true;
   http09 = false;
   contentDelimitation = false;
  -if (sslSupport != null)
  +if (sslSupport != null) {
   request.scheme().setString("https");
  +request.setSocket( socket );
  +}
   
   MessageBytes protocolMB = request.protocol();
   if (protocolMB.equals(Constants.HTTP_11)) {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[BUG] jk2 jni doesn't work

[Mladen Turk]

OK this is a release showstopper!

Now I'm convinced that JNI doesn't work as it should :(
Done some serious tests with various JDK's and TC versions from 4.0.4
through 4.1.10

The jni works _only_ and ONLY if preceded by socket call meaning
[channel.socket]
[channel.jni]
works, but
[channel.jni]
[channel.socket]
doesn't work

I've traced the problem down to the MsgAjp constructor called from
JniHandler's createMsgContext member:

...
public MsgContext createMsgContext() {
if( nativeJkHandlerP==0 || apr==null  )
return null;

try {
MsgContext msgCtx=new MsgContext();
// THIS IS PASSED
System.err.println("JniHandler OK createMsgContext
MsgContext");

MsgAjp msg=new MsgAjp();
// NEWER GETS HERE
System.err.println("JniHandler OK createMsgContext MsgAjp");


} catch( Exception ex ) {
// DISPLAYS NOTHING!
ex.printStackTrace();
return null;
}
 ...


IMHO the reason is missing org.apache.commons.logging.LogFactory,
perhaps not loaded by the jni channel.
If someone more familiar with that can dig into and trace the problem it
would be great, or I'll simply delete all that 'unnecessary' *.Log
stuff, and use the System.err.

MT.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Tomcat 4.1.11 src

[Fenlason, Josh]

I am probably stupid, but how/where can I find the latest source for Tomcat 4.1.11?  
Thanks in advance.
,
Josh.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Killing Apache Processes Connected to Tomcat via mod_jk (Ajp13)

[John Moore]

TC Users:

I have a big production problem that I'm hoping someone in the group can
address.  Running Apache 1.3.26/mod_ssl with  Tomcat 4.0.4 and mod_jk
connector (4.0.4) on Sun Sparc servers.   I have processes in apache
which get stuck in a 'W' state for days while processing a servlet
request through Tomcat.This is intermittent, although seem to be
tied to database access over a WAN and availability (which I have zero
control).   These processes are killed with kill -3 .   Now for the
problem.

We have had two reported occurrences in two days where one person logs
in and gets a page back for someone else and one other a about month
ago.  I am trying to determine if killing the apache pids could leave
the Tomcat Ajp socket open to return its content to the next person that
connects.Besides having cache-control and pragma statements, all
tranmission is via SSL upon hitting the login page so I'm betting
against any external cache.

If someone knows the ins and outs of the Ajp13 connector and tomcat who
can address this I am eternally grateful.   Trying to reproduce has been
difficult and looking for any support before diving into the code.

I posted to this forum last week and didn't see it go through so I'm 
reposting.  

John Moore






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Tomcat on AS/400 (iSeries)

[Henri Gomez]

http://eservercomputing.com/iseries/archives/index.asp?a=1&id=67

It cover the current Tomcat (3.2.4), available on iSeries but
the wizard should be seen.

Regards


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12778] New: - NoSuchMethod Excp on putValue() and setAttribute methods of HttpSession

[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=12778

NoSuchMethod Excp on putValue() and setAttribute methods of HttpSession

   Summary: NoSuchMethod Excp on putValue() and setAttribute methods
of HttpSession
   Product: Tomcat 4
   Version: 4.1.9
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hello there

I am running the following servlet code on Tomcat 4.1.10 :

public void doGet(HttpServletRequest request,
HttpServletResponse response)
HttpSession sess = request.getSession();
sess.setAttribute("Test", new Object());

the last line generate NoSuchMethod exception. I get the same error at run time 
if I used the deprecated putValue instead.

If I do this : 

java.lang.reflect.Method met[] = sess.getClass().getMethods();
for (int j = 0 ; j < met.length ; j++) {
  out.println("Method " + j + " of HttpSession is " + met[j].getName() 
+ "");
}

This is what I get :
...
Method 10 of HttpSession is putValue
...
Method 14 of HttpSession is setAttribute

I first thought that this could be related to Tomcat not supporting the correct 
version of the Servlet API but Tomcat 4.1.10 supports Servlet 2.3 in which 
those methods are supported but with the above reflection is not so clear 
anymore.

Many Thanks in advance for your help and advices.

Best Regards - Cecil Dijoux.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12777] New: - NoSuchMethod Exception

[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=12777

NoSuchMethod Exception

   Summary: NoSuchMethod Exception
   Product: Tomcat 4
   Version: 4.1.9
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am running the following code on with Tomcat 4.1.10 :

HttpSession sess = request.getSession();
sess.setAttribute("Test", new Object());

the last line generate NoSuchMethod exception. I get the same error at run time 
if I used the deprecated putValue instead.

If I do this : 
java.lang.reflect.Method met[] = sess.getClass().getMethods();
for (int j = 0 ; j < met.length ; j++) {
out.println("Method " + j + " of HttpSession is " + met[j].getName() + "");
  }

This is what I get :
...
Method 10 of HttpSession is putValue
...
Method 14 of HttpSession is setAttribute

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[bobh]

bobh2002/09/18 08:10:04

  Modified:util/java/org/apache/tomcat/util/net JSSESocketFactory.java
  Log:
  - Trust store shouldn't be initialized from key store
  - removed conditional around trust store initialization, so when a
  CLIENT-CERT resource is requested, Tomcat has something to use for
  starting a a trusted negotiation
  - changes reflect input from Vivek N. Yingxian Wang (JSSE), Craig M.,
  Qingqing Ouyang
  
  Revision  ChangesPath
  1.2   +13 -7 
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/JSSESocketFactory.java
  
  Index: JSSESocketFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/JSSESocketFactory.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- JSSESocketFactory.java5 Apr 2002 17:43:33 -   1.1
  +++ JSSESocketFactory.java18 Sep 2002 15:10:04 -  1.2
  @@ -191,14 +191,20 @@
com.sun.net.ssl.KeyManagerFactory.getInstance(algorithm);
kmf.init( kstore, keyPass.toCharArray());
   
  - // If client authentication is needed, set up TrustManager
  + //  set up TrustManager
com.sun.net.ssl.TrustManager[] tm = null;
  - if( clientAuth) {
  - com.sun.net.ssl.TrustManagerFactory tmf =
  -com.sun.net.ssl.TrustManagerFactory.getInstance("SunX509");
  - tmf.init(kstore);
  - tm = tmf.getTrustManagers();
  - }
  + String trustStoreFile = System.getProperty("javax.net.ssl.trustStore");
  + String trustStorePassword =
  + System.getProperty("javax.net.ssl.trustStorePassword");
  + if ( trustStoreFile != null && trustStorePassword != null ){
  +KeyStore trustStore = initKeyStore( trustStoreFile, trustStorePassword);
  +
  +com.sun.net.ssl.TrustManagerFactory tmf =
  +com.sun.net.ssl.TrustManagerFactory.getInstance("SunX509");
  +
  +tmf.init(trustStore);
  +tm = tmf.getTrustManagers();
  +}
   
// init context with the key managers
context.init(kmf.getKeyManagers(), tm, 
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

JSR45

[Damian Frach]

Hi,

I am a member of the web app group of  the Forte tools.

Our group is responsible for the Tomcat integration with the 
Netbeans/Forte IDE.

We are now planning new features for the next Forte release. We have 
plans for a JSR45 implementation.
Can you give me information of your plans in this issue?

It will really help us.

Thanks, Damian.

-
Damian Frach   

Software Engineer, Forte Tools   
Software Platforms and Products   

[EMAIL PROTECTED]
[EMAIL PROTECTED]

Sun Microsystems Czech s.r.o.   
Evropska 33E   
160 00 Prague 6 - Dejvice   
Tel.:   +420 (2)   3300 - 9183
  3300 - 9311
Fax.:   +420 (2)   3300 - 9299   
Mobile: +420 (604) 6277 - 20

Private:
Tunelaru 328 Praha 5 - Zbraslav 15600
 Tel:  +420 (2)   57924924
Polni 10Stepankovice74728
 Tel:  +420 (653) 6750 - 27
-




-- 
-
Damian Frach

Software Engineer, Forte Tools  
Software Platforms and Products 

[EMAIL PROTECTED]
[EMAIL PROTECTED]

Sun Microsystems Czech s.r.o.   
Evropska 33E
160 00 Prague 6 - Dejvice   
Tel.:   +420 (2)   3300 - 9183
   3300 - 9311
Fax.:   +420 (2)   3300 - 9299  
Mobile: +420 (604) 6277 - 20

Private:
 Tunelaru 328 Praha 5 - Zbraslav 15600
  Tel:  +420 (2)   57924924
 Polni 10Stepankovice74728
  Tel:  +420 (653) 6750 - 27
-




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: tomcat 3.3.2 and JMX

[Henri Gomez]

Shannon Lal wrote:
> Henri,
> 
> Will you also be submitting any sample code with this?

MXInterceptor let you monitor Tomcat 3.3.2-dev from a JMX
console or via the http adaptor.

To monitor your own code running on tomcat, you need to
adapt what's present in MxInterceptor and DynamicMBeanProxy (JTC)

Regards



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12521] - HTML Manager cannot deploy war file with path="/"

[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=12521

HTML Manager cannot deploy war file with path="/"





--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 14:27 
---
Wow! I didn't mean so fast!
Thank you very much,
Gabriele

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12521] - HTML Manager cannot deploy war file with path="/"

[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=12521

HTML Manager cannot deploy war file with path="/"

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 14:16 ---
The fix will be in 4.1.11.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12053] - HTML Manager is not allowed to reset/start/stop the root context

[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=12053

HTML Manager is not allowed to reset/start/stop the root context

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 14:15 ---
The fix will be in 4.1.11.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets HTMLManagerServlet.java ManagerServlet.java

[remm]

remm2002/09/18 07:13:46

  Modified:catalina/src/share/org/apache/catalina/servlets
HTMLManagerServlet.java ManagerServlet.java
  Log:
  - Port patches.
  
  Revision  ChangesPath
  1.3   +7 -24 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
  
  Index: HTMLManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- HTMLManagerServlet.java   12 Sep 2002 06:44:25 -  1.2
  +++ HTMLManagerServlet.java   18 Sep 2002 14:13:45 -  1.3
  @@ -224,9 +224,6 @@
   
   for (int i = 0; i < contextPaths.length; i++) {
   String displayPath = contextPaths[i];
  -if (displayPath.equals("")) {
  -displayPath = "/";
  -}
   sortedContextPathsMap.put(displayPath, contextPaths[i]);
   }
   
  @@ -241,6 +238,9 @@
   String displayPath = (String) entry.getKey();
   String contextPath = (String) entry.getKey();
   Context context = deployer.findDeployedApp(contextPath);
  +if (displayPath.equals("")) {
  +displayPath = "/";
  +}
   
   if (context != null ) {
   args = new Object[6];
  @@ -269,14 +269,6 @@
   STOPPED_APPS_ROW_BUTTON_SECTION, args));
   }
   
  -} else if (displayPath.equals("/")) {
  -args = new Object[4];
  -args[0] = displayPath;
  -args[1] = "ROOT";
  -args[2] = new Boolean(true);
  -args[3] = "-";
  -writer.print
  -(MessageFormat.format(APPS_ROOT_ROW_SECTION, args));
   }
   }
   
  @@ -537,15 +529,6 @@
   "   {4}  \n" +
   "   \n" +
   "  \n" +
  -" \n";
  -
  -private static final String APPS_ROOT_ROW_SECTION =
  -" \n" +
  -" {0}\n" +
  -" {1} \n" +
  -" {2} \n" +
  -" {3} \n" +
  -"   \n" +
   " \n";
   
   private static final String INSTALL_SECTION =
  
  
  
  1.3   +6 -7  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java
  
  Index: ManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ManagerServlet.java   12 Sep 2002 06:44:25 -  1.2
  +++ ManagerServlet.java   18 Sep 2002 14:13:45 -  1.3
  @@ -502,9 +502,8 @@
   return;
   }
   String displayPath = path;
  -if (displayPath.equals("")) {
  -displayPath = "/";
  -}
  +if( path.equals("/") )
  +path = "";
   String basename = null;
   if (path.equals("")) {
   basename = "_";
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servletsHTMLManagerServlet.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
> remm2002/09/18 07:08:34
> 
>   Modified:catalina/src/share/org/apache/catalina/servlets
> HTMLManagerServlet.java
>   Log:
>   - Allow the HTML manager to manipulate the root webapp.
>   - Fix bug 12053.
- Submitted by Chad Johnson 

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets HTMLManagerServlet.java

[remm]

remm2002/09/18 07:08:34

  Modified:catalina/src/share/org/apache/catalina/servlets
HTMLManagerServlet.java
  Log:
  - Allow the HTML manager to manipulate the root webapp.
  - Fix bug 12053.
  
  Revision  ChangesPath
  1.12  +7 -24 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
  
  Index: HTMLManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- HTMLManagerServlet.java   12 Sep 2002 07:07:27 -  1.11
  +++ HTMLManagerServlet.java   18 Sep 2002 14:08:34 -  1.12
  @@ -224,9 +224,6 @@
   
   for (int i = 0; i < contextPaths.length; i++) {
   String displayPath = contextPaths[i];
  -if (displayPath.equals("")) {
  -displayPath = "/";
  -}
   sortedContextPathsMap.put(displayPath, contextPaths[i]);
   }
   
  @@ -241,6 +238,9 @@
   String displayPath = (String) entry.getKey();
   String contextPath = (String) entry.getKey();
   Context context = deployer.findDeployedApp(contextPath);
  +if (displayPath.equals("")) {
  +displayPath = "/";
  +}
   
   if (context != null ) {
   args = new Object[6];
  @@ -272,14 +272,6 @@
   STOPPED_APPS_ROW_BUTTON_SECTION, args));
   }
   
  -} else if (displayPath.equals("/")) {
  -args = new Object[4];
  -args[0] = displayPath;
  -args[1] = "ROOT";
  -args[2] = new Boolean(true);
  -args[3] = "-";
  -writer.print
  -(MessageFormat.format(APPS_ROOT_ROW_SECTION, args));
   }
   }
   
  @@ -551,15 +543,6 @@
   "   {4}  \n" +
   "   \n" +
   "  \n" +
  -" \n";
  -
  -private static final String APPS_ROOT_ROW_SECTION =
  -" \n" +
  -" {0}\n" +
  -" {1} \n" +
  -" {2} \n" +
  -" {3} \n" +
  -"   \n" +
   " \n";
   
   private static final String INSTALL_SECTION =
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [ADDON] Jk2 uriMap using pcre (someone willing to check)

[Mladen Turk]

> From: jean-frederic clere 
> 
> Henri Gomez wrote:
> >>> That's jk2 (including IIS/NES) and not just Apache 1.3/2.0 since 
> >>> these files are in common and used for example in isapi 
> >>> implementation.
> >>>
> >>> Do you means that APR/APR-UTIL is a pre-requisite for ALL servers 
> >>> implementations ?
> >>
> >> Yes. It would be.
> > 
> > 
> > That's partially bad, since we'll have with jk2 many 
> questions about 
> > how to build apr/apr-util for platform (just remember webapp)
> 
> I know that mod_webapp was a _too_ early user of APR but now 
> the risks are lower.
>

And there is quite usable documentation at http://apr.apache.org/ that
will solve most of the RTFM and STFW answers :).
 
MT.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets ManagerServlet.java

[remm]

remm2002/09/18 07:00:44

  Modified:catalina/src/share/org/apache/catalina/servlets
ManagerServlet.java
  Log:
  - Fix bug 12521. The check is reversed.
  - Submitted by Gabriele Garuglieri 
  
  Revision  ChangesPath
  1.28  +6 -7  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java
  
  Index: ManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- ManagerServlet.java   12 Sep 2002 07:07:27 -  1.27
  +++ ManagerServlet.java   18 Sep 2002 14:00:44 -  1.28
  @@ -502,9 +502,8 @@
   return;
   }
   String displayPath = path;
  -if (displayPath.equals("")) {
  -displayPath = "/";
  -}
  +if( path.equals("/") )
  +path = "";
   String basename = null;
   if (path.equals("")) {
   basename = "_";
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12521] - HTML Manager cannot deploy war file with path="/"

[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=12521

HTML Manager cannot deploy war file with path="/"





--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 13:58 ---
This bug has alot in common with:

http://issues.apache.org/bugzilla/show_bug.cgi?id=12053

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources FileDirContext.java

[remm]

remm2002/09/18 06:54:33

  Modified:catalina/src/share/org/apache/naming/resources
FileDirContext.java
  Log:
  - Case sensitivity check will always be made, based on the value of the flag,
regardless of this OS.
  - Add a flag to allow sym linking.
  - I'll wait to port the patch to 5.0 based on the feedback.
  
  Revision  ChangesPath
  1.14  +31 -7 
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/FileDirContext.java
  
  Index: FileDirContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- FileDirContext.java   17 Mar 2002 00:03:13 -  1.13
  +++ FileDirContext.java   18 Sep 2002 13:54:33 -  1.14
  @@ -154,6 +154,12 @@
   protected boolean caseSensitive = true;
   
   
  +/**
  + * Allow linking.
  + */
  +protected boolean allowLinking = false;
  +
  +
   // - Properties
   
   
  @@ -208,6 +214,22 @@
   }
   
   
  +/**
  + * Set allow linking.
  + */
  +public void setAllowLinking(boolean allowLinking) {
  +this.allowLinking = allowLinking;
  +}
  +
  +
  +/**
  + * Is linking allowed.
  + */
  +public boolean getAllowLinking() {
  +return allowLinking;
  +}
  +
  +
   // - Public Methods
   
   
  @@ -217,6 +239,7 @@
   public void release() {
   
   caseSensitive = true;
  +allowLinking = false;
   absoluteBase = null;
   base = null;
   super.release();
  @@ -866,12 +889,13 @@
   if (canPath == null)
   return null;
   
  -if (!canPath.startsWith(absoluteBase)) {
  +// Check to see if going outside of the web application root
  +if ((!allowLinking) && (!canPath.startsWith(absoluteBase))) {
   return null;
   }
   
  -// Windows only check
  -if ((caseSensitive) && (File.separatorChar  == '\\')) {
  +// Case sensitivity check
  +if (caseSensitive) {
   String fileAbsPath = file.getAbsolutePath();
   if (fileAbsPath.endsWith("."))
   fileAbsPath = fileAbsPath + "/";
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [ADDON] Jk2 uriMap using pcre (someone willing to check)

[jean-frederic clere]

Henri Gomez wrote:
>>> That's jk2 (including IIS/NES) and not just Apache 1.3/2.0 since these
>>> files are in common and used for example in isapi implementation.
>>>
>>> Do you means that APR/APR-UTIL is a pre-requisite for ALL servers
>>> implementations ?
>>
>>
>>
>> Yes. It would be.
> 
> 
> That's partially bad, since we'll have with jk2 many questions about
> how to build apr/apr-util for platform (just remember webapp)

I know that mod_webapp was a _too_ early user of APR but now the risks are lower.

> 
 But you are right we only require APR until now, but APR-UTIL should 
 not bring additional problems.
>>>
>>>
>>>
>>>
>>> Yep, but I'd like to avoid the chicken-eggs problems of mod_webapp
>>> which required APR to be built and as such was only available for 
>>> Apache Web Servers.
>>
>>
>>
>> APR has reached 0.9. So APR binaries will be available one day for all 
>> supported platforms.
> 
> 
> 0.9.1 but still no binaries (Windows/Linux/MacOSX for examples) there :
> 
> http://www.apache.org/dist/apr/
> 

APR is still alpha.

> 
> 
> 
> 
> -- 
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12521] - HTML Manager cannot deploy war file with path="/"

[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=12521

HTML Manager cannot deploy war file with path="/"

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Major
   Priority|Other   |High



--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 13:44 
---
Sorry to bother you, but i raised priority and severity of this bug because i 
need to implement some production procedures based on the correct behaviour of 
manager deploy command, and i need at least an acknowledge to know if you are 
going to implement this fix in a future release.
I don't need a quick fix, the patch i have done already give me the correct 
results, for the moment i only need to be sure that the fix will be included in 
the standard distribution.
Thanks,  Gabriele

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: tomcat 3.3.2 and JMX

[Shannon Lal]

Henri,

Will you also be submitting any sample code with this?

Thanks Nin


>From: Henri Gomez <[EMAIL PROTECTED]>
>Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: tomcat 3.3.2 and JMX
>Date: Wed, 18 Sep 2002 09:51:40 +0200
>
>Hi to all,
>
>I've fixed MXInterceptor for Tomcat 3.3.2-dev which will now
>be able to use JMX stuff present in JTC.
>
>To enable it, just add in server.xml
>
>
>
>To use the jmx http adaptor add port :
>
>
>
>if you're using mx4j, you could also specify listen host :
>
>
>
>Be sure to have mx4j.jar and mx4j-tools in lib/container.
>
>Regards
>
>PS: Code will be commited ASAP
>
>
>--
>To unsubscribe, e-mail:   
>
>For additional commands, e-mail: 
>




_
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12771] - [PATCH] IllegalStateException on include of non-mapped mimetype

[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=12771

[PATCH] IllegalStateException on include of non-mapped mimetype

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 13:18 ---
I have applied the patch. This will be in 4.1.11.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java

[remm]

remm2002/09/18 06:17:31

  Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
  Log:
  - Port patch.
  
  Revision  ChangesPath
  1.2   +6 -6  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
  
  Index: DefaultServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- DefaultServlet.java   18 Jul 2002 16:47:40 -  1.1
  +++ DefaultServlet.java   18 Sep 2002 13:17:31 -  1.2
  @@ -1023,8 +1023,8 @@
   } catch (IllegalStateException e) {
   // If it fails, we try to get a Writer instead if we're
   // trying to serve a text file
  -if ( (contentType != null)
  - && (contentType.startsWith("text")) ) {
  +if ( (contentType == null)
  + || (contentType.startsWith("text")) ) {
   writer = response.getWriter();
   } else {
   throw e;
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java

[remm]

remm2002/09/18 06:16:39

  Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
  Log:
  - Relax the writer use policy to allow including files with unknown
MIME types, which in that case will be assumed to be text. This is to make
Tomcat more user friendly, although this has potential for some misuse.
  - Patch submitted by Tim Funk 
  
  Revision  ChangesPath
  1.58  +6 -6  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
  
  Index: DefaultServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
  retrieving revision 1.57
  retrieving revision 1.58
  diff -u -r1.57 -r1.58
  --- DefaultServlet.java   14 Jun 2002 03:19:43 -  1.57
  +++ DefaultServlet.java   18 Sep 2002 13:16:39 -  1.58
  @@ -1023,8 +1023,8 @@
   } catch (IllegalStateException e) {
   // If it fails, we try to get a Writer instead if we're
   // trying to serve a text file
  -if ( (contentType != null)
  - && (contentType.startsWith("text")) ) {
  +if ( (contentType == null)
  + || (contentType.startsWith("text")) ) {
   writer = response.getWriter();
   } else {
   throw e;
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12771] - [PATCH] IllegalStateException on include of non-mapped mimetype

[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=12771

[PATCH] IllegalStateException on include of non-mapped mimetype





--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 13:13 ---
Ok, I am willing to apply the patch to avoid user complaints. Now, it should be
clear that if you try to include a binary, this will not produce any useful results.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12771] - [PATCH] IllegalStateException on include of non-mapped mimetype

[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=12771

[PATCH] IllegalStateException on include of non-mapped mimetype





--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 13:11 ---
Created an attachment (id=3116)
Patch of org/apache/catalina/servlets/DefaultServlet.java

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12771] New: - [PATCH] IllegalStateException on include of non-mapped mimetype

[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=12771

[PATCH] IllegalStateException on include of non-mapped mimetype

   Summary: [PATCH] IllegalStateException on include of non-mapped
mimetype
   Product: Tomcat 4
   Version: Nightly Build
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


An IllegalState exception is thrown on .include() if the included file has an
extension not mapped to any mime types.

To reproduce: 
- create 2 files foo.jsp and foo.nomimetype
- foo.jsp has 1 line  
- foo.nomimetype can be any file with "stuff" text prefered
- accessing foo.jsp throws IllegalException error

Temporary Workaround:
Adding a mime-type mapping in web.xml for file extension "nomimetype" alleviates
the problem.

Patch will be attached to fix DefaultServlet. Currently it does this:

try {
ostream = response.getOutputStream();
} catch (IllegalStateException e) {
// If it fails, we try to get a Writer instead if we're
// trying to serve a text file
if ( (contentType != null)
 && (contentType.startsWith("text")) ) {
writer = response.getWriter();
} else {
throw e;
}
}

So if NO mime type is mapped, an exception will be thrown. My patch will change
++
if ( (contentType != null)
 && (contentType.startsWith("text")) ) {
++
to
++
if ( (contentType == null)
 || (contentType.startsWith("text")) ) {
++

So on not finding a mime-type it will default to obtaining a the Writer. 

This will be helpful for people who use .inc as a text include but don't have it
mapped.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-5 build.xml tomcat.nsi

[remm]

remm2002/09/18 06:03:37

  Modified:.build.xml tomcat.nsi
  Log:
  - Make the installer look more modern. More will be done, but the functionality
will likely change before NSIS 2 final.
  
  Revision  ChangesPath
  1.34  +2 -0  jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- build.xml 27 Aug 2002 13:20:49 -  1.33
  +++ build.xml 18 Sep 2002 13:03:36 -  1.34
  @@ -368,6 +368,8 @@
 
   
   
  +
   
   
   mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

Re: [ADDON] Jk2 uriMap using pcre (someone willing to check)

[Henri Gomez]

>> That's jk2 (including IIS/NES) and not just Apache 1.3/2.0 since these
>> files are in common and used for example in isapi implementation.
>>
>> Do you means that APR/APR-UTIL is a pre-requisite for ALL servers
>> implementations ?
> 
> 
> Yes. It would be.

That's partially bad, since we'll have with jk2 many questions about
how to build apr/apr-util for platform (just remember webapp)

>>> But you are right we only require APR until now, but APR-UTIL should 
>>> not bring additional problems.
>>
>>
>>
>> Yep, but I'd like to avoid the chicken-eggs problems of mod_webapp
>> which required APR to be built and as such was only available for 
>> Apache Web Servers.
> 
> 
> APR has reached 0.9. So APR binaries will be available one day for all 
> supported platforms.

0.9.1 but still no binaries (Windows/Linux/MacOSX for examples) there :

http://www.apache.org/dist/apr/





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [ADDON] Jk2 uriMap using pcre (someone willing to check)

[Mladen Turk]

> -Original Message-
> From: Henri Gomez [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, September 18, 2002 1:15 PM
> To: Tomcat Developers List
> Subject: Re: [ADDON] Jk2 uriMap using pcre (someone willing to check)
> 
> 
> That's jk2 (including IIS/NES) and not just Apache 1.3/2.0 
> since these files are in common and used for example in isapi 
> implementation.
> 
> Do you means that APR/APR-UTIL is a pre-requisite for ALL 
> servers implementations ?
>

Think it is... The IIS and Apache 2.0 jk2 are built and linked with apr
and apr-util.
Not sure about default for 1.3.
 
Is this a problem?

MT.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [ADDON] Jk2 uriMap using pcre (someone willing to check)

[jean-frederic clere]

Henri Gomez wrote:
> jean-frederic clere wrote:
> 
>> Henri Gomez wrote:
>>

 

 All the pcre related code from httd's util.c IMO can be moved to the
 apr-util.
>>>
>>>
>>>
>>>
>>> IIS/NES implemtation of jk will need pcre as shared libs / dll,
>>> so we'll have to update makefiles and documentations
>>
>>
>>
>> That is mod_jk2...
> 
> 
> That's jk2 (including IIS/NES) and not just Apache 1.3/2.0 since these
> files are in common and used for example in isapi implementation.
> 
> Do you means that APR/APR-UTIL is a pre-requisite for ALL servers
> implementations ?

Yes. It would be.

> 
>> But you are right we only require APR until now, but APR-UTIL should 
>> not bring additional problems.
> 
> 
> Yep, but I'd like to avoid the chicken-eggs problems of mod_webapp
> which required APR to be built and as such was only available for Apache 
> Web Servers.

APR has reached 0.9. So APR binaries will be available one day for all supported 
platforms.

> 
> 
> 
> 
> 
> -- 
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/bufDateTool.java

[Henri Gomez]

> The upshot is that DateFormats need to be either thread local, or created new 
> each time.

Created each time is exactly what we want to avoid ;)



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf DateTool.java

[Steve Downey]

OK, ignore my last message.

But, it's not just less paranoid. It's more correct. If rfc1123Format were 
used elsewhere, the lock on Class.DateTool would not be sufficient. 

Actually, refreshing my memory on this bug, synchronization is insufficient.

http://developer.java.sun.com/developer/bugParade/bugs/4228335.html

The upshot is that DateFormats need to be either thread local, or created new 
each time.

On Wednesday 18 September 2002 12:20 am, [EMAIL PROTECTED] wrote:
> billbarker2002/09/17 21:20:24
>
>   Modified:util/java/org/apache/tomcat/util/buf DateTool.java
>   Log:
>   A little less paraniod than the last one, but functionally the same.
>
>   Revision  ChangesPath
>   1.7   +6 -2 
> jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/DateTool.jav
>a
>
>   Index: DateTool.java
>   ===
>   RCS file:
> /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/Da
>teTool.java,v retrieving revision 1.6
>   retrieving revision 1.7
>   diff -u -r1.6 -r1.7
>   --- DateTool.java   18 Sep 2002 03:50:04 -  1.6
>   +++ DateTool.java   18 Sep 2002 04:20:24 -  1.7
>   @@ -141,8 +141,12 @@
>// Called from MessageBytes.setTime
>/**
> */
>   -public static synchronized String format1123( Date d ) {
>   -   return format1123(d, rfc1123Format);
>   +public static String format1123( Date d ) {
>   +   String dstr=null;
>   +   synchronized(rfc1123Format) {
>   +   dstr = format1123(d, rfc1123Format);
>   +   }
>   +   return dstr;
>}
>
>public static String format1123( Date d,DateFormat df ) {


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf DateTool.java

[Steve Downey]

I think that should probably be
   public static String format1123( Date d ) {
synchronized(rfc1123Format) {
return format1123(d, rfc1123Format);
}
   }

Synching on 'this' is overkill.

On Tuesday 17 September 2002 11:50 pm, [EMAIL PROTECTED] wrote:
> billbarker2002/09/17 20:50:05
>
>   Modified:util/java/org/apache/tomcat/util/buf DateTool.java
>   Log:
>   Fix thread-safe issue on date formatting.
>
>   Reported by: Hugh J. L. [EMAIL PROTECTED]
>
>   Revision  ChangesPath
>   1.6   +2 -7 
> jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/DateTool.jav
>a
>
>   Index: DateTool.java
>   ===
>   RCS file:
> /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/Da
>teTool.java,v retrieving revision 1.5
>   retrieving revision 1.6
>   diff -u -r1.5 -r1.6
>   --- DateTool.java   22 Mar 2002 04:12:01 -  1.5
>   +++ DateTool.java   18 Sep 2002 03:50:04 -  1.6
>   @@ -141,13 +141,8 @@
>// Called from MessageBytes.setTime
>/**
> */
>   -public static String format1123( Date d ) {
>   -long dt = d.getTime() / 1000;
>   -if ((rfc1123DS != null) && (dt == rfc1123Sec))
>   -return rfc1123DS;
>   -rfc1123DS  = rfc1123Format.format( d );
>   -rfc1123Sec = dt;
>   -return rfc1123DS;
>   +public static synchronized String format1123( Date d ) {
>   +   return format1123(d, rfc1123Format);
>}
>
>public static String format1123( Date d,DateFormat df ) {


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12766] - Tomcat should use tld files in /WEB-INF/ over version in jar

[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=12766

Tomcat should use tld files in /WEB-INF/ over version in jar

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Major   |Enhancement



--- Additional Comments From [EMAIL PROTECTED]  2002-09-18 11:46 ---
The spec only recommends that the classloader do not delegate first. TC 4.x is
supposed to not delegate first, however. TC 5 is likely to delegate always (not
delegating actually doesn't work).

--
To unsubscribe, e-mail:   
For additional commands, e-mail: