Security Fixes ?

[Steffen Fries]

Hi,

just a short question, are all of the security vulnerabilties
listed under
http://securitytracker.com/archives/target/420.html are
fixed in the newest version?
Is there a general list which shows, which security bugs are 
fixed?

Regards

Steffen

___
Steffen Fries, Siemens AG, CT IC 3  
Otto-Hahn-Ring 6,  D-81730 Munich, Germany 
Phone:  (+49) 89 / 636-53403, Fax  :  (+49) 89 / 636-48000
Email:  [EMAIL PROTECTED]
___
This email was written on 100% recycled bytes!



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

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

[craigmcc]

craigmcc02/02/28 21:46:52

  Modified:webapps/tomcat-docs/config host.xml
  Log:
  Tweak the auto-deployment documentation to reflect the current
  functionality.
  
  Revision  ChangesPath
  1.9   +21 -15jakarta-tomcat-4.0/webapps/tomcat-docs/config/host.xml
  
  Index: host.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/host.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- host.xml  25 Oct 2001 00:38:49 -  1.8
  +++ host.xml  1 Mar 2002 05:46:52 -   1.9
  @@ -73,7 +73,9 @@
 
   This flag value indicates if web applications from this host should
   be automatically deployed by the host configurator.
  -The flag's value defaults to true.
  +The flag's value defaults to true.  See
  +Automatic Application
  +Deployment for more information.
 
   
 
  @@ -117,18 +119,21 @@
   Java class name of the error reporting valve which will be used
   by this Host. The responsability of this valve is to output error
   reports. Setting this property allows to customize the look of the
  -error pages which will be generated by Tomcat. This class must 
  -implement the 
  +error pages which will be generated by Tomcat. This class must
  +implement the
   org.apache.catalina.Valve interface. If none is specified,
  -the value org.apache.catalina.valves.ErrorReportValve 
  +the value org.apache.catalina.valves.ErrorReportValve
   will be used by default.
 
   
 
   Set to true if you want web applications that are
  -deployed into this virtual host from a Web Application Archive (WAR)
  -file to be unpacked into a disk directory structure, or
  -false to run the application directly from a WAR file.
  +placed in the appBase directory as web application
  +archive (WAR) files to be unpacked into a corresponding disk directory
  +structure, false to run such web applications directly
  +from a WAR file.  See
  +Automatic Application
  +Deployment for more information.
 
   
   
  @@ -215,6 +220,13 @@
   This behavior is enabled by setting the autoDeploy attribute
   to true (which is the default value):
   
  +Any XML file in this directory is assumed to contain a
  +Context element (and its associated
  +subelements) for a single web application.  The docBase
  +attribute of this  element will typically
  +be the absolute pathname to a web applicationd directory, or the
  +absolute pathname of a web application archive (WAR) file (which
  +will not be expanded).
   Any web application archive file that does not have a corresponding
   directory of the same name (without the ".war" extension) will be
   automatically expanded, unless the unpackWARs property
  @@ -232,19 +244,13 @@
   deployed Context will be a slash character ("/") followed by the
   directory name, unless the directory name is ROOT, in which case
   the context path will be an empty string ("").
  -Any XML file in this directory is assumed to contain a
  -Context element (and its associated
  -subelements) for a single web application.  The docBase
  -attribute of this  element will typically
  -be the absolute pathname to a web applicationd directory, or the
  -absolute pathname of a web application archive (WAR) file (which
  -will not be expanded).
   
   
   In addition to the automatic deployment that occurs at startup time,
   you can also add new WAR files, directory, or XML configuration files
   into the appBase directory at any time, and the corresponding
  -applications will be automatically deployed.
  +applications will be automatically deployed if the autoDeploy
  +property is set to true.
   
 
   
  
  
  

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

Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4CoyoteConnector.java CoyoteProcessor.java

[costinm]

On Thu, 28 Feb 2002, Remy Maucherat wrote:

> The request is slightly different at the moment, but that's because I don't
> know what I need (so sorry, I'm not using your BaseRequest for the first
> version). The Catalina adapter will be a full reimplementation of the
> o.a.c.connector package (which has issues), and will use facaded
> request/response objects.
> So I'm doing the optimization work for you here.

Thanks :-)

The Catalina adapter in jk is refactored and optimized a bit in jk2,
but I would be very happy to not have to spend time on this and I'm
sure you'll do a much better implementation for 4.0 :-) 

It would be nice to avoid too many layers/adapters, but for start
it would be resonably easy to implement a JkHandler that delegates
to your Request. 

For now this is not a major issue, the current code seems ok, but
in time it would be good to not duplicate the work, it's not
that much fun to optimize the same thing too many times :-)

Costin


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

Tyrex pooling issues (Tomcat 4.0.2)

[Brad Thompson]

I wanted to use tyrex to pool JNDI-acquired JDBC connections.  I have
attached a file called "diary" that explains how I ultimately got this
working.  Unfortunately, this required several undesirable things.  First,
I had to specify a tomcat-specific class (tyrex.jdbc.ServerDataSource)
in my web.xml.  Second, I had to patch the source to ResourceFactory.java
(patch attached in ResourceFactory-pool-patch).  Third, I had to muck
around with security polices, even though I wasn't running under a
security manager (this is a tyrex issue, not a tomcat one, so I'm not
going to go any farther with this).

The fundamental problem is that as far as I can tell, there is no way
to get tyrex to create a ServerDataSource without doing what I did.
The patch tells ResourceFactory to create a ServerDataSource (which
does pooling) instead of an EnabledDataSource (which does not) if the
web.xml-specified class is tyrex.jdbc.ServerDataSource.  It needs to
explicitly specified this way because of the logic around line 214
of TyrexDataSourceFactory.java.

So, I think the point of this mail is a feature request for a way to
specify that I want a ServerDataSource instead of an EnabledDataSource
when I ask tomcat to give me a javax.sql.DataSource resource.
The attached patch is suboptimal because it requires tomcat-specific
information in web.xml.

I do not know the tomcat source that well...my apologies if I am missing
something important.

brad


There is a postgresql server listening on its normal port on localhost.

Untar tomcat 4.0.2 binary and source distributions into /tmp.

Delete the contents of jakarta-tomcat-4.0.2/webapps.  Create webapps/ROOT
and webapps/ROOT/WEB-INF directories.  Install the attached test.jsp
and web.xml files in those directories, respectively.

Unjar jakarta-tomcat-4.0.2/lib/naming-factory.jar into /tmp.  Copy
jakarta-tomcat-4.0.2-src/catalina/src/share/org/apache/naming/factory/ResourceFactory.java
into /tmp/org/apache/naming/factory/.  Apply the attached
ResourceFactory-pool-patch.  Add naming-common.jar to your
classpath and build ResourceFactory.java with jikes.  Run "jar cf
jakarta-tomcat-4.0.2/lib/naming-factory.jar org".

su and add the following to /usr/lib/j2re1.3/lib/security/java.policy:

  grant {
permission java.security.AllPermission;
  };

Delete the demo contexts and add the following to the appropriate place
in jakarta-tomcat-4.0.2/conf/server.xml:

  


  
user

  
  
password

  
  
driverClassName
org.postgresql.Driver
  
  
driverName
jdbc:postgresql://localhost/test
  

  

Copy postgresql-7.2.jar and ots.jar into /tmp/jakarta-tomcat-4.0.2/common/lib.  
Run /tmp/jakarta-tomcat-4.0.2/bin/startup.sh.  I make about 1000
connections over the course of a couple seconds, and six connections to
postmaster (the PostgreSQL daemon) are made.


--- 
jakarta-tomcat-4.0.1-src/catalina/src/share/org/apache/naming/factory/ResourceFactory.java
  Mon Nov 12 21:02:48 2001
+++ org/apache/naming/factory/ResourceFactory.java  Thu Feb 28 21:21:50 2002
@@ -138,7 +138,7 @@
 }
 }
 } else {
-if (ref.getClassName().equals("javax.sql.DataSource")) {
+if (ref.getClassName().equals("javax.sql.DataSource") || 
+ref.getClassName().equals("tyrex.jdbc.ServerDataSource")){
 String javaxSqlDataSourceFactoryClassName =
 System.getProperty("javax.sql.DataSource.Factory",
Constants.TYREX_DATASOURCE_FACTORY);


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



  
jdbc/testref
tyrex.jdbc.ServerDataSource
Container
  




<%@ page import="java.sql.*" %>
<%@ page import="javax.sql.DataSource" %>
<%@ page import="javax.naming.InitialContext" %>
<%
  response.setContentType("text/plain");

  DataSource ds =
(DataSource)new InitialContext().lookup("java:comp/env/jdbc/testref");
  Connection conn = ds.getConnection();
  Statement stmt = conn.createStatement();
  ResultSet rs = stmt.executeQuery("SELECT user FROM userlist");
  while(rs.next())
out.println(rs.getString("user"));
  conn.close();
%>



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

DO NOT REPLY [Bug 6770] - Login not displayed if error page is specified for a 401

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

Login not displayed if error page is specified for a 401

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-03-01 04:04 ---
Yes, it doesn't work, as what the error page is doing is a forward. So your
error page is now in control, and probably doesn't set the headers / status
correctly (a thing only the realm can do). Using an error page on a 403 is a
good idea. On a 401, it just won't work.

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

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

[Remy Maucherat]

> On Thu, 28 Feb 2002, GOMEZ Henri wrote:
>
> > Do you think coyote could be ever used with Tomcat 3.3 ?
> > ie: works with JDK 1.1, support TC 3.3 via modules
>
> Again: tomcat3.3 _doesn't_ require all modules to support
> JDK1.1 ! The only requirement is to have the basic
> functionality ( of a servlet container ) working on JDK1.1,
> and we already have that.
>
> There are quite a few optional modules in 3.3 that require
> 1.2 - sandbox, thread loader, etc. As long as the
> core is JDK1.1 compatible, things are going to be ok.

Anyway, it should be JDK 1.1 compliant.

> > JK/JK2 are available for both TC 3.3/4.x, it could be fine to
> > have also a common HTTP connector for them and coyote seems
> > to be the perfect candidate :)
>
> Well, we already have 4 HTTP/1.1 connectors for 3.3 :-)

I think he meant *JAVA* HTTP/1.1 connectors here.
:-)

> But I agree it would be good if Coyote would share more with
> jk - right now they use the low level stuff, but it would
> be trivial to integrate them a bit more and share the
> same connector ( the Request impl. - which will require
> quite a bit of work to optimize for 4.x ).

The request is slightly different at the moment, but that's because I don't
know what I need (so sorry, I'm not using your BaseRequest for the first
version). The Catalina adapter will be a full reimplementation of the
o.a.c.connector package (which has issues), and will use facaded
request/response objects.
So I'm doing the optimization work for you here.

Remy


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

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

[craigmcc]

craigmcc02/02/28 19:04:44

  Modified:catalina/src/share/org/apache/catalina/core
StandardHostDeployer.java
   catalina/src/share/org/apache/catalina/servlets
ManagerServlet.java
   catalina/src/share/org/apache/catalina/startup
HostConfig.java
  Log:
  Restore the unpackWARs behavior (but only for WAR files in the appBase
  subdirectory) that was broken by previous changes to deployment and the
  Manager webapp's servlet.  The WAR-expansion logic was refactored from
  StandardHostDeployer to HostConfig, which is the only place that requires it.
  
  Applications that are added via the Manager webapp's "/install" or "/deploy"
  commands are *not* auto-expanded -- if you want your webapp to run from an
  unpacked directory, you should install an unpacked directory.
  
  NOTE:  You can also get auto-unpack service by simply dropping a WAR file
  into the appBase directory while Tomcat is running - a background thread
  will notice this and unpack it in the same way that startup works.
  
  NOTE:  As before, any auto-unpacked directory is *never* deleted, because
  the user has probably changed things and would be very annoyed if it was
  removed.
  
  I'm going to make a pass through the JavaDocs and the documentation files
  to make sure that they are all up to date with respect to the actual
  functionality.
  
  Revision  ChangesPath
  1.5   +32 -226   
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java
  
  Index: StandardHostDeployer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- StandardHostDeployer.java 27 Feb 2002 01:17:00 -  1.4
  +++ StandardHostDeployer.java 1 Mar 2002 03:04:43 -   1.5
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
 1.4 2002/02/27 01:17:00 craigmcc Exp $
  - * $Revision: 1.4 $
  - * $Date: 2002/02/27 01:17:00 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
 1.5 2002/03/01 03:04:43 craigmcc Exp $
  + * $Revision: 1.5 $
  + * $Date: 2002/03/01 03:04:43 $
*
* 
*
  @@ -94,7 +94,7 @@
* StandardHost implementation class.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.4 $ $Date: 2002/02/27 01:17:00 $
  + * @version $Revision: 1.5 $ $Date: 2002/03/01 03:04:43 $
