[PATCH] Tyrex 1.0 w/ Tomcat

[David Haraburda]

Hi all,

I have written a patch to make Tomcat work with Tyrex 1.0.  Here's a
summary of the new classes/code and how it all works.  I apologize for
the length of this post, the explanation is necessary I feel...

New class org.apache.naming.factory.TyrexFactory:

Tyrex now has the idea of a TransactionDomain, which manages resources
and transactions and is configured through an XML config file.  In order
to instantiate a TransactionDomain instance, the class must know two
things: the location of the domain config file, and the name of the
domain to lookup in the file.  The way I've set it up, these two string
configuration parameters must be present in the java:comp/env
namespace.  The TyrexFactory is an abstract superclass that provides a
method to lookup these configuration parameters and create the
TransactionDomain.  The two subclasses of this abstract class are...

New/modified class: org.apache.naming.factory.TyrexTransactionFactory:

This factory simply uses the TransactionDomain to create a
javax.transaction.UserTransaction.

New class org.apache.naming.factory.TyrexResourceFactory:
(this replaces TyrexDataSourceFactory)

Tyrex now also has the idea of resources, of which now there are only
two "flavors" right now:  JDBC DataSources and JCA connectors.  Since
the configuration of these resources must be done in Tyrex's domain XML
config file, this factory simply returns the resource with the specified
name -- it is up to the user know what to do with the Object returned.

Here's an example of how Tyrex would be setup for a simple JDBC
datasource.  Let's say you have a domain-config.xml file, with a domain
named "my-domain", which has a resource named "my-db", which is a JDBC
datasource (see Tyrex docs for more info).  In the server.xml file, we
would need to specify two environment parameters:




and a resource:



  
name
my-db
  


This would all need to go under a  element (I made the two
config strings global environment elements, and created ResourceLinks
instead).

Now, the domain-config.xml file is placed where the classloader can use
getResource() to find it (so, WEB-INF/classes is a good place), and
everything should be ready to go.  You can now do:

InitialContext initCtx = new InitialContext();
DataSource ds = (DataSource) 
 initCtx.lookup("java:comp/env/my-datasource");
Connection conn = ds.getConnection();
... etc

in your user-level code.  Tyrex is still the default factory for
UserTransaction, so lookups on java:comp/env/UserTransaction work.

There are a few caveats:

(1) This is kind of a pain, but it's the way Tyrex 1.0 works.  This way
provides a lot of flexibility, without too much extra hassle.  If these
changes are made, however, a HOWTO is probably needed.  I can put one
together.
(2) For this to work, Tomcat now needs to be able to load the Tyrex
classes, and any classes it uses.  This means the tyrex jar and all
other jars included in the Tyrex distribution need to go in common/lib
(that includes JTA, OTS-JTS, and Xerces).  Furthermore, Tyrex needs some
JARs that it doesn't include in its distribution: the Castor XML jar,
and the Log4J jar.  This is six jars that need to be in common/lib for
Tyrex to work.  This kind of stinks as well.

Obviously there are probably a few kinks that need to be worked out, but
I've tested what is attached and it seems to work pretty well.

I've attached a cvs diff, as well as the two new files that are needed. 
These two new classes both go in the org.apache.naming.factory package. 
(remember TyrexDataSourceFactory needs to be removed)

Feedback/suggestions on my code is appreciated.  I'd like to see Tyrex
1.0 integrated with Tomcat fairly soon, so I'm prepared to make whatever
changes I need to in order to get the patch committed.

Thanks,

David


? jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/TyrexFactory.java
? 
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/TyrexResourceFactory.java
Index: jakarta-tomcat-4.0/catalina/src/share//org/apache/naming/factory/Constants.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/Constants.java,v
retrieving revision 1.5
diff -b -d -u -r1.5 Constants.java
--- jakarta-tomcat-4.0/catalina/src/share//org/apache/naming/factory/Constants.java
 17 May 2002 17:39:27 -  1.5
+++ jakarta-tomcat-4.0/catalina/src/share//org/apache/naming/factory/Constants.java
+ 21 Jun 2002 07:47:10 -
@@ -91,8 +91,8 @@
 public static final String DBCP_DATASOURCE_FACTORY = 
 "org.apache.commons.dbcp.BasicDataSourceFactory";
 
-public static final String TYREX_DATASOURCE_FACTORY = 
-Package + ".TyrexDataSourceFactory";
+public static final String TYREX_RESOURCE_FACTORY =
+Package + ".TyrexResourceFactory";
 
 public static final String TYREX_TRANSACTION_FACTORY = 
 Package + ".TyrexTransactionFac

RE: mod_jk testing (WAS RE: mod_jk 1.2.0 workers pool)

[GOMEZ Henri]

>First some things about testing:
>
>DO NOT USE the date.jsp (it could return various html lengths, so from
>there are coming those Failed requests ).
>I've just browsed through the source code of ab and it uses the first
>page as its length ethalon, and date.jsp could retur various length if
>the tests are finishing on the single second interval so there 
>is 1 byte
>html length differnce.
>
>Use the /examples/jsp/snp/snoop.jsp instead (think it allways returns
>the same content-length).
>
>The ones that count are only the 'Non-2xx responses'

Thanks for the clue, but I wonder why ab didn't have problems
when using date.jsp with Tomcat's http connectors ?

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

RE: mod_jk apache process 1 to 1 mapping with Tomcat AjpConnector thread

[GOMEZ Henri]

>The issue is not how many requests mod_jk/Tomcat can handle.
>
>The issue is that you end up over time with as many AjpConnector
>threads being created by Tomcat as you have apache httpd processes
>regardless of how many requests are forward on to Tomcat to process.
>For example, I have apache running on a server which hosts about 40
>websites and handles 10 million page views per month. This requires
>at times up to 350 httpd processes to handle peak load. Only one of
>those websites uses Tomcat, yet Tomcat ends up spawning 350 
>AjpConnector
>threads.  But the load from the one site which forwards some requests
>to Tomcat is only 10-15 simultaneous requests.  So Tomcat ends 
>up having
>350 AjpConnector threads when it only really needs 10-20 threads for
>handling the requests which get forwarded to it.

Do you have apache 1.3 or 2.0 ?

>From I see here, both Apache using mod_jk 1.2.0 drop ajp13 connections
when there is no more need for tomcat request. 

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

Close to solution ( WAS RE: mod_jk testing)

[Mladen Turk]

Think we can close that!

I've created the worker pool modifiable through workers.properties with
the worker.ajp13.poolsize.

The sadest thing is that I was so close the solution on day 0 (remember
the  mutexes?).
Well what ever!

There is some minor bug when using loglevel=debug, and it works
currently only for ajp13 (well, ajp common).
Also I'll need the Sleep() for unix.

Since I newer commited the code ever, and the changes are in (4 or 5
files I think), I'll mail it to Henri or someone else to do the dirty
work ;).

Now the crucial (see at the bottom the TC and date.jsp results statet at
different times):

Test results:

worker.ajp13.poolsize=1
worker.ajp13.cachesize=1

Server Software:Apache/2.0.40-dev
Server Hostname:localhost
Server Port:8000

Document Path:  /examples/jsp/snp/snoop.jsp
Document Length:712 bytes

Concurrency Level:  200
Time taken for tests:   103.5572 seconds
Complete requests:  1
Failed requests:0


Test results:

worker.ajp13.cachesize=25
worker.ajp13.poolsize=25



Server Software:Apache/2.0.40-dev
Server Hostname:localhost
Server Port:8000

Document Path:  /examples/jsp/snp/snoop.jsp
Document Length:712 bytes

Concurrency Level:  100
Time taken for tests:   41.586847 seconds
Complete requests:  1
Failed requests:0

Test with 200:

Concurrency Level:  200
Time taken for tests:   38.962629 seconds
Complete requests:  1
Failed requests:0


Document Path:  /examples/jsp/dates/date.jsp
Document Length:453 bytes

Concurrency Level:  200
Time taken for tests:   47.274576 seconds
Complete requests:  1
Failed requests:2180
   (Connect: 0, Length: 2180, Exceptions: 0)


TC Test started on 12:09:11 secs (all the XX seconds)

Server Software:Apache
Server Hostname:localhost
Server Port:8080

Document Path:  /examples/jsp/dates/date.jsp
Document Length:452 bytes

Concurrency Level:  200
Time taken for tests:   44.850752 seconds
Complete requests:  1
Failed requests:0

Server Software:Apache
Server Hostname:localhost
Server Port:8080

TC Test started on 12:11:01 secs (first we have X, then XX seconds)

Document Path:  /examples/jsp/dates/date.jsp
Document Length:452 bytes

Concurrency Level:  200
Time taken for tests:   40.644117 seconds
Complete requests:  1
Failed requests:7966
   (Connect: 0, Length: 7966, Exceptions: 0)


MT


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

Re: [PATCH] Tyrex 1.0 w/ Tomcat

[Remy Maucherat]

David Haraburda wrote:
> Hi all,
> 
> I have written a patch to make Tomcat work with Tyrex 1.0.  Here's a
> summary of the new classes/code and how it all works.  I apologize for
> the length of this post, the explanation is necessary I feel...
> 
> New class org.apache.naming.factory.TyrexFactory:
> 
> Tyrex now has the idea of a TransactionDomain, which manages resources
> and transactions and is configured through an XML config file.  In order
> to instantiate a TransactionDomain instance, the class must know two
> things: the location of the domain config file, and the name of the
> domain to lookup in the file.  The way I've set it up, these two string
> configuration parameters must be present in the java:comp/env
> namespace.  The TyrexFactory is an abstract superclass that provides a
> method to lookup these configuration parameters and create the
> TransactionDomain.  The two subclasses of this abstract class are...
> 
> New/modified class: org.apache.naming.factory.TyrexTransactionFactory:
> 
> This factory simply uses the TransactionDomain to create a
> javax.transaction.UserTransaction.
> 
> New class org.apache.naming.factory.TyrexResourceFactory:
> (this replaces TyrexDataSourceFactory)
> 
> Tyrex now also has the idea of resources, of which now there are only
> two "flavors" right now:  JDBC DataSources and JCA connectors.  Since
> the configuration of these resources must be done in Tyrex's domain XML
> config file, this factory simply returns the resource with the specified
> name -- it is up to the user know what to do with the Object returned.
> 
> Here's an example of how Tyrex would be setup for a simple JDBC
> datasource.  Let's say you have a domain-config.xml file, with a domain
> named "my-domain", which has a resource named "my-db", which is a JDBC
> datasource (see Tyrex docs for more info).  In the server.xml file, we
> would need to specify two environment parameters:
> 
>   value="domain-config.xml"/>
>   value="my-domain"/>
> 
> and a resource:
> 
>type="tyrex.resource.Resource"/>
> 
>   
> name
> my-db
>   
> 
> 
> This would all need to go under a  element (I made the two
> config strings global environment elements, and created ResourceLinks
> instead).
> 
> Now, the domain-config.xml file is placed where the classloader can use
> getResource() to find it (so, WEB-INF/classes is a good place), and
> everything should be ready to go.  You can now do:
> 
> InitialContext initCtx = new InitialContext();
> DataSource ds = (DataSource) 
>  initCtx.lookup("java:comp/env/my-datasource");
> Connection conn = ds.getConnection();
> ... etc
> 
> in your user-level code.  Tyrex is still the default factory for
> UserTransaction, so lookups on java:comp/env/UserTransaction work.
> 
> There are a few caveats:
> 
> (1) This is kind of a pain, but it's the way Tyrex 1.0 works.  This way
> provides a lot of flexibility, without too much extra hassle.  If these
> changes are made, however, a HOWTO is probably needed.  I can put one
> together.
> (2) For this to work, Tomcat now needs to be able to load the Tyrex
> classes, and any classes it uses.  This means the tyrex jar and all
> other jars included in the Tyrex distribution need to go in common/lib
> (that includes JTA, OTS-JTS, and Xerces).  Furthermore, Tyrex needs some
> JARs that it doesn't include in its distribution: the Castor XML jar,
> and the Log4J jar.  This is six jars that need to be in common/lib for
> Tyrex to work.  This kind of stinks as well.
> 
> Obviously there are probably a few kinks that need to be worked out, but
> I've tested what is attached and it seems to work pretty well.
> 
> I've attached a cvs diff, as well as the two new files that are needed. 
> These two new classes both go in the org.apache.naming.factory package. 
> (remember TyrexDataSourceFactory needs to be removed)
> 
> Feedback/suggestions on my code is appreciated.  I'd like to see Tyrex
> 1.0 integrated with Tomcat fairly soon, so I'm prepared to make whatever
> changes I need to in order to get the patch committed.

For the transaction stuff to work properly, don't you need a valve also 
to bind/unbind the Tyrex context ?
Or is this only needed if you would want your transaction to last more 
than one request ?

I'm +1 for the patch. We'll need to add detailed instructions on how to 
use it. Also, the JARs won't ship with Tomcat (it's just too much).

Remy


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

Proposal draft for Tomcat 5.0

[Remy Maucherat]

Hi,

I'm committing a draft for a Tomcat 5 proposal.

It is a draft, so it is not in final form yet (it needs feedback for that).

I'm attaching the document to the mail, in case people don't want to 
checkout the repository.

Remy




Proposal for Apache Tomcat 5.0
==



Introduction:


This document is a proposal for the next major release of Apache Tomcat, 
Apache Tomcat 5.0.

Apache Tomcat 5.0 will improve on the Apache Tomcat 3.3 and Apache
Tomcat 4.1 architectures, by making them simpler, more flexible and more 
modular, while at the same time adding support for the new Servlet API 2.4 and
JSP 2.0 specifications, currently under development by the Java Community 
Process.

The major goals for Apache Tomcat 5.0 are to:
- have simpler/cleaner code, so more people can get involved
- merge of the various ideas in 3.x and 4.x
- get the community togheter
- provide maximum modularity and compliance to the standards
- make it easy to continue to maintain the existing codebases

This proposal also tries to take advantage of the lessons learned while 
optimizing and maintaining Tomcat.

Note: The development of Apache Tomcat 4.1.x will continue in parallel to the 
implementation of this proposal.



General architecture:



An improved version of Coyote 1.0, called Coyote 2.0, will be used as 
the Apache Tomcat 5.0 core.

Coyote is currently considered a connector for Tomcat 3.3 and 4.x, and is under
development in the jakarta-tomcat-connectors repository.

Coyote 1.0 includes:
- Protocol handlers for AJP 1.3, HTTP/1.1 and JNI
- Adapter for Tomcat 3.3
- Adapter for Tomcat 4.x

Extensibility capabilities will be added to Coyote, as well as JMX management
features, and if possible, addional protocol handlers (like WARP 1.0).

The Servlet API 2.4 specification will be implemented in a new version of 
Catalina, called Catalina 2.0. A new version of the Coyote adapter will be
written for it if mandated by API changes. Components which duplicate 
functionality provided by Coyote will be removed, including the old connectors.

On the JSP side, Jasper 2 will be updated to support JSP 2.0, will be renamed 
to Jasper 3, and is the proposed Jasper codebase. It provides many 
improvements over Jasper 1 included in Tomcat 3.x and Tomcat 4.0.x, including 
good tag library handling, and near zero overhead when compared to 
an equivalent hand coded servlet. Jasper 2 will also undergo additional 
optimizations.

Apache Tomcat 5.0 will be made by default of the following components:
- Coyote 2.0 - core
- Catalina 2.0 - Servlet API 2.4 implementation
- Jasper 3 - JSP 2.0 implementation

Many other configurations are also possible, and it is expected that advanced
users take advantage of it to make Tomcat better suit their needs. It is also
possible that new special purpose components, like a bare bones Servlet API 
implementation, be developed to address the embedded market.

Due to the scope of this work, this initial Proposal only plans 
the implementation and support of the default configuration described above.



Resources needed:


* New jakarta-servletapi-5 repository

This new repository will hold the default implementation of the Servlet 
API 2.4 and the JSP 2.0 specifications. Alternately, the new API can be put
in the 'jakarta-servletapi' repository after a branch is created to hold the
current version of the code.

* New jakarta-tomcat-5.0 repository

This repository will contain the version of Catalina which will be updated to
support the Servlet API 2.4. Alternately, this code can be put in the 
'jakarta-tomcat-4.0' or 'jakarta-tomcat' repository after a branch is created
to hold the old code present.

* New branch in jakarta-tomcat-jasper

The implementation of JSP 2.0 will occur in the HEAD branch of the 
jakarta-tomcat-jasper repository. A branch will be created to contain 
the Jasper 2 code which is used in Tomcat 4.1.x.




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

cvs commit: jakarta-tomcat-4.0 PROPOSAL-5.0.txt

[remm]

