Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[jean-frederic clere]

Remy Maucherat wrote:
> 
> There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to
> start with some limited changes at first. Most of these proposed changes are
> Coyote-related (hence the subject of the message), and all involve some
> refactoring / API additions.
> 
> A) URI decoding refactoring. To avoid doing some URI decoding in many places
> in the pipeline, a decodedURI field (with associated getter/setter) should
> be added in the HttpRequest interface, and used in the Catalina pipeline.
> This also has the advantage to guarantee that no double URI decoding occurs
> (which can lead to URI-based security attacks).
> 
> 
> [X] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
> connector, which has many shortcoming (slow performance on output, HTTP
> handling limitations and extreme complexity). Initial tests results and
> benchmarks with Coyote are extremely positive so far.
> 
> 
> [X] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> C) Add better lifecycle handling in the resources. A start method is needed
> (which could be called 'allocate' to mirror the 'release' method), because
> it is currently not possible to restart a stopped context. In the 4.0
> branch, the patch introducing the 'release' method must either be reverted,
> or these proposed changes must also be ported to 4.0.
> Thanks to Jean-Francois Clere for the report and debugging of this problem.

Typo in my first name!
The bug is 6982. Porting the changes is what I prefer.

> 
> 
> [X] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
> be used for any new connector development. To make this more obvious, I'd
> like to deprecate all classes in this package and subpackages. The binaries
> will also be packaged in a separate JAR file (tentatively named
> catalina-legacy.jar). This package will continue to be maintained on a case
> by case basis. The facades will not be deprecated, and two new helper
> objects will be introduced to handle the need for "fake" req/resp when
> requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> more details).
> 
> 
> [X] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor
> interface. Otherwise, the processor has no way to cleanly handle logging.
> commons-logging is already used by other j-t-c components. At the moment,
> the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
> needs to be improved. When I originally designed most of the base
> interfaces, commons-logging didn't exist yet, and I didn't feel like adding
> yet another logging interface.
> 
> 
> [X] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> +1 for everything. Thanks for voting / commenting :)
> 
> Remy
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteConnector.java CoyoteProcessor.java

[remm]

remm02/03/12 23:42:11

  Modified:coyote/src/java/org/apache/coyote/tomcat4
CoyoteConnector.java CoyoteProcessor.java
  Log:
  - Add the URI normalization code from TC 4 used to protect against some URI
encoding based attacks. This may be useless in the HEAD branch after
the proposed URI decoding refactoring is done, so this code can be disabled.
It defaults to doing the checks, as some versions in the Tomcat 4.0.x branch
are very likely to need it.
  
  Revision  ChangesPath
  1.3   +32 -4 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java
  
  Index: CoyoteConnector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- CoyoteConnector.java  27 Feb 2002 08:24:08 -  1.2
  +++ CoyoteConnector.java  13 Mar 2002 07:42:11 -  1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java,v
 1.2 2002/02/27 08:24:08 remm Exp $
  - * $Revision: 1.2 $
  - * $Date: 2002/02/27 08:24:08 $
  + * $Header: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java,v
 1.3 2002/03/13 07:42:11 remm Exp $
  + * $Revision: 1.3 $
  + * $Date: 2002/03/13 07:42:11 $
*
* 
*
  @@ -103,7 +103,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.2 $ $Date: 2002/02/27 08:24:08 $
  + * @version $Revision: 1.3 $ $Date: 2002/03/13 07:42:11 $
*/
   
   
  @@ -326,6 +326,12 @@
   "org.apache.coyote.http11.Http11Processor";
   
   
  +/**
  + * Use URI normalization.
  + */
  +private boolean useURINormalizationHack = true;
  +
  +
   // - Properties
   
   
  @@ -820,6 +826,28 @@
   public void setTcpNoDelay(boolean tcpNoDelay) {
   
   this.tcpNoDelay = tcpNoDelay;
  +
  +}
  +
  +
  +/**
  + * Return the value of the Uri normalization flag.
  + */
  +public boolean getUseURINormalizationHack() {
  +
  +return (this.useURINormalizationHack);
  +
  +}
  +
  +
  +/**
  + * Set the value of the Uri normalization flag.
  + * 
  + * @param useURINormalizationHack The new flag value
  + */
  +public void setUseURINormalizationHack(boolean useURINormalizationHack) {
  +
  +this.useURINormalizationHack = useURINormalizationHack;
   
   }
   
  
  
  
  1.12  +102 -7
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteProcessor.java
  
  Index: CoyoteProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteProcessor.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- CoyoteProcessor.java  9 Mar 2002 17:40:01 -   1.11
  +++ CoyoteProcessor.java  13 Mar 2002 07:42:11 -  1.12
  @@ -1,6 +1,6 @@
  -/* * $Header: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteProcessor.java,v
 1.11 2002/03/09 17:40:01 remm Exp $
  - * $Revision: 1.11 $
  - * $Date: 2002/03/09 17:40:01 $
  +/* * $Header: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteProcessor.java,v
 1.12 2002/03/13 07:42:11 remm Exp $
  + * $Revision: 1.12 $
  + * $Date: 2002/03/13 07:42:11 $
*
* 
*
  @@ -112,7 +112,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.11 $ $Date: 2002/03/09 17:40:01 $
  + * @version $Revision: 1.12 $ $Date: 2002/03/13 07:42:11 $
*/
   
   final class CoyoteProcessor
  @@ -301,7 +301,7 @@
   try {
   // Parse and set Catalina and configuration specific 
   // request parameters
  -postParseRequest(req);
  +postParseRequest(req, res);
   // Calling the container
   connector.getContainer().invoke(request, response);
   response.finishResponse();
  @@ -370,7 +370,7 @@
   /**
* Parse additional request parameters.
*/
  -protected void postParseRequest(Request req)
  +protected void postParseRequest(Request req, Response res)
   throws IOException {
   
   request.setSocket(socket);
  @@ -385,6 +385,17 @@
   else
   request.setServerPort(serverPort);
   
  +// Normalize URI is needed for security reasons on older versions 
  +// of Tom

Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[Remy Maucherat]

> > A) URI decoding refactoring. To avoid doing some URI decoding in many
> places
> > in the pipeline, a decodedURI field (with associated getter/setter)
should
> > be added in the HttpRequest interface, and used in the Catalina
pipeline.
> > This also has the advantage to guarantee that no double URI decoding
> occurs
> > (which can lead to URI-based security attacks).
> >
> > 
> > [ ] +1
> > [X] +0 Already in the 3.3 code (and currently ignored in the 3.3
Adapter).
> > [ ] -1:

Good, then you'll be able to use that field in TC 3 (the HTTP/1.1 should now
populate it, and it uses the same decoder TC 3 uses; no surprise here).

Also, I'm about to add in the TC 4 adapter the code used in TC 4 to prevent
some URL based attacks (with a flag allowing to disable the checks, though,
as this may be useless in the HEAD branch after the proposed refactoring).
However, I know that TC 3.3 has that kind of nomalization code also, so
maybe you should check to be sure you don't need it (maybe in 3.3 it's not
part of the connector; I don't remember).

> > D) Deprecate the o.a.catalina.connector package. This package *SHOULD
NOT*
> > be used for any new connector development. To make this more obvious,
I'd
> > like to deprecate all classes in this package and subpackages. The
> binaries
> > will also be packaged in a separate JAR file (tentatively named
> > catalina-legacy.jar). This package will continue to be maintained on a
> case
> > by case basis. The facades will not be deprecated, and two new helper
> > objects will be introduced to handle the need for "fake" req/resp when
> > requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> > more details).
> >
> > 
> > [X] +1  I couldn't ever find the "fake" req/resp for 4518 (ok, in 3.3
> land, any class that ends in "Base" is an abstract class. ;-)
> > [ ] +0
> > [ ] -1:
> >
> > 

Here, I got lucky and was able to just use HttpRequestBase/HttpResponseBase,
just populate a few fields and have it work. Obviously, it is a complete
hack, so I plan to add some dummy request/response objects which could be
used for this instead.

> > E) Use commons-logging in Coyote, by adding a get/setLogger on the
> Processor
> > interface. Otherwise, the processor has no way to cleanly handle
logging.
> > commons-logging is already used by other j-t-c components. At the
moment,
> > the HTTP/1.1 processor "logs" problems as stack traces on the stderr;
this
> > needs to be improved. When I originally designed most of the base
> > interfaces, commons-logging didn't exist yet, and I didn't feel like
> adding
> > yet another logging interface.
> >
> > 
> > [X] +1 I'm guessing that Costin & Larry will have fits with this (TC 3.3
> currently has no dependencies on outside packages).  However, my support
is
> only if it gets into o.a.c.Processor.   It shouldn't be a http11 only
issue.
> > [ ] +0
> > [ ] -1:
> >
> > 

Yes, that's a good point. JK 2 is using commons-logging already, so I think
the dependency on that component is inevitable no matter what. I'd rather
live without it, but I'm very unhappy at the moment of having no logging at
all inside the processor.
Yes, the get/setLogger will go in the Processor interface.

Remy


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

Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[Bill Barker]

Disclaimer:
A +1 vote below does not necessarily mean that I'm going to pledge ongoing
support to o.a.c.tomcat4 (although it is very well done, and I relied
heavily on it for developing o.a.c.tomcat3). However, I do plan to support
o.a.c and o.a.c.http11.
- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 12, 2002 6:30 PM
Subject: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD


> There are many ways to take advantage of Coyote in Tomcat 4, but I'd like
to
> start with some limited changes at first. Most of these proposed changes
are
> Coyote-related (hence the subject of the message), and all involve some
> refactoring / API additions.
>
> A) URI decoding refactoring. To avoid doing some URI decoding in many
places
> in the pipeline, a decodedURI field (with associated getter/setter) should
> be added in the HttpRequest interface, and used in the Catalina pipeline.
> This also has the advantage to guarantee that no double URI decoding
occurs
> (which can lead to URI-based security attacks).
>
> 
> [ ] +1
> [X] +0 Already in the 3.3 code (and currently ignored in the 3.3 Adapter).
> [ ] -1:
>
> 
>
> B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
> connector, which has many shortcoming (slow performance on output, HTTP
> handling limitations and extreme complexity). Initial tests results and
> benchmarks with Coyote are extremely positive so far.
>
> 
> [X] +1
> [ ] +0
> [ ] -1:
>
> 
>
> C) Add better lifecycle handling in the resources. A start method is
needed
> (which could be called 'allocate' to mirror the 'release' method), because
> it is currently not possible to restart a stopped context. In the 4.0
> branch, the patch introducing the 'release' method must either be
reverted,
> or these proposed changes must also be ported to 4.0.
> Thanks to Jean-Francois Clere for the report and debugging of this
problem.
>
> 
> [X] +1
> [ ] +0
> [ ] -1:
>
> 
>
> D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
> be used for any new connector development. To make this more obvious, I'd
> like to deprecate all classes in this package and subpackages. The
binaries
> will also be packaged in a separate JAR file (tentatively named
> catalina-legacy.jar). This package will continue to be maintained on a
case
> by case basis. The facades will not be deprecated, and two new helper
> objects will be introduced to handle the need for "fake" req/resp when
> requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> more details).
>
> 
> [X] +1  I couldn't ever find the "fake" req/resp for 4518 (ok, in 3.3
land, any class that ends in "Base" is an abstract class. ;-)
> [ ] +0
> [ ] -1:
>
> 
>
> E) Use commons-logging in Coyote, by adding a get/setLogger on the
Processor
> interface. Otherwise, the processor has no way to cleanly handle logging.
> commons-logging is already used by other j-t-c components. At the moment,
> the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
> needs to be improved. When I originally designed most of the base
> interfaces, commons-logging didn't exist yet, and I didn't feel like
adding
> yet another logging interface.
>
> 
> [X] +1 I'm guessing that Costin & Larry will have fits with this (TC 3.3
currently has no dependencies on outside packages).  However, my support is
only if it gets into o.a.c.Processor.   It shouldn't be a http11 only issue.
> [ ] +0
> [ ] -1:
>
> 
>
> +1 for everything. Thanks for voting / commenting :)
>
> Remy
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[Bill Barker]

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, March 12, 2002 9:26 PM
Subject: Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD


> > on 3/12/02 6:30 PM, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:
> >
> > > A) URI decoding refactoring. To avoid doing some URI decoding in many
> places
> > > in the pipeline, a decodedURI field (with associated getter/setter)
> should
> > > be added in the HttpRequest interface, and used in the Catalina
> pipeline.
> > > This also has the advantage to guarantee that no double URI decoding
> occurs
> > > (which can lead to URI-based security attacks).
> > >
> > > 
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1:
> > >
> > > 
> >
> > Q: How can you modify the Servlet API interfaces?
>
> Well, it's not Http*Servlet*Request ;-)
> It's the internal Catalina API, and I'm just proposing to add a method to
it
> (servlets can't access it, but components of the Catalina core can).
>

+1 by the way.

Jon is confusing issues here.  The "encoding" here refers to URLs like:
/foobar/%3F.jsp

The methods request.encodeURL(...) work (much/exactly) the same in Coyote
4.x and 3.x as they did before.

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

> For additional commands, e-mail:

>


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

RE: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[costinm]

On Wed, 13 Mar 2002, GOMEZ Henri wrote:

> +1, share code, share code.
> 
> I'll be +1 to have it also in 3.3.2 

'decodedRequest' is already there, commons-logging is trivial to
add.  The lifecycle of modules is also fine, the only problem is the 
ordering of modules - but so far it is under control, even if not 
perfect, and the hooks are in to allow an interceptor to fully control the
ordering of each chain.

Costin



> >-Original Message-
> >From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> >Sent: Wednesday, March 13, 2002 3:30 AM
> >To: [EMAIL PROTECTED]
> >Subject: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
> >
> >
> >There are many ways to take advantage of Coyote in Tomcat 4, 
> >but I'd like to
> >start with some limited changes at first. Most of these 
> >proposed changes are
> >Coyote-related (hence the subject of the message), and all involve some
> >refactoring / API additions.
> >
> >A) URI decoding refactoring. To avoid doing some URI decoding 
> >in many places
> >in the pipeline, a decodedURI field (with associated 
> >getter/setter) should
> >be added in the HttpRequest interface, and used in the 
> >Catalina pipeline.
> >This also has the advantage to guarantee that no double URI 
> >decoding occurs
> >(which can lead to URI-based security attacks).
> >
> >
> >[ ] +1
> >[ ] +0
> >[ ] -1:
> >
> >
> >
> >B) Use Coyote as the default HTTP connector in 4.0-HEAD, 
> >replacing the old
> >connector, which has many shortcoming (slow performance on output, HTTP
> >handling limitations and extreme complexity). Initial tests results and
> >benchmarks with Coyote are extremely positive so far.
> >
> >
> >[ ] +1
> >[ ] +0
> >[ ] -1:
> >
> >
> >
> >C) Add better lifecycle handling in the resources. A start 
> >method is needed
> >(which could be called 'allocate' to mirror the 'release' 
> >method), because
> >it is currently not possible to restart a stopped context. In the 4.0
> >branch, the patch introducing the 'release' method must either 
> >be reverted,
> >or these proposed changes must also be ported to 4.0.
> >Thanks to Jean-Francois Clere for the report and debugging of 
> >this problem.
> >
> >
> >[ ] +1
> >[ ] +0
> >[ ] -1:
> >
> >
> >
> >D) Deprecate the o.a.catalina.connector package. This package 
> >*SHOULD NOT*
> >be used for any new connector development. To make this more 
> >obvious, I'd
> >like to deprecate all classes in this package and subpackages. 
> >The binaries
> >will also be packaged in a separate JAR file (tentatively named
> >catalina-legacy.jar). This package will continue to be 
> >maintained on a case
> >by case basis. The facades will not be deprecated, and two new helper
> >objects will be introduced to handle the need for "fake" req/resp when
> >requesting a JSP precompilation with a load-on-startup (see 
> >bug 4518 for
> >more details).
> >
> >
> >[ ] +1
> >[ ] +0
> >[ ] -1:
> >
> >
> >
> >E) Use commons-logging in Coyote, by adding a get/setLogger on 
> >the Processor
> >interface. Otherwise, the processor has no way to cleanly 
> >handle logging.
> >commons-logging is already used by other j-t-c components. At 
> >the moment,
> >the HTTP/1.1 processor "logs" problems as stack traces on the 
> >stderr; this
> >needs to be improved. When I originally designed most of the base
> >interfaces, commons-logging didn't exist yet, and I didn't 
> >feel like adding
> >yet another logging interface.
> >
> >
> >[ ] +1
> >[ ] +0
> >[ ] -1:
> >
> >
> >
> >+1 for everything. Thanks for voting / commenting :)
> >
> >Remy
> >
> >
> >--
> >To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


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

RE: mod_jk (1.2) enhancements

[GOMEZ Henri]

 
>> You're right it's better :
>> 
>> worker.ajp13.logRequest={The Proposed JkRequestLogFormat}
>> 
>> ie
>> 
>> worker.ajp13.logRequest="%b %w"
>> 
>> 
>
>
>The new JkRequestLogFormat scopes at the Apache VirtualHost,
>so you can specifiy different request logging formats for
>different virtual hosts.  The above wouldn't allow that.

You're rigth but it will help having different logs for 
differents workers which may help monitor speed of 
differents tomcat.

worker.ajp13.logRequest="%b %w"
worker.ajp13.logPath="/var/log/tomcat/ajp13_access.log"

worker.ajp12.logRequest="%b %w"
worker.ajp12.logPath="/var/log/tomcat/ajp12_access.log"

Ok, I know that %w give worker name, but that way it
will be portable to non Apache Web Server.

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

RE: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[GOMEZ Henri]

+1, share code, share code.

I'll be +1 to have it also in 3.3.2 

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, March 13, 2002 3:30 AM
>To: [EMAIL PROTECTED]
>Subject: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
>
>
>There are many ways to take advantage of Coyote in Tomcat 4, 
>but I'd like to
>start with some limited changes at first. Most of these 
>proposed changes are
>Coyote-related (hence the subject of the message), and all involve some
>refactoring / API additions.
>
>A) URI decoding refactoring. To avoid doing some URI decoding 
>in many places
>in the pipeline, a decodedURI field (with associated 
>getter/setter) should
>be added in the HttpRequest interface, and used in the 
>Catalina pipeline.
>This also has the advantage to guarantee that no double URI 
>decoding occurs
>(which can lead to URI-based security attacks).
>
>
>[ ] +1
>[ ] +0
>[ ] -1:
>
>
>
>B) Use Coyote as the default HTTP connector in 4.0-HEAD, 
>replacing the old
>connector, which has many shortcoming (slow performance on output, HTTP
>handling limitations and extreme complexity). Initial tests results and
>benchmarks with Coyote are extremely positive so far.
>
>
>[ ] +1
>[ ] +0
>[ ] -1:
>
>
>
>C) Add better lifecycle handling in the resources. A start 
>method is needed
>(which could be called 'allocate' to mirror the 'release' 
>method), because
>it is currently not possible to restart a stopped context. In the 4.0
>branch, the patch introducing the 'release' method must either 
>be reverted,
>or these proposed changes must also be ported to 4.0.
>Thanks to Jean-Francois Clere for the report and debugging of 
>this problem.
>
>
>[ ] +1
>[ ] +0
>[ ] -1:
>
>
>
>D) Deprecate the o.a.catalina.connector package. This package 
>*SHOULD NOT*
>be used for any new connector development. To make this more 
>obvious, I'd
>like to deprecate all classes in this package and subpackages. 
>The binaries
>will also be packaged in a separate JAR file (tentatively named
>catalina-legacy.jar). This package will continue to be 
>maintained on a case
>by case basis. The facades will not be deprecated, and two new helper
>objects will be introduced to handle the need for "fake" req/resp when
>requesting a JSP precompilation with a load-on-startup (see 
>bug 4518 for
>more details).
>
>
>[ ] +1
>[ ] +0
>[ ] -1:
>
>
>
>E) Use commons-logging in Coyote, by adding a get/setLogger on 
>the Processor
>interface. Otherwise, the processor has no way to cleanly 
>handle logging.
>commons-logging is already used by other j-t-c components. At 
>the moment,
>the HTTP/1.1 processor "logs" problems as stack traces on the 
>stderr; this
>needs to be improved. When I originally designed most of the base
>interfaces, commons-logging didn't exist yet, and I didn't 
>feel like adding
>yet another logging interface.
>
>
>[ ] +1
>[ ] +0
>[ ] -1:
>
>
>
>+1 for everything. Thanks for voting / commenting :)
>
>Remy
>
>
>--
>To unsubscribe, e-mail:   

For additional commands, e-mail: 


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

RE: mod_jk (1.2) enhancements

[GOMEZ Henri]

>I'm ok with dropping "request" from the JkLogLevel, though I wish
>someone had said something when I first proposed this. :-)

No the idea is excellent, but it will be more usefull to get this
feature in a separate logfile (httpd use error, access) as does
mod_gzip.


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

Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[Remy Maucherat]

> on 3/12/02 6:30 PM, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:
>
> > A) URI decoding refactoring. To avoid doing some URI decoding in many
places
> > in the pipeline, a decodedURI field (with associated getter/setter)
should
> > be added in the HttpRequest interface, and used in the Catalina
pipeline.
> > This also has the advantage to guarantee that no double URI decoding
occurs
> > (which can lead to URI-based security attacks).
> >
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1:
> >
> > 
>
> Q: How can you modify the Servlet API interfaces?

Well, it's not Http*Servlet*Request ;-)
It's the internal Catalina API, and I'm just proposing to add a method to it
(servlets can't access it, but components of the Catalina core can).

Remy


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

RE: mod_jk (1.2) enhancements

[GOMEZ Henri]

>The priority is "emerg,warning,request,info,debug".
>
>Your though is that someone might want just request loggin without
>emerg and warning?

Yep, you could even have this kind of log in a separate log file
for statistic, that's what is used for example by mod_gzip.
Very very usefull when you want to make stats from this file alone.

>
>I'll let the core j-t-c committers worry about that. :-)
>
:-)

>No, Here is an example JkAutoAlias config:
>
>JkAutoAlias /usr/local/tomcat/webapps
>
>Any context dir found in the above directory is automatically aliased
>into the apache document root for the virtual host.
>
>So if the above webapps directory had the context dirs
>
>examples
>admin
>foobar

Do you also handle ROOT subdir and map it to / ?

>The equivalent apache aliases would be
>
>Alias /examples /usr/local/tomcat/webapps/examples
>Alias /admin /usr/local/tomcat/webapps/admin
>Alias /foobar /usr/local/tomcat/webapps/foobar
>
>Using JkAutoAlias saves you from having to configure an apache
>Alias for each context dir and automatically handles any new context
>dirs you add to the webapp directory.
>
>Attached, Enjoy!
>

Not found

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

Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[Jon Scott Stevens]

on 3/12/02 6:30 PM, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:

> A) URI decoding refactoring. To avoid doing some URI decoding in many places
> in the pipeline, a decodedURI field (with associated getter/setter) should
> be added in the HttpRequest interface, and used in the Catalina pipeline.
> This also has the advantage to guarantee that no double URI decoding occurs
> (which can lead to URI-based security attacks).
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 

Q: How can you modify the Servlet API interfaces?

-jon


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

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs jndi-resources-howto.xml

[craigmcc]

craigmcc02/03/12 20:13:34

  Modified:webapps/tomcat-docs jndi-resources-howto.xml
  Log:
  Update JNDI documentation to reflect the switch from Tyrex to DBCP for default
  connection pool support.
  
  Revision  ChangesPath
  1.12  +5 -28 jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-resources-howto.xml
  
  Index: jndi-resources-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-resources-howto.xml,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- jndi-resources-howto.xml  18 Dec 2001 18:17:44 -  1.11
  +++ jndi-resources-howto.xml  13 Mar 2002 04:13:34 -  1.12
  @@ -420,9 +420,11 @@
   
   
   NOTE - The default data source support in Tomcat
  -supports Tyrex.  However, it is possible to use any other connection pool
  -that implements javax.sql.DataSource, by writing your own
  -custom resource factory, as described
  +is based on the DBCP connection pool from the
  +http://jakarta.apache.org/commons";>Jakarta Commons
  +subproject.  However, it is possible to use any other connection pool
  +that implements javax.sql.DataSource, by writing your
  +own custom resource factory, as described
   below.
   
   1.  Install Your JDBC Driver
  @@ -528,31 +530,6 @@
   JDBC driver.  Customize the driverClassName and
   driverName parameters to match your actual database's
   JDBC driver and connection URL.
  -
  -  
  -
  -  
  -
  -If you utilize Tyrex for your JDBC resource factory as described
  -above, you will also have support for
  -the java.transaction.UserTransaction resource provided by
  -Tyrex (since it is XA-capable).  To use this feature, code your
  -application as follows:
  -
  -Context initCtx = new InitialContext();
  -Context envCtx = (Context) initCtx.lookup("java:comp/env");
  -Transaction tx = (Transaction) envCtx.lookup("UserTransaction");
  -
  -tx.begin();
  -... perform transactional operations on data ...
  -tx.commit();
  -
  -
  -This is useful when you need to do "two-phased commits" across more
  -than one database, where the commit needs to either succeed completely
  -or fail completely across all associated databases.  This feature
  -requires a JDBC driver that also supports XA capabilities.  See the
  -J2EE and JDBC documentation for more information.
   
 
   
  
  
  

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

Re: mod_jk (1.2) enhancements

[costinm]

On Tue, 12 Mar 2002, Glenn Nielsen wrote:

> Why?  This is a minor change that IMO fixes a problem.
> The example JkMount /servlet/* doesn't work with Tomcat.  There needed to be
> a way to easily configure passing of servlet requests to Tomcat without having
> to configure it for each Context Path.

The real fix is to process web.xml and configure automatically all the 
(right) mappings. This is required by the servlet spec - /*/servlet/* is 
just hiding the problem for some cases.

Right now autogeneration of mappings works with both 3.3 and 4.0, if 
something is missing or can be improved - I'm +1, if you want more 
automation or protocol-based config of mappings - +1 ( not easy, but
can be done ). If you want to automatically read web.xml and extract 
mappings - that's fine too :-) 

Simplifying the config very important - and the AutoAlias is an excelent 
example. 

As I said, I am ok with enhancing AutoAlias to add automatically rules
for /path/servlet/*, *.jsp, /path/WEB-INF/* and /path/META-INF/*.
That would have almost the same effect as your proposal.
 
Costin


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

DO NOT REPLY [Bug 7037] - JIT 3.10.107(x) error Structured Exception(c0000005) in ....

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

JIT 3.10.107(x) error Structured Exception(c005) in 

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-03-13 03:47 ---
As the error message tells you, this is a JVM issue, not a Tomcat bug.

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

cvs commit: jakarta-tomcat/src/share/org/apache/jasper JspC.java

[larryi]

larryi  02/03/12 19:44:36

  Modified:src/share/org/apache/jasper JspC.java
  Log:
  Port a couple of fixes from Tomcat 4.x.
  
  Revision  ChangesPath
  1.25  +2 -1  jakarta-tomcat/src/share/org/apache/jasper/JspC.java
  
  Index: JspC.java
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/JspC.java,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- JspC.java 17 Dec 2001 05:18:45 -  1.24
  +++ JspC.java 13 Mar 2002 03:44:36 -  1.25
  @@ -284,6 +284,7 @@
   tok = nextArg();
   if (tok != null) {
   scratchDir = new File(new File(tok).getAbsolutePath());
  +dirset = false;
   } else {
   // either an in-java call with an explicit null
   // or a "-d --" sequence should cause this,
  @@ -407,7 +408,7 @@
   mappingout.write("\n\t\n\t\t");
   mappingout.write(thisServletName);
   mappingout.write("\n\t\t");
  -mappingout.write(file);
  +mappingout.write(file.replace('\\', '/'));
   mappingout.write("\n\t\n");
   }
   return true;
  
  
  

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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server PoolTcpConnector.java

[larryi]

larryi  02/03/12 19:43:33

  Modified:src/share/org/apache/tomcat/modules/server
PoolTcpConnector.java
  Log:
  Remove setting the socketFactory attributes from checkSocketFactory().
  It is now handled in engineInit() where it should have been in the first
  place.
  
  Revision  ChangesPath
  1.16  +0 -8  
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/PoolTcpConnector.java
  
  Index: PoolTcpConnector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/PoolTcpConnector.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- PoolTcpConnector.java 12 Mar 2002 04:03:12 -  1.15
  +++ PoolTcpConnector.java 13 Mar 2002 03:43:33 -  1.16
  @@ -197,14 +197,6 @@
(sslImplementationName);
   socketFactory = 
   sslImplementation.getServerSocketFactory();
  -if( socketFactory!=null ) {
  -Enumeration attE=attributes.keys();
  -while( attE.hasMoreElements() ) {
  -String key=(String)attE.nextElement();
  -Object v=attributes.get( key );
  -socketFactory.setAttribute( key, v );
  -}
  -}
ep.setServerSocketFactory(socketFactory);
} catch (ClassNotFoundException e){
throw new TomcatException("Error loading SSLImplementation ",
  
  
  

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

cvs commit: jakarta-tomcat/src/etc/jk wrapper.properties

[larryi]

larryi  02/03/12 19:40:07

  Modified:src/etc/jk wrapper.properties
  Log:
  Added quotes around wrapper.javabin in the wrapper.cmd_line.
  
  Submitted by: David Schreibman
  
  Added wrapper.jvm.options and some documentation.
  
  Revision  ChangesPath
  1.4   +24 -4 jakarta-tomcat/src/etc/jk/wrapper.properties
  
  Index: wrapper.properties
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/etc/jk/wrapper.properties,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- wrapper.properties13 Oct 2001 02:25:13 -  1.3
  +++ wrapper.properties13 Mar 2002 03:40:07 -  1.4
  @@ -1,7 +1,7 @@
   #
  -# $Header: /home/cvs/jakarta-tomcat/src/etc/jk/wrapper.properties,v 1.3 2001/10/13 
02:25:13 billbarker Exp $
  -# $Revision: 1.3 $
  -# $Date: 2001/10/13 02:25:13 $
  +# $Header: /home/cvs/jakarta-tomcat/src/etc/jk/wrapper.properties,v 1.4 2002/03/13 
03:40:07 larryi Exp $
  +# $Revision: 1.4 $
  +# $Date: 2002/03/13 03:40:07 $
   #
   #
   # jk_service.properties - a bootstrup file for the Tomcat NT service.
  @@ -100,17 +100,37 @@
   # wrapper.shutdown_port tells the service the identity of the port that 
   # is used by AJP12/AJP13.
   #
  +# Ajp12
   wrapper.shutdown_port=8007
   
  +# Ajp13
  +#wrapper.shutdown_port=8009
  +
   #
   # Can either be ajp12 or ajp13 depending on your configuration.
   #
  +# Note: If you use ajp13, be sure to enable shutdown on the Ajp13Connector.
  +#   For Tomcat 3.3 add: shutDownEnable="true"
  +#   For Tomcat 3.3.1 add: shutdownEnable="true" or shutDownEnable="true"
  +#
  +# Note: Use of a shutdown "secret" (i.e. password) is not supported.
  +#
   # Default value is ajp12
   #
   wrapper.shutdown_protocol=ajp12
   
   #
  +# JVM Options
  +#
  +# Useful Options:
  +# -Xms256m= Initial heap size, modify for desired size
  +# -Xmx256m= Maximum heap size, modify for desired size
  +# -Xrs= Available in Jdk1.3.1 to avoid JVM termination during logoff
  +#
  +wrapper.jvm.options=
  +
  +#
   # This is the command line that is used to start Tomcat. You can *add* extra
   # parameters to it but you can not remove anything.
   #
  -wrapper.cmd_line=$(wrapper.javabin) 
-Djava.security.policy=="$(wrapper.tomcat_policy)"   
-Dtomcat.home="$(wrapper.tomcat_home)" -classpath $(wrapper.class_path) 
$(wrapper.startup_class) -config $(wrapper.server_xml) 
  +wrapper.cmd_line="$(wrapper.javabin)" $(wrapper.jvm.options) 
-Djava.security.policy=="$(wrapper.tomcat_policy)" 
-Dtomcat.home="$(wrapper.tomcat_home)" -classpath $(wrapper.class_path) 
$(wrapper.startup_class) -config $(wrapper.server_xml) 
  
  
  

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

Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[costinm]

+1 for everything

Costin

On Tue, 12 Mar 2002, Remy Maucherat wrote:

> There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to
> start with some limited changes at first. Most of these proposed changes are
> Coyote-related (hence the subject of the message), and all involve some
> refactoring / API additions.
> 
> A) URI decoding refactoring. To avoid doing some URI decoding in many places
> in the pipeline, a decodedURI field (with associated getter/setter) should
> be added in the HttpRequest interface, and used in the Catalina pipeline.
> This also has the advantage to guarantee that no double URI decoding occurs
> (which can lead to URI-based security attacks).
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
> connector, which has many shortcoming (slow performance on output, HTTP
> handling limitations and extreme complexity). Initial tests results and
> benchmarks with Coyote are extremely positive so far.
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> C) Add better lifecycle handling in the resources. A start method is needed
> (which could be called 'allocate' to mirror the 'release' method), because
> it is currently not possible to restart a stopped context. In the 4.0
> branch, the patch introducing the 'release' method must either be reverted,
> or these proposed changes must also be ported to 4.0.
> Thanks to Jean-Francois Clere for the report and debugging of this problem.
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
> be used for any new connector development. To make this more obvious, I'd
> like to deprecate all classes in this package and subpackages. The binaries
> will also be packaged in a separate JAR file (tentatively named
> catalina-legacy.jar). This package will continue to be maintained on a case
> by case basis. The facades will not be deprecated, and two new helper
> objects will be introduced to handle the need for "fake" req/resp when
> requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> more details).
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor
> interface. Otherwise, the processor has no way to cleanly handle logging.
> commons-logging is already used by other j-t-c components. At the moment,
> the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
> needs to be improved. When I originally designed most of the base
> interfaces, commons-logging didn't exist yet, and I didn't feel like adding
> yet another logging interface.
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> +1 for everything. Thanks for voting / commenting :)
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


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

[PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[Remy Maucherat]

There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to
start with some limited changes at first. Most of these proposed changes are
Coyote-related (hence the subject of the message), and all involve some
refactoring / API additions.

A) URI decoding refactoring. To avoid doing some URI decoding in many places
in the pipeline, a decodedURI field (with associated getter/setter) should
be added in the HttpRequest interface, and used in the Catalina pipeline.
This also has the advantage to guarantee that no double URI decoding occurs
(which can lead to URI-based security attacks).


[ ] +1
[ ] +0
[ ] -1:



B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
connector, which has many shortcoming (slow performance on output, HTTP
handling limitations and extreme complexity). Initial tests results and
benchmarks with Coyote are extremely positive so far.


[ ] +1
[ ] +0
[ ] -1:



C) Add better lifecycle handling in the resources. A start method is needed
(which could be called 'allocate' to mirror the 'release' method), because
it is currently not possible to restart a stopped context. In the 4.0
branch, the patch introducing the 'release' method must either be reverted,
or these proposed changes must also be ported to 4.0.
Thanks to Jean-Francois Clere for the report and debugging of this problem.


[ ] +1
[ ] +0
[ ] -1:



D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
be used for any new connector development. To make this more obvious, I'd
like to deprecate all classes in this package and subpackages. The binaries
will also be packaged in a separate JAR file (tentatively named
catalina-legacy.jar). This package will continue to be maintained on a case
by case basis. The facades will not be deprecated, and two new helper
objects will be introduced to handle the need for "fake" req/resp when
requesting a JSP precompilation with a load-on-startup (see bug 4518 for
more details).


[ ] +1
[ ] +0
[ ] -1:



E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor
interface. Otherwise, the processor has no way to cleanly handle logging.
commons-logging is already used by other j-t-c components. At the moment,
the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
needs to be improved. When I originally designed most of the base
interfaces, commons-logging didn't exist yet, and I didn't feel like adding
yet another logging interface.


[ ] +1
[ ] +0
[ ] -1:



+1 for everything. Thanks for voting / commenting :)

Remy


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

cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0.4-B2.txt

[remm]

remm02/03/12 18:25:14

  Modified:.Tag: tomcat_40_branch RELEASE-NOTES-4.0.4-B2.txt
  Log:
  - Changelog update.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.2   +4 -1  jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.4-B2.txt
  
  Index: RELEASE-NOTES-4.0.4-B2.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.4-B2.txt,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- RELEASE-NOTES-4.0.4-B2.txt2 Mar 2002 04:20:13 -   1.1.2.1
  +++ RELEASE-NOTES-4.0.4-B2.txt13 Mar 2002 02:25:14 -  1.1.2.2
  @@ -3,7 +3,7 @@
   Release Notes
   =
   
  -$Id: RELEASE-NOTES-4.0.4-B2.txt,v 1.1.2.1 2002/03/02 04:20:13 remm Exp $
  +$Id: RELEASE-NOTES-4.0.4-B2.txt,v 1.1.2.2 2002/03/13 02:25:14 remm Exp $
   
   
   
  @@ -71,6 +71,8 @@
   Catalina Bug Fixes:
   --
   
  +HttpResponseBase: Revert fix for 6600, which breaks sessionid URL encoding in
  +  4.0.4 Beta 1.
   
   
   
  @@ -89,6 +91,7 @@
   Bugzilla Bugs Resolved:
   --
   
  +7061  Servlet loaded TWICE on application startup?
   
   
   
  
  
  

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

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

[craigmcc]

craigmcc02/03/12 17:26:49

  Modified:catalina/src/share/org/apache/catalina/core
StandardHostDeployer.java
   catalina/src/share/org/apache/catalina/loader
StandardClassLoader.java
   catalina/src/share/org/apache/catalina/servlets
ManagerServlet.java
  Log:
  Remove obsolete JAR related imports from StandardHostDeployer and
  ManagerServlet.  Enhance JAR handling in StandardClassLoader to close a
  JAR file even if an exception occurs.
  
  Revision  ChangesPath
  1.7   +4 -7  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java
  
  Index: StandardHostDeployer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- StandardHostDeployer.java 1 Mar 2002 16:44:32 -   1.6
  +++ StandardHostDeployer.java 13 Mar 2002 01:26:49 -  1.7
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
 1.6 2002/03/01 16:44:32 glenn Exp $
  - * $Revision: 1.6 $
  - * $Date: 2002/03/01 16:44:32 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
 1.7 2002/03/13 01:26:49 craigmcc Exp $
  + * $Revision: 1.7 $
  + * $Date: 2002/03/13 01:26:49 $
*
* 
*
  @@ -70,11 +70,8 @@
   import java.io.FileOutputStream;
   import java.io.InputStream;
   import java.io.IOException;
  -import java.net.JarURLConnection;
   import java.net.URL;
   import java.util.Enumeration;
  -import java.util.jar.JarEntry;
  -import java.util.jar.JarFile;
   import org.apache.catalina.Container;
   import org.apache.catalina.Context;
   import org.apache.catalina.Deployer;
  @@ -94,7 +91,7 @@
* StandardHost implementation class.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.6 $ $Date: 2002/03/01 16:44:32 $
  + * @version $Revision: 1.7 $ $Date: 2002/03/13 01:26:49 $
*/
   
   public class StandardHostDeployer implements Deployer {
  
  
  
  1.26  +11 -7 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java
  
  Index: StandardClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- StandardClassLoader.java  9 Nov 2001 17:59:16 -   1.25
  +++ StandardClassLoader.java  13 Mar 2002 01:26:49 -  1.26
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
 1.25 2001/11/09 17:59:16 remm Exp $
  - * $Revision: 1.25 $
  - * $Date: 2001/11/09 17:59:16 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
 1.26 2002/03/13 01:26:49 craigmcc Exp $
  + * $Revision: 1.26 $
  + * $Date: 2002/03/13 01:26:49 $
*
* 
*
  @@ -112,7 +112,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.25 $ $Date: 2001/11/09 17:59:16 $
  + * @version $Revision: 1.26 $ $Date: 2002/03/13 01:26:49 $
*/
   
   public class StandardClassLoader
  @@ -1063,8 +1063,8 @@
   
   // Validate the manifest of a JAR file repository
   if (!repository.endsWith(File.separator)) {
  +JarFile jarFile = null;
   try {
  -JarFile jarFile = null;
   Manifest manifest = null;
   if (repository.startsWith("jar:")) {
   URL url = new URL(null, repository, streamHandler);
  @@ -1104,12 +1104,16 @@
   required.add(extensions.next());
   }
   }
  -if (jarFile != null)
  -jarFile.close();
   } catch (Throwable t) {
   t.printStackTrace();
   throw new IllegalArgumentException
   ("addRepositoryInternal: " + t);
  +} finally {
  +if (jarFile != null) {
  +try {
  +jarFile.close();
  +} catch (Throwable t) {}
  +}
   }
   }
   
  
  
  
  1.18  +4 -6  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java
  
  Index: ManagerServlet.java
  

