Re: PROPOSAL: build directories

[costinm]

On Fri, 7 Jun 2002, Remy Maucherat wrote:

> We have a different definition of what a full build is. You define it as:
> rebuild everything from HEAD, including the dependent JARs (Gump style),
> while I define it as: rebuild all the Tomcat components (the 7 you defined
> above) based on "stable" versions of the dependent JARs. Since we should IMO
> base our work on stable versions of the dependent JARs, this seems like a
> legitimate way to do the build.

HEAD has nothing to do with it. 

My definition is of 'full build' is to be able to build all the components 
that end up in a distribution, based on CVS tags of stable versions ( and 
maybe patches ).

In order to maintain tomcat you _must_ be able to fix bugs in tomcat but
also in the packages it depends on - see the commons-logging problem we 
had. Or at least be able to debug the problem - i.e. add println() in
different places in code.

But even for our code, the round-trip for debugging is huge - you modify 
a class in util and have to wait 5 minutes for the main build to 
look in all the dirs. Or build util and copy the files. 

Anyway - one -1 is enough, and I got 4 already, so I give up :-)

I'll probably write my own script and use it, I can't deal with the
current mess of jars and distributions and files all over the place.

Costin



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

Re: PROPOSAL: build directories

[Pier Fumagalli]

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

>> Some of you may remember back in tomcat3.0 we used to
>> build all the stuff in jakarta-tomcat/../build and ../dist.
>> 
>> What do you think about moving back to that layout ?
> 
> I'd vote -1. I like the current style better. I have lots of different
> Tomcat 4.x repositories (4.0.4-b3, 4.0.x, 4.1.x, 4.0.3), and if the build
> was ../build, I'd have lots of nasty conflicts between the different copies.

Agreed...

Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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

DO NOT REPLY [Bug 8926] - Duplicate variable definition in generated Java source, related to custom tag scripting 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=8926

Duplicate variable definition in generated Java source, related to custom tag 
scripting variable





--- Additional Comments From [EMAIL PROTECTED]  2002-06-08 01:59 ---
This is the same bug that I just posted (9699).  I believe, I see that the 
do...while() loop containing "currentValue" also contains another 
do...while() loop with "currentValue" defined--although the code is a little 
hard to follow in this browser window.  This is improper java syntax.  It is a 
problem with self nested tags.  You can duplicate this example using the 
simple tag example FooTag, foo.jsp that installs with jakarta by nesting a 
 tag within the existing  tag.  See the other bug (9699) for 
a little more detail.  This is critical for us, it blocks development on 
Tomcat.  We are trying to port our application to Tomcat from Weblogic 6.  
By the way--this bugzilla thing is pretty cool, just used it for the first time 
today--and it sure beats Rational clearquest.

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

[FAQ] jGuru FAQ Update

[Alex Chaffee]

jGuru maintains FAQs and Forums on Servlets, JSP, and Tomcat (as well as
many other Java topics).  Here is an automated update on recent postings to
Tomcat-related FAQs.  Please direct flames and feedback to [EMAIL PROTECTED] .

 - Alex


 JGURU PREMIUM SERVICE!

 How often has jGuru helped you solve a problem?  Contribute to the
 Java community and keep jGuru the best place to get answers by
 becoming a premium member.

 Get the World's BEST JAVA SEARCH ENGINE, FASTER PAGE RENDERING, and
 NO ADS. Just 4.95 a month or subscribe for a year at 49.95 and get
 12 months for the price of 10 and a FREE XL JGURU T-SHIRT!  Sign up
 now and try out the premium service for two weeks at no charge!

http://www.jguru.com/misc/page.jsp?fsm=premiumreg&node=blurb&src=email


Hi.  You asked to be notified weekly when certain jGuru.com items get new entries.


++ JavaServer Pages (JSP) FAQ: http://www.jguru.com/faq/JSP

Is the HTTP Session maintained even when the network connection goes down? Can the 
same browser instance resume a previous session after re-establishing the network 
connection?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=906310

Is the HTTP Session maintained even when the network connection goes down? Can the 
same browser instance resume a previous session after re-establishing the network 
connection?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=906309

I am using Resin2.0. In our Intranet, all the user requests are directed to a servlet 
which does the authentication and redirects to the respective jsp files. Users are not 
supposed to access the jsp files directly. How to prevent, if a user access the jsp 
file directly by typing the url...This is possible after establishing the session...Is 
there any way to check this in the resin configuration, so that automatically 
redirecting to the servletIn resin.conf some mappings can be done for servlets..Is 
it possible for jsp..?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=906307


You can shut email notification off at the FAQ home
page(s) or:

  http://www.jguru.com/guru/notifyprefs.jsp



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

Re: PROPOSAL: build directories

[Remy Maucherat]

> On Fri, 7 Jun 2002, Remy Maucherat wrote:
>
> The problem is that I loose track of all the dozens of projects, each with
> different conventions and locations.
>
> By 'clean build' I meant building all the projects from their sources,
> to make sure all things are in sync. My conclusion so far - it's
> impossible to do so, there are far too many inderdependencies and
> chicken-egg problems.
>
> For 4.x we do build in 7 different places:
>
> - jakarta-tomcat-4.0/catalina/build
> - j-t/jasper/build
> - j-t-jasper/jasper2/build
> - j-t-c/util/build
> - j-t-c/jk/build
> - j-t-c/coyote/build
> - j-t-c/http11/build

Those are the source dependencies.

> To that you can add about 10 different build directories for
> jakarta-commons ( 3-4 ), log4j, mx4j, etc.

You are supposed to deal with stable versions of each of these. Because of
bugs, or because the package is not ready yet, we're not at the moment, but
hopefully this won't last for too long.

> Of course, it's simpler with checked-in binaries, but if you
> want to debug a cross-project problem it's hell. Jars are
> scatered in at least 20 directories.
>
> Can you do a full build of tomcat ( including all dependent jars
> that are open source ) ?

We have a different definition of what a full build is. You define it as:
rebuild everything from HEAD, including the dependent JARs (Gump style),
while I define it as: rebuild all the Tomcat components (the 7 you defined
above) based on "stable" versions of the dependent JARs. Since we should IMO
base our work on stable versions of the dependent JARs, this seems like a
legitimate way to do the build.

'ant clean' followed 'ant dist' will do that with 4.1.

Remy


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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime TagHandlerPool.java

[kinman]

kinman  2002/06/07 17:16:45

  Added:   jasper2/src/share/org/apache/jasper/runtime