remm2002/06/21 03:41:19

  Added:   .PROPOSAL-5.0.txt
  Log:
  - Add TC 5 proposal draft.
  - Comments welcome / needed.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-4.0/PROPOSAL-5.0.txt
  
  Index: PROPOSAL-5.0.txt
  ===
  
  
  Proposal for Apache Tomcat 5.0
  ==
  
  
  
  Introduction:
  
  
  This document is a proposal for the next major release of Apache Tomcat, 
  Apache Tomcat 5.0.
  
  Apache Tomcat 5.0 will improve on the Apache Tomcat 3.3 and Apache
  Tomcat 4.1 architectures, by making them simpler, more flexible and more 
  modular, while at the same time adding support for the new Servlet API 2.4 and
  JSP 2.0 specifications, currently under development by the Java Community 
  Process.
  
  The major goals for Apache Tomcat 5.0 are to:
  - have simpler/cleaner code, so more people can get involved
  - merge of the various ideas in 3.x and 4.x
  - get the community togheter
  - provide maximum modularity and compliance to the standards
  - make it easy to continue to maintain the existing codebases
  
  This proposal also tries to take advantage of the lessons learned while 
  optimizing and maintaining Tomcat.
  
  Note: The development of Apache Tomcat 4.1.x will continue in parallel to the 
  implementation of this proposal.
  
  
  
  General architecture:
  
  
  
  An improved version of Coyote 1.0, called Coyote 2.0, will be used as 
  the Apache Tomcat 5.0 core.
  
  Coyote is currently considered a connector for Tomcat 3.3 and 4.x, and is under
  development in the jakarta-tomcat-connectors repository.
  
  Coyote 1.0 includes:
  - Protocol handlers for AJP 1.3, HTTP/1.1 and JNI
  - Adapter for Tomcat 3.3
  - Adapter for Tomcat 4.x
  
  Extensibility capabilities will be added to Coyote, as well as JMX management
  features, and if possible, addional protocol handlers (like WARP 1.0).
  
  The Servlet API 2.4 specification will be implemented in a new version of 
  Catalina, called Catalina 2.0. A new version of the Coyote adapter will be
  written for it if mandated by API changes. Components which duplicate 
  functionality provided by Coyote will be removed, including the old connectors.
  
  On the JSP side, Jasper 2 will be updated to support JSP 2.0, will be renamed 
  to Jasper 3, and is the proposed Jasper codebase. It provides many 
  improvements over Jasper 1 included in Tomcat 3.x and Tomcat 4.0.x, including 
  good tag library handling, and near zero overhead when compared to 
  an equivalent hand coded servlet. Jasper 2 will also undergo additional 
  optimizations.
  
  Apache Tomcat 5.0 will be made by default of the following components:
  - Coyote 2.0 - core
  - Catalina 2.0 - Servlet API 2.4 implementation
  - Jasper 3 - JSP 2.0 implementation
  
  Many other configurations are also possible, and it is expected that advanced
  users take advantage of it to make Tomcat better suit their needs. It is also
  possible that new special purpose components, like a bare bones Servlet API 
  implementation, be developed to address the embedded market.
  
  Due to the scope of this work, this initial Proposal only plans 
  the implementation and support of the default configuration described above.
  
  
  
  Resources needed:
  
  
  * New jakarta-servletapi-5 repository
  
  This new repository will hold the default implementation of the Servlet 
  API 2.4 and the JSP 2.0 specifications. Alternately, the new API can be put
  in the 'jakarta-servletapi' repository after a branch is created to hold the
  current version of the code.
  
  * New jakarta-tomcat-5.0 repository
  
  This repository will contain the version of Catalina which will be updated to
  support the Servlet API 2.4. Alternately, this code can be put in the 
  'jakarta-tomcat-4.0' or 'jakarta-tomcat' repository after a branch is created
  to hold the old code present.
  
  * New branch in jakarta-tomcat-jasper
  
  The implementation of JSP 2.0 will occur in the HEAD branch of the 
  jakarta-tomcat-jasper repository. A branch will be created to contain 
  the Jasper 2 code which is used in Tomcat 4.1.x.
  
  
  
  

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

Re: New warp connector 4.0.4 does not work

[Asar . Khan]

>>"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
>> Hello all,
>>
>> We have Apache 2.0.39 and tomcat 4.0.4 running using the old 4.0.2-01 warp
>> connector.
>>
>> I have tried to build and use the new connector without success. Although it
>> builds fine and Apache seems not to complain about it, I cannot access any
>> pages and keep getting 302 temporarily moved error. The log files do not
>> provide any useful information either.
>>
>> Is this a bug or am I missing something?
>>
>> Also, does anyone know if there is any decent documentation on this?
>
>I haven't yet tried on this environment... What MPM are you using? What OS?
>Did you recompile it from the sources?
>
>Pier
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 


Pier,

The environment is Linux (Redhat 7.2) kernel 2.4.9-34

I used the following steps:

1. compiled and installed apache-2.0.39 from source.
2. compiled and installed autconf 2.53 from source (required for new connector)
3. compiled and installed from source from:
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.4/src/jakarta-tomcat-connectors-4.0.4-src.tar.gz

An older version jakarta-tomcat-connectors-4.0.2-01-src.tar.gz works fine.

Any ideas?



-- --
Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

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

RE: Close to solution ( WAS RE: mod_jk testing)

[GOMEZ Henri]

>Think we can close that!

Ouf.

>I've created the worker pool modifiable through workers.properties with
>the worker.ajp13.poolsize.

Good

>The sadest thing is that I was so close the solution on day 0 (remember
>the  mutexes?).
>Well what ever!

ok

>There is some minor bug when using loglevel=debug, and it works
>currently only for ajp13 (well, ajp common).

Minor bug with loglevel=debug, tell su more ...

>Also I'll need the Sleep() for unix.

Hum, I really dislike to use Sleep/sleep in mod_jk. Delaying something
is not an issue.

>Since I newer commited the code ever, and the changes are in (4 or 5
>files I think), I'll mail it to Henri or someone else to do the dirty
>work ;).

Send the patches to the list

>Now the crucial (see at the bottom the TC and date.jsp results 
>statet at
>different times):
>
>Test results:
>
>worker.ajp13.poolsize=1
>worker.ajp13.cachesize=1
>
>Server Software:Apache/2.0.40-dev
>Server Hostname:localhost
>Server Port:8000
>
>Document Path:  /examples/jsp/snp/snoop.jsp
>Document Length:712 bytes
>
>Concurrency Level:  200
>Time taken for tests:   103.5572 seconds
>Complete requests:  1
>Failed requests:0
>
>
>Test results:
>
>worker.ajp13.cachesize=25
>worker.ajp13.poolsize=25
>
>
>
>Server Software:Apache/2.0.40-dev
>Server Hostname:localhost
>Server Port:8000
>
>Document Path:  /examples/jsp/snp/snoop.jsp
>Document Length:712 bytes
>
>Concurrency Level:  100
>Time taken for tests:   41.586847 seconds
>Complete requests:  1
>Failed requests:0
>
>Test with 200:
>
>Concurrency Level:  200
>Time taken for tests:   38.962629 seconds
>Complete requests:  1
>Failed requests:0
>
>
>Document Path:  /examples/jsp/dates/date.jsp
>Document Length:453 bytes
>
>Concurrency Level:  200
>Time taken for tests:   47.274576 seconds
>Complete requests:  1
>Failed requests:2180
>   (Connect: 0, Length: 2180, Exceptions: 0)
>
>
>TC Test started on 12:09:11 secs (all the XX seconds)
>
>Server Software:Apache
>Server Hostname:localhost
>Server Port:8080
>
>Document Path:  /examples/jsp/dates/date.jsp
>Document Length:452 bytes
>
>Concurrency Level:  200
>Time taken for tests:   44.850752 seconds
>Complete requests:  1
>Failed requests:0
>
>Server Software:Apache
>Server Hostname:localhost
>Server Port:8080
>
>TC Test started on 12:11:01 secs (first we have X, then XX seconds)
>
>Document Path:  /examples/jsp/dates/date.jsp
>Document Length:452 bytes
>
>Concurrency Level:  200
>Time taken for tests:   40.644117 seconds
>Complete requests:  1
>Failed requests:7966
>   (Connect: 0, Length: 7966, Exceptions: 0)

I re-tested mod_jk 1.2.0 against TC 3.3.1 / TC 4.0.4 under
Apache 1.3 and 2.0 with helloworld servlet, and didn't find
anymore errors (ab requested 10 Millions pages with 127 concurrents)

The problem was problably due to the way ab works, and many thanks
to have discovered it :)

We should revue your patches and also the keep-alive add-on 
proposal sent by Jan Singer (firewall/keepalive)

I also listen to Glenn concern about childs/ajp13 and also he's rigth here.
Imagine the following situation.

An Apache server is used to handle statics pages and route requests to 
tomcat(s).

Under load Apache will create many childs/threads. 

At some times, requests will be for tomcat, so the child/thread 
which got the request will create the ajp13 connection.

You could end-up with an Apache where all childs/threads will 
open an ajp13 connection, even if they do not send any more requests
to tomcats.

A solution could be to close open connection after some moments
of inactivity, ie a stressed child will see if it didn't used 
it's ajp13 connection for some minutes, and will drop it if 
the request it has to process is not for tomcat.
This should be simple to add to jk 1.2.0

On jk 2.0.0, another solution, could be to add to 
workers.properties a maxconnection  :

worker.myhost-ajp13.maxconnection=25

In that case, we should have in jk2 a shared pool of connections
between threads (for IIS/AP2.0/IPLANET - easy) and between childs 
(AP 1.3 - how to do this ?) and get the connection from here.

What do you think ?


 


 

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

Re: New warp connector 4.0.4 does not work

[jean-frederic clere]

[EMAIL PROTECTED] wrote:
>>>"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>>
>>>Hello all,
>>>
>>>We have Apache 2.0.39 and tomcat 4.0.4 running using the old 4.0.2-01 warp
>>>connector.
>>>
>>>I have tried to build and use the new connector without success. Although it
>>>builds fine and Apache seems not to complain about it, I cannot access any
>>>pages and keep getting 302 temporarily moved error. The log files do not
>>>provide any useful information either.
>>>
>>>Is this a bug or am I missing something?
>>>
>>>Also, does anyone know if there is any decent documentation on this?
>>
>>I haven't yet tried on this environment... What MPM are you using? What OS?
>>Did you recompile it from the sources?
>>
>>   Pier
>>
>>
>>--
>>To unsubscribe, e-mail:   
>>For additional commands, e-mail: 
> 
> 
> 
> Pier,
> 
> The environment is Linux (Redhat 7.2) kernel 2.4.9-34
> 
> I used the following steps:
> 
> 1. compiled and installed apache-2.0.39 from source.

What options did you use to configure it?

> 2. compiled and installed autconf 2.53 from source (required for new connector)
> 3. compiled and installed from source from:
> 
>http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.4/src/jakarta-tomcat-connectors-4.0.4-src.tar.gz
> 
> An older version jakarta-tomcat-connectors-4.0.2-01-src.tar.gz works fine.
> 
> Any ideas?
> 
> 
> 
> -- --
> Visit our Internet site at http://www.reuters.com
> 
> Any views expressed in this message are those of  the  individual
> sender,  except  where  the sender specifically states them to be
> the views of Reuters Ltd.
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 




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

RE: Proposal draft for Tomcat 5.0

[GOMEZ Henri]

A big +1 for that draft.

Things I'd like to see in TC 5.0.

Delegation: 

don't decode full HTTP headers until
user code ask for (ie locales(), ssl certs)

It will make TC 5.0 faster (less request processing
time, less objets creation/recycling).

Extended JMX support:

TC 5.0 should be manageable via JMX console tools.

Better integration with WebServers:

extended use of JK2 to void duplicate works in web-servers
and TC 5.0, for example it's a waste of time to decode some
http-headers one time in Apache 2.0 and another time in TC. 

All in one, this 5.0 proposal is a good news.

-
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: Friday, June 21, 2002 12:41 PM
>To: Tomcat Developers List
>Subject: Proposal draft for Tomcat 5.0
>
>
>Hi,
>
>I'm committing a draft for a Tomcat 5 proposal.
>
>It is a draft, so it is not in final form yet (it needs 
>feedback for that).
>
>I'm attaching the document to the mail, in case people don't want to 
>checkout the repository.
>
>Remy
>

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

Re: New warp connector 4.0.4 does not work

[Asar . Khan]

Options used to configure Apache were:

./configure --enable-layout=Asar --enable-so --enable-mods-shared=most


prefix:/opt/apache-2.0.39
exec_prefix:   ${prefix}
bindir:${exec_prefix}/bin
sbindir:   ${exec_prefix}/bin
libdir:${exec_prefix}/lib
libexecdir:${exec_prefix}/modules
mandir:${prefix}/man
sysconfdir:${prefix}/conf
errordir:  ${prefix}/error
datadir:   ${prefix}/home/httpd
iconsdir:  ${datadir}/icons
htdocsdir: ${datadir}/htdocs
manualdir: ${datadir}/manual
cgidir:${datadir}/cgi-bin
installbuilddir: ${prefix}/build
includedir:${prefix}/include
localstatedir: ${prefix}/logs
runtimedir:${localstatedir}/run
logfiledir:${localstatedir}
proxycachedir: ${localstatedir}/proxy





   

jean-frederic clere

  
emens.com>cc:  

   Subject: Re: New warp 
connector 4.0.4 does not work 
21/06/2002 11:56   Header:  Internal Use Only  

Please respond to Tomcat   

Developers List

   

   




[EMAIL PROTECTED] wrote:
>>>"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>>
>>>Hello all,
>>>
>>>We have Apache 2.0.39 and tomcat 4.0.4 running using the old 4.0.2-01 warp
>>>connector.
>>>
>>>I have tried to build and use the new connector without success. Although it
>>>builds fine and Apache seems not to complain about it, I cannot access any
>>>pages and keep getting 302 temporarily moved error. The log files do not
>>>provide any useful information either.
>>>
>>>Is this a bug or am I missing something?
>>>
>>>Also, does anyone know if there is any decent documentation on this?
>>
>>I haven't yet tried on this environment... What MPM are you using? What OS?
>>Did you recompile it from the sources?
>>
>>   Pier
>>
>>
>>--
>>To unsubscribe, e-mail:   
>>For additional commands, e-mail: 
>
>
>
> Pier,
>
> The environment is Linux (Redhat 7.2) kernel 2.4.9-34
>
> I used the following steps:
>
> 1. compiled and installed apache-2.0.39 from source.

What options did you use to configure it?

> 2. compiled and installed autconf 2.53 from source (required for new connector)
> 3. compiled and installed from source from:
> 
>http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.4/src/jakarta-tomcat-connectors-4.0.4-src.tar.gz
>
> An older version jakarta-tomcat-connectors-4.0.2-01-src.tar.gz works fine.
>
> Any ideas?
>
>
>
> -- --
> Visit our Internet site at http://www.reuters.com
>
> Any views expressed in this message are those of  the  individual
> sender,  except  where  the sender specifically states them to be
> the views of Reuters Ltd.
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>




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







-- --
Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

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

[PATCH] mod_jk 1.2.0 workers pool

[Mladen Turk]

Think this solves a lot of problems (at least to my tests).
Don't forget to add the worker.ajp13.poolsize=nn in the
workers.properties (this is the actual number of workers  (connections)
to the TC), the default is 1.

This value should be close to the number of predicted client
connections, or to the desired no of TC threads. (didn't done some
serious profiling).

How it works:

At startup we create the nn workers, and the actual clients gets
serialized through those workers (nothing fancy, just a safe
multithreading I hope).

Need in the jk_worker.c solution for:

+#ifdef WIN32
+Sleep(10);
+#else
+
+#endif

This is the loop that waits for a worker to finish serving request if
non free has been found.

That's it.

MT.



mod_jk.c.patch
Description: Binary data


jk_ajp_common.c.patch
Description: Binary data


jk_service.h.patch
Description: Binary data


jk_util.c.patch
Description: Binary data


jk_util.h.patch
Description: Binary data


jk_worker.c.patch
Description: Binary data

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

Re: Proposal draft for Tomcat 5.0

[Remy Maucherat]

GOMEZ Henri wrote:
> A big +1 for that draft.
> 
> Things I'd like to see in TC 5.0.
> 
> Delegation: 
> 
> don't decode full HTTP headers until
> user code ask for (ie locales(), ssl certs)

That's done already for the most common things (like locales).
A lot of that should already be in TC 4.1.

> It will make TC 5.0 faster (less request processing
> time, less objets creation/recycling).

Indeed. I want to optimize the mapping now.

> Extended JMX support:
> 
> TC 5.0 should be manageable via JMX console tools.

I'd like to add JMX to control the component assembler we'll have (which 
may be the launcher). Same in Coyote. Catalina already populates a 
domain with beans to represent all its components, so that should be ok.

Remy


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

RE: Close to solution ( WAS RE: mod_jk testing)

[Jan Singer]

Your solution to Glenn's concern for jk 1.2.0 is just a change to my patch for 
timeouts of connections. I didn't implement a timer, so the connections aren't closed 
if they are not used. The timeout-evaluation is done in jk_get_endpoint.

I'll try to add this, but since I'm new to this maybe someone should beat me ;-)

d:-> Jan

-Ursprüngliche Nachricht-
Von: GOMEZ Henri [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 21. Juni 2002 12:49
An: Tomcat Developers List
Cc: Mladen Turk; Glenn Nielsen; Jan Singer
Betreff: RE: Close to solution ( WAS RE: mod_jk testing)


>Think we can close that!

Ouf.

>I've created the worker pool modifiable through workers.properties with 
>the worker.ajp13.poolsize.

Good

>The sadest thing is that I was so close the solution on day 0 (remember 
>the  mutexes?). Well what ever!

ok

>There is some minor bug when using loglevel=debug, and it works 
>currently only for ajp13 (well, ajp common).

Minor bug with loglevel=debug, tell su more ...

>Also I'll need the Sleep() for unix.

Hum, I really dislike to use Sleep/sleep in mod_jk. Delaying something is not an issue.

>Since I newer commited the code ever, and the changes are in (4 or 5 
>files I think), I'll mail it to Henri or someone else to do the dirty 
>work ;).

Send the patches to the list