DO NOT REPLY [Bug 7059] - Jasper compiler holds pointers to jars in WEB-INF/lib: cannot delete

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

Jasper compiler holds pointers to jars in WEB-INF/lib: cannot delete





--- Additional Comments From [EMAIL PROTECTED]  2002-03-13 00:56 ---
Hmmm, my experience with setting setUseCaches(false) was the same as Glenn's --
it did not seem to make any difference because the JAR file itself was left
open.  Adding a call to jarFile.close() after the TLD scan is complete, however,
causes more problems (such as two Watchdog failures on pages that reference TLDs
inside of JAR files).  Apparently, the Jasper compiler reparses the TLD again at
page compile time, even though it already pre-scanned it at app startup --
that's going to take some more study.

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

Re: mod_jk (1.2) enhancements

[costinm]

On Tue, 12 Mar 2002, Glenn Nielsen wrote:

> > worker.ajp13.logRequest="%b %w"
> > 
> > 
> 
> 
> The new JkRequestLogFormat scopes at the Apache VirtualHost,
> so you can specifiy different request logging formats for
> different virtual hosts.  The above wouldn't allow that.

You're right, but will work with all servers. I assume this is intended 
for debugging, and having it at virtual host level is not a big win.
Having it at uri level would be interesting, but I don't think it's worth 
the effort.

It doesn't matter too much - you can check it in as apache1.3 specific
if you want.


> I'm ok with dropping "request" from the JkLogLevel, though I wish
> someone had said something when I first proposed this. :-)

Sorry.

> Right, the subject line states mod_jk 1.2.

I'm very nervous about adding new features to mod_jk 1.2, especially the 
mapper. 

Costin 


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

Re: mod_jk (1.2) enhancements

[Glenn Nielsen]

GOMEZ Henri wrote:

>>>If JkLogLevel <= REQUEST ?
>>>
>>Please, no more levels... Debug, info, error, etc is enough - 
>>request is 
>>not a level but a channel/log/whatever.
>>
> 
>>What next, add a 'headers' level to display the headers ? Is 
>>headers>
> 
> Good idea the dump of header, I'll often have to track problems
> with them, seriously
> 
> 
>>Add a worker.ajp13.logRequest property if you want, and use INFO level.
>>
> 
> You're right it's better :
> 
> worker.ajp13.logRequest={The Proposed JkRequestLogFormat}
> 
> ie
> 
> worker.ajp13.logRequest="%b %w"
> 
> 


The new JkRequestLogFormat scopes at the Apache VirtualHost,
so you can specifiy different request logging formats for
different virtual hosts.  The above wouldn't allow that.


>>>Why not use instead JkLogLevel INFO + REQUEST to explicitly 
>>>explain we want request logged
>>>
>>Let's keep log level and option to the standard levels. 
>>
>>I'm -1 on messing with the levels, almost everyone agrees on the 
>>4-5 levels ( see log4j, commons-loging, etc ) and separate 'channels'
>>for logging different kinds of information.
>>
> 
> Ok, let drop this.
> 



I'm ok with dropping "request" from the JkLogLevel, though I wish
someone had said something when I first proposed this. :-)


The existance of a JkRequestLogFormat config for a VH could be
enough to trigger on logging of request data for a VH.


> 
Here is an example:

JkMount /*/servlet/ ajp13

>>>Great
>>>
>>Not very great, the mapper is already very messy - and this 
>>shortcut will 
>>be hard to support in future, we have enough troubles with the 
>>standard 
>>mappoings. 
>>
>>If you really need it, I'm ok if you check it in so you solve your 
>>problem, but I would leave it undocumented ( or documented as 
>>an experimental 
>>feature that might/will go away in future )
>>
>>A better solution ( IMHO ) would be for AutoAlias to automatically add 
>>a mapping for servlets and jsps, and maybe read a 
>>ctx_root/WEB-INF/jkmap.properties with additional mappings for the 
>>context. 
>>
> 
> You're speaking of jk 2.0 when Glenn works on jk 1.2.
> Let say that these features (JkMount/JkAlias) will be present in jk 1.2 only 
> and will be replaced in jk 2.0
> 



Right, the subject line states mod_jk 1.2.


Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--


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

DO NOT REPLY [Bug 7059] - Jasper compiler holds pointers to jars in WEB-INF/lib: cannot delete

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

Jasper compiler holds pointers to jars in WEB-INF/lib: cannot delete

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||tomcat-
   ||[EMAIL PROTECTED]
 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2002-03-12 22:36 ---
It (used to be) even worse than that ... Tomcat wouldn't let go of the WAR file
when undeploying an application, either.  That one was fixed ... I'm walking
through the other places where Tomcat opens a JAR file now.

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

Re: mod_jk (1.2) enhancements

[Glenn Nielsen]

GOMEZ Henri wrote:

>>I have implemented the mod_jk (1.2) request logging I proposed 
>>a few weeks
>>ago.  Its up and running.
>>
>>/*
>>* JkRequestLogFormat Directive Handling
>>*
>>* JkRequestLogFormat format string
>>*
>>* %b - Bytes sent, excluding HTTP headers. In CLF format
>>* %B - Bytes sent, excluding HTTP headers.
>>* %H - The request protocol   
>>* %m - The request method 
>>* %p - The canonical Port of the server serving the request
>>* %q - The query string (prepended with a ? if a query string exists,
>>*  otherwise an empty string)
>>* %r - First line of request 
>>* %s - request HTTP status code  
>>* %T - Requset duration, elapsed time to handle request in 
>>seconds '.' micro seconds
>>* %U - The URL path requested, not including any query 
>>string.  
>>* %v - The canonical ServerName of the server serving the 
>>request.  
>>* %V - The server name according to the UseCanonicalName setting. 
>>* %w - Tomcat worker name 
>>*/
>>
> 
> Excellent
> 
> 
>>Another log level of "request" was added also.  If log level 
>>is <= request
>>and JkRequestLogFormat is configured, requests will be logged.
>>
> 
> If JkLogLevel <= REQUEST ?
> 
> Why not use instead JkLogLevel INFO + REQUEST to explicitly 
> explain we want request logged


The priority is "emerg,warning,request,info,debug".

Your though is that someone might want just request loggin without
emerg and warning?


> 
> 
>>This is only implemented for Apache 1.3 and I cloned alot of 
>>code from the
>>Apache httpd logging module to implement this.
>>
> 
> Could be factorized to be used later by Apache 1.3/2.0 for mod_jk 1.2.
> And of course jk2 will use it in a similar fashion (must be easier with
> new architecture)
> 


I'll let the core j-t-c committers worry about that. :-)


> 
>>---
>>
>>
>>I also added a new config directive called JkAutoAlias, again this is
>>only implemented for Apache 1.3.
>>
>>JkAutoAlias {webapp directory}
>>
>>JkAutoAlias is used when you want to map static files in a webapp
>>context directory into the Apache virtual host document space so 
>>it can serve the static pages instead of Tomcat.
>>
>>This works automatically for an context in the configured 
>>webapp directory
>>which has a context directory. And is a great deal easier than 
>>configuring
>>an Apache Alias for each individual webapp context directory.
>>
> 
> So you'll have :
> 
> JkAutoAlias examples
> JkAutoAlias admin
> JkAutoAlias webapp
> 
> 


No, Here is an example JkAutoAlias config:

JkAutoAlias /usr/local/tomcat/webapps

Any context dir found in the above directory is automatically aliased
into the apache document root for the virtual host.

So if the above webapps directory had the context dirs

examples
admin
foobar


The equivalent apache aliases would be

Alias /examples /usr/local/tomcat/webapps/examples
Alias /admin /usr/local/tomcat/webapps/admin
Alias /foobar /usr/local/tomcat/webapps/foobar

Using JkAutoAlias saves you from having to configure an apache
Alias for each context dir and automatically handles any new context
dirs you add to the webapp directory.


> 
>>---
>>-
>>
>>I made one other minor change to how JkMount works which 
>>applies to all web servers.
>>
>>I added the ability to configure a * for the context 
>>directory, then match on the
>>remaining path.
>>
>>Here is an example:
>>
>>JkMount /*/servlet/ ajp13
>>
> 
> Great
> 
> 
>>The above would forward all requests where the second path 
>>component is named "servlet"
>>to Tomcat.  This also makes it easier to configure a virtual 
>>host to handle multiple
>>web application contexts without having tho change the Apache config.
>>
>>
>>I haven't contributed code  to jakarta-tomcat-connectors, but 
>>if everyone is OK with
>>this I can commit the code.
>>
> 
> Could you send us the patches for study, but it allready appears
> to be great addition
> 


Attached, Enjoy!


Glenn


--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--



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

Tomcat 4 and OMVS

[Steve Guthrie]

Has anyone successfully got Tomcat 4 running under Unix System Services on
an OS390 mainframe machine?

Thanks,

Stephen J. Guthrie
Regional Sales Manager
Mantissa Corporation
2200 Valleydale Road
Birmingham, AL 35244
(800) 438-7367


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

RE: mod_jk (1.2) enhancements

[GOMEZ Henri]

>> If JkLogLevel <= REQUEST ?
>
>Please, no more levels... Debug, info, error, etc is enough - 
>request is 
>not a level but a channel/log/whatever.

>What next, add a 'headers' level to display the headers ? Is 
>headersAdd a worker.ajp13.logRequest property if you want, and use INFO level.

You're right it's better :

worker.ajp13.logRequest={The Proposed JkRequestLogFormat}

ie

worker.ajp13.logRequest="%b %w"

>> Why not use instead JkLogLevel INFO + REQUEST to explicitly 
>> explain we want request logged
>
>Let's keep log level and option to the standard levels. 
>
>I'm -1 on messing with the levels, almost everyone agrees on the 
>4-5 levels ( see log4j, commons-loging, etc ) and separate 'channels'
>for logging different kinds of information.

Ok, let drop this.

>> >Here is an example:
>> >
>> >JkMount /*/servlet/ ajp13
>> 
>> Great
>
>Not very great, the mapper is already very messy - and this 
>shortcut will 
>be hard to support in future, we have enough troubles with the 
>standard 
>mappoings. 
>
>If you really need it, I'm ok if you check it in so you solve your 
>problem, but I would leave it undocumented ( or documented as 
>an experimental 
>feature that might/will go away in future )
>
>A better solution ( IMHO ) would be for AutoAlias to automatically add 
>a mapping for servlets and jsps, and maybe read a 
>ctx_root/WEB-INF/jkmap.properties with additional mappings for the 
>context. 

You're speaking of jk 2.0 when Glenn works on jk 1.2.
Let say that these features (JkMount/JkAlias) will be present in jk 1.2 only 
and will be replaced in jk 2.0

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

RE: mod_jk (1.2) enhancements

[costinm]

On Tue, 12 Mar 2002, GOMEZ Henri wrote:

> >Another log level of "request" was added also.  If log level 
> >is <= request
> >and JkRequestLogFormat is configured, requests will be logged.
> 
> If JkLogLevel <= REQUEST ?

Please, no more levels... Debug, info, error, etc is enough - request is 
not a level but a channel/log/whatever.

What next, add a 'headers' level to display the headers ? Is 
headers Why not use instead JkLogLevel INFO + REQUEST to explicitly 
> explain we want request logged

Let's keep log level and option to the standard levels. 

I'm -1 on messing with the levels, almost everyone agrees on the 
4-5 levels ( see log4j, commons-loging, etc ) and separate 'channels'
for logging different kinds of information.

