RE: Decoding problems.

[cmanolache]

I found the problem, I'm working on a fix. 

It happens only when you send the high bytes ( well, the URL is supposed
to have only ASCII ), and the query decoding defaults right now to UTF8.
The simple fix is to change the default to 8859_1, as required by spec,
but the right fix is to pass the detected encoding. 

Thant's for finding that.

Costin


On Mon, 18 Jun 2001, Angel Aray wrote:

> Encoding of mail messages seems to also be a problem. :(
> 
> The test data was supposed to have tildes, but outlook decided to remove
> them.
> 
> here is the encoded version:
> test+%E1%E9%ED%F3
> 
> 
> -Original Message-
> From: Angel Aray [mailto:[EMAIL PROTECTED]]
> Sent: Lunes, 18 de Junio de 2001 01:47 p.m.
> To: [EMAIL PROTECTED]
> Subject: RE: Decoding problems.
> 
> 
> Here is a simple example:
> 
> first a form:
> 
> 
> 
> 
> 
> 
> 
> MSG: 
> 
> 
> 
> 
> 
> 
> second a echo.jsp to process de data.
> <%
>String msg= request.getParameter("msg");
> %>
> 
> 
> MSG: <%= msg %>
> 
> 
> 
> 
> test with:
> test aeiou
> 
> this will only echo the word test.
> 
> if you remove the meta tag form the html form the problem goes away.
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Lunes, 18 de Junio de 2001 12:36 p.m.
> To: 'Tomcat-Dev
> Subject: Re: Decoding problems.
> 
> 
> Can you send a URI that shows the problem ( including the special chars )?
> Are the chars encoded ( %something ) or not ? This is an important one,
> thanks for the report.
> 
> Costin
> 
> 
> 
> On Mon, 18 Jun 2001, Angel Aray wrote:
> 
> >
> > I am having problems with tomcat handlings of special characters.
> > Whenever some data is post/get that contains special characters (i.e.
> > characters with accents, tildes, etc) the request parameter gets truncated
> > up to the occurrence of the first special character.
> >
> > I would like to help and fix this bug, but I don't know where to
> > start. One thing I did try was to disable de Decode Interceptor but
> > that had no effect.
> >
> >
> > Any hints where to start looking will be appreciated.
> >
> >
> > P.S: I am using  tomcat33 out of CVS and the problem appeared recently. I
> > had an about 3 weeks old tomcat out of CVS and the problem was not there.
> I
> > hope this helps to find/solve this bug.
> >
> >
> >
> > Regards.
> >
> > Angel Aray.
> >
> 

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler BeanRepository.java

[remm]

remm01/06/18 21:17:43

  Modified:jasper/src/share/org/apache/jasper/compiler
BeanRepository.java
  Log:
  - Make Jasper dynamically retrieve the classloader instead of sticking with the
same classloader, which was breaking reloading (since Jasper was using the
old classloader, it was never able to pick up changes).
  
  Revision  ChangesPath
  1.2   +9 -9  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanRepository.java
  
  Index: BeanRepository.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanRepository.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- BeanRepository.java   2000/08/12 00:52:07 1.1
  +++ BeanRepository.java   2001/06/19 04:17:42 1.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanRepository.java,v
 1.1 2000/08/12 00:52:07 pierred Exp $
  - * $Revision: 1.1 $
  - * $Date: 2000/08/12 00:52:07 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanRepository.java,v
 1.2 2001/06/19 04:17:42 remm Exp $
  + * $Revision: 1.2 $
  + * $Date: 2001/06/19 04:17:42 $
*
* 
* 
  @@ -84,7 +84,6 @@
   Vector appBeans;
   Vector requestBeans;
   Hashtable beanTypes;
  -ClassLoader loader;
   
   public BeanRepository (ClassLoader loader) {
sessionBeans = new Vector(11);
  @@ -92,7 +91,6 @@
appBeans = new Vector(11);
requestBeans= new Vector(11);
beanTypes= new Hashtable ();
  - this.loader = loader;
   }
   
   public boolean checkSessionBean (String s) {
  @@ -168,7 +166,8 @@
   throws ClassNotFoundException {
Class cls = null;
//try {
  - cls = loader.loadClass(clsname) ;
  + cls = Thread.currentThread().getContextClassLoader().loadClass
  +(clsname) ;
//} catch (ClassNotFoundException ex) {
//return false;
//}
  @@ -178,7 +177,8 @@
   public Class getBeanType (String bean) throws JasperException {
Class cls = null;
try {
  - cls = loader.loadClass((String)beanTypes.get(bean)) ;
  + cls = Thread.currentThread().getContextClassLoader().loadClass
  +((String)beanTypes.get(bean)) ;
} catch (ClassNotFoundException ex) {
throw new JasperException (ex);
}
  @@ -213,7 +213,7 @@
throws ClassNotFoundException {
Class cls = null;
if (clsname != null) {
  - cls =  loader.loadClass (clsname);
  + cls = Thread.currentThread().getContextClassLoader().loadClass 
(clsname);
}
return cls;
   }
  @@ -221,7 +221,7 @@
   public boolean beanFound (String beanName)
throws ClassNotFoundException {
try {
  - Beans.instantiate (loader, beanName);
  + Beans.instantiate(Thread.currentThread().getContextClassLoader(), 
beanName);
return true;
} catch (java.io.IOException ex) {
// Ignore it for the time being.
  
  
  

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

[remm]

remm01/06/18 21:17:27

  Modified:jasper/src/share/org/apache/jasper JspEngineContext.java
  Log:
  - Make Jasper dynamically retrieve the classloader instead of sticking with the
same classloader, which was breaking reloading (since Jasper was using the
old classloader, it was never able to pick up changes).
  
  Revision  ChangesPath
  1.9   +4 -4  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspEngineContext.java
  
  Index: JspEngineContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspEngineContext.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- JspEngineContext.java 2001/03/22 16:39:27 1.8
  +++ JspEngineContext.java 2001/06/19 04:17:26 1.9
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspEngineContext.java,v
 1.8 2001/03/22 16:39:27 glenn Exp $
  - * $Revision: 1.8 $
  - * $Date: 2001/03/22 16:39:27 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspEngineContext.java,v
 1.9 2001/06/19 04:17:26 remm Exp $
  + * $Revision: 1.9 $
  + * $Date: 2001/06/19 04:17:26 $
*
* 
* 
  @@ -190,7 +190,7 @@
* this JSP? I don't think this is used right now -- akv. 
*/
   public ClassLoader getClassLoader() {
  -return loader;
  +return Thread.currentThread().getContextClassLoader();
   }
   
   /**
  
  
  

[t4] [patch] for "inconvenient" -config current dir

[Geoff Soutter]

Hi there,

As I've been twiddling with T4 again recently this problem has resurfaced.
In T3, I was able to specify the -config option relative to my current
directory. T4 has changed this so that a relative path used with -config is
resolved relative to CATALINA_HOME.

I find this annoying because I like to store my server.xml files into our
version control system, and it means that relative paths from my VCS work
dir to the server.xml don't work any more. I have to use something like
//tomcat4/server.xml. Now, if you use an IDE to debug your
servlet in Tomcat, you need to enter this path into the config. And that
means that every time you create a new work dir, you need to update your IDE
project file.

So, can we please change back to "-config relative to the CWD" the way
Tomcat 3 worked? Or perhaps at least get it to check for it relative to CWD
before checking relative to CATALINA_HOME?

All thats required is to remove/change the absolute path stuff in the
configFile() method of Catalina.java like so:

protected File configFile() {
  File file = new File(configFile);
  /*
  NOTE: alternatively use !file.exists() here for "fallback"
  from CWD to CATALINA_HOME
  if (!file.isAbsolute())
file = new File(System.getProperty("catalina.home") +
  File.separator + configFile);
  */
  return (file);
}

Geoff

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp Ajp13Packet.java

[seguin]

seguin  01/06/18 20:15:34

  Modified:jk/java/org/apache/ajp Ajp13Packet.java
  Log:
  psuedo-fix for bug 1528.
  
  it would be better if when buffer overflow is detected, and exception is thrown,
  rather than printing a message and letting an error be thrown.
  
  Revision  ChangesPath
  1.7   +1 -1  
jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13Packet.java
  
  Index: Ajp13Packet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13Packet.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- Ajp13Packet.java  2001/06/08 19:49:51 1.6
  +++ Ajp13Packet.java  2001/06/19 03:15:32 1.7
  @@ -304,7 +304,7 @@
*/
   public void appendBytes( byte b[], int off, int numBytes ) {
   appendInt( numBytes );
  -if( pos + numBytes > buff.length ) {
  +if( pos + numBytes >= buff.length ) {
   System.out.println("Buffer overflow " + buff.length + " " + pos + " " + 
numBytes );
   // XXX Log
   }
  
  
  

Patch for bug 1528

[Marc Saegesser]

Larry,

I fixed bug 1528 in tomcat_32 and I think a similar problems exists in 3.3
in the class org.apache.tomcat.modules.server.Ajp13.  A diff is attached.  I
don't have a buildable 3.3 project now so I can't test it.

 Ajp13.diff

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service/connector MsgBuffer.java

[marcsaeg]

marcsaeg01/06/18 19:42:23

  Modified:src/share/org/apache/tomcat/service/connector Tag: tomcat_32
MsgBuffer.java
  Log:
  Fix buffer bounds check.
  
  PR: 1528
  Submitted by: [EMAIL PROTECTED]
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.7.2.2   +4 -4  
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/MsgBuffer.java
  
  Index: MsgBuffer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/MsgBuffer.java,v
  retrieving revision 1.7.2.1
  retrieving revision 1.7.2.2
  diff -u -r1.7.2.1 -r1.7.2.2
  --- MsgBuffer.java2000/12/12 09:41:44 1.7.2.1
  +++ MsgBuffer.java2001/06/19 02:42:23 1.7.2.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/MsgBuffer.java,v
 1.7.2.1 2000/12/12 09:41:44 hgomez Exp $
  - * $Revision: 1.7.2.1 $
  - * $Date: 2000/12/12 09:41:44 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/MsgBuffer.java,v
 1.7.2.2 2001/06/19 02:42:23 marcsaeg Exp $
  + * $Revision: 1.7.2.2 $
  + * $Date: 2001/06/19 02:42:23 $
*
* 
*
  @@ -158,7 +158,7 @@
   public void appendBytes( byte b[], int off, int len ) {
BuffTool.addInt( buff, pos, len );
pos+=2;
  - if( pos + len > buff.length ) {
  + if( pos + len >= buff.length ) {
System.out.println("Buffer overflow " + buff.length + " " + pos + " " + 
len );
}
System.arraycopy( b, off, buff, pos, len);
  
  
  

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

[Remy Maucherat]

> on 6/18/01 7:12 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > - All the JARs in /WEB-INF/lib are extracted and copied to the work
directory,
> >   even if the resources are filesystem based. Otherwise, it is not
possible to
> >   actually manipulate the JARs which are in the webapp while they're
open, at
> >   least under Windows. This operation is relatively fast anyway.
>
> So, what is the side effect of this? Will that directory now grow without
> bounds?

Obviously, the "side effect" is not that huge.

Try it first, and complain later if it's really a problem :)

> I'm not sure I like a hack like this that is clearly winblows specific.
Can
> you do this conditionally depending on platform?

It's not a hack, it's just about robustness. Maybe it would be a problem on
some other platform, I just don't know.

Remy

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

[Jon Stevens]

on 6/18/01 7:12 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> - All the JARs in /WEB-INF/lib are extracted and copied to the work directory,
>   even if the resources are filesystem based. Otherwise, it is not possible to
>   actually manipulate the JARs which are in the webapp while they're open, at
>   least under Windows. This operation is relatively fast anyway.

So, what is the side effect of this? Will that directory now grow without
bounds?

I'm not sure I like a hack like this that is clearly winblows specific. Can
you do this conditionally depending on platform?

-jon

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

[remm]

remm01/06/18 19:20:32

  Modified:catalina/src/share/org/apache/catalina/startup
ContextConfig.java
  Log:
  - Stopping and starting any of the Catalina components is broken at the moment,
because the component is not reinitialized.
  - This fixes the problem (at least partially) for a Context.
  - I think this code should be moved to the container itself. I suggest adding
either a new Container.recycle() method or a new Lifecycle.recycle() method.
  
  Revision  ChangesPath
  1.47  +148 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
  
  Index: ContextConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
  retrieving revision 1.46
  retrieving revision 1.47
  diff -u -r1.46 -r1.47
  --- ContextConfig.java2001/05/31 03:56:11 1.46
  +++ ContextConfig.java2001/06/19 02:20:32 1.47
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
 1.46 2001/05/31 03:56:11 remm Exp $
  - * $Revision: 1.46 $
  - * $Date: 2001/05/31 03:56:11 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
 1.47 2001/06/19 02:20:32 remm Exp $
  + * $Revision: 1.47 $
  + * $Date: 2001/06/19 02:20:32 $
*
* 
*
  @@ -106,6 +106,14 @@
   import org.apache.catalina.core.StandardContext;
   import org.apache.catalina.deploy.LoginConfig;
   import org.apache.catalina.deploy.SecurityConstraint;
  +import org.apache.catalina.deploy.ApplicationParameter;
  +import org.apache.catalina.deploy.ContextEjb;
  +import org.apache.catalina.deploy.ContextEnvironment;
  +import org.apache.catalina.deploy.ErrorPage;
  +import org.apache.catalina.deploy.FilterDef;
  +import org.apache.catalina.deploy.FilterMap;
  +import org.apache.catalina.deploy.ContextLocalEjb;
  +import org.apache.catalina.deploy.ContextResource;
   import org.apache.catalina.loader.Extension;
   import org.apache.catalina.util.StringManager;
   import org.apache.catalina.util.xml.SaxContext;
  @@ -120,7 +128,7 @@
* of that Context, and the associated defined servlets.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.46 $ $Date: 2001/05/31 03:56:11 $
  + * @version $Revision: 1.47 $ $Date: 2001/06/19 02:20:32 $
*/
   
   public final class ContextConfig
  @@ -859,10 +867,145 @@
   /**
* Process a "stop" event for this Context.
*/
  -private void stop() {
  +private synchronized void stop() {
   
if (debug > 0)
log(sm.getString("contextConfig.stop"));
  +
  +int i;
  +
  +// Removing children
  +Container[] children = context.findChildren();
  +for (i = 0; i < children.length; i++) {
  +context.removeChild(children[i]);
  +}
  +
  +// FIXME : remove mappers ?
  +
  +// Removing application listeners
  +String[] applicationListeners = context.findApplicationListeners();
  +for (i = 0; i < applicationListeners.length; i++) {
  +context.removeApplicationListener(applicationListeners[i]);
  +}
  +
  +// Removing application parameters
  +ApplicationParameter[] applicationParameters = 
  +context.findApplicationParameters();
  +for (i = 0; i < applicationParameters.length; i++) {
  +context.removeApplicationParameter
  +(applicationParameters[i].getName());
  +}
  +
  +// Removing security constraints
  +SecurityConstraint[] securityConstraints = context.findConstraints();
  +for (i = 0; i < securityConstraints.length; i++) {
  +context.removeConstraint(securityConstraints[i]);
  +}
  +
  +// Removing Ejbs
  +ContextEjb[] contextEjbs = context.findEjbs();
  +for (i = 0; i < contextEjbs.length; i++) {
  +context.removeEjb(contextEjbs[i].getName());
  +}
  +
  +// Removing environments
  +ContextEnvironment[] contextEnvironments = context.findEnvironments();
  +for (i = 0; i < contextEnvironments.length; i++) {
  +context.removeEnvironment(contextEnvironments[i].getName());
  +}
  +
  +// Removing errors pages
  +ErrorPage[] errorPages = context.findErrorPages();
  +for (i = 0; i < errorPages.length; i++) {
  +context.removeErrorPage(errorPages[i]);
  +}
  +
  +// Removing filter defs
  +FilterDef[] filterDefs = context.findFilterDefs();
  +for (i = 0; i < filterDefs.length; i++) {
  +context.removeFilterDef(filterDefs[i]);
  +}
  +
  +// Removing filt

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

[remm]

remm01/06/18 19:14:49

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  - Normalize the work directory path.
  - Use the new Webapp class loader instead of standard class loader.
Note : This is a one line change.
  
  Revision  ChangesPath
  1.63  +15 -8 
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.62
  retrieving revision 1.63
  diff -u -r1.62 -r1.63
  --- StandardContext.java  2001/06/13 02:32:01 1.62
  +++ StandardContext.java  2001/06/19 02:14:48 1.63
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.62 2001/06/13 02:32:01 remm Exp $
  - * $Revision: 1.62 $
  - * $Date: 2001/06/13 02:32:01 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.63 2001/06/19 02:14:48 remm Exp $
  + * $Revision: 1.63 $
  + * $Date: 2001/06/19 02:14:48 $
*
* 
*
  @@ -128,7 +128,7 @@
   import org.apache.catalina.deploy.SecurityCollection;
   import org.apache.catalina.deploy.SecurityConstraint;
   import org.apache.catalina.loader.StandardClassLoader;
  -import org.apache.catalina.loader.StandardLoader;
  +import org.apache.catalina.loader.WebappLoader;
   import org.apache.catalina.session.StandardManager;
   import org.apache.catalina.util.CharsetMapper;
   import org.apache.catalina.util.RequestUtil;
  @@ -141,7 +141,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.62 $ $Date: 2001/06/13 02:32:01 $
  + * @version $Revision: 1.63 $ $Date: 2001/06/19 02:14:48 $
*/
   
   public class StandardContext
  @@ -3151,7 +3151,7 @@
   if (getLoader() == null) {  // (2) Required by Manager
   if (debug >= 1)
   log("Configuring default Loader");
  -setLoader(new StandardLoader(getParentClassLoader()));
  +setLoader(new WebappLoader(getParentClassLoader()));
   }
   if (getManager() == null) { // (3) After prerequisites
   if (debug >= 1)
  @@ -3740,8 +3740,15 @@
   
// Create this directory if necessary
File dir = new File(workDir);
  - if (!dir.isAbsolute())
  - dir = new File(System.getProperty("catalina.home"), workDir);
  + if (!dir.isAbsolute()) {
  +File catalinaHome = new File(System.getProperty("catalina.home"));
  +String catalinaHomePath = null;
  +try {
  +catalinaHomePath = catalinaHome.getCanonicalPath();
  +dir = new File(catalinaHomePath, workDir);
  +} catch (IOException e) {
  +}
  +}
dir.mkdirs();
   
// Set the appropriate servlet context attribute
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader WebappLoader.java

[remm]

remm01/06/18 19:12:50

  Added:   catalina/src/share/org/apache/catalina/loader
WebappLoader.java
  Log:
  - New classloader implementation, used for web applications only.
  - Extends URLClassLoader (to preserve maximum compatibility).
  - Does not require dynamic bindings to work.
  - Supports reloading of classes in /WEB-INF/classes.
  - Supports reloading of JARs. This is untested, and is only a convinience
feature (for example, when you forgot a JAR required by a webapp). In many
cases, a stop / start of the context (which destroys it and recreates it from
scratch) will be needed to avoid getting JVM linkage errors and class casts.
  - Improved efficiency a lot : no more double tracking of the classes and
resources, unified loaded resources repository (classes + resources).
  - Fixed lookup path : first classes repository, then JARs. It was impossible
to control the order of the repositories by directly using URLClassLoader.
  - To the outside world (if getURLs() is called), it appears as a file-based
URLClassLoader.
  - All the JARs in /WEB-INF/lib are extracted and copied to the work directory,
even if the resources are filesystem based. Otherwise, it is not possible to
actually manipulate the JARs which are in the webapp while they're open, at
least under Windows. This operation is relatively fast anyway.
  - Tested with the examples webapp, Slide and Jasper.
  - Note : Jasper reloading of the classes may still be broken.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java
  
  Index: WebappLoader.java
  ===
  /*
   * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
 1.1 2001/06/19 02:12:49 remm Exp $
   * $Revision: 1.1 $
   * $Date: 2001/06/19 02:12:49 $
   *
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights 
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer. 
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:  
   *   "This product includes software developed by the 
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written 
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   * [Additional notices, if required by prior licensing conditions]
   *
   */ 
  
  
  package org.apache.catalina.loader;
  
  
  import java.beans.PropertyChangeEvent;
  import java.beans.PropertyChangeListener;
  import java.beans.PropertyChangeSupport;
  impo

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

[amyroh]

amyroh  01/06/18 18:06:24

  Modified:catalina build.xml
  Log:
  Add to handle jdk1.3 dependency for CGI.
  
  Revision  ChangesPath
  1.45  +5 -3  jakarta-tomcat-4.0/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
  retrieving revision 1.44
  retrieving revision 1.45
  diff -u -r1.44 -r1.45
  --- build.xml 2001/06/15 20:51:16 1.44
  +++ build.xml 2001/06/19 01:06:21 1.45
  @@ -129,6 +129,8 @@
classname="org.apache.avalon.blocks.Block" />
   
  +
   
   
 
  +   unless="jdk.1.3.present"/>
 
  +   unless="jdk.1.3.present"/>
   
   
   
  @@ -166,7 +168,7 @@
  />
   
   

cvs commit: jakarta-tomcat build.xml

[mmanders]

mmanders01/06/18 17:34:38

  Modified:.build.xml
  Log:
  Updated conditionals for commons-dbcp.  This will now build properly even if 
jakarta-commons isn't available.
  
  Revision  ChangesPath
  1.135 +29 -30jakarta-tomcat/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/build.xml,v
  retrieving revision 1.134
  retrieving revision 1.135
  diff -u -r1.134 -r1.135
  --- build.xml 2001/06/17 18:59:39 1.134
  +++ build.xml 2001/06/19 00:34:37 1.135
  @@ -38,10 +38,16 @@
   
 
  +
  +  
   
 
 
  @@ -54,18 +60,6 @@
 
 
   
  -  
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -  
  -
 
 
  @@ -80,8 +74,7 @@
   
   
  +   file="${jakarta-commons}/dbcp/dist/commons-dbcp.jar" />
   
   
   
 
  +  
 
 
   
  @@ -380,23 +374,26 @@
 
   
   
  -  
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  +-->
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
 
   
 
  @@ -410,8 +407,10 @@
   
   
   
  +
  +
  +
 
  -  
 
 

Re: [repost] [T4] servlet including jsp causes jsp to flush buffer?

[Geoff Soutter]

Sorry, my fault.

This was actually our code calling stream.flush() which ends up calling
response.flushBuffer() (fairly reasonable, really :-).

So, looks like the T4 code is beyond reproach, again.

Geoff


- Original Message -
From: "Geoff Soutter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 14, 2001 1:12 PM
Subject: [repost] [T4] servlet including jsp causes jsp to flush buffer?


> come on guys, I know you're listening ... :-)
>
> is this really a bug or am I missing something obvious? (I'm not really up
> to speed on Jasper...)
>
> If it is I can enter it into bugzilla...
>
> geoff
>
> - Original Message -
> From: "Geoff Soutter" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, June 13, 2001 4:14 PM
> Subject: [T4] servlet including jsp causes jsp to flush buffer?
>
>
> > Hi,
> >
> > I've got a servlet which includes a JSP page, and it appears that the
JSP
> > engine in Tomcat 4.0 calls response.flushBuffer() when the include
> finishes.
> >
> > IMHO this behaviour is incorrect, as it should be up to the "topmost"
> > servlet to control what is happening with the buffering as much as
> possible.
> > Currently this behaviour is preventing my servlet from controlling the
> > buffering as it would like to.
> >
> > I looked though the list and noticed that v3.x has many flushing
problems
> > but I was kinda hoping they'd be fixed in Tomcat 4.x ;-).
> >
> > Anyway, here's the offending code (I think).
> >
> > In PageContextImpl.java
> >
> > public void release() {
> >   try {
> > if (isIncluded) {
> >   ((JspWriterImpl)out).flushBuffer(); // push it into the including
> > jspWriter
> > } else {
> >   out.flush();
> > }
> >   } catch (IOException ex) {
> > loghelper.log("Internal error flushing the buffer in release()");
> >   }
> >
> > and in JspWriterImpl.java
> >
> > public void flush()  throws IOException {
> >   synchronized (lock) {
> > flushBuffer();
> > if (out != null) {
> >   out.flush();
> >   // Also flush the response buffer.
> >   response.flushBuffer();
> > }
> >   }
> > }
> >
> > Geoff
> >
> > --
> > Keep cool till after school!
> >
> >
>
>

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

[remm]

remm01/06/18 16:28:40

  Modified:catalina/src/share/org/apache/catalina/connector/http
HttpProcessor.java
  Log:
  - Skip leftover bytes before closing the socket.
  
  Revision  ChangesPath
  1.28  +19 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java
  
  Index: HttpProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- HttpProcessor.java2001/06/18 06:22:27 1.27
  +++ HttpProcessor.java2001/06/18 23:28:39 1.28
  @@ -1,6 +1,6 @@
  -/* * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
 1.27 2001/06/18 06:22:27 remm Exp $
  - * $Revision: 1.27 $
  - * $Date: 2001/06/18 06:22:27 $
  +/* * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
 1.28 2001/06/18 23:28:39 remm Exp $
  + * $Revision: 1.28 $
  + * $Date: 2001/06/18 23:28:39 $
*
* 
*
  @@ -106,7 +106,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.27 $ $Date: 2001/06/18 06:22:27 $
  + * @version $Revision: 1.28 $ $Date: 2001/06/18 23:28:39 $
*/
   
   final class HttpProcessor
  @@ -935,12 +935,27 @@
   }
   
try {
  +shutdownInput(input);
   socket.close();
} catch (IOException e) {
;
}
socket = null;
   
  +}
  +
  +
  +protected void shutdownInput(InputStream input)
  +throws IOException {
  +try {
  +int available = input.available();
  +// skip any unread (bogus) bytes
  +if (available > 0) {
  +input.skip(available);
  +}
  +} catch (Exception e) {
  +;
  +}
   }
   
   
  
  
  

RE: Where is jni_connect for Tomcat 3.2.2?

[Marc Saegesser]

Its there now, but I have no way to test it at present.

> -Original Message-
> From: Engel Sanchez [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 4:34 PM
> To: [EMAIL PROTECTED]
> Subject: Where is jni_connect for Tomcat 3.2.2?
> 
> 
> I just installed tomcat in win2k running IIS and got
> it working. I'm interested in trying it out as an
> in-process module, but even though the instructions
> mention getting jni_connect.dll from the distribution
> site, this file is not present for Tomcat 3.2.2 (it is
> there for 3.2.1). Is it no longer supported? Thanks in advance.
> 
> =
> _ @ Engel Amin Sanchez-Santos  
>  @>:O)  <-- Some afro is better than no afro
>   @ E-mail: [EMAIL PROTECTED]
> 
> __
> Do You Yahoo!?
> Spot the hottest trends in music, movies, and more.
> http://buzz.yahoo.com/

Re: [tomcat-dev] [J-T-C] What about ajp13 refactory in java ?

[Aaron Bannert]

On Mon, Jun 18, 2001 at 05:01:59PM +0200, GOMEZ Henri wrote:
> I'd like to know what's the current status of ajp java on j-t-c.

I've been lurking on this list for awhile and wading through all the code,
and this one has been bothering me for awhile. Is there a way we could get
a STATUS and README file written for j-t-c? I would do it myself, but
honestly I'm at a loss for what would go in there.

-aaron

Where is jni_connect for Tomcat 3.2.2?

[Engel Sanchez]

I just installed tomcat in win2k running IIS and got
it working. I'm interested in trying it out as an
in-process module, but even though the instructions
mention getting jni_connect.dll from the distribution
site, this file is not present for Tomcat 3.2.2 (it is
there for 3.2.1). Is it no longer supported? Thanks in advance.

=
_ @ Engel Amin Sanchez-Santos  
 @>:O)  <-- Some afro is better than no afro
  @ E-mail: [EMAIL PROTECTED]

__
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

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

[remm]

remm01/06/18 14:35:56

  Modified:catalina/src/share/org/apache/catalina/connector/http
HttpConnector.java
  Log:
  - Actually call setTcpNoDelay on the newly accepted socket.
  
  Revision  ChangesPath
  1.17  +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java
  
  Index: HttpConnector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- HttpConnector.java2001/06/14 14:45:55 1.16
  +++ HttpConnector.java2001/06/18 21:35:54 1.17
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
 1.16 2001/06/14 14:45:55 remm Exp $
  - * $Revision: 1.16 $
  - * $Date: 2001/06/14 14:45:55 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
 1.17 2001/06/18 21:35:54 remm Exp $
  + * $Revision: 1.17 $
  + * $Date: 2001/06/18 21:35:54 $
*
* 
*
  @@ -95,7 +95,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.16 $ $Date: 2001/06/14 14:45:55 $
  + * @version $Revision: 1.17 $ $Date: 2001/06/18 21:35:54 $
*/
   
   
  @@ -934,7 +934,7 @@
   //log("run: Returned from 
serverSocket.accept()");
   if (connectionTimeout > 0)
   socket.setSoTimeout(connectionTimeout);
  -setTcpNoDelay(tcpNoDelay);
  +socket.setTcpNoDelay(tcpNoDelay);
   } catch (AccessControlException ace) {
   log("socket accept security exception", ace);
   continue;
  
  
  

Serious problem with Tomcat JVM running out of memory

[Tom Amiro]

Hi,

Yes I've tried that and it did not seem to help.

I'm using the XSLTC processor from Sun that compiles
XSL stylesheets into translets (java byte code).

Tom

Hi, have you tried to set java memory parameters in tomcat.sh
at TOMCAT_OPTS (e.g. -Xmx256m -Xms128m).
We are running a quite large application without problems
after setting these parameters.

regards, tom

btw: what xslt-processor do you use, cause we are experiencing
an enormous performance leak using xalan compared to ms-xml
(40 sec to 3 msec) xalan on solaris 8 440Mhz, ms-xml on
w2k P3-850.

> -Ursprungliche Nachricht-
> Von: Tom Amiro [mailto:[EMAIL PROTECTED]]
> Gesendet: Sonntag, 17. Juni 2001 22:33
> An: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Betreff: serious problem with Tomcat JVM running out of memory
>
>
> Hello,
>
> I am at the end of my rope. A couple of weeks ago, I tried to
> deploy a Java servlet
> that gets about 300-400 hits a day using Tomcat in stand-alone mode
> and Tomcat keeps running out of memory and crashing.  The servlet
> does an XSLT transformation
> on an XML file about 1.5MB large. I was planning on integrating
> Tomcat into the main Apache
> server after finishing the development, but haven't been able to
> get that far.
>
> I've tried a lot of things and collected a lot of data, but have
> not been able to prevent
> the Tomcat heap from growing and growing, until TC crashes.  The terminal
> window shows lots of out-of-memory messages coming from the servlet before
> the crash -- so I know it is servlet. Tomcat is only running the
> servlet (that gets
> 300-400 hits a day) and some JSP data entry tools used to
> maintain the XML file.
> I've found that even when we refrain from using the data entry
> tools, and just
> let the servlet run the problem still happens. The JSPs add to
> it, but even  with
> them out of the picture, the situation is untenable.
>
> I've spent more than 6 months developing this application -- an event
> calendar -- and was forced to put it into production before it was tested.
> But Java servlets and JSPs are supposed to make it easier to create web
> applications, right?
>
> At first, I thought I must be something wrong. So I did every
> thing I could
> to plug memory leaks in my code. The thing that really perplexes
> me is that
> the heap -- (rt.totalMemory()-rt.freeMemory() --will hover around 75M for
> quite a while and then seem to jump in leaps and bounds --
> sometimes 5-10MB at a time.
>
> In the very beginning, I sent mail to the users group and have implemented
> suggestions, like increasing the file descriptors to 1024,
> minimizing sessions
> (session.setMaxInactiveInterval(120), starting the Tomcat JVM with more
> memory (-Xmx160m).  That has helped somewhat. It takes longer to
> crash with a 90MB core file filling up my /usr/local partition,
> but it hasn't
> stayed up more than 24 hours.
>
> Here's the configuration:
>
>   - Solaris 2.7 on an Ultra-2 with all the patches.
>   - one processor with 512MB memory
>   - Java 1.3 is installed
>   - Tomcat 3.2.2 jars
>   - Session timeout 120 seconds
>   - Using the thread pool with
> max_threads 25
> max_spare_threads 10
> min_spare_threads 5
>
> I've started the TC JVM from the command line and done Ctrl-\,
> but my telnet application's buffer isn't big enough to capture the
> highest session, and I don't know what to look for.
>
> I've been using the 'top' command to monitor the Tomcat
> process. It shows the memory going up and up. Not sure
> how to read it. With the max heap set to 160M, I've seen top
> show the SIZE get up to 215M before the crash. Right now
> its at 156M SIZE 52M RES.
>
> >From time to time this error keeps popping up.
>
> 2001-06-17 04:10:36 - ContextManager: SocketException reading
> request, ignored -
>  java.net.SocketException: Connection reset by peer
> at java.net.PlainSocketImpl.socketAvailable(Native Method)
> at java.net.PlainSocketImpl.available(PlainSocketImpl.java:451)
> at
> java.net.SocketInputStream.available(SocketInputStream.java:137)
> at
> org.apache.tomcat.service.http.HttpConnectionHandler.processConnectio
> n(HttpConnectionHandler.java:217)
> at
> org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java: 416)
> at
> org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java
> :501)
> at java.lang.Thread.run(Thread.java:484)
>
>
> I've attached files to show you the servlet (Transform.java) and the
> configuration files.
>
> What should I do next? There has got to be a way to get this to work.
>
> Please make sure to send email to me and not just to the dev alias,
> as I'm not on the dev alias.
> [EMAIL PROTECTED]
>
> Thanks,
>
> Tom
>
>
>
>
>
>
>
>

RE: Decoding problems.

[Angel Aray]

Encoding of mail messages seems to also be a problem. :(

The test data was supposed to have tildes, but outlook decided to remove
them.

here is the encoded version:
test+%E1%E9%ED%F3


-Original Message-
From: Angel Aray [mailto:[EMAIL PROTECTED]]
Sent: Lunes, 18 de Junio de 2001 01:47 p.m.
To: [EMAIL PROTECTED]
Subject: RE: Decoding problems.


Here is a simple example:

first a form:







MSG: 






second a echo.jsp to process de data.
<%
   String msg= request.getParameter("msg");
%>


MSG: <%= msg %>




test with:
test aeiou

this will only echo the word test.

if you remove the meta tag form the html form the problem goes away.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Lunes, 18 de Junio de 2001 12:36 p.m.
To: 'Tomcat-Dev
Subject: Re: Decoding problems.


Can you send a URI that shows the problem ( including the special chars )?
Are the chars encoded ( %something ) or not ? This is an important one,
thanks for the report.

Costin



On Mon, 18 Jun 2001, Angel Aray wrote:

>
> I am having problems with tomcat handlings of special characters.
> Whenever some data is post/get that contains special characters (i.e.
> characters with accents, tildes, etc) the request parameter gets truncated
> up to the occurrence of the first special character.
>
> I would like to help and fix this bug, but I don't know where to
> start. One thing I did try was to disable de Decode Interceptor but
> that had no effect.
>
>
> Any hints where to start looking will be appreciated.
>
>
> P.S: I am using  tomcat33 out of CVS and the problem appeared recently. I
> had an about 3 weeks old tomcat out of CVS and the problem was not there.
I
> hope this helps to find/solve this bug.
>
>
>
> Regards.
>
> Angel Aray.
>

RE: Decoding problems.

[Angel Aray]

Here is a simple example:

first a form:







MSG: 






second a echo.jsp to process de data.
<%
   String msg= request.getParameter("msg");
%>


MSG: <%= msg %>




test with:
test aeiou

this will only echo the word test.

if you remove the meta tag form the html form the problem goes away.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Lunes, 18 de Junio de 2001 12:36 p.m.
To: 'Tomcat-Dev
Subject: Re: Decoding problems.


Can you send a URI that shows the problem ( including the special chars )?
Are the chars encoded ( %something ) or not ? This is an important one,
thanks for the report.

Costin



On Mon, 18 Jun 2001, Angel Aray wrote:

>
> I am having problems with tomcat handlings of special characters.
> Whenever some data is post/get that contains special characters (i.e.
> characters with accents, tildes, etc) the request parameter gets truncated
> up to the occurrence of the first special character.
>
> I would like to help and fix this bug, but I don't know where to
> start. One thing I did try was to disable de Decode Interceptor but
> that had no effect.
>
>
> Any hints where to start looking will be appreciated.
>
>
> P.S: I am using  tomcat33 out of CVS and the problem appeared recently. I
> had an about 3 weeks old tomcat out of CVS and the problem was not there.
I
> hope this helps to find/solve this bug.
>
>
>
> Regards.
>
> Angel Aray.
>

Re: Status of BASIC authentication in Tomcat4.0-latest?

[Craig R. McClanahan]

You have not declared an  inside your
, which is essentially saying that "this security
constraint does not require authentication".

Craig McClanahan

On 17 Jun 2001, David M. Karr wrote:

> > "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
> 
> Craig> On 16 Jun 2001, David M. Karr wrote:
> 
> >> What is the status of BASIC authentication in Tomcat4.0-latest?  I noticed it
> >> seems to do nothing.  A login dialog never appeared, but it gave access to the
> >> resource, and the return from "request.getAuthType()" in the resource was a
> >> null string.
> >> 
> 
> Craig> As far as I know, it works according to the specs.  Same for the other
> Craig> container managed security methods.
> 
> Craig> Did you create a  to protect the resources that you
> Craig> wanted to have protected?  If you don't do this, authentication will never
> Craig> be triggered (so request.getAuthType() will return null, of course).
> 
> Following this is my web.xml for the BASIC test.  This is almost verbatim from
> the Prof. JSP example.  I tried a similar test with FORM-based authentication
> (also from the book), with similar but different results.  It never went to the
> login page, but instead of just going to the protected resource (like the BASIC
> test), it failed with a permission error on the resource.
> 
> 
> 
> PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
>"http://java.sun.com/j2ee/dtds/web-app_2_3.dtd";>
> 
>  
>   
>Entire Application
>/*
>   
>  
>  
>   BASIC
>   ProJSP Authentication Example
>  
> 
> 
> -- 
> ===
> David M. Karr  ; Best Consulting
> [EMAIL PROTECTED]   ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)
> 
> 

RE: Decoding problems.

[Martin van den Bemt]

org.apache.tomcat.util.buf.UDecode.java got lost somewhere along the way. It
crashed my tomcat on some forms (no special things happening btw). So maby
the problem is in there. Where it is, I don't have a clue..

Mvgr,
Martin

> -Original Message-
> From: Angel Aray [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 1:39 PM
> To: 'Tomcat-Dev
> Subject: Decoding problems.
>
>
>
> I am having problems with tomcat handlings of special characters.
> Whenever some data is post/get that contains special characters (i.e.
> characters with accents, tildes, etc) the request parameter gets truncated
> up to the occurrence of the first special character.
>
> I would like to help and fix this bug, but I don't know where to
> start. One thing I did try was to disable de Decode Interceptor but
> that had no effect.
>
>
> Any hints where to start looking will be appreciated.
>
>
> P.S: I am using  tomcat33 out of CVS and the problem appeared recently. I
> had an about 3 weeks old tomcat out of CVS and the problem was
> not there. I
> hope this helps to find/solve this bug.
>
>
>
> Regards.
>
> Angel Aray.
>
>

RE: Ways of Debugging tomcat itself..

[Steve Downey]

With netbeans, in particular, an important trick is to disable the inclusion
of its embedded tomcat in the executor and debugger. With 3.2, I think
that's the {library} keyword. It changed between 3.1 and 3.2, I believe.

Otherwise you're debugging the IDE, not the instance of Tomcat you're
building. 

Other than that, it's really straightforward. Add all the different source
trees to the filesystem, set up a cross compiler pointing to the build
directory, which needs to be mounted also, and the do builds as normal, or
by using Ant. 

Use org.apache.tomcat.startup.Main as the main class. Look at tomcat.sh for
the system defines to add also.


> -Original Message-
> From: Martin van den Bemt [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 14, 2001 6:40 PM
> To: jakarta-tomcat-dev
> Subject: Ways of Debugging tomcat itself..
> 
> 
> Hi,
> 
> Maby this question has been asked before, but I'm looking for 
> a good way to
> debug tomcat itself (not taling about servlets in specific). 
> The environment
> i'm using now is netbeans 3.2.
> Does anyone have tips on how to debug tomcat (except for 
> logging to the
> console, that one I know..).
> I would love to have an opinion / your experience with this. 
> Doesn't matter
> which environment you use or how you debug, it may be 
> interesting to put
> this in a document. If there is already some nice info on 
> this, please also
> let me know..
> 
> Mvgr,
> Martin van den Bemt
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

Re: [J-T-C] What about ajp13 refactory in java ?

[cmanolache]

On Mon, 18 Jun 2001, kevin seguin wrote:

> i think that soon, all of the core ajp java code should be refactored
> into the org.apache.ajp package.  that probably just means removing
> Ajp13.java from org.apache.ajp.tomcat33.

It would be better to just add a note that the package is deprecated and
will be removed - for now the code is used as the "stable" version for
3.3.

We could also tag the workspace and keep the stable code in a branch, but
it' much safer to use 2 packages (same as we do with jasper/jasper34 ),
this way we can also reduce incompatibilities.

I think we should use coyote as a basis, but there are few API problems we
should fix ( I sent a mail last week about some of the problems ). In
particular I'm very interested in the event/listener model for
communication between layers. 


Costin


> 
> also, i think that org.apache.ajp.AjpRequest can either be replaced by
> org.apache.coyote.Request, or it should extend or adapt
> org.apache.coyote.Request.
> 
> hopefully, in the coming weeks, i'll have more time to spend on this
> stuff :)
> 
> -kevin.
> 
> GOMEZ Henri wrote:
> > 
> > Hi to all,
> > 
> > I'd like to know what's the current status of ajp java on j-t-c.
> > 
> > 1) We have now two implementations of AJP13 protocol,
> >in org.apache.ajp.tomcat33 and org.apache.ajp
> >Also implementations came with its own code for core engine.
> >(org.apache.ajp.tomcat33  / org.apache.ajp.tomcat4)
> > 
> >Could we at minina, share ajp networking code between TC33/TC40 ?
> > 
> >Will we use Coyote as base of reflexion and have implementation
> >on both TC33 and TC40 ?
> > 
> > All these questions since I'll start to write ajp14 java side and
> > need to know what will be the base. If we could have at least common
> > ajp networking code between TC33/TC40, it will avoid duplicate and
> > error.
> > 
> > Regards
> 

Re: Decoding problems.

[cmanolache]

Can you send a URI that shows the problem ( including the special chars )?
Are the chars encoded ( %something ) or not ? This is an important one,
thanks for the report.

Costin



On Mon, 18 Jun 2001, Angel Aray wrote:

> 
> I am having problems with tomcat handlings of special characters.
> Whenever some data is post/get that contains special characters (i.e.
> characters with accents, tildes, etc) the request parameter gets truncated
> up to the occurrence of the first special character.
> 
> I would like to help and fix this bug, but I don't know where to
> start. One thing I did try was to disable de Decode Interceptor but
> that had no effect.
> 
> 
> Any hints where to start looking will be appreciated.
> 
> 
> P.S: I am using  tomcat33 out of CVS and the problem appeared recently. I
> had an about 3 weeks old tomcat out of CVS and the problem was not there. I
> hope this helps to find/solve this bug.
> 
> 
> 
> Regards.
> 
> Angel Aray.
> 

Re: [PROPOSAL] Update to Tomcat 3.3 release schedule

[Mike Anderson]

+1

>>> [EMAIL PROTECTED] 06/17/01 02:54PM >>>
Hi,

Continuing to adapt the Tomcat 3.3 schedule to available time and needs,
I propose the following changes to the current RELEASE-PLAN-3.3:

Add a Milestone 4:

Code Freeze/Tag Date:   June 20, 2001
Release Manager:Larry Isaacs

This release contains a switch to using jakarta-tomcat-connectors
for some utility classes.  It also uses jakarta-tomcat-jasper
for building jasper34, which will be enabled as the default
JSP handler.  The internal "jasper33" will be enabled as the
default JSP handler for future releases of Tomcat 3.3.

Known issues in order of priority:
1. Jasper34 needs to be stable.
2. Watchdog and internal test need to be passing all tests.
3. Build documentation need to be updated to document
   new dependencies on jakarta-tomcat-connectors and
   jakarta-tomcat-jasper.


Change the Beta 1 Freeze Date to July 11.

Change the Beta 2 Freeze Date to July 18.

Change the Final Release August 1.

Cheers,
Larry

Decoding problems.

[Angel Aray]

I am having problems with tomcat handlings of special characters.
Whenever some data is post/get that contains special characters (i.e.
characters with accents, tildes, etc) the request parameter gets truncated
up to the occurrence of the first special character.

I would like to help and fix this bug, but I don't know where to
start. One thing I did try was to disable de Decode Interceptor but
that had no effect.


Any hints where to start looking will be appreciated.


P.S: I am using  tomcat33 out of CVS and the problem appeared recently. I
had an about 3 weeks old tomcat out of CVS and the problem was not there. I
hope this helps to find/solve this bug.



Regards.

Angel Aray.

Re: [J-T-C] What about ajp13 refactory in java ?

[kevin seguin]

the java side of the ajp stuff in jtc has been static for a while
because i've been really busy and also i had been waiting to see what
was in coyote and how it would affect tomcat 4.

i think that soon, all of the core ajp java code should be refactored
into the org.apache.ajp package.  that probably just means removing
Ajp13.java from org.apache.ajp.tomcat33.

also, i think that org.apache.ajp.AjpRequest can either be replaced by
org.apache.coyote.Request, or it should extend or adapt
org.apache.coyote.Request.

hopefully, in the coming weeks, i'll have more time to spend on this
stuff :)

-kevin.

GOMEZ Henri wrote:
> 
> Hi to all,
> 
> I'd like to know what's the current status of ajp java on j-t-c.
> 
> 1) We have now two implementations of AJP13 protocol,
>in org.apache.ajp.tomcat33 and org.apache.ajp
>Also implementations came with its own code for core engine.
>(org.apache.ajp.tomcat33  / org.apache.ajp.tomcat4)
> 
>Could we at minina, share ajp networking code between TC33/TC40 ?
> 
>Will we use Coyote as base of reflexion and have implementation
>on both TC33 and TC40 ?
> 
> All these questions since I'll start to write ajp14 java side and
> need to know what will be the base. If we could have at least common
> ajp networking code between TC33/TC40, it will avoid duplicate and
> error.
> 
> Regards

[J-T-C] What about ajp13 refactory in java ?

[GOMEZ Henri]

Hi to all,

I'd like to know what's the current status of ajp java on j-t-c.

1) We have now two implementations of AJP13 protocol, 
   in org.apache.ajp.tomcat33 and org.apache.ajp
   Also implementations came with its own code for core engine.
   (org.apache.ajp.tomcat33  / org.apache.ajp.tomcat4)

   Could we at minina, share ajp networking code between TC33/TC40 ?

   Will we use Coyote as base of reflexion and have implementation
   on both TC33 and TC40 ? 
   
All these questions since I'll start to write ajp14 java side and
need to know what will be the base. If we could have at least common 
ajp networking code between TC33/TC40, it will avoid duplicate and
error.

Regards

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

[hgomez]

hgomez  01/06/18 07:46:32

  Modified:jk/native/jni jk_jnicb.c
   jk/native/nt_service jk_nt_service.c
  Log:
  Updated Copyrigth Notice to Apache 1.1
  
  Revision  ChangesPath
  1.2   +56 -54jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c
  
  Index: jk_jnicb.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jk_jnicb.c2001/05/14 09:50:02 1.1
  +++ jk_jnicb.c2001/06/18 14:46:19 1.2
  @@ -1,62 +1,64 @@
  -/*
  - * Copyright (c) 1997-1999 The Java Apache Project.  All rights reserved.
  - *
  - * Redistribution and use in source and binary forms, with or without
  - * modification, are permitted provided that the following conditions
  - * are met:
  - *
  - * 1. Redistributions of source code must retain the above copyright
  - *notice, this list of conditions and the following disclaimer.
  - *
  - * 2. Redistributions in binary form must reproduce the above copyright
  - *notice, this list of conditions and the following disclaimer in
  - *the documentation and/or other materials provided with the
  - *distribution.
  - *
  - * 3. All advertising materials mentioning features or use of this
  - *software must display the following acknowledgment:
  - *"This product includes software developed by the Java Apache 
  - *Project for use in the Apache JServ servlet engine project
  - *."
  - *
  - * 4. The names "Apache JServ", "Apache JServ Servlet Engine" and 
  - *"Java Apache Project" must not be used to endorse or promote products 
  - *derived from this software without prior written permission.
  - *
  - * 5. Products derived from this software may not be called "Apache JServ"
  - *nor may "Apache" nor "Apache JServ" appear in their names without 
  - *prior written permission of the Java Apache Project.
  - *
  - * 6. Redistributions of any form whatsoever must retain the following
  - *acknowledgment:
  - *"This product includes software developed by the Java Apache 
  - *Project for use in the Apache JServ servlet engine project
  - *."
  - *
  - * THIS SOFTWARE IS PROVIDED BY THE JAVA APACHE PROJECT "AS IS" AND ANY
  - * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
  - * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE JAVA APACHE PROJECT OR
  - * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
  - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
  - * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  - * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  - * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
  - * OF THE POSSIBILITY OF SUCH DAMAGE.
  - *
  - * This software consists of voluntary contributions made by many
  - * individuals on behalf of the Java Apache Group. For more information
  - * on the Java Apache Project and the Apache JServ Servlet Engine project,
  - * please see .
  - *
  - */
  +/* = *
  + *   *
  + * The Apache Software License,  Version 1.1 *
  + *   *
  + *  Copyright (c) 1999-2001 The Apache Software Foundation.  *
  + *   All rights reserved.*
  + *   *
  + * = *
  + *   *
  + * Redistribution and use in source and binary forms,  with or without modi- *
  + * fication, are permitted provided that the following conditions are met:   *
  + *   *
  + * 1. Redistributions of source code  must retain the above copyright notice *
  + *notice, this list of conditions and the following disclaimer.  *
  + *   *
  + * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
  + *notice,  this list of conditions  and the following  disclaimer in the *
  + *documentation and/or other materials provided with the distribution.   *
  + *   

cvs commit: jakarta-tomcat-connectors/jk/native/domino config.h inifile.c inifile.h jk_dsapi_plugin.c

[hgomez]

hgomez  01/06/18 07:41:28

  Modified:jk/native/domino config.h inifile.c inifile.h
jk_dsapi_plugin.c
  Log:
  Update Copyrigth notice to Apache 1.1
  
  Revision  ChangesPath
  1.4   +57 -55jakarta-tomcat-connectors/jk/native/domino/config.h
  
  Index: config.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/domino/config.h,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- config.h  2001/06/14 14:36:08 1.3
  +++ config.h  2001/06/18 14:41:17 1.4
  @@ -1,62 +1,64 @@
  -/*
  - * Copyright (c) 1997-1999 The Java Apache Project.  All rights reserved.
  - *
  - * Redistribution and use in source and binary forms, with or without
  - * modification, are permitted provided that the following conditions
  - * are met:
  - *
  - * 1. Redistributions of source code must retain the above copyright
  - *notice, this list of conditions and the following disclaimer.
  - *
  - * 2. Redistributions in binary form must reproduce the above copyright
  - *notice, this list of conditions and the following disclaimer in
  - *the documentation and/or other materials provided with the
  - *distribution.
  - *
  - * 3. All advertising materials mentioning features or use of this
  - *software must display the following acknowledgment:
  - *"This product includes software developed by the Java Apache
  - *Project for use in the Apache JServ servlet engine project
  - *."
  - *
  - * 4. The names "Apache JServ", "Apache JServ Servlet Engine" and
  - *"Java Apache Project" must not be used to endorse or promote products
  - *derived from this software without prior written permission.
  - *
  - * 5. Products derived from this software may not be called "Apache JServ"
  - *nor may "Apache" nor "Apache JServ" appear in their names without
  - *prior written permission of the Java Apache Project.
  - *
  - * 6. Redistributions of any form whatsoever must retain the following
  - *acknowledgment:
  - *"This product includes software developed by the Java Apache
  - *Project for use in the Apache JServ servlet engine project
  - *."
  - *
  - * THIS SOFTWARE IS PROVIDED BY THE JAVA APACHE PROJECT "AS IS" AND ANY
  - * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
  - * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE JAVA APACHE PROJECT OR
  - * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
  - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
  - * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  - * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  - * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
  - * OF THE POSSIBILITY OF SUCH DAMAGE.
  - *
  - * This software consists of voluntary contributions made by many
  - * individuals on behalf of the Java Apache Group. For more information
  - * on the Java Apache Project and the Apache JServ Servlet Engine project,
  - * please see .
  - *
  - */
  +/* = *
  + *   *
  + * The Apache Software License,  Version 1.1 *
  + *   *
  + *  Copyright (c) 1999-2001 The Apache Software Foundation.  *
  + *   All rights reserved.*
  + *   *
  + * = *
  + *   *
  + * Redistribution and use in source and binary forms,  with or without modi- *
  + * fication, are permitted provided that the following conditions are met:   *
  + *   *
  + * 1. Redistributions of source code  must retain the above copyright notice *
  + *notice, this list of conditions and the following disclaimer.  *
  + *   *
  + * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
  + *notice,  this list of conditions  and the following  disclaimer in the *
  + *documentation and/or other materials provided with the distribution.   *
  + *  

Form based Security not working as expected

[Kevin Jones]

In the latest nightlies  -

I have a site setup where only part of the site is protected with a logon.
If a user tries to logon and uses the wrong username or password I'd expect
to see the error page, however the user sees the logon page again.

If they then enter the correct logon they see the error page.

If they then try and go back they get a HTTP Status 404 -
/course/j_security_check 'not available' message (/course is part of the URL
they are trying to get to)

This seems to work fine in Beta 3 (the last beta I have setup).

Could somebody check this and confirm I'm not going mad,

thanks,

Kevin Jones
DevelopMentor
www.develop.com

cvs commit: jakarta-tomcat-connectors/jk/native/netscape jk_nsapi_plugin.c

[hgomez]

hgomez  01/06/18 07:37:36

  Modified:jk/native/apache-1.3 mod_jk.c
   jk/native/apache-2.0 mod_jk.c
   jk/native/iis jk_isapi_plugin.c
   jk/native/netscape jk_nsapi_plugin.c
  Log:
  Updated Copyrigth notice to Apache 1.1
  
  Revision  ChangesPath
  1.8   +57 -55jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- mod_jk.c  2001/06/08 14:34:05 1.7
  +++ mod_jk.c  2001/06/18 14:37:18 1.8
  @@ -1,57 +1,59 @@
  -/*
  - * Copyright (c) 1997-1999 The Java Apache Project.  All rights reserved.
  - *
  - * Redistribution and use in source and binary forms, with or without
  - * modification, are permitted provided that the following conditions
  - * are met:
  - *
  - * 1. Redistributions of source code must retain the above copyright
  - *notice, this list of conditions and the following disclaimer.
  - *
  - * 2. Redistributions in binary form must reproduce the above copyright
  - *notice, this list of conditions and the following disclaimer in
  - *the documentation and/or other materials provided with the
  - *distribution.
  - *
  - * 3. All advertising materials mentioning features or use of this
  - *software must display the following acknowledgment:
  - *"This product includes software developed by the Java Apache 
  - *Project for use in the Apache JServ servlet engine project
  - *."
  - *
  - * 4. The names "Apache JServ", "Apache JServ Servlet Engine" and 
  - *"Java Apache Project" must not be used to endorse or promote products 
  - *derived from this software without prior written permission.
  - *
  - * 5. Products derived from this software may not be called "Apache JServ"
  - *nor may "Apache" nor "Apache JServ" appear in their names without 
  - *prior written permission of the Java Apache Project.
  - *
  - * 6. Redistributions of any form whatsoever must retain the following
  - *acknowledgment:
  - *"This product includes software developed by the Java Apache 
  - *Project for use in the Apache JServ servlet engine project
  - *."
  - *
  - * THIS SOFTWARE IS PROVIDED BY THE JAVA APACHE PROJECT "AS IS" AND ANY
  - * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
  - * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE JAVA APACHE PROJECT OR
  - * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
  - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
  - * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  - * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  - * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
  - * OF THE POSSIBILITY OF SUCH DAMAGE.
  - *
  - * This software consists of voluntary contributions made by many
  - * individuals on behalf of the Java Apache Group. For more information
  - * on the Java Apache Project and the Apache JServ Servlet Engine project,
  - * please see .
  - *
  - */
  +/* = *
  + *   *
  + * The Apache Software License,  Version 1.1 *
  + *   *
  + *  Copyright (c) 1999-2001 The Apache Software Foundation.  *
  + *   All rights reserved.*
  + *   *
  + * = *
  + *   *
  + * Redistribution and use in source and binary forms,  with or without modi- *
  + * fication, are permitted provided that the following conditions are met:   *
  + *   *
  + * 1. Redistributions of source code  must retain the above copyright notice *
  + *notice, this list of conditions and the following disclaimer.  *
  + *   *
  + * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
  + *notice,  this list of conditions  and the following  disclaimer in the *
  + *documentation and/or other materials provided with the distr

RE: J-T-C huge commit without mail

[GOMEZ Henri]

It was that :

To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-connectors/jk/native/common
jk_ajp12_worker.c jk_ajp12_worker.h jk_ajp13.c jk_ajp13.h jk_ajp13_worker.c
jk_ajp13_worker.h jk_ajp14.c jk_ajp14.h jk_ajp14_worker.c jk_ajp14_worker.h
jk_ajp_common.c jk_ajp_common.h jk_connect.c jk_connect.h jk_context.c
jk_context.h jk_global.h jk_jni_worker.c jk_jni_worker.h jk_lb_worker.c
jk_lb_worker.h jk_logger.h jk_map.c jk_map.h jk_msg_buff.c jk_msg_buff.h
jk_mt.h jk_nwmain.c jk_pool.c jk_pool.h jk_service.h jk_sockbuf.c
jk_sockbuf.h jk_uri_worker_map.c jk_uri_worker_map.h jk_util.c jk_util.h
jk_worker.c jk_worker.h jk_worker_list.h

hgomez  01/06/18 07:17:09

  Modified:jk/native/common jk_ajp12_worker.c jk_ajp12_worker.h
jk_ajp13.c jk_ajp13.h jk_ajp13_worker.c
jk_ajp13_worker.h jk_ajp14.c jk_ajp14.h
jk_ajp14_worker.c jk_ajp14_worker.h jk_ajp_common.c
jk_ajp_common.h jk_connect.c jk_connect.h
jk_context.c jk_context.h jk_global.h
jk_jni_worker.c jk_jni_worker.h jk_lb_worker.c
jk_lb_worker.h jk_logger.h jk_map.c jk_map.h
jk_msg_buff.c jk_msg_buff.h jk_mt.h jk_nwmain.c
jk_pool.c jk_pool.h jk_service.h jk_sockbuf.c
jk_sockbuf.h jk_uri_worker_map.c
jk_uri_worker_map.h jk_util.c jk_util.h jk_worker.c
jk_worker.h jk_worker_list.h
  Log:
  Updated Copyright notice to Apache 1.1
  
  Revision  ChangesPath
  1.3   +57 -55
jakarta-tomcat-connectors/jk/native/common/jk_ajp12_worker.c

.

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

J-T-C huge commit without mail

[GOMEZ Henri]

Hi,

Just upgraded jk Copyright notice to Apache 1.1.

But I stupidly forgot the qmail limitation and so
you didn't received the commit info by email .

ALL THE FILES in jk/native/common have been updated

APACHE 1.3/2.0, IIS, DOMINO, NETSCAPE are on the way

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

Missing CGIServlet from nightly build

[Kevin Jones]

I'm trying to use the Tomcat nightly's, and found that the
org.apache.catalina.servlets.CGIServlet class is missing from the 16th, 17th
and 18th June builds, although it (an its related classes) is in the earlier
nightlys,

Kevin Jones
DevelopMentor
www.develop.com

Session with IE

[Jose Luis Rodriguez]

My developed employment is IIS 4.0, Tomcat 3.2.1 under Windows Nt 4.0
I have a problem when I run mi application with IE 5.5, this lose the
session inmediatly that I run another time. With Netscape Communicator
that's Ok.
In SYSTEM32/LogFiles/W3SVC1 I see an error number 200 that say so:
06:42:14 197.100.1.12 GET /prueba2/Inicio.html 200
I have created a virtual path for jakarta with execute acces. What I do
bad?

Thanks in advance,
José Luis

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c

[hgomez]

hgomez  01/06/18 01:32:22

  Modified:jk/native/common jk_lb_worker.c
  Log:
  This patch changes the behavior by pre-initializing lb_value for each
  worker.  The selection algorithm searches for the worker with the lowest
  lb_value that is not in a failed state.  It then increments the lb_value
  by the lb_factor.  lb_factor is set to the inverse (1/x) of the
  lb_factor specified in the config file.  When lb_factor in the config
  file is 0, this number becomes basically MAX_DOUBLE.  That means that
  lb_value becomes MAX_DOUBLE, so it will never be selected for any
  practical purposes.
  Obtained from: Paul Frieden <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.3   +8 -2  jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
  
  Index: jk_lb_worker.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- jk_lb_worker.c2001/06/12 06:26:25 1.2
  +++ jk_lb_worker.c2001/06/18 08:32:18 1.3
  @@ -58,7 +58,7 @@
*  several workers.   *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
* Based on:   *
  - * Version: $Revision: 1.2 $   *
  + * Version: $Revision: 1.3 $   *
***/
   
   #include "jk_pool.h"
  @@ -427,7 +427,13 @@
   p->lb_workers[i].lb_factor = jk_get_lb_factor(props, 
  worker_names[i]);
   p->lb_workers[i].lb_factor = 1/p->lb_workers[i].lb_factor;
  -p->lb_workers[i].lb_value = 0.0;
  +/* 
  + * Allow using lb in fault-tolerant mode.
  + * Just set lbfactor in worker.properties to 0 to have 
  + * a worker used only when principal is down or session route
  + * point to it. Provided by Paul Frieden <[EMAIL PROTECTED]>
  + */
  +p->lb_workers[i].lb_value = p->lb_workers[i].lb_factor;
   p->lb_workers[i].in_error_state = JK_FALSE;
   p->lb_workers[i].in_recovering  = JK_FALSE;
   if(!wc_create_worker(p->lb_workers[i].name, 
  
  
  

RE: [PROPOSAL] Update to Tomcat 3.3 release schedule

[GOMEZ Henri]

+1

What about clean the proposals sub-dir.

jasper34 and web-connector have their own repositories.
These two sub-dirs will save 2.2Mb...


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

RE: cvs commit: jakarta-tomcat/src/etc server.xml

[GOMEZ Henri]

>  @@ -200,7 +197,9 @@
>   
>   
>className="org.apache.tomcat.modules.server.Ajp12Interceptor"
>  @@ -209,8 +208,8 @@
>   
>   
>   className="org.apache.ajp.tomcat33.Ajp13Interceptor"

AJP12/AJP13 bind change WILL HAVE TO BE COMMENTED IN Changelog since
many of us use Apache and Tomcat on differents machines and the Apache
won't be able to connect to localhost !

RE: structure for Tomcat-Connectors

[GOMEZ Henri]

>I am trying to think about a structure for our connectors:
> 
> 
> From httpd From httpd
>   | |
>+|
>+ AP1.3 | AP2.0 | NETSCAPE | DOMINO | others||
>+ 
>+  core mod_jk  + + mod_backhand +
>+ 
>+ ajp12 | ajp13 | apj14 | warp | new protocols  +|
>+|
>   | |
> To JVMTo JVM
>   | |
>+   +++
>+ ajp12 | ajp13 | apj14 | warp | new protocols  +   +   HTTP  +
>+   +++
>+   Tomcat  layers  +   + +
>+++
>+ ..  +
> 
>That would means that if we are writting a warp connector we 
>should only be
>worried by the protocol and have 2 sets of routines one to 
>get/send information
>from/to a core module, one to send/get information to/from a Tomcat.

On the Servlet Engine side, Coyote is a good starting point of
reflexion. Basically how to see an HTTP service ? 
We could be ambtious here and goes farther than just how to 
handle HTTP GET/POST.

>In a configuration like that the Apache 2.0 specialist would 
>write the AP2.0
>part, the Apache1-3 the AP1.3 and so on.
> 
>Having a defined interface to Tomcat there should be not 
>problem to get a
>protocol supported by all Tomcat versions.

mod_jk and its worker concept is a good framework.

But there is still lacks in it :
 
* The original worker in mod_jk from Tomcat 3.3 didn't 
  passed to workers validate/init functions information 
  about web-server (ie the URI to WORKER map). The autoconf
  features found in AJP14/WARP need that. I updated that in 
  J-T-C mod_jk.

* The original worker have no provision on how 
  to handle real-time information from servlet-engine to web-server.
  On the web-server, the connector task (which is 
  basically a redirect) only goes to life when a client 
  request arrive.
  What about change on the servlet-side ? ie: a servlet 
  context is make down by admin staff ? We should handle at that
  time the context down information by rerouting the request to another 
  worker (another servlet-engine). May be better to be informed of that
  in real-time to be able to update the URIs to WORKER table accordingly.
  That's a problem today, since we have many OS to support and many
web-server
  and a common solution is hard to find. 
  We should have new thread handling the real-time updates. 
  It's must be easy in Apache 2.0 and IIS (what about Netscape/Domino ?)
  But it's a problem in at least Apache 1.3/Linux where we could have
  problem using DSO and libpthread. 
  Also what about forked configurations (AP1.3) ? 
  Should we have 1 thread by forked child or did there is a way to share 
  data between all forked (shared-meme/MM)

* Could we think also about the web-server acting as an intelligent cache 
  system ? Many pages (or part of pages) may not change so often (JSP) and 
  if the web-servlet / servlet-engine could share a sort of ID/BYTES pool, 
  we could again reduce network-traffic between them. 

>* mod_backhand is not (yet) ours. 

The mod_backhand license is a no way for Apache at this time. Jon Stevens
tried to do some lobbying with backhand authors but what the current status 
of this action ?

Could we think using Java API like JINI to be an alternative ?
JINI support autoconf/discovery and also fault-tolerance built-in. 

Also we manily use TCP protocol in AJPxx/WARP. What about using UDP
(with securisation stuff ?)

Regards

RE: fault-tolerant/backup_mode in mod_jk : Was: [j-t-c] OS poll => [j-t-c] webserver poll

[GOMEZ Henri]

>This is actually very easy with the existing code and a tiny patch I
>submitted a few weeks ago.  We're using it in production mode, so it is
>known to be stable.  The first version I submitted had some additional
>logging added, but I'm attaching a minimal patch.
>
>All you have to do is set the lbfactor in workers.properties to 0, and
>it should never select that worker unless the session route points to
>it, or the primary worker is down.

Exactly what we want :)

>This also has the added benefit of making externally load balanced
>clusters behave properly for AOL/Compuserve users without special
>configuration of the load balancer.  Those services use IP randomizing
>proxies which break generic IP-based sticky.  This will cause the
>sessions to be re-routed from the Apache that receives the request to
>the Tomcat that initiated the session.  This actually works, because we
>were able to remove all of our special configurations to deal with this
>from our load balancers.  The problem is described at
>http://webmaster.info.aol.com/index.cfm?article=15

>This patch changes the behavior by pre-initializing lb_value for each
>worker.  The selection algorithm searches for the worker with 
>the lowest
>lb_value that is not in a failed state.  It then increments 
>the lb_value
>by the lb_factor.  lb_factor is set to the inverse (1/x) of the
>lb_factor specified in the config file.  When lb_factor in the config
>file is 0, this number becomes basically MAX_DOUBLE.  That means that
>lb_value becomes MAX_DOUBLE, so it will never be selected for any
>practical purposes.
>
>This patch has been tested extensivly in production use, and works
>perfectly.

Seems fine to me. I'll commit it today :)

RE: Changing the TomCat Directory structure...

[GOMEZ Henri]

>I don't see "reducing the number of top level directories" as a very
>compelling goal, and prefer to see the stuff sorted at the top 
>level based
>on which classloader it's going to go into.

+1

>Note also that having a top-level "lib" directory for user application
>classes is getting pretty common.

+1