>Now the crucial (see at the bottom the TC and date.jsp results
>statet at
>different times):
>
>Test results:
>
>worker.ajp13.poolsize=1
>worker.ajp13.cachesize=1
>
>Server Software:Apache/2.0.40-dev
>Server Hostname:localhost
>Server Port:8000
>
>Document Path:  /examples/jsp/snp/snoop.jsp
>Document Length:712 bytes
>
>Concurrency Level:  200
>Time taken for tests:   103.5572 seconds
>Complete requests:  1
>Failed requests:0
>
>
>Test results:
>
>worker.ajp13.cachesize=25
>worker.ajp13.poolsize=25
>
>
>
>Server Software:Apache/2.0.40-dev
>Server Hostname:localhost
>Server Port:8000
>
>Document Path:  /examples/jsp/snp/snoop.jsp
>Document Length:712 bytes
>
>Concurrency Level:  100
>Time taken for tests:   41.586847 seconds
>Complete requests:  1
>Failed requests:0
>
>Test with 200:
>
>Concurrency Level:  200
>Time taken for tests:   38.962629 seconds
>Complete requests:  1
>Failed requests:0
>
>
>Document Path:  /examples/jsp/dates/date.jsp
>Document Length:453 bytes
>
>Concurrency Level:  200
>Time taken for tests:   47.274576 seconds
>Complete requests:  1
>Failed requests:2180
>   (Connect: 0, Length: 2180, Exceptions: 0)
>
>
>TC Test started on 12:09:11 secs (all the XX seconds)
>
>Server Software:Apache
>Server Hostname:localhost
>Server Port:8080
>
>Document Path:  /examples/jsp/dates/date.jsp
>Document Length:452 bytes
>
>Concurrency Level:  200
>Time taken for tests:   44.850752 seconds
>Complete requests:  1
>Failed requests:0
>
>Server Software:Apache
>Server Hostname:localhost
>Server Port:8080
>
>TC Test started on 12:11:01 secs (first we have X, then XX seconds)
>
>Document Path:  /examples/jsp/dates/date.jsp
>Document Length:452 bytes
>
>Concurrency Level:  200
>Time taken for tests:   40.644117 seconds
>Complete requests:  1
>Failed requests:7966
>   (Connect: 0, Length: 7966, Exceptions: 0)

I re-tested mod_jk 1.2.0 against TC 3.3.1 / TC 4.0.4 under Apache 1.3 and 2.0 with 
helloworld servlet, and didn't find anymore errors (ab requested 10 Millions pages 
with 127 concurrents)

The problem was problably due to the way ab works, and many thanks to have discovered 
it :)

We should revue your patches and also the keep-alive add-on 
proposal sent by Jan Singer (firewall/keepalive)

I also listen to Glenn concern about childs/ajp13 and also he's rigth here. Imagine 
the following situation.

An Apache server is used to handle statics pages and route requests to 
tomcat(s).

Under load Apache will create many childs/threads. 

At some times, requests will be for tomcat, so the child/thread 
which got the request will create the ajp13 connection.

You could end-up with an Apache where all childs/threads will 
open an ajp13 connection, even if they do not send any more requests to tomcats.

A solution could be to close open connection after some moments of inactivity, ie a 
stressed child will see if it didn't used 
it's ajp13 connection for some minutes, and will drop it if 
the request it has to process is not for tomcat.
This should be simple to add to jk 1.2.0

On jk 2.0.0, another solution, could be to add to 
workers.properties a maxconnection  :

worker.myhost-ajp13.maxconnection=25

In that case, we should have in jk2 a shared pool of connections between threads (for 
IIS/AP2.0/IPLANET - easy) and between childs 
(AP 1.3 - how to do this ?) and get the connection from here.

What do you think ?

RE: [PATCH] mod_jk 1.2.0 workers pool

[GOMEZ Henri]

I started take a look at patches, 
but I didn't like the Sleep(10).

Why did you put a Sleep only in Windows case ?

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



>-Original Message-
>From: Mladen Turk [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 21, 2002 1:24 PM
>To: [EMAIL PROTECTED]
>Subject: [PATCH] mod_jk 1.2.0 workers pool
>
>
>
>Think this solves a lot of problems (at least to my tests).
>Don't forget to add the worker.ajp13.poolsize=nn in the
>workers.properties (this is the actual number of workers  (connections)
>to the TC), the default is 1.
>
>This value should be close to the number of predicted client
>connections, or to the desired no of TC threads. (didn't done some
>serious profiling).
>
>How it works:
>
>At startup we create the nn workers, and the actual clients gets
>serialized through those workers (nothing fancy, just a safe
>multithreading I hope).
>
>Need in the jk_worker.c solution for:
>
>+#ifdef WIN32
>+Sleep(10);
>+#else
>+
>+#endif
>
>This is the loop that waits for a worker to finish serving request if
>non free has been found.
>
>That's it.
>
>MT.
>

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

RE: [PATCH] mod_jk 1.2.0 workers pool

[Mladen Turk]

> 
> I started take a look at patches, 
> but I didn't like the Sleep(10).
> 
> Why did you put a Sleep only in Windows case ?
> 

Cause I don't know what is the actual function call on unix :)



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

RE: [PATCH] mod_jk 1.2.0 workers pool

[GOMEZ Henri]

sleep(#seconds)

or 

usleep(#microseconds)

No the real problem is with using a sleep in
network code, I didn't like it. 

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



>-Original Message-
>From: Mladen Turk [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 21, 2002 1:38 PM
>To: 'Tomcat Developers List'
>Subject: RE: [PATCH] mod_jk 1.2.0 workers pool
>
>
>> 
>> I started take a look at patches, 
>> but I didn't like the Sleep(10).
>> 
>> Why did you put a Sleep only in Windows case ?
>> 
>
>Cause I don't know what is the actual function call on unix :)
>
>
>
>--
>To unsubscribe, e-mail:   
>
>For additional commands, e-mail: 
>
>
>

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

RE: [PATCH] mod_jk 1.2.0 workers pool

[Mladen Turk]

> -Original Message-
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] 
> Sent: 21. lipanj 2002 13:44
> To: Tomcat Developers List
> Subject: RE: [PATCH] mod_jk 1.2.0 workers pool
> 
> 
> sleep(#seconds)
> 
> or 
> 
> usleep(#microseconds)
>

The it should be usleep (1);
 
> No the real problem is with using a sleep in
> network code, I didn't like it. 
> 

Well I have a loop that waits that one of the ajp workers sets its
is_busy flag to 0. Without the sleep you have a thread lock. If the code
would run only on WIN32, then I would use the WaitForMultipleObjects,
but since I don't know the unix pthreads that thorowly, the sleep is the
simplest solution I've think of (signals perhaps).


MT.


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

Re: Proposal draft for Tomcat 5.0

[Nicola Ken Barozzi]

Remy Maucherat wrote:
> Hi,
> 
> I'm committing a draft for a Tomcat 5 proposal.
> 
> It is a draft, so it is not in final form yet (it needs feedback for that).
> 
> I'm attaching the document to the mail, in case people don't want to 
> checkout the repository.

What about using Avalon as a framework?
This way we would have a unified server environment, and reusable server 
components.

If the Tomcat connectors were Avalon-aware, we could reuse them for 
James, Cocoon (directly, so we don't need to make Cocoon a servlet, 
which it's not), etc.

I'm a committer in POI, Forrest, Avalon and Cocoon, so as you imagine 
I'm a bit biased ;-) , but I also use Tomcat heavily, and I think that 
cooperation in this area would be nice and bring additional value to the 
users and to the projects themselves.

Tomcat4 is excellent in it's framework, and in many aspects is more 
Avalon than Avalon itself, as both came from the Jserv effort.

Now that Turbine is working on using Avalon (also FOP, POI, and others), 
  IMHO it would be excellent to also have the talented Tomcat developers 
work together with us.

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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

Re: Proposal draft for Tomcat 5.0

[Remy Maucherat]

Nicola Ken Barozzi wrote:
> 
> Remy Maucherat wrote:
> 
>> Hi,
>>
>> I'm committing a draft for a Tomcat 5 proposal.
>>
>> It is a draft, so it is not in final form yet (it needs feedback for 
>> that).
>>
>> I'm attaching the document to the mail, in case people don't want to 
>> checkout the repository.
> 
> 
> What about using Avalon as a framework?
> This way we would have a unified server environment, and reusable server 
> components.

-1.
(I'm tired of replying to this)

Avalon is the contrary of flexibility, so it will not be considered (at 
least not by me).

> If the Tomcat connectors were Avalon-aware, we could reuse them for 
> James, Cocoon (directly, so we don't need to make Cocoon a servlet, 
> which it's not), etc.
> 
> I'm a committer in POI, Forrest, Avalon and Cocoon, so as you imagine 
> I'm a bit biased ;-) , but I also use Tomcat heavily, and I think that 
> cooperation in this area would be nice and bring additional value to the 
> users and to the projects themselves.
> 
> Tomcat4 is excellent in it's framework, and in many aspects is more 
> Avalon than Avalon itself, as both came from the Jserv effort.
> 
> Now that Turbine is working on using Avalon (also FOP, POI, and others), 
>  IMHO it would be excellent to also have the talented Tomcat developers 
> work together with us.

Remy


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

Re: Proposal draft for Tomcat 5.0

[Nicola Ken Barozzi]

Remy Maucherat wrote:
 > Nicola Ken Barozzi wrote:
 >
 >>
 >> Remy Maucherat wrote:
 >>
 >>> Hi,
 >>>
 >>> I'm committing a draft for a Tomcat 5 proposal.
 >>>
 >>> It is a draft, so it is not in final form yet (it needs feedback for
 >>> that).
 >>>
 >>> I'm attaching the document to the mail, in case people don't want to
 >>> checkout the repository.
 >>
 >> What about using Avalon as a framework?
 >> This way we would have a unified server environment, and reusable
 >> server components.
 >
 > -1.
 > (I'm tired of replying to this)

I'm sorry, wasn't aware that I would cause distress.
I searced in the archives of tomcat-dev with "Avalon" and couldn't find
recent answers on this topic.

 > Avalon is the contrary of flexibility, so it will not be considered (at
 > least not by me).

Avalon is a project, not the contrary of flexibility.

Tomcat is a project too, and AFAIK it wants to be usable in different
environments.

Taken that you are against using Avalon directly, I don't want to table
a discussion with you on it.
When you'll want to take another look at Avalon and give us suggestions,
you're welcome.

Anyway, for my personal information, what's the current status of this?
What's the plan for T5?


List: tomcat-dev
Subject:  Re: [PATCH] CatalinaBlock.java
From: "Sam Ruby" <[EMAIL PROTECTED]>
Date: 2001-02-12 11:29:53

Remy Maucherat wrote:
 >
 > For these reasons, I'd like to see an official Avalon wrapper
 > introduced in Tomcat 4.1, but not in Tomcat 4.0.  I also
 > propose to remove the current Avalon wrapper from the Tomcat
 > 4.0 repository, to avoid the maintenance related issues.

Thank you.

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
  - verba volant, scripta manent -
 (discussions get forgotten, just code remains)
-



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

DO NOT REPLY [Bug 10116] New: - welcome page resolutions do not take mapped servlets or jsp pages into account

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

welcome page resolutions do not take mapped servlets or jsp pages into account

   Summary: welcome page resolutions do not take mapped servlets or
jsp pages into account
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am trying to do the following thing:

I created a jsp page called index.jsp an put it into the root path of a webapp.
This page shall be a welcome page. Therefore I could specify index.jsp as a 
welcome page within the web descriptor, which works fine. Now I would like to 
hide the .jsp suffix from the users. Therefore I created a servlet mapping that 
maps the index.jsp page to the url pattern /index.html and specified index.html 
to be a welcome page.
This doesn't seem to work. If I manually type into my 
browser "/index.html" then my jsp page is invoked, which is fine, but 
if I just type "" then I get a directory listing.
I believe that this behaviour is not correct.

For better understanding I will post an extract of the web descriptor as well:


root-page
/index.jsp



root-page
/index.html



index.html



Since index.html is specified as the welcome page, if I access the root 
directory / then, to my intuition, catalina should make a redirect or a forward 
to /index.html. It should then realize that a jsp page called /index.jsp is 
mapped to this URL and invoke it.

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

DO NOT REPLY [Bug 10116] - welcome page resolutions do not take mapped servlets or jsp pages into account

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

welcome page resolutions do not take mapped servlets or jsp pages into account

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 13:37 ---
I don't know how to implement this in a satisfactory way.

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

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

DO NOT REPLY [Bug 9016] - welcome-files don't map to servlet without disk file

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

welcome-files don't map to servlet without disk file

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 13:37 ---
*** Bug 10116 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 9961] - JSTL core tag forEach does not work for List

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

JSTL core tag forEach does not work for List





--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 13:38 ---
Created an attachment (id=2147)
Testcase for the bug

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

DO NOT REPLY [Bug 10064] - Tomcat nt service does not use security manager

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

Tomcat nt service does not use security manager

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||LATER



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 13:44 ---
Hacking JavaService is not really supported (and is third party code). This
should be better supported when we use the commons-daemon launcher code.

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

DO NOT REPLY [Bug 10057] - banner.jsp form should not link to absolute path

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10057

banner.jsp form should not link to absolute path

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement
   Priority|Other   |High



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 13:47 ---
You should submit a patch which fixes it. Otherwise, it doesn't look very high
priority for the Tomcat developers.

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

DO NOT REPLY [Bug 10049] - Wrong presentation of German Umlaute (ä, ö, ü)

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

Wrong presentation of German Umlaute (ä, ö, ü)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME
Summary|wrong presentation of German|Wrong presentation of German
   |Umlaute (ä, ö, ü)   |Umlaute (ä, ö, ü)



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 13:50 ---
This is difficult to reproduce. Maybe there could be a problem with the b2c or
c2b conversion done when storing / retrieving the data in the database ?
IMO, you should investigate this further (more "basic" i18n scenarios work
fine). Reopen the bug if you have more details indicating a problem with Tomcat.

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

DO NOT REPLY [Bug 10021] - Installer overwrites webapps/root files

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

Installer overwrites webapps/root files





--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 13:52 ---
Maybe it could be fixed, but updating an existing installation using the
installer isn't a very good idea. The recommended way is uninstall / install.

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

DO NOT REPLY [Bug 9997] - Servlet.service() for servlet default threw exception java.net.SocketException: Operation would block

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

Servlet.service() for servlet default threw exception java.net.SocketException: 
Operation would block

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Catalina|Connector:JK/AJP
   ||(deprecated)

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

DO NOT REPLY [Bug 10120] New: - Custom realm and shared instalation.

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

Custom realm and shared instalation.

   Summary: Custom realm and shared instalation.
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have created a custom realm, and I install it in tomcat by copying a jar file
inside $CATALINA_HOME/server/lib. 
But I have some issues about this: 

I can not have two application with similar realm classes but not exactly the same.
I can not have a shared installation of tomcat for multiple users. Each one of
them may require a different custom realm, and the only way to do this is by
giving them write access to the $CATALINA_HOME/server/lib directory, or at least
some files inside of it.

Now I understand the realm is not part of the servlet specification or the jsp
specification, and should not be part of the web application. 

What I propose is simple: in the realm tag in server.xml, add an extra parameter
which will tell tomcat in which directory or jar file to get the realm. for example:

 

That way, each user could configure his own realm in his own catalina
configuration directories.

Another option would be to search the classes that are available to the context
the realm is defined in. 

For example if my web application has the realm classes inside
SOMEDIR/WEB-INF/classes/MyCustomRealmClass.class
and I put this inside server.xml:


  
...
/>

it will find the class and use it.

Note this would not break any specification, it would be just tomcat's way of
configuring the realm. Other application servers are not currently following
current tomcat's way anyway.

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

DO NOT REPLY [Bug 8438] - Unable to start Apache service when using mod_jk

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8438

Unable to start Apache service when using mod_jk

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 14:32 ---
There is too few information to be usefull.
I close the bug for now

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

Re: New warp connector 4.0.4 does not work

[Pier Fumagalli]

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

>>> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>> 
>>> Hello all,
>>> 
>>> We have Apache 2.0.39 and tomcat 4.0.4 running using the old 4.0.2-01 warp
>>> connector.
>>> 
>>> I have tried to build and use the new connector without success. Although it
>>> builds fine and Apache seems not to complain about it, I cannot access any
>>> pages and keep getting 302 temporarily moved error. The log files do not
>>> provide any useful information either.
>>> 
>>> Is this a bug or am I missing something?
>>> 
>>> Also, does anyone know if there is any decent documentation on this?
>> 
>> I haven't yet tried on this environment... What MPM are you using? What OS?
>> Did you recompile it from the sources?
>> 
>>Pier
>> 
>> 
>> --
>> To unsubscribe, e-mail:   
>> For additional commands, e-mail: 
> 
> 
> Pier,
> 
> The environment is Linux (Redhat 7.2) kernel 2.4.9-34
> 
> I used the following steps:
> 
> 1. compiled and installed apache-2.0.39 from source.
> 2. compiled and installed autconf 2.53 from source (required for new
> connector)
> 3. compiled and installed from source from:
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.4/src/jakarta
> -tomcat-connectors-4.0.4-src.tar.gz
> 
> An older version jakarta-tomcat-connectors-4.0.2-01-src.tar.gz works fine.
> 
> Any ideas?

Nope. That doesn't tell me ANYTHING on how your HTTP stack is configured...
I suppose you're using the PREFORK mpm, as that's the default. But please
confirm that...

Pier


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

Re: Proposal draft for Tomcat 5.0

[Pier Fumagalli]

"Remy Maucherat" <[EMAIL PROTECTED]> wrote:

> Extensibility capabilities will be added to Coyote, as well as JMX management
> features, and if possible, addional protocol handlers (like WARP 1.0).

As far as I would like to see WARP and its future development, it'll
probably end up following a different container architecture. The
extenization of the HTTP stack from the core of the container brings some
advantages to the engine, but as well this need to introduce a different
layering scheme for the components, such as the removal of .

Plus, for security reasons, I want WebApp to follow the trend of being
slimmer, therefore not inheriting the whole "Tomcat" weight, but letting it
do only _the_ container, with no kits or caboodle attached to it... Apache
is my platform, there is where I will want and add complexity. Tomcat, just
a servlet container (IMO)...

This is where I want to end up to. Frankly at this point in time I don't
think that carrying on with the development of components such as the HTTP
connector, or other tomcat "features" (GZIP on-the-fly compression, CGI
support, JMX support), matters to me...

I want, and I'm getting there, only a servlet container able to handle some
10/15 millions servlet-based requests/day. Therefore also approaches such as
JNI are definitely out for high availability approach...

Given the latest developments, I seriously don't think I want to be carrying
on with TC5.0 anymore, I'll just (as always) do what matters to me, and if
it works for me, I'm set...

Pier


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

Re: New warp connector 4.0.4 does not work

[Pier Fumagalli]

This is prefork... AFAICS from the sources, we never send back a 302... I'll
have to doublecheck though...

Pier



"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> 
> Options used to configure Apache were:
> 
> ./configure --enable-layout=Asar --enable-so --enable-mods-shared=most
> 
> 
>   prefix:/opt/apache-2.0.39
>   exec_prefix:   ${prefix}
>   bindir:${exec_prefix}/bin
>   sbindir:   ${exec_prefix}/bin
>   libdir:${exec_prefix}/lib
>   libexecdir:${exec_prefix}/modules
>   mandir:${prefix}/man
>   sysconfdir:${prefix}/conf
>   errordir:  ${prefix}/error
>   datadir:   ${prefix}/home/httpd
>   iconsdir:  ${datadir}/icons
>   htdocsdir: ${datadir}/htdocs
>   manualdir: ${datadir}/manual
>   cgidir:${datadir}/cgi-bin
>   installbuilddir: ${prefix}/build
>   includedir:${prefix}/include
>   localstatedir: ${prefix}/logs
>   runtimedir:${localstatedir}/run
>   logfiledir:${localstatedir}
>   proxycachedir: ${localstatedir}/proxy
> 
> 
> 
> 
> 
>  
>   jean-frederic clere
>List <[EMAIL PROTECTED]>
>   emens.com>cc:
>  Subject: Re: New warp
> connector 4.0.4 does not work
>   21/06/2002 11:56   Header:  Internal Use
> Only 
>   Please respond to Tomcat
>   Developers List
>  
>  
> 
> 
> 
> [EMAIL PROTECTED] wrote:
 "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>>> 
 Hello all,
 
 We have Apache 2.0.39 and tomcat 4.0.4 running using the old 4.0.2-01 warp
 connector.
 
 I have tried to build and use the new connector without success. Although
 it
 builds fine and Apache seems not to complain about it, I cannot access any
 pages and keep getting 302 temporarily moved error. The log files do not
 provide any useful information either.
 
 Is this a bug or am I missing something?
 
 Also, does anyone know if there is any decent documentation on this?
>>> 
>>> I haven't yet tried on this environment... What MPM are you using? What OS?
>>> Did you recompile it from the sources?
>>> 
>>>   Pier
>>> 
>>> 
>>> --
>>> To unsubscribe, e-mail:   
>>> For additional commands, e-mail: 
>> 
>> 
>> 
>> Pier,
>> 
>> The environment is Linux (Redhat 7.2) kernel 2.4.9-34
>> 
>> I used the following steps:
>> 
>> 1. compiled and installed apache-2.0.39 from source.
> 
> What options did you use to configure it?
> 
>> 2. compiled and installed autconf 2.53 from source (required for new
>> connector)
>> 3. compiled and installed from source from:
>> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.4/src/jakart
>> a-tomcat-connectors-4.0.4-src.tar.gz
>> 
>> An older version jakarta-tomcat-connectors-4.0.2-01-src.tar.gz works fine.
>> 
>> Any ideas?


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

DO NOT REPLY [Bug 10123] New: - getRemoteHost() returns IP address

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

getRemoteHost() returns IP address

   Summary: getRemoteHost() returns IP address
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In my server.xml file I had the following:



getRemoteHost() would return the IP address.

If I reverted to the old connector using:



getRemoteHost() would return the correct host name.

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

DO NOT REPLY [Bug 10057] - banner.jsp form should not link to absolute path

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10057

banner.jsp form should not link to absolute path





--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 14:54 ---
Created an attachment (id=2149)
banner.jsp file that remove "/admin"

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

Re: Proposal draft for Tomcat 5.0

[Pier Fumagalli]

"Remy Maucherat" <[EMAIL PROTECTED]> wrote:

> Nicola Ken Barozzi wrote:
>> 
>> Remy Maucherat wrote:
>> 
>>> Hi,
>>> 
>>> I'm committing a draft for a Tomcat 5 proposal.
>>> 
>>> It is a draft, so it is not in final form yet (it needs feedback for
>>> that).
>>> 
>>> I'm attaching the document to the mail, in case people don't want to
>>> checkout the repository.
>> 
>> 
>> What about using Avalon as a framework?
>> This way we would have a unified server environment, and reusable server
>> components.
> 
> -1.
> (I'm tired of replying to this)
> 
> Avalon is the contrary of flexibility, so it will not be considered (at
> least not by me).

That's a JOKE right?


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

DO NOT REPLY [Bug 4915] - Relocation error while loading mod_jk when starting apache.

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

Relocation error while loading mod_jk when starting apache.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 15:05 ---
No more comments on that bug, may be the user upgraded to 
higher solaris version ?

I'll add compile flags, NO_SNPRINTF and NO_VSNPRINTF to 
use the netware patch in jk 1.2.0 release

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

Re: Proposal draft for Tomcat 5.0

[Remy Maucherat]

Pier Fumagalli wrote:
> "Remy Maucherat" <[EMAIL PROTECTED]> wrote:
> 
> 
>>Nicola Ken Barozzi wrote:
>>
>>>Remy Maucherat wrote:
>>>
>>>
Hi,

I'm committing a draft for a Tomcat 5 proposal.

It is a draft, so it is not in final form yet (it needs feedback for
that).

I'm attaching the document to the mail, in case people don't want to
checkout the repository.
>>>
>>>
>>>What about using Avalon as a framework?
>>>This way we would have a unified server environment, and reusable server
>>>components.
>>
>>-1.
>>(I'm tired of replying to this)
>>
>>Avalon is the contrary of flexibility, so it will not be considered (at
>>least not by me).
> 
> 
> That's a JOKE right?

Ok, so maybe my statement was too strong ;-)

For all the things it gives you, Avalon is a framework, and makes you 
feel like it. It imposes contracts between components / patterns, 
packaging, etc. All things which aren't compatible with 5.0. And more 
importantly, the API changes often, to the extent that all the projects 
which use Avalon work off a specific snapshot, and don't upgrade too often.

Also, most of the utility provided by Avalon are available from the 
commons without any string attached, and/or are of a better quality.

There has been plenty of discussion on that with Paul, and during the 
whole commons-logging incident, at which point I thought it would be 
best if I didn't have anything to do with Avalon.

OTOH, we could have optional Avalon wrappers again, as long as there is 
someone to write them *and* maintain them when the API changes. So +0.1 
to work nice with Avalon, but -1 for basing the architecture on Avalon.

Remy


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

DO NOT REPLY [Bug 10126] New: - NullPointerException when no uri defined in taglib directive

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

NullPointerException when no uri defined in taglib directive

   Summary: NullPointerException when no uri defined in taglib
directive
   Product: Tomcat 4
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The following taglib directive causes an NPE in Jasper2 parser:

<%@ taglib prefix="f">

Here's the exception:

java.lang.NullPointerException


at java.util.Hashtable.get(Hashtable.java:326)


at
org.apache.jasper.compiler.TldLocationsCache.getLocation(TldLocationsCache.java:319)


at
org.apache.jasper.JspCompilationContext.getTldLocation(JspCompilationContext.java:441)


at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:353)


at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:381)


at org.apache.jasper.compiler.Parser.parseElements(Parser.java:790)


at org.apache.jasper.compiler.Parser.parse(Parser.java:122)


at org.apache.jasper.compiler.ParserController.parse(ParserController.java:199)


at org.apache.jasper.compiler.ParserController.parse(ParserController.java:153)


at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:228)


at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)


at 
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:478)


at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184)


at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289)


at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)


at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)

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