> >Here is an example:
> >
> >JkMount /*/servlet/ ajp13
> 
> Great

Not very great, the mapper is already very messy - and this shortcut will 
be hard to support in future, we have enough troubles with the standard 
mappoings. 

If you really need it, I'm ok if you check it in so you solve your 
problem, but I would leave it undocumented ( or documented as an experimental 
feature that might/will go away in future )

A better solution ( IMHO ) would be for AutoAlias to automatically add 
a mapping for servlets and jsps, and maybe read a 
ctx_root/WEB-INF/jkmap.properties with additional mappings for the 
context. 

Costin



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

DO NOT REPLY [Bug 7061] - Servlet loaded TWICE on application startup?

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

Servlet loaded TWICE on application startup?

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-03-12 21:31 ---
This has been fixed in CVS already.

The servlet init method will get called twice. If you look at the Tomcat source,
it is quite obvious why it happens.

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

DO NOT REPLY [Bug 6600] - enodeURL adds 'jsession' when 'isRequestedSessionIdFromURL' returns false

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

enodeURL adds 'jsession' when 'isRequestedSessionIdFromURL' returns false

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement
 Status|RESOLVED|REOPENED
   Priority|Other   |Medium
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2002-03-12 21:28 ---
The patch for this broke URL encoding of the session id, and has been reverted.
The spec doesn't require to implement this, so I'm changing to an enhancement
request.

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

DO NOT REPLY [Bug 7061] New: - Servlet loaded TWICE on application startup?

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

Servlet loaded TWICE on application startup?

   Summary: Servlet loaded TWICE on application startup?
   Product: Tomcat 4
   Version: 4.0.4 Beta 1
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a servlet called ShopInit that has load-on-startup set. In TC 4.0.4B1 the 
servlet gets loaded 
TWICE (maybe others as well but they don't log anything so I can't see anything).
Copying this 
webapp (w/o any modification) to TC 4.0.1 or 4.0.2 doesn't show this behavior.

This is the 
web.xml:



http://java.sun.com/j2ee/dtds/web-app_2_3.dtd";>



  

com.webtothemax.shop.admin.SessionCounter
  


  
action
org.apache.struts.action.ActionServlet

  application
  ApplicationResources



  config
  /WEB-
INF/struts-config.xml


  debug
  2


  
detail
  2


  validate
  true

2
  
  
com.webtothemax.shop.servlets.ShopInit
Servlet 
ShopInit
Loads application wide data for 
ShopCart.
com.webtothemax.shop.servlets.ShopInit

  productslist pathname
  /WEB-
INF/shopdata/xml/prod_catalog.xml

10
  
  
twypReceiver
twypReceiver

Waits for Twyp callbacks
com.webtothemax.shop.servlets.twypReceiver
  
  

LogInit
com.webtothemax.shop.servlets.LogInit
1
  
  
action
*.do
  
  
twypReceiver
/servlet/twypReceiver
  

  

30

  

  
index.jsp
  

  
/WEB-INF/struts-bean.tld

/WEB-INF/struts-bean.tld
  
  

/WEB-INF/struts-html.tld
/WEB-INF/struts-
html.tld
  
  
/WEB-INF/struts-
logic.tld
/WEB-INF/struts-logic.tld
  

  
  

snip snip---
  


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

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs manager-howto.xml

[craigmcc]

craigmcc02/03/12 13:14:16

  Modified:catalina/src/share/org/apache/catalina/servlets
LocalStrings.properties ManagerServlet.java
   webapps/tomcat-docs manager-howto.xml
  Added:   catalina/src/share/org/apache/catalina/ant
ResourcesTask.java
  Log:
  Add a new "/resources" command that will enumerate the available global JNDI
  resources (either all of them, or all of them for a specific type like
  javax.sql.DataSource).  This is useful to tools that want to package up
  webapps and create the  configuration element, with embedded
   elements that link resource references in the web.xml to
  the corresponding actual resources.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ant/ResourcesTask.java
  
  Index: ResourcesTask.java
  ===
  /*
   * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ant/ResourcesTask.java,v
 1.1 2002/03/12 21:14:15 craigmcc Exp $
   * $Revision: 1.1 $
   * $Date: 2002/03/12 21:14:15 $
   *
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 2002 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   */
  
  
  package org.apache.catalina.ant;
  
  
  import org.apache.tools.ant.BuildException;
  import org.apache.tools.ant.Task;
  
  
  /**
   * Ant task that implements the /list command, supported by the
   * Tomcat manager application.
   *
   * @author Craig R. McClanahan
   * @version $Revision: 1.1 $ $Date: 2002/03/12 21:14:15 $
   * @since 4.1
   */
  public class ResourcesTask extends AbstractCatalinaTask {
  
  
  // - Properties
  
  
  /**
   * The fully qualified class name of the resource type being requested
   * (if any).
   */
  protected String type = null;
  
  public String getType() {
  return (this.type);
  }
  
  public void setType(String type) {
  this.type = type;
  }
  
  
  // - Public Methods
  
  
  /**
   * Execute the requested operation.
   *
   * @exception BuildException if an error occurs
   */
  public void execute() throws BuildEx

RE: In memory session replication, reminder

[GOMEZ Henri]

>> We speak about spread some times ago but the licence wasn't Apache
>> at this time, and yes it's another good Broadcast system.
>> Good point it support native and java.
>
>Spread has a BSD license now. Thanks to many ASF members 
>speaking to the
>spread developers and convincing them to switch.

Thanks Jon for your successfull lobying :)

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

RE: pluggable security implementations

[GOMEZ Henri]

>> I hope that the following server.xml snip correctly describes the
>> inclusion!
>Our experience with 3.3 was that just having a single socket factory
>didn't work very well, because you also need to choose the right
>classes to get socket info... The 3.3 approach was to have a 
>single meta-class which provided factories for both the socket
>and the accessors.
>
>I need to look over Coyote and see how things woudl fit in there...

It will be nice to have a common HTTP connector in both Tomcats.
JTC original goals was to have common stuff in connector area 
(connector to web-server, or directly to client) and it seems 
this initial goal is near completion.

So Coyote seems the perfect candidate for alternative to JSSE
via PureTLS. 

And since PureTLS may also use crypto provider others than Cryptix, 
like BC, so it may be specified via extra Coyote params



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

RE: jk2: Config changes ( again )

[GOMEZ Henri]

>Even more extreme - use full uri, with query strings. We're in a http 
>server, we should know how to parse this kind of stuff :-)
>
>
>  JkUriSet worker 
>ajp13://tomcat_host.my.com:8009?lbfactor=10&debug=INFO
>

Good, but Apache oriented

>And another idea for workers.properties:
>
>myworker1=ajp13://host.name.com:8009?lbfactor=10&debug=INFO

Better since it should be easier to port on non Apache 
WebServer like IIS/iPlanet, a common synthax

>In this case the name ( without any delimiter ) will act as a 
>shortcut or 
>alias, the RHS will be a URI that will be used in constructor. 
>Both alias
>or the uri can be used in JkMount/JkUriSet/uri properties.
>
>More brainstorming ? Should we post this on tomcat-users, to get more 
>feedback ? 

Yes, there is many tomcat/apache admins at tomcat-users...

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

RE: mod_jk (1.2) enhancements

[GOMEZ Henri]

>I have implemented the mod_jk (1.2) request logging I proposed 
>a few weeks
>ago.  Its up and running.
>
>/*
> * JkRequestLogFormat Directive Handling
> *
> * JkRequestLogFormat format string
> *
> * %b - Bytes sent, excluding HTTP headers. In CLF format
> * %B - Bytes sent, excluding HTTP headers.
> * %H - The request protocol   
> * %m - The request method 
> * %p - The canonical Port of the server serving the request
> * %q - The query string (prepended with a ? if a query string exists,
> *  otherwise an empty string)
> * %r - First line of request 
> * %s - request HTTP status code  
> * %T - Requset duration, elapsed time to handle request in 
>seconds '.' micro seconds
> * %U - The URL path requested, not including any query 
>string.  
> * %v - The canonical ServerName of the server serving the 
>request.  
> * %V - The server name according to the UseCanonicalName setting. 
> * %w - Tomcat worker name 
> */

Excellent

>Another log level of "request" was added also.  If log level 
>is <= request
>and JkRequestLogFormat is configured, requests will be logged.

If JkLogLevel <= REQUEST ?

Why not use instead JkLogLevel INFO + REQUEST to explicitly 
explain we want request logged

>This is only implemented for Apache 1.3 and I cloned alot of 
>code from the
>Apache httpd logging module to implement this.

Could be factorized to be used later by Apache 1.3/2.0 for mod_jk 1.2.
And of course jk2 will use it in a similar fashion (must be easier with
new architecture)

>---
>
>
>I also added a new config directive called JkAutoAlias, again this is
>only implemented for Apache 1.3.
>
>JkAutoAlias {webapp directory}
>
>JkAutoAlias is used when you want to map static files in a webapp
>context directory into the Apache virtual host document space so 
>it can serve the static pages instead of Tomcat.
>
>This works automatically for an context in the configured 
>webapp directory
>which has a context directory. And is a great deal easier than 
>configuring
>an Apache Alias for each individual webapp context directory.

So you'll have :

JkAutoAlias examples
JkAutoAlias admin
JkAutoAlias webapp


>---
>-
>
>I made one other minor change to how JkMount works which 
>applies to all web servers.
>
>I added the ability to configure a * for the context 
>directory, then match on the
>remaining path.
>
>Here is an example:
>
>JkMount /*/servlet/ ajp13

Great

>The above would forward all requests where the second path 
>component is named "servlet"
>to Tomcat.  This also makes it easier to configure a virtual 
>host to handle multiple
>web application contexts without having tho change the Apache config.
>
>
>I haven't contributed code  to jakarta-tomcat-connectors, but 
>if everyone is OK with
>this I can commit the code.

Could you send us the patches for study, but it allready appears
to be great addition

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

RE: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http MimeHeaders.java

[GOMEZ Henri]

>> I prefer not to move tomcat_util to J-T-C until after Tomcat 3.3.1,
>> which I plan on getting out this week or weekend at the latest.
>> After that, I'm +1.
>
Agree

>
>What about including the alpha of coyote and jk2(java) with 3.3.1 ? 
>( disabled, but easy to activate )

+1, disabled by default but activable. It will help us all to have
bug reports from coyote when activated in TC 3.3.1

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

DO NOT REPLY [Bug 7059] - Jasper compiler holds pointers to jars in WEB-INF/lib: cannot delete

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

Jasper compiler holds pointers to jars in WEB-INF/lib: cannot delete





--- Additional Comments From [EMAIL PROTECTED]  2002-03-12 20:57 ---
The same problem was exhibited in the manager servlet for installing
web apps from a war file at a remote URL.

I tried setUseCaches(false) and that still did not fix the problem
with the war (jar) being cached by the JVM.  This was JRE 1.3x.

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

[PATCH] jtc jk_nt_service set service properties on install

[Tim Whittington]

Attached is a patch to the jtc jk_nt_service.c to allow service properties
to be supplied as arguments on the command line when the service is
installed.

Most of this is a merge from the tomcat 3.3 tree, with the addition of
allowing the
service description to be set.

--

tim
 <> 



jk_nt_service.c.diff
Description: Binary data

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

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

[remm]

remm02/03/12 12:21:22

  Modified:coyote/src/java/org/apache/coyote/tomcat4
CoyoteResponse.java
  Log:
  - Port change from the HTTP connector.
  - Revert the patch for 6600, which was causing URL encoding to fail.
  - Bug 6600 will be converted to an enhancement request (the spec doesn't
require this to work).
  
  Revision  ChangesPath
  1.7   +5 -5  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java
  
  Index: CoyoteResponse.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- CoyoteResponse.java   11 Mar 2002 07:13:39 -  1.6
  +++ CoyoteResponse.java   12 Mar 2002 20:21:21 -  1.7
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
 1.6 2002/03/11 07:13:39 remm Exp $
  - * $Revision: 1.6 $
  - * $Date: 2002/03/11 07:13:39 $
  + * $Header: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
 1.7 2002/03/12 20:21:21 remm Exp $
  + * $Revision: 1.7 $
  + * $Date: 2002/03/12 20:21:21 $
*
* 
*
  @@ -114,7 +114,7 @@
*
* @author Remy Maucherat
* @author Craig R. McClanahan
  - * @version $Revision: 1.6 $ $Date: 2002/03/11 07:13:39 $
  + * @version $Revision: 1.7 $ $Date: 2002/03/12 20:21:21 $
*/
   
   public class CoyoteResponse
  @@ -1181,7 +1181,7 @@
   HttpSession session = hreq.getSession(false);
   if (session == null)
   return (false);
  -if (!hreq.isRequestedSessionIdFromURL())
  +if (hreq.isRequestedSessionIdFromCookie())
   return (false);
   
   // Is this a valid absolute URL?
  
  
  

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector HttpResponseBase.java

[remm]

remm02/03/12 12:20:49

  Modified:catalina/src/share/org/apache/catalina/connector
HttpResponseBase.java
  Log:
  - Revert the patch for 6600, which was causing URL encoding to fail.
  - Bug 6600 will be converted to an enhancement request (the spec doesn't
require this to work).
  
  Revision  ChangesPath
  1.50  +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
  
  Index: HttpResponseBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
  retrieving revision 1.49
  retrieving revision 1.50
  diff -u -r1.49 -r1.50
  --- HttpResponseBase.java 22 Feb 2002 06:31:06 -  1.49
  +++ HttpResponseBase.java 12 Mar 2002 20:20:49 -  1.50
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
 1.49 2002/02/22 06:31:06 billbarker Exp $
  - * $Revision: 1.49 $
  - * $Date: 2002/02/22 06:31:06 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
 1.50 2002/03/12 20:20:49 remm Exp $
  + * $Revision: 1.50 $
  + * $Date: 2002/03/12 20:20:49 $
*
* 
*
  @@ -104,7 +104,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.49 $ $Date: 2002/02/22 06:31:06 $
  + * @version $Revision: 1.50 $ $Date: 2002/03/12 20:20:49 $
*/
   
   public class HttpResponseBase
  @@ -506,7 +506,7 @@
   HttpSession session = hreq.getSession(false);
   if (session == null)
   return (false);
  -if (!hreq.isRequestedSessionIdFromURL())
  +if (hreq.isRequestedSessionIdFromCookie())
   return (false);
   
   // Is this a valid absolute URL?
  
  
  

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector HttpResponseBase.java

[remm]

remm02/03/12 12:20:39

  Modified:catalina/src/share/org/apache/catalina/connector Tag:
tomcat_40_branch HttpResponseBase.java
  Log:
  - Revert the patch for 6600, which was causing URL encoding to fail.
  - Bug 6600 will be converted to an enhancement request (the spec doesn't
require this to work).
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.37.2.11 +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
  
  Index: HttpResponseBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
  retrieving revision 1.37.2.10
  retrieving revision 1.37.2.11
  diff -u -r1.37.2.10 -r1.37.2.11
  --- HttpResponseBase.java 22 Feb 2002 06:26:51 -  1.37.2.10
  +++ HttpResponseBase.java 12 Mar 2002 20:20:39 -  1.37.2.11
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
 1.37.2.10 2002/02/22 06:26:51 billbarker Exp $
  - * $Revision: 1.37.2.10 $
  - * $Date: 2002/02/22 06:26:51 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
 1.37.2.11 2002/03/12 20:20:39 remm Exp $
  + * $Revision: 1.37.2.11 $
  + * $Date: 2002/03/12 20:20:39 $