TagHandlerPool.java
  Log:
  - Added a new runtime class.  Patch by Jan Luehe.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/TagHandlerPool.java
  
  Index: TagHandlerPool.java
  ===
  /*
   * 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
   * .
   *
   */ 
  
  package org.apache.jasper.runtime;
  
  import javax.servlet.jsp.JspException;
  import javax.servlet.jsp.tagext.Tag;
  
  /**
   * Pool of tag handlers that can be reused.
   *
   * @author Jan Luehe
   */
  public class TagHandlerPool {
  
  private static final int MAX_POOL_SIZE = 5;
  
  private Tag[] handlers;
  
  // index of next available tag handler
  private int current;
  
  /**
   * Constructs a tag handler pool with the default capacity.
   */
  public TagHandlerPool() {
this(MAX_POOL_SIZE);
  }
  
  /**
   * Constructs a tag handler pool with the given capacity.
   *
   * @param capacity Tag handler pool capacity
   */
  public TagHandlerPool(int capacity) {
this.handlers = new Tag[capacity];
this.current = -1;
  }
  
  /**
   * Gets the next available tag handler from this tag handler pool,
   * instantiating one if this tag handler pool is empty.
   *
   * @param handlerClass Tag handler class
   *
   * @return Reused or newly instantiated tag handler
   *
   * @throws JspException if a tag handler cannot be instantiated
   */
  public synchronized Tag get(Class handlerClass) throws JspException {
Tag handler = null;
  
if (current >= 0) {
handler = handlers[current--];
} else {
try {
return (Tag) handlerClass.newInstance();
} catch (Exception e) {
throw new JspException(e.getMessage(), e);
}
}
  
return handler;
  }
  
  /**
   * Adds the given tag handler to this tag handler pool, unless this tag
   * handler pool has already reached its capacity, in which case the tag
   * handler's release() method is called.
   *
   * @param handler T

cvs commit: jakarta-tomcat-connectors gump.xml

[costin]

costin  2002/06/07 17:15:13

  Modified:.gump.xml
  Log:
  Fix the gump descriptor.
  
  Revision  ChangesPath
  1.5   +1 -1  jakarta-tomcat-connectors/gump.xml
  
  Index: gump.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/gump.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- gump.xml  7 Jun 2002 04:07:11 -   1.4
  +++ gump.xml  8 Jun 2002 00:15:13 -   1.5
  @@ -13,7 +13,7 @@
   org.apache.tomcat.util
   
 
  -  
  +  
 
   
   
  
  
  

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

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

[kinman]

kinman  2002/06/07 17:14:35

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
JspUtil.java Node.java
  Log:
  Applied the patch supplied by Jan Luehe, to implement tag pooling/reuse
  based on a scheme Jan and I discussed.  Jan's note:
  
  Tag pooling/reuse is implemented as follows:
  
  - Every custom tag is assigned a tag handler pool, based on its full tag name
  and attribute set.
  
  - Tag handler pools are declared as servlet instance variables, so
  that they can be shared across page invocations.
  
  - Tag handler pools are instantiated with a
  yet-to-be-made-configurable capacity at servlet construction time
  (current default capacity is 5).
  
  - When a tag handler is required, it is retrieved from the appropriate
  tag handler pool. If the pool is empty, a new tag handler is instantiated and
  returned.
  
  - When a tag handler is no longer needed, it is returned to the appropriate
  pool. It is added to the pool, unless the pool has already reached its
  capacity, in which case the tag handler's release() method is called.
  
  - The servlet's destroy() method enumerates the servlet's tag handler
  pools and calls the release() method of every available tag handler.
  
  Outstanding issues:
  - Make tag handler pool capacity configurable.
  - Optimize tag reuse in the body of iteration tags.
  
  Revision  ChangesPath
  1.18  +154 -44   
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- Generator.java5 Jun 2002 22:01:33 -   1.17
  +++ Generator.java8 Jun 2002 00:14:35 -   1.18
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
 1.17 2002/06/05 22:01:33 kinman Exp $
  - * $Revision: 1.17 $
  - * $Date: 2002/06/05 22:01:33 $
  + * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
 1.18 2002/06/08 00:14:35 kinman Exp $
  + * $Revision: 1.18 $
  + * $Date: 2002/06/08 00:14:35 $
*
* 
* 
  @@ -96,6 +96,7 @@
   private boolean breakAtLF;
   private PageInfo pageInfo;
   private int maxTagNesting;
  +private Vector tagHandlerPoolNames;
   
   /**
* @param s the input string
  @@ -158,6 +159,99 @@
   }
   
   /**
  + * Compiles list of tag handler pool names.
  + */
  +private void compileTagHandlerPoolList(Node.Nodes page)
  + throws JasperException {
  +
  + class TagHandlerPoolVisitor extends Node.Visitor {
  +
  + private Vector names;
  +
  + /*
  +  * Constructor
  +  *
  +  * @param v Vector of tag handler pool names to populate
  +  */
  + TagHandlerPoolVisitor(Vector v) {
  + names = v;
  + }
  +
  + /*
  +  * Gets the name of the tag handler pool for the given custom tag
  +  * and adds it to the list of tag handler pool names unless it is
  +  * already contained in it.
  +  */
  + public void visit(Node.CustomTag n) throws JasperException {
  + 
  + String name = createTagHandlerPoolName(n.getPrefix(),
  + n.getShortName(),
  + n.getAttributes());
  + n.setTagHandlerPoolName(name);
  + if (!names.contains(name)) {
  + names.add(name);
  + }
  + visitBody(n);
  + }
  +
  + /*
  +  * Creates the name of the tag handler pool whose tag handlers may
  +  * be (re)used to service this action.
  +  *
  +  * @return The name of the tag handler pool
  +  */
  + private String createTagHandlerPoolName(String prefix,
  + String shortName,
  + Attributes attrs) {
  + String poolName = null;
  +
  + if (prefix.indexOf('-') >= 0)
  + prefix = JspUtil.replace(prefix, '-', "$1");
  + if (prefix.indexOf('.') >= 0)
  + prefix = JspUtil.replace(prefix, '.', "$2");
  +
  + if (shortName.indexOf('-') >= 0)
  + shortName = JspUtil.replace(shortName, '-', "$1");
  + if (shortName.indexOf('.') >= 0)
  + shortName = JspUtil.replace(shortName, '.', "$2");
  + if (shortName.indexOf(':') >= 0)
  + shortName = JspUtil.replace

Re: PROPOSAL: build directories

[costinm]

On Fri, 7 Jun 2002, Remy Maucherat wrote:

> I agree this is not perfect, but IMO it is a lot less risky that ../build. I
> could indeed maintain completely separate environments, but this is not very
> convinient or efficient (at least for me). Note that the current system
> doesn't prevent you from doing that (but the one you propose would require
> you to do so).

The problem is that I loose track of all the dozens of projects, each with 
different conventions and locations. 

By 'clean build' I meant building all the projects from their sources, 
to make sure all things are in sync. My conclusion so far - it's 
impossible to do so, there are far too many inderdependencies and 
chicken-egg problems. 

For 4.x we do build in 7 different places:

- jakarta-tomcat-4.0/catalina/build
- j-t/jasper/build
- j-t-jasper/jasper2/build
- j-t-c/util/build
- j-t-c/jk/build
- j-t-c/coyote/build
- j-t-c/http11/build

To that you can add about 10 different build directories for 
jakarta-commons ( 3-4 ), log4j, mx4j, etc.

Of course, it's simpler with checked-in binaries, but if you
want to debug a cross-project problem it's hell. Jars are
scatered in at least 20 directories.

Can you do a full build of tomcat ( including all dependent jars
that are open source ) ? 


Costin



> 
> > At least at my level of knowledge about jakarta and tomcat - I find
> > it close to impossible to have a clean build ( i.e. from sources ).
> 
> You'll notice that 'ant clean' in TC 4 clears all the Tomcat source
> dependencies, to avoid that.
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


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

Re: [4.1.3] Binaries uploaded

[costinm]

Can you try again ? I suspect it was a problem with some log statements
having NULL params ( as %s ).

I switched to use apr_vsprintf, now it should be consistent on all 
platforms.

Let me know what's the next error :-)

Costin


On Thu, 6 Jun 2002, jean-frederic clere wrote:

> GOMEZ Henri wrote:
> >>? I have:
> >>$ /home1/apache20/apache20/bin/apxs -q EXTRA_CFLAGS
> >>-DNO_DBM_REWRITEMAP$
> >>$ /home1/apache20/apache20/bin/apxs -q CFLAGS
> >>-DXTI_SUPPORT$
> >>
> >>The DXTI_SUPPORT is the missing one ;-)
> > 
> > 
> > Ok, so we need to concat CFLAGS & EXTRA_CFLAGS in jk_apxs.m4.
> > 
> > I must leave, could you update the CVS JF ?
> 
> Done ;-)
> 
> I will test the result tomorrow. The libtool or the libcrypt I have is somehow 
> broken: libtool has build *.a instead *.so:
> +++
> 
> *** Warning: This library needs some functionality provided by -lcrypt.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have.
> 
> ++
> 
> > 
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> > 
> > 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[costin]

costin  2002/06/07 16:45:30

  Modified:jk/native2/common jk_logger_file.c
   jk/native2/server/apache13 mod_jk2.c
   jk/native2/server/apache2 jk_logger_apache2.c mod_jk2.c
   jk/native2/server/isapi jk_isapi_plugin.c
  Log:
  If APR is available, use it to avoid some ugly vprintf/buf ugliness.
  
  Use APR pools if apr is available - there is no point in using the old
  jk pools if we use APR. Right now the only use of the jk_pool remains
  apache1.3 when built without APR ( to get around some aledged problems
  when the binary version of apr won't work with single-threaded apache ).
  
  This is also supposed to resolve the crash reported by JFC.
  
  Revision  ChangesPath
  1.24  +47 -1 jakarta-tomcat-connectors/jk/native2/common/jk_logger_file.c
  
  Index: jk_logger_file.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_logger_file.c,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- jk_logger_file.c  28 May 2002 22:44:50 -  1.23
  +++ jk_logger_file.c  7 Jun 2002 23:45:30 -   1.24
  @@ -59,7 +59,7 @@
* Description: Utility functions (mainly configuration)   *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
* Author:  Henri Gomez <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.23 $   *
  + * Version: $Revision: 1.24 $   *
***/
   
   #include "jk_env.h"
  @@ -210,6 +210,51 @@
return JK_OK;
   }
   
  +#ifdef HAS_APR
  +
  +static int JK_METHOD jk2_logger_file_jkVLog(jk_env_t *env, jk_logger_t *l,
  +  const char *file,
  +  int line,
  +  int level,
  +  const char *fmt,
  +  va_list args)
  +{
  +int rc = 0;
  +char *buf;
  +char *fmt1;
  +apr_pool_t *aprPool=env->tmpPool->_private;
  +char rfctime[APR_RFC822_DATE_LEN];
  +apr_time_t time = apr_time_now();
  +
  +if( !file || !args) {
  +return -1;
  +}
  +
  +if(l->logger_private==NULL ||
  +   l->level <= level) {
  +char *f = (char *)(file + strlen(file) - 1);
  +
  +while(f != file && '\\' != *f && '/' != *f) {
  +f--;
  +}
  +if(f != file) {
  +f++;
  +}
  +
  +/* XXX or apr_ctime ? */
  +apr_rfc822_date( rfctime, time );
  +fmt1=apr_pvsprintf( aprPool, "[%s] [%s:%d] %s", rfctime, file, line, fmt );
  +buf=apr_pvsprintf( aprPool, fmt, args );
  +
  +l->log(env, l, level, buf);
  +
  +}
  +
  +return rc;
  +}
  +
  +
  +#else
   
   static int JK_METHOD jk2_logger_file_jkVLog(jk_env_t *env, jk_logger_t *l,
 const char *file,
  @@ -284,6 +329,7 @@
   return rc;
   }
   
  +#endif
   
   
   static int jk2_logger_file_jkLog(jk_env_t *env, jk_logger_t *l,
  
  
  
  1.15  +12 -2 jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c
  
  Index: mod_jk2.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- mod_jk2.c 24 May 2002 07:12:32 -  1.14
  +++ mod_jk2.c 7 Jun 2002 23:45:30 -   1.15
  @@ -59,7 +59,7 @@
* Description: Apache 1.3 plugin for Jakarta/Tomcat *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
* Henri Gomez <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.14 $   *
  + * Version: $Revision: 1.15 $   *
***/
   
   /*
  @@ -130,6 +130,10 @@
   return NULL;
   }
   
  +#ifdef HAS_APR
  +apr_pool_t *jk_globalPool;
  +#endif
  +
   /* Create the initial set of objects. You need to cut&paste this and
  adapt to your server.
*/
  @@ -139,11 +143,17 @@
   jk_pool_t *globalPool;
   jk_bean_t *jkb;
   
  +#ifdef HAS_APR
  +apr_pool_create( &jk_globalPool, NULL );
  +
  +jk2_pool_apr_create( NULL, &globalPool, NULL, jk_globalPool );
  +#else
   /** First create a pool. We use the default ( jk ) pool impl,
*  other choices are apr or native.
*/
   jk2_pool_create( NULL, &globalPool, NULL, 2048 );
  -
  +#endif
  +
   /** Create the global environment. This will register the

cvs commit: jakarta-tomcat-connectors/jk/native2/jni jk_jni_aprImpl.c org_apache_jk_apr_AprImpl.h

[costin]

costin  2002/06/07 16:42:19

  Modified:jk/native2/jni jk_jni_aprImpl.c org_apache_jk_apr_AprImpl.h
  Log:
  Another patch from  Mladen Turk, cleaning up the singatures.
  
  Revision  ChangesPath
  1.31  +3 -3  jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c
  
  Index: jk_jni_aprImpl.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- jk_jni_aprImpl.c  31 May 2002 19:19:45 -  1.30
  +++ jk_jni_aprImpl.c  7 Jun 2002 23:42:19 -   1.31
  @@ -255,11 +255,11 @@
   return 0;
   }
   
  -JNIEXPORT jint JNICALL 
  +JNIEXPORT void JNICALL 
   Java_org_apache_jk_apr_AprImpl_sendSignal(JNIEnv *jniEnv, jobject _jthis, jint 
signo,
  -  jlong target)
  +  jint target)
   {
  -return 0;
  +
   }
   
   #endif
  
  
  
  1.5   +56 -49
jakarta-tomcat-connectors/jk/native2/jni/org_apache_jk_apr_AprImpl.h
  
  Index: org_apache_jk_apr_AprImpl.h
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/jni/org_apache_jk_apr_AprImpl.h,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- org_apache_jk_apr_AprImpl.h   28 May 2002 22:34:59 -  1.4
  +++ org_apache_jk_apr_AprImpl.h   7 Jun 2002 23:42:19 -   1.5
  @@ -17,6 +17,8 @@
   #define org_apache_jk_apr_AprImpl_HANDLE_RECEIVE_PACKET 10L
   #undef org_apache_jk_apr_AprImpl_HANDLE_SEND_PACKET
   #define org_apache_jk_apr_AprImpl_HANDLE_SEND_PACKET 11L
  +#undef org_apache_jk_apr_AprImpl_HANDLE_FLUSH
  +#define org_apache_jk_apr_AprImpl_HANDLE_FLUSH 12L
   /* Inaccessible static: aprSingleton */
   /* Inaccessible static: ok */
   /* Inaccessible static: jniMode */
  @@ -36,70 +38,77 @@
   JNIEXPORT jint JNICALL Java_org_apache_jk_apr_AprImpl_terminate
 (JNIEnv *, jobject);
   
  +/*
  + * Class: org_apache_jk_apr_AprImpl
  + * Method:getJkEnv
  + * Signature: ()J
  + */
  +JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_getJkEnv
  +  (JNIEnv *, jobject);
   
   /*
* Class: org_apache_jk_apr_AprImpl
  - * Method:unSocketClose
  - * Signature: (JJI)J
  + * Method:releaseJkEnv
  + * Signature: (J)V
*/
  -JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_unSocketClose
  -  (JNIEnv *, jobject, jlong, jint);
  +JNIEXPORT void JNICALL Java_org_apache_jk_apr_AprImpl_releaseJkEnv
  +  (JNIEnv *, jobject, jlong);
   
   /*
* Class: org_apache_jk_apr_AprImpl
  - * Method:unSocketListen
  - * Signature: (JLjava/lang/String;I)J
  + * Method:getJkHandler
  + * Signature: (JLjava/lang/String;)J
*/
  -JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_unSocketListen
  -  (JNIEnv *, jobject, jstring, jint);
  +JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_getJkHandler
  +  (JNIEnv *, jobject, jlong, jstring);
   
   /*
* Class: org_apache_jk_apr_AprImpl
  - * Method:unSocketConnect
  + * Method:createJkHandler
* Signature: (JLjava/lang/String;)J
*/
  -JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_unSocketConnect
  -  (JNIEnv *, jobject, jstring);
  +JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_createJkHandler
  +  (JNIEnv *, jobject, jlong, jstring);
   
   /*
* Class: org_apache_jk_apr_AprImpl
  - * Method:unAccept
  - * Signature: (JJ)J
  + * Method:jkSetAttribute
  + * Signature: (JJLjava/lang/String;Ljava/lang/String;)I
*/
  -JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_unAccept
  -  (JNIEnv *, jobject, jlong);
  +JNIEXPORT jint JNICALL Java_org_apache_jk_apr_AprImpl_jkSetAttribute
  +  (JNIEnv *, jobject, jlong, jlong, jstring, jstring);
   
   /*
* Class: org_apache_jk_apr_AprImpl
  - * Method:unRead
  - * Signature: (JJ[BII)I
  + * Method:jkGetAttribute
  + * Signature: (JJLjava/lang/String;)Ljava/lang/String;
*/
  -JNIEXPORT jint JNICALL Java_org_apache_jk_apr_AprImpl_unRead
  -  (JNIEnv *, jobject, jlong, jbyteArray, jint, jint);
  +JNIEXPORT jstring JNICALL Java_org_apache_jk_apr_AprImpl_jkGetAttribute
  +  (JNIEnv *, jobject, jlong, jlong, jstring);
   
   /*
* Class: org_apache_jk_apr_AprImpl
  - * Method:unWrite
  - * Signature: (JJ[BII)I
  + * Method:jkInit
  + * Signature: (JJ)I
*/
  -JNIEXPORT jint JNICALL Java_org_apache_jk_apr_AprImpl_unWrite
  -  (JNIEnv *, jobject, jlong, jbyteArray, jint, jint);
  +JNIEXPORT jint JNICALL Java_org_apache_jk_apr_AprImpl_jkInit
  +  (JNIEnv *, jobject, jlong, jlong);
   
   /*
* Class: org_apache_jk_apr_AprImpl
  - * Method:getJkEnv
  - * Signature: ()J
  + * Method:jkDestroy
  + * Signature: (JJ)I
*/
  -JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_getJkEnv
  -  (JNIEnv *, jobjec

Re: PROPOSAL: build directories

[Remy Maucherat]

> On Fri, 7 Jun 2002, Remy Maucherat wrote:
>
> > > Some of you may remember back in tomcat3.0 we used to
> > > build all the stuff in jakarta-tomcat/../build and ../dist.
> > >
> > > What do you think about moving back to that layout ?
> >
> > I'd vote -1. I like the current style better. I have lots of different
> > Tomcat 4.x repositories (4.0.4-b3, 4.0.x, 4.1.x, 4.0.3), and if the
build
> > was ../build, I'd have lots of nasty conflicts between the different
copies.
>
> I could use separate 'workspaces' for each version ( or combination) -
i.e.
> /ws/40
> /ws/41
> /ws/gump
>
> In each you can have a certain combination of versions, including
> builds from HEAD, etc. How do you work with jakarta-tomcat-connectors
> and jasper ? ( the tagged and HEAD versions ) ?

I use the properties to define which repositories I want in my build.

> Right now each component creates a build/ somewhere 1-2 levels deep
> in the _source_ tree, copies stuff from different places - a
> total mess, even if you are familiar with the sources.

I agree this is not perfect, but IMO it is a lot less risky that ../build. I
could indeed maintain completely separate environments, but this is not very
convinient or efficient (at least for me). Note that the current system
doesn't prevent you from doing that (but the one you propose would require
you to do so).

> At least at my level of knowledge about jakarta and tomcat - I find
> it close to impossible to have a clean build ( i.e. from sources ).

You'll notice that 'ant clean' in TC 4 clears all the Tomcat source
dependencies, to avoid that.

Remy


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

Re: PROPOSAL: build directories

[Eric Rescorla]

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

> > Some of you may remember back in tomcat3.0 we used to
> > build all the stuff in jakarta-tomcat/../build and ../dist.
> >
> > What do you think about moving back to that layout ?
> 
> I'd vote -1. I like the current style better. I have lots of different
> Tomcat 4.x repositories (4.0.4-b3, 4.0.x, 4.1.x, 4.0.3), and if the build
> was ../build, I'd have lots of nasty conflicts between the different copies.
I agree with Remy here.

-Ekr

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

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

Re: PROPOSAL: build directories

[costinm]

On Fri, 7 Jun 2002, Remy Maucherat wrote:

> > Some of you may remember back in tomcat3.0 we used to
> > build all the stuff in jakarta-tomcat/../build and ../dist.
> >
> > What do you think about moving back to that layout ?
> 
> I'd vote -1. I like the current style better. I have lots of different
> Tomcat 4.x repositories (4.0.4-b3, 4.0.x, 4.1.x, 4.0.3), and if the build
> was ../build, I'd have lots of nasty conflicts between the different copies.

I could use separate 'workspaces' for each version ( or combination) -  i.e.
/ws/40
/ws/41
/ws/gump

In each you can have a certain combination of versions, including
builds from HEAD, etc. How do you work with jakarta-tomcat-connectors 
and jasper ? ( the tagged and HEAD versions ) ? 

Right now each component creates a build/ somewhere 1-2 levels deep
in the _source_ tree, copies stuff from different places - a 
total mess, even if you are familiar with the sources. 

At least at my level of knowledge about jakarta and tomcat - I find
it close to impossible to have a clean build ( i.e. from sources ).


Costin


> 
> > Also, we curently rely on having all dependency as a
> > full package. It may be better to just have all the
> > .jar files built ( or copied/checkout ) in a single
> >  lib/ directory. This will eliminate most of the complexity
> > from our build files.
> >
> > ( that's post-4.1.0, of course - i.e. in the main tree )
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


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

DO NOT REPLY [Bug 9705] - Extra LDAP searches occur during JNDIRealm authentication

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

Extra LDAP searches occur during JNDIRealm authentication





--- Additional Comments From [EMAIL PROTECTED]  2002-06-07 22:56 ---
AFAIK, nobody is currently actively maintaining the JNDI realm. So the changes 
you propose won't be implemented anytime soon unless you submit some patches.

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

Re: PROPOSAL: build directories

[Remy Maucherat]

> Some of you may remember back in tomcat3.0 we used to
> build all the stuff in jakarta-tomcat/../build and ../dist.
>
> What do you think about moving back to that layout ?

I'd vote -1. I like the current style better. I have lots of different
Tomcat 4.x repositories (4.0.4-b3, 4.0.x, 4.1.x, 4.0.3), and if the build
was ../build, I'd have lots of nasty conflicts between the different copies.

> Also, we curently rely on having all dependency as a
> full package. It may be better to just have all the
> .jar files built ( or copied/checkout ) in a single
>  lib/ directory. This will eliminate most of the complexity
> from our build files.
>
> ( that's post-4.1.0, of course - i.e. in the main tree )

Remy


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

PROPOSAL: build directories

[costinm]

Some of you may remember back in tomcat3.0 we used to 
build all the stuff in jakarta-tomcat/../build and ../dist.

What do you think about moving back to that layout ? 

Also, we curently rely on having all dependency as a 
full package. It may be better to just have all the 
.jar files built ( or copied/checkout ) in a single
 lib/ directory. This will eliminate most of the complexity
from our build files. 

( that's post-4.1.0, of course - i.e. in the main tree )



Costin


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

cvs commit: jakarta-tomcat-connectors/lib commons-logging-api.jar commons-logging.jar mx4j.jar mx4j-tools.jar

[costin]

costin  2002/06/07 14:29:18

  Modified:lib  commons-logging-api.jar commons-logging.jar
mx4j.jar mx4j-tools.jar
  Log:
  Update with a build from CVS. To reproduce use today's date, I'll
  update the build as soon as a release is made.
  
  The current 'official' release has problems.
  
  Revision  ChangesPath
  1.2   +26 -17jakarta-tomcat-connectors/lib/commons-logging-api.jar
  
<>
  
  
  1.6   +30 -29jakarta-tomcat-connectors/lib/commons-logging.jar
  
<>
  
  
  1.3   +309 -290  jakarta-tomcat-connectors/lib/mx4j.jar
  
<>
  
  
  1.3   +164 -169  jakarta-tomcat-connectors/lib/mx4j-tools.jar
  
<>
  
  

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

DO NOT REPLY [Bug 9705] New: - Extra LDAP searches occur during JNDIRealm authentication

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

Extra LDAP searches occur during JNDIRealm authentication

   Summary: Extra LDAP searches occur during JNDIRealm
authentication
   Product: Tomcat 4
   Version: 4.1.3
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm using JNDIRealm with the following setup.

ldap://myldapserver";
userPattern="uid={0}, ou=People, dc=mydomain"
userRoleName="ou"/>

I noticed that JNDIRealm is performing an extra query with a search base of "" 
and a filter of "(objectClass=*)". If I perform this search using ldapsearch, 
I receive an error of "ldap_search: No such object", so, it appears that that 
search isn't returning any meaningful information.

The following is what gets logged when using iPlanet Directory Server 5.1.

[07/Jun/2002:15:41:36 -0500] conn=23 op=12 BIND dn="cn=Directory Manager" 
method=128 version=3
[07/Jun/2002:15:41:36 -0500] conn=23 op=12 RESULT err=0 tag=97 nentries=0 
etime=0 dn="cn=directory manager"
[07/Jun/2002:15:41:36 -0500] conn=23 op=13 SRCH base="uid=jemiller, ou=People, 
dc=mydomain" scope=0 filter="(objectClass=*)" attrs="ou"
[07/Jun/2002:15:41:36 -0500] conn=23 op=13 RESULT err=0 tag=101 nentries=1 
etime=0
[07/Jun/2002:15:41:36 -0500] conn=23 op=14 BIND dn="uid=jemiller, ou=People, 
dc=mydomain" method=128 version=3
[07/Jun/2002:15:41:36 -0500] conn=23 op=14 RESULT err=0 tag=97 nentries=0 
etime=0 dn="uid=jemiller,ou=people,dc=mydomain"
[07/Jun/2002:15:41:36 -0500] conn=23 op=15 SRCH base="" scope=0 
filter="(objectClass=*)" attrs=ALL
[07/Jun/2002:15:41:36 -0500] conn=23 op=15 RESULT err=0 tag=101 nentries=1 
etime=0

Another possible optimization could be implemented for the following setup. 
With this setup connectionName and connectionPassword are left unspecified. As 
a result, an anonymous bind occurs when querying for the userRoleName. This 
works as long as the attribute that is being queried for is readable by the 
anonymous user.

ldap://myldapserver";
userPattern="uid={0}, ou=People, dc=mydomain"
userRoleName="ou"/>

This is what the log looks like. As you can see, it's the same as above. In 
this case, really all you need to do is bind as the user that you are 
authenticating. IMHO, if the connectionName and connectionPassword are left 
unspecified, it shouldn't perform the extra bind.

[07/Jun/2002:15:54:05 -0500] conn=26 op=0 BIND dn="" method=128 version=3
[07/Jun/2002:15:54:05 -0500] conn=26 op=0 RESULT err=0 tag=97 nentries=0 
etime=0 dn=""
[07/Jun/2002:15:54:26 -0500] conn=26 op=1 SRCH base="uid=jemiller, ou=People, 
dc=mydomain" scope=0 filter="(objectClass=*)" attrs="ou"
[07/Jun/2002:15:54:26 -0500] conn=26 op=1 RESULT err=0 tag=101 nentries=1 
etime=0
[07/Jun/2002:15:54:26 -0500] conn=26 op=2 BIND dn="uid=jemiller, ou=People, 
dc=mydomain" method=128 version=3
[07/Jun/2002:15:54:26 -0500] conn=26 op=2 RESULT err=0 tag=97 nentries=0 
etime=0 dn="uid=jemiller,ou=people,dc=mydomain"
[07/Jun/2002:15:54:26 -0500] conn=26 op=3 SRCH base="" scope=0 
filter="(objectClass=*)" attrs=ALL
[07/Jun/2002:15:54:26 -0500] conn=26 op=3 RESULT err=0 tag=101 nentries=1 
etime=0

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

DO NOT REPLY [Bug 9703] New: - Two extra authentications occur for each JNDIRealm authentication

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

Two extra authentications occur for each JNDIRealm authentication

   Summary: Two extra authentications occur for each JNDIRealm
authentication
   Product: Tomcat 4
   Version: 4.1.3
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm using JNDIRealm with the following setup.

ldap://myldapserver";
roleBase="ou=roles, dc=mydomain"
roleName="cn"
roleSearch="(uniqueMember={0})"
roleSubtree="false"
userPattern="uid={0}, ou=People, dc=mydomain"/>

As you can see, I have it setup so that it authenticates the user by binding 
to the directory as them rather than querying for a password attribute. I 
found that for every authentication (i.e. everytime I access a protected page) 
it authenticates two extra times.

The following is what gets written to the log for iPlanet Directory Server 5.1 
during one authentication. As you can see, it does the same thing three times 
instead of only once.

I tested this with OpenLDAP as well and the behavior was the same.

[07/Jun/2002:15:03:01 -0500] conn=14 op=0 BIND dn="cn=Directory Manager" 
method=128 version=3
[07/Jun/2002:15:03:01 -0500] conn=14 op=0 RESULT err=0 tag=97 nentries=0 
etime=0 dn="cn=directory manager"
[07/Jun/2002:15:03:33 -0500] conn=14 op=1 BIND dn="uid=jemiller, ou=People, 
dc=mydomain" method=128 version=3
[07/Jun/2002:15:03:33 -0500] conn=14 op=1 RESULT err=0 tag=97 nentries=0 
etime=0 dn="uid=jemiller,ou=people,dc=mydomain"
[07/Jun/2002:15:03:33 -0500] conn=14 op=2 SRCH base="" scope=0 
filter="(objectClass=*)" attrs=ALL
[07/Jun/2002:15:03:33 -0500] conn=14 op=2 RESULT err=0 tag=101 nentries=1 
etime=0
[07/Jun/2002:15:03:33 -0500] conn=14 op=3 BIND dn="cn=Directory Manager" 
method=128 version=3
[07/Jun/2002:15:03:33 -0500] conn=14 op=3 RESULT err=0 tag=97 nentries=0 
etime=0 dn="cn=directory manager"
[07/Jun/2002:15:03:33 -0500] conn=14 op=4 SRCH base="ou=roles, dc=mydomain" 
scope=1 filter="(uniqueMember=uid=jemiller, ou=People, dc=mydomain)" attrs="cn"
[07/Jun/2002:15:03:33 -0500] conn=14 op=4 RESULT err=0 tag=101 nentries=1 
etime=0

[07/Jun/2002:15:03:33 -0500] conn=14 op=5 BIND dn="uid=jemiller, ou=People, 
dc=mydomain" method=128 version=3
[07/Jun/2002:15:03:33 -0500] conn=14 op=5 RESULT err=0 tag=97 nentries=0 
etime=0 dn="uid=jemiller,ou=people,dc=mydomain"
[07/Jun/2002:15:03:33 -0500] conn=14 op=6 SRCH base="" scope=0 
filter="(objectClass=*)" attrs=ALL
[07/Jun/2002:15:03:33 -0500] conn=14 op=6 RESULT err=0 tag=101 nentries=1 
etime=0
[07/Jun/2002:15:03:33 -0500] conn=14 op=7 BIND dn="cn=Directory Manager" 
method=128 version=3
[07/Jun/2002:15:03:33 -0500] conn=14 op=7 RESULT err=0 tag=97 nentries=0 
etime=0 dn="cn=directory manager"
[07/Jun/2002:15:03:33 -0500] conn=14 op=8 SRCH base="ou=roles, dc=mydomain" 
scope=1 filter="(uniqueMember=uid=jemiller, ou=People, dc=mydomain)" attrs="cn"
[07/Jun/2002:15:03:33 -0500] conn=14 op=8 RESULT err=0 tag=101 nentries=1 
etime=0

[07/Jun/2002:15:03:33 -0500] conn=14 op=9 BIND dn="uid=jemiller, ou=People, 
dc=mydomain" method=128 version=3
[07/Jun/2002:15:03:33 -0500] conn=14 op=9 RESULT err=0 tag=97 nentries=0 
etime=0 dn="uid=jemiller,ou=people,dc=mydomain"
[07/Jun/2002:15:03:33 -0500] conn=14 op=10 SRCH base="" scope=0 
filter="(objectClass=*)" attrs=ALL
[07/Jun/2002:15:03:33 -0500] conn=14 op=10 RESULT err=0 tag=101 nentries=1 
etime=0
[07/Jun/2002:15:03:33 -0500] conn=14 op=11 BIND dn="cn=Directory Manager" 
method=128 version=3
[07/Jun/2002:15:03:33 -0500] conn=14 op=11 RESULT err=0 tag=97 nentries=0 
etime=0 dn="cn=directory manager"
[07/Jun/2002:15:03:33 -0500] conn=14 op=12 SRCH base="ou=roles, dc=mydomain" 
scope=1 filter="(uniqueMember=uid=jemiller, ou=People, dc=mydomain)" attrs="cn"
[07/Jun/2002:15:03:33 -0500] conn=14 op=12 RESULT err=0 tag=101 nentries=1 
etime=0

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java JspReader.java Parser.java ParserController.java CompileException.java ParseException.java

[kinman]

kinman  2002/06/07 13:04:28

  Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
JspReader.java Parser.java ParserController.java
  Removed: jasper2/src/share/org/apache/jasper/compiler
CompileException.java ParseException.java
  Log:
  - Removed unused classes and methods.
  
  Revision  ChangesPath
  1.13  +3 -41 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
  
  Index: Compiler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Compiler.java 5 Jun 2002 22:01:33 -   1.12
  +++ Compiler.java 7 Jun 2002 20:04:27 -   1.13
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
 1.12 2002/06/05 22:01:33 kinman Exp $
  - * $Revision: 1.12 $
  - * $Date: 2002/06/05 22:01:33 $
  + * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
 1.13 2002/06/07 20:04:27 kinman Exp $
  + * $Revision: 1.13 $
  + * $Date: 2002/06/07 20:04:27 $
*
* 
* 
  @@ -340,44 +340,6 @@
   
   public JspCompilationContext getCompilationContext() {
return ctxt;
  -}
  -
  -
  -/**
  - * Change the encoding for the reader if specified.
  - */
  -public String changeEncodingIfNecessary(JspReader tmpReader)
  - throws JasperException {
  -
  - // A lot of code replicated from Parser.java
  - // Main aim is to "get-it-to-work".
  - while (tmpReader.skipUntil("<%@") != null) {
  -
  - tmpReader.skipSpaces();
  -
  - // check if it is a page directive.
  - if (tmpReader.matches("page")) {
  -
  - tmpReader.advance(4);
  - tmpReader.skipSpaces();
  - 
  - try {
  - Attributes attrs = tmpReader.parseTagAttributes();
  - String ct = attrs.getValue("contentType");
  - if (ct != null) {
  - int loc = ct.indexOf("charset=");
  - if (loc > 0) {
  - String encoding = ct.substring(loc + 8);
  - return encoding;
  - }
  - }
  - } catch (ParseException ex) {
  - // Ignore the exception here, it will be caught later.
  - return null;
  - }
  - }
  - }
  - return null;
   }
   
   
  
  
  
  1.5   +0 -217
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspReader.java
  
  Index: JspReader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspReader.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- JspReader.java17 Apr 2002 01:42:54 -  1.4
  +++ JspReader.java7 Jun 2002 20:04:27 -   1.5
  @@ -457,223 +457,6 @@
   }
   
   /**
  - * Parse an attribute/value pair, and store it in provided hash table.
  - * The attribute/value pair is defined by:
  - * 
  - * av := spaces token spaces '=' spaces token spaces
  - * 
  - * Where token is defined by parseToken and
  - * spaces is defined by skipSpaces.
  - * The name is always considered case insensitive, hence stored in its
  - * lower case version.
  - * @param into The Hashtable instance to save the result to.
  - */
  -private void parseAttributeValue(AttributesImpl into)
  - throws JasperException {
  - // Get the attribute name:
  - skipSpaces();
  - String name = parseToken(false);
  - // Check for an equal sign:
  - skipSpaces();
  - if (peekChar() != '=') {
  - err.jspError(mark(), "jsp.error.attr.novalue", name);
  - }
  - char ch = (char) nextChar();
  - // Get the attribute value:
  - skipSpaces();
  - String value = parseToken(true);
  - skipSpaces();
  - // Add the binding to the provided hashtable:
  -//TODO review if the empty namespace works, or if we should get another one
  -//TODO do we want to use typw to indicate rt expression/scripting vlaue?
  - into.addAttribute("", name, name, "CDATA", value);
  - return;
  -}
  -
  -/**
  - * Parse some tag attributes for Beans.
  - * The stream is assumed to be positioned right after the tag name. The
  - * syntax recognized is:
  - * 
  - * tag-attrs := empty | attr-list (">" | "-->" | %>)
  - * attr-list := empty | av spaces attr-list
  -   

DO NOT REPLY [Bug 9702] New: - JNDIRealm StartTLS/SSL support request

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

JNDIRealm StartTLS/SSL support request

   Summary: JNDIRealm StartTLS/SSL support request
   Product: Tomcat 4
   Version: 4.1.3
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Would it be possible to add StartTLS or SSL support to JNDIRealm? In theory, 
it should be relatively simple. For SSL support, you would just need to add a 
line similar to the following.

h.put(Context.SECURITY_PROTOCOL, "ssl");

For StartTLS, you would just need something like the following.

LdapContext lc = new InitialLdapContext(h, null);

StartTlsResponse stlsr = (StartTlsResponse)lc.extendedOperation(new 
StartTlsRequest());

stlsr.negotiate();

And then, maybe add an attribute that you can put in your server.xml similar 
to what you have for the HTTP connector like the following.

secure="true"

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

Re: 4.1.3b1 zip lib crash

[Remy Maucherat]

> That helps me? Some pointers on what to try next maybe

I ran out of ideas. Unless somebody else can reproduce it and can look into
it, I can't do anything. It works for me on all JDKs on my Win2k box.

> Could using a conf file from 4.0.x (modified to use Coyote http/1.1
> connector) be the culprit? Should I not be using
> org.apache.catalina.logger.FileLogger anymore?

It doesn't use commons-logging, so it's not the problem.

Remy


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

Re: 4.1.3b1 zip lib crash

[Nick Wesselman]

[nick@odyssey conf]$ /usr/java/j2sdk1.4.0/bin/javap 
java.util.logging.Logger | grep setUseParentHandlers
[nick@odyssey conf]$

Something added in 1.4.0_01 maybe?

Nick

On Friday, June 7, 2002, at 02:49 PM, [EMAIL PROTECTED] wrote:

>
>> OK, How about this? From the catalina.out when I try using jdk 1.4...
>> ...
>> Caused by: java.lang.NoSuchMethodError:
>> java.util.logging.Logger.setUseParentHandlers(Z)V
>> org.apache.commons.logging.impl.Jdk14Logger.(Jdk14Logger.java:97)
>
> Humm. I seem to have method setUseParentHandlers, do you?
>
> $ javap java.util.logging.Logger | grep setUseParentHandlers
> public synchronized void setUseParentHandlers(boolean);
>
> Cheers,
> -bob
>
> --
> To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> For additional commands, e-mail:  [EMAIL PROTECTED]>


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

Re: 4.1.3b1 zip lib crash

[bob]

> OK, How about this? From the catalina.out when I try using jdk 1.4...
> ...
> Caused by: java.lang.NoSuchMethodError: 
> java.util.logging.Logger.setUseParentHandlers(Z)V
> org.apache.commons.logging.impl.Jdk14Logger.(Jdk14Logger.java:97)

Humm. I seem to have method setUseParentHandlers, do you?

$ javap java.util.logging.Logger | grep setUseParentHandlers
public synchronized void setUseParentHandlers(boolean);

Cheers,
-bob

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

Re: 4.1.3b1 zip lib crash

[Nick Wesselman]

That helps me? Some pointers on what to try next maybe

Could using a conf file from 4.0.x (modified to use Coyote http/1.1 
connector) be the culprit? Should I not be using 
org.apache.catalina.logger.FileLogger anymore?

Nick

On Friday, June 7, 2002, at 02:23 PM, Remy Maucherat wrote:

>> OK, How about this? From the catalina.out when I try using jdk 1.4...
>>
>
>> java.lang.reflect.Constructor.newInstance(Constructor.java:263)
>>  at
>> org.apache.commons.logging.impl.LogFactoryImpl.newInstance
>> (LogFactoryImpl.java:487)
>>  ... 12 more
>> Caused by: java.lang.NoSuchMethodError:
>> java.util.logging.Logger.setUseParentHandlers(Z)V
>>  at
>> org.apache.commons.logging.impl.Jdk14Logger.(Jdk14Logger.java:97)
>>  ... 17 more
>
> I'm using JDK 1.4 on Windows (on the box used to generate the build 
> you're
> using) and it works (and uses the JDK 1.4 logger).
>
> Remy
>
>
> --
> To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> For additional commands, e-mail:  [EMAIL PROTECTED]>


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

Re: 4.1.3b1 zip lib crash

[Remy Maucherat]

> OK, How about this? From the catalina.out when I try using jdk 1.4...
>

> java.lang.reflect.Constructor.newInstance(Constructor.java:263)
>  at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance
> (LogFactoryImpl.java:487)
>  ... 12 more
> Caused by: java.lang.NoSuchMethodError:
> java.util.logging.Logger.setUseParentHandlers(Z)V
>  at
> org.apache.commons.logging.impl.Jdk14Logger.(Jdk14Logger.java:97)
>  ... 17 more

I'm using JDK 1.4 on Windows (on the box used to generate the build you're
using) and it works (and uses the JDK 1.4 logger).

Remy


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

How to use just Catalina connector

[Chandra Talluri]

Hi,

I am just wondering how to go about the following problem

We have our own server which accepts the data either on a TCP port or an UDP
port.  we want to use only Catalina connector to process the data and spit
out html. We don't want to use any web server or the tomcat server.

Basically we want to integrate the catalina.jar and other required jars in
our server so that our server can invoke the servlets.

Is it possible and if so can some one give where should I start with by
pointing either examples or documents

Any input is appreciated

-Chandra Talluri
NetNumber.com, Inc.
650 Suffolk Street
Suite 307
Lowell, MA 01854
Tel: 978-848-2841
[EMAIL PROTECTED]
http://www.netnumber.com


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

Re: 4.1.3b1 zip lib crash

[Nick Wesselman]

OK, How about this? From the catalina.out when I try using jdk 1.4...

org.apache.commons.logging.LogConfigurationException: 
java.lang.reflect.InvocationTargetException
 at 
org.apache.commons.logging.impl.LogFactoryImpl.newInstance
(LogFactoryImpl.java:494)
 at 
org.apache.commons.logging.impl.LogFactoryImpl.getInstance
(LogFactoryImpl.java:285)
 at 
org.apache.commons.logging.LogFactory.getLog(LogFactory.java:400)
 at org.apache.commons.digester.Digester.(Digester.java:310)
 at 
org.apache.catalina.startup.Catalina.createStartDigester(Catalina.java:280)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:441)
 at 
org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
 at 
org.apache.catalina.startup.Catalina.process(Catalina.java:180)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
42)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:28)
 at java.lang.reflect.Method.invoke(Method.java:313)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
Caused by: java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
Method)
 at 
sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:42)
 at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:30)
 at 
java.lang.reflect.Constructor.newInstance(Constructor.java:263)
 at 
org.apache.commons.logging.impl.LogFactoryImpl.newInstance
(LogFactoryImpl.java:487)
 ... 12 more
Caused by: java.lang.NoSuchMethodError: 
java.util.logging.Logger.setUseParentHandlers(Z)V
 at 
org.apache.commons.logging.impl.Jdk14Logger.(Jdk14Logger.java:97)
 ... 17 more

Nick

On Friday, June 7, 2002, at 02:08 PM, Remy Maucherat wrote:

>> OK, I gave the IBM jdk a shot, and it crashes on me as well. 
>> Interesting
>> that it also happens related to opening a zip:
>>
>>  "main" (TID:0x100519D8, sys_thread_t:0x8059108, state:R, native
>> ID:0x400) prio=5
>>  at java.util.zip.ZipFile.open(Native Method)
>>  at java.util.zip.ZipFile.(ZipFile.java:127)
>>  at java.util.jar.JarFile.(JarFile.java:138)
>>  at 
>> sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:62)
>>  at 
>> sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:45)
>>  at 
>> sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:166)
>>  at java.security.AccessController.doPrivileged(Native Method)
>>  at
>> sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:152)
>>  at
>> sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:57)
>>  at
>> sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:65)
>>  at
>>
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:108)
>>  at
>>
> sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:
>> 92)
>>  at
>>
> org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:894)
>
> I don't see anything wrong with the code in that source file. That code 
> is
> more or less identical in 4.0.x.
>
> Unless you can point out a specific flaw in what Tomcat does, this 
> won't be
> fixed.
>
> Remy
>
>
> --
> To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> For additional commands, e-mail:  [EMAIL PROTECTED]>


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

Re: Tomcat 4.0 nightly build binary downloads broken?

[costinm]

On Fri, 7 Jun 2002, Craig R. McClanahan wrote:

> It wasn't Jasper2 that killed it ... it was the switch to Ant 1.5b2.  I'll
> try to get that working again on my box over the weekend, but it would be
> better to migrate the standard nightly build process somewhere else.

Well, jakarta-tomcat-utils is now killing all tomcat gump builds.

I'm working on it.

Costin


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

Re: 4.1.3b1 zip lib crash

[Remy Maucherat]

> OK, I gave the IBM jdk a shot, and it crashes on me as well. Interesting
> that it also happens related to opening a zip:
>
>  "main" (TID:0x100519D8, sys_thread_t:0x8059108, state:R, native
> ID:0x400) prio=5
>  at java.util.zip.ZipFile.open(Native Method)
>  at java.util.zip.ZipFile.(ZipFile.java:127)
>  at java.util.jar.JarFile.(JarFile.java:138)
>  at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:62)
>  at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:45)
>  at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:166)
>  at java.security.AccessController.doPrivileged(Native Method)
>  at
> sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:152)
>  at
> sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:57)
>  at
> sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:65)
>  at
>
sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:108)
>  at
>
sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:
> 92)
>  at
>
org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:894)

I don't see anything wrong with the code in that source file. That code is
more or less identical in 4.0.x.

Unless you can point out a specific flaw in what Tomcat does, this won't be
fixed.

Remy


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

[PATCH] Tag pooling/reuse in Jasper 2 (RESENT)

[Jan Luehe]

[I am resending this patch, since my original posting apparently did not
make it to the list.]

Attached is a patch implementing tag pooling and tag reuse for Jasper 2.
I am also attaching a new class org.apache.jasper.runtime.TagHandlerPool
implementing a tag handler pool (org.apache.jasper.util.SimplePool
is not being leveraged, since we want our pool's get() method to
encapsulate the logic of instantiating a new tag handler if the pool
is empty, and its reuse() method to encapsulate the logic of calling
the handler's release() method if the pool is full).


Tag pooling/reuse is implemented as follows:

- Every custom tag is assigned a tag handler pool, based on its full tag name
and attribute set.

- Tag handler pools are declared as servlet instance variables, so
that they can be shared across page invocations.

- Tag handler pools are instantiated with a
yet-to-be-made-configurable capacity at servlet construction time
(current default capacity is 5).

- When a tag handler is required, it is retrieved from the appropriate
tag handler pool. If the pool is empty, a new tag handler is instantiated and
returned.

- When a tag handler is no longer needed, it is returned to the appropriate
pool. It is added to the pool, unless the pool has already reached its
capacity, in which case the tag handler's release() method is called.

- The servlet's destroy() method enumerates the servlet's tag handler
pools and calls the release() method of every available tag handler.


Outstanding issues:
- Make tag handler pool capacity configurable.
- Optimize tag reuse in the body of iteration tags.


Thanks,


Jan


Executing ssh-askpass to query the password...
Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on 
the server side.
cvs server: Diffing src
cvs server: Diffing src/bin
cvs server: Diffing src/share
cvs server: Diffing src/share/org
cvs server: Diffing src/share/org/apache
cvs server: Diffing src/share/org/apache/jasper
cvs server: Diffing src/share/org/apache/jasper/compiler
Index: src/share/org/apache/jasper/compiler/Generator.java
===
RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.17
diff -u -r1.17 Generator.java
--- src/share/org/apache/jasper/compiler/Generator.java 5 Jun 2002 22:01:33 -  
 1.17
+++ src/share/org/apache/jasper/compiler/Generator.java 6 Jun 2002 19:12:37 -
@@ -96,6 +96,7 @@
 private boolean breakAtLF;
 private PageInfo pageInfo;
 private int maxTagNesting;
+private Vector tagHandlerPoolNames;
 
 /**
  * @param s the input string
@@ -158,6 +159,58 @@
 }
 
 /**
+ * Compiles list of tag handler pool names.
+ */
+private void compileTagHandlerPoolList(Node.Nodes page)
+   throws JasperException {
+
+   class TagHandlerPoolVisitor extends Node.Visitor {
+
+   private Vector names;
+
+   /*
+* Constructor
+*
+* @param v Vector of tag handler pool names to populate
+*/
+   TagHandlerPoolVisitor(Vector v) {
+   names = v;
+   }
+
+   /*
+* Gets the name of the tag handler pool for the given custom tag
+* and adds it to the list of tag handler pool names unless it is
+* already contained in it.
+*/
+   public void visit(Node.CustomTag n) throws JasperException {
+   String name = n.getTagHandlerPoolName();
+   if (!names.contains(name)) {
+   names.add(name);
+   }
+   visitBody(n);
+   }
+   }
+
+   page.visit(new TagHandlerPoolVisitor(tagHandlerPoolNames));
+}
+
+/**
+ * Generates the destroy() method which is responsible for calling the
+ * release() method on every tag handler in any of the tag handler pools.
+ */
+private void generateDestroy() {
+   out.printil("public void jspDestroy() {");
+   out.pushIndent();
+   for (int i=0; i= 0)
-   prefix = replace(prefix, '-', "$1");
+   prefix = JspUtil.replace(prefix, '-', "$1");
if (prefix.indexOf('.') >= 0)
-   prefix = replace(prefix, '.', "$2");
+   prefix = JspUtil.replace(prefix, '.', "$2");
 
if (shortName.indexOf('-') >= 0)
-   shortName = replace(shortName, '-', "$1");
+   shortName = JspUtil.replace(shortName, '-', "$1");
if (shortName.indexOf('.') >= 0)
-   shortName = replace(shortName, '.', "$2");
+   shortName = JspUtil.replace(shortName, '.', "$2");
if (shortName.indexOf(':') >= 0)
-   shortName = replace(shortName, ':', "$3");
+   shortName = JspUtil.replace(shortName, ':', "$3");
 
synchronized (tagVarNumbers) {
String varName = 

[Patch] tiny past-o in jasper2 Constants.java javadoc

[Ian Darwin]

--- jasper2/src/share/org/apache/jasper/Constants.java.orig Fri Jun  7 13:42:00 
2002
+++ jasper2/src/share/org/apache/jasper/Constants.java  Fri Jun  7 13:42:11 2002
@@ -118,7 +118,7 @@
 
 /**
  * FIXME
- * ServletContext attribute for classpath. This is tomcat specific. 
+ * ServletContext attribute for class loader. This is tomcat specific. 
  * Other servlet engines can choose to have this attribute if they 
  * want to have this JSP engine running on them. 
  */

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

Re: 4.1.3b1 zip lib crash

[bob]

Yea, take a look at 9204,  Seems like IBM's version of ZipFile
is asked to load "/classes" and throws an exception, while Sun's
implementation doesnt throw an exception.

> OK, I gave the IBM jdk a shot, and it crashes on me as well. Interesting 
> that it also happens related to opening a zip:
> 
>  "main" (TID:0x100519D8, sys_thread_t:0x8059108, state:R, native 
> ID:0x400) prio=5
>  at java.util.zip.ZipFile.open(Native Method)
>  at java.util.zip.ZipFile.(ZipFile.java:127)
>  at java.util.jar.JarFile.(JarFile.java:138)
>  at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:62)
>  at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:45)
>  at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:166)
>  at java.security.AccessController.doPrivileged(Native Method)
> 

Cheers,
-bob

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

Re: 4.1.3b1 zip lib crash

[Nick Wesselman]

OK, I gave the IBM jdk a shot, and it crashes on me as well. Interesting 
that it also happens related to opening a zip:

 "main" (TID:0x100519D8, sys_thread_t:0x8059108, state:R, native 
ID:0x400) prio=5
 at java.util.zip.ZipFile.open(Native Method)
 at java.util.zip.ZipFile.(ZipFile.java:127)
 at java.util.jar.JarFile.(JarFile.java:138)
 at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:62)
 at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:45)
 at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:166)
 at java.security.AccessController.doPrivileged(Native Method)
 at 
sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:152)
 at 
sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:57)
 at 
sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:65)
 at 
sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:108)
 at 
sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:
92)
 at 
org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:894)
 at 
org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:856)
 at 
org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647)
 at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:
243)
 at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:166)
 at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3445)
 at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:
821)
 at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
 at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579)
 at 
org.apache.catalina.core.StandardHostDeployer.install
(StandardHostDeployer.java:257)
 at 
org.apache.catalina.core.StandardHost.install(StandardHost.java:774)
 at 
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:569)
 at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:411)
 at 
org.apache.catalina.startup.HostConfig.start(HostConfig.java:882)
 at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:368)
 at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:166)
 at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1198)
 at 
org.apache.catalina.core.StandardHost.start(StandardHost.java:740)
 at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1190)
 at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
 at 
org.apache.catalina.core.StandardService.start(StandardService.java:499)
 at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:2186)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:510)
 at 
org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
 at 
org.apache.catalina.startup.Catalina.process(Catalina.java:180)
 at java.lang.reflect.Method.invoke(Native Method)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)

Full "javacore" follows.

Nick

--
Fri Jun  7 13:09:03 2002
SIGBUS received at 0x(nil) in unknown. Processing terminated.
J2RE 1.3.1 IBM build cxia32131-20020410
Operating Environment
-
Host: odyssey.digivis.com.(none)
OS Level: 2.4.2-2.#1 Sun Apr 8 20:41:30 EDT 2001
glibc Version   : 2.2.2
No. of Procs: 1
Memory Info:
 total:used:free:  shared: buffers:  cached:
Mem:  261595136 62472192 1991229440  3072000 31584256
Swap: 2714255360 271425536
MemTotal:   255464 kB
MemFree:194456 kB
MemShared:   0 kB
Buffers:  3000 kB
Cached:  30844 kB
Active:  31880 kB
Inact_dirty:  1964 kB
Inact_clean: 0 kB
Inact_target:  924 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   255464 kB
LowFree:194456 kB
SwapTotal:  265064 kB
SwapFree:   265064 kB
User Limits (in bytes except for NOFILE and NPROC) -
 RLIMIT_FSIZE: infinity
 RLIMIT_DATA : infinity
 RLIMIT_STACK: 8388608
 RLIMIT_CORE : 102400
 RLIMIT_NOFILE   : 1024
 RLIMIT_NPROC: 8188
Application Environment
---
Signal Handlers -
 SIGHUP  : intrDispatchMD (libhpi.so)
 SIGINT  : intrDispatchMD (libhpi.so)
 SIGQUIT : intrDispatchMD (libhpi.so)
 SIGILL  : intrDispatchMD (libhpi.so)
 SIGTRAP : intrDispatchMD (libhpi.so)
 SIGABRT : intrDispatchMD (libhpi.so)
 SIGFPE  : intrDispatchMD (l

RE: mod_jk 4.03 deadlock

[costinm]

Ok, I checked in a fix.

Let me know if it helps.

Costin

On 7 Jun 2002, Jean-Francois Nadeau wrote:

> Hi.
> 
> I found something very interesting this morning in catalina.out file.
> Here it is:
> 
> java.lang.IllegalStateException: Current state = FLUSHED, new state =
> CODING_END
> at
> java.nio.charset.CharsetEncoder.throwIllegalStateException(CharsetEncoder.java:933)
> at
> java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529)
> at
> sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar(StreamEncoder.java:356)
> at
> sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413)
> at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158)
> at java.io.OutputStreamWriter.close(OutputStreamWriter.java:222)
> at java.io.PrintWriter.close(PrintWriter.java:137)
> at
> org.apache.catalina.connector.ResponseBase.finishResponse(ResponseBase.java:482)
> at
> 
>org.apache.catalina.connector.HttpResponseBase.finishResponse(HttpResponseBase.java:236)
> at
> org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Response.java:190)
> at
> org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:435)
> at
> org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:495)
> at java.lang.Thread.run(Thread.java:536)
> 
> I looked at the AJP13 code (connectors, branch 4.02) in Tomcat CVS and I
> found that there is no finally block to close socket connections in case
> of failure... Because IllegalStateException is an unchecked exception, I
> run out of file descriptors after a short amount of time. Also, because
> mod_jk doesn't get the END, Apache deadlocks without my select patch 
> 
> I use JDK 1.4. It seems to be a NIO bug...
> 
> Do you have any idea how to fix that?
> 
> Thanks,
> 
> jeff
> 
> On Fri, 2002-06-07 at 04:30, GOMEZ Henri wrote:
> > >The real issue is why tomcat doesn't send the data. Could you try 
> > >with tomcat4.1 ( or the new coyote-based ajp connector ) ? Is it 
> > >really a deadlock ( tomcat and mod_jk both waiting for input,
> > >i.e. locked in read ) ? Or it is that tomcat for some reasons
> > >doesn't send the 'END' message ? 
> > 
> > Hum, it recall me some problems which may have been solved in post
> > 4.0.3 or in recent jtc (related to thread problem)
> >  
> > >Of course, there is the issue of detecting timeouts - but that's
> > >extremely tricky, as some requests may take a long time to process,
> > >and waiting 3 seconds ( or any other timeout ) is not a good solution. 
> > >It is the java side who should send the END message when the
> > >requests ends.
> > 
> > Hum, I never liked too much the select, at least on Unix boxes
> > a good blocking read make OS wake up your task/thread as soon as
> > there is something to do.
> >  
> > >Can you try more debugging, also on the java side ? Maybe the
> > >etherreal AJP pluging can help :-) 
> > >
> > >BTW, even if you solved the deadlock you may run into other problems,
> > >as requests longer than 3 secs will fail.
> > 
> > Yep, select is not the solution.
> > 
> > You could :
> > 
> > Keep tomcat 4.0.3 and add debugging code
> > Use tomcat 4.0.4b2
> > Or better switch to tomcat 4.1.3
> > 
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


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

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java Ajp13Response.java

[costin]

costin  2002/06/07 11:54:22

  Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java
Ajp13Response.java
  Log:
  Possible workaround/fix for the deadlock reported by Jean-Francois Nadeau.
  
  It seems on JDK1.4 some strange nio error happens. Can't reproduce it,
  but I'll trust his stacktrace :-)
  
  Revision  ChangesPath
  1.9   +5 -5  
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java
  
  Index: Ajp13Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- Ajp13Processor.java   20 Feb 2002 16:12:42 -  1.8
  +++ Ajp13Processor.java   7 Jun 2002 18:54:21 -   1.9
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java,v
 1.8 2002/02/20 16:12:42 seguin Exp $
  - * $Revision: 1.8 $
  - * $Date: 2002/02/20 16:12:42 $
  + * $Header: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java,v
 1.9 2002/06/07 18:54:21 costin Exp $
  + * $Revision: 1.9 $
  + * $Date: 2002/06/07 18:54:21 $
*
* 
*
  @@ -102,7 +102,7 @@
   
   /**
* @author Kevin Seguin
  - * @version $Revision: 1.8 $ $Date: 2002/02/20 16:12:42 $
  + * @version $Revision: 1.9 $ $Date: 2002/06/07 18:54:21 $
*/
   
   final class Ajp13Processor
  @@ -468,7 +468,7 @@
   logger.log("finished handling request.");
   }
   
  -} catch (Exception e) {
  +} catch (Throwable e) {
   logger.log("process: invoke", e);
   }
   
  
  
  
  1.4   +5 -1  
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Response.java
  
  Index: Ajp13Response.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Response.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Ajp13Response.java17 May 2001 23:55:33 -  1.3
  +++ Ajp13Response.java7 Jun 2002 18:54:22 -   1.4
  @@ -187,7 +187,11 @@
   
   public void finishResponse() throws IOException {
if(!this.finished) {
  - super.finishResponse();
  +try {
  +super.finishResponse();
  +} catch( Throwable t ) {
  +t.printStackTrace();
  +}
   this.finished = true; // Avoid END_OF_RESPONSE sent 2 times
ajp13.finish();
}
  
  
  

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

Re: Tomcat 4.0 nightly build binary downloads broken?

[Craig R. McClanahan]

On Fri, 7 Jun 2002, Remy Maucherat wrote:

> Date: Fri, 7 Jun 2002 10:24:00 -0700
> From: Remy Maucherat <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Jonathan Eric Miller <[EMAIL PROTECTED]>
> Subject: Re: Tomcat 4.0 nightly build binary downloads broken?
>
> > I found that it looks like the nightly binary builds are broken. As you
> can
> > see, for some reason the many of the file sizes are only 45 bytes. Also,
> the
> > .zip file builds are missing.
> >
> > http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/
>
> The switch to Jasper 2 probably killed it (but it was really bad to keep
> Jasper 1 in there). Craig could fix it when he has some time, or we could
> decide it's (finally) time to switch to Gump.
>

+1 (for Gump-built nightly builds).

It wasn't Jasper2 that killed it ... it was the switch to Ant 1.5b2.  I'll
try to get that working again on my box over the weekend, but it would be
better to migrate the standard nightly build process somewhere else.

Just let me know and I'll remove it from my nightly cron job.

> Remy
>

Craig


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

cvs commit: jakarta-tomcat-4.0/webapps/ROOT index.jsp

[remm]

remm2002/06/07 10:50:14

  Modified:webapps/ROOT index.jsp
  Log:
  - Add links.
  - Decrease a bit the emphasis on the example web applications.
  
  Revision  ChangesPath
  1.4   +27 -9 jakarta-tomcat-4.0/webapps/ROOT/index.jsp
  
  Index: index.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/ROOT/index.jsp,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- index.jsp 30 Apr 2002 22:17:49 -  1.3
  +++ index.jsp 7 Jun 2002 17:50:14 -   1.4
  @@ -60,14 +60,12 @@
   
   
   
  -Web 
Applications  
  +Administration  
   
   
   
   
  -JSP Examples
  -Servlet Examples
  -WebDAV capabilities
  +Tomcat Administration
    
   
   
  @@ -76,12 +74,12 @@
   
   
   
  -Administration  
  +Documentation  
   
   
   
   
  -Tomcat Administration
  +Tomcat Documentation
    
   
   
  @@ -90,12 +88,32 @@
   
   
   
  -Documentation  
  +Tomcat 
Online  
   
   
   
   
  -Tomcat Documentation
  +http://jakarta.apache.org/tomcat/";>Home 
Page
  +http://jakarta.apache.org/tomcat/bugreport.html";>Bug Database
  +http://www.mail-archive.com/tomcat-user%40jakarta.apache.org/";>Users Mailing 
List
  +http://www.mail-archive.com/tomcat-dev%40jakarta.apache.org/";>Developers Mailing 
List
  +IRC
  + 
  +
  +
  +
  +
  +
  +
  +
  +Examples  
  +
  +
  +
  +
  +JSP Examples
  +Servlet Examples
  +WebDAV capabilities
    
   
   
  @@ -151,7 +169,7 @@
   
   
    
  -Copyright © 1999-2001 Apache Software 
Foundation
  +Copyright © 1999-2002 Apache Software 
Foundation
   All Rights Reserved 
    
    
  
  
  

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

Re: Required jar/rpms to build tomcat 4.1.3b1

[Bill Barker]

- Original Message -
From: "GOMEZ Henri" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, June 07, 2002 7:39 AM
Subject: RE: Required jar/rpms to build tomcat 4.1.3b1


>> PureTLS ? Not yet in TC 4.x ...
>
>4.1 uses coyote which uses tomcat-utils, which works fine with
>pureTLS.
>I assume it's just undocumented, I don't see a code
>problem ( with the coyote connector ).
>

>Hum, JSSE is still required in part of the code, outside HTTP
>connector world.

>org.apache.catalina.net.SSLServerSocketFactory require JSSE.

>JCERT is needed by org.apache.catalina.valves.CertificatesValve.


I had thought that PureTLS was working on 4.1, but I haven't had a chance to
try it.  IFAIK, SSLServerSocketFactory isn't used, and CertificatesValve
doens't do anything useful.


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



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

Re: Tomcat 4.0 nightly build binary downloads broken?

[Remy Maucherat]

> I found that it looks like the nightly binary builds are broken. As you
can
> see, for some reason the many of the file sizes are only 45 bytes. Also,
the
> .zip file builds are missing.
>
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/

The switch to Jasper 2 probably killed it (but it was really bad to keep
Jasper 1 in there). Craig could fix it when he has some time, or we could
decide it's (finally) time to switch to Gump.

Remy


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

Re: problem in nested custom tags- Jboss3.0-tomcat4.03.

[Kin-Man Chung]

Looks like the same problem as one decribed in bugzilla #9699 that
got reported today.  Good timing!  :-)

> Date: Fri, 07 Jun 2002 15:42:54 +0530
> From: Anil Agrawal <[EMAIL PROTECTED]>
> Subject: problem in nested custom tags- Jboss3.0-tomcat4.03.
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> MIME-version: 1.0
> Delivered-to: mailing list [EMAIL PROTECTED]
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> X-Antivirus: nagoya (v4198 created Apr 24 2002)
> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
> List-Post: 
> List-Subscribe: 
> List-Unsubscribe: 
> List-Help: 
> List-Id: "Tomcat Developers List" 
> 
> respected sir,
> 
>   I am working on Jboss3.0-tomcat4.03.
> 
>   following jsp (uses nested custom tags) working perfactly fine
>   with weblogic6.01.
> 
>   jsp code is logically right also. at compilation time tomcat throws
> exception
> 
> 
> ==
> jsp compilation error
> =
> 
> D:\jboss-3.0.0_tomcat-4.0.3\catalina\work\localhost\wsc_auth\auth\admin\Assi
> gnDeassignService$jsp.java:350: Variable 'inputError' is already defined in
> this method.
>   String inputError = null;
> 
> ==
> jsp file
> =
> 
>   serviceName='<%=sName%>' >   
>   
>   <%=inputError%>
>  
>  
> 
>   <%=businessError%>
> 
> 
>
> 
> 
> 
> <%=inputError%>
>
>  
>   
>   <%=businessError%>
>   
>
> 
>   
>   
> 
>  
>   
>  
> 
>   
>   
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


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

Re: TC 4.1.3 jasper error

[Kin-Man Chung]

I already committed a fix for this problem a couple of days ago.

The problem is of course private instance variables are beening referenced
in a child class.  The 1.3 javac does not flag this as an error, and
1.4 javac gives misleading error messages!

> Date: Fri, 07 Jun 2002 11:32:02 -0400 (EDT)
> From: [EMAIL PROTECTED]
> Subject: Re: TC 4.1.3 jasper error
> To: [EMAIL PROTECTED]
> MIME-version: 1.0
> Content-transfer-encoding: 7bit
> Delivered-to: mailing list [EMAIL PROTECTED]
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> X-Antivirus: nagoya (v4198 created Apr 24 2002)
> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
> List-Post: 
> List-Subscribe: 
> List-Unsubscribe: 
> List-Help: 
> List-Id: "Tomcat Developers List" 
> 
> > 
> > My Eclipse IDE (with Sun JDK 1.3.1_03) give me the following error 
> > for Node.java
> 
> I had a hard time compiling Node.java in jasper2 until I made this
> change (which I believe doenst change the logic at all)
> 
> Index: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
> ===
> RCS file: 
/home/cvspublic/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compil
er/Node.java,v
> retrieving revision 1.9
> diff -u -r1.9 Node.java
> --- 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java 
 23 May 2002 21:29:38 -   1.9
> +++ 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java 
 7 Jun 2002 15:26:43 -
> @@ -370,13 +370,13 @@
>  * @return The text string
>  */
> public char[] getText() {
> -   char[] ret = text;
> -   if ((ret == null) && (body != null)) {
> +   char[] ret = super.getText();
> +   if ((ret == null) && (getBody() != null)) {
> CharArrayWriter chars = new CharArrayWriter();
> -   int size = body.size();
> +   int size = getBody().size();
> for (int i=0; i -   chars.write(body.getNode(i).getText(), 0,
> -   body.getNode(i).getText().length);
> +   chars.write(getBody().getNode(i).getText(), 0,
> +   getBody().getNode(i).getText().length);
> }
> ret = chars.toCharArray();
> }
> 
> 
> Cheers,
> -bob
> 
> 
> > in :
> > 
> > /**
> >  * When this node was created from a JSP page in JSP syntax, its text
> >  * was stored as a String in the "text" field, whereas when this node
> >  * was created from a JSP document, its text was stored as one or more
> >  * TemplateText nodes in its body. This method handles either case.
> >  * @return The text string
> >  */
> > public char[] getText() {
> > char[] ret = text;
> > if ((ret == null) && (body != null)) {
> > CharArrayWriter chars = new CharArrayWriter();
> > int size = body.size();
> > for (int i=0; i > chars.write(body.getNode(i).getText(), 0,
> > body.getNode(i).getText().length);
> > }
> > ret = chars.toCharArray();
> > }
> > return ret;
> > }
> > }
> > 
> > jakarta-tomcat-4.1.3-b1/org/apache/jasper/compiler/Node.java
> > 
> > Cannot make a static reference to the non-static field text
> > 
> > line 373 in Node.ScriptingElement.getText()
> > line 374 in Node.ScriptingElement.getText()
> > line 376 in Node.ScriptingElement.getText()
> > line 378 in Node.ScriptingElement.getText()
> > line 379 in Node.ScriptingElement.getText()
> > 
> > Did someone else get this error ?
> > 
> > 
> > -
> > Henri Gomez ___[_]
> > EMAIL : [EMAIL PROTECTED](. .) 
> > PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> > PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
> > 
> > 
> > 
> > >-Original Message-
> > >From: Jean-Francois Nadeau [mailto:[EMAIL PROTECTED]]
> > >Sent: Friday, June 07, 2002 3:41 PM
> > >To: Tomcat Developers List
> > >Subject: RE: mod_jk 4.03 deadlock
> > >
> > >
> > >Hi.
> > >
> > >I found something very interesting this morning in catalina.out file.
> > >Here it is:
> > >
> > >java.lang.IllegalStateException: Current state = FLUSHED, new state =
> > >CODING_END
> > >at
> > >java.nio.charset.CharsetEncoder.throwIllegalStateException(Char
> > >setEncoder.java:933)
> > >at
> > >java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529)
> > >at
> > >sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar(StreamEnco
> > >der.java:356)
> > >at
> > >sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413)
> > >at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158)
> > >at 
> > >java.io.OutputStreamW