DO NOT REPLY [Bug 10127] New: - tomcat 4.0.4 locks jsp files

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

tomcat 4.0.4 locks jsp files

   Summary: tomcat 4.0.4 locks jsp files
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


sun jdk1.4.0_01
tomcat 4.0.4 final
winnt4 sp6a
IE5,6 & Mozilla 0.9.9

using tomcat embedded in our app, we find that tomcat will lock the jsp under 
certain circumstances so the original cannot be edited and saved until tomcat 
is shut down. If we open the jsp source in dreamweaver (or any editor), and 
then view the page via our servlet, we can change the jsp source, hit refresh 
in the browser, and see the changes immediately. However, if we hit refresh 
twice in a row (without making any changes to the jsp source) the jsp becomes 
locked by tomcat, and we can no longer make any changes without either closing 
tomcat down, or deleting the .java and .class files from tomcats work 
directory, as a sharing violation occurs. (this also stops us deleting or 
renaming the jsp)
Using HandleEx (from sysinternals.com), we can see that every time refresh is 
pressed in the browser without changes being made to the jsp, a new handle to 
the file is created and kept open.
I've entered a severity of Major, because our users (mainly web designers) need 
to be able to make changes to a jsp and view the changes immediately, and this 
problem is causing them major delays because they have to keep shutting down 
the jvm, and restarting.

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

Re: Proposal draft for Tomcat 5.0

[Remy Maucherat]

Pier Fumagalli wrote:
> "Remy Maucherat" <[EMAIL PROTECTED]> wrote:
> 
> 
>>Extensibility capabilities will be added to Coyote, as well as JMX management
>>features, and if possible, addional protocol handlers (like WARP 1.0).
> 
> 
> As far as I would like to see WARP and its future development, it'll
> probably end up following a different container architecture. The
> extenization of the HTTP stack from the core of the container brings some
> advantages to the engine, but as well this need to introduce a different
> layering scheme for the components, such as the removal of .

I'm not sure I quite understand why you say that.

In that deployment scenario, you use:
- Coyote HTTP/1.1
- Catalina 2.0
and this is not fundamentally different that the current Tomcat 4.1. The 
main difference is that the loader will probably be different, but 
you'll still be able to use the old one if you need to.

Actually, if you package the current o.a.c.connector classes with the 
webapp classes, you should be able (maybe after adding one or two new 
methods for the new Servlet API, but it shouldn't be too hard) to run 
Webapp 1.0 on TC 5.

> Plus, for security reasons, I want WebApp to follow the trend of being
> slimmer, therefore not inheriting the whole "Tomcat" weight, but letting it
> do only _the_ container, with no kits or caboodle attached to it... Apache
> is my platform, there is where I will want and add complexity. Tomcat, just
> a servlet container (IMO)...

Rewriting WARP for Coyote wouldn't be that difficult, IMO. It just 
changes the way you communicate with your lower layer, and that's about 
it. I believe Costin wants to improve the "action" stuff used currently 
to be more flexible and powerful.

In return, you get a GC friendly behavior of the connector, higher 
performance, and it should also be easier to adapt to future version of 
Tomcat and / or may be used by other containers.

> This is where I want to end up to. Frankly at this point in time I don't
> think that carrying on with the development of components such as the HTTP
> connector, or other tomcat "features" (GZIP on-the-fly compression, CGI
> support, JMX support), matters to me...

I can understand. Usually, you lose interest in a project as soon as it 
does whatever you want it to do :)
There are some exceptions, but I really can understand that.

> I want, and I'm getting there, only a servlet container able to handle some
> 10/15 millions servlet-based requests/day. Therefore also approaches such as
> JNI are definitely out for high availability approach...

Load balancing with node failure tolerance (like the one provided by JK) 
could help there.
Did you look at JK 2 at all ?

> Given the latest developments, I seriously don't think I want to be carrying
> on with TC5.0 anymore, I'll just (as always) do what matters to me, and if
> it works for me, I'm set...

I'd like to keep you involved if I can.

Remy


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

Re: Proposal draft for Tomcat 5.0

[Christopher K. St. John]

Remy Maucherat wrote:
> 
> I'm committing a draft for a Tomcat 5 proposal.
> It is a draft, so it is not in final form yet (it needs feedback for that).
> 

 Re-architecting Tomcat yet again is a bad step if it's not
absolutely necessary. I have some reservations. To keep from
confusing the issue, I'll list them in separate messages.

  "In criticism I will be bold, and as sternly,
   absolutely just with friend and foe. From
   this purpose nothing shall turn me." - Edgar
   Allen Poe


> while at the same time adding support for the new Servlet
> API 2.4 and JSP 2.0 specifications
>

 Reservation #1: There is a new architecture being proposed,
but since the 2.4 API isn't out yet, all the requirements aren't
available. So there's no intelligent way to judge if the
architecture fits well with the primary requirement (which is
being a good 2.4 container)

 Tomcat 5 isn't some sort of generic server framework, it's
the reference implementation for the 2.4 spec. The spec is
central.



-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

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

RE: mod_jk testing (WAS RE: mod_jk 1.2.0 workers pool)

[Ignacio J. Ortega]

Ahhh, finally got to do the test on a capable machine, but very
overloaded with some db procecesses, dont take anything from the
absolute timing i know are very bad.., 

For all the other, my test seem ok..


Server Software:Microsoft-IIS/5.0
Server Hostname:ciberlogic
Server Port:80

Document Path:  /examples/jsp/snp/snoop.jsp
Document Length:713 bytes

Concurrency Level:  200
Time taken for tests:   39.937500 seconds
Complete requests:  1
Failed requests:0
Write errors:   0
Total transferred:  8909265 bytes
HTML transferred:   713 bytes
Requests per second:250.39 [#/sec] (mean)
Time per request:   798.750 [ms] (mean)
Time per request:   3.994 [ms] (mean, across all concurrent
requests)
Transfer rate:  217.84 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:01   5.8  0 281
Processing:78  791 4566.9250   39718
Waiting:   15  766 4568.4250   39718
Total: 78  792 4566.9250   39718

Percentage of the requests served within a certain time (ms)
  50%250
  66%265
  75%265
  80%281
  90%312
  95%453
  98%812
  99%  39656
 100%  39718 (longest request)

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: Mladen Turk [mailto:[EMAIL PROTECTED]]
> Enviado el: 21 de junio de 2002 8:19
> Para: 'Tomcat Developers List'
> Cc: [EMAIL PROTECTED]; GOMEZ Henri
> Asunto: mod_jk testing (WAS RE: mod_jk 1.2.0 workers pool)
> Importancia: Alta
> 
> 
> First some things about testing:
> 
> DO NOT USE the date.jsp (it could return various html lengths, so from
> there are coming those Failed requests ).
> I've just browsed through the source code of ab and it uses the first
> page as its length ethalon, and date.jsp could retur various length if
> the tests are finishing on the single second interval so 
> there is 1 byte
> html length differnce.
> 
> Use the /examples/jsp/snp/snoop.jsp instead (think it allways returns
> the same content-length).
> 
> The ones that count are only the 'Non-2xx responses'
> 
> 
> > -Original Message-
> > From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] 
> > Sent: 20. lipanj 2002 22:37
> > To: 'Tomcat Developers List'
> > Subject: RE: mod_jk 1.2.0 workers pool
> > 
> > 
> > > -Mensaje original-
> > > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> > Enviado el: 20 
> > > de junio de 2002 20:29
> > 
> > I need time to prepare a machine that can handle this level 
> > of concurrency, Mladen used  -c 200, i need to switch to one 
> > of the servers, :(, Thanks to microsoft, W2k professional 
> > only can handle 10 simultaneus connections :..
> >
> It's a IIS thing I think.
>  
> > I think Mlanden uses XP, right? which version ? Home, 
> > Professional? do you know the exact number of concurrent 
> > connections the XP version you use can handle?
> > 
> 
> Its Professional. And if I'm running the snoop.jsp with -c 200:
> 
> 181857 [Thread-4] ERROR server.JkCoyoteHandler  - Error in action code
> java.net.SocketException: Software caused connection abort: 
> socket write
> error
> 
> And,
> 
> 181867 [Thread-4] ERROR common.ChannelSocket  - Error, closing
> connection
> java.net.SocketException: Software caused connection abort: 
> JVM_recv in
> socket input stream read
> 
> Running with -c 10 doesn't produce such a error.
> 
> 
> MT.
> 
> 

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

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp14_worker.h jk_global.h jk_util.c

[hgomez]

hgomez  2002/06/21 08:28:56

  Modified:jk/native/common jk_ajp14_worker.h jk_global.h jk_util.c
  Log:
  fix the vsnprintf and snprintf
  Just define USE_SPRINT and USE_VSPRINTF when you didn't have
  these on your OS (ie Solaris 2.5)
  
  Revision  ChangesPath
  1.7   +1 -6  jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.h
  
  Index: jk_ajp14_worker.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.h,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- jk_ajp14_worker.h 4 Dec 2001 19:48:41 -   1.6
  +++ jk_ajp14_worker.h 21 Jun 2002 15:28:56 -  1.7
  @@ -80,11 +80,6 @@
   
   #define JK_AJP14_WORKER_NAME ("ajp14")
   
  -#ifdef WIN32
  -/* define snprint to match windows version */
  -#define snprintf _snprintf
  -#endif
  -
   int JK_METHOD ajp14_worker_factory(jk_worker_t **w,
  const char *name,
  jk_logger_t *l);
  
  
  
  1.18  +10 -1 jakarta-tomcat-connectors/jk/native/common/jk_global.h
  
  Index: jk_global.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_global.h,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- jk_global.h   3 May 2002 05:39:58 -   1.17
  +++ jk_global.h   21 Jun 2002 15:28:56 -  1.18
  @@ -197,6 +197,15 @@
   #ifdef WIN32
   /* For WIN32, emulate gettimeofday() using _ftime() */
   #define gettimeofday(tv,tz) { struct _timeb tb; _ftime(&tb); (tv)->tv_sec = 
tb.time; (tv)->tv_usec = tb.millitm * 1000; }
  +/* define snprint to match windows version */
  +#define snprintf _snprintf
  +/* define vsnprint to match windows version */
  +#define vsnprintf _vsnprintf
  +#endif
  +
  +#ifdef NETWARE
  +#define USE_SPRINTF
  +#define USE_VSPRINTF
   #endif
   
   #ifdef __cplusplus
  
  
  
  1.15  +5 -11 jakarta-tomcat-connectors/jk/native/common/jk_util.c
  
  Index: jk_util.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- jk_util.c 15 May 2002 21:00:29 -  1.14
  +++ jk_util.c 21 Jun 2002 15:28:56 -  1.15
  @@ -237,16 +237,12 @@
   f++;
   }
   
  -#ifdef WIN32
  - set_time_str(buf, HUGE_BUFFER_SIZE);
  - used = strlen(buf);
  -if(line)
  -used += _snprintf(&buf[used], HUGE_BUFFER_SIZE, " [%s (%d)]: ", f, 
line);
  -#elif defined(NETWARE) /* until we get a snprintf function */
  +#ifdef USE_SPRINTF /* until we get a snprintf function */
  +#ifdef NETWARE
   buf = (char *) malloc(HUGE_BUFFER_SIZE);
   if (NULL == buf)
  return -1;
  -
  +#endif