*
* 
*
  @@ -102,7 +102,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.37.2.10 $ $Date: 2002/02/22 06:26:51 $
  + * @version $Revision: 1.37.2.11 $ $Date: 2002/03/12 20:20:39 $
*/
   
   public class HttpResponseBase
  @@ -491,7 +491,7 @@
   HttpSession session = hreq.getSession(false);
   if (session == null)
   return (false);
  -if (!hreq.isRequestedSessionIdFromURL())
  +if (hreq.isRequestedSessionIdFromCookie())
   return (false);
   
   // Is this a valid absolute URL?
  
  
  

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

DO NOT REPLY [Bug 7059] - Jasper compiler holds pointers to jars in WEB-INF/lib: cannot delete

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

Jasper compiler holds pointers to jars in WEB-INF/lib: cannot delete





--- Additional Comments From [EMAIL PROTECTED]  2002-03-12 20:16 ---
org.apache.catalina.startup.ContextConfig also uses a JarURLConnection
on tag library jars in tldConfigJar(...)

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

DO NOT REPLY [Bug 7059] New: - Jasper compiler holds pointers to jars in WEB-INF/lib: cannot delete

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

Jasper compiler holds pointers to jars in WEB-INF/lib: cannot delete

   Summary: Jasper compiler holds pointers to jars in WEB-INF/lib:
cannot delete
   Product: Tomcat 4
   Version: 4.0 Beta 1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The jasper compiler is using JarURLConnections to open tag library jar files
in WEB-INF/lib. JarURLConnection caches the jar by default, and thus
a pointer to the jar (file descriptor?) is kept open so the jar cannot be
deleted. 

This makes redeployment and reloading of web apps difficult, because
taglib jars cannot successfully be replaced. On windows, the delete
operation fails. On Unix, the delete is successful, but the inode
sticks around, and the jar file remains cached. This means that the 
next compile of the JSP will use the old tag library rather than
the new one that was placed in WEB-INF/lib. 

A possible workaround might be to stop tomcat when taglib jars need
to change. 

However, from a development tool perspective, this isn't quite
satisfactory. For example, in netbeans webapp support, the 
jasper compiler is used to compile jsps to report errors without
having to run them. When jsps are compiled in web contexts that
have tag libraries in WEB-INF/lib, those tag libaries can no longer
be deleted. 

Looking in more detail at the jasper compiler, in two files:
org.apache.jasper.compiler.TagLibraryInfoImpl and
org.apache.jasper.compiler.TldLocationsCache, 
JarURLConnections are used, and there is a fixme comment about
the jar url connections caching the jars:
// FIXME @@@
// -- it seems that the JarURLConnection class caches JarFile 
// objects for particular URLs, and there is no way to get 
// it to release the cached entry, so
// there's no way to redeploy from the same JAR file.  Wierd.

It turns out that there are two ways to prevent caching of the jar
files. One is to call setUsesCache(false) on each JarURLConnection
before calling getJarFile, e.g.:
JarURLConnection conn =
(JarURLConnection) url.openConnection();
conn.setUseCaches(false);
jarFile = conn.getJarFile();

Another way is to call URLConnection.setDefaultUseCaches(false), 
which will change the default caching behaviour. Unfortunately, that
is not a static method (even though it sets a private static variable).
Also, it's kind of a large sledgehammer since it changes behaviour for 
all URLConnections. 

There may be other places as well where JarURLConnections are used on 
jars in WEB-INF/lib. They should all be setUseCaches(false)-ed.

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

Re: In memory session replication, reminder

[Jon Scott Stevens]

on 3/12/02 1:08 AM, "GOMEZ Henri" <[EMAIL PROTECTED]> wrote:

> We speak about spread some times ago but the licence wasn't Apache
> at this time, and yes it's another good Broadcast system.
> Good point it support native and java.

Spread has a BSD license now. Thanks to many ASF members speaking to the
spread developers and convincing them to switch.

-jon


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

Re: HTML : multipart/form-data

[Jon Scott Stevens]

on 3/11/02 10:08 PM, "Bojan Smojver" <[EMAIL PROTECTED]> wrote:

> I was looking for a class capable of parsing the above, but I couldn't
> find one in Jakarta source tree (in the meantime I whacked a dodgy one
> together, so my immediate problem is solved). Can someone point me to
> the 'proper' one in in Jakarta sources?
> 
> Bojan

The code you need is in here (MultipartStream.java):




p.s. Unlike Struts, it can be separated out.
p.s. Don't use JavaMail for it, because JavaMail tends to have a lot of
overhead.
p.s. Once again, Turbine rules.

:-)

-jon


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

cvs commit: jakarta-tomcat-connectors/jk/native/nt_service nt_service.dsp

[costin]

costin  02/03/12 11:12:18

  Added:   jk/native/nt_service nt_service.dsp
  Log:
  Added as binary, with dos file ending.
  
  Revision  ChangesPath
  1.8   +199 -199  jakarta-tomcat-connectors/jk/native/nt_service/nt_service.dsp
  
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native/nt_service nt_service.dsp

[costin]

costin  02/03/12 11:11:36

  Removed: jk/native/nt_service nt_service.dsp
  Log:
  Removed to be added back as -kb

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

Re: jk2: Config changes ( again )

[costinm]

On Tue, 12 Mar 2002, jean-frederic clere wrote:

> myworker1=
> Would be the same as:
> myworker1=ajp13://localhost:8009?lbfactor=0&debug=ERROR
> (no load balancing and only log error messages).

 
> How to describe AF_UNIX or shared memory (as transport but not protocol)?
> myworker1=ajp13://file_name:afsocket?lbfactor=0&debug=ERROR
> myworker1=ajp13://key_file:shm?lbfactor=0&debug=ERROR

Good question... 

ajp13:aprChannel:/tmp/tomcat.socket?
or
apj13:channel.apr:/tmp/tomcat.socket?lbfactor=0...

ajp13:jniChannel?lbfactor=0&debug=0

If no channel is specified, default to the socket channel.
ajp13:channel.socket://localhost:8009
ajp13://localhost:8009

Ok, so the question is: which form ? The goal is to be intuitive, easy to 
type, easy to explain. It seems some hierarchical naming is the best way
( but which form ? ).

So far we have the following:

- separators do not matter ( syntactical sugar ) - . : / _ -
- each 'name' is hierarchical
- a name with a single component ( myworker1 ) defines an alias, for 
easier typing. The RHS will be the real name. Question: should it be
alias.myworker1=ajp13:// ?

- The first part of the hierarchical name will identify the type. 

- The second part of the hierarchical name be used by the constructor.
For example, the ajp13 constructor will take the local part and interpret 
the first component as a channel name, then what's after ? as parameters.

What do we do about properties ? Are we going with 2 styles - a URL style
and a workers.properties style ? 

In workers.properties style:


ajp13.[LOCAL_PART].port=8009
ajp13.[LOCAL_PART].debug=0
ajp13.[LOCAL_PART].lbfactor=1


More ideas ? Implementing this is not trivial, but I would hate to have to 
do it again. 

Costin







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

RE: JSP parsing bug?

[Tomas Rokicki]

This isn't a bug; this is according to spec.  The parsing
of the <%...%> is done first, independent of whatever bytes
might be in there.  Thus, your code looks to the JSP compiler
like

A declaration consisting of
"

// <% comment "

Literal content consisting of
"

final static int SOME_INT = 0xF;

public void someMethod(){

}
%>
This page demonstrates a parsing bug"

So, I'd say, no bug.  Just a common misunderstanding.

-tom

-Original Message-
From: Alf Scherer [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 12, 2002 10:53 AM
To: Tomcat Developers List
Subject: JSP parsing bug?


Hi,

I've discovered something that looks like a bug to me, although I'm not
sure whethter this should/can be classified as a bug. The following
behavour occurs when you put "<% %>"-JSP tags inside a java comment in a
JSP file. The code following the comment will be displayed on the page
when requesting the file.


You can try the following code snippet to see how it works out.

 snip 
<%!

// <% comment %> 

final static int SOME_INT = 0xF;

public void someMethod(){

}
%>
This page demonstrates a parsing bug
 snip 

Cya,
Alf


-
 Alf Scherer|
|
 CarrotMEDIA GmbH   |
 Saegewerkstr. 3| Q: What is a programmer?
 83395 Freilassing  | A: A bio-chemical machine, turning 
 Germany, EU|coffee into lines of code
- 


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

JSP parsing bug?

[Alf Scherer]

Hi,

I've discovered something that looks like a bug to me, although I'm not
sure whethter this should/can be classified as a bug. The following
behavour occurs when you put "<% %>"-JSP tags inside a java comment in a
JSP file. The code following the comment will be displayed on the page
when requesting the file.


You can try the following code snippet to see how it works out.

 snip 
<%!

// <% comment %> 

final static int SOME_INT = 0xF;

public void someMethod(){

}
%>
This page demonstrates a parsing bug
 snip 

Cya,
Alf


-
 Alf Scherer|
|
 CarrotMEDIA GmbH   |
 Saegewerkstr. 3| Q: What is a programmer?
 83395 Freilassing  | A: A bio-chemical machine, turning 
 Germany, EU|coffee into lines of code
- 



smime.p7s
Description: application/pkcs7-signature

RE: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/to mcat/util/http MimeHeaders.java

[Larry Isaacs]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, March 12, 2002 11:01 AM
> To: Tomcat Developers List
> Subject: RE: cvs commit: 
> jakarta-tomcat-connectors/util/java/org/apache/to 
> mcat/util/http MimeHeaders.java
> 
> 
> On Tue, 12 Mar 2002, Larry Isaacs wrote:
> 
> > I prefer not to move tomcat_util to J-T-C until after Tomcat 3.3.1, 
> > which I plan on getting out this week or weekend at the 
> latest. After 
> > that, I'm +1.
> 
> Sounds great. 
> 
> What about including the alpha of coyote and jk2(java) with 3.3.1 ? 
> ( disabled, but easy to activate )

Being short on time, I'm also reluctant to alter my build scripts
until after 3.3.1 (rarely get things right the first time :-( ).
I'll be sure to mention its availablitiy in the download site and
the announcement.

Larry

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

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

Re: jk2: Config changes ( again )

[jean-frederic clere]

[EMAIL PROTECTED] wrote:
> 
> On Tue, 12 Mar 2002, jean-frederic clere wrote:
> 
> > What to do when myvhost is www.apache.org for example...
> > uri."www.apache.org:/examples".worker? Using ':' instead of '.' does not
> > solve the problem.
> 
> Sounds good.
> 
> If we use a hierarchical name we also solve the 'type' restriction:
> 
>  worker.ajp13_9009.port=9009
> or
>  worker.ajp13.9009.port=9009
> 
> Each name must start with the type. Quotes can be used for the local part,
> and will be ignored. The local part can be used in the constructor ( I
> mean factory :-) for additional heuristics, to reduce the amount of
> configuration.
> 
>  worker.ajp13."host2.foo:8009"
> or
>  worker.ajp13.host2.foo:8009
> 
> I would still like to have : and uri-style names at least as an option.
> 
> What about using URI for name:
> 
>   ajp13://host.foo:8009/?lbfactor=1
> or
>   ajp13://host.foo:8009/;lbfactor=1
> 
> Even better - .:/_"- are delimiters, the prefix is used to locate the type
> ( it can have one or more components ), the last component is used as
> property. And the property and "=value" are optional - so
> 
> ajp13://host.foo:8009
> 
> will be a valid construct in workers.properties, the name used in
> constructor and all properties with default values.
> 
> If we do that we can simplify the config even more - and eliminate the
> requirement for a worker to be declared in workers.properties. You just
> use a uri for the name, in the JkMount equivalent - and we'll know
> what to do.
> 
> Even more extreme - use full uri, with query strings. We're in a http
> server, we should know how to parse this kind of stuff :-)
> 
> 
>   JkUriSet worker ajp13://tomcat_host.my.com:8009?lbfactor=10&debug=INFO
> 
> 
> And another idea for workers.properties:
> 
> myworker1=ajp13://host.name.com:8009?lbfactor=10&debug=INFO
> 
> In this case the name ( without any delimiter ) will act as a shortcut or
> alias, the RHS will be a URI that will be used in constructor. Both alias
> or the uri can be used in JkMount/JkUriSet/uri properties.

myworker1=
Would be the same as:
myworker1=ajp13://localhost:8009?lbfactor=0&debug=ERROR
(no load balancing and only log error messages).

How to describe AF_UNIX or shared memory (as transport but not protocol)?
myworker1=ajp13://file_name:afsocket?lbfactor=0&debug=ERROR
myworker1=ajp13://key_file:shm?lbfactor=0&debug=ERROR

> 
> More brainstorming ? Should we post this on tomcat-users, to get more
> feedback ?
> 
> Costin
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

Error Starting Tomcat 4.0.1 in AIX

[Andy Soedibjo]

Hi All,

I've been installed tomcat 4.0.3 for windows successfully. But, now when i 
try to install tomcat 4.0.3 in AIX, i can start the Tomcat ... but
with some error message. I've tried to debug it, but still i can't find why 
it happens.

It's seemed from the error message, the Tomcat can't find the 
getResourcePaths method in the implementation class of
javax.servlet.ServletContext (that is ApplicationContext).

But, i've seen the source code of ApplicationContext and it contains this 
method.

Does anyone has ever faced this problem before?
Any suggestion is welcomed, and thanks in advance.

Best Regards,
Andy S.

NB: This is my error message:

2002-03-12 16:53:34 StandardContext[/manager]: Starting
2002-03-12 16:53:34 StandardContext[/manager]: Processing start(), current 
available=false
2002-03-12 16:53:34 StandardContext[/manager]: Configuring default Resources
2002-03-12 16:53:34 StandardContext[/manager]: Configuring non-privileged 
default Loader
2002-03-12 16:53:34 StandardContext[/manager]: Configuring default Manager
2002-03-12 16:53:34 StandardContext[/manager]: Processing standard 
container startup
2002-03-12 16:53:34 WebappLoader[/manager]: Deploying class repositories to 
work directory /home/logserv/jakarta-tomcat-4.0.3/work/localhost/manager
2002-03-12 16:53:34 StandardManager[/manager]: Seeding random number 
generator class java.security.SecureRandom
2002-03-12 16:53:34 StandardManager[/manager]: Seeding of random number 
generator has been completed
2002-03-12 16:53:35 ContextConfig[/manager]: ContextConfig: Processing START
2002-03-12 16:53:36 StandardContext[/manager]: Setting deployment 
descriptor public ID to '-//Sun Microsystems, Inc.//DTD Web Application 
2.3//EN'
2002-03-12 16:53:38 StandardContext[/manager]: Setting deployment 
descriptor public ID to '-//Sun Microsystems, Inc.//DTD Web Application 
2.3//EN'
2002-03-12 16:53:38 ContextConfig[/manager]: Scanning web.xml tag libraries
2002-03-12 16:53:38 ContextConfig[/manager]: Scanning library JAR files
2002-03-12 16:53:38 ContextConfig[/manager]: Added certificates -> request 
attribute Valve
2002-03-12 16:53:38 Authenticator[/manager]: No SingleSignOn Valve is present
2002-03-12 16:53:38 ContextConfig[/manager]: Configured an authenticator 
for method BASIC
2002-03-12 16:53:38 ContextConfig[/manager]: Pipline Configuration:
2002-03-12 16:53:38 
ContextConfig[/manager]:   org.apache.catalina.valves.CertificatesValve/1.0
2002-03-12 16:53:38 
ContextConfig[/manager]: 
org.apache.catalina.authenticator.BasicAuthenticator/1.0
2002-03-12 16:53:38 
ContextConfig[/manager]:   org.apache.catalina.core.StandardContextValve/1.0
2002-03-12 16:53:38 ContextConfig[/manager]: ==
2002-03-12 16:53:38 StandardContext[/manager]: Configuring application 
event listeners
2002-03-12 16:53:38 StandardContext[/manager]: Sending application start events
2002-03-12 16:53:38 StandardContext[/manager]: Starting filters
2002-03-12 16:53:38 StandardContext[/manager]: Posting standard context 
attributes
2002-03-12 16:53:38 StandardWrapper[/manager:default]: Loading container 
servlet default
2002-03-12 16:53:38 org.apache.catalina.servlets.DefaultServlet: init
2002-03-12 16:53:38 StandardWrapper[/manager:invoker]: Loading container 
servlet invoker
2002-03-12 16:53:38 org.apache.catalina.servlets.InvokerServlet: init
2002-03-12 16:53:38 org.apache.jasper.servlet.JspServlet: init
2002-03-12 16:53:39 StandardContext[/manager]: Servlet /manager threw 
load() exception
javax.servlet.ServletException: Servlet.init() for servlet jsp threw exception
 at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java(Compiled 
Code))
 at 
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java(Compiled 
Code))
 at 
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java(Compiled 
Code))
 at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3395)
 at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java(Compiled Code))
 at org.apache.catalina.core.StandardHost.start(StandardHost.java:614)
 at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
 at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343)
 at 