DO NOT REPLY [Bug 6884] - Need Better Error Handling in WebappClassLoader.validateJarFile

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

Need Better Error Handling in WebappClassLoader.validateJarFile





--- Additional Comments From [EMAIL PROTECTED]  2002-06-07 16:45 ---

I checked 4.1.3 and it also has this issue. The patch at the bottom adds
logging.  Although looking at the class, I am concerned that
WebappClassLoader.java only checks for one class "javax.servlet.Servlet.class"

Perahaps it would be wiser to loop through the jar's contents and reject it
if anything startsWith("javax/servlet/") ?


Index:
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.39
diff -u -r1.39 WebappClassLoader.java
---
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java

22 May 2002 23:35:52 -   1.39
+++
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java

7 Jun 2002 16:35:48 -
@@ -1994,6 +1994,7 @@
 log(" Checking for " + name);
 JarEntry jarEntry = jarFile.getJarEntry(name);
 if (jarEntry != null) {
+log("validateJarFile("+jarfile+") - jar not loaded. See Servlet
Spec 2.3, section 9.7.2. Offending class: " + name);
 jarFile.close();
 return (false);
 }

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

Re: Required jar/rpms to build tomcat 4.1.3b1

[Eric Rescorla]

"Craig R. McClanahan" <[EMAIL PROTECTED]> writes:
> CertificatesValve is used to fulfill the Servlet API requirement that the
> certificate chain supplied by the client is exposed as a request attribute
> (also the cipher suite and key size in Servlet 2.3).  Currently, it's hard
> coded to JSSE (including having to perform the type conversion from
> javax.security.cert.X509Certificate (supplied by JSSE) to
> java.security.cert.X509Certificate (requird by the Servlet API).
>
> For PureTLS, we'd need to provide these request attributes via some other
> mechanism -- perhaps by plugging in a PureTLS-specific version of this
> class, or by making this class smart enough to use introspection for
> whichever type of SSL support is available.

Craig,

When we're using Coyote, these attributes are set in
HttpProcessor.action(ACTION_REQ_SSL_ATTRIBUTE). 

This code calls the sslSupport class which automatically translates
from the underlying implementation to a vector j.s.c.X509Certificate.
The actual translators live in o.a.t.u.net.{JSSE,PureTLS}Support.

-Ekr

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

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

DO NOT REPLY [Bug 9700] New: - JNDIRealm authentication incorrectly succeeds with blank password

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

JNDIRealm authentication incorrectly succeeds with blank password

   Summary: JNDIRealm authentication incorrectly succeeds with blank
password
   Product: Tomcat 4
   Version: 4.1.3
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I found that if you configure Tomcat to use JNDIRealm in the configuration 
where it binds as the remote user to the LDAP server (i.e. if you leave the 
userPassword attribute blank as described under bullet point 4 in the 
JNDIRealm documentation in the Catalina documentation), that it allows users 
to authenticate successfully with a blank password.

I think this is because LDAP considers authentication with a valid DN and a 
blank password an anonymous authentication. i.e. authentication doesn't fail, 
it just logs you in anonymously instead.

So, I'm thinking that JNDIRealm should probably check to make sure that 
password isn't blank and if it is a blank password, it should fail.

I'm using the following configuration in my server.xml.

ldap://myldapserver";
roleBase="ou=roles, dc=mydomain"
roleName="cn"
roleSearch="(uniqueMember={0})"
roleSubtree="false"
userPattern="uid={0}, ou=People, dc=mydomain"/>

I've tested this with OpenLDAP and iPlanet Directory Server and the behavior 
is the same.

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

Re: Required jar/rpms to build tomcat 4.1.3b1

[costinm]

On 7 Jun 2002, Eric Rescorla wrote:
> > org.apache.catalina.net.SSLServerSocketFactory require JSSE.
> >
> > JCERT is needed by org.apache.catalina.valves.CertificatesValve.
> Well, Ant is smart enough to not try to build these if you
> don't have JSSE. I'm still not completely clear on the circumstances
> in which these classes would get used. 
> 
> In any case, the future we're moving toward will be all Coyote
> in which case you won't need these classes at all. Is that your
> understanding as well?

I certainly hope so. Whatever those classes are doing, they'll fail
when used with a apache ( or other web server ) - since JSSE is 
not involved.

Costin


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

Re: Required jar/rpms to build tomcat 4.1.3b1

[costinm]

On Fri, 7 Jun 2002, Remy Maucherat wrote:

> > So the required packages are :
> >
> > ant 1.4.1
> > xerces 2.0.1
> > xalan 2.3.1
> 
> Xalan is not required (yet).

It was discussed on ant-dev, I believe it is required by the 
JAXP licence. If you could check ( in case you know someone working
at Sun :-), it would be great. 
( i.e. if it is possible to distribute a partial implementation
of a JCP spec - like JAXP without xslt - or servlet without jsp :-).

BTW, the licence on JMX_RI_1.1 seems slightly different from 
the previous, it may ( or not ) be distributable. Any lawyer 
wanting to become commiter on tomcat ? 
( of course, using an open source product is better, but
again the terms on MX4J are still unclear wrt JCP test 
requirements - which in a distant future will be resolved,
but not in this present ) 


Costin


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

Re: Required jar/rpms to build tomcat 4.1.3b1

[Eric Rescorla]

"GOMEZ Henri" <[EMAIL PROTECTED]> writes:

> >> Hum, JSSE is still required in part of the code, outside HTTP 
> >> connector world.
> >>
> >> org.apache.catalina.net.SSLServerSocketFactory require JSSE.
> >>
> >> JCERT is needed by org.apache.catalina.valves.CertificatesValve.
> >Well, Ant is smart enough to not try to build these if you
> >don't have JSSE. I'm still not completely clear on the circumstances
> >in which these classes would get used. 
> >
> >In any case, the future we're moving toward will be all Coyote
> >in which case you won't need these classes at all. Is that your
> >understanding as well?
> 
> Yes, I hope we could in fine use the OSS's PureTLS/Cryptix 
> instead of  JSSE for all cert/net/ssl, instead of JSSE, 
> even if this one is present in JDK 1.4.
> 
> But in the interim, we'll have to use the same mecanism that
> the one present in TC 3.3.1, ie auto detection of present
> API (JSSE/PURETLS) and use of the corresponding factories
It seems to me that there are three issues:

(1) What's the status of the current direct JSSE-using code in Catalina?
As far as I can tell, the current direct JSSE-using code in Catalina
(i.e. o.a.c.valves.CertificateValce and o.a.c.net.SSLServerSocketFactory)
is completely superseded by the switch-hitting code in Coyote. Are
there some circumstances under which these classes will be required
at all? If not, let's remove them.

(2) Does PureTLS work with 4.1.3b1? 
Prior to my checkin on May 28, the switch-hitting support in Coyote
didn't work properly with PureTLS. The right stuff is in the tree,
so this is presumably just a version skew problem.

(3) What SSL implementation should Tomcat use?
The current code in Coyote switch-hits between JSSE and PureTLS
depending on what's there. This has the advantage that people
who want to use JSSE can. It has the disadvantage that JSSE
and PureTLS are not direct substitutes from a configuration
perspective (they take different keying material and slightly
different configuration flags) so this is a support problem.

It sounds like you're suggesting that in some future release we
should simply use PureTLS rather than switch-hitting. Is that
what you meant?

-Ekr


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

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

Re: Required jar/rpms to build tomcat 4.1.3b1

[Craig R. McClanahan]

On 7 Jun 2002, Eric Rescorla wrote:

> Date: 07 Jun 2002 08:47:23 -0700
> From: Eric Rescorla <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>,
>  EKR <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: Required jar/rpms to build tomcat 4.1.3b1
>
> "GOMEZ Henri" <[EMAIL PROTECTED]> writes:
>
> > >> PureTLS ? Not yet in TC 4.x ...
> > >
> > >4.1 uses coyote which uses tomcat-utils, which works fine with
> > >pureTLS.
> > >I assume it's just undocumented, I don't see a code
> > >problem ( with the coyote connector ).
> > >
> >
> > Hum, JSSE is still required in part of the code, outside HTTP
> > connector world.
> >
> > org.apache.catalina.net.SSLServerSocketFactory require JSSE.
> >
> > JCERT is needed by org.apache.catalina.valves.CertificatesValve.

> Well, Ant is smart enough to not try to build these if you
> don't have JSSE. I'm still not completely clear on the circumstances
> in which these classes would get used.
>

CertificatesValve is used to fulfill the Servlet API requirement that the
certificate chain supplied by the client is exposed as a request attribute
(also the cipher suite and key size in Servlet 2.3).  Currently, it's hard
coded to JSSE (including having to perform the type conversion from
javax.security.cert.X509Certificate (supplied by JSSE) to
java.security.cert.X509Certificate (requird by the Servlet API).

For PureTLS, we'd need to provide these request attributes via some other
mechanism -- perhaps by plugging in a PureTLS-specific version of this
class, or by making this class smart enough to use introspection for
whichever type of SSL support is available.

> In any case, the future we're moving toward will be all Coyote
> in which case you won't need these classes at all. Is that your
> understanding as well?
>
> -Ekr
>
> --
> [Eric Rescorla   [EMAIL PROTECTED]]
> http://www.rtfm.com/
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>

Craig McClanahan



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

RE: Required jar/rpms to build tomcat 4.1.3b1

[GOMEZ Henri]

>> Hum, JSSE is still required in part of the code, outside HTTP 
>> connector world.
>>
>> org.apache.catalina.net.SSLServerSocketFactory require JSSE.
>>
>> JCERT is needed by org.apache.catalina.valves.CertificatesValve.
>Well, Ant is smart enough to not try to build these if you
>don't have JSSE. I'm still not completely clear on the circumstances
>in which these classes would get used. 
>
>In any case, the future we're moving toward will be all Coyote
>in which case you won't need these classes at all. Is that your
>understanding as well?

Yes, I hope we could in fine use the OSS's PureTLS/Cryptix 
instead of  JSSE for all cert/net/ssl, instead of JSSE, 
even if this one is present in JDK 1.4.

But in the interim, we'll have to use the same mecanism that
the one present in TC 3.3.1, ie auto detection of present
API (JSSE/PURETLS) and use of the corresponding factories


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

RE: Jsp compilation of nested custom tags (porting from weblogic 6 to tomcat 4.0.3)

[Pete Gordon]

Thanks Kin-Man.

I have filed a bug on Tomcat-Jasper component (BUG# 9699).  I was able to
duplicate the problem using the examples\foo simple tag example by just
trying to nest the tag within itself (see code below).

If you have pointers on where the generate java code might be, I might be
able to try to look at it.

Pete Gordon


foo.jsp



<%@ taglib uri="http://jakarta.apache.org/tomcat/examples-taglib";
prefix="eg"%>

Radio stations that rock:



<%= member %>

  This is the some more members.





Did you see me on the stderr window?



Did you see me on the browser window as well?







-Original Message-
From: Kin-Man Chung [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, June 06, 2002 8:40 PM
To: [EMAIL PROTECTED]
Subject: Re: Jsp compilation of nested custom tags (porting from weblogic 6
to tomcat 4.0.3)


I assume that lOffset is a scripting variable defined either in a 
element of a tld, or in a TagExtraInfo, and that its declaration (in the
generated java file) is a result of the compiler trying to do its
synchronization with the pagecontext attribute of the same name.

If so, what is the scope of this variable?  Is it NESTED or AT_BEGIN?

I can see how the current Jasper implementation can be problematic, There
are two problems here.

First, if the scope is AT_BEGIN, then the scope of the variable should
remain defined until the end of the page, and the current implementation
actually make it unavailable after the end of the tag, which is wrong.

Second, if the tags are nested, as is your case here, then redclaring it in
the nested block would be illegal Java.

Can you file a bug report in bugzilla for this?  It would help if you can
also include a small test case, so that fixes can be verified.

Thanks.


> Date: Thu, 06 Jun 2002 18:54:11 -0400
> From: Pete Gordon <[EMAIL PROTECTED]>
> Subject: Re: Jsp compilation of nested custom tags (porting from 
> weblogic 6 to
tomcat 4.0.3)
> To: Tag Libraries Developers List <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> MIME-version: 1.0 (Apple Message framework v481)
> Delivered-to: mailing list [EMAIL PROTECTED]
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> X-Antivirus: nagoya (v4198 created Apr 24 2002)
> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
> List-Post: 
> List-Subscribe: 
> List-Unsubscribe: 
> List-Help: 
> List-Id: "Tomcat Developers List" 
> 
> Thanks, Shawn.
> 
> Let me summarize for the tomcat-dev list.  I have an existing
> application with custom tags that runs on weblogic 6, when porting it 
> over to Tomcat I now am running into an error where the generated java 
> from a jsp with self nested tags will not compile, the code generated 
> from jspc simulates the HelloWorld sample below, which is not valid java
> 
> code--it would be valid in C, but that's another story.
> 
> The first htmlGlobalAttribSearch$jsp.java compile error is line 198,
> variable lOffset is already defined.  There are several (19) more errors
> 
> like this that are also outputed from trying to compile the $jsp.java
> file that I have attached.
> 
> public class HelloWorld{
>   public static void main(String args[]){
>   do{
>   int i = 5;
>   do{
>   int i=10;
>   }while(false);
>   }while(false);
>   }
> }
> 
> Tomorrow, I will try to create a minimal nested tag example and see if 
> I
> 
> can duplicate the problem.  Unless someone is aware of this problem
> already, and can save me the effort.
> 
> Thanks,
> Pete Gordon
> 
> 
> 
> On Thursday, June 6, 2002, at 03:03 PM, Shawn Bayern wrote:
> 
> > Hi Pete,
> >
> > If this is a Tomcat bug, it would be better to mail tomcat-dev about
> it
> > or
> > to submit a Tomcat bug report in Apache's Bugzilla 
> > (http://nagoya.apache.org/bugzilla).  I'd be happy to take a look at
> it
> > myself, but it's difficult to identify the problem in a large 
> > compiled servlet.  (I can't attempt to compile it myself since it 
> > depends on
> some
> > custom classes not included.)  If you could post the compilation
> error,
> > that'd definitely help us determine whether it looks like a Tomcat 
> > bug
> 
> > or
> > not.
> 
> 
> 
> From: Pete Gordon <[EMAIL PROTECTED]>
> Date: Thu Jun 06, 2002  02:32:06 PM US/Eastern
> To: 'Tag Libraries Developers List' <[EMAIL PROTECTED]>
> Subject: Jsp compilation of nested custom tags (porting from weblogic 
> 6
> to tomcat 4.0.3)
> Reply-To: "Tag Libraries Developers List"  [EMAIL PROTECTED]>
> 
> There is a problem with compiling the genenerated java code
> (htmlGlobalAttribSearch$jsp.java) it tells me that variables have 
> already been defined.  I have compiled the source file and even 
> created a test HelloWorld.java to test it.  It is correct variables 
> have already been defined, which we found strange as far

RE: Required jar/rpms to build tomcat 4.1.3b1

[GOMEZ Henri]

>
>I would include all of these.
>
>What's up with the daemon component BTW ?

I could find a tarball but JF make a snap.

Thanks for the reply, I know what I should
get and what I could drop.

BTW, I'll build with a SDK 1.3.1 for probably
SDK 1.2/1.3 (the more common today on Linux world)

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

Re: Required jar/rpms to build tomcat 4.1.3b1

[Eric Rescorla]

"GOMEZ Henri" <[EMAIL PROTECTED]> writes:

> >> PureTLS ? Not yet in TC 4.x ...
> >
> >4.1 uses coyote which uses tomcat-utils, which works fine with 
> >pureTLS. 
> >I assume it's just undocumented, I don't see a code 
> >problem ( with the coyote connector ).
> >
> 
> Hum, JSSE is still required in part of the code, outside HTTP 
> connector world.
>
> org.apache.catalina.net.SSLServerSocketFactory require JSSE.
>
> JCERT is needed by org.apache.catalina.valves.CertificatesValve.
Well, Ant is smart enough to not try to build these if you
don't have JSSE. I'm still not completely clear on the circumstances
in which these classes would get used. 

In any case, the future we're moving toward will be all Coyote
in which case you won't need these classes at all. Is that your
understanding as well?

-Ekr

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

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

DO NOT REPLY [Bug 9699] New: - jsp tags nested within themselves do not generate valid java code

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

jsp tags nested within themselves do not generate valid java code

   Summary: jsp tags nested within themselves do not generate valid
java code
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I confirmed this by modifying the simple test tag foo.jsp to nest this foo tag 
within the one provided on line 12 of foo.jsp.

This is the body of the nested foo tag.


This creates the foo$jsp.java file that will not compile.   The generated 
code looks like this...
do{
  String member = null;//line:79 in foo$jsp.java
do{
 String member = null;//line:111 in foo$jsp.java
 } while (false)

} while (false)

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

Re: 4.1.3b1 zip lib crash

[Remy Maucherat]

> True enough, VM bug, but we use this JVM w/ 4.0.1 and 4.0.3 in
> production no problem. I won't argue with you about it though--I'm not a
> TC developer :-)

It's not the same crash we're used to see (if I remember well, it usually is
a crash on startup parsing XML with 4.0.x, but it may also crash later
randomly), but those JDKs are not stable with recent kernels unless you use
the workarounds described in the release notes.

Remy


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

problem in nested custom tags- Jboss3.0-tomcat4.03.

[Anil Agrawal]

respected sir,

  I am working on Jboss3.0-tomcat4.03.

  following jsp (uses nested custom tags) working perfactly fine
  with weblogic6.01.

  jsp code is logically right also. at compilation time tomcat throws
exception


==
jsp compilation error
=

D:\jboss-3.0.0_tomcat-4.0.3\catalina\work\localhost\wsc_auth\auth\admin\Assi
gnDeassignService$jsp.java:350: Variable 'inputError' is already defined in
this method.
  String inputError = null;

==
jsp file
=


  
  <%=inputError%>
 
 

<%=businessError%>

  
   
  

  
  <%=inputError%>
 
 

<%=businessError%>

   



  
 
  
 

  
  

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

DO NOT REPLY [Bug 9677] - JSP files not recompiled when newer

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

JSP files not recompiled when newer





--- Additional Comments From [EMAIL PROTECTED]  2002-06-07 15:35 ---
Hello Remy:

I've got a slight difference in how I am using Tomcat and how you describe it.  
I have been modifying a test JSP in another directory and then copying that 
file into the web application directory.  

When I do that, I am finding that Java source file (for the JSP file) in the 
work directory gets a date newer than the original JSP source file, though its 
contents do not change.  This perplexes me.  

Can you try this usage scenario?  I don't know how to explain how Jasper might 
get tripped on this, but I'll keep looking into it...

Thanks,
Glenn

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

Re: 4.1.3b1 zip lib crash

[Nick Wesselman]

True enough, VM bug, but we use this JVM w/ 4.0.1 and 4.0.3 in 
production no problem. I won't argue with you about it though--I'm not a 
TC developer :-)

Thanks for the quick reply.

Nick

On Friday, June 7, 2002, at 10:28 AM, Remy Maucherat wrote:

>> Greetings,
>>
>> I was trying out 4.1.3b1 and received the error below in my
>> catalina.out. Should I submit this to bugzilla?
>>
>> JVM 1.3.1_01 on RedHat 7.1 stock (2.4.2-2 kernel).
>>
>> The last line in my catalina log is
>> 2002-06-07 09:09:47 WebappLoader[]: Deploy JAR /WEB-
>> INF/lib/jce1_2-do.jar to
>> /mnt/development/NWESSELMAN/webhome/webapps/ROOT/WEB-
>> INF/lib/jce1_2-do.jar
>>
>> I hope there's a fix, I really want to check out the admin app :-)
>
> VM crash = VM bug.
>
> Do *not* use Tomcat with Linux and JDK 1.2 or 1.3. There are workarounds
> (read the release notes), but either use Sun JDK 1.4 or IBM JDK 1.3.
>
> Remy
>
>
> --
> To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> For additional commands, e-mail:  [EMAIL PROTECTED]>


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

Re: 4.1.3b1 zip lib crash

[Remy Maucherat]

> Greetings,
>
> I was trying out 4.1.3b1 and received the error below in my
> catalina.out. Should I submit this to bugzilla?
>
> JVM 1.3.1_01 on RedHat 7.1 stock (2.4.2-2 kernel).
>
> The last line in my catalina log is
> 2002-06-07 09:09:47 WebappLoader[]: Deploy JAR /WEB-
> INF/lib/jce1_2-do.jar to
> /mnt/development/NWESSELMAN/webhome/webapps/ROOT/WEB-
> INF/lib/jce1_2-do.jar
>
> I hope there's a fix, I really want to check out the admin app :-)

VM crash = VM bug.

Do *not* use Tomcat with Linux and JDK 1.2 or 1.3. There are workarounds
(read the release notes), but either use Sun JDK 1.4 or IBM JDK 1.3.

Remy


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

Re: TC 4.1.3 jasper error

[bob]

> 
> My Eclipse IDE (with Sun JDK 1.3.1_03) give me the following error 
> for Node.java

I had a hard time compiling Node.java in jasper2 until I made this
change (which I believe doenst change the logic at all)

Index: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java,v
retrieving revision 1.9
diff -u -r1.9 Node.java
--- jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java  
23 May 2002 21:29:38 -   1.9
+++ jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java  
+7 Jun 2002 15:26:43 -
@@ -370,13 +370,13 @@
 * @return The text string
 */
public char[] getText() {
-   char[] ret = text;
-   if ((ret == null) && (body != null)) {
+   char[] ret = super.getText();
+   if ((ret == null) && (getBody() != null)) {
CharArrayWriter chars = new CharArrayWriter();
-   int size = body.size();
+   int size = getBody().size();
for (int i=0; i in :
> 
>   /**
>* When this node was created from a JSP page in JSP syntax, its text
>* was stored as a String in the "text" field, whereas when this node
>* was created from a JSP document, its text was stored as one or more
>* TemplateText nodes in its body. This method handles either case.
>* @return The text string
>*/
>   public char[] getText() {
>   char[] ret = text;
>   if ((ret == null) && (body != null)) {
>   CharArrayWriter chars = new CharArrayWriter();
>   int size = body.size();
>   for (int i=0; i   chars.write(body.getNode(i).getText(), 0,
>   body.getNode(i).getText().length);
>   }
>   ret = chars.toCharArray();
>   }
>   return ret;
>   }
> }
> 
> jakarta-tomcat-4.1.3-b1/org/apache/jasper/compiler/Node.java
> 
> Cannot make a static reference to the non-static field text
> 
> line 373 in Node.ScriptingElement.getText()
> line 374 in Node.ScriptingElement.getText()
> line 376 in Node.ScriptingElement.getText()
> line 378 in Node.ScriptingElement.getText()
> line 379 in Node.ScriptingElement.getText()
> 
> Did someone else get this error ?
> 
> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .) 
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
> 
> 
> 
> >-Original Message-
> >From: Jean-Francois Nadeau [mailto:[EMAIL PROTECTED]]
> >Sent: Friday, June 07, 2002 3:41 PM
> >To: Tomcat Developers List
> >Subject: RE: mod_jk 4.03 deadlock
> >
> >
> >Hi.
> >
> >I found something very interesting this morning in catalina.out file.
> >Here it is:
> >
> >java.lang.IllegalStateException: Current state = FLUSHED, new state =
> >CODING_END
> >at
> >java.nio.charset.CharsetEncoder.throwIllegalStateException(Char
> >setEncoder.java:933)
> >at
> >java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529)
> >at
> >sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar(StreamEnco
> >der.java:356)
> >at
> >sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413)
> >at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158)
> >at 
> >java.io.OutputStreamWriter.close(OutputStreamWriter.java:222)
> >at java.io.PrintWriter.close(PrintWriter.java:137)
> >at
> >org.apache.catalina.connector.ResponseBase.finishResponse(Respo
> >nseBase.java:482)
> >at
> >org.apache.catalina.connector.HttpResponseBase.finishResponse(H
> >ttpResponseBase.java:236)
> >at
> >org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Respon
> >se.java:190)
> >at
> >org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:435)
> >at
> >org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:495)
> >at java.lang.Thread.run(Thread.java:536)
> >
> >I looked at the AJP13 code (connectors, branch 4.02) in Tomcat 
> >CVS and I
> >found that there is no finally block to close socket 
> >connections in case
> >of failure... Because IllegalStateException is an unchecked 
> >exception, I
> >run out of file descriptors after a short amount of time. Also, because
> >mod_jk doesn't get the END, Apache deadlocks without my select patch 
> >
> >I use JDK 1.4. It seems to be a NIO bug...
> >
> >Do you have any idea how to fix that?
> >
> >Thanks,
> >
> >jeff
> >
> >On Fri, 2002-06-07 at 04:30, GOMEZ Henri wrote:
> >> >The real issue is why tomcat doesn't send the data. Could you try 
> >> >with tomcat4.1 ( or the new coyote-based ajp connector ) ? Is it 
> >> >really a deadlock ( tomcat and mod_jk both wait

Re: Required jar/rpms to build tomcat 4.1.3b1

[Remy Maucherat]

> So the required packages are :
>
> ant 1.4.1
> xerces 2.0.1
> xalan 2.3.1

Xalan is not required (yet).

> These two are not required by JDK 1.3 and later
>
> jndi 1.2.1 (SUN LICENSE PROBLEM)
> ldap/jaas 1.2.3 (SUN LICENSE PROBLEM)

IMO, don't include them

> servletapi 4 (or 2.3 depends how we call it)
>
> Commons Beanutils 1.1 or greater (1.3 is the latest)
>
> Commons Collections 1.0 or greater (2.0 is the latest)
>
> Commons Digester 1.1.1 or greater (1.2 is the latest)
>
> Commons Logging (one of the latest)

I always include the latest version of these components, and didn't run into
any problems.

> regexp 1.2

> Here is a list of optional packages, but it should be
> fine to have them also to be able to build a fully complete
> tomcat 4.1.3
>
> JDBC Optional 2.0 (SUN LICENSE PROBLEM)

OPtional with JDK 1.4.

> mx4j 1.0 (avoid Sun JMX to have an OSS solution)

JMX is not really optional (the default configuration uses it).

> Java Activation Framework 1.0.1 (SUN LICENSE PROBLEM)
>
> JavaMail 1.2 or later (SUN LICENSE PROBLEM)

I wouldn't bother about these two; they are only used by JNDI object
factories.

> JSSE 1.0.2 (SUN LICENSE AND CRYPTO EXPORTS PROBLEMS)

Included in JDK 1.4; IMO, do not redistribute.

> Java Transaction API 1.0.1 or later (SUN LICENSE PROBLEM)

Only required by Tyrex; do not redistribute.

> Struts 1.0.1 or later

Required for the admin webapp; include it.

> Tyrex Data Source 1.0 or later

Do not redistribute it (replaced by commons-DBCP); interested users should
install it themselves, as it is quite somplex to configure and use anyway,
as has been proven by the amount of support questions we got for it.

> JUnit 3.7 or later

Not useful.

> Commons Modeler Binary version 20020117 or later

Required by the admin webapp.

> Commons DBCP version 20011030 or later
>
> Commons Pool version 20011030 or later
>
> Commons Daemon version 20020219 or later

I would include all of these.

What's up with the daemon component BTW ?

Remy


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

4.1.3b1 zip lib crash

[Nick Wesselman]

Greetings,

I was trying out 4.1.3b1 and received the error below in my 
catalina.out. Should I submit this to bugzilla?

JVM 1.3.1_01 on RedHat 7.1 stock (2.4.2-2 kernel).

The last line in my catalina log is
2002-06-07 09:09:47 WebappLoader[]: Deploy JAR /WEB-
INF/lib/jce1_2-do.jar to 
/mnt/development/NWESSELMAN/webhome/webapps/ROOT/WEB-
INF/lib/jce1_2-do.jar

I hope there's a fix, I really want to check out the admin app :-)

Nick Wesselman
Digital Visions, Inc.

---

Starting service Tomcat-Apache
Apache Tomcat/4.1.3

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 7 occurred at PC=0x405327a7
Function name=allocZip
Library=/usr/java/jdk1.3.1_01/jre/lib/i386/libzip.so

Current Java thread:
 at java.util.zip.ZipFile.open(Native Method)
 at java.util.zip.ZipFile.(ZipFile.java:110)
 at java.util.jar.JarFile.(JarFile.java:115)
 at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:48)
 at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:31)
 at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:152)
 at java.security.AccessController.doPrivileged(Native Method)
 at 
sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:138)
 at 
sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:43)
 at 
sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:71)
 at 
sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:88)
 at 
sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:
72)
 at 
org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:894)
 at 
org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:856)
 at 
org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647)
 at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:
243)
 at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:166)
 at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3445)
 at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:
821)
 at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
 at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579)
 at 
org.apache.catalina.core.StandardHostDeployer.install
(StandardHostDeployer.java:257)
 at 
org.apache.catalina.core.StandardHost.install(StandardHost.java:774)
 at 
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:569)
 at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:411)
 at 
org.apache.catalina.startup.HostConfig.start(HostConfig.java:882)
 at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:368)
 at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:166)
 at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1198)
 at 
org.apache.catalina.core.StandardHost.start(StandardHost.java:740)
 at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1190)
 at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
 at 
org.apache.catalina.core.StandardService.start(StandardService.java:499)
 at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:2186)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:510)
 at 
org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
 at 
org.apache.catalina.startup.Catalina.process(Catalina.java:180)
 at java.lang.reflect.Method.invoke(Native Method)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)

Dynamic libraries:
08048000-0804c000 r-xp  03:03 1161464
/usr/java/jdk1.3.1_01/bin/i386/native_threads/java
0804c000-0804d000 rw-p 3000 03:03 1161464
/usr/java/jdk1.3.1_01/bin/i386/native_threads/java
4000-40016000 r-xp  03:03 65444  /lib/ld-2.2.2.so
40016000-40017000 rw-p 00015000 03:03 65444  /lib/ld-2.2.2.so
40018000-40019000 r--p  03:03 686792 
/usr/lib/locale/en_US/LC_IDENTIFICATION
40019000-4001a000 r--p  03:03 686793 
/usr/lib/locale/en_US/LC_MEASUREMENT
4001a000-4001b000 r--p  03:03 686796 
/usr/lib/locale/en_US/LC_TELEPHONE
4001b000-4001c000 r--p  03:03 686791 
/usr/lib/locale/en_US/LC_ADDRESS
4001c000-4001d000 r--p  03:03 686794 
/usr/lib/locale/en_US/LC_NAME
4001d000-4001e000 r--p  03:03 686795 
/usr/lib/locale/en_US/LC_PAPER
4001e000-4001f000 r--p  03:03 278006 
/usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES
4001f000-4002 r--p  03:03 408810 
/usr/lib/locale/en_US/LC_MONETARY
4002-4002d000 r-xp  

Re: DO NOT REPLY [Bug 9677] - JSP files not recompiled when newer

[Remy Maucherat]

> --- Additional Comments From [EMAIL PROTECTED]  2002-06-07 15:15 ---
> Win2k SP1+ / JDK 1.3 (I never use Unix)
> Load date.jsp from the examples in your browser.
> Then open it in notepad; modify a few things in it; press reload in the
browser.

Can anyone reproduce this bug ?
(I can't)

Thanks,
Remy


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

Re: Required jar/rpms to build tomcat 4.1.3b1

[Remy Maucherat]

> >4.1 uses coyote which uses tomcat-utils, which works fine with
> >pureTLS.

BTW, PureTLS support is not included in this release (next one I promise
:)). You'll have to rebuild Coyote from the source to get it.

Remy


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

DO NOT REPLY [Bug 9677] - JSP files not recompiled when newer

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

JSP files not recompiled when newer





--- Additional Comments From [EMAIL PROTECTED]  2002-06-07 15:15 ---
Win2k SP1+ / JDK 1.3 (I never use Unix)
Load date.jsp from the examples in your browser.
Then open it in notepad; modify a few things in it; press reload in the browser.

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

RE: TC 4.1.3 jasper error

[GOMEZ Henri]

>> My Eclipse IDE (with Sun JDK 1.3.1_03) give me the following error
>> for Node.java
>
>It's been fixed already (a few variables needed to be 
>protected instead of
>private), but that class must be compiled with the classic compiler in
>4.1.3.

Thanks, but Eclipse use its own compiler (which is damn't fast).

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

Re: TC 4.1.3 jasper error

[Remy Maucherat]

> My Eclipse IDE (with Sun JDK 1.3.1_03) give me the following error
> for Node.java

It's been fixed already (a few variables needed to be protected instead of
private), but that class must be compiled with the classic compiler in
4.1.3.

Remy


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

DO NOT REPLY [Bug 9690] - POST - HttpRequestBase.parseParameters() infinite loop

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

POST - HttpRequestBase.parseParameters() infinite loop

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

DO NOT REPLY [Bug 9690] - POST - HttpRequestBase.parseParameters() infinite loop

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

POST - HttpRequestBase.parseParameters() infinite loop

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-06-07 15:07 ---
This bug was fixed 4/9/2002.
The latest 4.0.4 Beta 3 and 4.1.3 Beta versions of Tomcat
were built after this bug was fixed.  Upgrading should
fix the problem.

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

TC 4.1.3 jasper error

[GOMEZ Henri]

My Eclipse IDE (with Sun JDK 1.3.1_03) give me the following error 
for Node.java

in :

/**
 * When this node was created from a JSP page in JSP syntax, its text
 * was stored as a String in the "text" field, whereas when this node
 * was created from a JSP document, its text was stored as one or more
 * TemplateText nodes in its body. This method handles either case.
 * @return The text string
 */
public char[] getText() {
char[] ret = text;
if ((ret == null) && (body != null)) {
CharArrayWriter chars = new CharArrayWriter();
int size = body.size();
for (int i=0; i-Original Message-
>From: Jean-Francois Nadeau [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 07, 2002 3:41 PM
>To: Tomcat Developers List
>Subject: RE: mod_jk 4.03 deadlock
>
>
>Hi.
>
>I found something very interesting this morning in catalina.out file.
>Here it is:
>
>java.lang.IllegalStateException: Current state = FLUSHED, new state =
>CODING_END
>at
>java.nio.charset.CharsetEncoder.throwIllegalStateException(Char
>setEncoder.java:933)
>at
>java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529)
>at
>sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar(StreamEnco
>der.java:356)
>at
>sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413)
>at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158)
>at 
>java.io.OutputStreamWriter.close(OutputStreamWriter.java:222)
>at java.io.PrintWriter.close(PrintWriter.java:137)
>at
>org.apache.catalina.connector.ResponseBase.finishResponse(Respo
>nseBase.java:482)
>at
>org.apache.catalina.connector.HttpResponseBase.finishResponse(H
>ttpResponseBase.java:236)
>at
>org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Respon
>se.java:190)
>at
>org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:435)
>at
>org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:495)
>at java.lang.Thread.run(Thread.java:536)
>
>I looked at the AJP13 code (connectors, branch 4.02) in Tomcat 
>CVS and I
>found that there is no finally block to close socket 
>connections in case
>of failure... Because IllegalStateException is an unchecked 
>exception, I
>run out of file descriptors after a short amount of time. Also, because
>mod_jk doesn't get the END, Apache deadlocks without my select patch 
>
>I use JDK 1.4. It seems to be a NIO bug...
>
>Do you have any idea how to fix that?
>
>Thanks,
>
>jeff
>
>On Fri, 2002-06-07 at 04:30, GOMEZ Henri wrote:
>> >The real issue is why tomcat doesn't send the data. Could you try 
>> >with tomcat4.1 ( or the new coyote-based ajp connector ) ? Is it 
>> >really a deadlock ( tomcat and mod_jk both waiting for input,
>> >i.e. locked in read ) ? Or it is that tomcat for some reasons
>> >doesn't send the 'END' message ? 
>> 
>> Hum, it recall me some problems which may have been solved in post
>> 4.0.3 or in recent jtc (related to thread problem)
>>  
>> >Of course, there is the issue of detecting timeouts - but that's
>> >extremely tricky, as some requests may take a long time to process,
>> >and waiting 3 seconds ( or any other timeout ) is not a 
>good solution. 
>> >It is the java side who should send the END message when the
>> >requests ends.
>> 
>> Hum, I never liked too much the select, at least on Unix boxes
>> a good blocking read make OS wake up your task/thread as soon as
>> there is something to do.
>>  
>> >Can you try more debugging, also on the java side ? Maybe the
>> >etherreal AJP pluging can help :-) 
>> >
>> >BTW, even if you solved the deadlock you may run into other 
>problems,
>> >as requests longer than 3 secs will fail.
>> 
>> Yep, select is not the solution.
>> 
>> You could :
>> 
>> Keep tomcat 4.0.3 and add debugging code
>> Use tomcat 4.0.4b2
>> Or better switch to tomcat 4.1.3
>> 
>> --
>> To unsubscribe, e-mail:   

> For additional commands, e-mail: 
> 
> 



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


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

DO NOT REPLY [Bug 9677] - JSP files not recompiled when newer

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

JSP files not recompiled when newer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |



--- Additional Comments From [EMAIL PROTECTED]  2002-06-07 14:55 ---
Remy:

Are you using Windows platform for your test?  Bug #2885 seems to indicate that 
the problem was only present on Windows platforms.  

When you state the you modified a JSP from the examples web application and 
then reloaded, do you mean that you only did a Browser Refresh?  That is what I 
was trying to do.  Or are you instructing the web application to reload through 
the Manager interface (which I still haven't found the documentation for)?

Thanks!
Glenn

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

Re: Required jar/rpms to build tomcat 4.1.3b1

[jean-frederic clere]

GOMEZ Henri wrote:
> Could you also provide source tarball also ?

done. I will look for a way to get it done automaticly...

> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .) 
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
> 
> 
> 
> 
>>-Original Message-
>>From: jean-frederic clere [mailto:[EMAIL PROTECTED]]
>>Sent: Friday, June 07, 2002 2:55 PM
>>To: Tomcat Developers List
>>Subject: Re: Required jar/rpms to build tomcat 4.1.3b1
>>
>>
>>GOMEZ Henri wrote:
>>
>Yes, but where is it ?