set_time_str(buf, HUGE_BUFFER_SIZE);
used = strlen(buf);
   if(line)
  @@ -262,9 +258,7 @@
   }
   
   va_start(args, fmt);
  -#ifdef WIN32
  -rc = _vsnprintf(buf + used, HUGE_BUFFER_SIZE - used, fmt, args);
  -#elif defined(NETWARE) /* until we get a vsnprintf function */
  +#ifdef USE_VSPRINTF /* until we get a vsnprintf function */
   rc = vsprintf(buf + used, fmt, args);
   #else 
   rc = vsnprintf(buf + used, HUGE_BUFFER_SIZE - used, fmt, args);
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 Makefile.apxs.in

[hgomez]

hgomez  2002/06/21 08:22:48

  Modified:jk/native/apache-1.3 Makefile.apxs.in
  Log:
  Add the missing / to common dir
  
  Revision  ChangesPath
  1.3   +1 -1  jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.apxs.in
  
  Index: Makefile.apxs.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.apxs.in,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Makefile.apxs.in  14 Jun 2001 14:38:13 -  1.2
  +++ Makefile.apxs.in  21 Jun 2002 15:22:48 -  1.3
  @@ -6,7 +6,7 @@
   APXSLDFLAGS=@APXSLDFLAGS@
   APXSCFLAGS=@APXSCFLAGS@
   
  -JK=../common
  +JK=../common/
   JK_INCL=-DUSE_APACHE_MD5 -I ${JK}
   JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
   JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L ${JAVA_HOME}/lib/${ARCH}/native_threads
  
  
  

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

RE: mod_jk testing (WAS RE: mod_jk 1.2.0 workers pool)

[GOMEZ Henri]

Ok so mod_jk 1.2.0 seems to be stable also on IIS.

Good news.

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



>-Original Message-
>From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 21, 2002 5:27 PM
>To: 'Mladen Turk'; 'Tomcat Developers List'
>Cc: '[EMAIL PROTECTED]'; GOMEZ Henri
>Subject: RE: mod_jk testing (WAS RE: mod_jk 1.2.0 workers pool)
>
>
>Ahhh, finally got to do the test on a capable machine, but very
>overloaded with some db procecesses, dont take anything from the
>absolute timing i know are very bad.., 
>
>For all the other, my test seem ok..
>
>
>Server Software:Microsoft-IIS/5.0
>Server Hostname:ciberlogic
>Server Port:80
>
>Document Path:  /examples/jsp/snp/snoop.jsp
>Document Length:713 bytes
>
>Concurrency Level:  200
>Time taken for tests:   39.937500 seconds
>Complete requests:  1
>Failed requests:0
>Write errors:   0
>Total transferred:  8909265 bytes
>HTML transferred:   713 bytes
>Requests per second:250.39 [#/sec] (mean)
>Time per request:   798.750 [ms] (mean)
>Time per request:   3.994 [ms] (mean, across all concurrent
>requests)
>Transfer rate:  217.84 [Kbytes/sec] received
>
>Connection Times (ms)
>  min  mean[+/-sd] median   max
>Connect:01   5.8  0 281
>Processing:78  791 4566.9250   39718
>Waiting:   15  766 4568.4250   39718
>Total: 78  792 4566.9250   39718
>
>Percentage of the requests served within a certain time (ms)
>  50%250
>  66%265
>  75%265
>  80%281
>  90%312
>  95%453
>  98%812
>  99%  39656
> 100%  39718 (longest request)
>
>Saludos ,
>Ignacio J. Ortega
>
>
>> -Mensaje original-
>> De: Mladen Turk [mailto:[EMAIL PROTECTED]]
>> Enviado el: 21 de junio de 2002 8:19
>> Para: 'Tomcat Developers List'
>> Cc: [EMAIL PROTECTED]; GOMEZ Henri
>> Asunto: mod_jk testing (WAS RE: mod_jk 1.2.0 workers pool)
>> Importancia: Alta
>> 
>> 
>> First some things about testing:
>> 
>> DO NOT USE the date.jsp (it could return various html 
>lengths, so from
>> there are coming those Failed requests ).
>> I've just browsed through the source code of ab and it uses the first
>> page as its length ethalon, and date.jsp could retur various 
>length if
>> the tests are finishing on the single second interval so 
>> there is 1 byte
>> html length differnce.
>> 
>> Use the /examples/jsp/snp/snoop.jsp instead (think it allways returns
>> the same content-length).
>> 
>> The ones that count are only the 'Non-2xx responses'
>> 
>> 
>> > -Original Message-
>> > From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] 
>> > Sent: 20. lipanj 2002 22:37
>> > To: 'Tomcat Developers List'
>> > Subject: RE: mod_jk 1.2.0 workers pool
>> > 
>> > 
>> > > -Mensaje original-
>> > > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
>> > Enviado el: 20 
>> > > de junio de 2002 20:29
>> > 
>> > I need time to prepare a machine that can handle this level 
>> > of concurrency, Mladen used  -c 200, i need to switch to one 
>> > of the servers, :(, Thanks to microsoft, W2k professional 
>> > only can handle 10 simultaneus connections :..
>> >
>> It's a IIS thing I think.
>>  
>> > I think Mlanden uses XP, right? which version ? Home, 
>> > Professional? do you know the exact number of concurrent 
>> > connections the XP version you use can handle?
>> > 
>> 
>> Its Professional. And if I'm running the snoop.jsp with -c 200:
>> 
>> 181857 [Thread-4] ERROR server.JkCoyoteHandler  - Error in 
>action code
>> java.net.SocketException: Software caused connection abort: 
>> socket write
>> error
>> 
>> And,
>> 
>> 181867 [Thread-4] ERROR common.ChannelSocket  - Error, closing
>> connection
>> java.net.SocketException: Software caused connection abort: 
>> JVM_recv in
>> socket input stream read
>> 
>> Running with -c 10 doesn't produce such a error.
>> 
>> 
>> MT.
>> 
>> 
>

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

DO NOT REPLY [Bug 9439] - mod_jk on solaris not working with apache 2.0.35

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

mod_jk on solaris not working with apache 2.0.35

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 15:38 ---
Fixed in current jk 1.2.0 CVS

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

DO NOT REPLY [Bug 5511] - Error upload files

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

Error upload files

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 15:57 ---
Could you try against latest mod_jk and tomcat 3.3.1

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

DO NOT REPLY [Bug 5925] - Apache server hangs up and consumes 100% CPU resource when upload file to server

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

Apache server hangs up and consumes 100% CPU resource when upload file to server





--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 15:59 ---
Could you retry against latest Tomcat 3.3.1 and mod_jk ?

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

DO NOT REPLY [Bug 7863] - I have a problem when running Tomcat with IIS

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

I have a problem when running Tomcat with IIS





--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 16:00 ---
Could you retry against latest Tomcat 3.3.1 and mod_jk ?

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

DO NOT REPLY [Bug 7637] - Tomcat terminates after connecting to a database

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

Tomcat terminates after connecting to a database

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 16:01 ---
This is a jvm error, and have nothing to do with tomcat.
Try to get an updated JDK

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

Re: How was the precompiled mod_webapp.so binary built for Solaris 8

[Albert Chin]

On Thu, Jun 20, 2002 at 05:56:44PM +0100, Pier Fumagalli wrote:
> "Albert Chin" <[EMAIL PROTECTED]> wrote:
> 
> > How was the precompiled binary of mod_webapp available from
> > http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.3/bin/solaris
> > 8/sparc/
> > built?
> > 
> > I'm trying to build it with the Sun C compiler (Forte 6.2) as follows
> > (Apache 1.3.24):
> > ./configure CFLAGS="-mr -Qn -xstrconst -xO2 -xtarget=generic -xarch=v8" \
> > CC=cc JAVA_HOME=/opt/java1.4 --with-apxs=[blah] --with-perl=[blah] \
> > --disable-docs --disable-apidoc-java --disable-apidoc-c \
> > --with-java=[tomcat dir] --with-ant=[path to ant]
> > 
> > I followed the instructions at:
> > http://archive.covalent.net/jakarta/tomcat-user/2002/03/0209.xml
> > to fetch webapp and apr but get an error when trying to connect:
> > 
> > $ telnet localhost 80
> > Trying 127.0.0.1...
> > Connected to localhost.
> > Escape character is '^]'.
> > GET /examples/ HTTP/1.0
> > 
> > Connection closed by foreign host.
> > 
> > Using the precompiled binary above works fine!
> > 
> > I attached to the httpd pid as no core was generated:
> > $ gdb pid [blah]
> > gdb> bt
> > #0  0xfebc75b0 in apr_vformatter (flush_func=0xfebd348c ,
> > vbuff=0xffbef430, fmt=0xfebdac53 "d %s", ap=0xffbef520)
> > at apr_snprintf.c:1189
> > #1  0xfebd37e0 in apr_pvsprintf (pool=0xbe430, fmt=0xfebdac50 "%03d %s",
> > ap=0xffbef51c) at apr_pools.c:992
> > #2  0xfebd3a7c in apr_psprintf (p=0xbe430, fmt=0xfebdac50 "%03d %s")
> > at apr_pools.c:1730
> > #3  0xfebbd430 in wam_handler_setstatus (r=0xbe458, status=200,
> > message=0xd0460 "OK") at mod_webapp.c:299
> > ...
> > 
> > This is against webapp/apr as of 06/19 01:00PM CDT.
> 
> Are you using the latest copy straight out of CVS? It mightbe a small bug I
> introduced last week AFAICS...

Yes, the latest from CVS as of 06/19 01:00PM CDT.

-- 
albert chin ([EMAIL PROTECTED])

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

DO NOT REPLY [Bug 9416] - Memory usage by Tomcat

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

Memory usage by Tomcat

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 16:06 ---
Tomcat 3.2.x is known to have memory problems (TC 3.2 creating way to much 
objects).
Upgrade to Tomcat 3.3 or 4.0

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

Re: Proposal draft for Tomcat 5.0

[Nicola Ken Barozzi]

Remy, I hear you.
Current Avalon is what you say.
Next Avalon will be what it was supposed to be in the first place.

I respect you and your judgement; if you could give me additional hints 
on what the problem is about for using Avalon here, I would sincerely be 
grateful.

Anyway, as I tried to say in my last post, the only fact that you think 
this about Avalon is IMHO enough to not use it ATM.

Remy Maucherat wrote:

> For all the things it gives you, Avalon is a framework, and makes you 
> feel like it. It imposes contracts between components / patterns, 
> packaging, etc. All things which aren't compatible with 5.0. 

Hmmm... imposing good contracts is a good thing. Every API is a 
contract, and good APIs help make good software.
Hmmm...

 > And more
> importantly, the API changes often, to the extent that all the projects 
> which use Avalon work off a specific snapshot, and don't upgrade too often.

This is not that true. Avalon framework API 4 is stable for quite some 
time. What really changed fast are the implementations.

We are now working on make a single reference implementation and focus 
on that.

> Also, most of the utility provided by Avalon are available from the 
> commons without any string attached, and/or are of a better quality.

Utilities provided by Avalon are lifecycle management and component 
reusability+management.
All the other things are not Avalon, and are currently being moved to 
Commons, or wherelse where they belong.

> There has been plenty of discussion on that with Paul, and during the 
> whole commons-logging incident, at which point I thought it would be 
> best if I didn't have anything to do with Avalon.

I wasn't here when the logging incident took place, luckily ;-) , but I 
must say that it was a bad thing for all of us.

Currently there has been a proposal of using commons logging APIs, but 
there is still a bit of resistence from both parts.

I'm confident we will get through them, because if we don't I'll ask 
Pier some spiritual karma and have some kicking to do ;-)

> OTOH, we could have optional Avalon wrappers again, as long as there is 
> someone to write them *and* maintain them when the API changes. 

This is certainly nice.
I hoped that someone did some work on them, but it's ok.

When we'll be ready for that stage, I'll post again.

> So +0.1 
> to work nice with Avalon, but -1 for basing the architecture on Avalon.

We'll talk about this when we've finished our spring-cleaning.

Could you kindly summarize the things that Avalon needs to do before you 
would even consider taking it in consideration as a framework?

Thanks :-)

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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

jspc patch for TC 3.3.2

[GOMEZ Henri]

Hi,

One of my coworker have some problems with jspc
when included jsp got a relative path.

Find attached a possible patch. 

Thanks to comment and commit if 
valid.

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




jspc.patch
Description: jspc.patch

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

RE: mod_jk testing (WAS RE: mod_jk 1.2.0 workers pool)

[Mladen Turk]

> -Original Message-
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] 
> Sent: 21. lipanj 2002 17:27
> To: 'Mladen Turk'; 'Tomcat Developers List'
> Cc: '[EMAIL PROTECTED]'; 'GOMEZ Henri'
> Subject: RE: mod_jk testing (WAS RE: mod_jk 1.2.0 workers pool)
> 
> 
> Ahhh, finally got to do the test on a capable machine, but 
> very overloaded with some db procecesses, dont take anything 
> from the absolute timing i know are very bad.., 
> 
> For all the other, my test seem ok..
>

Great...
 
> 
> Server Software:Microsoft-IIS/5.0
> Server Hostname:ciberlogic
> Server Port:80

Perhaps its my XP then?