*/
   
   public class StandardHostDeployer implements Deployer {
  @@ -206,9 +206,10 @@
* @exception IllegalStateException if the specified context path
*  is already attached to an existing web application
* @exception IOException if an input/output error was encountered
  - *  during install
  + *  during installation
*/
  -public void install(String contextPath, URL war) throws IOException {
  +public synchronized void install(String contextPath, URL war)
  +throws IOException {
   
   // Validate the format and state of our arguments
   if (contextPath == null)
  @@ -224,49 +225,23 @@
   throw new IllegalArgumentException
   (sm.getString("standardHost.warRequired"));
   
  -// Prepare the local variables we will require
  +// Calculate the document base for the new web application
  +host.log(sm.getString("standardHost.installing",
  +  contextPath, war.toString()));
   String url = war.toString();
   String docBase = null;
  -host.log(sm.getString("standardHost.installing", contextPath, url));
  -
  -// Expand a WAR archive into an unpacked directory if needed
  -// NOTE:  If the user supplies a "jar:file:" URL, assume that
  -// they do not want WAR expansion even if unpackWARs is set
  -if (host.isUnpackWARs() && !url.startsWith("jar:file:")) {
  -
  -if (url.startsWith("jar:"))
  -docBase = expand(war);
  -else if (url.startsWith("file://"))
  -docBase = url.substring(7);
  -else if (url.startsWith("file:"))
  -docBase = url.substring(5);
  -else
  -throw new IllegalArgumentException
  -(sm.getString("standardHost.warURL", url));
  -
  -// Make sure the document base directory exists and is readable
  -File docBaseDir = new File(docBase);
  -if (!docBaseDir.exists() || !docBaseDir.isDirectory() ||
  -!docBaseDir.canRead())
  -throw new IllegalArgumentException
  -

Re: [4.0.3] [VOTES] Upcoming release and security fix

[costinm]

On Thu, 28 Feb 2002, Remy Maucherat wrote:

> On the security problem reported yesterday, affecting the security manager
> sandboxing. We should:
> 
> A [] Make a full 4.0.3 (or 4.0.2a) release which would only include  the
> security fix
> B [+1] Make the security fix available as a binary patch for 4.0.2 (it would
> take the form of an archive to extract in $CATALINA_HOME, and would be
> *small*)
> C [] Accelerate the release schedule of 4.0.3, which would include the
> security fix, as well as fixes for other issues with 4.0.2 (with Beta 1 on
> 03/01 and Final on 03/08)
> 

> Multiple votes are acceptable. If there are other interesting possibilities,
> let me know.
> 
> My vote is 'B'.
> 
> In parallel, I'd like to release a first beta of 4.0.3 on 03/01 (depending
> on the vote on item 'C' above, the release cycle may be shorter or longer):
> 
> +1 [+1( jk part )] I support the release, and I will help
> +0 [ ] I support the release
> -0 [ ] I don't support the release
> -1 [ ] I'm against the release because:

Costin


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

RE: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4CoyoteConnector.java CoyoteProcessor.java

[costinm]

On Thu, 28 Feb 2002, GOMEZ Henri wrote:

> Do you think coyote could be ever used with Tomcat 3.3 ?
> ie: works with JDK 1.1, support TC 3.3 via modules 

Again: tomcat3.3 _doesn't_ require all modules to support
JDK1.1 ! The only requirement is to have the basic 
functionality ( of a servlet container ) working on JDK1.1,
and we already have that.

There are quite a few optional modules in 3.3 that require
1.2 - sandbox, thread loader, etc. As long as the 
core is JDK1.1 compatible, things are going to be ok.

> JK/JK2 are available for both TC 3.3/4.x, it could be fine to
> have also a common HTTP connector for them and coyote seems
> to be the perfect candidate :)

Well, we already have 4 HTTP/1.1 connectors for 3.3 :-) 
But I agree it would be good if Coyote would share more with
jk - right now they use the low level stuff, but it would
be trivial to integrate them a bit more and share the
same connector ( the Request impl. - which will require 
quite a bit of work to optimize for 4.x ). 

Costin


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

cvs commit: jakarta-tomcat-4.0 build.properties.sample BUILDING.txt

[remm]

remm02/02/28 17:48:14

  Modified:.build.properties.sample BUILDING.txt
  Log:
  - Various changes to the buld  instructions.
  - Submitted in part by Luc Vanlerberghe 
  
  Revision  ChangesPath
  1.32  +7 -5  jakarta-tomcat-4.0/build.properties.sample
  
  Index: build.properties.sample
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/build.properties.sample,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- build.properties.sample   23 Feb 2002 02:06:21 -  1.31
  +++ build.properties.sample   1 Mar 2002 01:48:14 -   1.32
  @@ -6,7 +6,7 @@
   # modules that Tomcat depends on.  Copy this file to "build.properties"
   # in the top-level source directory, and customize it as needed.
   #
  -# $Id: build.properties.sample,v 1.31 2002/02/23 02:06:21 remm Exp $
  +# $Id: build.properties.sample,v 1.32 2002/03/01 01:48:14 remm Exp $
   # -
   
   
  @@ -146,10 +146,10 @@
   jdbc20ext.jar=${jdbc20ext.lib}/jdbc2_0-stdext.jar
   
   
  -# - Java Management Extensions (JMX), JMX RI 1.0.1 or later or OpenJMX 1.0b2 or 
later -
  -jmx.home=${base.path}/openjmx-1.0
  +# - Java Management Extensions (JMX), JMX RI 1.0.1 or later or MX4J 1.0 or 
later -
  +jmx.home=${base.path}/mx4j-1.0
   jmx.lib=${jmx.home}/lib
  -jmx.jar=${jmx.lib}/openjmx.jar
  +jmx.jar=${jmx.lib}/mx4j.jar
   
   
   # - Java Secure Sockets Extension (JSSE), version 1.0.2 or later -
  @@ -183,12 +183,14 @@
   
   
   # - Struts, version 1.0.1 or later -
  -struts.home=${base.path}/jakarta-struts-1.0.1
  +struts.home=${base.path}/jakarta-struts-1.0.2
   struts.lib=${struts.home}/lib
   struts.jar=${struts.lib}/struts.jar
   
  +
   # - Tyrex Data Source, version 0.9.7 -
   tyrex.home=${base.path}/tyrex-0.9.7.0
   tyrex.lib=${tyrex.home}
   tyrex.jar=${tyrex.lib}/tyrex-0.9.7.0.jar
  +
   
  
  
  
  1.28  +62 -40jakarta-tomcat-4.0/BUILDING.txt
  
  Index: BUILDING.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/BUILDING.txt,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- BUILDING.txt  20 Feb 2002 01:07:34 -  1.27
  +++ BUILDING.txt  1 Mar 2002 01:48:14 -   1.28
  @@ -1,4 +1,4 @@
  -$Id: BUILDING.txt,v 1.27 2002/02/20 01:07:34 remm Exp $
  +$Id: BUILDING.txt,v 1.28 2002/03/01 01:48:14 remm Exp $
   
   
  Building The Tomcat 4.0 Servlet/JSP Container
  @@ -73,8 +73,28 @@
   * Make the "xalan.jar" file of this distribution available to Ant (so that
 it can be used with the 

DO NOT REPLY [Bug 6769] - Regexp (required) is missing from BUILDING.txt

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

Regexp (required) is missing from BUILDING.txt

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-03-01 01:48 ---
Fixed.

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

cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[larryi]

larryi  02/02/28 17:35:34

  Modified:.RELEASE-PLAN-3.3.1.txt
  Log:
  Bring up to date.
  
  Revision  ChangesPath
  1.7   +15 -9 jakarta-tomcat/RELEASE-PLAN-3.3.1.txt
  
  Index: RELEASE-PLAN-3.3.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3.1.txt,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- RELEASE-PLAN-3.3.1.txt19 Feb 2002 19:17:56 -  1.6
  +++ RELEASE-PLAN-3.3.1.txt1 Mar 2002 01:35:34 -   1.7
  @@ -89,33 +89,39 @@
Item  Description 
   1  Update build.xml to work with Ant 1.4 with no warnings, i.e.
  require Ant 1.4.
  +   DONE
   2  Document special handling of '_' and '.' by AutoWebApp.
  Make special characters configurable.
  +   DONE
   
  -
  -Bugs to fix:
  -5532  underscore is wrong (fixed by item 2 above)
  -
  +Addressed
   4206  missing config files do not cause an error
 (add error or warning messages)
  +  Resolved as FIXED
  +
  +4365  build-solaris for Apache connector does not compile with -DE
  +  (do what we can to review and update the connector make files)
  +  Resolved as FIXED
  +
  +5532  underscore is wrong (fixed by item 2 above)
  +  Resolved as FIXED
   
   5769  NT Service display name should not be used as service name
 (determine solution and patch)
   
  -4364  build-solaris for Apache connector does not compile with -DE
  -  (do what we can to review and update the connector make files)
  +6448  NullPointerException when docBase is missing
  +  (implement better error handling)
  +  Resolved as LATER
   
   6214  Problems on ClientAuth
 (fix documentation to indicate PoolTcpConnector's attribute
  is clientauth, not clientAuth)
   
  -6448  NullPointerException when docBase is missing
  -  (implement better error handling)
  -
   6518  class name generated from jsp filename mangles some valid
 identifier characters
 (derive patch from the one supplied and Tomcat 4.x
  implementation)
  +  Resolved as FIXED
   
   
   Tomcat 3.3.1 Final Release:
  
  
  

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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java

[larryi]

larryi  02/02/28 17:34:22

  Modified:src/share/org/apache/tomcat/core ContextManager.java
  Log:
  Update for 3.3.1-rc1
  
  Revision  ChangesPath
  1.202 +1 -1  
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
  
  Index: ContextManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
  retrieving revision 1.201
  retrieving revision 1.202
  diff -u -r1.201 -r1.202
  --- ContextManager.java   14 Feb 2002 14:23:43 -  1.201
  +++ ContextManager.java   1 Mar 2002 01:34:21 -   1.202
  @@ -148,7 +148,7 @@
   public class ContextManager {
   /** Official name and version
*/
  -public static final String TOMCAT_VERSION = "3.3.1 Dev";
  +public static final String TOMCAT_VERSION = "3.3.1 Release Candidate 1";
   public static final String TOMCAT_NAME = "Tomcat Web Server";
   
   /** System property used to set the base directory ( tomcat home ).
  
  
  

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

cvs commit: jakarta-tomcat/src/webpages index.html

[larryi]

larryi  02/02/28 17:33:47

  Modified:src/webpages index.html
  Log:
  Update for 3.3.1-rc1
  
  Revision  ChangesPath
  1.24  +2 -2  jakarta-tomcat/src/webpages/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/webpages/index.html,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- index.html14 Feb 2002 14:23:28 -  1.23
  +++ index.html1 Mar 2002 01:33:47 -   1.24
  @@ -4,13 +4,13 @@
   
   
   
  -Tomcat v3.3.1 Dev
  +Tomcat v3.3.1 Release Candidate 1
   
   
   Tomcat 
   
   Version
  -3.3.1 Dev
  +3.3.1 Release Candidate 1
   This is the default Tomcat home page. This page serves as a quick reference
   guide to related resources and is located at:
   
  
  
  

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

cvs commit: jakarta-tomcat/src/doc readme-3.3.1

[larryi]

larryi  02/02/28 17:32:07

  Modified:src/doc  readme-3.3.1
  Log:
  Update for 3.3.1-rc1
  
  Revision  ChangesPath
  1.2   +167 -111  jakarta-tomcat/src/doc/readme-3.3.1
  
  Index: readme-3.3.1
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/readme-3.3.1,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- readme-3.3.1  14 Feb 2002 14:25:53 -  1.1
  +++ readme-3.3.1  1 Mar 2002 01:32:06 -   1.2
  @@ -1,4 +1,4 @@
  -$Id: readme-3.3.1,v 1.1 2002/02/14 14:25:53 larryi Exp $
  +$Id: readme-3.3.1,v 1.2 2002/03/01 01:32:06 larryi Exp $
   
  Release Notes for:
  ===
  @@ -7,101 +7,103 @@
   
   
   This document describes the changes that have been made since the
  -last release of Tomcat 3.3.
  +release of Tomcat 3.3 Final.
   
   =
   Bug Fixes
   =
   
  +The release in which the fix appears is indicated in brackets.
  +
   Feature Additions:
   
   Bug No.  Description
   
  - Restored prefix attribute to InvokerInterceptor.  It was available in
  +[b1] Restored prefix attribute to InvokerInterceptor.  It was available in
Tomcat 3.2.x.
   
  - Added SingleThreadModel pooling to ServletHandler.  The default is to
  +[b1] Added SingleThreadModel pooling to ServletHandler.  The default is to
use pooling.
   
  - Added optional checking (configured on SessionId module) to ensure
  +[b1] Added optional checking (configured on SessionId module) to ensure
that the SSL session IDs match for each request within a Tomcat
session.  This check is disabled by default.
   
  - Added org.apache.tomcat.util.net.URL class from Tomcat 4.0 so
  +[b1] Added org.apache.tomcat.util.net.URL class from Tomcat 4.0 so
response.encodeURL() can work under SSL without JSSE.  This can occur
if you have Apache forwarding SSL requests to a Tomcat that doesn't
have JSSE installed.
   
  -  Fixed logic for response.encodeURL() so that it will work correctly 
  -  if the input URL includes an anchor tag.
  +[b1] Fixed logic for response.encodeURL() so that it will work correctly 
  + if the input URL includes an anchor tag.
   
  -  Improved the handling of invalid web.xml files.  Now you get the same
  -  error messages every time you parse the file.
  +[b1] Improved the handling of invalid web.xml files.  Now you get the same
  + error messages every time you parse the file.
   
  -  Moved the setting of the default "*.jsp" mapping so that it is now 
  -  possible to entirely disable support for jsp files.
  +[b1] Moved the setting of the default "*.jsp" mapping so that it is now 
  + possible to entirely disable support for jsp files.
   
  -  Fixed problem with jsp_precompile parameter to JSP files.
  +[b1] Fixed problem with jsp_precompile parameter to JSP files.
   
  - Context properties and ContextManager properties can now be set with
  +[b1] Context properties and ContextManager properties can now be set with
 elements, i.e: 

For backwards compatibility, the ContextManager "lower-case-p"
 version supported by Tomcat 3.3. is still supported.
   
  - Added variable substitution handling to ContextXmlReader, allowing
  +[b1] Added variable substitution handling to ContextXmlReader, allowing
variable substitution to be used in 
declarations.
   
  -  Added support for PureTLS as an SSL option.  Also, any attribute
  +[b1] Added support for PureTLS as an SSL option.  Also, any attribute
used to create the socket factory, such as "rootfile" (or
"keystoreType" for JSSE), is now settable on the Http10Connector
element in server.xml.
   
  - The configuration files generated by ApacheConfig, IISConfig and
  +[b1] The configuration files generated by ApacheConfig, IISConfig and
NSConfig were improved for the case when the forwardAll attribute
is false. Primarily, a servlet mapping like "/foo/*" now generates
a mod_jk mapping for "/foo" as well as "/foo/*" to better match
the servlet spec.
   
  - The default log handler was updated to specify autoFlush=true for
  +[b1] The default log handler was updated to specify autoFlush=true for
the PrintWriter so the output doesn't just go to a buffer.  Since
this logger is replaced a new logger set by the LogSetter module,
its reduction in efficiency won't affect normal operation.
   
  - ServerXmlReader now logs a warning if the modules.xml file isn't
  +[b1] ServerXmlReader now logs a warning if the modules.xml f

cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.1.txt

[larryi]

larryi  02/02/28 17:31:26

  Modified:.RELEASE-NOTES-3.3.1.txt
  Log:
  Identify release for each fix.  Also rearranged by bug number or lack of one.
  Documented some additional documentation fixes.
  
  Revision  ChangesPath
  1.43  +148 -122  jakarta-tomcat/RELEASE-NOTES-3.3.1.txt
  
  Index: RELEASE-NOTES-3.3.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.1.txt,v
  retrieving revision 1.42
  retrieving revision 1.43
  diff -u -r1.42 -r1.43
  --- RELEASE-NOTES-3.3.1.txt   28 Feb 2002 03:45:30 -  1.42
  +++ RELEASE-NOTES-3.3.1.txt   1 Mar 2002 01:31:26 -   1.43
  @@ -3,106 +3,107 @@
Release Notes
=
   
  -$Id: RELEASE-NOTES-3.3.1.txt,v 1.42 2002/02/28 03:45:30 larryi Exp $
  +$Id: RELEASE-NOTES-3.3.1.txt,v 1.43 2002/03/01 01:31:26 larryi Exp $
   
   
   This document describes the changes that have been made since the
  -last release of Tomcat 3.3.
  +release of Tomcat 3.3 Final.
   
   =
   Bug Fixes
   =
   
  +The release in which the fix appears is indicated in brackets.
  +
   Feature Additions:
   
   Bug No.  Description
   
  - Restored prefix attribute to InvokerInterceptor.  It was available in
  +[b1] Restored prefix attribute to InvokerInterceptor.  It was available in
Tomcat 3.2.x.
   
  - Added SingleThreadModel pooling to ServletHandler.  The default is to
  +[b1] Added SingleThreadModel pooling to ServletHandler.  The default is to
use pooling.
   
  - Added optional checking (configured on SessionId module) to ensure
  +[b1] Added optional checking (configured on SessionId module) to ensure
that the SSL session IDs match for each request within a Tomcat
session.  This check is disabled by default.
   
  - Added org.apache.tomcat.util.net.URL class from Tomcat 4.0 so
  +[b1] Added org.apache.tomcat.util.net.URL class from Tomcat 4.0 so
response.encodeURL() can work under SSL without JSSE.  This can occur
if you have Apache forwarding SSL requests to a Tomcat that doesn't
have JSSE installed.
   
  -  Fixed logic for response.encodeURL() so that it will work correctly 
  -  if the input URL includes an anchor tag.
  +[b1] Fixed logic for response.encodeURL() so that it will work correctly 
  + if the input URL includes an anchor tag.
   
  -  Improved the handling of invalid web.xml files.  Now you get the same
  -  error messages every time you parse the file.
  +[b1] Improved the handling of invalid web.xml files.  Now you get the same
  + error messages every time you parse the file.
   
  -  Moved the setting of the default "*.jsp" mapping so that it is now 
  -  possible to entirely disable support for jsp files.
  +[b1] Moved the setting of the default "*.jsp" mapping so that it is now 
  + possible to entirely disable support for jsp files.
   
  -  Fixed problem with jsp_precompile parameter to JSP files.
  +[b1] Fixed problem with jsp_precompile parameter to JSP files.
   
  - Context properties and ContextManager properties can now be set with
  +[b1] Context properties and ContextManager properties can now be set with
 elements, i.e: 

For backwards compatibility, the ContextManager "lower-case-p"
 version supported by Tomcat 3.3. is still supported.
   
  - Added variable substitution handling to ContextXmlReader, allowing
  +[b1] Added variable substitution handling to ContextXmlReader, allowing
variable substitution to be used in 
declarations.
   
  -  Added support for PureTLS as an SSL option.  Also, any attribute
  +[b1] Added support for PureTLS as an SSL option.  Also, any attribute
used to create the socket factory, such as "rootfile" (or
"keystoreType" for JSSE), is now settable on the Http10Connector
element in server.xml.
   
  - The configuration files generated by ApacheConfig, IISConfig and
  +[b1] The configuration files generated by ApacheConfig, IISConfig and
NSConfig were improved for the case when the forwardAll attribute
is false. Primarily, a servlet mapping like "/foo/*" now generates
a mod_jk mapping for "/foo" as well as "/foo/*" to better match
the servlet spec.
   
  - The default log handler was updated to specify autoFlush=true for
  +[b1] The default log handler was updated to specify autoFlush=true for
the PrintWriter so the output doesn't just go to a buffer.  Since
this logger is replaced a new logger set by the LogSetter module,
its reduction in efficiency won't affect normal ope

DO NOT REPLY [Bug 6762] - WebappClassLoader: Lifecycle error : CL stopped

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

WebappClassLoader: Lifecycle error : CL stopped





--- Additional Comments From [EMAIL PROTECTED]  2002-03-01 00:56 ---
Thanks Remy

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

Re: more information about bug 6704 (rmi in jsp)

[Hugh J. L.]

yes. i tried. that is the problem. too many server
session objects are created before any session
expires. web stress tool's automatic cookie doesn't
work well with tomcat so we don't use it in testing.

i just wonder why this problem only causes port
problem. when we integrate tomcat into our system,
configure multi-port and multi-context for the same
jsp, after one port gets down due to this problem,
other ports and the entire tomcat still work well.

anyway, this is not a tomcat bug.

thank you, Bill.


__
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c

[costin]

costin  02/02/28 16:45:58

  Modified:jk/native2/common jk_registry.h jk_uriMap.c
jk_worker_status.c
   jk/native2/include jk_uriEnv.h
   jk/native2/server/apache13 mod_jk2.c
   jk/native2/server/apache2 mod_jk2.c
  Added:   jk/native2/common jk_uriEnv.c
  Log:
  Move the uriEnv code in a separate object.
  
  Fix jk2 for apache1.3 ( again, compiles - I haven't tested it yet ).
  
  Few more fixes.
  
  Revision  ChangesPath
  1.8   +8 -1  jakarta-tomcat-connectors/jk/native2/common/jk_registry.h
  
  Index: jk_registry.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_registry.h,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- jk_registry.h 21 Feb 2002 11:12:11 -  1.7
  +++ jk_registry.h 1 Mar 2002 00:45:58 -   1.8
  @@ -62,7 +62,7 @@
   
   /***
* Description: Worker list*
  - * Version: $Revision: 1.7 $   *
  + * Version: $Revision: 1.8 $   *
***/
   
   /** Static declarations for all 'hardcoded' modules. This is a hack, 
  @@ -154,3 +154,10 @@
   int JK_METHOD jk2_handler_response_factory(jk_env_t *env, jk_pool_t *pool,
  void **result,
  const char *type, const char *name);
  +
  +int JK_METHOD jk2_uriMap_factory(jk_env_t *env, jk_pool_t *pool, void **result,
  + const char *type, const char *name);
  +
  +int JK_METHOD jk2_uriEnv_factory(jk_env_t *env, jk_pool_t *pool, void **result,
  + const char *type, const char *name);
  +
  
  
  
  1.16  +13 -146   jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c
  
  Index: jk_uriMap.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- jk_uriMap.c   28 Feb 2002 23:07:01 -  1.15
  +++ jk_uriMap.c   1 Mar 2002 00:45:58 -   1.16
  @@ -67,19 +67,13 @@
* servlet container.  
* 
* Author:  Gal Shachor <[EMAIL PROTECTED]>   
  - * Version: $Revision: 1.15 $   
  + * Version: $Revision: 1.16 $   
*/
   
   #include "jk_pool.h"
   #include "jk_env.h"
   #include "jk_uriMap.h"
  -
  -int JK_METHOD jk2_uriMap_factory(jk_env_t *env, jk_pool_t *pool, void **result,
  - const char *type, const char *name);
  -
  -static int jk2_uriMap_init(jk_env_t *env, jk_uriMap_t *_this,
  -   jk_workerEnv_t *workerEnv,
  -   jk_map_t *init_data);
  +#include "jk_registry.h"
   
   static jk_uriEnv_t *jk2_uriMap_addMapping(jk_env_t *env, jk_uriMap_t *_this,
 const char *vhost,
  @@ -174,50 +168,21 @@
   return JK_TRUE;
   }
   
  -/*  XXX Move to uriEnv.c  */
  -static jk_uriEnv_t *jk2_uriEnv_setProperty(jk_env_t *env,
  -   jk_uriEnv_t *uriEnv,
  -   const char *nameParam,
  -   const char *valueParam)
  -{
  -char *name=uriEnv->pool->pstrdup(env,uriEnv->pool, nameParam);
  -char *val=uriEnv->pool->pstrdup(env,uriEnv->pool, valueParam);
  -
  -uriEnv->properties->add( env ,uriEnv->properties,
  - name, val );
  -if( strcmp("worker", name) == 0 ) {
  -uriEnv->workerName=val;
  -}
  -
  -}
  -
  -
   static jk_uriEnv_t *jk2_uriEnv_createUriEnv(jk_env_t *env,
   jk_uriMap_t *uriMap,
  -const char *vhost,
  -const char *path) 
  +char *vhost,
  +char *path) 
   {
  -jk_pool_t *uriPool;
   int err;
   jk_uriEnv_t *uriEnv;
  -jk_workerEnv_t *wEnv=uriMap->workerEnv;
   
  -/** Will be discarded/flushed on reload */
  -/** XXX Group by webapp */
  -uriPool=(jk_pool_t *)uriMap->pool->create( env, uriMap->pool,
  - HUGE_POOL_SIZE);
  +   

cvs commit: jakarta-tomcat-4.0 OUTSTANDING-BUGS-4.0.3.txt RELEASE-NOTES-4.0.3-B1.txt

[remm]

remm02/02/28 16:36:05

  Modified:.Tag: tomcat_40_branch OUTSTANDING-BUGS-4.0.3.txt
RELEASE-NOTES-4.0.3-B1.txt
  Log:
  - Update bug status.
  - Remove a few obsolete release notes.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.9   +6 -2  jakarta-tomcat-4.0/Attic/OUTSTANDING-BUGS-4.0.3.txt
  
  Index: OUTSTANDING-BUGS-4.0.3.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/Attic/OUTSTANDING-BUGS-4.0.3.txt,v
  retrieving revision 1.1.2.8
  retrieving revision 1.1.2.9
  diff -u -r1.1.2.8 -r1.1.2.9
  --- OUTSTANDING-BUGS-4.0.3.txt28 Feb 2002 01:04:51 -  1.1.2.8
  +++ OUTSTANDING-BUGS-4.0.3.txt1 Mar 2002 00:36:05 -   1.1.2.9
  @@ -7,15 +7,19 @@
   acceptable to delay their resolution.
   
   
  +4964jasper popBody() is called before doEndTag() is called in a BodyTag
   5507catalina   Swapping sessions causes exceptions and it doesn't work 
  with FileStore
  +5741jasper Jspc -webapp option is broken due to namespace collisions
   5827catalina   DataInputStream.readInt returns wrong values
  -5976catalina   Tomcat 4.0.2B2 + Security Manager + JSSE don't work together
  +5853catalina   Unable to get request parameters in the Error page 
  +   for form based login
  +5998jasper Exception hiding when a JspExceptioin is thrown by a tag
   6068jk AJP13 "bad read", IOException
  +6281catalina   JDBCRealm+Form Login+URL re-writing session=broken
   6331jk Cannot add more than one cookie
   6420jk Loadbalancer mod_jk from 4.02 not working with TC 3.3
   6457jk mod_jk causes segmentation fault with JkLogLevel != debug
  -6464jasper Jspc generates bad package names on Windows NT
   6617catalina   Iterating over session attribute name enumeration fails
   
   
  
  
  
  1.1.2.14  +4 -37 jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.3-B1.txt
  
  Index: RELEASE-NOTES-4.0.3-B1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.3-B1.txt,v
  retrieving revision 1.1.2.13
  retrieving revision 1.1.2.14
  diff -u -r1.1.2.13 -r1.1.2.14
  --- RELEASE-NOTES-4.0.3-B1.txt28 Feb 2002 00:35:04 -  1.1.2.13
  +++ RELEASE-NOTES-4.0.3-B1.txt1 Mar 2002 00:36:05 -   1.1.2.14
  @@ -3,7 +3,7 @@
   Release Notes
   =
   
  -$Id: RELEASE-NOTES-4.0.3-B1.txt,v 1.1.2.13 2002/02/28 00:35:04 remm Exp $
  +$Id: RELEASE-NOTES-4.0.3-B1.txt,v 1.1.2.14 2002/03/01 00:36:05 remm Exp $
   
   
   
  @@ -144,13 +144,15 @@
 correctly
   6641  Download of MS Office docs from protected areas fail with IE
   6644  Whitespace after Content-type header value leads to POST method failure
  +6668  HttpProcessor takes incorrect defaults for proxy port according 
  +  to HTTP/1.1 Spec
  +6772  [Security] RequestDipatcher allows to bypass security manager sandboxing
   
   
   
   KNOWN ISSUES IN THIS RELEASE:
   
   
  -* Tomcat 4.0 and Apache
   * Tomcat 4.0 and JNI Based Applications
   * Tomcat 4.0 Standard APIs Available
   * Tomcat 4.0 and XML Parsers
  @@ -161,41 +163,6 @@
   * Tomcat 4.0 and Apache Cocoon 2.0
   * Enabling SSI and CGI Support
   * Tomcat 4.0 and Sun JDK 1.4 beta 3
  -
  -
  --
  -Tomcat 4.0 and Apache:
  --
  -
  -The binary distribution for Tomcat 4.0 includes the most recent stable version
  -of the WARP connector, which is the Tomcat component that talks to mod_webapp
  -inside Apache 1.3.  The current state of this support is summarized as follows:
  -
  -* The mod_webapp connector is configured based on the contents of the
  -  web.xml file for your web application.  The only required per-webapp
  -  configuration information in your Apache 1.3 httpd.conf file is
  -  something like this:
  -
  -WebAppDeploy examples   warpConnection   /examples/
  -
  -  which causes mod_webapp to automatically recognize all of your servlet
  -  mappings, security constraints, and other configuration elements.
  -
  -* Currently, mod_webapp forwards *all* requests under the specified
  -  context path to Tomcat for processing.  In a futher release,
  -  it will automatically configure itself to serve static resources
  -  from Apache *unless* the resource is subject to filtering, or subject
  -  to a security constraint, as defined in web.xml.  No extra configuration
  -  in httpd.conf will be required.
  -
  -* With this release, FORM-based authentication will work correctly, but
  -  there is a bug that prevents BASIC authentication from operating.  This
  -  will be addressed before final release.

cvs commit: jakarta-tomcat-connectors/jk/native2 build.xml

[costin]

costin  02/02/28 15:36:18

  Modified:jk/native2 build.xml
  Log:
  Add EAPI in the default build.xml, build all files in apache13 ( i.e. service + 
mod_jk )
  
  Revision  ChangesPath
  1.16  +4 -2  jakarta-tomcat-connectors/jk/native2/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/build.xml,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- build.xml 23 Feb 2002 19:02:19 -  1.15
  +++ build.xml 28 Feb 2002 23:36:18 -  1.16
  @@ -189,12 +189,12 @@
profile="${so.profile}">
   
 
  - 
  + 

   
   
  -
  +
 
 

  @@ -222,6 +222,8 @@
 

 
  +
  +  
   
 
 mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_service_apache2.c mod_jk2.c

[costin]

costin  02/02/28 15:35:26

  Modified:jk/native2/server/apache2 jk_service_apache2.c mod_jk2.c
  Log:
  Finally, the config changed we discussed.
  
  There is only one config directive for mod_jk that we should care:
JkSet name value
  
  JkSet workersFile  ... will read properties from a file, you can
  use it multiple times.
  
  Also "JkSet workersFile urimap.properties" will read a file in the
  style used by IIS ( /uri=worker ).
  Or
JkSet /examples ajp13
  will do the same as the old "JkMount /examples ajp13" ( or "/examples=ajp13"
  in any properties file ).
  
  Properties file will hopefully be automatically generated, and this allows
  httpd.conf to be used in the exact way with workers.properties ( and reverse).
  
  The other special directive is JkSetUri, in a  context, which will
  set properties on a uriEnv.
  
  I'll add an equivalent thing, properties-style, and that should be it.
  
  Revision  ChangesPath
  1.10  +1 -2  
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c
  
  Index: jk_service_apache2.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- jk_service_apache2.c  22 Feb 2002 10:08:35 -  1.9
  +++ jk_service_apache2.c  28 Feb 2002 23:35:26 -  1.10
  @@ -59,7 +59,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat 
* Author:  Gal Shachor <[EMAIL PROTECTED]>   
* Henri Gomez <[EMAIL PROTECTED]>
  - * Version: $Revision: 1.9 $   
  + * Version: $Revision: 1.10 $   
*/
   
   #include "apu_compat.h"
  @@ -233,7 +233,6 @@
   }
   }
   
  -
   {
   const apr_array_header_t *t = apr_table_elts(rr->headers_out);
   if(t && t->nelts) {
  
  
  
  1.2   +101 -306  jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
  
  Index: mod_jk2.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- mod_jk2.c 22 Feb 2002 10:04:34 -  1.1
  +++ mod_jk2.c 28 Feb 2002 23:35:26 -  1.2
  @@ -59,7 +59,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
* Henri Gomez <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.1 $   *
  + * Version: $Revision: 1.2 $   *
***/
   
   /*
  @@ -132,184 +132,36 @@
* and is nowhere near the apache mapper.
*/
   
  -/**
  - * In order to define a webapp you must add "Jk2Webapp" directive
  - * in a Location. 
  - *
  - * Example:
  - *   
  - *  
  - * Jk2Webapp worker ajp13
  - *  
  - *   
  - *
  - * This is the best way to define a webapplication in apache. It is
  - * scalable ( using apache native optimizations, you can have hundreds
  - * of hosts and thousands of webapplications ), 'natural' to any
  - * apache user.
  - */
  -static const char *jk2_setWebapp(cmd_parms *cmd, void *per_dir, 
  -const char *name, const char *val)
  -{
  -jk_uriEnv_t *uriEnv=(jk_uriEnv_t *)per_dir;
  -
  -if( uriEnv->webapp == NULL ) {
  -/* Do we know the url ? */
  -uriEnv->webapp=workerEnv->createWebapp( workerEnv->globalEnv, workerEnv,
  -NULL, cmd->path, NULL );
  -
  -/* fprintf(stderr, "New webapp %p %p\n",uriEnv, uriEnv->webapp); */
  -} else {
  -/* fprintf(stderr, "Existing webapp %p\n",uriEnv->webapp); */
  -}
  -
  -if( strcmp( name, "worker") == 0 ) {
  -uriEnv->webapp->workerName=ap_pstrdup(cmd->pool, val);
  -} else {
  -/* Generic properties */
  -uriEnv->webapp->properties->add( workerEnv->globalEnv,
  - uriEnv->webapp->properties,
  - ap_pstrdup(cmd->pool, name),
  - ap_pstrdup(cmd->pool, val));
  -}
  -
  -fprintf(stderr, "Jk2Webapp  %s %s dir=%s args=%s\n",
  -uriEnv->webapp->workerName, cmd->path,
  -cmd->directive->directive,
  -cmd->directive->args);
  -
  -return NULL;
  -}
  -
  -/**
  - * Associate a servlet to a . 
  - *
  - * Ex

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_requtil.c

[Bill Barker]

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 28, 2002 3:01 PM
Subject: cvs commit: jakarta-tomcat-connectors/jk/native2/common
jk_requtil.c


> costin  02/02/28 15:01:15
>
>   Modified:jk/native2/common jk_requtil.c
>   Log:
>   Case insensitive, if 'native' maps are used we no longer create copies
>of all the headers ( good for performance), but that also means we
>   don't have all-lowercase.
>
>   Someone with more C knowledge - let me know if strcasecmp is not
>   portable.

It's not portable (in particular, not to Windows).  However, you can
#ifdef WINDOWS
#define strcasecmp strcmpi
#endif



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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_serialize_ajp.c jk_handler_discovery.c

[costin]

costin  02/02/28 15:29:13

  Modified:jk/native2/common jk_serialize_ajp.c jk_handler_discovery.c
  Log:
  Updates and more debugging for the headers.
  
  Revision  ChangesPath
  1.7   +7 -0  jakarta-tomcat-connectors/jk/native2/common/jk_serialize_ajp.c
  
  Index: jk_serialize_ajp.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_serialize_ajp.c,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- jk_serialize_ajp.c21 Feb 2002 11:13:23 -  1.6
  +++ jk_serialize_ajp.c28 Feb 2002 23:29:13 -  1.7
  @@ -208,12 +208,16 @@
   char *name=s->headers_in->nameAt(env, s->headers_in, i);
   
   if (jk2_requtil_getHeaderId(env, name, &sc)) {
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
  +  "handle.request() Add headerId %s %d\n", name, sc);
   if (msg->appendInt(env, msg, sc)) {
   env->l->jkLog(env, env->l, JK_LOG_ERROR,
 "handle.request() Error serializing header id\n");
   return JK_FALSE;
   }
   } else {
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
  +  "handle.request() Add headerName %s\n", name);
   if (msg->appendString(env, msg, name)) {
   env->l->jkLog(env, env->l, JK_LOG_ERROR,
 "handle.request() Error serializing header name\n");
  @@ -221,6 +225,9 @@
   }
   }
   
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
  +  "handle.request() Add headerValue %s\n",
  +  s->headers_in->valueAt( env, s->headers_in, i));
   if (msg->appendString(env, msg,
 s->headers_in->valueAt( env, s->headers_in, i))) {
   env->l->jkLog(env, env->l, JK_LOG_ERROR,
  
  
  
  1.12  +6 -6  
jakarta-tomcat-connectors/jk/native2/common/jk_handler_discovery.c
  
  Index: jk_handler_discovery.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_handler_discovery.c,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- jk_handler_discovery.c21 Feb 2002 11:10:12 -  1.11
  +++ jk_handler_discovery.c28 Feb 2002 23:29:13 -  1.12
  @@ -58,7 +58,7 @@
   /**
* Description: AJP14 Discovery handler
* Author:  Henri Gomez <[EMAIL PROTECTED]>
  - * Version: $Revision: 1.11 $  
  + * Version: $Revision: 1.12 $  
*/
   
   #include "jk_global.h"
  @@ -68,7 +68,7 @@
   #include "jk_logger.h"
   #include "jk_service.h"
   #include "jk_handler.h"
  -#include "jk_webapp.h"
  +#include "jk_uriEnv.h"
   #include "jk_workerEnv.h"
   #include "jk_registry.h"
   
  @@ -128,8 +128,8 @@
   char *uri;
   int cmd;
   int i,j;
  -jk_webapp_t *ci;
  -jk_webapp_t *webapp;  
  +jk_uriEnv_t *ci;
  +jk_uriEnv_t *webapp;  
   char*buf;
   jk_workerEnv_t *we=ae->worker->workerEnv;
   
  @@ -158,7 +158,7 @@
 "contextList - Context: %s:%s \n",
 vname, cname);
   
  -webapp = we->createWebapp( env, we, vname, cname, NULL );
  +webapp = we->uriMap->createUriEnv( env, we->uriMap, vname, cname );
   if( webapp==NULL ) {
   env->l->jkLog(env, env->l, JK_LOG_ERROR,
"discoveryHandler: can't create webapp\n");
  @@ -208,7 +208,7 @@
   {
   char*vname;
   char*cname;
  -jk_webapp_t   *ci = NULL;
  +jk_uriEnv_t   *ci = NULL;
   
   /* get virtual name */
   vname  = (char *)msg->getString(env, msg);
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_workerEnv.c

[costin]

costin  02/02/28 15:28:33

  Modified:jk/native2/common jk_workerEnv.c
  Log:
  Use setProperty() to pass all config information.
  
  One sideefect is that you can now specify multiple files and/or use that
  as an include ( set workerFile property and the file will be read ).
  Of course, abuse can hurt.
  
  Also removed webapp, uriEnv will be managed by uriMap.
  
  Revision  ChangesPath
  1.17  +118 -118  jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c
  
  Index: jk_workerEnv.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- jk_workerEnv.c21 Feb 2002 11:13:59 -  1.16
  +++ jk_workerEnv.c28 Feb 2002 23:28:33 -  1.17
  @@ -59,7 +59,7 @@
* Description: Workers controller *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
* Author:  Henri Gomez <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.16 $   *
  + * Version: $Revision: 1.17 $   *
***/
   
   #include "jk_workerEnv.h" 
  @@ -77,76 +77,112 @@
   static void jk2_workerEnv_initHandlers(jk_env_t *env, jk_workerEnv_t *_this);
   static int  jk2_workerEnv_init1(jk_env_t *env, jk_workerEnv_t *_this);
   
  -static int jk2_workerEnv_init(jk_env_t *env, jk_workerEnv_t *workerEnv)
  +/*  Setup  */
  +
  +static int jk2_workerEnv_setWorkerFile( struct jk_env *env,
  +struct jk_workerEnv *workerEnv,
  + char *workerFile)
   {
  +struct stat statbuf;
   int err;
  -char *opt;
  -int options;
  -
  -opt=jk2_map_getString( env, workerEnv->init_data, "workerFile", NULL );
  -if( opt != NULL ) {
  -struct stat statbuf;
  -
  -/* we need an absolut path (ap_server_root_relative does the ap_pstrdup) */
  -workerEnv->worker_file = opt;
  -/* We should make it relative to JK_HOME or absolute path.
  -   ap_server_root_relative(cmd->pool,opt); */
  -
  -if (workerEnv->worker_file == NULL) {
  -env->l->jkLog(env, env->l, JK_LOG_ERROR,
  -  "JkWorkersFile file_name invalid %s", 
workerEnv->worker_file);
  -return JK_FALSE;
  -}
  -
  -if (stat(workerEnv->worker_file, &statbuf) == -1) {
  -env->l->jkLog(env, env->l, JK_LOG_ERROR,
  -  "Can't find the workers file specified");
  -return JK_FALSE;
  -}
  -/** Read worker files
  - */
  -env->l->jkLog(env, env->l, JK_LOG_DEBUG, "Reading map %s %d\n",
  -  workerEnv->worker_file,
  -  workerEnv->init_data->size(env, workerEnv->init_data) );
   
  -err=jk2_map_readFileProperties(env, workerEnv->init_data,
  -  workerEnv->worker_file);
  -if( err==JK_TRUE ) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  -  "mod_jk.initJk() Reading worker properties %s %d\n", 
workerEnv->worker_file,
  -  workerEnv->init_data->size( env, workerEnv->init_data ) );
  -} else {
  -env->l->jkLog(env, env->l, JK_LOG_ERROR,
  -  "mod_jk.initJk() Error reading worker properties %s %d\n",
  -  workerEnv->worker_file,
  -  workerEnv->init_data->size( env, workerEnv->init_data ) );
  -}
  +/* We should make it relative to JK_HOME or absolute path.
  +   ap_server_root_relative(cmd->pool,opt); */
  +
  +if (stat(workerFile, &statbuf) == -1) {
  +env->l->jkLog(env, env->l, JK_LOG_ERROR,
  +  "Can't find the workers file %s", workerFile );
  +return JK_FALSE;
   }
  -
  -opt=jk2_map_getString( env, workerEnv->init_data, "logLevel", "Error" );
  -
  -if(0 == strcasecmp(opt, JK_LOG_INFO_VERB)) {
  -env->l->level=JK_LOG_INFO_LEVEL;
  +
  +/** Read worker files
  + */
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "Reading properties %s %d\n",
  +  workerFile,
  +  workerEnv->initData->size(env, workerEnv->initData) );
  +
  +err=jk2_map_readFileProperties(env, workerEnv->initData, workerFile );
  +
  +if( err==JK_TRUE ) {
  +env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +  "mod_jk.initJk() Reading worker properties %s %d\n",
  +  workerFile,
  + 

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_status.c

[costin]

costin  02/02/28 15:07:22

  Modified:jk/native2/common jk_worker_status.c
  Log:
  Display all mappings, few other updates.
  
  Revision  ChangesPath
  1.6   +20 -15jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c
  
  Index: jk_worker_status.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jk_worker_status.c21 Feb 2002 11:13:59 -  1.5
  +++ jk_worker_status.c28 Feb 2002 23:07:22 -  1.6
  @@ -95,7 +95,7 @@
   
   va_start(vargs,fmt);
   buf->pos=0; /* Temp - we don't buffer */
  -ret=apr_vsnprintf(buf->buf + buf->pos, buf->size - buf->pos, fmt, vargs);
  +ret=vsnprintf(buf->buf + buf->pos, buf->size - buf->pos, fmt, vargs);
   va_end(vargs);
   
   buf->s->write( env, buf->s, buf->buf, strlen(buf->buf) );
  @@ -153,7 +153,7 @@
   static void jk2_worker_status_displayWorkerEnv(jk_env_t *env, jk_buff_t *buf,
  jk_workerEnv_t *wenv)
   {
  -jk_map_t *map=wenv->init_data;
  +jk_map_t *map=wenv->initData;
   int i;
   
   jk2_printf(env, buf, "Worker Env Info\n");
  @@ -180,30 +180,35 @@
   
   }
   
  -static void jk2_worker_status_displayWebapps(jk_env_t *env, jk_buff_t *buf,
  +static void jk2_worker_status_displayMappings(jk_env_t *env, jk_buff_t *buf,
jk_workerEnv_t *wenv)
   {
  -jk_map_t *map=wenv->webapps;
  +jk_uriEnv_t **maps=wenv->uriMap->maps;
  +int size=wenv->uriMap->size;
   int i;
   
  -jk2_printf(env, buf, "Webapps\n");
  +jk2_printf(env, buf, "Mappings\n");
   
  -if( map==NULL ) {
  +if( maps==NULL ) {
   jk2_printf(env, buf, "None\n");
   return;
   }
   
  -jk2_printf(env, buf, "\n");
  +jk2_printf(env, buf, "\n");
   
  -jk2_printf(env, buf, "NameDocBase"
  -  "Mappings");
  +jk2_printf(env, buf, "HostUri"
  +  "Worker");
   
  -for( i=0; i< map->size( env, map ) ; i++ ) {
  -char *name=map->nameAt( env, map, i );
  -jk_webapp_t *webapp=(jk_webapp_t *)map->valueAt( env, map,i );
  +for( i=0; i< size ; i++ ) {
  +jk_uriEnv_t *uriEnv=maps[i];
   
  -jk2_printf(env, buf, "", name );
  -jk2_printf(env, buf, "%s", name );
  +jk2_printf(env, buf, "" );
  +jk2_printf(env, buf, "%s",
  +   (uriEnv->virtual==NULL) ? "*" : uriEnv->virtual );
  +jk2_printf(env, buf, "%s",
  +   uriEnv->uri);
  +jk2_printf(env, buf, "%s",
  +   (uriEnv->workerName==NULL) ? "DEFAULT" : uriEnv->workerName );
   jk2_printf(env, buf, "" );
   }
   
  @@ -260,7 +265,7 @@
   /* Body */
   jk2_worker_status_displayWorkerEnv(env, buff, s->workerEnv );
   jk2_worker_status_displayWorkers(env, buff, s->workerEnv );
  -jk2_worker_status_displayWebapps(env, buff, s->workerEnv );
  +jk2_worker_status_displayMappings(env, buff, s->workerEnv );
   jk2_worker_status_displayConnections(env, buff, s->workerEnv );
   
   s->afterRequest( env, s);
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriMap.c

[costin]

costin  02/02/28 15:07:01

  Modified:jk/native2/common jk_uriMap.c
  Log:
  - add createUriEnv. It'll be used from mod_jk to register a , that
  replace the duplicated code that was used there.
  Now all maps are registered with uriMap, including the ones in ,
  the only difference is that  is faster and may be integrated with
  other apache directives.
  
  - add setProperty for uriEnv, it'll be extended - the same model used for java,
  with getter and setter ( but only one method ). This will allow us some
  more flexibility ( it's mostly used at config time, so it doesn't affect
  the performance )
  
  Revision  ChangesPath
  1.15  +84 -44jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c
  
  Index: jk_uriMap.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- jk_uriMap.c   22 Feb 2002 11:06:01 -  1.14
  +++ jk_uriMap.c   28 Feb 2002 23:07:01 -  1.15
  @@ -67,7 +67,7 @@
* servlet container.  
* 
* Author:  Gal Shachor <[EMAIL PROTECTED]>   
  - * Version: $Revision: 1.14 $   
  + * Version: $Revision: 1.15 $   
*/
   
   #include "jk_pool.h"
  @@ -174,52 +174,73 @@
   return JK_TRUE;
   }
   
  -static jk_uriEnv_t *jk2_uriMap_createUriEnv(jk_env_t *env, jk_uriMap_t *_this,
  -const char *vhost, const char *uri)
  +/*  XXX Move to uriEnv.c  */
  +static jk_uriEnv_t *jk2_uriEnv_setProperty(jk_env_t *env,
  +   jk_uriEnv_t *uriEnv,
  +   const char *nameParam,
  +   const char *valueParam)
   {
  -jk_uriEnv_t *uriEnv=(jk_uriEnv_t *)_this->pool->calloc(env, _this->pool,
  -   sizeof(jk_uriEnv_t));
  -uriEnv->workerEnv=_this->workerEnv;
  -/* XXX search the real webapp
  - */
  -uriEnv->webapp=_this->workerEnv->rootWebapp;
  +char *name=uriEnv->pool->pstrdup(env,uriEnv->pool, nameParam);
  +char *val=uriEnv->pool->pstrdup(env,uriEnv->pool, valueParam);
  +
  +uriEnv->properties->add( env ,uriEnv->properties,
  + name, val );
  +if( strcmp("worker", name) == 0 ) {
  +uriEnv->workerName=val;
  +}
   
  -return uriEnv;
   }
   
  -static jk_uriEnv_t *jk2_uriMap_addMapping(jk_env_t *env, jk_uriMap_t *_this,
  -  const char *vhost,
  -  const char *puri, 
  -  const char *pworker)
  +
  +static jk_uriEnv_t *jk2_uriEnv_createUriEnv(jk_env_t *env,
  +jk_uriMap_t *uriMap,
  +const char *vhost,
  +const char *path) 
   {
  -jk_uriEnv_t *uwr;
  -char *uri;
  -char *worker;
  +jk_pool_t *uriPool;
   int err;
  -char *asterisk;
  +jk_uriEnv_t *uriEnv;
  +jk_workerEnv_t *wEnv=uriMap->workerEnv;
   
  +/** Will be discarded/flushed on reload */
  +/** XXX Group by webapp */
  +uriPool=(jk_pool_t *)uriMap->pool->create( env, uriMap->pool,
  + HUGE_POOL_SIZE);
  +
  +uriEnv=(jk_uriEnv_t *)uriMap->pool->calloc(env, uriPool,
  +  sizeof(jk_uriEnv_t));
  +
  +uriEnv->setProperty=&jk2_uriEnv_setProperty;
  +uriEnv->pool=uriPool;
  +
  +uriEnv->workerEnv=uriMap->workerEnv;
  +jk2_map_default_create( env, &uriEnv->properties, uriPool );
  +
  +uriEnv->uri=uriPool->pstrdup(env, uriPool, path);
  +uriEnv->virtual=uriPool->pstrdup(env, uriPool, vhost);
  +
  +/* Register it */
   /* make sure we have space */
  -err=jk2_uriMap_realloc(env, _this);
  +err=jk2_uriMap_realloc(env, uriMap);
   if (err != JK_TRUE ) {
   env->l->jkLog(env, env->l, JK_LOG_ERROR,
 "uriMap.addMappint() OutOfMemoryException\n");
   return NULL;
   }
  +uriMap->maps[uriMap->size] = uriEnv;
  +uriMap->size++;
   
  -uwr = jk2_uriMap_createUriEnv(env, _this,vhost,puri);
  -
  -uri = _this->pool->pstrdup(env, _this->pool, puri);
  -uwr->uri = _this->pool->pstrdup(env, _this->pool, uri);
  -
  -worker = _this->pool->pstrdup(env, _this->pool, pworker);
  -uwr->webapp->workerName = worker;
  +return uriEnv;
  +}
   
  -   

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_requtil.c

[costin]

costin  02/02/28 15:01:15

  Modified:jk/native2/common jk_requtil.c
  Log:
  Case insensitive, if 'native' maps are used we no longer create copies
   of all the headers ( good for performance), but that also means we
  don't have all-lowercase.
  
  Someone with more C knowledge - let me know if strcasecmp is not
  portable.
  
  Revision  ChangesPath
  1.8   +25 -18jakarta-tomcat-connectors/jk/native2/common/jk_requtil.c
  
  Index: jk_requtil.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_requtil.c,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- jk_requtil.c  21 Feb 2002 11:13:23 -  1.7
  +++ jk_requtil.c  28 Feb 2002 23:01:15 -  1.8
  @@ -165,19 +165,23 @@
   int  jk2_requtil_getHeaderId(jk_env_t *env, const char *header_name,
   unsigned short *sc) 
   {
  +/* char lowerCased[30]; */
  +
  +/* if( strlen( header_name ) > 30 ) */
  +/* return JK_FALSE; */
  +/* strncpy( lowerCased, header_name,  30 ); */
  +
  +
   switch(header_name[0]) {
   case 'a':
  -if('c' ==header_name[1] &&
  -   'c' ==header_name[2] &&
  -   'e' ==header_name[3] &&
  -   'p' ==header_name[4] &&
  -   't' ==header_name[5]) {
  +case 'A':
  +if(strncasecmp( header_name, "accept", 6 ) == 0 ) {
   if ('-' == header_name[6]) {
  -if(!strcmp(header_name + 7, "charset")) {
  +if(!strcasecmp(header_name + 7, "charset")) {
   *sc = SC_ACCEPT_CHARSET;
  -} else if(!strcmp(header_name + 7, "encoding")) {
  +} else if(!strcasecmp(header_name + 7, "encoding")) {
   *sc = SC_ACCEPT_ENCODING;
  -} else if(!strcmp(header_name + 7, "language")) {
  +} else if(!strcasecmp(header_name + 7, "language")) {
   *sc = SC_ACCEPT_LANGUAGE;
   } else {
   return JK_FALSE;
  @@ -187,7 +191,7 @@
   } else {
   return JK_FALSE;
   }
  -} else if (!strcmp(header_name, "authorization")) {
  +} else if (!strcasecmp(header_name, "authorization")) {
   *sc = SC_AUTHORIZATION;
   } else {
   return JK_FALSE;
  @@ -195,15 +199,15 @@
   break;
   
   case 'c':
  -if(!strcmp(header_name, "cookie")) {
  +if(!strcasecmp(header_name, "cookie")) {
   *sc = SC_COOKIE;
  -} else if(!strcmp(header_name, "connection")) {
  +} else if(!strcasecmp(header_name, "connection")) {
   *sc = SC_CONNECTION;
  -} else if(!strcmp(header_name, "content-type")) {
  +} else if(!strcasecmp(header_name, "content-type")) {
   *sc = SC_CONTENT_TYPE;
  -} else if(!strcmp(header_name, "content-length")) {
  +} else if(!strcasecmp(header_name, "content-length")) {
   *sc = SC_CONTENT_LENGTH;
  -} else if(!strcmp(header_name, "cookie2")) {
  +} else if(!strcasecmp(header_name, "cookie2")) {
   *sc = SC_COOKIE2;
   } else {
   return JK_FALSE;
  @@ -211,7 +215,7 @@
   break;
   
   case 'h':
  -if(!strcmp(header_name, "host")) {
  +if(!strcasecmp(header_name, "host")) {
   *sc = SC_HOST;
   } else {
   return JK_FALSE;
  @@ -219,7 +223,7 @@
   break;
   
   case 'p':
  -if(!strcmp(header_name, "pragma")) {
  +if(!strcasecmp(header_name, "pragma")) {
   *sc = SC_PRAGMA;
   } else {
   return JK_FALSE;
  @@ -227,7 +231,7 @@
   break;
   
   case 'r':
  -if(!strcmp(header_name, "referer")) {
  +if(!strcasecmp(header_name, "referer")) {
   *sc = SC_REFERER;
   } else {
   return JK_FALSE;
  @@ -235,7 +239,7 @@
   break;
   
   case 'u':
  -if(!strcmp(header_name, "user-agent")) {
  +if(!strcasecmp(header_name, "user-agent")) {
   *sc = SC_USER_AGENT;
   } else {
   return JK_FALSE;
  @@ -243,6 +247,9 @@
   break;
   
   default:
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
  +  "requtil.getHeaderId() long header %s\n", header_name);
  +
   return JK_FALSE;
   }
   /* Never reached */
  
  
  

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

DO NOT REPLY [Bug 6772] - [Security] RequestDipatcher allows to bypass security manager sandboxing

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

[Security] RequestDipatcher allows to bypass security manager sandboxing

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 22:46 ---
This security vulnerability has been fixed in both the 4.0.x and the HEAD 
branch.

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

cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c

[costin]

costin  02/02/28 14:45:50

  Modified:jk/native/apache-2.0 mod_jk.c
  Log:
  Avoid duplicated initialization
  
  Revision  ChangesPath
  1.40  +4 -3  jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
  retrieving revision 1.39
  retrieving revision 1.40
  diff -u -r1.39 -r1.40
  --- mod_jk.c  4 Dec 2001 21:38:26 -   1.39
  +++ mod_jk.c  28 Feb 2002 22:45:50 -  1.40
  @@ -60,7 +60,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
* Henri Gomez <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.39 $   *
  + * Version: $Revision: 1.40 $   *
***/
   
   /*
  @@ -682,8 +682,8 @@
* JkAutoMount directive handling
*
* JkAutoMount worker [virtualhost]
  + * This is an experimental and undocumented extension made in j-t-c/jk.
*/
  -
   static const char *jk_automount_context(cmd_parms *cmd,
   void *dummy,
   const char *worker,
  @@ -731,6 +731,7 @@
   
   /*
* JkWorker name value
  + * This is an experimental and undocumented extension made in j-t-c/jk.
*/
   static const char *jk_worker_property(cmd_parms *cmd,
 void *dummy,
  @@ -1473,7 +1474,7 @@
   jk_server_conf_t *conf =
   (jk_server_conf_t *)ap_get_module_config(s->module_config, &jk_module);
   
  -init_jk( pconf, conf, s );
  +/* init_jk( pconf, conf, s ); */
   }
   
   /** Initialize jk, using worker.properties. 
  
  
  

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

DO NOT REPLY [Bug 6772] New: - [Security] RequestDipatcher allows to bypass security manager sandboxing

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

[Security] RequestDipatcher allows to bypass security manager sandboxing

   Summary: [Security] RequestDipatcher allows to bypass security
manager sandboxing
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using a request dipatcher with a relative URL (incuding '/../') allows a 
servlet or JSP to access files on the server filesystem, bypassing the 
protection the security manager provides.

>From the original report:

The problem is this: with a more-or-less default installation of Tomcat
using the security manager, in a jsp:include you can access outside of
your context using ../../../ .  Note that in other forms of reading the
files, the security manager correctly prohibits access (both in a
jsp:include giving the real path, and in standard programmatic file 
opening with real and ../ paths).  It's just in the case of the include
with relative path that it allows access to others' files.

Here's a sample line of a jsp that should generate an error, but
doesn't.  The contexts are foo1/ and foo2/, they are defined in separate
context tags.  This line is from a file in foo1/.


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

DO NOT REPLY [Bug 6770] New: - Login not displayed if error page is specified for a 401

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

Login not displayed if error page is specified for a 401

   Summary: Login not displayed if error page is specified for a 401
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If web.xml has an error page associated with a 401, IE will not display a login 
however if you remove it the login works as expected.

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

Re: Tomcat 4.1-dev Host unpackWARs not working

[Remy Maucherat]

> [PROPOSAL]

-1 for this proposal (sorry, but I really *hate* it).

To paraphrase a bit:
If unpack="false" then unpack.
If unpack="true" then unpack somewhere else.
Otehrwise, both do the same.

The current behavior will hopefully encourage people not to rely on the
filesystem and use more portable APIs (a good thing IMO).

-1 for removing expanded webapps on shutdown. You don't know if the user
modified something, and would like to see its modifications survive the
shutdown.
At least unpack="false" currently makes things very clear, since the user
can't modify anything without unpacking himself.

-1 for update as a new manager command. Its behavior seems highly
unpredictable to me. remove + install seems better, so that the user knows
what he's doing.

Note: remove/start/stop already exist.

Remy


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

DO NOT REPLY [Bug 6769] - Regexp (required) is missing from BUILDING.txt

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

Regexp (required) is missing from BUILDING.txt





--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 22:16 ---
Created an attachment (id=1254)
Adds a paragraph for Regexp and corrects a reference...

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

DO NOT REPLY [Bug 6769] New: - Regexp (required) is missing from BUILDING.txt

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

Regexp (required) is missing from BUILDING.txt

   Summary: Regexp (required) is missing from BUILDING.txt
   Product: Tomcat 4
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Regexp is a required component (as can be seen in build.properties.sample)
but is not mentioned in BUILDING.txt

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

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_uriMap.h jk_workerEnv.h

[costin]

costin  02/02/28 14:08:21

  Modified:jk/native2/include jk_uriMap.h jk_workerEnv.h
  Log:
  Few more changes in cleaning up the uri mapping and config.
  
  Revision  ChangesPath
  1.8   +5 -0  jakarta-tomcat-connectors/jk/native2/include/jk_uriMap.h
  
  Index: jk_uriMap.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_uriMap.h,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- jk_uriMap.h   16 Dec 2001 23:17:23 -  1.7
  +++ jk_uriMap.h   28 Feb 2002 22:08:21 -  1.8
  @@ -115,6 +115,11 @@
   
   void (*destroy)( struct jk_env *env, jk_uriMap_t *_this );
   
  +struct jk_uriEnv *(*createUriEnv)(struct jk_env *env,
  +  struct jk_uriMap *_this,
  +  const char *vhost,
  +  const char *name );
  +
   /** Add a servlet mapping. Can be done before init()
*/
   jk_uriEnv_t *(*addMapping)( struct jk_env *env, jk_uriMap_t *_this,
  
  
  
  1.11  +42 -18jakarta-tomcat-connectors/jk/native2/include/jk_workerEnv.h
  
  Index: jk_workerEnv.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_workerEnv.h,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- jk_workerEnv.h6 Feb 2002 19:19:16 -   1.10
  +++ jk_workerEnv.h28 Feb 2002 22:08:21 -  1.11
  @@ -58,7 +58,7 @@
   /***
* Description: Workers controller header file *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   * 
  - * Version: $Revision: 1.10 $   *
  + * Version: $Revision: 1.11 $   *
***/
   
   #ifndef JK_WORKERENV_H
  @@ -69,7 +69,7 @@
   #include "jk_worker.h"
   #include "jk_map.h"
   #include "jk_uriMap.h"
  -#include "jk_webapp.h"
  +#include "jk_uriEnv.h"
   #include "jk_handler.h"
   #include "jk_service.h"
   #include "jk_vm.h"
  @@ -82,7 +82,7 @@
   struct jk_endpoint;
   struct jk_env;
   struct jk_uriMap;
  -struct jk_webapp;
  +struct jk_uriEnv;
   struct jk_map;
   struct jk_logger;
   struct jk_handler;
  @@ -129,7 +129,10 @@
   
   /** Initialization properties, set via native options or workers.properties.
*/
  -struct jk_map *init_data;
  +/* XXX renamed from init_data to force all code to use setProperty
  +   This is private property !
  +*/
  +struct jk_map *initData;
   
   /** Root env, used to register object types, etc
*/
  @@ -141,18 +144,12 @@
   char *log_file;
   int  log_level;
   
  -/*
  - * Worker stuff
  - */
  -char *worker_file;
  -
   char *secret_key;
   /* jk_map_t *automount; */
   
   struct jk_uriMap *uriMap;
   
  -struct jk_webapp *rootWebapp;
  -struct jk_map *webapps;
  +struct jk_uriEnv *rootWebapp;
   
   /** If 'global' server mappings will be visible in virtual hosts
   as well. XXX Not sure this is needed
  @@ -205,6 +202,38 @@
   void *_private;
   
   /*  Methods  */
  +/** Set a jk property. This is similar with the mechanism
  + *  used by java side ( with individual setters for
  + *  various properties ), except we use a single method
  + *  and a big switch
  + *
  + *  As in java beans, setting a property may have side effects
  + *  like changing the log level or reading a secondary
  + *  properties file.
  + *
  + *  Changing a property at runtime will also be supported for
  + *  some properties.
  + *  XXX Document supported properties as part of
  + *  workers.properties doc.
  + *  XXX Implement run-time change in the status/ctl workers.
  + */
  +int (*setProperty)( struct jk_env *env,
  + struct jk_workerEnv *_this,
  + const char *name, char *value);
  +
  +char *(*getProperty)( struct jk_env *env,
  +  struct jk_workerEnv *_this,
  +  const char *name);
  +
  +/** Return a list of supported properties.
  +Not all properties can be set ( some may be runtime
  +status ).
  +@experimental This is not a final API, I would use
  +an external config ( DTD/schema or even MIB-like ?  )
  +*/
  +char **(*getPropertyNames)( struct jk_env *env,
  +struct jk_workerEnv *_this );
  +
   
   /** Get worker by name
*/
  @@ -218,12 +247,6 @@
 

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_uriEnv.h

[costin]

costin  02/02/28 14:04:31

  Modified:jk/native2/include jk_uriEnv.h
  Log:
  Added the stuff from jk_webapp.
  
  Added a setProperty() - another attempt to harmonize the java and C versions.
  
  Revision  ChangesPath
  1.6   +52 -1 jakarta-tomcat-connectors/jk/native2/include/jk_uriEnv.h
  
  Index: jk_uriEnv.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_uriEnv.h,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jk_uriEnv.h   16 Dec 2001 23:17:23 -  1.5
  +++ jk_uriEnv.h   28 Feb 2002 22:04:31 -  1.6
  @@ -95,6 +95,8 @@
   
   
   struct jk_uriEnv {
  +struct jk_pool *pool;
  +
   struct jk_workerEnv *workerEnv;
   
   struct jk_webapp *webapp;
  @@ -126,9 +128,58 @@
   int match_type;
   
   int debug;
  +
  +/** Worker associated with this uri
  +Inherited by virtual host. Defaults to the first declared worker.
  +( if null == use default worker ).
  +*/
  +struct jk_worker *worker;
  +
  +/** worker name - allow this to be set before the worker is defined.
  + *  worker will be set on init.
  + */
  +char *workerName; 
  +
  +/** You can fine-tune the logging level per location
  + */
  +int logLevel;
  +
  +/** Different apps can have different loggers.
  + */
  +struct jk_logger *l;
  +
  +/* Environment variables support
  + */
  +int envvars_in_use;
  +struct jk_map *envvars;
  +
  +/* Virtual server handled - NULL means 'global' ( visible in all
  + * virtual servers ). This is the canonical name.
  + */
  +char *virtual;
  +int virtualPort;
  +
  +/** Uri we're monted on
  + *  The 'id' is the index in the context table ( todo ), it
  + *  reduce the ammount of trafic ( and string creation on java )
  + */
  +char *context;
  +int ctxt_len;
  +int contextId;
  +
   /*  Methods  */
   
  -/* get/setProperty */
  +int (*setProperty)( struct jk_env *env,
  + struct jk_uriEnv *_this,
  + const char *name, char *value);
  +
  +char *(*getProperty)( struct jk_env *env,
  +  struct jk_uriEnv *_this,
  +  const char *name);
  +
  +char **(*getPropertyNames)( struct jk_env *env,
  +struct jk_uriEnv *_this );
  +
   };
   
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_webapp.h

[costin]

costin  02/02/28 13:59:28

  Removed: jk/native2/include jk_webapp.h
  Log:
  Removed webapp.h - it was a good idea, but extremely difficult to implement
  in the current model, where we deal mostly with uris.
  
  This simplifies the whole mapping code, a webapp is just a particular case
  or uriEnv. This is part of the simplifications in the config.

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

Re: [4.0.3] [VOTES] Upcoming release and security fix

[Bill Barker]

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 28, 2002 11:09 AM
Subject: [4.0.3] [VOTES] Upcoming release and security fix


> 
> A [+0] Make a full 4.0.3 (or 4.0.2a) release which would only include the
> security fix
> B [+0] Make the security fix available as a binary patch for 4.0.2 (it
would
> take the form of an archive to extract in $CATALINA_HOME, and would be
> *small*)
> C [ ] Accelerate the release schedule of 4.0.3, which would include the
> security fix, as well as fixes for other issues with 4.0.2 (with Beta 1 on
> 03/01 and Final on 03/08)
> 
>
Much the same as with Craig.  The RPM people will probably want A, whereas
I'd guess that a lot of non-Linux people will want B.

> 
> +1 [ ] I support the release, and I will help
> +0 [X] I support the release
> -0 [ ] I don't support the release
> -1 [ ] I'm against the release because:
>
>
> 
>
> My vote is +1.
>
> Note: Non-committers are welcome to vote if they feel like it, but the
vote
> in that case is non binding.
>
> Remy
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

DO NOT REPLY [Bug 6749] - Work directory not deleted when Context is removed from 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=6749

Work directory not deleted when Context is removed from Tomcat





--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 20:13 ---
This probably was the same problem as bug 6594; I confirmed that redeployment 
works fine on a build of the current tomcat_40_branch in CVS.

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

tomcat402+iplanet4.1

[Thutika, Swamy]

Hi All,
  I could succesfully connect iplanet4.1 with tomcat33a with ajp3
connector(on windows nt). I user nsapi_redirector that came is under binary
distribution.

  I am using tomcat as ouofprocess engine.

  But when i do the same thing between tomcat402 and iplanet4.1 , i get the
following errors when accessing examples url from iplanet


**
  [Thu Feb 28 08:51:19 2002]  [jk_connect.c (115)]: jk_open_socket, try to
connect socket = 444
[Thu Feb 28 08:51:21 2002]  [jk_connect.c (124)]: jk_open_socket, after
connect ret = -1
[Thu Feb 28 08:51:21 2002]  [jk_connect.c (143)]: jk_open_socket, connect()
failed errno = 61
[Thu Feb 28 08:51:21 2002]  [jk_ajp13_worker.c (196)]: In
jk_endpoint_t::connect_to_tomcat, failed errno = 61
[Thu Feb 28 08:51:21 2002]  [jk_ajp13_worker.c (635)]: Error connecting to
the Tomcat process.
[Thu Feb 28 08:51:21 2002]  [jk_ajp13_worker.c (848)]: In
jk_endpoint_t::service, send_request failed in send loop 0
[Thu Feb 28 08:51:21 2002]  [jk_connect.c (108)]: Into jk_open_socket
[Thu Feb 28 08:51:21 2002]  [jk_connect.c (115)]: jk_open_socket, try to
connect socket = 452
[Thu Feb 28 08:51:22 2002]  [jk_connect.c (124)]: jk_open_socket, after
connect ret = -1
[Thu Feb 28 08:51:22 2002]  [jk_connect.c (143)]: jk_open_socket, connect()
failed errno = 61
[Thu Feb 28 08:51:22 2002]  [jk_ajp13_worker.c (196)]: In
jk_endpoint_t::connect_to_tomcat, failed errno = 61
[Thu Feb 28 08:51:22 2002]  [jk_ajp13_worker.c (635)]: Error connecting to
the Tomcat process.
[Thu Feb 28 08:51:22 2002]  [jk_ajp13_worker.c (848)]: In
jk_endpoint_t::service, send_request failed in send loop 1
[Thu Feb 28 08:51:22 2002]  [jk_connect.c (108)]: Into jk_open_socket
[Thu Feb 28 08:51:22 2002]  [jk_connect.c (115)]: jk_open_socket, try to
connect socket = 460
[Thu Feb 28 08:51:24 2002]  [jk_connect.c (124)]: jk_open_socket, after
connect ret = -1
[Thu Feb 28 08:51:24 2002]  [jk_connect.c (143)]: jk_open_socket, connect()
failed errno = 61
[Thu Feb 28 08:51:24 2002]  [jk_ajp13_worker.c (196)]: In
jk_endpoint_t::connect_to_tomcat, failed errno = 61
[Thu Feb 28 08:51:24 2002]  [jk_ajp13_worker.c (635)]: Error connecting to
the Tomcat process.
[Thu Feb 28 08:51:24 2002]  [jk_ajp13_worker.c (848)]: In
jk_endpoint_t::service, send_request failed in send loop 2
[Thu Feb 28 08:51:24 2002]  [jk_ajp13_worker.c (549)]: Into
jk_endpoint_t::done





As i didn't find naspi_redirector.dll under tomcat402 binary , i am using
the 33a redirector.

NOTE: if i use ajp12 i get an incomplete read of -1 error.

Could somebody help me resolve this? 


Thanks in advance,

Swamy


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

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

[Remy Maucherat]

Did I actually reply to this before ?
I can't remember, so in case I didn't ...

> Actually, I was hoping to find time to get started on this once 3.3.1 is
out
> the door (and hopefully things slow down a bit).
>
> I'm a bit behind on Remy's recent work, but I'm pretty sure that it
requires
> Java2.

No, I don't think so. The HTTP/1.1 stack should work with 1.1 (I can't find
any Java2 code in there).

Also, the HTTP stack is just the stack. It doesn't include the thread
pooling code, or the network handling code.
The Catalina adatpter, and the Catalina connector both require Java2, OTOH.

> Hi Remy,
>
> Do you think coyote could be ever used with Tomcat 3.3 ?
> ie: works with JDK 1.1, support TC 3.3 via modules

Since Coyote = more or less 1/2 of the Tomcat 3.3 core (according to
Costin's definition of the TC 3.3 core), it should be easier to adapt.

Note: I got complaints from Costin about the request and response objects.
Well, this is only the first version, and I had limited objectives (which
were: write a HTTP/1.1 stack on top of it + an adapter for TC 4, while
trying to keep things fairly generic). Coyote 2 can use different
request/response objects.

> JK/JK2 are available for both TC 3.3/4.x, it could be fine to
> have also a common HTTP connector for them and coyote seems
> to be the perfect candidate :)

I think the new HTTP stack is fast (but I don't have profiling data to back
this up at the moment). I'll do lots of profiling when the adapter for TC 4
is working.
It could be worthwhile to port JK 2 to Coyote (2 ?), since the TC 4 adapter
will likely be a lot faster than using the o.a.c.connector package. There's
obviously no hurry, as it's working fine already.

Remy


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

Re: [4.0.3] [VOTES] Upcoming release and security fix

[Craig R. McClanahan]

+1 for option A and B together (they don't have to be mutually exclusive,
and we can examine user behavior to see if binary patches are an idea
worth pursuing.

+1 for 4.0.3-b1.

Craig


On Thu, 28 Feb 2002, Remy Maucherat wrote:

> Date: Thu, 28 Feb 2002 11:09:08 -0800
> From: Remy Maucherat <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [4.0.3] [VOTES] Upcoming release and security fix
>
> Since there are apparently diverging opinions on the subject (and also since
> I didn't get any +1s for a possible 4.0.3 b1, or a 4.0.2a release), here's a
> formal request for vote.
>
> On the security problem reported yesterday, affecting the security manager
> sandboxing. We should:
> 
> A [ ] Make a full 4.0.3 (or 4.0.2a) release which would only include the
> security fix
> B [ ] Make the security fix available as a binary patch for 4.0.2 (it would
> take the form of an archive to extract in $CATALINA_HOME, and would be
> *small*)
> C [ ] Accelerate the release schedule of 4.0.3, which would include the
> security fix, as well as fixes for other issues with 4.0.2 (with Beta 1 on
> 03/01 and Final on 03/08)
> 
>
> Multiple votes are acceptable. If there are other interesting possibilities,
> let me know.
>
> My vote is 'B'.
>
> In parallel, I'd like to release a first beta of 4.0.3 on 03/01 (depending
> on the vote on item 'C' above, the release cycle may be shorter or longer):
> 
> +1 [ ] I support the release, and I will help
> +0 [ ] I support the release
> -0 [ ] I don't support the release
> -1 [ ] I'm against the release because:
>
>
> 
>
> My vote is +1.
>
> Note: Non-committers are welcome to vote if they feel like it, but the vote
> in that case is non binding.
>
> Remy
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

Logging

[Jay Wright]

Using Tomcat 4, I am trying to accomplish writing logs (preferrably via
System.out and System.err) that have a timestamp on each and every write.
Iplanet and JavaWebServer did this automatically.  It is important to write
to these logs and have them timestamped, WITHOUT writing code that is in any
way web-server specific.

What I have learned about Tomcat 4 logging is this:  All System.out and
System.err print statements go by default to the catalina.out file.  Each
 within tomcat can be written to a specific file via the 
component.  

There are a couple of "questions" that I'm trying to understand.

First - can the catalina.out file be configured through tomcat components
such that all System.out and System.err entries are timestamped.  

Two - What are the api calls to write to the  file and can I
specifiy the verbosity (the level of the entry 0-4) with each entry?

I'm hesitant to use the  since I'm unfamiliar with whether or not
that code would be portable to other web servers?

Thanks,
Jay

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

Re: Tomcat 4.1-dev Host unpackWARs not working

[Craig R. McClanahan]

On Thu, 28 Feb 2002, Glenn Nielsen wrote:

> Date: Thu, 28 Feb 2002 10:57:55 -0600
> From: Glenn Nielsen <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Tomcat 4.1-dev Host unpackWARs not working
>
> "Craig R. McClanahan" wrote:
> >
> > On Thu, 28 Feb 2002, Glenn Nielsen wrote:
> >
> > > Date: Thu, 28 Feb 2002 09:18:39 -0600
> > > From: Glenn Nielsen <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Tomcat 4.1-dev Host unpackWARs not working
> > >
> > > The Host attribute unpackWARs="true" is not working in the Tomcat 4 HEAD CVS
> > > version.
> > >
> > > I think it is due to the following at line 232 in StandardHostDeployer.java
> > > If you turn debug on you will see that a war file in the webapps directory
> > > is deployed using a jar:file URL.
> > >
> > > // Expand a WAR archive into an unpacked directory if needed
> > > // NOTE:  If the user supplies a "jar:file:" URL, assume that
> > > // they do not want WAR expansion even if unpackWARs is set
> > > if (host.isUnpackWARs() && !url.startsWith("jar:file:")) {
> > >
> > > What is the reason for making the above assumption?
> > >
> > > If there is a valid reason for doing this, it should be documented
> > > that unpackWARs="true" works except when ...
> > >
> >
> > This comment is embedded inside the install() method, which accepts a URL
> > to either a WAR or a directory.  Since the person doing the deployment
> > (typically using the manager webapp) consciously made a choice to send one
> > or the other, it's not a good idea for the container to second guess that
> > choice.
> >
>
> I don't think that is a valid assumption.  It may have just been easier for
> the user to install a war file in their hosts webapp directory than install
> the unpacked files.
>

For things inside the appBase directory (i.e. $CATALINA_HOME/webapps by
default), I don't see huge problems with unpacking.  However, if I install
a WAR file with an absolute path that is outside this directory, like
this:

  
http://localhost:8080/manager/install?path=/foo&war=jar:file:/home/craigmcc/mywar.war!/

then there are not very many good options for where to unpack to.  (I
certainly don't want Tomcat creating a directory in my home directory.)
And, what does it mean to dynamically remove an application that has been
deployed this way?  We currently don't delete the auto-unpacked directory,
and neither do we re-unpack on top of it.

IMHO, auto-unpack is a hack we have to keep around for legacy backwards
compatibility.  People doing dynamic install or deploy should choose what
they want to do, and then send that argument (either a directory or a WAR
file).  Auto-unpack should be explicitly defined to work only in the
appBase directory.  Dynamic installation should install exactly what the
user said to install, and not mess around with it.

> There are three ways listed in the manager docs.  A file url, a jar:file url
> and a remote jar url.  The remote jar url does follow the Host config for
> unpackWARs, the jar:file doesn't.
>
> I think the manager should follow the Host config explicitely.  If the
> person using the manager wants to override this, then that should be
> another parameter to the install, i.e. 
>install?path=jar:file:/path-to-war&unpack=false
>
> > I will update the docs on unpackWARs to note that it only applies to
> > auto-deployed apps (from the appBase directory) at startup time.
> >
> > > Regards,
> > >
> > > Glenn
> > >
> >
> > Craig
> >

Craig



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

Re: [4.0.3] [VOTES] Upcoming release and security fix

[Jason Brittain]

Hi Remy and gang..

Below is my non-binding vote (for fun!):

Remy Maucherat wrote:
> Since there are apparently diverging opinions on the subject (and also since
> I didn't get any +1s for a possible 4.0.3 b1, or a 4.0.2a release), here's a
> formal request for vote.
> 
> On the security problem reported yesterday, affecting the security manager
> sandboxing. We should:
> 
> A [X] Make a full 4.0.3 (or 4.0.2a) release which would only include the
> security fix

This looks to me to be the path of least resistance/hassle for everyone
involved, since it's just a small change to the last release.  Release early,
release often.  :)

> B [ ] Make the security fix available as a binary patch for 4.0.2 (it would
> take the form of an archive to extract in $CATALINA_HOME, and would be
> *small*)

Binary patches make me nervous.  Whether this would work best or not
depends on a whole bunch of unspecified factors, so I won't vote for it.

> C [ ] Accelerate the release schedule of 4.0.3, which would include the
> security fix, as well as fixes for other issues with 4.0.2 (with Beta 1 on
> 03/01 and Final on 03/08)
> 

This one would be nice too, but it creates a bunch of extra work for you
it seems (which is my guess as to why you're not voting for it).

> Multiple votes are acceptable. If there are other interesting possibilities,
> let me know.
> 
> My vote is 'B'.
> 
> In parallel, I'd like to release a first beta of 4.0.3 on 03/01 (depending
> on the vote on item 'C' above, the release cycle may be shorter or longer):
> 
> +1 [ ] I support the release, and I will help
> +0 [X] I support the release, and I sure wish I had time to help!!
> -0 [ ] I don't support the release
> -1 [ ] I'm against the release because:


-- 
Jason Brittain

CollabNet http://www.collab.net


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

DO NOT REPLY [Bug 6762] - WebappClassLoader: Lifecycle error : CL stopped

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

WebappClassLoader: Lifecycle error : CL stopped





--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 19:25 ---
I understand, but by doing this, you're violating the J2EE model and
overstepping the container boundaries, so it doesn't have to be supported (and I
don't really see how it could, since, as I said, when the VM is shutdown, the
webapp and related components will have been stopped long before).

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

DO NOT REPLY [Bug 6764] New: - commons-logging error at startup

[bugzilla]

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

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

commons-logging error at startup

   Summary: commons-logging error at startup
   Product: Tomcat 4
   Version: Nightly Build
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

If I put log4j.jar (I'm using version 1.2 alpha 5) in my webapp WEB-INF/lib 
directory (which I need for my application), I get the error below with Tomcat 
4.1dev builds of 20020214, 20020223 and 2002028 (I've only tried with these). 
It works with Tomcat 4.0.2.

If I don't log4j.jar at all in WEB-INF/lib, it works.

I suspect this is an issue due to the introduction of commons-logging.

2002-02-28 18:51:15 HttpConnector Opening server socket on all host IP 
addresses
2002-02-28 18:51:15 HttpConnector[8080] Sarting background thread
2002-02-28 18:51:15 HostConfig[localhost]: Deploying web application archive 
test.war
2002-02-28 18:51:15 StandardHost[localhost]: Installing web application at 
context path /test from URL jar:file:E:\Dev\jakarta-cactus\target\servlet23
\dist\sample\target\test\tomcat40\webapps\test.war!/
2002-02-28 18:51:15 HttpProcessor[8080][0] Starting background thread
2002-02-28 18:51:15 HttpProcessor[8080][1] Starting background thread
2002-02-28 18:51:15 HttpProcessor[8080][2] Starting background thread
2002-02-28 18:51:15 HttpProcessor[8080][3] Starting background thread
2002-02-28 18:51:15 HttpProcessor[8080][4] Starting background thread
2002-02-28 18:51:16 StandardHost[localhost]: MAPPING configuration error for 
request URI 
2002-02-28 18:51:16 StandardContext[/test]: Cannot find message associated 
with key standardContext.namingInitFailed
2002-02-28 18:51:16 WebappLoader[/test]: Deploying class repositories to work 
directory E:\Dev\jakarta-cactus\target\servlet23
\dist\sample\target\test\tomcat40\work\localhost\test
2002-02-28 18:51:16 WebappLoader[/test]: Deploy class files /WEB-INF/classes 
to E:\Dev\jakarta-cactus\target\servlet23\dist\sample\target\test\tomcat40
\webapps\test\WEB-INF\classes
2002-02-28 18:51:16 WebappLoader[/test]: Deploy JAR /WEB-INF/lib/aspectjrt.jar 
to E:\Dev\jakarta-cactus\target\servlet23\dist\sample\target\test\tomcat40
\webapps\test\WEB-INF\lib\aspectjrt.jar
2002-02-28 18:51:16 WebappLoader[/test]: Deploy JAR /WEB-INF/lib/cactus.jar to 
E:\Dev\jakarta-cactus\target\servlet23\dist\sample\target\test\tomcat40
\webapps\test\WEB-INF\lib\cactus.jar
2002-02-28 18:51:16 WebappLoader[/test]: Deploy JAR /WEB-
INF/lib/httpclient.jar to E:\Dev\jakarta-cactus\target\servlet23
\dist\sample\target\test\tomcat40\webapps\test\WEB-INF\lib\httpclient.jar
2002-02-28 18:51:16 WebappLoader[/test]: Deploy JAR /WEB-INF/lib/junit.jar to 
E:\Dev\jakarta-cactus\target\servlet23\dist\sample\target\test\tomcat40
\webapps\test\WEB-INF\lib\junit.jar
2002-02-28 18:51:16 WebappLoader[/test]: Deploy JAR /WEB-INF/lib/log4j.jar to 
E:\Dev\jakarta-cactus\target\servlet23\dist\sample\target\test\tomcat40
\webapps\test\WEB-INF\lib\log4j.jar
2002-02-28 18:51:16 StandardManager[/test]: Seeding random number generator 
class java.security.SecureRandom
2002-02-28 18:51:16 StandardManager[/test]: Seeding of random number generator 
has been completed
2002-02-28 18:51:16 ContextConfig[/test] Parse error in default web.xml
org.apache.commons.logging.LogConfigurationException: 
java.lang.reflect.InvocationTargetException
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance
(LogFactoryImpl.java:464)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance
(LogFactoryImpl.java:273)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:338)
at org.apache.commons.digester.Digester.(Digester.java:309)
at org.apache.catalina.startup.ContextConfig.createWebDigester(Unknown 
Source)
at org.apache.catalina.startup.ContextConfig.defaultConfig(Unknown 
Source)
at org.apache.catalina.startup.ContextConfig.start(Unknown Source)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(Unknown 
Source)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(Unknown Source)

Any idea ?

Thanks
-Vincent

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

Re: [4.0.3] [VOTES] Upcoming release and security fix

[Eric Rescorla]

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

> Since there are apparently diverging opinions on the subject (and also since
> I didn't get any +1s for a possible 4.0.3 b1, or a 4.0.2a release), here's a
> formal request for vote.
> 
> On the security problem reported yesterday, affecting the security manager
> sandboxing. We should:
> 
> A [ ] Make a full 4.0.3 (or 4.0.2a) release which would only include the
> security fix
> B [ ] Make the security fix available as a binary patch for 4.0.2 (it would
> take the form of an archive to extract in $CATALINA_HOME, and would be
> *small*)
> C [ ] Accelerate the release schedule of 4.0.3, which would include the
> security fix, as well as fixes for other issues with 4.0.2 (with Beta 1 on
> 03/01 and Final on 03/08)
> 
My vote is C.

> In parallel, I'd like to release a first beta of 4.0.3 on 03/01 (depending
> on the vote on item 'C' above, the release cycle may be shorter or longer):
> 
> +1 [ ] I support the release, and I will help
> +0 [ ] I support the release
> -0 [ ] I don't support the release
> -1 [ ] I'm against the release because:
> 
> 
> 
> 
> My vote is +1.
+0

-Ekr

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

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

[4.0.3] [VOTES] Upcoming release and security fix

[Remy Maucherat]

Since there are apparently diverging opinions on the subject (and also since
I didn't get any +1s for a possible 4.0.3 b1, or a 4.0.2a release), here's a
formal request for vote.

On the security problem reported yesterday, affecting the security manager
sandboxing. We should:

A [ ] Make a full 4.0.3 (or 4.0.2a) release which would only include the
security fix
B [ ] Make the security fix available as a binary patch for 4.0.2 (it would
take the form of an archive to extract in $CATALINA_HOME, and would be
*small*)
C [ ] Accelerate the release schedule of 4.0.3, which would include the
security fix, as well as fixes for other issues with 4.0.2 (with Beta 1 on
03/01 and Final on 03/08)


Multiple votes are acceptable. If there are other interesting possibilities,
let me know.

My vote is 'B'.

In parallel, I'd like to release a first beta of 4.0.3 on 03/01 (depending
on the vote on item 'C' above, the release cycle may be shorter or longer):

+1 [ ] I support the release, and I will help
+0 [ ] I support the release
-0 [ ] I don't support the release
-1 [ ] I'm against the release because:




My vote is +1.

Note: Non-committers are welcome to vote if they feel like it, but the vote
in that case is non binding.

Remy


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

DO NOT REPLY [Bug 6762] - WebappClassLoader: Lifecycle error : CL stopped

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

WebappClassLoader: Lifecycle error : CL stopped





--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 19:08 ---
Init and destroy methods from the servlet don't work for me. The thing I try to 
achieve is to execute something before the JVM exits. I need to close log files 
and do some additional clean-up processing.

-Georg

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

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

[Bill Barker]

Actually, I was hoping to find time to get started on this once 3.3.1 is out
the door (and hopefully things slow down a bit).

I'm a bit behind on Remy's recent work, but I'm pretty sure that it requires
Java2.
- Original Message -
From: "GOMEZ Henri" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, February 28, 2002 12:31 AM
Subject: RE: cvs commit:
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4
CoyoteConnector.java CoyoteProcessor.java


Hi Remy,

Do you think coyote could be ever used with Tomcat 3.3 ?
ie: works with JDK 1.1, support TC 3.3 via modules

JK/JK2 are available for both TC 3.3/4.x, it could be fine to
have also a common HTTP connector for them and coyote seems
to be the perfect candidate :)

-
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: 

RE: In memory replication - a non intrusive approach

[Filip Hanik]

>>the source code can be found on my web site along with the document
>>describing the implementation.
>>http://www.filip.net/tomcat/tomcat-javagroups.html
>>http://www.filip.net/tomcat/tomcat-javagroups-src.jar
>
>Do you think we could use this stuff in JK/JK2, both
>java and native parts, so we could use it in TC 3.3/4.x ?

Hi Henri,
I'm not really sure what you are asking me. The implementation only does
session replication.
This means that you can place any load balancer in front of it, be it Apache
with mod_jk, or even a hardware balancer and the fail over should work. As
long as the load balancer doesn't modify the session id in the cookie (or
url), the Tomcat server shouldn't really care what is in front of it.

My implementation is for Tomcat 4.x, since the architecture is 4 is
different than 3.x the same implementation will not work for 3.x.
If it was highly desired, I could back port the code into the 3.x source
tree as well.

Did you get a chance to look at the code?

regards
Filip

~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
[EMAIL PROTECTED]
www.filip.net


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

DO NOT REPLY [Bug 6762] - WebappClassLoader: Lifecycle error : CL stopped

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

WebappClassLoader: Lifecycle error : CL stopped

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 18:50 ---
The classloader is destroyed and the webapps stopped long before the VM is
shutdown. That's why it doesn't work.
You should use the container-provided lifecycle handling instead (init and
destroy methods from the servlet).

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

DO NOT REPLY [Bug 6762] New: - WebappClassLoader: Lifecycle error : CL stopped

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

WebappClassLoader: Lifecycle error : CL stopped

   Summary: WebappClassLoader: Lifecycle error : CL stopped
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: PC
   URL: http://http://
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm running JDK 1.3. At Tomcat startup time my web app executes a servlet which 
adds a cleanup thread via Runtime.getRuntime().addShutdownHook( ...)

When I normally shutdown Tomcat the following exception is thrown:

Stopping service Tomcat-Standalone
Stopping service Tomcat-Apache
WebappClassLoader: Lifecycle error : CL stopped
java.lang.NoClassDefFoundError: java/util/Enumeration
at com.replaytv.shared.logger.LogManager.initCleanUp 
(LogManager.java:196)
at com.replaytv.shared.logger.LogCleanUpThread.run
(LogCleanUpThread.java:22)

In this example the class java.util.Enumeration hasn't been used before and is 
therefore not loaded yet. During shutdown, the cleanup thread tries to load the 
class but the Tomcats custom classloader has been removed already.

I work around it by loading the handful of classes I need in the cleanup thread 
during startup via Class.forName( ...).

When the custom classloader is removed shouldn't at least the default class 
loader be set?

-Georg

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

[DOCUMENTATION ERROR] FW: The Tomcat 4 Servlet-JSP Container - Class Loader INFO

[Paulo Gaspar]

-Original Message-
From: CTP Steve Temple [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 28, 2002 2:57 PM
To: [EMAIL PROTECTED]
Subject: The Tomcat 4 Servlet-JSP Container - Class Loader INFO


Hi,

Just a quick one, I noticed that on the following page under Quick Start the
s is missing from the end of /WEB-INF/classes

 http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html

Thanks

Steve

--
Steve Temple
Software Engineer
CTP information management
+44 (0)1242 542271
[EMAIL PROTECTED]
www.ctpi.co.uk



The Tomcat 4 Servlet-JSP Container - Class Loader INFO.url
Description: Binary data

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

DO NOT REPLY [Bug 6761] New: - The rpm of tomcat4-webapps-4.0.2-3.noarch.rpm has the wrong port

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

The rpm of  tomcat4-webapps-4.0.2-3.noarch.rpm has the wrong port

   Summary: The rpm of  tomcat4-webapps-4.0.2-3.noarch.rpm has the
wrong port
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: PC
   URL: http://localhost:8080/
OS/Version: Linux
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The rpm when download and installed on linux RedHat 7.2 will have the 
sever.xml file pointing to port 8180 instead of 8080.  I spent a lot of time 
trying to figure this one out.  It seems to work fine, i.e. I get the 
index.html file now.  

If you are able to confirm this, would you please respond to John Niven mail 
with the Subject: RE: tomcat waiting in linux  and tell him that he is right.

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

Multiple instances of Filter class

[Kim Altintop]

Hi,

I've got a webapp that reads almost everything from a database. As this
causes a lot of overhead, I implemented a Filter that caches whole pages
(or images or whatever requested) to the filesystem and serves these to
subsequent requests with the same URI. Additionally, all HTTP headers that
I generate from the database records are kept in memory and set every time
a cached page is requested. Naturally, if Tomcat is stopped or restarted,
the in-memory cache entries are lost and the fs is cluttered with stale
cache files. To work around this problem, I created a subclass of
java.lang.Thread to frequently check if the files are still valid (that is,
present in the cache table) and delete them if necessary. For this purpose
it is absolutely necessary, that only one instance of each the cache table
(a HashMap) and the cleanup thread is present in the webapp.

The servlet spec says [version 2.3, section SRV.6.2.1 "Filter Lifecycle"]: 

"Only one instance per filter declaration in the deployment descriptor is
instantiated per Java virtual machine of the container."


However, I discovered that this is not true with Tomcat (I'm running
4.0.2-LE under JDK1.4/Win2000), as you can easily verify by installing the
following code as a filter in your webapp:

public class DummyFilter
implements Filter {
private static int instance = 0;

public void init(FilterConfig config) {
System.out.println("DummyFilter.init [" + instance + "]");
instance++;
}

public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
throws ServletException, IOException {
System.out.println("DummyFilter.doFilter");
chain.doFilter(request, response);
}

public void destroy() {
System.out.println("DummyFilter.destroy");
}
}


One would expect the init() method to print "DummyFilter.init [0]" exactly
one time on stdout, when Tomcat is started (or the webapp is deployed).
However, what happens is, that the same String is printed TWICE (yes,
instance is 0 each time). I then changed the init() code to print 

  ClassLoader myloader = this.getClass().getClassLoader();
  System.out.println(myloader.getClass().getName() + "[" +
myloader.hashCode() + "]");

and the result was, that two different hash codes were printed. 
For this reason I suspect that there are actually TWO WebappClassLoaders
installed for my application, each of which instantiating DummyFilter (in
which case the behaviour of the static variable is correct, I believe...).


Am I missing something or could this be considered a bug?

Thanks in advance for any enlightenment..
Kim

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContext.java StandardHost.java

[glenn]

glenn   02/02/28 09:20:56

  Modified:.RELEASE-NOTES-4.1-dev.txt
   catalina/docs/config host.html
   catalina/src/share/org/apache/catalina/core
StandardContext.java StandardHost.java
  Log:
  Added the Engine name as a directory path component when creating
  the default work directory for a web application.  This fixes a bug
  where the same work directory would be used for the http and https version
  of a virtual host.
  
  Added the workDir attribute to the Host configuration.  This makes it
  easier to set the base directory where the work directories for
  applications are placed when virtual hosting sites with Tomcat.
  
  Revision  ChangesPath
  1.3   +9 -1  jakarta-tomcat-4.0/RELEASE-NOTES-4.1-dev.txt
  
  Index: RELEASE-NOTES-4.1-dev.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1-dev.txt,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- RELEASE-NOTES-4.1-dev.txt 5 Jan 2002 22:40:23 -   1.2
  +++ RELEASE-NOTES-4.1-dev.txt 28 Feb 2002 17:20:56 -  1.3
  @@ -3,7 +3,7 @@
   Release Notes
   =
   
  -$Id: RELEASE-NOTES-4.1-dev.txt,v 1.2 2002/01/05 22:40:23 larryi Exp $
  +$Id: RELEASE-NOTES-4.1-dev.txt,v 1.3 2002/02/28 17:20:56 glenn Exp $
   
   
   
  @@ -39,6 +39,9 @@
   Catalina New Features:
   -
   
  +Added the workDir attribute to the Host configuration in server.xml.
  +This makes it easier to configure a different location for each
  +virtual hosts application work directories.
   
   ---
   Jasper New Features:
  @@ -48,6 +51,11 @@
   
   Webapps New Features:
   
  +
  +The default work directory created for a web application now includes the
  +Engine name as a directory in work directory path name.  This ensures that
  +if you have two Host's with the same host name (one http, one https) configured
  +in different Engine's, they will each have their own unique work directory.
   
   
   ==
  
  
  
  1.5   +16 -0 jakarta-tomcat-4.0/catalina/docs/config/host.html
  
  Index: host.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/docs/config/host.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- host.html 21 Mar 2001 01:59:19 -  1.4
  +++ host.html 28 Feb 2002 17:20:56 -  1.5
  @@ -88,6 +88,22 @@
   
 
   
  +  
  +workDir
  +
  +  Pathname to a scratch directory to be used by applications for 
  +  this Host. Each application will have its own sub directory with
  +  temporary read-write use.  Configuring a Context workDir will override
  +  use of the Host workDir configuration.  The
  +  corresponding directory will be made visible as a servlet context
  +  attribute (of type java.io.File) with the standard name
  +  assigned by the Servlet API Specification, version 2.2
  +  (javax.servlet.context.tempdir).  If not specified, a
  +  suitable directory underneath Catalina's home directory will be
  +  assigned automatically.
  +
  +  
  +
   
   
   
  
  
  
  1.100 +29 -13
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.99
  retrieving revision 1.100
  diff -u -r1.99 -r1.100
  --- StandardContext.java  27 Feb 2002 02:34:54 -  1.99
  +++ StandardContext.java  28 Feb 2002 17:20:56 -  1.100
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.99 2002/02/27 02:34:54 remm Exp $
  - * $Revision: 1.99 $
  - * $Date: 2002/02/27 02:34:54 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.100 2002/02/28 17:20:56 glenn Exp $
  + * $Revision: 1.100 $
  + * $Date: 2002/02/28 17:20:56 $
*
* 
*
  @@ -147,7 +147,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.99 $ $Date: 2002/02/27 02:34:54 $
  + * @version $Revision: 1.100 $ $Date: 2002/02/28 17:20:56 $
*/
   
   public class StandardContext
  @@ -3829,16 +3829,28 @@
*/
   private void postWorkDirectory() {
   
  -// Retrieve our parent (normally a host) name
  -String parentName = null;
  -if (getParent() != null)
  -parentName = getParent().

Re: Tomcat 4.1-dev Host unpackWARs not working

[Craig R. McClanahan]

On Thu, 28 Feb 2002, Glenn Nielsen wrote:

> Date: Thu, 28 Feb 2002 10:41:40 -0600
> From: Glenn Nielsen <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Tomcat 4.1-dev Host unpackWARs not working
>
> "Craig R. McClanahan" wrote:
> >
> > On Thu, 28 Feb 2002, Glenn Nielsen wrote:
> >
> > > Date: Thu, 28 Feb 2002 09:18:39 -0600
> > > From: Glenn Nielsen <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Tomcat 4.1-dev Host unpackWARs not working
> > >
> > > The Host attribute unpackWARs="true" is not working in the Tomcat 4 HEAD CVS
> > > version.
> > >
> > > I think it is due to the following at line 232 in StandardHostDeployer.java
> > > If you turn debug on you will see that a war file in the webapps directory
> > > is deployed using a jar:file URL.
> > >
> > > // Expand a WAR archive into an unpacked directory if needed
> > > // NOTE:  If the user supplies a "jar:file:" URL, assume that
> > > // they do not want WAR expansion even if unpackWARs is set
> > > if (host.isUnpackWARs() && !url.startsWith("jar:file:")) {
> > >
> > > What is the reason for making the above assumption?
> > >
> > > If there is a valid reason for doing this, it should be documented
> > > that unpackWARs="true" works except when ...
> > >
> >
> > This comment is embedded inside the install() method, which accepts a URL
> > to either a WAR or a directory.  Since the person doing the deployment
> > (typically using the manager webapp) consciously made a choice to send one
> > or the other, it's not a good idea for the container to second guess that
> > choice.
> >
> > I will update the docs on unpackWARs to note that it only applies to
> > auto-deployed apps (from the appBase directory) at startup time.
> >
>
> Craig,
>
> My point is that unpackWARs is _NOT_ working correctly during autodeploy
> at startup.  Perhaps because it is deploying using a jar:file URL.
>

Ah ... must have broken that along the way :-(.  Will be fixed shortly.

> Glenn
>

Craig


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

Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670

[Christopher K . St . John]

"Craig R. McClanahan" wrote:
> 
> Internal references from one package to another (say,
> org.apache.catalina.realm to org.apache.catalina.core) are much less
> desireable. 
> ...
> Is it appropriate to go through the exercise of identifying the
> offending cases and defining proposed changes to implement them?
> Yah, it's definitely time for that to happen.
> 

 Currently, AuthenticatorBase depends on StandardContext. It's
not some deep dependency. AuthenticatorBase just wants to set
its debug level to be the same as its Context. There's an
instanceof check before the cast, so AuthenticatorBase doesn't
actually require that its parent be a StandardContext, but
it does require that StandardContext exists. It produces a 
'mystery dependency' that is invisible from the outside. 

 I may be preaching to the converted, but mystery dependencies
are bad. They make the code brittle and hard to understand.
They lead to spaghetti.

 I reported the dependency as a bug (with a patch) and the
bug was changed to a feature request. I suppose it depends
on how you look at it. It's certainly a bug for me. 

 There are a couple of ways to fix the problem:

 1) Delete the offending code. Easiest, and in this case
 probably reasonable. You'll lose the debug-setting 
 propagation, but you can always set that manually. It's for
 debugging so presumably you're messing with the settings
 any case. My patch did this, I'd like to see it applied.

 2) Move setDebug() up to the Context or Container level.
 They all implement setDebug() anyway, right? And it doesn't
 break compatibility with old code. Med/long term, this would
 probably be a good solution.

 3) Create a Debug interface. Pretty much everything in 
 Catalina has set/getDebug() methods, not just Containers.
 But it's overkill. Each new class or interface adds
 conceptual overhead to the system. I don't think it's
 worth it.

 Whether you like the idea of something like MimimalTomcat
or not, I suspect writing it will turn up some problems
(and solutions) that will improve all of the Catalina code.


 While we're on the subject of interfaces, what is
Context.findRoleMapping() for? I've got it stubbed out in
MinimalTomcat, but I'd like to know what I'm stubbing out.
It used to be used in HttpRequestBase.isUserInRole(), but
the call was replaced by a call to Context.findSecurityRole().
 

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

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

Re: Tomcat 4.1-dev Host unpackWARs not working

[Craig R. McClanahan]

On Thu, 28 Feb 2002, Glenn Nielsen wrote:

> Date: Thu, 28 Feb 2002 09:18:39 -0600
> From: Glenn Nielsen <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Tomcat 4.1-dev Host unpackWARs not working
>
> The Host attribute unpackWARs="true" is not working in the Tomcat 4 HEAD CVS
> version.
>
> I think it is due to the following at line 232 in StandardHostDeployer.java
> If you turn debug on you will see that a war file in the webapps directory
> is deployed using a jar:file URL.
>
> // Expand a WAR archive into an unpacked directory if needed
> // NOTE:  If the user supplies a "jar:file:" URL, assume that
> // they do not want WAR expansion even if unpackWARs is set
> if (host.isUnpackWARs() && !url.startsWith("jar:file:")) {
>
> What is the reason for making the above assumption?
>
> If there is a valid reason for doing this, it should be documented
> that unpackWARs="true" works except when ...
>

This comment is embedded inside the install() method, which accepts a URL
to either a WAR or a directory.  Since the person doing the deployment
(typically using the manager webapp) consciously made a choice to send one
or the other, it's not a good idea for the container to second guess that
choice.

I will update the docs on unpackWARs to note that it only applies to
auto-deployed apps (from the appBase directory) at startup time.

> Regards,
>
> Glenn
>

Craig


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

DO NOT REPLY [Bug 6748] - Reduce amount of logging through WarpEngine, WarpHost

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

Reduce amount of logging through WarpEngine, WarpHost





--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 15:29 ---
Submitted patch for 4.0 branch (warp stuff still residing in tomcat module) and 
HEAD (warp stuff migrated to j-t-c), basically the same patch.  Used the easy 
mechanism of logging only if debugging is on.

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

DO NOT REPLY [Bug 6748] - Reduce amount of logging through WarpEngine, WarpHost

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

Reduce amount of logging through WarpEngine, WarpHost





--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 15:27 ---
Created an attachment (id=1247)
j-t-c patch of WarpEngine, WarpHost (for HEAD branch)

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

DO NOT REPLY [Bug 6748] - Reduce amount of logging through WarpEngine, WarpHost

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

Reduce amount of logging through WarpEngine, WarpHost





--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 15:27 ---
Created an attachment (id=1246)
4.0 branch patch for WarpEngine, WarpHost

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

DO NOT REPLY [Bug 5976] - Tomcat 4.0.2B2 + Security Manager + JSSE don't work together

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

Tomcat 4.0.2B2 + Security Manager + JSSE don't work together

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

FW: The Tomcat 4 Servlet-JSP Container - Class Loader INFO

[Pier Fumagalli]

Not Acked...

Pier

-- Forwarded Message
> From: [EMAIL PROTECTED] (CTP Steve Temple)
> Date: Thu, 28 Feb 2002 13:57:14 -
> To: <[EMAIL PROTECTED]>
> Subject: The Tomcat 4 Servlet-JSP Container - Class Loader INFO
> 
> Hi,
> 
> Just a quick one, I noticed that on the following page under Quick Start the s
> is missing from the end of /WEB-INF/classes
> 
> http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html
> 
> Thanks
> 
> Steve
> 
> --
> Steve Temple
> Software Engineer
> CTP information management
> +44 (0)1242 542271
> [EMAIL PROTECTED]
> www.ctpi.co.uk
> 

-- End of Forwarded Message




The Tomcat 4 Servlet-JSP Container - Class Loader INFO.url
Description: Binary data

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

RE: In memory replication - a non intrusive approach

[GOMEZ Henri]

>Hi Henri,
>the source code can be found on my web site along with the document
>describing the implementation.
>http://www.filip.net/tomcat/tomcat-javagroups.html
>http://www.filip.net/tomcat/tomcat-javagroups-src.jar

Do you think we could use this stuff in JK/JK2, both
java and native parts, so we could use it in TC 3.3/4.x ?

>There is one thing that I would like to change if this 
>implementation became
>a part of tomcat-catalina.
>I would rather make the GenericPrincipal be serializable than 
>having to wrap
>the principal information in my SerializablePrincipal.
>
>But for this implementation I didn't want to touch any of the 
>other code
>since nobody could use my stuff if that was the case.
>
>let me know what you think?
>Filip
>
>~
>Namaste - I bow to the divine in you
>~
>Filip Hanik
>Software Architect
>[EMAIL PROTECTED]
>www.filip.net
>
>>-Original Message-
>>From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, February 27, 2002 2:38 AM
>>To: Tomcat Developers List
>>Subject: RE: In memory replication - a non intrusive approach
>>
>>
>>>Hi Remy,
>>>thanks for getting back to me.
>>>
Yes, why not.
Note that the feature is:
- a bit redundant with JK/JK2 load balancing, so it's not my
>>>top priority
personally
- currently in alpha/unsupported status
>>>
>>>I'm not sure about the JK/JK2 load balancing feature, but from
>>>the name of
>>>it, I don't think they are redundant, they are two pieces that
>>>complete the
>>>puzzle. See my implementation only does session replication,
>>>nothing else.
>>>If you have JK/JK2 do loadbalancing between the different
>>>tomcat servers and
>>>session replication, then you are all good to go. A complete cluster
>>>solution.
>>
>>LoadBalancing + SessionReplication are not redundant, they are the
>>2 major piece of Failover/Recovery, and I'll be more than happy to
>>see that piece of code.
>>
>>I proposed sometimes ago to add such functionnality in jk/jk2, by
>>extending jk protocol to forward  to web server, http answers and
>>also ALL session ID + session DATA (when there is an update).
>>
>>In recover mode, a backup tomcat could then receive REQUEST AND
>>SESSION ID/SESSION DATA which where produced previously by master
>>tomcat.
>>
>>>Where do I look at the JK/JK2 code?
>>
>>jakarta-tomcat-connectors
>>
>>>And where/to who do I send my files to be submitted to CVS?
>>
>>Send it to the list, we take all a revue and commit it if
>>everybody agree :)
>>
>>I'll take a definitive look at it
>>
>>--
>>To unsubscribe, e-mail:
>>[EMAIL PROTECTED]>
>>For additional
>>commands, e-mail:
>>
>>
>>
>
>
>--
>To unsubscribe, e-mail:   

For additional commands, e-mail: 


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

Re: [4.0.3] Beta 1 release

[Renato]

 I guess security issues have to be always a priority. I think we can live with 4.0.2a 
( there is a Tomcat 3.3a and I imagine people are used to it ) and a 4.0.3-B1.
  Remy Maucherat <[EMAIL PROTECTED]> wrote: Hi,

I'd like to propose to release Tomcat 4.0.3 Beta 1 at the end of this week
(03/01 seems an appropriate target). This release will include the fix for
the security issue publicized earlier today, as well as other fixes. I
personally don't think the issue is significant enough so that there's the
need for a full 4.0.2a release, or an emergency 4.0.3 release.

I will also make available a binary patch for 4.0.2 Final, which will fix
the vulnerability. Note: This has never been done in the past, so I'm not
convinced this is really a good idea. Security patches could be *the*
exception, and justify it.

Votes / comments ?

Remy


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



-
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!

DO NOT REPLY [Bug 5976] - Tomcat 4.0.2B2 + Security Manager + JSSE don't work together

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

Tomcat 4.0.2B2 + Security Manager + JSSE don't work together

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 12:41 ---
Thanks Glenn !

With the extra security permissions it worked fine !

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

DO NOT REPLY [Bug 5899] - HTTP POST parameters ignored in CGIServlet.java

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

HTTP POST parameters ignored in CGIServlet.java





--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 12:33 ---
I have checked the code, it seems the code ignore the HTTP POST data which is
collected by the CGIRunner.getPostInput() method. Therefore there is NO way for
the Perl script to handle the HTTP POST request.

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

problem with jspc

[Kavita Bhattacharjee]

While running the command jspc in tomcat\bin with -webapp option.
It gave a error.The problem deduced is...
 All the JSP files include another JSP file i.e, ImagePath.jsp which
contains
<%
   org.apache.struts.util.PropertyMessageResources _resBundle =
(org.apache.struts.util.PropertyMessageResources)
getServletContext().getAttribute("ZLABOR_CONFIG");
   String ZLaborImgDir =
_resBundle.getMessage(request.getLocale(),"ZLABOR_IMAGES_DIR");
%>

while executing the jspc -webapp command it give error saying the Bad file
argument to include. 
The line it shows as error is <%@ include file="ImagePath.jsp" %>

Any idea what could be wrong?
Need help immediately.

Thanks in advance

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

DO NOT REPLY [Bug 5899] - HTTP POST parameters ignored in CGIServlet.java

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

HTTP POST parameters ignored in CGIServlet.java





--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 12:03 ---
Created an attachment (id=1243)
XML document that Tomcat doesn't like (see my comments)

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

DO NOT REPLY [Bug 5899] - HTTP POST parameters ignored in CGIServlet.java

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

HTTP POST parameters ignored in CGIServlet.java

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 12:01 ---
I've experienced a similar problem when upgrading from Tomcat 3.3.3a to Tomcat 
4.

The test code in my servlet uses .getParameterNames() to list all parameters 
POSTed to it. I'm using Perl with LWP:UserAgent to make a POST request to the 
servlet with one field containing a URLEncoded XML document about 1Kb in size.

Even when I reduce to the size of the XML document the servlet still does not 
get passed the paramter. When I substitute the document for an ASCII string of 
the same length the parameter does get passed. Therefore I'm guessing that 
there is something in the XML document that Tomcat doesn't like. I've attached 
the document as fails.xml.

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

time out error

[Mahesh Agarwal]

Hi All

I am using loadrunner to test my application. When i am setting 5 users to
connect to my server (I am using JBoss-2.4.1_Tomcat-3.2.3) ,it is
successful. But when increases the count to 10 users, its giving timeout
error for everyone. Can any body please solve out issue.

thanks a lot in advance

Mahesh


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

DO NOT REPLY [Bug 5762] - CGI servlet misses to include port number in HTTP_HOST environment variable

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

CGI servlet misses to include port number in HTTP_HOST environment variable

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |



--- Additional Comments From [EMAIL PROTECTED]  2002-02-28 09:45 
---
I tried the patch from 6668 and it did not change the outcome of my test
script, the result is still wrong.

Does it really work in your environment? Did you really run the test script
that I provided?

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

Re: [4.0.3] Beta 1 release

[jean-frederic clere]

Remy Maucherat wrote:
> 
> Hi,
> 
> I'd like to propose to release Tomcat 4.0.3 Beta 1 at the end of this week
> (03/01 seems an appropriate target). This release will include the fix for
> the security issue publicized earlier today, as well as other fixes. I
> personally don't think the issue is significant enough so that there's the
> need for a full 4.0.2a release, or an emergency 4.0.3 release.
> 
> I will also make available a binary patch for 4.0.2 Final, which will fix
> the vulnerability. Note: This has never been done in the past, so I'm not
> convinced this is really a good idea. Security patches could be *the*
> exception, and justify it.
> 
> Votes / comments ?

I would prefer to see 4.0.3 as 4.0.2 + security patch very quickly and 4.0.4
Beta 1 little later.

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

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

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

[GOMEZ Henri]

Hi Remy,

Do you think coyote could be ever used with Tomcat 3.3 ?
ie: works with JDK 1.1, support TC 3.3 via modules 

JK/JK2 are available for both TC 3.3/4.x, it could be fine to
have also a common HTTP connector for them and coyote seems
to be the perfect candidate :)

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



>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 27, 2002 9:24 AM
>To: [EMAIL PROTECTED]
>Subject: cvs commit:
>jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4
>CoyoteConnector.java CoyoteProcessor.java
>
>
>remm02/02/27 00:24:08
>
>  Modified:coyote/src/java/org/apache/coyote/tomcat4
>CoyoteConnector.java CoyoteProcessor.java
>  Log:
>  - Code cleanup: remove old debug code for the thread pool, 
>use exclusively
>internationalized strings.
>  
>  Revision  ChangesPath
>  1.2   +62 -97
>jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tom
>cat4/CoyoteConnector.java
>  
>  Index: CoyoteConnector.java
>  ===
>  RCS file: 
>/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/
>coyote/tomcat4/CoyoteConnector.java,v
>  retrieving revision 1.1
>  retrieving revision 1.2
>  diff -u -r1.1 -r1.2
>  --- CoyoteConnector.java 17 Jan 2002 21:08:44 -  1.1
>  +++ CoyoteConnector.java 27 Feb 2002 08:24:08 -  1.2
>  @@ -1,7 +1,7 @@
>   /*
>  - * $Header: 
>/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/
>coyote/tomcat4/CoyoteConnector.java,v 1.1 2002/01/17 21:08:44 
>remm Exp $
>  - * $Revision: 1.1 $
>  - * $Date: 2002/01/17 21:08:44 $
>  + * $Header: 
>/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/
>coyote/tomcat4/CoyoteConnector.java,v 1.2 2002/02/27 08:24:08 
>remm Exp $
>  + * $Revision: 1.2 $
>  + * $Date: 2002/02/27 08:24:08 $
>*
>* 
>
>*
>  @@ -103,7 +103,7 @@
>*
>* @author Craig R. McClanahan
>* @author Remy Maucherat
>  - * @version $Revision: 1.1 $ $Date: 2002/01/17 21:08:44 $
>  + * @version $Revision: 1.2 $ $Date: 2002/02/27 08:24:08 $
>*/
>   
>   
>  @@ -326,12 +326,6 @@
>   "org.apache.coyote.http11.Http11Processor";
>   
>   
>  -/**
>  - * Coyote Processor class.
>  - */
>  -private Class processorClass = null;
>  -
>  -
>   // 
>- 
>Properties
>   
>   
>  @@ -839,11 +833,9 @@
>*/
>   public Request createRequest() {
>   
>  -//if (debug >= 2)
>  -//log("createRequest: Creating new request");
>   CoyoteRequest request = new CoyoteRequest();
>   request.setConnector(this);
>  -return null;//(request);
>  +return (request);
>   
>   }
>   
>  @@ -854,11 +846,9 @@
>*/
>   public Response createResponse() {
>   
>  -//if (debug >= 2)
>  -//log("createResponse: Creating new response");
>   CoyoteResponse response = new CoyoteResponse();
>   response.setConnector(this);
>  -return null;//(response);
>  +return (response);
>   
>   }
>   
>  @@ -873,8 +863,6 @@
>*/
>   void recycle(CoyoteProcessor processor) {
>   
>  -//if (debug >= 2)
>  -//log("recycle: Recycling processor " + 
>processor);
>   processors.push(processor);
>   
>   }
>  @@ -893,22 +881,14 @@
>   
>   synchronized (processors) {
>   if (processors.size() > 0) {
>  -// if (debug >= 2)
>  -// log("createProcessor: Reusing existing 
>processor");
>   return ((CoyoteProcessor) processors.pop());
>   }
>   if ((maxProcessors > 0) && (curProcessors < 
>maxProcessors)) {
>  -// if (debug >= 2)
>  -// log("createProcessor: Creating new processor");
>   return (newProcessor());
>   } else {
>   if (maxProcessors < 0) {
>  -// if (debug >= 2)
>  -// log("createProcessor: Creating new 
>processor");
>   return (newProcessor());
>   } else {
>  -// if (debug >= 2)
>  -// log("createProcessor: Cannot create 
>new processor");
>   return (null);
>   }
>   }
>  @@ -964,14 +944,12 @@
>*/
>   private CoyoteProcessor newProcessor() {
>   
>  -//if (debug >= 2)
>  -//log("newProcessor: Creating new processor");
>   CoyoteProcessor pr

RE: Apache+SSL+mod_jk cache control headers issue

[GOMEZ Henri]

>> Could you try to use mod_jk from jakarta-tomcat-connectors against
>> TC 3.3 and TC 4.0.2 ?
>I have done those tests whith tomcat 4.0.2. I'm going to try 
>with tomcat-3.3

Thanks to verify if you have also the problem with TC 3.3 / 4.0.2
http connector in SSL mode (HTTP/1.O for TC 3.3), (HTTP/1.1 for TC 4.0.2)

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