In cvs for the moment.
Should I produce one and put it in a known place?
>>>
>>>
>>>Yes, please ;)
>>
>>I have put it in http://www.apache.org/~jfclere/commons-daemon/
>>named commons-daemon.jar
>>
>>You can get it build in the TC by doing ant download. (that is 
>>what I have used 
>>to produce it).
>>
>>
>>>--
>>>To unsubscribe, e-mail:   
>>
>>
>>
>>>For additional commands, e-mail: 
>>
>>
>>
>>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:   
>>
>>For additional commands, e-mail: 
>>
>>
>>
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 




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

DO NOT REPLY [Bug 6659] - HttpUtils.getRequestURL gives incorrect URL with web.xml redirected error pages

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

HttpUtils.getRequestURL gives incorrect URL with web.xml redirected error pages





--- Additional Comments From [EMAIL PROTECTED]  2002-06-07 14:55 ---

So... Does it make sence to just change the method 

HttpUtils.getRequestURL( request )

so that it simply has 1 line,

return request.getRequestURL() 

Since HttpServletRequest.getRequestURL() returns the correct answer?

I implemented this and tested it for me. and it seems to work just fine.

ie, this patch...
Index: jakarta-servletapi-4/src/share/javax/servlet/http/HttpUtils.java
===
RCS file:
/home/cvspublic/jakarta-servletapi-4/src/share/javax/servlet/http/HttpUtils.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 HttpUtils.java
--- jakarta-servletapi-4/src/share/javax/servlet/http/HttpUtils.java9 Jan
2001 03:24:20 -   1.1.1.1
+++ jakarta-servletapi-4/src/share/javax/servlet/http/HttpUtils.java7 Jun
2002 14:47:19 -
@@ -324,28 +324,7 @@
  */
 
 public static StringBuffer getRequestURL (HttpServletRequest req) {
-   StringBuffer url = new StringBuffer ();
-   String scheme = req.getScheme ();
-   int port = req.getServerPort ();
-   String urlPath = req.getRequestURI();
-
-   //StringservletPath = req.getServletPath ();
-   //StringpathInfo = req.getPathInfo ();
-
-   url.append (scheme);// http, https
-   url.append ("://");
-   url.append (req.getServerName ());
-   if ((scheme.equals ("http") && port != 80)
-   || (scheme.equals ("https") && port != 443)) {
-   url.append (':');
-   url.append (req.getServerPort ());
-   }
-   //if (servletPath != null)
-   //url.append (servletPath);
-   //if (pathInfo != null)
-   //url.append (pathInfo);
-   url.append(urlPath);
-   return url;
+   return req.getRequestURL();
 }
 }

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

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

[bugzilla]

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

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

Simple custom tag example uses old declaration style





--- Additional Comments From [EMAIL PROTECTED]  2002-06-07 14:39 ---
Hi.  Couldn't find who was using webapps/example/jsp/source.jsp, but I
updated that also.   Here is my patch.   Can someone review and apply this?

Index: jakarta-tomcat-4.0/webapps/examples/WEB-INF/web.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/WEB-INF/web.xml,v
retrieving revision 1.21
diff -u -r1.21 web.xml
--- jakarta-tomcat-4.0/webapps/examples/WEB-INF/web.xml 4 Apr 2002 20:30:34
-   1.21
+++ jakarta-tomcat-4.0/webapps/examples/WEB-INF/web.xml 7 Jun 2002 14:17:13
-
@@ -169,24 +169,6 @@
 
 
 
-
-
-  http://jakarta.apache.org/tomcat/debug-taglib
-
-
-   /WEB-INF/jsp/debug-taglib.tld
-
-
-
-
-
-  http://jakarta.apache.org/tomcat/examples-taglib
-
-
-   /WEB-INF/jsp/example-taglib.tld
-
-
-
 
   mail/Session
   javax.mail.Session
Index: jakarta-tomcat-4.0/webapps/examples/jsp/simpletag/foo.jsp
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/simpletag/foo.jsp,v
retrieving revision 1.3
diff -u -r1.3 foo.jsp
--- jakarta-tomcat-4.0/webapps/examples/jsp/simpletag/foo.jsp   20 Sep 2001
17:48:49 -  1.3
+++ jakarta-tomcat-4.0/webapps/examples/jsp/simpletag/foo.jsp   7 Jun 2002
14:17:13 -
@@ -4,7 +4,7 @@
   reserved.
 -->
 
-<%@ taglib uri="http://jakarta.apache.org/tomcat/examples-taglib"; prefix="eg"%>
+<%@ taglib uri="/WEB-INF/jsp/example-taglib.tld" prefix="eg"%>
 
 Radio stations that rock:
 
Index: jakarta-tomcat-4.0/webapps/examples/jsp/source.jsp
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/source.jsp,v
retrieving revision 1.2
diff -u -r1.2 source.jsp
--- jakarta-tomcat-4.0/webapps/examples/jsp/source.jsp  20 Mar 2002 17:34:30
-  1.2
+++ jakarta-tomcat-4.0/webapps/examples/jsp/source.jsp  7 Jun 2002 14:17:13
-
@@ -1,4 +1,3 @@
-<%@ taglib uri="http://jakarta.apache.org/tomcat/examples-taglib";
-prefix="eg" %>
+<%@ taglib uri="/WEB-INF/jsp/example-taglib.tld" prefix="eg"%>
 
 

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

RE: Required jar/rpms to build tomcat 4.1.3b1

[GOMEZ Henri]

>> PureTLS ? Not yet in TC 4.x ...
>
>4.1 uses coyote which uses tomcat-utils, which works fine with 
>pureTLS. 
>I assume it's just undocumented, I don't see a code 
>problem ( with the coyote connector ).
>

Hum, JSSE is still required in part of the code, outside HTTP 
connector world.

org.apache.catalina.net.SSLServerSocketFactory require JSSE.

JCERT is needed by org.apache.catalina.valves.CertificatesValve.



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

cvs commit: jakarta-tomcat-connectors/webapp/docs menu.idx

[jfclere]

jfclere 2002/06/07 07:27:14

  Modified:webapp/docs menu.idx
  Log:
  Add the faq (still a very primitive document).
  
  Revision  ChangesPath
  1.4   +1 -0  jakarta-tomcat-connectors/webapp/docs/menu.idx
  
  Index: menu.idx
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/docs/menu.idx,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- menu.idx  13 May 2002 02:33:17 -  1.3
  +++ menu.idx  7 Jun 2002 14:27:14 -   1.4
  @@ -6,4 +6,5 @@
 
 
 
  +  
   
  
  
  

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

RE: Required jar/rpms to build tomcat 4.1.3b1

[costinm]

On Fri, 7 Jun 2002, GOMEZ Henri wrote:

> 
> >
> >Bad and I though we had a substitution.
> 
> PureTLS ? Not yet in TC 4.x ...

4.1 uses coyote which uses tomcat-utils, which works fine with pureTLS. 
I assume it's just undocumented, I don't see a code 
problem ( with the coyote connector ).

Costin

> 
> But I remember PureTLS author, Eric Rescorla, wrote
> something about work in progress some times ago...
>  
> >> Java Transaction API 1.0.1 or later (SUN LICENSE PROBLEM)
> >> 
> >> Struts 1.0.1 or later
> >> 
> >> Tyrex Data Source 1.0 or later
> >> 
> >> JUnit 3.7 or later
> >> 
> >> Commons Modeler Binary version 20020117 or later
> >
> >It get released: commons-modeler-1.0
> 
> Good
> 
> >> Commons DBCP version 20011030 or later
> >> 
> >> Commons Pool version 20011030 or later
> >
> >It get released: commons-pool-1.0
> 
> Good
> 
> >> Commons Daemon version 20020219 or later
> >
> >I need help and time in this ;-)
> 
> Yes, but where is it ?
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


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

RE: mod_jk 4.03 deadlock

[Jean-Francois Nadeau]

Hi.

My bug was a known issue:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7725

Effectively, we use HttpServletResponse.sendRedirect in our code.

Thanks a lot,

jeff

On Fri, 2002-06-07 at 09:40, Jean-Francois Nadeau wrote:
> Hi.
> 
> I found something very interesting this morning in catalina.out file.
> Here it is:
> 
> java.lang.IllegalStateException: Current state = FLUSHED, new state =
> CODING_END
> at
> java.nio.charset.CharsetEncoder.throwIllegalStateException(CharsetEncoder.java:933)
> at
> java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529)
> at
> sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar(StreamEncoder.java:356)
> at
> sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413)
> at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158)
> at java.io.OutputStreamWriter.close(OutputStreamWriter.java:222)
> at java.io.PrintWriter.close(PrintWriter.java:137)
> at
> org.apache.catalina.connector.ResponseBase.finishResponse(ResponseBase.java:482)
> at
> 
>org.apache.catalina.connector.HttpResponseBase.finishResponse(HttpResponseBase.java:236)
> at
> org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Response.java:190)
> at
> org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:435)
> at
> org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:495)
> at java.lang.Thread.run(Thread.java:536)
> 
> I looked at the AJP13 code (connectors, branch 4.02) in Tomcat CVS and I
> found that there is no finally block to close socket connections in case
> of failure... Because IllegalStateException is an unchecked exception, I
> run out of file descriptors after a short amount of time. Also, because
> mod_jk doesn't get the END, Apache deadlocks without my select patch 
> 
> I use JDK 1.4. It seems to be a NIO bug...
> 
> Do you have any idea how to fix that?
> 
> Thanks,
> 
> jeff
> 
> On Fri, 2002-06-07 at 04:30, GOMEZ Henri wrote:
> > >The real issue is why tomcat doesn't send the data. Could you try 
> > >with tomcat4.1 ( or the new coyote-based ajp connector ) ? Is it 
> > >really a deadlock ( tomcat and mod_jk both waiting for input,
> > >i.e. locked in read ) ? Or it is that tomcat for some reasons
> > >doesn't send the 'END' message ? 
> > 
> > Hum, it recall me some problems which may have been solved in post
> > 4.0.3 or in recent jtc (related to thread problem)
> >  
> > >Of course, there is the issue of detecting timeouts - but that's
> > >extremely tricky, as some requests may take a long time to process,
> > >and waiting 3 seconds ( or any other timeout ) is not a good solution. 
> > >It is the java side who should send the END message when the
> > >requests ends.
> > 
> > Hum, I never liked too much the select, at least on Unix boxes
> > a good blocking read make OS wake up your task/thread as soon as
> > there is something to do.
> >  
> > >Can you try more debugging, also on the java side ? Maybe the
> > >etherreal AJP pluging can help :-) 
> > >
> > >BTW, even if you solved the deadlock you may run into other problems,
> > >as requests longer than 3 secs will fail.
> > 
> > Yep, select is not the solution.
> > 
> > You could :
> > 
> > Keep tomcat 4.0.3 and add debugging code
> > Use tomcat 4.0.4b2
> > Or better switch to tomcat 4.1.3
> > 
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 



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

RE: mod_jk 4.03 deadlock

[Jean-Francois Nadeau]

Hi.

I found something very interesting this morning in catalina.out file.
Here it is:

java.lang.IllegalStateException: Current state = FLUSHED, new state =
CODING_END
at
java.nio.charset.CharsetEncoder.throwIllegalStateException(CharsetEncoder.java:933)
at
java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529)
at
sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar(StreamEncoder.java:356)
at
sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413)
at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158)
at java.io.OutputStreamWriter.close(OutputStreamWriter.java:222)
at java.io.PrintWriter.close(PrintWriter.java:137)
at
org.apache.catalina.connector.ResponseBase.finishResponse(ResponseBase.java:482)
at
org.apache.catalina.connector.HttpResponseBase.finishResponse(HttpResponseBase.java:236)
at
org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Response.java:190)
at
org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:435)
at
org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:495)
at java.lang.Thread.run(Thread.java:536)

I looked at the AJP13 code (connectors, branch 4.02) in Tomcat CVS and I
found that there is no finally block to close socket connections in case
of failure... Because IllegalStateException is an unchecked exception, I
run out of file descriptors after a short amount of time. Also, because
mod_jk doesn't get the END, Apache deadlocks without my select patch 

I use JDK 1.4. It seems to be a NIO bug...

Do you have any idea how to fix that?

Thanks,

jeff

On Fri, 2002-06-07 at 04:30, GOMEZ Henri wrote:
> >The real issue is why tomcat doesn't send the data. Could you try 
> >with tomcat4.1 ( or the new coyote-based ajp connector ) ? Is it 
> >really a deadlock ( tomcat and mod_jk both waiting for input,
> >i.e. locked in read ) ? Or it is that tomcat for some reasons
> >doesn't send the 'END' message ? 
> 
> Hum, it recall me some problems which may have been solved in post
> 4.0.3 or in recent jtc (related to thread problem)
>  
> >Of course, there is the issue of detecting timeouts - but that's
> >extremely tricky, as some requests may take a long time to process,
> >and waiting 3 seconds ( or any other timeout ) is not a good solution. 
> >It is the java side who should send the END message when the
> >requests ends.
> 
> Hum, I never liked too much the select, at least on Unix boxes
> a good blocking read make OS wake up your task/thread as soon as
> there is something to do.
>  
> >Can you try more debugging, also on the java side ? Maybe the
> >etherreal AJP pluging can help :-) 
> >
> >BTW, even if you solved the deadlock you may run into other problems,
> >as requests longer than 3 secs will fail.
> 
> Yep, select is not the solution.
> 
> You could :
> 
> Keep tomcat 4.0.3 and add debugging code
> Use tomcat 4.0.4b2
> Or better switch to tomcat 4.1.3
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 



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

Re: webapp connector configure.in problem with alt apache layout

[Pier Fumagalli]

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

> G'day,
> 
> Apache httpd 2 supports different ways of laying out the installed files when
> building and installing from the source via the config.layout file.  I built
> and installed using a variant of the "opt" layout that is FHS compliant.
> 
> Unfortunately, configure.in for webapp contains some hardwired layout
> assumptions.  Here's an example:
> 
> MODULE="apache-2.0"
> local_prefix="`${APXS} -q PREFIX`"
> LIBTOOL="$local_prefix/build/libtool"
> 
> I suggested an enhancement (#9316) to the Apache folks that will help out
> with this and the change has just been checked in:
> 
>> "apxs -q installbuilddir" now works with the current code in CVS.
> 
> There have also been a few other apxs fixes checked in, so it's less broken
> than the comment in configure.in suggests.

Nope, it doesn't:

$ grep "build" `find . -type f` | grep LIBTOOL
$

Get the latest CVS.

Pier


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

webapp connector configure.in problem with alt apache layout

[Smiley Jonathan]

G'day,

  Apache httpd 2 supports different ways of laying out the installed files when
building and installing from the source via the config.layout file.  I built
and installed using a variant of the "opt" layout that is FHS compliant.

  Unfortunately, configure.in for webapp contains some hardwired layout
assumptions.  Here's an example:

  MODULE="apache-2.0"
  local_prefix="`${APXS} -q PREFIX`"
  LIBTOOL="$local_prefix/build/libtool"

  I suggested an enhancement (#9316) to the Apache folks that will help out
with this and the change has just been checked in:

> "apxs -q installbuilddir" now works with the current code in CVS.

  There have also been a few other apxs fixes checked in, so it's less broken
than the comment in configure.in suggests.

  Just thought I'd let you know.

Regards,
 Jonathan Knispel

http://www.sold.com.au - The Sold.com.au Big Brand Sale
- New PCs, notebooks, digital cameras, phones and more ... Sale ends June 12

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

RE: Required jar/rpms to build tomcat 4.1.3b1

[GOMEZ Henri]

Could you also provide source tarball also ?

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



>-Original Message-
>From: jean-frederic clere [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 07, 2002 2:55 PM
>To: Tomcat Developers List
>Subject: Re: Required jar/rpms to build tomcat 4.1.3b1
>
>
>GOMEZ Henri wrote:
Yes, but where is it ?
>>>
>>>In cvs for the moment.
>>>Should I produce one and put it in a known place?
>> 
>> 
>> Yes, please ;)
>
>I have put it in http://www.apache.org/~jfclere/commons-daemon/
>named commons-daemon.jar
>
>You can get it build in the TC by doing ant download. (that is 
>what I have used 
>to produce it).
>
>> 
>> --
>> To unsubscribe, e-mail:   
>
>> For additional commands, e-mail: 
>
>> 
>> 
>
>
>
>
>--
>To unsubscribe, e-mail:   
>
>For additional commands, e-mail: 
>
>
>

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

Re: Required jar/rpms to build tomcat 4.1.3b1

[jean-frederic clere]

GOMEZ Henri wrote:
>>>Yes, but where is it ?
>>
>>In cvs for the moment.
>>Should I produce one and put it in a known place?
> 
> 
> Yes, please ;)

I have put it in http://www.apache.org/~jfclere/commons-daemon/
named commons-daemon.jar

You can get it build in the TC by doing ant download. (that is what I have used 
to produce it).

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




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

Problems in redirecting requests from IIS to Tomcat 4

[Luca Ventura]

Hello everybody!

I have installed Internet Information Services (IIS) as Web Server  and
Apache Tomcat 4.0 as plug-in of IIS to support JSP-Servlets (to do this I
installed an ISAPI filter in IIS that redirects
all my JSP-servlet requests to Tomcat). All works fine when I am on
"localhost" but if I use
another domain for my Web Server (e.g: www.mydomain.com) I have the
following problem: when I try to connect to a site that must be redirected
to Tomcat 4 (because it contains JSP pages or servlets), IIS ask me a login
or a password to access to it. For example: i try to connect to the url
"http://www.mydomain.com/mysite"; and "mysite" is a web application defined
in "webapps" folder of tomcat (the document folder is in
webapps\mysite\web-inf").

What can I do to avoid IIS asks me a password or a login? I want that all
users that connects to my site  are redirected to Tomcat without asking any
login and password

I think the problem it isn't in Tomcat's configuration but in IIS's
configurationbut I can be wrong.

I hope someone can help me...thanks i advance!

 Luca


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

DO NOT REPLY [Bug 9690] New: - POST - HttpRequestBase.parseParameters() infinite loop

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

POST - HttpRequestBase.parseParameters() infinite loop

   Summary: POST - HttpRequestBase.parseParameters() infinite loop
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Other
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Summary:
org.apache.catalina.connector.HttpRequestBase.parseParameters() might inifinite
loop with POST data.

BACKGROUND:
We use apache 1.3 + tomcat 4.0.2 (Ajp13Connector).
We run 2 apache instances and 4 tomcat instances. Occasionally we see an httpd
process begin to *hog* cpu and not stop trying to hog cpu until httpd is
restarted. Over time, another httpd process will reach this state until too much
cpu is wasted on the bad httpd processes and a restart of apache is needed.
During this time - one (or more) of the java processes will also begin to hog
cpu. This is event does not happen quickly - it usually takes a week or so to
reach a state where a restart is needed. 
Looking at MRTG graphs - we see *lots* of network activity appear (and
disappear) with the start of the problem and subsequent restart of httpd.
I performed some thread dumps of the java process. And noticed that there were 2
threads consistently stuck in a similar stack trace. (Over the course of a 45
minute investigation of several thread dumps of the same java process).

Digging into the stack trace - I see that that the *runaway* threads are
switching between suspended/runnable and their method calls are socketRead and
socketWrite. 

I belive what is happening is an infinite loop in
HttpRequestBase.parseParameters(). Here is the the offending snippet, lines 639-647:
int max = getContentLength();
int max = getContentLength();
int len = 0;
byte buf[] = new byte[getContentLength()];
ServletInputStream is = getInputStream();
while (len < max) {
int next = is.read(buf, len, max - len);
len += next;
}
== end sippet ==

I believe is.read is allowed to return 0 or a negative number. If that is true -
then the loop never finishes - possibly causing the issues I am seeing. It seems
occasionally for some reason - the POSTing of data from apache to tomcat seems
to be failing but the not serious enough to warrant an IOException.

Unfortuneately - I have not yet been able reproduce this in a lab environment
yet. I only see this issue occur in a production environment.

If anyone can validate this - I may be able to provide a patch.

Here is one of the stack traces (that the thread is stuck in):
"Ajp13Processor[12009][56]" daemon prio=9 tid=0x0143da98 nid=318 lwp_id=29393
runnable [0x6edc1000..0x6edbf478]
at java.net.SocketOutputStream.socketWrite(Native Method)
at java.net.SocketOutputStream.write(Unknown Source)
at org.apache.ajp.Ajp13.send(Ajp13.java:525)
at org.apache.ajp.RequestHandler.refillReadBuffer(RequestHandler.java:700)
at org.apache.ajp.RequestHandler.doRead(RequestHandler.java:645)
at org.apache.ajp.Ajp13.doRead(Ajp13.java:354)
at org.apache.ajp.tomcat4.Ajp13InputStream.read(Ajp13InputStream.java:99)
at
org.apache.catalina.connector.HttpRequestBase.parseParameters(HttpRequestBase.java:644)
at
org.apache.catalina.connector.HttpRequestBase.getParameterMap(HttpRequestBase.java:695)
at
org.apache.catalina.connector.RequestFacade.getParameterMap(RequestFacade.java:175)
at
org.apache.catalina.core.ApplicationHttpRequest.setRequest(ApplicationHttpRequest.java:523)
- locked <0x7733f990> (a java.util.HashMap)
at
org.apache.catalina.core.ApplicationHttpRequest.(ApplicationHttpRequest.java:126)
at
org.apache.catalina.core.ApplicationDispatcher.wrapRequest(ApplicationDispatcher.java:918)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:547)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:497)
at 
org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:819)
at org.apache.jsp.prod_0005flist$jsp._jspService(prod_0005flist$jsp.java:96)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:202)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
a

RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config MxInterceptor.java

[GOMEZ Henri]

>   * The Apache Software License, Version 1.1
>   *
>   * Copyright (c) 1999 The Apache Software Foundation.  All rights 
>   * reserved.

Humn may be time to change copyright to Copyright (c) 1999-2002 ? 

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

Re: [4.1.3] Binaries uploaded

[jean-frederic clere]

[EMAIL PROTECTED] wrote:
> I assume it works fine if you take out mod_jk2 ?

yes ;-(

> Can you turn debugging on
> ( debug=1 in all [] sections ) ?

done.

> 
> What do you see in error.log ?

It ends in:
+++
[Thu Jun 06 17:13:58 2002] [warn] config.setAttribute() Error setting logger.apa
che2: file /export/home2/apache20/apache20/logs/mod_jk.log
[Thu Jun 06 17:20:53 2002] [warn] config.setAttribute() Error setting logger.apa
che2: file /export/home2/apache20/apache20/logs/mod_jk.log
[Thu Jun 06 17:25:42 2002] [warn] config.setAttribute() Error setting logger.apa
che2: file /export/home/apache20/apache20/logs/mod_jk.log
[Fri Jun 07 11:42:11 2002] [warn] config.setAttribute() 1 setting logger.apache2
: level DEBUG
[Fri Jun 07 11:42:11 2002] [warn] config: set logger.apache2: / file / c4e68 / l
ogger.apache2:.file = /export/home/apache20/apache20/logs/mod_jk.log
[Fri Jun 07 11:42:11 2002] [warn] config.setAttribute() Error setting logger.apa
che2: file /export/home/apache20/apache20/logs/mod_jk.log
[Fri Jun 07 11:42:11 2002] [warn] config.setAttribute() 1 setting logger.apache2
: file /export/home/apache20/apache20/logs/mod_jk.log
[Fri Jun 07 11:42:11 2002] [warn] config: set logger.apache2: / debug / c4e68 /
logger.apache2:.debug = 1
[Fri Jun 07 11:42:11 2002] [warn] config.setConfig():  Creating channel.socket:l
ocalhost:8019
[Fri Jun 07 11:42:11 2002] [warn] config: set channel.socket:localhost:8019 / po
rt / e8f08 / channel.socket:localhost:8019.port = 8019
[Fri Jun 07 11:42:11 2002] [warn] config.setAttribute() 1 setting channel.socket
:localhost:8019 port 8019
[Fri Jun 07 11:42:11 2002] [warn] config: set channel.socket:localhost:8019 / ho
st / e8f08 / channel.socket:localhost:8019.host = 127.0.0.1
[Fri Jun 07 11:42:11 2002] [warn] config.setAttribute() 1 setting channel.socket
:localhost:8019 host 127.0.0.1
[Fri Jun 07 11:42:11 2002] [warn] config: set channel.socket:localhost:8019 / de
bug / e8f08 / channel.socket:localhost:8019.debug = 1
[Fri Jun 07 11:42:11 2002] [warn] config.setConfig():  Creating worker.status
+++

I have commented out the status worker things and now it cores:
+++
$ mdb bin/httpd core
Loading modules: [ ]
 > $c
libc.so.1`strlen+0x80(0, eef77, 0, 67601, 0, fe2ae792)
libc.so.1`vsnprintf+0x5c(ffbed578, 7fff, fe2ae778, ffbef65c, 746a8,
ffbed578)
mod_jk2.so`jk2_logger_apache2_jkVLog+0x40(0, ffbed578, fe2ae6f8, 166, 1,
fe2ae778)
mod_jk2.so`jk2_logger_apache2_jkLog+0x20(bb698, c6ee8, fe2ae6f8, 166, 1,
fe2ae778)
mod_jk2.so`jk2_uriEnv_init+0x4a4(bb698, f0f08, fe2a1ce8, 103020, 4, fe29c5bc)
mod_jk2.so`jk2_uriMap_init+0x268(bb698, 102fc0, 808, 83c, 808, c4ec8)
mod_jk2.so`jk2_workerEnv_init+0x278(bb698, c8ef0, fe2a4350, 0, 0, 0)
mod_jk2.so`jk2_init+0xc(bb698, 112f58, c8ef0, 746a8, 1, c8ef0)
mod_jk2.so`jk2_child_init+0x68(112f58, 746a8, fe2ab364, 67a08, 0, 0)
ap_run_child_init+0x3c(112f58, 746a8, 112f58, 0, 10, 0)
child_main+0xd0(1, 1, fefbef98, fefcb228, 64400, 68400)
make_child+0xf0(0, 1, a, 2c, 1, 1)
perform_idle_server_maintenance+0x168(72958, 6, ffbefb58, 72958, 746a8, 4d398)
ap_mpm_run+0x56c(0, 67800, 0, 64400, 64400, 4f000)
main+0x4c0(746a8, 709d0, 4f0b8, 4f0c8, 0, 0)
_start+0x5c(0, 0, 0, 0, 0, 0)
+++

> 
> 
> On Thu, 6 Jun 2002, jean-frederic clere wrote:
> 
>> [Thu Jun 06 17:20:53 2002] [warn] config.setAttribute() Error setting 
>> logger.apache2: file /export/home/apache20/apache20/logs/mod_jk.log
>> +++
>>
>> Any things wrong in my workers2.properties?
> 
> 
> I'll remove the message. In jk2 we use the apache2 logger ( i.e. 
> everything goes to error.log, using the apache code for logging ).
> The default is the file logger - where we use our own impl.
> ( IIS can also use the windows event log ).
> 
> 
> 
> Costin
> 
> 
> 
> 
> # Comments will be lost when protocol-based config will be used
> # ( at least in the first version ). In a future version we'll save
> # the comments before every section and property and save ( maybe )
> 
> # Global options ( in addition to the pre-defined fs, ps, java_home
> [config]
> foo=bar
> 
> # Logger options. For apache2 only level can be set ( it logs to error.log )
> # For apache1 the file must be specified too.
> # XXX logger is an alias or shortcut to logger.file:"" 
> # Do we need shortcuts ? XXX Document shortcuts
> [logger]
> level=DEBUG
> file=/export/home/apache20/apache20/logs/mod_jk.log
> 
> # Default channel. Defaults are used
> # XXX The name must be parsed and used automatically
> # XXX Objects to be defined on-demand, using default values
> #[channel.socket:localhost:8009]
> 
> # Example socket channel, override port
> [channel.socket:localhost:8019]
> port=8019
> host=127.0.0.1
> 
> # Example unix socket
> #[channel.apr:/tmp/tomcatUnixSocket]
> 
> # The status worker. Only defaults. XXX in the final version,
> # you shouldn't have to define the objects using defaults, they'll be
> # created automatically, on demand. 
> [worker.status]
> 
> # XXX docum

RE: Required jar/rpms to build tomcat 4.1.3b1

[GOMEZ Henri]

>> Yes, but where is it ?
>
>In cvs for the moment.
>Should I produce one and put it in a known place?

Yes, please ;)

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

Re: Required jar/rpms to build tomcat 4.1.3b1

[jean-frederic clere]

GOMEZ Henri wrote:
>>Bad and I though we had a substitution.
> 
> 
> PureTLS ? Not yet in TC 4.x ...
> 
> But I remember PureTLS author, Eric Rescorla, wrote
> something about work in progress some times ago...
>  
> 
>>>Java Transaction API 1.0.1 or later (SUN LICENSE PROBLEM)
>>>
>>>Struts 1.0.1 or later
>>>
>>>Tyrex Data Source 1.0 or later
>>>
>>>JUnit 3.7 or later
>>>
>>>Commons Modeler Binary version 20020117 or later
>>
>>It get released: commons-modeler-1.0
> 
> 
> Good
> 
> 
>>>Commons DBCP version 20011030 or later
>>>
>>>Commons Pool version 20011030 or later
>>
>>It get released: commons-pool-1.0
> 
> 
> Good
> 
> 
>>>Commons Daemon version 20020219 or later
>>
>>I need help and time in this ;-)
> 
> 
> Yes, but where is it ?

In cvs for the moment.
Should I produce one and put it in a known place?

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




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

RE: Required jar/rpms to build tomcat 4.1.3b1

[GOMEZ Henri]

>
>Bad and I though we had a substitution.

PureTLS ? Not yet in TC 4.x ...

But I remember PureTLS author, Eric Rescorla, wrote
something about work in progress some times ago...
 
>> Java Transaction API 1.0.1 or later (SUN LICENSE PROBLEM)
>> 
>> Struts 1.0.1 or later
>> 
>> Tyrex Data Source 1.0 or later
>> 
>> JUnit 3.7 or later
>> 
>> Commons Modeler Binary version 20020117 or later
>
>It get released: commons-modeler-1.0

Good

>> Commons DBCP version 20011030 or later
>> 
>> Commons Pool version 20011030 or later
>
>It get released: commons-pool-1.0

Good

>> Commons Daemon version 20020219 or later
>
>I need help and time in this ;-)

Yes, but where is it ?

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

Re: Required jar/rpms to build tomcat 4.1.3b1

[jean-frederic clere]

GOMEZ Henri wrote:
> Hi,
> 
> I've started digging around to make Tomcat 4.1.3 beta1 rpm
> and you'll find later of required packages.
> 
> jpackage project members get a copy of this mail since 
> they could have many of them allready available, and sus 
> we could use them.
> 
> The problem with Tomcat 4.1.3, in an OSS packaging perspective,
> is the mix of OSS packages, which could be freely distributed
> and 'closed' packages, that couldn't be provided independently
> due to Sun license which insist on having them included in 
> programs and not alone.
> 
> So the required packages are :
> 
> ant 1.4.1
> xerces 2.0.1
> xalan 2.3.1
> 
> These two are not required by JDK 1.3 and later
> 
> jndi 1.2.1(SUN LICENSE PROBLEM)
> ldap/jaas 1.2.3   (SUN LICENSE PROBLEM)
> 
> servletapi 4 (or 2.3 depends how we call it)
> 
> Commons Beanutils 1.1 or greater (1.3 is the latest)
> 
> Commons Collections 1.0 or greater (2.0 is the latest)
> 
> Commons Digester 1.1.1 or greater (1.2 is the latest)
> 
> Commons Logging (one of the latest)
> 
> regexp 1.2
> 
> Here is a list of optional packages, but it should be
> fine to have them also to be able to build a fully complete
> tomcat 4.1.3
> 
> JDBC Optional 2.0 (SUN LICENSE PROBLEM)
> 
> mx4j 1.0 (avoid Sun JMX to have an OSS solution)
> 
> Java Activation Framework 1.0.1 (SUN LICENSE PROBLEM)
> 
> JavaMail 1.2 or later (SUN LICENSE PROBLEM)
> 
> JSSE 1.0.2 (SUN LICENSE AND CRYPTO EXPORTS PROBLEMS)

Bad and I though we had a substitution.

> 
> Java Transaction API 1.0.1 or later (SUN LICENSE PROBLEM)
> 
> Struts 1.0.1 or later
> 
> Tyrex Data Source 1.0 or later
> 
> JUnit 3.7 or later
> 
> Commons Modeler Binary version 20020117 or later

It get released: commons-modeler-1.0

> 
> Commons DBCP version 20011030 or later
> 
> Commons Pool version 20011030 or later

It get released: commons-pool-1.0

> 
> Commons Daemon version 20020219 or later

I need help and time in this ;-)

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




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

RE: mod_jk 4.03 deadlock

[GOMEZ Henri]

>The real issue is why tomcat doesn't send the data. Could you try 
>with tomcat4.1 ( or the new coyote-based ajp connector ) ? Is it 
>really a deadlock ( tomcat and mod_jk both waiting for input,
>i.e. locked in read ) ? Or it is that tomcat for some reasons
>doesn't send the 'END' message ? 

Hum, it recall me some problems which may have been solved in post
4.0.3 or in recent jtc (related to thread problem)
 
>Of course, there is the issue of detecting timeouts - but that's
>extremely tricky, as some requests may take a long time to process,
>and waiting 3 seconds ( or any other timeout ) is not a good solution. 
>It is the java side who should send the END message when the
>requests ends.

Hum, I never liked too much the select, at least on Unix boxes
a good blocking read make OS wake up your task/thread as soon as
there is something to do.
 
>Can you try more debugging, also on the java side ? Maybe the
>etherreal AJP pluging can help :-) 
>
>BTW, even if you solved the deadlock you may run into other problems,
>as requests longer than 3 secs will fail.

Yep, select is not the solution.

You could :

Keep tomcat 4.0.3 and add debugging code
Use tomcat 4.0.4b2
Or better switch to tomcat 4.1.3

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

RE: MX4J problems - important!

[GOMEZ Henri]

Hum, I'm wondering which mx4j I should package for
tc 4.1.3, rigth now I've got a 1.0b3.

-
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: Friday, June 07, 2002 4:50 AM
>To: Tomcat Developers List
>Subject: Re: MX4J problems - important!
>
>
>On Thu, 6 Jun 2002, Remy Maucherat wrote:
>
>> > There is a very serious issue with MX4J1.0.b3, the method:
>> > 
>> >   javax.management.MBeanServerFactory.findMBeanServer() 
>> > 
>> > has the wrong signature ( returns List instead of ArrayList ). 
>> > 
>> > Remy - please, update to a more recent version ( CVS head 
>seems to be 
>> > fine ) for the next build (and for the distribution ).
>> 
>> No problem :)
>> Are the JARs you committed in j-t-c/lib ok ?
>
>No, I'll check them in ( I did a build from CVS head, and it seems
>to work fine ).
>
>I'll also check in the commons-logging.jar and the -api
>This is also very important to fix - right now 4.1 will not 
>allow apps to use commons-logging with log4j, I sent a mail
>this morning about this.
>
>Costin
>
>
>--
>To unsubscribe, e-mail:   
>
>For additional commands, e-mail: 
>
>
>

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

R: How to close an HTTP port on Apache Tomcat 4?

[Luca Ventura]

Hello Kevin,

I am very sorry to have posted off-topic:-( but I posted many times in
the tomcat-user forum
but I received always no reply:-(
Given that I need absolutely of such information I tried to post the
question in this forum
because I hope that some more expert people can help meby the way..can
you give me some useful hint?


Thanks anyway and sorry again for my mistake in posting

Regards.
   Luca

-Messaggio originale-
Da: Kevin Jones [mailto:[EMAIL PROTECTED]]
Inviato: venerdi 7 giugno 2002 8.47
A: 'Tomcat Developers List'
Oggetto: RE: How to close an HTTP port on Apache Tomcat 4?


Luca,

both these questions are really user questions. The tomcat-dev list is
for the development of Tomcat.

As many people read both lists they will see these posts twice.
Please don't spam the lists.
Please choose the appropriate list for your questions.

Kevin Jones
Developmentor
www.develop.com


> -Original Message-
> From: Luca Ventura [mailto:[EMAIL PROTECTED]]
> Sent: 07 June 2002 07:28
> To: tomcat-user; tomcat-dev
> Subject: How to close an HTTP port on Apache Tomcat 4?
>
>
> Hello everybody!
>
> I use Apache Tomcat 4.0 as Web Server an I would like to know
> how I can close an opened port (eg. 8000 or 9000) to avoid
> that someone can use it to enter in my system. Which
> configuration files I must modify?
>
>
> Thanks a lot in advance!
>
>Luca
>
>
> --
> 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: 

Required jar/rpms to build tomcat 4.1.3b1

[GOMEZ Henri]

Hi,

I've started digging around to make Tomcat 4.1.3 beta1 rpm
and you'll find later of required packages.

jpackage project members get a copy of this mail since 
they could have many of them allready available, and sus 
we could use them.

The problem with Tomcat 4.1.3, in an OSS packaging perspective,
is the mix of OSS packages, which could be freely distributed
and 'closed' packages, that couldn't be provided independently
due to Sun license which insist on having them included in 
programs and not alone.

So the required packages are :

ant 1.4.1
xerces 2.0.1
xalan 2.3.1

These two are not required by JDK 1.3 and later

jndi 1.2.1  (SUN LICENSE PROBLEM)
ldap/jaas 1.2.3 (SUN LICENSE PROBLEM)

servletapi 4 (or 2.3 depends how we call it)

Commons Beanutils 1.1 or greater (1.3 is the latest)

Commons Collections 1.0 or greater (2.0 is the latest)

Commons Digester 1.1.1 or greater (1.2 is the latest)

Commons Logging (one of the latest)

regexp 1.2

Here is a list of optional packages, but it should be
fine to have them also to be able to build a fully complete
tomcat 4.1.3

JDBC Optional 2.0   (SUN LICENSE PROBLEM)

mx4j 1.0 (avoid Sun JMX to have an OSS solution)

Java Activation Framework 1.0.1 (SUN LICENSE PROBLEM)

JavaMail 1.2 or later (SUN LICENSE PROBLEM)

JSSE 1.0.2 (SUN LICENSE AND CRYPTO EXPORTS PROBLEMS)

Java Transaction API 1.0.1 or later (SUN LICENSE PROBLEM)

Struts 1.0.1 or later

Tyrex Data Source 1.0 or later

JUnit 3.7 or later

Commons Modeler Binary version 20020117 or later

Commons DBCP version 20011030 or later

Commons Pool version 20011030 or later

Commons Daemon version 20020219 or later


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