Further more seems that my patch not behaves very well with IIS :(.
Currently checking why, so hold the patches...

MT.


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

DO NOT REPLY [Bug 9440] - build-unix.sh does not build on solaris 8 for apache2.0.35

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

build-unix.sh does not build on solaris 8 for apache2.0.35

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 16:28 ---
You should use instead configure :

cd jk/native
./buildconf.sh
./configure --with-apxs=/usr/sbin/apxs2 (path to your apxs for Apache 2)
cd apache-2.0
make -f Makefile.apxs

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

mod_jk 1.2.0 release news

[GOMEZ Henri]

Ok, I restarted the test using ab against
Apache 1.3/2.0 and Tomcat 3.3.1 and 4.0.4.


Status/Stability :


I stressed latest jk 1.2.0 with ab using 127 
concurrents requests, asking for 1 Million requests 
for the good old HelloWorldExample servlet
(Mladen discovered a problem with ab with dynamic
content-length)

I didn't have any error now, with any
combinaison of Apache 1.3/2.0 and 
Tomcat 3.3.1/4.0.4.

Nacho does also extended testing with IIS
without any problems

We need now people to test jk 1.2.0 against
apache 1.3/2.0 on windows (and windows/cygwin ?).
Also we need testing for iplanet.


Bugzilla :


jk/tc3

ID Sev Pri Plt Owner State Result Summary 
5925  Cri Oth PC [EMAIL PROTECTED] NEW  Apache server hangs up and 
consumes 100% CPU resource when u  
7863  Maj Oth PC [EMAIL PROTECTED] NEW  I have a problem when running 
Tomcat with IIS  
9913  Nor Oth PC [EMAIL PROTECTED] NEW  Default pages not picked up by 
mod_jk 1.2.0 with Apache 2.0.  

jk/tc4

ID Sev Pri Plt Owner State Result Summary 
4500  Nor Oth PC [EMAIL PROTECTED] NEW  isapi_redirect.dll does not pass 
Client certificate to tomca  
4930  Maj Hig PC [EMAIL PROTECTED] ASSI  java.io.StreamCorruptedException: 
Type code out of range, is  
5709  Nor Oth All [EMAIL PROTECTED] REOP  HttpServletRequest.getHost 
returns web server address or nul  
6457  Cri Oth Sun [EMAIL PROTECTED] NEW  mod_jk causes segmentation fault 
with JkLogLevel != debug  
6983  Nor Oth Oth [EMAIL PROTECTED] NEW  SSL + Mac + IE5 = no session 
cookies  
8541  Nor Oth PC [EMAIL PROTECTED] NEW  IIS redirector URL-encodes cookie 
values  
8613  Maj Oth Sun [EMAIL PROTECTED] NEW  POST request with invalid 
Content-Length header  
8709  Maj Hig PC [EMAIL PROTECTED] NEW  ISAPI Filter failing to pass on 
DAV "OPTIONS" requests  
8918  Nor Oth Sun [EMAIL PROTECTED] NEW  Wrong ContentType set.  
9334  Nor Oth PC [EMAIL PROTECTED] NEW  Intermittent parsing error in 
Ajp13Request  
9417  Blo Oth Oth [EMAIL PROTECTED] NEW  ajp13 conector does not pass 
Query string corectly to tomcat  
9791  Cri Oth All [EMAIL PROTECTED] NEW  Form-based login fails using 
apache, mod_jk, mod_ssl without  
9832  Cri Oth PC [EMAIL PROTECTED] NEW  Tomcat 4 IIS redirector cannot 
cope with POST in SSL  
9936  Cri Hig All [EMAIL PROTECTED] NEW  http tunnel could not work with 
mod_jk  


Many of them seems more related to java side than native side.
Others are for IIS integration (Nacho thanks to see what could be done).


Patches :
---

Before we release mod_jk 1.2.0 there was 
proposed patches by Mladen Turk (pool of workers)
and Jan Singer (timeout/keepalive) which could be
applied to mod_jk 1.2.0.

The patches proposed by Jan will be really
usefull when you got a firewall between 
Apache and Tomcat (a common situation) and
shouldn't brake anything.

The patches proposed by Mladen are more complex
and I'd like to delay them for mod_jk 1.2.1 or
may be better see how they included/adapted for jk2.


Documentation :
-

Both series of patches will need a documentation
update, and I'd like to switch to xml documentations
format used by JF for jk2 for :

mod_jk-howto.html
in-process-howto.html
tomcat-iis-howto.html
tomcat-netscape-howto.html

I'll convert all of them to xml, but will need 
help for in-process, iis, netscape to update what's
needed.

I discover many documentations about jk/webapp/tomcat's on the web :

http://www.acg-gmbh.de/mod_jk/http://www.acg-gmbh.de/mod_jk/

http://bruno.vernay.free.fr/HowTo/Apache-tomcat/bWebServer/

http://www.webmasterbase.com/article/305

http://www.galatea.com/flashguides/index

http://www.jguru.com/faq/subtopic.jsp?topicID=417590

http://www.jguru.com/faq/subtopic.jsp?topicID=221895

http://www.jguru.com/forums/home.jsp?topic=Tomcat

http://dcb.sun.com/practices/howtos/tomcat_apache.jsp

http://www.pubbitch.org/jboss.html

http://www.ajug.org/howto/tomcat4.html

http://www.tek-tips.com/gfaqs.cfm/lev2/3/lev3/22/spid/65/sfid/1552

These documentations are excellent so I've contacted authors to see
if they could be interested in contributing some updated how-to/guide
which will be present in mod_jk 1.2.0 release or later at jakarta.


Contributors :


We'll need people using others platform like HP-UX, AIX, 
Solaris (sparc/intel), MacOS/X (Pier ?), OS/390, OS/400
to build mod_jk 1.2.0 after I tag it and release the tarball.



Apply Jan patches, review  

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

Re: Proposal draft for Tomcat 5.0

[Stefanos Karasavvidis]

> The major goals for Apache Tomcat 5.0 are to:
> - have simpler/cleaner code, so more people can get involved

Although not Tomcat 5 specific, I would add the following
- have good documentation, so more people can use it without going through the dev list
- have good documentation, so more people can get involved 

Stefanos Karasavvidis



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

Re: Proposal draft for Tomcat 5.0

[costinm]

On Fri, 21 Jun 2002, Christopher K.  St.  John wrote:

>  Re-architecting Tomcat yet again is a bad step if it's not
> absolutely necessary. I have some reservations. To keep from
> confusing the issue, I'll list them in separate messages.

It's not re-architecting tomcat - AFAIK 5.0 is just a normal
evolution of the existing architecture(s).

Coyote is already used, and we should try to make sure most of the
code that works today with either 3.3 or 4.0 will work with 5.0.
The only change in Coyote that is needed is in the Action area,
to better support this.

> > while at the same time adding support for the new Servlet
> > API 2.4 and JSP 2.0 specifications
> >
> 
>  Reservation #1: There is a new architecture being proposed,
> but since the 2.4 API isn't out yet, all the requirements aren't
> available. So there's no intelligent way to judge if the
> architecture fits well with the primary requirement (which is
> being a good 2.4 container)

Most of the proposal refers to the lower layer, and I hope the 
2.4 API will not do any crazy things - we are already stretching 
the limits on server integration.

Costin


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

Re: Proposal draft for Tomcat 5.0

[costinm]

I'm also -1 on Avalon - same reasons as Remy, plus more ( 
the IoC madness/obsession, the over-design, ever-changing interfaces, 
logkit, etc.)

Some components are good, and the move to commons is great - but
I'm strongly -1 on using the framework.

Costin 


On Fri, 21 Jun 2002, Remy Maucherat wrote:

> For all the things it gives you, Avalon is a framework, and makes you 
> feel like it. It imposes contracts between components / patterns, 
> packaging, etc. All things which aren't compatible with 5.0. And more 
> importantly, the API changes often, to the extent that all the projects 
> which use Avalon work off a specific snapshot, and don't upgrade too often.
> 
> Also, most of the utility provided by Avalon are available from the 
> commons without any string attached, and/or are of a better quality.
> 
> There has been plenty of discussion on that with Paul, and during the 
> whole commons-logging incident, at which point I thought it would be 
> best if I didn't have anything to do with Avalon.
> 
> OTOH, we could have optional Avalon wrappers again, as long as there is 
> someone to write them *and* maintain them when the API changes. So +0.1 
> to work nice with Avalon, but -1 for basing the architecture on Avalon.
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 




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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler JspRuntimeContext.java

[glenn]

glenn   2002/06/21 10:11:32

  Modified:jasper2/src/share/org/apache/jasper/compiler
JspRuntimeContext.java
  Log:
  Preload TagHandlerPool class to make SecurityManager happy
  
  Revision  ChangesPath
  1.4   +6 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java
  
  Index: JspRuntimeContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- JspRuntimeContext.java20 Jun 2002 22:58:58 -  1.3
  +++ JspRuntimeContext.java21 Jun 2002 17:11:32 -  1.4
  @@ -127,6 +127,8 @@
   factory.getClass().getClassLoader().loadClass( basePackage +
   "runtime.ServletResponseWrapperInclude");
   factory.getClass().getClassLoader().loadClass( basePackage +
  +"runtime.TagHandlerPool");
  +factory.getClass().getClassLoader().loadClass( basePackage +
   "servlet.JspServletWrapper");
   } catch (ClassNotFoundException ex) {
   System.out.println(
  
  
  

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

Re: Tomcat 4.1 HEAD DefaultContext JNDI bug

[Remy Maucherat]

Glenn Nielsen wrote:
> I just built Tomcat 4.1 HEAD from CVS and get the following for JNDI
> named resource defined in the server.xml  for a Host.
> 
> 2002-06-21 12:07:46 
>NamingContextListener[/Tomcat-Apache/www.dev.kinetic.more.net/dbtags-examples]: 
>Failed to bind obje
> ct: javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
> 2002-06-21 12:07:46 
>NamingContextListener[/Tomcat-Apache/www.dev.kinetic.more.net/dbtags-examples]: 
>Failed to bind obje
> ct: javax.naming.NameNotFoundException: Name mail is not bound in this Context

I noticed (yesterday) I had introduced bugs during my last cleanup (much 
needed, there were two notification schemes being used, etc). I'm 
working on it :)

Remy


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

Re: Proposal draft for Tomcat 5.0

[costinm]

On Fri, 21 Jun 2002, Nicola Ken Barozzi wrote:

> Remy, I hear you.
> Current Avalon is what you say.
> Next Avalon will be what it was supposed to be in the first place.

I think next avalon should start by looking for a problem to solve
before proposing the solution to all the problems :-)
And it should start looking at what APIs are already used ( JMX, 
JNDI, etc ).

> > Also, most of the utility provided by Avalon are available from the 
> > commons without any string attached, and/or are of a better quality.
> 
> Utilities provided by Avalon are lifecycle management and component 
> reusability+management.

I don't think we have problems with the lifecycle management or 
component management ( for the last JMX seems to solve the problem ).

> Could you kindly summarize the things that Avalon needs to do before you
> would even consider taking it in consideration as a framework? 

I suppose finding the problem to solve would be a good first step.


Costin


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

RE: Jasper2: serious problem with tag declarations

[Jan Luehe]

Hi Costin,

> But there is still a problem - now if you have:
>
>   
> 
>   
>   
> 
> ( i.e. the same variable name ), it will fail with duplicated declaration, 
> the code will be: 
>Object i;
>...
>Object i;
> 
> ( id is nested ).

The above code fragment compiles fine for me.
I've attached the generated servlet code.

Can you send me the exact page you are trying to run?
If you could provide the generated code, that would help, too.

Thanks,


Jan


package org.apache.jsp;

import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import org.apache.jasper.runtime.*;

public class test1$jsp extends HttpJspBase {


  private static java.util.Vector _jspx_includes;

  private org.apache.jasper.runtime.TagHandlerPool _jspx_tagPool_logic_iterate_id;

  public test1$jsp() {
_jspx_tagPool_logic_iterate_id = new org.apache.jasper.runtime.TagHandlerPool();
  }

  public java.util.List getIncludes() {
return _jspx_includes;
  }

  public void jspDestroy() {
_jspx_tagPool_logic_iterate_id.release();
  }

  public void _jspService(HttpServletRequest request, HttpServletResponse response)
throws java.io.IOException, ServletException {

JspFactory _jspxFactory = null;
javax.servlet.jsp.PageContext pageContext = null;
HttpSession session = null;
ServletContext application = null;
ServletConfig config = null;
JspWriter out = null;
Object page = this;
JspWriter _jspx_out = null;


try {
  _jspxFactory = JspFactory.getDefaultFactory();
  response.setContentType("text/html;ISO-8859-1");
  pageContext = _jspxFactory.getPageContext(this, request, response,
null, true, 8192, true);
  application = pageContext.getServletContext();
  config = pageContext.getServletConfig();
  session = pageContext.getSession();
  out = pageContext.getOut();
  _jspx_out = out;

  out.write("\n\n");
  /*   logic:iterate  */
  java.lang.Object i;
  org.apache.struts.taglib.logic.IterateTag _jspx_th_logic_iterate_0 = 
(org.apache.struts.taglib.logic.IterateTag) 
_jspx_tagPool_logic_iterate_id.get(org.apache.struts.taglib.logic.IterateTag.class);
  _jspx_th_logic_iterate_0.setPageContext(pageContext);
  _jspx_th_logic_iterate_0.setParent(null);
  _jspx_th_logic_iterate_0.setId("i");
  int _jspx_eval_logic_iterate_0 = _jspx_th_logic_iterate_0.doStartTag();
  if (_jspx_eval_logic_iterate_0 != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
if (_jspx_eval_logic_iterate_0 != 
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE) {
  javax.servlet.jsp.tagext.BodyContent _bc = pageContext.pushBody();
  _bc.clear();
  out = _bc;
  _jspx_th_logic_iterate_0.setBodyContent(_bc);
  _jspx_th_logic_iterate_0.doInitBody();
}
do {
  i = (java.lang.Object) pageContext.findAttribute("i");
  out.write(" \n");
} while (_jspx_th_logic_iterate_0.doAfterBody() == 
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);
if (_jspx_eval_logic_iterate_0 != 
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE)
  out = pageContext.popBody();
  }
  if (_jspx_th_logic_iterate_0.doEndTag() == 
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;
  _jspx_tagPool_logic_iterate_id.reuse(_jspx_th_logic_iterate_0);
  out.write("\n\n");
  /*   logic:iterate  */
  org.apache.struts.taglib.logic.IterateTag _jspx_th_logic_iterate_1 = 
(org.apache.struts.taglib.logic.IterateTag) 
_jspx_tagPool_logic_iterate_id.get(org.apache.struts.taglib.logic.IterateTag.class);
  _jspx_th_logic_iterate_1.setPageContext(pageContext);
  _jspx_th_logic_iterate_1.setParent(null);
  _jspx_th_logic_iterate_1.setId("i");
  int _jspx_eval_logic_iterate_1 = _jspx_th_logic_iterate_1.doStartTag();
  if (_jspx_eval_logic_iterate_1 != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
if (_jspx_eval_logic_iterate_1 != 
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE) {
  javax.servlet.jsp.tagext.BodyContent _bc = pageContext.pushBody();
  _bc.clear();
  out = _bc;
  _jspx_th_logic_iterate_1.setBodyContent(_bc);
  _jspx_th_logic_iterate_1.doInitBody();
}
do {
  i = (java.lang.Object) pageContext.findAttribute("i");
  out.write("\n");
} while (_jspx_th_logic_iterate_1.doAfterBody() == 
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);
if (_jspx_eval_logic_iterate_1 != 
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE)
  out = pageContext.popBody();
  }
  if (_jspx_th_logic_iterate_1.doEndTag() == 
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;
  _jspx_tagPool_logic_iterate_id.reuse(_jspx_th_logic_iterate_1);
  out.write("\n\n");
} catch (Throwable t) {
  out = _jspx_out;
  if (out != null && out.getBufferSize() != 0)
out.clearBuffer();
  if (pageConte

RE: mod_jk 1.2.0 release news

[Mladen Turk]

> -Original Message-
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] 
> Sent: 21. lipanj 2002 18:36
> 
> Status/Stability :
> 
> 
> I stressed latest jk 1.2.0 with ab using 127 
> concurrents requests, asking for 1 Million requests 
> for the good old HelloWorldExample servlet
> (Mladen discovered a problem with ab with dynamic
> content-length)
> 
> I didn't have any error now, with any
> combinaison of Apache 1.3/2.0 and 
> Tomcat 3.3.1/4.0.4.
>

What about those forced closed connections, and not closed sockets?

> 
> We need now people to test jk 1.2.0 against
> apache 1.3/2.0 on windows (and windows/cygwin ?).
> Also we need testing for iplanet.
> 

Apache 2.0.39+ with Tomcat 4 is ok on WIN2K, but has problems on XP. It
would be great if someone can run that on the other XP machine, but on
the other hand doesn't really matter because of afd.sys bug on XP (MSKB
article Q317949).


MT.


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

Re: Proposal draft for Tomcat 5.0 : #1: 2.4 spec

[Christopher K. St. John]

[EMAIL PROTECTED] wrote:
> 
> I hope the 2.4 API will not do any crazy things
>

 Me too.

 One of the things I heard mentioned was tighter integration
with the NIO api's, which could affect both low and high level
layers. OTOH, maybe not, I haven't seen the spec. But that's
the whole point.



-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

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

Re: Proposal draft for Tomcat 5.0

[Nicola Ken Barozzi]

[EMAIL PROTECTED] wrote:
> I'm also -1 on Avalon - same reasons as Remy, plus more ( 
> the IoC madness/obsession,

? madness?

It's a pattern, would you say that someone has a "Factory" obsession?

> the over-design,

Please explain.

> ever-changing interfaces, 

The Avalon 4 interfaces are stable.
They are not everchanging.

> logkit, etc.)

?
What does logkit have to do with framework?

> Some components are good, and the move to commons is great - but
> I'm strongly -1 on using the framework.

Please give me some more insight.
What you say seems to me like: Avalon is too good to be of any use.
If it were a bit more "hacky" I would use it.

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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

RE: mod_jk 1.2.0 release news

[costinm]

Very strange..

I looked at the patch, I think we should spend more time on that, the
sleep doesn't look good and I'm afraid we may have some problems
with the CS.

The worker was supposed to be thread safe, like a servlet - and
so far it works in most cases. But all thread problems are
difficult to trace, and if we can't find the real problem I'm
ok with using the pool - but with a different patch if possible.

I run tests with jk2 and it seems to work fine ( -c 100).

Costin


On Fri, 21 Jun 2002, Mladen Turk wrote:

> 
> 
> > -Original Message-
> > From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] 
> > Sent: 21. lipanj 2002 18:36
> > 
> > Status/Stability :
> > 
> > 
> > I stressed latest jk 1.2.0 with ab using 127 
> > concurrents requests, asking for 1 Million requests 
> > for the good old HelloWorldExample servlet
> > (Mladen discovered a problem with ab with dynamic
> > content-length)
> > 
> > I didn't have any error now, with any
> > combinaison of Apache 1.3/2.0 and 
> > Tomcat 3.3.1/4.0.4.
> >
> 
> What about those forced closed connections, and not closed sockets?
> 
> > 
> > We need now people to test jk 1.2.0 against
> > apache 1.3/2.0 on windows (and windows/cygwin ?).
> > Also we need testing for iplanet.
> > 
> 
> Apache 2.0.39+ with Tomcat 4 is ok on WIN2K, but has problems on XP. It
> would be great if someone can run that on the other XP machine, but on
> the other hand doesn't really matter because of afd.sys bug on XP (MSKB
> article Q317949).
> 
> 
> MT.
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


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

RE: mod_jk 1.2.0 release news

[GOMEZ Henri]

>> I stressed latest jk 1.2.0 with ab using 127 
>> concurrents requests, asking for 1 Million requests 
>> for the good old HelloWorldExample servlet
>> (Mladen discovered a problem with ab with dynamic
>> content-length)
>> 
>> I didn't have any error now, with any
>> combinaison of Apache 1.3/2.0 and 
>> Tomcat 3.3.1/4.0.4.
>>
>
>What about those forced closed connections, and not closed sockets?

You're right, there is still more jk_open_connection calls 
than jk_close_connection. Could you try to figure and fix that ?

>> We need now people to test jk 1.2.0 against
>> apache 1.3/2.0 on windows (and windows/cygwin ?).
>> Also we need testing for iplanet.
>> 
>
>Apache 2.0.39+ with Tomcat 4 is ok on WIN2K, but has problems on XP. It
>would be great if someone can run that on the other XP machine, but on
>the other hand doesn't really matter because of afd.sys bug on XP (MSKB
>article Q317949).