org.apache.catalina.core.StandardService.start(StandardService.java:388)
 at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:506)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:781)
 at org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
 at org.apache.catalina.startup.Catalina.process(Catalina.java:179)
 at java.lang.reflect.Method.invoke(Native Method)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)
- Root Cause -
java.lang.NoSuchMethodError: javax.servlet.ServletContext: method 
getResourcePaths(Ljava/lang/String;)Ljava/util/Set; not found

DO NOT REPLY [Bug 7052] - Security manager not initialised or accessed properly

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

Security manager not initialised or accessed properly





--- Additional Comments From [EMAIL PROTECTED]  2002-03-12 17:04 ---
Thanks Glenn - I understand that the issue should be assessed in a wider context.  I'm 
up and 
running, anyway, it's just that it seems a bit dodgy having to patch Tomcat on each 
client 
site!

Sorry about the monster code listing.  The diff is given 
below.

Keith

177a178,180
> if( securityManager == null ) {
> securityManager = 
System.getSecurityManager();
> }
193a197,199
>  if( securityManager == null ) {
>  
securityManager = System.getSecurityManager();
>  }
211a218,220
> if( 
securityManager == null ) {
> securityManager = System.getSecurityManager();
> }

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

Re: jk2: Config changes ( again )

[costinm]

On Tue, 12 Mar 2002, jean-frederic clere wrote:

> What to do when myvhost is www.apache.org for example...
> uri."www.apache.org:/examples".worker? Using ':' instead of '.' does not
> solve the problem.

Sounds good.

If we use a hierarchical name we also solve the 'type' restriction:

 worker.ajp13_9009.port=9009 
or
 worker.ajp13.9009.port=9009

Each name must start with the type. Quotes can be used for the local part,
and will be ignored. The local part can be used in the constructor ( I 
mean factory :-) for additional heuristics, to reduce the amount of 
configuration.

 worker.ajp13."host2.foo:8009"
or
 worker.ajp13.host2.foo:8009

I would still like to have : and uri-style names at least as an option.

What about using URI for name:
  
  ajp13://host.foo:8009/?lbfactor=1
or
  ajp13://host.foo:8009/;lbfactor=1
 
Even better - .:/_"- are delimiters, the prefix is used to locate the type 
( it can have one or more components ), the last component is used as 
property. And the property and "=value" are optional - so 

ajp13://host.foo:8009 

will be a valid construct in workers.properties, the name used in 
constructor and all properties with default values.

If we do that we can simplify the config even more - and eliminate the 
requirement for a worker to be declared in workers.properties. You just
use a uri for the name, in the JkMount equivalent - and we'll know
what to do.

Even more extreme - use full uri, with query strings. We're in a http 
server, we should know how to parse this kind of stuff :-)


  JkUriSet worker ajp13://tomcat_host.my.com:8009?lbfactor=10&debug=INFO


And another idea for workers.properties:

myworker1=ajp13://host.name.com:8009?lbfactor=10&debug=INFO

In this case the name ( without any delimiter ) will act as a shortcut or 
alias, the RHS will be a URI that will be used in constructor. Both alias
or the uri can be used in JkMount/JkUriSet/uri properties.

More brainstorming ? Should we post this on tomcat-users, to get more 
feedback ? 

Costin


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

RE: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http MimeHeaders.java

[costinm]

On Tue, 12 Mar 2002, Larry Isaacs wrote:

> I prefer not to move tomcat_util to J-T-C until after Tomcat 3.3.1,
> which I plan on getting out this week or weekend at the latest.
> After that, I'm +1.

Sounds great. 

What about including the alpha of coyote and jk2(java) with 3.3.1 ? 
( disabled, but easy to activate )

Costin


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

Re: pluggable security implementations

[Eric Rescorla]

Nick Betteridge <[EMAIL PROTECTED]> writes:
> I've written the TLS socket but haven't been able to get around to
> testing it yet - swamped.
I know how that is.

> The socket also has a certificate factory to enable certificates to be
> read from a variety of sources.
This seems like a nice addition.

> I hope that the following server.xml snip correctly describes the
> inclusion!
Our experience with 3.3 was that just having a single socket factory
didn't work very well, because you also need to choose the right
classes to get socket info... The 3.3 approach was to have a 
single meta-class which provided factories for both the socket
and the accessors.

I need to look over Coyote and see how things woudl fit in there...

-Ekr



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

Re: pluggable security implementations

[Eric Rescorla]

"Bill Barker" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> > By "pluggable security implementations", I assume you really mean
> > pluggable SSL implementations?  I'd certainly be +1 if someone wanted to
> > tackle porting the changes that were made in 3.3 to make this pluggable.
> >
> 
> AFAIK, Eric wanted to get to this at one point (and who could be better
> qualified :).  I think that it will be easier to do this in Coyote than the
> current Http11Connector.
Yeah, at one point is about right. I'm a little swamped right now, so
I couldn't do any more than a rush job--always a dangerous practice on
security critical code. I'll be happy to offer advice and review
if someone else wants to take a shot at it. Alternately, if someone
can commit to giving my code a thorough review, I'll take a crack
at it myself.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

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

[Coyote] Coyote 1.0 Beta 2 available

[Remy Maucherat]

Coyote 1.0 Beta 2 is now available, and includes:
- A high performance HTTP/1.1 processor
- An adapter for Tomcat 3.3.x (new in this release)
- An adapter for Tomcat 4.0.x
- Bugfixes over 1.0 Beta 1

Binaries can be downloaded at:
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/coyote/release/v1
.0-b2/

Installation instructions for both 3.3.x and 4.0.x are given on the download
page. The Tomcat 4 nighly builds already include this new connector.

Remy


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

DO NOT REPLY [Bug 7052] - Security manager not initialised or accessed properly

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

Security manager not initialised or accessed properly





--- Additional Comments From [EMAIL PROTECTED]  2002-03-12 15:57 ---
I'll take a look at your changes within the overall SecurityManager design.

BTW, a patch created with diff -u is much easier to work with, could you
please submit one?

Thanks,

Glenn

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

Re: DO NOT REPLY [Bug 5785] - XML request time attributenotgenerated correctly

[Khun Yee Fung]

Thanks for the message. It is wonderful to know that we are not the only ones that got 
stuck. In my opinion, JSP 1.2 XML has two bugs. This and the fact that we can't 
specify that the output is really HTML in XHTML form. In other words, we need 
something like the output method in XSLT and James Clark's implementation of that 
element in his XT XSLT processor: that you can plug in an output module to handle the 
actual tag outputs. For instance, if you specify that the output is really HTML, the 
HTML output module will take over and makes sure the tags it outputs are proper HTML 
tags. We used that approach with XT to output some bizzarre HTML-like markup languages 
like HDML, WML variants that insist of having the literal & character (literal & 
characters, can you imagine that?) in their attributes (it caused so much pain...). As 
long as it sends the JSP tags to the JSP output writer, the JSP semantics will still 
be maintained.

I might just have to implement something like that. Obviously, that will not violate 
the JSP 1.2 spec. A post-processor, if you like. I will simply use the mime type that 
you can specify in JSP pages to indicate the output engine to use...

Let me think about the solution you have. I am not sure how we can incorporate it into 
our system. In our system, we start from XML files that specify HTML Form elements on 
pages, without presentation. We then use XSLT to convert that into JSP pages that 
combine look-and-feel elements from other files. In this way, we can generate a Web 
site with a particular look-and-feel in about 2 minutes, and still basically serve JSP 
pages. Half a year ago, we used JSP 1.1 with CDATA sections and  all over the place in our XSLT scripts. It was painful, 
not to mention very error-prone, as we cannot expect XML to match tags and attribute 
quotes for us any more. So I was ecstatic when JSP 1.2 XML came out. Now, if I had to 
follow the spec, I had two choices: tons of CDATA sections and xsl:text and generally 
ugliness in my XSLT scripts, or tons of CDATA sections and generally ugliness in the 
JSP pages we generate. What a choice! :)

About the need for namespace prefix. I can use xmlns='...' to declare the default 
namespace to be my namespace name. That will get rid of the prefix.

Don't apologise for long messages. They are good for clearing up complex situations.

Khun Yee


>>> [EMAIL PROTECTED] 03/12/02 03:46AM >>>
Hi,

> *moan* Now I have to convert HTML tags we have that use request-time
attributes
> into custom tags so that we can give them request time attributes. *sigh*
Is it going
> to change in 1.3? I mean, XSLT allows all *non*-XSLT tags to have the
equivalent
> of request-time attributes. I guess I thought JSP would be the same. It
just makes
> sense, doesn't it? :)

We ran into exactly the same problem. IMO it's a really ugly spec bug :-(  I
already sent a comment about that to [EMAIL PROTECTED], but got
no response. We (kind of) solved the problem by wrapping our pages in custom
tags that buffer their body content and parse it by hand. Of course, this
doesn't work for arbitrary expressions without putting a lot of effort into
it. In our case, we just look up pageContext attributes so that



is translated into



with "someImg" being the value of pageContext.getAttribute("someSrc").

Since this is not satisfactory, we're currently working at a solution that
takes an XML document that looks like a JSP and translates it into a
non-XML-JSP (via XSLT). During translation, all %= = attribute values are
replaced by the appropriate code. This way, you're still working with
something that looks like an XML-JSP but with RT attribute expressions in
_all_ tags. If you're interested, I can send you more information. Note:
This work is done within a diploma thesis, so it's absolutely free to use,
copy, change, ...

> Well, maybe I can kill two birds with one stone: sooner or later I need to
get real
> HTML syntax out of my JSP1.2 pages anyway, maybe I will just get all the
HTML
> custom tags to output proper HTML syntax tags. The performance is going to
be
> bad though...

I really wouldn't do that, it's too work for what you get at the end. BTW, I
don't think you can sell  (or other html tags) to Jasper as custom
tags without a namespace prefix: . And this looks _really_
ugly!

Best regards

  Andreas Junghans

PS Sorry for being so lengthy, it's a bad habit of mine ...



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


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

DO NOT REPLY [Bug 7052] New: - Security manager not initialised or accessed properly

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

Security manager not initialised or accessed properly

   Summary: Security manager not initialised or accessed properly
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


OS: Win2K

JDK: 1.3.1_02

Stack Trace:

java.lang.NullPointerException
at 
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:180)
at 
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:132)
at 
java.lang.ClassLoader.loadClassInternal(Unknown Source)
at 
org.apache.jsp.RMStartRim$jsp._jspService(RMStartRim$jsp.java:114)
at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:202)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at 
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at 
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at 
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at 
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at 
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1012)
at 
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1107)
at 
java.lang.Thread.run(Unknown Source)


Investigation:

I have had a problem 
running JSPs under Tomcat 4.x embedded in JBoss 2.4.4, which I believe stems from the 
initialisation of the "java.security.manager" system property.

When running Tomcat 
inside JBoss, the security manager property does not seem to be automatically 
initialised, 
perhaps because JBoss uses a different security model.  If you try to initialise the 
system 
property value yourself by specifying a security manager class name in the JBoss 
startup file 
command line, you get a weird error, which I have not been able to debug since it 
crashes the JBoss 
VM entirely.

Anyway, this would perhaps not matter to some people, who can get away without 
specifying a security manager directly in their own code.  However, I need to set one 
for the RMI 
calls in Jini, since I persist data via a JavaSpace.  Hence a part of my application 
initialisation is to set the system security manager.

Now, the Tomcat class loader object 
(an instance of org.apache.jasper.servlet.JasperLoader) is created before any web apps 
are 
loaded, and there seems to be a bu

DO NOT REPLY [Bug 7026] - AutoDeploy works bad

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

AutoDeploy works bad

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |



--- Additional Comments From [EMAIL PROTECTED]  2002-03-12 14:40 ---
In my configuration file server.xml, I put :
 


But I still have the problem : when I update some times my web application, 
I have more and more native_threads java (corresponding of my application servlets 
which are loaded on startup).
(and the maxSpareThreads doesn't change anything)

So, I think there is a real bug.

But my question is :
Is there a solution, in tomcat 3.3, for updating existing web applications (on 
production servers) without re-starting the entire server ?

I tried with  (as described above) or with the Administration tools 
(remove then add context) 
but nothing is acceptable...

thanks

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

RE: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http MimeHeaders.java

[Larry Isaacs]

I prefer not to move tomcat_util to J-T-C until after Tomcat 3.3.1,
which I plan on getting out this week or weekend at the latest.
After that, I'm +1.

Cheers,
Larry

> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, March 11, 2002 7:10 PM
> To: Tomcat Developers List
> Subject: Re: cvs commit: 
> jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/htt
> p MimeHeaders.java
> 
> 
> > On Mon, 11 Mar 2002, Bill Barker wrote:
> >
> > > Now if we could just make the code common to 3.3/4.0. :(
> > > I think that we'll probably have to review the tomcat_util.jar 
> > > policies
> in
> > > 3.3.2 now that more people are likely to start using modules from 
> > > j-t-c.
> >
> > What about removing the tomcat_util from 3.3 tree, and keeping a 
> > single copy in j-t-c ?
> >
> > As long as tomcat_util.jar is backward compatibile it is 
> possible to 
> > use new modules with any 3.3.x - by upgrading the jar with 
> the newer 
> > version.
> >
> > Larry - would you be comfortable with this ? It's much easier than 
> > duplicating each change in 2 trees ( especially since Remy may be 
> > uncomfortable updating the changes in 3.3 tree :-).
> 
> I didn't know I was supposed to keep them in sync ;-)
> 
> I noticed it was a very bad idea to keep duplicated sources, 
> so +1 for removing the duplication.
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 

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

DO NOT REPLY [Bug 7043] - database user and password for JDBC Based Store

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

database user and password for JDBC Based Store 





--- Additional Comments From [EMAIL PROTECTED]  2002-03-12 10:17 ---
Created an attachment (id=1337)
The popup window

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

DO NOT REPLY [Bug 7043] - database user and password for JDBC Based Store

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

database user and password for JDBC Based Store 





--- Additional Comments From [EMAIL PROTECTED]  2002-03-12 10:17 ---
Created an attachment (id=1336)
change JDBCStore

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

DO NOT REPLY [Bug 7043] New: - database user and password for JDBC Based Store

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

database user and password for JDBC Based Store 

   Summary: database user and password for JDBC Based Store
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,
in my opinion the possibility to use a user with password to connect the 
database would make sense.

May be that these parameters should be asked by a popup window during starting 
of Tomcat so that they are not stored in the configuration file. Hacking the 
file system is much easier than the database.

I have attached two source file doing thi suggestion.

Best regards

Thomas Mäsing

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

Re: HTML : multipart/form-data

[Bojan Smojver]

That was my first thought as well but I never carried it through, mostly
because I was too lazy to do the RTFM. I guess I can always rewrite my
own parser with the JavaMail stuff.

Thanks for the code...

Bojan

On Tue, 2002-03-12 at 19:54, Andreas Junghans wrote:
> Hi Bojan,
> 
> you can use JavaMail for that. Below is a code snippet that extracts all the
> parts of the form data (probably could need some cleanup though). I don't
> know if this solution works under all circumstances, but we're using it
> regularly with no problems so far.
> 
> Best regards
> 
>   Andreas Junghans
> 
> 
> Properties props = System.getProperties();
> javax.mail.Session session = javax.mail.Session.getDefaultInstance(props,
> null);
> String headers = "Content-Type: " + request.getContentType() + "\r\n\r\n";
> InputStream messageIS = null;
> MimeMessage message = null;
> messageIS = new SequenceInputStream(new
> ByteArrayInputStream(headers.getBytes()), request.getInputStream());
> message = new MimeMessage(session, messageIS);
> 
> MimeMultipart multi = (MimeMultipart) message.getContent();
> int count = multi.getCount();
> int i;
> MimeBodyPart part = null;
> String name;
> String content;
> for (i = 0; i < count; ++i) {
> part = (MimeBodyPart) multi.getBodyPart(i);
> disp = part.getHeader("Content-Disposition")[0];
> name = disp.substring(disp.indexOf("name=\"") + 6);
> name = name.substring(0, name.indexOf('"'));
> ...
> content = (String)part.getContent();
> ...
> }
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 



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

RE: pluggable security implementations

[GOMEZ Henri]

>AFAIK, Eric wanted to get to this at one point (and who could be better
>qualified :).  I think that it will be easier to do this in 
>Coyote than the
>current Http11Connector.

+1, since Coyote may be the common http 1.1 connector for TC 3.3
and 4.0, let focus effort on it

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

RE: cvs commit: jakarta-tomcat/src/doc tomcat-ssl-howto.html

[GOMEZ Henri]

cryptix, cryptix-asn1 and puretls RPMs are also in
the jpackage project:

http://www.jpackage.org


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, March 12, 2002 5:12 AM
>To: [EMAIL PROTECTED]
>Subject: cvs commit: jakarta-tomcat/src/doc tomcat-ssl-howto.html
>
>
>larryi  02/03/11 20:11:52
>
>  Modified:src/doc  tomcat-ssl-howto.html
>  Log:
>  Fix cryptix link.
>  
>  Revision  ChangesPath
>  1.10  +4 -6  jakarta-tomcat/src/doc/tomcat-ssl-howto.html
>  
>  Index: tomcat-ssl-howto.html
>  ===
>  RCS file: /home/cvs/jakarta-tomcat/src/doc/tomcat-ssl-howto.html,v
>  retrieving revision 1.9
>  retrieving revision 1.10
>  diff -u -r1.9 -r1.10
>  --- tomcat-ssl-howto.html27 Feb 2002 02:25:20 -  1.9
>  +++ tomcat-ssl-howto.html12 Mar 2002 04:11:52 -  1.10
>  @@ -215,7 +215,7 @@
>   PureTLS is open source (BSD-style license) and JSSE is 
>closed source.
>   Therefore, if you want to redistribute compiled versions of 
>Tomcat or
>   just look at the source of your SSL/TLS implementation you must
>  -use PureTLS. 
>  +use PureTLS.
>   
>   At build time (via Ant), Tomcat will automatically build as 
>much SSL support
>   as it can. If you have both PureTLS and JSSE in your 
>CLASSPATH,
>  @@ -535,7 +535,7 @@
>   
>   SSL Support with PureTLS
>   1. Downloading and Installing PureTLS
>  -The easiest way to download PureTLS is by simply downloading the 
>  +The easiest way to download PureTLS is by simply downloading the
>   prebuilt version from href="http://www.rtfm.com/puretls/prebuilt.html";>
>   http://www.rtfm.com/puretls/prebuilt.html. This version contains
>   all the jar files you will need in order to use PureTLS in 
>one package.
>  @@ -564,10 +564,8 @@
>   Alternately, you can download the PureTLS source distribution from
>   http://www.rtfm.com/puretls";>http://www.rtfm.com/puretls
>and build it yourself. You will also need to install
>  -Cryptix 3.2 from href="http://www.cryptix.org>http://www.cryptix.org/";>
>  -http://www.cryptix.org/
>  -. Once you've built Cryptix and PureTLS, install them 
>as described
>  -above.
>  +Cryptix 3.2 from href="http://www.cryptix.org/";>http://www.cryptix.org/.
>  +Once you've built Cryptix and PureTLS, install them as 
>described above.
>   
>   2. Obtaining Keys and Certificates
>   
>  
>  
>  
>
>--
>To unsubscribe, e-mail:   

For additional commands, e-mail: 


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

RE: In memory session replication, reminder

[GOMEZ Henri]

>If you liked that, also have a look at Spread:
>
>http://www.spread.org/
>
>The messaging engine (daemon) isn't written in Java, but it's very
>fast and efficient, and runs on all the popular OSs.  The Java clients
>connect to it via TCP sockets, so the clients can be pure-Java.  The
>License is similar to the Apache license, and unlike JavaGroups the
>engine does know to fall back to using TCP unicast when multicast is
>not available.  It's been around for quite some time, too.

We speak about spread some times ago but the licence wasn't Apache 
at this time, and yes it's another good Broadcast system. 
Good point it support native and java.

>What I'd like to do at some point is take Filip Hanik's TC4 session
>replication code (looking nice!) and make it switchable to use either
>Spread or JavaGroups, or other communication mechanisms for keeping the
>session data in sync. Pluggable messaging back-ends..
>
>FWIW, I'd like to see the in-memory session replication code as part
>of TC4 itself, with a pluggable messaging layer API that allows
>a separate messaging system to be used.  But, if people decide that
>it's better suited to j-t-c, then that's okay (not quite as good, IMO),
>but I'd still like it to have a pluggable messaging layer API.

Did the session replication and propagation is something which 
could be usefull for TC 3.3/4.0 ? 

If so, it'll better to have it in jtc.

And since you point us that there is at least 2 solutions, javagroups
and spread, it's another reason to have it in jtc where we could add
others implementations



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

Re: HTML : multipart/form-data

[Andreas Junghans]

Hi Bojan,

you can use JavaMail for that. Below is a code snippet that extracts all the
parts of the form data (probably could need some cleanup though). I don't
know if this solution works under all circumstances, but we're using it
regularly with no problems so far.

Best regards

  Andreas Junghans


Properties props = System.getProperties();
javax.mail.Session session = javax.mail.Session.getDefaultInstance(props,
null);
String headers = "Content-Type: " + request.getContentType() + "\r\n\r\n";
InputStream messageIS = null;
MimeMessage message = null;
messageIS = new SequenceInputStream(new
ByteArrayInputStream(headers.getBytes()), request.getInputStream());
message = new MimeMessage(session, messageIS);

MimeMultipart multi = (MimeMultipart) message.getContent();
int count = multi.getCount();
int i;
MimeBodyPart part = null;
String name;
String content;
for (i = 0; i < count; ++i) {
part = (MimeBodyPart) multi.getBodyPart(i);
disp = part.getHeader("Content-Disposition")[0];
name = disp.substring(disp.indexOf("name=\"") + 6);
name = name.substring(0, name.indexOf('"'));
...
content = (String)part.getContent();
...
}



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

Re: DO NOT REPLY [Bug 5785] - XML request time attribute notgenerated correctly

[Andreas Junghans]

Hi,

> *moan* Now I have to convert HTML tags we have that use request-time
attributes
> into custom tags so that we can give them request time attributes. *sigh*
Is it going
> to change in 1.3? I mean, XSLT allows all *non*-XSLT tags to have the
equivalent
> of request-time attributes. I guess I thought JSP would be the same. It
just makes
> sense, doesn't it? :)

We ran into exactly the same problem. IMO it's a really ugly spec bug :-(  I
already sent a comment about that to [EMAIL PROTECTED], but got
no response. We (kind of) solved the problem by wrapping our pages in custom
tags that buffer their body content and parse it by hand. Of course, this
doesn't work for arbitrary expressions without putting a lot of effort into
it. In our case, we just look up pageContext attributes so that



is translated into



with "someImg" being the value of pageContext.getAttribute("someSrc").

Since this is not satisfactory, we're currently working at a solution that
takes an XML document that looks like a JSP and translates it into a
non-XML-JSP (via XSLT). During translation, all %= = attribute values are
replaced by the appropriate code. This way, you're still working with
something that looks like an XML-JSP but with RT attribute expressions in
_all_ tags. If you're interested, I can send you more information. Note:
This work is done within a diploma thesis, so it's absolutely free to use,
copy, change, ...

> Well, maybe I can kill two birds with one stone: sooner or later I need to
get real
> HTML syntax out of my JSP1.2 pages anyway, maybe I will just get all the
HTML
> custom tags to output proper HTML syntax tags. The performance is going to
be
> bad though...

I really wouldn't do that, it's too work for what you get at the end. BTW, I
don't think you can sell  (or other html tags) to Jasper as custom
tags without a namespace prefix: . And this looks _really_
ugly!

Best regards

  Andreas Junghans

PS Sorry for being so lengthy, it's a bad habit of mine ...



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