If it works on W2K and not on XP, it's a M$ problem which should 
be reported to msdn ;)

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

Re: Proposal draft for Tomcat 5.0

[Nicola Ken Barozzi]

[EMAIL PROTECTED] wrote:
> On Fri, 21 Jun 2002, Nicola Ken Barozzi wrote:
> 
> 
>>Remy, I hear you.
>>Current Avalon is what you say.
>>Next Avalon will be what it was supposed to be in the first place.
> 
> 
> I think next avalon should start by looking for a problem to solve
> before proposing the solution to all the problems :-)

We have a charter.

> And it should start looking at what APIs are already used ( JMX, 
> JNDI, etc ).

We know them.

Phoenix is MBean compatible (baxter is currently being put in 
Commons-sandbox), JNDI is not incompatible with Avalon, since Avalon 
itself has no alternative to give for it; excalibur even has a "naming" 
package for it.

>>>Also, most of the utility provided by Avalon are available from the 
>>>commons without any string attached, and/or are of a better quality.
>>
>>Utilities provided by Avalon are lifecycle management and component 
>>reusability+management.
> 
> 
> I don't think we have problems with the lifecycle management or 
> component management ( for the last JMX seems to solve the problem ).

I never said you have a problem.
But since you are redesigning, I would think you would consider using 
the "Java Apache Server Framework" which Avalon is.

As commons is a common package repo, Avalon should be the common server 
framework.

James runs on it, Cocoon soon, Turbine is working on it, we have an FTP 
server, HSQLDB, FOP component, POI component in the works...

>>Could you kindly summarize the things that Avalon needs to do before you
>>would even consider taking it in consideration as a framework? 
> 
> I suppose finding the problem to solve would be a good first step.

This project goals are:
 >  - Design and documentation of the Java Apache Server Framework.
 >  - Creation and implementation of this framework
 >(interfaces, abstract classes, and shared modules).
 >  - Centralized management of the evolution/fixing/patching
 >of both the shared code and the framework design.

We are reorganizing to refocus on our original goal, and become more 
tight focused.

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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

RE: Proposal draft for Tomcat 5.0

[GOMEZ Henri]

I hope that Tomcat 5.0 proposal draft won't turn in
a battle or flame war between Tomcat and Avalon commiters.

Why ?

Because we had just too many flams wars in tomcat-dev
between tomcat 3.3 and tomcat 4.x teams.

Tomcat 5.0 appears to be a way to have both teams
works again together to make a better tomcat,
which will be profitable to the whole jakarta 
community.

Tomcat 5.0 will be Coyote 2.0 based, a small and
efficient core.

The question shouldn't be to use Avalon as framework, 
but how make tighers links between Avalon and TC 5.0.

That core will link to catalina 2.0, jasper 3, 
why not avalon 4 or 5 ? 

Others goal of TC 5.0 will be to be faster than TC 3.3
or 4.x, better integration with web-servers, better
management via JMX.

TC 5.0 is a normal evolution on works conducted on 
TC 3.3 and 4.x, and a merge of ideas and commiters.

That's not so bad.

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

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

DO NOT REPLY [Bug 9318] - HttpSession getMaxInactiveInterval() throws IllegalStateException

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

HttpSession getMaxInactiveInterval() throws IllegalStateException





--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 17:56 ---

I reviewed the Servlet Specs and I agree with the poster.  This
patch stops the exception from being thrown.

Cheers,
-bob

Index: StandardSession.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
retrieving revision 1.28
diff -r1.28 StandardSession.java
473,476d472
< if (!isValid)
< throw new IllegalStateException
< (sm.getString("standardSession.getMaxInactiveInterval.ise"));
<

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

RE: Proposal draft for Tomcat 5.0

[costinm]

+1

Costin


On Fri, 21 Jun 2002, GOMEZ Henri wrote:

> I hope that Tomcat 5.0 proposal draft won't turn in
> a battle or flame war between Tomcat and Avalon commiters.
> 
> Why ?
> 
> Because we had just too many flams wars in tomcat-dev
> between tomcat 3.3 and tomcat 4.x teams.
> 
> Tomcat 5.0 appears to be a way to have both teams
> works again together to make a better tomcat,
> which will be profitable to the whole jakarta 
> community.
> 
> Tomcat 5.0 will be Coyote 2.0 based, a small and
> efficient core.
> 
> The question shouldn't be to use Avalon as framework, 
> but how make tighers links between Avalon and TC 5.0.
> 
> That core will link to catalina 2.0, jasper 3, 
> why not avalon 4 or 5 ? 
> 
> Others goal of TC 5.0 will be to be faster than TC 3.3
> or 4.x, better integration with web-servers, better
> management via JMX.
> 
> TC 5.0 is a normal evolution on works conducted on 
> TC 3.3 and 4.x, and a merge of ideas and commiters.
> 
> That's not so bad.
> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .) 
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


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

RE: mod_jk 1.2.0 release news

[Mladen Turk]

> >
> >What about those forced closed connections, and not closed sockets?
> 
> You're right, there is still more jk_open_connection calls 
> than jk_close_connection. Could you try to figure and fix that ?
>

I'll try, or consider that done :-).
 
> 
> If it works on W2K and not on XP, it's a M$ problem which should 
> be reported to msdn ;)
> 

It is, long time ago, and they have a fix, but will be available in the
next service pack :). I'm waiting 3 days to receive it, but, as the guy
from their support said, their server in Munich is down (3 days?).

MT.


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

RE: mod_jk 1.2.0 release news

[GOMEZ Henri]

>> >What about those forced closed connections, and not closed sockets?
>> 
>> You're right, there is still more jk_open_connection calls 
>> than jk_close_connection. Could you try to figure and fix that ?
>>
>
>I'll try, or consider that done :-).

Ok, I consider it will be fixed on Monday ;-)

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

Tomcat 4.0.4 -> CM ! YES.. WAS:::: AW: [ANNOUNCEMENT] Tomcat 4.0.4 Final released

[Oliver Fischer]

Say hello to Tomcat 4.0.4 in our CM share

Bye

Oliver

P.S.: The script tomcat4 still uses 4.0.3 To use 4.0.4 you have to call to
Tomcat4_0_4.bat script... Hey Tomcat4 is an interface ... ;-)

-Ursprüngliche Nachricht-
Von: Remy Maucherat [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 19. Juni 2002 08:04
An: Tomcat Developers List; Tomcat Users List;
[EMAIL PROTECTED]
Betreff: [ANNOUNCEMENT] Tomcat 4.0.4 Final released


The Tomcat team is proud to announce the availability of Tomcat 4.0.4 
Final. This release includes bugfixes and small feature additions over 
Tomcat 4.0.2/4.0.3. Please refer to the release notes for the complete list.

Release notes:
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.4/RELEASE-N
OTES

Downloads (source and binaries):
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.4/

Remy


--
To unsubscribe, e-mail:

For additional commands, e-mail:


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

Re: mod_jk 1.2.0 release news

[Martin van den Bemt]

On Fri, 2002-06-21 at 18:36, GOMEZ Henri wrote:
> Contributors :
> 
> 
> We'll need people using others platform like HP-UX, AIX, 
> Solaris (sparc/intel), MacOS/X (Pier ?), OS/390, OS/400
> to build mod_jk 1.2.0 after I tag it and release the tarball.

I can build it on solaris 6 and 8 afaik runnign on a sparc, if you want
the building tested.. I can add it to the test server, which is not used
very often..


Mvgr,
Martin


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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session StandardSession.java

[remm]

remm2002/06/21 11:07:06

  Modified:catalina/src/share/org/apache/catalina/session
StandardSession.java
  Log:
  - Fix obvious problem when recycling sessions (manager was always null, so
it was never recycled).
  - Patch submitted by Bob Herrmann 
  
  Revision  ChangesPath
  1.29  +6 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java
  
  Index: StandardSession.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- StandardSession.java  1 Mar 2002 19:37:45 -   1.28
  +++ StandardSession.java  21 Jun 2002 18:07:06 -  1.29
  @@ -768,7 +768,6 @@
   expiring = false;
   id = null;
   lastAccessedTime = 0L;
  -manager = null;
   maxInactiveInterval = -1;
   notes.clear();
   setPrincipal(null);
  @@ -778,6 +777,8 @@
   // Tell our Manager that this Session has been recycled
   if ((manager != null) && (manager instanceof ManagerBase))
   ((ManagerBase) manager).recycle(this);
  +
  +manager = null;
   
   }
   
  
  
  

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session StandardSession.java

[remm]

remm2002/06/21 11:14:22

  Modified:catalina/src/share/org/apache/catalina/session
StandardSession.java
  Log:
  - Don't throw ISE when getMaxInactiveInterval is called.
  - Bugzilla 9318.
  - Patch submitted by Bob Herrmann 
  
  Revision  ChangesPath
  1.30  +4 -11 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java
  
  Index: StandardSession.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- StandardSession.java  21 Jun 2002 18:07:06 -  1.29
  +++ StandardSession.java  21 Jun 2002 18:14:21 -  1.30
  @@ -464,15 +464,8 @@
* Return the maximum time interval, in seconds, between client requests
* before the servlet container will invalidate the session.  A negative
* time indicates that the session should never time out.
  - *
  - * @exception IllegalStateException if this method is called on
  - *  an invalidated session
*/
   public int getMaxInactiveInterval() {
  -
  -if (!isValid)
  -throw new IllegalStateException
  -(sm.getString("standardSession.getMaxInactiveInterval.ise"));
   
   return (this.maxInactiveInterval);
   
  
  
  

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

DO NOT REPLY [Bug 9318] - HttpSession getMaxInactiveInterval() throws IllegalStateException

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

HttpSession getMaxInactiveInterval() throws IllegalStateException

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 18:14 ---
I think I agree too.

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

DO NOT REPLY [Bug 5829] - StandardManager needs to cope with sessions throwing exception in read/write

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

StandardManager needs to cope with sessions throwing exception in read/write





--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 18:21 ---
Humm...  I gave this some more thought.  How about an extra layer of
abstraction.  Namely each session is serialized in memory, then the 
byte array is written to the object stream.  Thus unserializable sessions will
not be saved.  Also, when restoring sessions if a session cannot be
de-serialized (missing clases or whatever), the next session in the stream can
still be read and restored.   What do you think?

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

DO NOT REPLY [Bug 6671] - Simple custom tag example uses old declaration style

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

Simple custom tag example uses old declaration style





--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 18:33 ---

Hey, can someone review/apply this?

Cheers,
-bob

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

DO NOT REPLY [Bug 9961] - JSTL core tag forEach does not work for List

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

JSTL core tag forEach does not work for List

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 18:35 ---
I tried the attached test with the latest build of tomcat 4 (with jasper2), and
it worked.  I assumed this problem has been fixed with changes since 4.1.5
build.

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

Re: Proposal draft for Tomcat 5.0

[Amy Roh]

GOMEZ Henri wrote

>Tomcat 5.0 appears to be a way to have both teams
>works again together to make a better tomcat,
>which will be profitable to the whole jakarta 
>community.
>
+1  good comment.  :-)

>
>
>Tomcat 5.0 will be Coyote 2.0 based, a small and
>efficient core.
>
>The question shouldn't be to use Avalon as framework, 
>but how make tighers links between Avalon and TC 5.0.
>
>That core will link to catalina 2.0, jasper 3, 
>why not avalon 4 or 5 ? 
>
>Others goal of TC 5.0 will be to be faster than TC 3.3
>or 4.x, better integration with web-servers, better
>management via JMX.
>
>TC 5.0 is a normal evolution on works conducted on 
>TC 3.3 and 4.x, and a merge of ideas and commiters.
>
>That's not so bad.
>
I agree.

Amy

>
>
>-
>Henri Gomez ___[_]
>EMAIL : [EMAIL PROTECTED](. .) 
>PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>



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

DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace

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

Base64 decoder chokes on a whitespace





--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 18:49 ---
How about fixing the code in the Jakarta Commons Sandbox Codec package's Base64
class?  It's what the decoders in both Tomcat 4 and XML-RPC are based on
(perhaps there are minor differences now?).

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

DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace

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

Base64 decoder chokes on a whitespace





--- Additional Comments From [EMAIL PROTECTED]  2002-06-21 19:01 ---
The (unverified) problem with the Base64 class would applies to the versions in
the HttpClient and Codec components.

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

Re: Proposal draft for Tomcat 5.0 : #2 Tradeoffs

[Christopher K. St. John]

 Ok, second round.

 People are +1'ing the _goals_ of the proposal, but I
the proposal itself doesn't give sufficient detail to
determine if the recommended actions will actually 
lead to those goals being accomplished.

 Some of the goals even appear to be contradictory,
but there's no discussion of the inevitable engineering
tradeoffs. Simplicity vs Flexibility is a big issue.

 For example, the Coyote framework is compatible with
Tomcat 3 and Tomcat 4. This is admirable, and may lead
to closer ties between the two groups of developers.

 BUT Coyote is also more complicated and harder to
understand than the HTTP connector code in Tomcat 4 that
it replaces. It does more, too, but let's face it, it's
an integrated framework for writing connectors, and
frameworks are harder to understand and build than
single-purpose code.

 That isn't to say it wasn't worth it, but you've gone
from only needing to understand o.a.c.connector to having
to understand a whole slew of packages and patterns and
conventions. There's more buy-in required.

 I'd like to see considerably more discussion about
tradeoffs before the proposal is approved.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

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

RE: Proposal draft for Tomcat 5.0

[Leo Simons]

On Fri, 21 Jun 2002, GOMEZ Henri wrote:
> I hope that Tomcat 5.0 proposal draft won't turn in
> a battle or flame war between Tomcat and Avalon commiters.

+1.

The avalon developers think that avalon is pretty much very cool, as do
some other people at apache. It's a healthy jakarta project that's
growing in acceptance at a steady pace, and it has been like that for
quite some time.

The same is true -- to say the least -- for tomcat.

(...)

If the people that develop tomcat do not think that avalon is cool,
there is absolutely no problem if they decide not to use it in tomcat 5.
Some  (probably a lot) of the people that use avalon might consider that
to be a pity, but that's okay.

If avalon is really as cool as the avalon people believe it is, tomcat 7
(or whatever) will probably support the services JSR. If it is not,
well, tomcat does what it does pretty well.

One thing I do ask: please be considerate of your avalon fellow
developers, and factual in commenting on avalon on this list, as bad
publicity here can have big consequences.

regards,

- Leo Simons,
avalon committer


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

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config context.xml

[amyroh]

amyroh  2002/06/21 12:19:52

  Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin
ApplicationResources_es.properties
   webapps/tomcat-docs/config context.xml
  Log:
  Add messages to support admin webapp in espanol.  Fix minor typo.
  
  Revision  ChangesPath
  1.53  +34 -16
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties
  
  Index: ApplicationResources_es.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties,v
  retrieving revision 1.52
  retrieving revision 1.53
  diff -u -r1.52 -r1.53
  --- ApplicationResources_es.properties30 May 2002 19:42:23 -  1.52
  +++ ApplicationResources_es.properties21 Jun 2002 19:19:52 -  1.53
  @@ -264,6 +264,8 @@
   # -- Resources Module --
   resources.treeBuilder.subtreeNode=Recursos
   resources.treeBuilder.datasources=Fuentes De Datos
  +resources.treeBuilder.mailsessions=Sesiones Del Correo
  +resources.treeBuilder.resourcelinks=Acoplamientos Del Recurso
   resources.env.entries=Entradas Del Ambiente
   resources.env.entry=Nombre De la Entrada
   resources.env.props=Caracteristicas De la Entrada Del Ambiente
  @@ -274,9 +276,9 @@
   resources.actions.env.list=Entradas Existentes De la Lista
   resources.datasrc.jdbc=JDBC Driver
   resources.actions.datasrc=Datasources
  -resources.actions.datasrc.create=Cree Datasource Nuevo
  -resources.actions.datasrc.delete=Cancelacion Datasources
  -resources.actions.datasrc.edit=Edit Datasource
  +resources.actions.datasrc.create=Cree La Nueva Fuente De Datos
  +resources.actions.datasrc.delete=Fuentes De Datos De la Cancelación
  +resources.actions.datasrc.edit=Corrija La Fuente De Datos
   resources.datasrc.url=Datasource URL
   resources.datasrc.jdbcclass=JDBC Driver Class
   resources.datasrc.connections=Conexiones
  @@ -285,23 +287,39 @@
   resources.datasrc.wait=Max. Espera para la conexion
   resources.datasrc.validation=Validation Query
   resources.datasrc.jndi=JNDI Name
  +resources.actions.mailsession=Sesiones Del Correo
  +resources.actions.mailsession.create=Cree La Nueva Sesión Del Correo
  +resources.actions.mailsession.delete=Sesión Del Correo De la Cancelación
  +resources.actions.mailsession.edit=Corrija La Sesión Del Correo
  +resources.mailsession.name=Nombre
  +resources.mailsession.mailhost=mail.smtp.host
  +resources.actions.resourcelk=Acoplamientos Del Recurso
  +resources.actions.resourcelk.create=Cree El Nuevo Acoplamiento Del Recurso
  +resources.actions.resourcelk.delete=Acoplamiento Del Recurso De la Cancelación
  +resources.actions.resourcelk.edit=Corrija El Acoplamiento Del Recurso
  +resources.resourcelk.name=Nombre
  +resources.resourcelk.global=Global
  +resources.resourcelk.type=Tipo
   resources.error.name.required=Nombre requiredo.
  +resources.error.global.required=Global se requiere.
  +resources.error.type.required=Mecanografíe se requiere.
   resources.error.value.required=Value requiredo.
   resources.error.value.mismatch=El tipo y el valor no se parecen emparejar.
   resources.error.entryType.invalid=El tipo de la entrada no recognized.
  -resources.error.entryType.notimpl=Validation for this type not implemented 
yet.
  -resources.error.url.required=Datasource URL is required.
  -resources.error.driverClass.required=JDBC Driver Class is required.
  -resources.error.active.required=Max Active Connections is required.
  -resources.error.idle.required=Max Idle Connections is required.
  -resources.error.wait.required=Max Wait for a Connection is required.
  -resources.integer.error=Invalid integer error.
  -resources.actions.userdb.create=Create New User Database
  -resources.actions.userdb.edit=Edit User Database
  -resources.actions.userdb.delete=Delete User Databases
  -resources.userdb.location=Location
  -resources.userdb.factory=Factory
  -resources.treeBuilder.userdbs=User Databases
  +resources.error.entryType.notimpl=Validación para este tipo no puesto en 
ejecucio'n todavía.
  +resources.error.url.required=Se requiere el URL de Datasource.
  +resources.error.driverClass.required=Se requiere la clase del conductor de 
JDBC.
  +resources.error.active.required=Se requieren las conexiones activas 
máximas.
  +resources.error.idle.required=Se requieren las conexiones ociosas máximas.
  +resources.error.wait.required=La espera máxima para una conexión se 
requiere.
  +resources.error.mailhost.required=mail.smtp.host is required.
  +resources.integer.error=Error inválido del número entero.
  +resources.actions.userdb.create=Cree La Nueva Base de datos Del Usuario
  +resources.actions.userdb.edit=Corrija La Base de datos Del Usuario
  +resources.actions.userdb.delete=Bases de datos Del Usuario De la Cancelación
  +resources.userdb.location=Localización
  +res

Re: Proposal draft for Tomcat 5.0 : #2 Tradeoffs

[costinm]

On Fri, 21 Jun 2002, Christopher K.  St.  John wrote:

>  People are +1'ing the _goals_ of the proposal, but I
> the proposal itself doesn't give sufficient detail to
> determine if the recommended actions will actually 
> lead to those goals being accomplished.

That's exactly the target - to set the goals and the overal
direction ( it's a 'long-term plan' ). Each particular
detail will be discussed and revisited many times during the 
implementation stage. 


>  Some of the goals even appear to be contradictory,
> but there's no discussion of the inevitable engineering
> tradeoffs. Simplicity vs Flexibility is a big issue.

The goal seems to be to get more flexibility and a simpler
core. I seen no contradiction here - our experience so far
seems to indicate that by reducing complexity you gain
more flexibility.


>  For example, the Coyote framework is compatible with
> Tomcat 3 and Tomcat 4. This is admirable, and may lead
> to closer ties between the two groups of developers.

>  BUT Coyote is also more complicated and harder to
> understand than the HTTP connector code in Tomcat 4 that
> it replaces. It does more, too, but let's face it, it's
> an integrated framework for writing connectors, and
> frameworks are harder to understand and build than
> single-purpose code.

Coyote is not a framework for writing connectors - it defines
the base objects and a hook mechanism. 

It is not perfect - and one of the goals is to improve it
in tomcat5. But most of the stuff is needed to get decent
performance - and to be able to support other protocols
and have better integration with the server.

There are many things that are hard or impossible with o.a.ajp.

>  That isn't to say it wasn't worth it, but you've gone
> from only needing to understand o.a.c.connector to having
> to understand a whole slew of packages and patterns and
> conventions. There's more buy-in required.



What do you mean 'only o.a.c.connector' ? There are few dozens
interfaces and classes you must understand, and the point is
you can't get too much performance without good buffer management,
byte[], optimized conversions, etc. 

Costin



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

Re: Jasper2: serious problem with tag declarations

[Remy Maucherat]

Jan Luehe wrote:
> Hi Costin,
> 
> 
>>But there is still a problem - now if you have:
>>   
>>  
>>
>>  
>>  
>>
>>( i.e. the same variable name ), it will fail with duplicated declaration, 
>>the code will be: 
>>   Object i;
>>   ...
>>   Object i;
>>
>>( id is nested ).
> 
> 
> The above code fragment compiles fine for me.
> I've attached the generated servlet code.
> 
> Can you send me the exact page you are trying to run?
> If you could provide the generated code, that would help, too.

If those variable declaration problems are fixed, I'll release a new 
4.1.6 milestone as soon as I can fix the JNDI problems.

Thanks,
Remy


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

cvs commit: jakarta-tomcat-4.0/webapps/admin/images ResourceLink.gif

[amyroh]

amyroh  2002/06/21 12:45:27

  Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin
TomcatTreeBuilder.java
  Added:   webapps/admin/images ResourceLink.gif
  Log:
  Add Resource Link image for admin webapp.
  
  Revision  ChangesPath
  1.34  +5 -5  
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java
  
  Index: TomcatTreeBuilder.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- TomcatTreeBuilder.java21 Jun 2002 00:40:59 -  1.33
  +++ TomcatTreeBuilder.java21 Jun 2002 19:45:27 -  1.34
  @@ -494,7 +494,7 @@
   false);
   TreeControlNode resourcelinks = new TreeControlNode
   ("Resource Links " + containerName,
  -"Datasource.gif",
  +"ResourceLink.gif",
   resources.getMessage("resources.treeBuilder.resourcelinks"),
   "resources/listResourceLinks.do?resourcetype=" + 
   URLEncoder.encode(type) + "&path=" +
  
  
  
  1.1  jakarta-tomcat-4.0/webapps/admin/images/ResourceLink.gif
  
<>
  
  

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

Re: Proposal draft for Tomcat 5.0 : #2 Tradeoffs

[Christopher K. St. John]

[EMAIL PROTECTED] wrote:
> 
> On Fri, 21 Jun 2002, Christopher K.  St.  John wrote:
> 
> >  People are +1'ing the _goals_ of the proposal, but I
> > the proposal itself doesn't give sufficient detail ...
> 
> That's exactly the target - to set the goals and the overal
> direction ( it's a 'long-term plan' ).
>

 The proposal lists a set of goals (like "simpler" and
"more flexibile") and a set of actions to acheive those
goals (like "make Coyote the core of Tomcat 5").

 I (more or less) agree with the goals, but I have some
reservations about the proposed course of action.

 I would hope that many others on this list would also
have questions, since the proposal itself is too vague to 
base a decision on. (Although your answers to my questions
are helping, thanks)


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

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

Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config context.xml

[Amy Roh]

Please feel free to edit these spanish messages if you're a spanish 
speaker and find these messages incorrect.  

My three years in high school spanish doesn't seem to be good enough 
since I highly depended on a translation engine. (I don't know how 
accurate they are)  ;-)

Gracias!

Amy

[EMAIL PROTECTED] wrote:

>amyroh  2002/06/21 12:19:52
>
>  Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin
>ApplicationResources_es.properties
>   webapps/tomcat-docs/config context.xml
>  Log:
>  Add messages to support admin webapp in espanol.  Fix minor typo.
>  
>  Revision  ChangesPath
>  1.53  +34 -16
>jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties
>  
>  Index: ApplicationResources_es.properties
>  ===
>  RCS file: 
>/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties,v
>  retrieving revision 1.52
>  retrieving revision 1.53
>  diff -u -r1.52 -r1.53
>  --- ApplicationResources_es.properties   30 May 2002 19:42:23 -  1.52
>  +++ ApplicationResources_es.properties   21 Jun 2002 19:19:52 -  1.53
>  @@ -264,6 +264,8 @@
>   # -- Resources Module --
>   resources.treeBuilder.subtreeNode=Recursos
>   resources.treeBuilder.datasources=Fuentes De Datos
>  +resources.treeBuilder.mailsessions=Sesiones Del Correo
>  +resources.treeBuilder.resourcelinks=Acoplamientos Del Recurso
>   resources.env.entries=Entradas Del Ambiente
>   resources.env.entry=Nombre De la Entrada
>   resources.env.props=Caracteristicas De la Entrada Del Ambiente
>  @@ -274,9 +276,9 @@
>   resources.actions.env.list=Entradas Existentes De la Lista
>   resources.datasrc.jdbc=JDBC Driver
>   resources.actions.datasrc=Datasources
>  -resources.actions.datasrc.create=Cree Datasource Nuevo
>  -resources.actions.datasrc.delete=Cancelacion Datasources
>  -resources.actions.datasrc.edit=Edit Datasource
>  +resources.actions.datasrc.create=Cree La Nueva Fuente De Datos
>  +resources.actions.datasrc.delete=Fuentes De Datos De la Cancelación
>  +resources.actions.datasrc.edit=Corrija La Fuente De Datos
>   resources.datasrc.url=Datasource URL
>   resources.datasrc.jdbcclass=JDBC Driver Class
>   resources.datasrc.connections=Conexiones
>  @@ -285,23 +287,39 @@
>   resources.datasrc.wait=Max. Espera para la conexion
>   resources.datasrc.validation=Validation Query
>   resources.datasrc.jndi=JNDI Name
>  +resources.actions.mailsession=Sesiones Del Correo
>  +resources.actions.mailsession.create=Cree La Nueva Sesión Del Correo
>  +resources.actions.mailsession.delete=Sesión Del Correo De la Cancelación
>  +resources.actions.mailsession.edit=Corrija La Sesión Del Correo
>  +resources.mailsession.name=Nombre
>  +resources.mailsession.mailhost=mail.smtp.host
>  +resources.actions.resourcelk=Acoplamientos Del Recurso
>  +resources.actions.resourcelk.create=Cree El Nuevo Acoplamiento Del Recurso
>  +resources.actions.resourcelk.delete=Acoplamiento Del Recurso De la Cancelación
>  +resources.actions.resourcelk.edit=Corrija El Acoplamiento Del Recurso
>  +resources.resourcelk.name=Nombre
>  +resources.resourcelk.global=Global
>  +resources.resourcelk.type=Tipo
>   resources.error.name.required=Nombre requiredo.
>  +resources.error.global.required=Global se requiere.
>  +resources.error.type.required=Mecanografíe se requiere.
>   resources.error.value.required=Value requiredo.
>   resources.error.value.mismatch=El tipo y el valor no se parecen emparejar.
>   resources.error.entryType.invalid=El tipo de la entrada no recognized.
>  -resources.error.entryType.notimpl=Validation for this type not implemented 
>yet.
>  -resources.error.url.required=Datasource URL is required.
>  -resources.error.driverClass.required=JDBC Driver Class is required.
>  -resources.error.active.required=Max Active Connections is required.
>  -resources.error.idle.required=Max Idle Connections is required.
>  -resources.error.wait.required=Max Wait for a Connection is required.
>  -resources.integer.error=Invalid integer error.
>  -resources.actions.userdb.create=Create New User Database
>  -resources.actions.userdb.edit=Edit User Database
>  -resources.actions.userdb.delete=Delete User Databases
>  -resources.userdb.location=Location
>  -resources.userdb.factory=Factory
>  -resources.treeBuilder.userdbs=User Databases
>  +resources.error.entryType.notimpl=Validación para este tipo no puesto en 
>ejecucio'n todavía.
>  +resources.error.url.required=Se requiere el URL de Datasource.
>  +resources.error.driverClass.required=Se requiere la clase del conductor de 
>JDBC.
>  +resources.error.active.required=Se requieren las conexiones activas 
>máximas.
>  +resources.error.idle.required=Se requieren las conexiones ociosas máximas.
>  +resources.error.wait.required=La espera máxima para una conexión se 
>re

Re: Jasper2: serious problem with tag declarations

[costinm]

On Fri, 21 Jun 2002, Remy Maucherat wrote:

> If those variable declaration problems are fixed, I'll release a new 
> 4.1.6 milestone as soon as I can fix the JNDI problems.

Not yet...

I attached the failed jsp.

Costin


package JspServ;

import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import org.apache.jasper.runtime.*;

public class b$jsp extends HttpJspBase {


  private static java.util.Vector _jspx_includes;

  private org.apache.jasper.runtime.TagHandlerPool 
_jspx_tagPool_logic_iterate_property_name_id;
  private org.apache.jasper.runtime.TagHandlerPool _jspx_tagPool_logic_present_name;

  public b$jsp() {
_jspx_tagPool_logic_iterate_property_name_id = new 
org.apache.jasper.runtime.TagHandlerPool();
_jspx_tagPool_logic_present_name = new org.apache.jasper.runtime.TagHandlerPool();
  }

  public java.util.List getIncludes() {
return _jspx_includes;
  }

  public void jspDestroy() {
_jspx_tagPool_logic_iterate_property_name_id.release();
_jspx_tagPool_logic_present_name.release();
  }

  public void _jspService(HttpServletRequest request, HttpServletResponse response)
throws java.io.IOException, ServletException {

JspFactory _jspxFactory = null;
javax.servlet.jsp.PageContext pageContext = null;
HttpSession session = null;
ServletContext application = null;
ServletConfig config = null;
JspWriter out = null;
Object page = this;
JspWriter _jspx_out = null;


try {
  _jspxFactory = JspFactory.getDefaultFactory();
  response.setContentType("text/html;ISO-8859-1");
  pageContext = _jspxFactory.getPageContext(this, request, response,
null, true, 8192, true);
  application = pageContext.getServletContext();
  config = pageContext.getServletConfig();
  session = pageContext.getSession();
  out = pageContext.getOut();
  _jspx_out = out;

  out.write("\n");
  out.write("\n\n");
  /*   logic:iterate  */
  java.lang.Object a;
  org.apache.struts.taglib.logic.IterateTag _jspx_th_logic_iterate_0 = 
(org.apache.struts.taglib.logic.IterateTag) 
_jspx_tagPool_logic_iterate_property_name_id.get(org.apache.struts.taglib.logic.IterateTag.class);

  _jspx_th_logic_iterate_0.setPageContext(pageContext);
  _jspx_th_logic_iterate_0.setParent(null);
  _jspx_th_logic_iterate_0.setId("a");
  _jspx_th_logic_iterate_0.setName("foo");
  _jspx_th_logic_iterate_0.setProperty("bar");
  int _jspx_eval_logic_iterate_0 = _jspx_th_logic_iterate_0.doStartTag();
  if (_jspx_eval_logic_iterate_0 != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
if (_jspx_eval_logic_iterate_0 != 
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE) {
  javax.servlet.jsp.tagext.BodyContent _bc = pageContext.pushBody();
  _bc.clear();
  out = _bc;
  _jspx_th_logic_iterate_0.setBodyContent(_bc);
  _jspx_th_logic_iterate_0.doInitBody();
}
do {
  a = (java.lang.Object) pageContext.findAttribute("a");
  out.write("\n");
} while (_jspx_th_logic_iterate_0.doAfterBody() == 
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);
if (_jspx_eval_logic_iterate_0 != 
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE)
  out = pageContext.popBody();
  }
  if (_jspx_th_logic_iterate_0.doEndTag() == 
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;
  _jspx_tagPool_logic_iterate_property_name_id.reuse(_jspx_th_logic_iterate_0);
  out.write("\n\n");
  /*   logic:present  */
  org.apache.struts.taglib.logic.PresentTag _jspx_th_logic_present_0 = 
(org.apache.struts.taglib.logic.PresentTag) 
_jspx_tagPool_logic_present_name.get(org.apache.struts.taglib.logic.PresentTag.class);
  _jspx_th_logic_present_0.setPageContext(pageContext);
  _jspx_th_logic_present_0.setParent(null);
  _jspx_th_logic_present_0.setName("b");
  int _jspx_eval_logic_present_0 = _jspx_th_logic_present_0.doStartTag();
  if (_jspx_eval_logic_present_0 != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
do {
  out.write("\n");
  /*   logic:iterate  */
  java.lang.Object a;
  org.apache.struts.taglib.logic.IterateTag _jspx_th_logic_iterate_1 = 
(org.apache.struts.taglib.logic.IterateTag) 
_jspx_tagPool_logic_iterate_property_name_id.get(org.apache.struts.taglib.logic.IterateTag.class);

  _jspx_th_logic_iterate_1.setPageContext(pageContext);
  _jspx_th_logic_iterate_1.setParent(_jspx_th_logic_present_0);
  _jspx_th_logic_iterate_1.setId("a");
  _jspx_th_logic_iterate_1.setName("foo");
  _jspx_th_logic_iterate_1.setProperty("bar");
  int _jspx_eval_logic_iterate_1 = _jspx_th_logic_iterate_1.doStartTag();
  if (_jspx_eval_logic_iterate_1 != javax.servlet.jsp.tagext.Tag

Re: Proposal draft for Tomcat 5.0 : #2 Tradeoffs

[costinm]

On Fri, 21 Jun 2002, Christopher K.  St.  John wrote:

>  The proposal lists a set of goals (like "simpler" and
> "more flexibile") and a set of actions to acheive those
> goals (like "make Coyote the core of Tomcat 5").
> 
>  I (more or less) agree with the goals, but I have some
> reservations about the proposed course of action.

Can you expand a bit on this ? If you see another solution
I would be happy to hear it - prefereably before we start
working :-)

So far Coyote seems to have significant performance benefits
over the old connector, seems to be a 'common ground' for
a majority of developers - and is certainly a reasonably simple
API ( compared even with tomcat3.3 ).
I think with some changes in Action it can be made more flexible
than either 3.3 or 4.x, while keeping it simple. 

The whole idea of this proposal is to _agree_ on a small/manageable
core. Agreement is essential here, and I think everyone understand
that we must satisfy a whole range of requirements - and 
do what it takes to to get most people happy.

If you can clarify your concerns - do you disagree with Coyote 
entirely ( and why ), is it something missing that you want 
added or something that is there and you feel shouldn't ? 

Costin


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