cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_apache2.h jk_logger_apache2.c jk_pool_apr.c mod_jk.c

[costin]

costin  01/12/13 23:14:59

  Modified:jk/native2/server/apache2 jk_apache2.h jk_logger_apache2.c
jk_pool_apr.c mod_jk.c
  Log:
  Switch to jk_pools so I can test them.
  
  The apr pools seem to work fine, we seem to clean up everything
  ( i.e. reset the pool - I fixed a small bug there ). I run few 100.000 requests,
  the memory is constant.
  
  It also seem jk_pools are fine ( and no malloc happens after the
  warmup, all pools are recycled and we have constant memory as well ! ).
  
  ( I'll remove the debug statements tommorow )
  
  Revision  ChangesPath
  1.2   +5 -1  jakarta-tomcat-connectors/jk/native2/server/apache2/jk_apache2.h
  
  Index: jk_apache2.h
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_apache2.h,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jk_apache2.h  2001/12/13 18:50:33 1.1
  +++ jk_apache2.h  2001/12/14 07:14:59 1.2
  @@ -59,7 +59,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat 
* Author:  Gal Shachor <[EMAIL PROTECTED]>   
* Henri Gomez <[EMAIL PROTECTED]>
  - * Version: $Revision: 1.1 $   
  + * Version: $Revision: 1.2 $   
*/
   
   #include "jk_global.h"
  @@ -81,6 +81,10 @@
   
   int  jk_pool_apr_factory(jk_env_t *env, jk_pool_t *pool,
void **result, char *type, char *name);
  +
  +int  jk_map_aprtable_factory(jk_env_t *env, jk_pool_t *pool,
  + void **result,
  + char *type, char *name);
   
   /* Temp. - we should use the factory ( we may need few changes ) */
   int jk_pool_apr_create( jk_pool_t **newPool, jk_pool_t *parent,
  
  
  
  1.8   +2 -0  
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_logger_apache2.c
  
  Index: jk_logger_apache2.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_logger_apache2.c,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- jk_logger_apache2.c   2001/12/13 19:05:31 1.7
  +++ jk_logger_apache2.c   2001/12/14 07:14:59 1.8
  @@ -132,6 +132,8 @@
   char buf[HUGE_BUFFER_SIZE];
   #endif
   
  +if( level >= l->level )
  +return JK_TRUE;
   
   if( s==NULL ) {
   return JK_FALSE;
  
  
  
  1.5   +46 -15
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_pool_apr.c
  
  Index: jk_pool_apr.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_pool_apr.c,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- jk_pool_apr.c 2001/12/13 19:05:31 1.4
  +++ jk_pool_apr.c 2001/12/14 07:14:59 1.5
  @@ -68,8 +68,12 @@
   
   #include "jk_apache2.h"
   
  -int jk_pool_apr_create( jk_pool_t **newPool, jk_pool_t *parent, apr_pool_t *aprPool 
);
  +#define POOL_DEBUG
   
  +
  +int jk_pool_apr_create( jk_pool_t **newPool, jk_pool_t *parent,
  +apr_pool_t *aprPool );
  +
   int JK_METHOD jk_pool_apr_factory(jk_env_t *env,
 jk_pool_t *pool,
 void **result,
  @@ -79,7 +83,9 @@
*/
   static void jk_pool_apr_close(jk_pool_t *p)
   {
  -
  +#ifdef POOL_DEBUG
  +fprintf(stderr, "apr_close %p\n", p);
  +#endif
   }
   
   /** Nothing - apache will take care.
  @@ -88,12 +94,18 @@
   */
   static void jk_pool_apr_reset(jk_pool_t *p)
   {
  +#ifdef POOL_DEBUG
  +fprintf(stderr, "apr_reset %p\n", p);
  +#endif
   apr_pool_clear(p->_private);
   }
   
   static void *jk_pool_apr_calloc(jk_pool_t *p, 
  -   size_t size)
  +size_t size)
   {
  +#ifdef POOL_DEBUG
  +fprintf(stderr, "apr_calloc %p %d\n", p, size);
  +#endif
   /* assert( p->_private != NULL ) */
   return apr_pcalloc( (apr_pool_t *)p->_private, (apr_size_t)size);
   }
  @@ -101,16 +113,23 @@
   static void *jk_pool_apr_alloc(jk_pool_t *p, 
  size_t size)
   {
  +#ifdef POOL_DEBUG
  +fprintf(stderr, "apr_alloc %p %d\n", p, size);
  +#endif
  +
   return apr_palloc( (apr_pool_t *)p->_private, (apr_size_t)size);
   }
   
   static void *jk_pool_apr_realloc(jk_pool_t *p, 
  - size_t sz,
  - const void *old,
  - size_t old_sz)
  + size_t sz,
  + const void *old,
  + size_t old_sz)
   {
   void *

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_ajp14_worker.c jk_channel_socket.c jk_env.c jk_handler_discovery.c jk_handler_logon.c jk_handler_response.c jk_jni_worker.c jk_lb_worker.c jk_logger_file.c jk_uriMap.c jk_workerEnv.c

[costin]

costin  01/12/13 23:12:42

  Modified:jk/native2/common jk_ajp14_worker.c jk_channel_socket.c
jk_env.c jk_handler_discovery.c jk_handler_logon.c
jk_handler_response.c jk_jni_worker.c
jk_lb_worker.c jk_logger_file.c jk_uriMap.c
jk_workerEnv.c
  Log:
  Use the new interface to maps.
  
  Revision  ChangesPath
  1.9   +12 -5 jakarta-tomcat-connectors/jk/native2/common/jk_ajp14_worker.c
  
  Index: jk_ajp14_worker.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_ajp14_worker.c,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- jk_ajp14_worker.c 2001/12/13 18:49:01 1.8
  +++ jk_ajp14_worker.c 2001/12/14 07:12:42 1.9
  @@ -161,7 +161,8 @@
   int proto=AJP14_PROTO;
   
   aw = _this;
  -secret_key = map_getStrProp( props, "worker", aw->name, "secretkey", NULL );
  +secret_key = jk_map_getStrProp( we->env, props,
  +"worker", aw->name, "secretkey", NULL );
   
   if ((!secret_key) || (!strlen(secret_key))) {
   proto=AJP13_PROTO;
  @@ -418,11 +419,17 @@
   
   w= e->worker;
   
  +l->jkLog(l, JK_LOG_INFO, "ajp14.done() before reset pool %p\n",
  + e->cPool );
   if( e->cPool != NULL ) 
   e->cPool->reset(e->cPool);
  +l->jkLog(l, JK_LOG_INFO, "ajp14.done() after reset pool %p\n",
  + e->cPool );
   
   if (w->endpointCache != NULL ) {
   int err=0;
  +l->jkLog(l, JK_LOG_INFO, "ajp14.done() before return to pool %s\n",
  + w->name );
   
   err=w->endpointCache->put( w->endpointCache, e );
   if( err==JK_TRUE ) {
  @@ -507,8 +514,8 @@
   int proto=AJP14_PROTO;
   int cache_sz;
   
  -secret_key = map_getStrProp( props, "worker", _this->name,
  - "secretkey", NULL );
  +secret_key = jk_map_getStrProp( we->env, props,
  +"worker", _this->name, "secretkey", NULL );
   
   if( secret_key==NULL ) {
   proto=AJP13_PROTO;
  @@ -521,9 +528,9 @@
   
   
   /* start the connection cache */
  -cache_sz = map_getIntProp( props, "worker", _this->name, "cachesize",
  +cache_sz=jk_map_getIntProp(we->env, props,
  +   "worker", _this->name, "cachesize",
  JK_OBJCACHE_DEFAULT_SZ );
  -
   if (cache_sz > 0) {
   int err;
   _this->endpointCache=jk_objCache_create( _this->pool, l );
  
  
  
  1.9   +9 -3  jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c
  
  Index: jk_channel_socket.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- jk_channel_socket.c   2001/12/13 18:49:01 1.8
  +++ jk_channel_socket.c   2001/12/14 07:12:42 1.9
  @@ -156,9 +156,15 @@
   char *host=socketInfo->host;
   short port=socketInfo->port;
   struct sockaddr_in *rc=&socketInfo->addr;
  -
  -port = map_getIntProp( props, "worker", worker_name, "port", port );
  -host = map_getStrProp( props, "worker", worker_name, "host", host);
  +jk_workerEnv_t *workerEnv=worker->workerEnv;
  +char *tmp;
  +
  +host = jk_map_getStrProp( NULL, props,
  +  "worker", worker_name, "host", host);
  +tmp = jk_map_getStrProp( NULL, props,
  +  "worker", worker_name, "port", NULL );
  +if( tmp != NULL )
  +port=jk_map_str2int( NULL, tmp);
   
   _this->worker=worker;
   _this->properties=props;
  
  
  
  1.6   +4 -3  jakarta-tomcat-connectors/jk/native2/common/jk_env.c
  
  Index: jk_env.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_env.c,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jk_env.c  2001/12/12 23:36:01 1.5
  +++ jk_env.c  2001/12/14 07:12:42 1.6
  @@ -101,7 +101,8 @@
 }
   
 /** XXX add check for the type */
  -  result=(jk_env_objectFactory_t)map_get( env->_registry, typeName, NULL );
  +  result=(jk_env_objectFactory_t)env->_registry->get( env, env->_registry,
  +  typeName);
 free( typeName );
 return result;
   }
  @@ -146,7 +147,7 @@
 strcpy(typeName, type );
 strcat( typeName, "/" );
 strcat( typeName, name );
  -  map_put( env->_registry, typeName, fact, &old );
  +  env->_registry->put( env, env->_registry, typeName, fact, &old );
   }
   
   static void jk_env_initEnv( jk_env_t *env, char *id ) {
  @@

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

[costin]

costin  01/12/13 23:11:42

  Added:   jk/native2/server/apache2 jk_map_aprtable.c
  Log:
  The map implementation using apr_table.
  
  One problem is that apr_table supports only string values. We use
  string values for most of the stuff, but we need void * for uriMap.
  
  But in uriMap we should better use hashtable - and maybe we shuld have
  2 interfaces ?
  
  For now aprtable will be used only for headers/env where we know
  we only have strings, and the 'original' jk_map will continue to
  be used.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_map_aprtable.c
  
  Index: jk_map_aprtable.c
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   *  Copyright (c) 1999-2001 The Apache Software Foundation.  *
   *   All rights reserved.*
   *   *
   * = *
   *   *
   * Redistribution and use in source and binary forms,  with or without modi- *
   * fication, are permitted provided that the following conditions are met:   *
   *   *
   * 1. Redistributions of source code  must retain the above copyright notice *
   *notice, this list of conditions and the following disclaimer.  *
   *   *
   * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
   *notice,  this list of conditions  and the following  disclaimer in the *
   *documentation and/or other materials provided with the distribution.   *
   *   *
   * 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 ."  *
   *   *
   *Alternately, this acknowlegement may appear in the software itself, if *
   *and wherever such third-party acknowlegements normally appear. *
   *   *
   * 4. The names  "The  Jakarta  Project",  "Jk",  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 Software Foundation.*
   *   *
   * 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 indivi- *
   * duals on behalf of the  Apache Soft

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

[costin]

costin  01/12/13 23:09:31

  Modified:jk/native2/common jk_map.c
  Log:
  The implementation change to support the new interface.
  
  Revision  ChangesPath
  1.7   +379 -354  jakarta-tomcat-connectors/jk/native2/common/jk_map.c
  
  Index: jk_map.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_map.c,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- jk_map.c  2001/12/12 21:56:43 1.6
  +++ jk_map.c  2001/12/14 07:09:31 1.7
  @@ -58,7 +58,7 @@
   /***
* Description: General purpose map object *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.6 $   *
  + * Version: $Revision: 1.7 $   *
***/
   
   #include "jk_global.h"
  @@ -69,132 +69,241 @@
   #define CAPACITY_INC_SIZE (50)
   #define LENGTH_OF_LINE(1024)
   
  -struct jk_map {
  -jk_pool_t *pool;
  +typedef struct jk_map_private {
  +char **names;
  +void **values;
  +
  +int capacity;
  +int size;
  +} jk_map_private_t;
   
  -const char **names;
  -const void **values;
  -
  -unsigned capacity;
  -unsigned size;
  -};
  -
  +static int jk_map_default_realloc(jk_map_t *m);
   static void trim_prp_comment(char *prp);
   static int trim(char *s);
  -static int map_realloc(jk_map_t *m);
   
  -int map_alloc(jk_map_t **m, jk_pool_t *pool )
  +static void *jk_map_default_get(jk_env_t *env, jk_map_t *m,
  +const char *name)
   {
  -jk_map_t *_this;
  +int i;
  +jk_map_private_t *mPriv;
  +
  +if(name==NULL )
  +return NULL;
  +mPriv=(jk_map_private_t *)m->_private;
   
  -if( m== NULL )
  +for(i = 0 ; i < mPriv->size ; i++) {
  +if(0 == strcmp(mPriv->names[i], name)) {
  +return  mPriv->values[i];
  +}
  +}
  +return NULL;
  +}
  +
  +
  +static int jk_map_default_put(jk_env_t *env, jk_map_t *m,
  +  const char *name, void *value,
  +  void **old)
  +{
  +int rc = JK_FALSE;
  +int i;
  +jk_map_private_t *mPriv;
  +
  +if( name==NULL ) 
   return JK_FALSE;
  +
  +mPriv=(jk_map_private_t *)m->_private;
   
  -_this=(jk_map_t *)pool->alloc(pool, sizeof(jk_map_t));
  -*m=_this;
  +for(i = 0 ; i < mPriv->size ; i++) {
  +if(0 == strcmp(mPriv->names[i], name)) {
  +break;
  +}
  +}
   
  -if( _this == NULL )
  -return JK_FALSE;
  +/* Old value found */
  +if(i < mPriv->size) {
  +if( old!=NULL )
  +*old = (void *) mPriv->values[i]; /* DIRTY */
  +mPriv->values[i] = value;
  +return JK_TRUE;
  +}
   
  -_this->pool = pool;
  +jk_map_default_realloc(m);
   
  -_this->capacity = 0;
  -_this->size = 0;
  -_this->names= NULL;
  -_this->values   = NULL;
  +if(mPriv->size < mPriv->capacity) {
  +mPriv->values[mPriv->size] = value;
  +/* XXX this is wrong - either we take ownership and copy both
  +   name and value,
  +   or none. The caller should do that if he needs !
  +*/
  +/* mPriv->names[mPriv->size] = m->pool->pstrdup(m->pool, name); */
  +mPriv->names[mPriv->size] =  name; 
  +mPriv->size ++;
  +rc = JK_TRUE;
  +}
  +return rc;
  +}
   
  -return JK_TRUE;
  +static int jk_map_default_size(jk_env_t *env, jk_map_t *m)
  +{
  +jk_map_private_t *mPriv;
  +
  +/* assert(m!=NULL) -- we call it via m->... */
  +mPriv=(jk_map_private_t *)m->_private;
  +return mPriv->size;
   }
   
  -int map_free(jk_map_t **m)
  +static char *jk_map_default_nameAt(jk_env_t *env, jk_map_t *m,
  +   int idex)
   {
  -int rc = JK_FALSE;
  +jk_map_private_t *mPriv;
   
  -if(m && *m) {
  -(*m)->pool->close((*m)->pool);
  -rc = JK_TRUE;
  -/*  free(*m); */
  -*m = NULL;
  -}
  -return rc;
  +mPriv=(jk_map_private_t *)m->_private;
  +
  +if(idex < 0 || idex > mPriv->size ) 
  +return NULL;
  +
  +return (char *)mPriv->names[idex]; 
   }
   
  -void *map_get(jk_map_t *m,
  -  const char *name,
  -  const void *def)
  -{
  -const void *rc = (void *)def;
  -
  -if(m && name) {
  -unsigned i;
  -for(i = 0 ; i < m->size ; i++) {
  -if(0 == strcmp(m->names[i], name)) {
  -rc = m->values[i];
  -break;
  -}
  -}
  -}
  +static 

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_endpoint.h jk_env.h jk_uriMap.h jk_webapp.h jk_worker.h jk_workerEnv.h

[costin]

costin  01/12/13 23:09:01

  Modified:jk/native2/include jk_endpoint.h jk_env.h jk_uriMap.h
jk_webapp.h jk_worker.h jk_workerEnv.h
  Log:
  Few changes to get it to compile.
  
  Using typedef'ed names is very strange in .h, I had to replace some
  with struct - the order and how the .h files are included seem to play
  a role. Probably there is a better solution, but I'm not a C programmer.
  
  Revision  ChangesPath
  1.7   +5 -3  jakarta-tomcat-connectors/jk/native2/include/jk_endpoint.h
  
  Index: jk_endpoint.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_endpoint.h,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- jk_endpoint.h 2001/12/13 19:06:11 1.6
  +++ jk_endpoint.h 2001/12/14 07:09:01 1.7
  @@ -61,7 +61,7 @@
* Author:  Gal Shachor <[EMAIL PROTECTED]>   
* Author:  Dan Milstein <[EMAIL PROTECTED]>
* Author:  Henri Gomez <[EMAIL PROTECTED]>   
  - * Version: $Revision: 1.6 $  
  + * Version: $Revision: 1.7 $  
***/
   
   #ifndef JK_ENDPOINT_H
  @@ -80,6 +80,8 @@
   
   struct jk_endpoint;
   struct jk_ws_service;
  +struct jk_logger;
  +struct jk_map;
   typedef struct jk_endpoint   jk_endpoint_t;
   
   /*
  @@ -177,7 +179,7 @@
*/
   int (JK_METHOD *service)(jk_endpoint_t *e, 
struct jk_ws_service *s,
  - jk_logger_t *l,
  + struct jk_logger *l,
int *is_recoverable_error);
   
   /*
  @@ -194,7 +196,7 @@
* worker.
*/
   int (JK_METHOD *done)(jk_endpoint_t **p,
  -  jk_logger_t *l);
  +  struct jk_logger *l);
   };
   
   #ifdef __cplusplus
  
  
  
  1.3   +4 -2  jakarta-tomcat-connectors/jk/native2/include/jk_env.h
  
  Index: jk_env.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_env.h,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- jk_env.h  2001/12/06 22:48:49 1.2
  +++ jk_env.h  2001/12/14 07:09:01 1.3
  @@ -82,6 +82,8 @@
*/
   struct jk_pool;
   struct jk_env;
  +struct jk_logger;
  +struct jk_map;
   typedef struct jk_env jk_env_t;
   
   /**
  @@ -121,7 +123,7 @@
*  the other methods parameters.  
*/
   struct jk_env {
  -jk_logger_t *logger;
  +struct jk_logger *logger;
   jk_pool_t   *globalPool; 
   
   /** Global properties ( similar with System properties in java)
  @@ -158,7 +160,7 @@
  char *factorySymbol);
   
   /* private */
  -jk_map_t *_registry;
  +struct jk_map *_registry;
   
   };
   
  
  
  
  1.6   +3 -2  jakarta-tomcat-connectors/jk/native2/include/jk_uriMap.h
  
  Index: jk_uriMap.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_uriMap.h,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jk_uriMap.h   2001/12/06 22:48:49 1.5
  +++ jk_uriMap.h   2001/12/14 07:09:01 1.6
  @@ -79,15 +79,16 @@
   #define JK_URIMAP_H
   
   #include "jk_global.h"
  -#include "jk_map.h"
   #include "jk_logger.h"
   #include "jk_uriEnv.h"
  +#include "jk_map.h"
   
   #ifdef __cplusplus
   extern "C" {
   #endif /* __cplusplus */
   
   struct jk_uriMap;
  +struct jk_map;
   typedef struct jk_uriMap jk_uriMap_t;
   
   struct jk_uriMap {
  @@ -105,7 +106,7 @@
   */
   int (*init)( jk_uriMap_t *_this,
struct jk_workerEnv *workerEnv,
  - jk_map_t *init_data );
  + struct jk_map *init_data );
   
   void (*destroy)( jk_uriMap_t *_this );
   
  
  
  
  1.2   +3 -2  jakarta-tomcat-connectors/jk/native2/include/jk_webapp.h
  
  Index: jk_webapp.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_webapp.h,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jk_webapp.h   2001/12/06 22:43:29 1.1
  +++ jk_webapp.h   2001/12/14 07:09:01 1.2
  @@ -81,6 +81,7 @@
   struct jk_env;
   struct jk_uri_worker_map;
   struct jk_map;
  +struct jk_logger;
   
   struct jk_webapp;
   typedef struct jk_webapp jk_webapp_t;
  @@ -137,7 +138,7 @@
   
   /** Different apps can have different loggers.
*/
  -jk_logger_t *l;
  +struct jk_logger *l;
   
   

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

[costin]

costin  01/12/13 23:07:11

  Modified:jk/native2/include jk_map.h
  Log:
  That was a bit more difficult, but seems to be fine.
  
  The idea is the same as in pools - use the native mechanism if possible,
  if not use the default impl.
  
  This change will allow the use of apr_table and other map implementations.
  It would also let us plug apr_hash. But more important, in jk_service
  we can avoid copying the headers and use the native representation and
  a wrappers. And the same will work for all servers ( if someone implements
  the wrapper ).
  
  I started to use jk_env as first param, not used for now but it's important
  to get it in the api before it's frozen.
  
  Revision  ChangesPath
  1.4   +96 -70jakarta-tomcat-connectors/jk/native2/include/jk_map.h
  
  Index: jk_map.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_map.h,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jk_map.h  2001/12/06 22:48:49 1.3
  +++ jk_map.h  2001/12/14 07:07:11 1.4
  @@ -58,13 +58,14 @@
   /***
* Description: Map object header file *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.3 $   *
  + * Version: $Revision: 1.4 $   *
***/
   
   #ifndef JK_MAP_H
   #define JK_MAP_H
   
   #include "jk_pool.h"
  +#include "jk_env.h"
   #include "jk_logger.h"
   
   #ifdef __cplusplus
  @@ -74,94 +75,119 @@
   struct jk_logger;
   struct jk_pool;
   struct jk_map;
  +struct jk_env;
   typedef struct jk_map jk_map_t;
   
  -int map_alloc(jk_map_t **m, struct jk_pool *pool);
  +/** Map interface. This include only the basic operations, and
  + *   supports both name and index access.
  + */
  +struct jk_map {
  +
  +void *(*get)(struct jk_env *env, struct jk_map *_this,
  + const char *name);
  +
  +int (*put)(struct jk_env *env, struct jk_map *_this,
  +   const char *name, void *value,
  +   void **oldValue);
  +
  +/*  int (*add)(struct jk_env *env, struct jk_map *_this, */
  +/*   const char *name, void *value ); */
  +
  +/* Similar with apr_table, elts can be accessed by id
  + */
  +
  +int (*size)(struct jk_env *env, struct jk_map *_this);
  +
  +char *(*nameAt)(struct jk_env *env, struct jk_map *m,
  +int pos);
  +
  +void *(*valueAt)(struct jk_env *env, struct jk_map *m,
  + int pos);
  +
  +/* Admin operations */
  +void (*init)(struct jk_env *env, struct jk_map *m,
  + int initialSize, void *wrappedNativeObj);
  +
  +
  +/* Empty the map, remove all values ( but it can keep
  +   allocated storage for [] )
  +*/
  +void (*clear)(struct jk_env *env, struct jk_map *m);
  +
  +struct jk_pool *pool;
  +void *_private;
  +};
   
  -int map_free(jk_map_t **m);
  +int jk_map_default_create(struct jk_env *env, jk_map_t **m, 
  +  struct jk_pool *pool); 
   
  -int map_open(jk_map_t *m);
  +/* int map_open(jk_env *env, jk_map_t *m); */
   
  -int map_close(jk_map_t *m);
   
  -void *map_get(jk_map_t *m,
  -  const char *name,
  -  const void *def);
  +
  +/* Additional functions that operate on maps. They are implemented
  + *  in jk_map.c, togheter with the 'default' jk map, but should operate
  + *  on any map.
  + */
  +
  +char *jk_map_getString(struct jk_env *env, jk_map_t *m,
  +   const char *name, char *def);
  +
  +/** Get a string property, using the worker's style
  +for properties.
  +Example worker.ajp13.host=localhost.
  +*/
  +char *jk_map_getStrProp(struct jk_env *env, jk_map_t *m,
  +const char *objType, const char *objName,
  +const char *pname, char *def);
  +
  +int jk_map_getIntProp(struct jk_env *env, jk_map_t *m,
  +  const char *objType, const char *objName,
  +  const char *pname,
  +  int def);
   
  -int map_get_int(jk_map_t *m,
  -const char *name,
  -int def);
  +/** Add all the values from src into dst. Use dst's pool
  + */
  +int jk_map_append(struct jk_env *env, jk_map_t * dst,
  +  jk_map_t * src );
   
  -double map_get_double(jk_map_t *m,
  -  const char *name,
  -  double def);
  +/* == Manipulating values   == */
   
  -char *map_get_string(jk_map_t *m,
  - const char *name,
  - const char *def);

Re: Configuring Multiple Tomcat JVMs with Apache - Load Balancing

[Jeff Turner]

On Thu, Dec 13, 2001 at 06:14:06PM -0800, Vijai Misra wrote:
> Hi,
> 
> I'm trying to Configure Multiple Tomcat JVMs with Apache to distribute load
> between various AppServers. Apparently, load balancing with Tomcat is not
> widely published on the internet.

.. which is sad, because it's so cool :) You can have as much redundancy
in your apps as needed. If one JVM dies, the others transparently take
over. I'm looking forward to when mod_webapp gets this functionality.

> I figured someone might be able to point me to the right direction so I can
> make this architecture work.

Try asking on the tomcat-user list, where I and others can help without
perpetuating the off-topicness.

--Jeff

> Thanks,
> VJ
> Sr. Consultant
> TechSpan, Inc.
> Email: [EMAIL PROTECTED]
> http://www.geocities.com/vijaimisra

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

cvs commit: jakarta-tomcat-4.0/tester/web/golden JspInclude01.txt JspInclude01a.txt JspInclude02.txt JspInclude02a.txt

[craigmcc]

craigmcc01/12/13 21:24:02

  Modified:tester/src/bin tester.xml
   tester/src/tester/org/apache/tester Include00.java
  Added:   tester/web JspForward01.jsp JspForward01a.jsp
JspInclude01.jsp JspInclude01a.jsp JspInclude02.jsp
JspInclude02a.jsp
   tester/web/golden JspInclude01.txt JspInclude01a.txt
JspInclude02.txt JspInclude02a.txt
  Log:
  Add unit tests for RequestDispatcher.include() for all combinations of:
  * Servlet or JSP includer
  * Servlet or JSP includee
  * Flush or no-flush before include
  
  Currently, the RequestDispatcher implementation has a bug (no output in
  the response for the include or anything after it returns) whenever an
  include is performed after a flush (either because an including servlet
  called response.flushBuffer(), or because an including JSP page is
  exectuing a ).  This manifests itself as
  failures on the corresponding tests in the "Jsp" and "RequestDispatcher"
  targets.
  
  I suspect this bug was introduced during the recent refactorings for error
  page handling -- alas, our unit tests did not catch it :-(  I've looked
  for a while and can't find it yet.  Any ideas?
  
  Revision  ChangesPath
  1.76  +79 -11jakarta-tomcat-4.0/tester/src/bin/tester.xml
  
  Index: tester.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
  retrieving revision 1.75
  retrieving revision 1.76
  diff -u -r1.75 -r1.76
  --- tester.xml2001/12/12 22:34:20 1.75
  +++ tester.xml2001/12/14 05:24:02 1.76
  @@ -610,6 +610,30 @@
request="${context.path}/JspDoc01.jsp" debug="${debug}"
 golden="${golden.path}/JspDoc01.txt"/>
   
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
 
   
   
  @@ -655,7 +679,7 @@
   
 
   
  -
  +
   
   
   
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
  
  
  
  1.2   +11 -1 
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Include00.java
  
  Index: Include00.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Include00.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Include00.java2001/05/03 23:06:31 1.1
  +++ Include00.java2001/12/14 05:24:02 1.2
  @@ -66,7 +66,7 @@
* Exercise basic including functionality.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.1 $ $Date: 2001/05/03 23:06:31 $
  + * @version $Revision: 1.2 $ $Date: 2001/12/14 05:24:02 $
*/
   
   public class Include00 extends HttpServlet {
  @@ -85,6 +85,9 @@
   if (path == null)
   path = "/Include00a";
   
  +// Acquire the flush flag
  +boolean flush = "true".equals(request.getParameter("flush"));
  +
   // Create a request dispatcher and call include() on it
   RequestDispatcher rd = null;
   if (path.startsWith("!"))
  @@ -94,6 +97,13 @@
   if (rd == null) {
   sb.append(" No RequestDispatcher returned/");
   } else {
  +if (flush) {
  +try {
  +response.flushBuffer();
  +} catch (IOException e) {
  +sb.append(" Flush threw IOException/");
  +}
  +}
   if (sb.length() < 1)
   rd.include(request, response);
   }
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/JspForward01.jsp
  
  Index: JspForward01.jsp
  ===
  <%@ page contentType="text/plain" %>
  JspForward01 FAILED - Content from forwarded-to page not included
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/JspForward01a.jsp
  
  Index: JspForward01a.jsp
  ===
  <%@ page contentType="text/plain" %>JspForward01a PASSED
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/JspInclude01.jsp
  
  Index: JspInclude01.jsp
  ===
  <%@ page contentType="text/plain" %>This is before the include
  " flush="true"/>
  This is after the include
  
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/JspInclude01a.jsp
  
  Index: JspInclude01a.jsp
  ===
  <%@ page contentType="text/plain" %>This is the include
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/JspInclude02.jsp
  
  Index: JspIncl

Re: AJP Todo

[Bill Barker]

The ${Server}Config files are about as good as I can get them.  Any
remaining improvements would require someone that knows more about Catalina
than I do.  The main improvement that I can think of would require an API
change in Catalina, but this configuration method will likely be obsolete by
the time 4.1 rolls out (thanks to Costin and Henri).


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

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/config BaseJkConfig.java

[billbarker]

billbarker01/12/13 20:27:05

  Modified:jk/java/org/apache/ajp/tomcat4/config BaseJkConfig.java
  Log:
  Remove sub-config from Server Listener, since it doesn't work with Catalina.
  
  Revision  ChangesPath
  1.3   +3 -10 
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/config/BaseJkConfig.java
  
  Index: BaseJkConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/config/BaseJkConfig.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- BaseJkConfig.java 2001/12/11 03:52:35 1.2
  +++ BaseJkConfig.java 2001/12/14 04:27:05 1.3
  @@ -120,7 +120,7 @@
   @author Costin Manolache
   @author Larry Isaacs
   @author Bill Barker
  - @version $Revision: 1.2 $
  + @version $Revision: 1.3 $
*/
   public class BaseJkConfig  implements LifecycleListener {
   protected int debug=0;
  @@ -185,16 +185,8 @@
if( ! generateJkHead(mod_jk) )
return;
generateSSLConfig(mod_jk);
  - }
  - Service [] services = svr.findServices();
  - for(int ii=0; ii < services.length; ii++) {
  - Container  con = services[ii].getContainer();
  - if( con instanceof Engine ) {
  - executeEngine((Engine)con, mod_jk);
  - }
  - }
  - if( ! append )
generateJkTail(mod_jk);
  + }
   }
   
   /** Generate SSL options
  @@ -419,6 +411,7 @@
   return docBase;
   }
   
  +// -- Grabbed from FileUtil -
   public static File getConfigFile( File base, File configDir, String defaultF )
   {
   if( base==null )
  
  
  

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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util JavaGeneratorTool.java

[billbarker]

billbarker01/12/13 19:55:11

  Modified:src/share/org/apache/tomcat/util JavaGeneratorTool.java
  Log:
  Remove debugging line that I had enabled to track this down.
  
  Revision  ChangesPath
  1.4   +1 -1  
jakarta-tomcat/src/share/org/apache/tomcat/util/JavaGeneratorTool.java
  
  Index: JavaGeneratorTool.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/JavaGeneratorTool.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- JavaGeneratorTool.java2001/12/14 03:47:26 1.3
  +++ JavaGeneratorTool.java2001/12/14 03:55:11 1.4
  @@ -71,7 +71,7 @@
   if(index == -1 ) continue;
   while (index != -1) {
int endIdx=index+keywords[i].length();
  - System.out.println("XXX " + s + " " + index + " " + 
endIdx );
  + //  System.out.println("XXX " + s + " " + index + 
" " + endIdx );
// Is it a full word ?
if( index>0 && s.charAt( index-1 ) != '/' ) {
index = s.indexOf(keywords[i],index+3);
  
  
  

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

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

[billbarker]

billbarker01/12/13 19:50:21

  Modified:.RELEASE-NOTES-3.3.1.txt
  Log:
  Document Mangler fix.
  
  Revision  ChangesPath
  1.14  +3 -1  jakarta-tomcat/RELEASE-NOTES-3.3.1.txt
  
  Index: RELEASE-NOTES-3.3.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.1.txt,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- RELEASE-NOTES-3.3.1.txt   2001/12/13 04:26:09 1.13
  +++ RELEASE-NOTES-3.3.1.txt   2001/12/14 03:50:20 1.14
  @@ -3,7 +3,7 @@
Release Notes
=
   
  -$Id: RELEASE-NOTES-3.3.1.txt,v 1.13 2001/12/13 04:26:09 billbarker Exp $
  +$Id: RELEASE-NOTES-3.3.1.txt,v 1.14 2001/12/14 03:50:20 billbarker Exp $
   
   
   This document describes the changes that have been made since the
  @@ -114,6 +114,8 @@
   
   5390  Fixed the behavior of LoadOnStartup servlets when the servlet is
 actually a JSP page.
  +
  +5365  Fixed the JasperMangler to handle Java reserved words correctly.
   
   Documentation:
   
  
  
  

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

DO NOT REPLY [Bug 5365] - JSPs cannot be compiled if their working path includes reserved word

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

JSPs cannot be compiled if their working path includes reserved word

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-12-13 19:48 ---
This is now fixed in the CVS HEAD, and will appear in the next nightly.

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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util JavaGeneratorTool.java

[billbarker]

billbarker01/12/13 19:47:26

  Modified:src/share/org/apache/tomcat/util JavaGeneratorTool.java
  Log:
  Fix indexing problem on Mangler.
  
  Just a classic 0/1 based indexing problem.
  
  Fix for bug #5365
  Reported by: Cory [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.3   +2 -2  
jakarta-tomcat/src/share/org/apache/tomcat/util/JavaGeneratorTool.java
  
  Index: JavaGeneratorTool.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/JavaGeneratorTool.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JavaGeneratorTool.java2001/08/03 02:51:44 1.2
  +++ JavaGeneratorTool.java2001/12/14 03:47:26 1.3
  @@ -71,14 +71,14 @@
   if(index == -1 ) continue;
   while (index != -1) {
int endIdx=index+keywords[i].length();
  - //  System.out.println("XXX " + s + " " + index + " " + 
endIdx );
  + System.out.println("XXX " + s + " " + index + " " + 
endIdx );
// Is it a full word ?
if( index>0 && s.charAt( index-1 ) != '/' ) {
index = s.indexOf(keywords[i],index+3);
continue;
}

  - if( (s.length()>endIdx+1) && s.charAt( endIdx+1 ) != '/' ) {
  + if( (s.length()>=endIdx) && s.charAt( endIdx ) != '/' ) {
index = s.indexOf(keywords[i],index+3);
continue;
}
  
  
  

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

Re: Jk2: missing Makefiles/configure?

[costinm]

On Thu, 13 Dec 2001, GAWLAS,JULIUS (HP-Cupertino,ex1) wrote:

> Hi,
>
> I wanted to build jk2, but I could not find neither configure nor
> makefiles in jk/native2.
>
> Could you give me some pointers?

Surprise :-)

Just type ant and see what happens. ( you may need to type 'ant jkant' in
j-t-c/jk first ).

I'll create a makefile, but for now ant is the only tool I use. Please
give it a try and let me know if it doesn't work for you. It uses libtool
( by default - it also supports msvc and other compilers ). You should
also be able to compile using apxs.

( we want jk2 to start using apr, so configure will not be needed - for
release we'll have makefiles and ant, if people like the idea )

Costin



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

Configuring Multiple Tomcat JVMs with Apache - Load Balancing

[Vijai Misra]

Hi,

I'm trying to Configure Multiple Tomcat JVMs with Apache to distribute load
between various AppServers. Apparently, load balancing with Tomcat is not
widely published on the internet.
I figured someone might be able to point me to the right direction so I can
make this architecture work.

Thanks,
VJ
Sr. Consultant
TechSpan, Inc.
Email: [EMAIL PROTECTED]
http://www.geocities.com/vijaimisra



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

cvs commit: jakarta-tomcat-connectors/jk/native/iis jk_isapi_plugin.c

[larryi]

larryi  01/12/13 17:29:26

  Modified:jk/native/iis jk_isapi_plugin.c
  Log:
  Copy the worker_mount_file properties map to a second properties map,
  leaving out the non-mapping entries.  Assume they were string substitutions.
  This allows it to work with the uriworkermap.properties file generated by
  Tomcat 3.3's IISConfig module.
  
  Revision  ChangesPath
  1.12  +40 -19jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- jk_isapi_plugin.c 2001/12/13 22:31:30 1.11
  +++ jk_isapi_plugin.c 2001/12/14 01:29:26 1.12
  @@ -60,7 +60,7 @@
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
* Author:  Larry Isaacs <[EMAIL PROTECTED]>   *
* Author:  Ignacio J. Ortega <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.11 $   *
  + * Version: $Revision: 1.12 $   *
***/
   
   // This define is needed to include wincrypt,h, needed to get client certificates
  @@ -867,23 +867,44 @@
   if (!jk_open_file_logger(&logger, log_file, log_level)) {
   logger = NULL;
   }
  - /* Logging the initialization type: registry or properties file in 
virtual dir
  - */
  - if (using_ini_file) {
  -  jk_log(logger, JK_LOG_DEBUG, "Using ini file %s.\n", 
ini_file_name);
  - } else {
  -  jk_log(logger, JK_LOG_DEBUG, "Using registry.\n");
  - }
  - jk_log(logger, JK_LOG_DEBUG, "Using log file %s.\n", log_file);
  - jk_log(logger, JK_LOG_DEBUG, "Using log level %d.\n", log_level);
  - jk_log(logger, JK_LOG_DEBUG, "Using extension uri %s.\n", extension_uri);
  - jk_log(logger, JK_LOG_DEBUG, "Using worker file %s.\n", worker_file);
  - jk_log(logger, JK_LOG_DEBUG, "Using worker mount file %s.\n", 
worker_mount_file);
  +/* Logging the initialization type: registry or properties file in virtual dir
  +*/
  +if (using_ini_file) {
  +jk_log(logger, JK_LOG_DEBUG, "Using ini file %s.\n", ini_file_name);
  +} else {
  +jk_log(logger, JK_LOG_DEBUG, "Using registry.\n");
  +}
  +jk_log(logger, JK_LOG_DEBUG, "Using log file %s.\n", log_file);
  +jk_log(logger, JK_LOG_DEBUG, "Using log level %d.\n", log_level);
  +jk_log(logger, JK_LOG_DEBUG, "Using extension uri %s.\n", extension_uri);
  +jk_log(logger, JK_LOG_DEBUG, "Using worker file %s.\n", worker_file);
  +jk_log(logger, JK_LOG_DEBUG, "Using worker mount file %s.\n", 
worker_mount_file);
   
   if (map_alloc(&map)) {
   if (map_read_properties(map, worker_mount_file)) {
  -if (uri_worker_map_alloc(&uw_map, map, logger)) {
  -rc = JK_TRUE;
  +/* remove non-mapping entries (assume they were string substitutions) */
  +jk_map_t *map2;
  +if (map_alloc(&map2)) {
  +int sz,i;
  +void* old;
  +
  +sz = map_size(map);
  +for(i = 0; i < sz ; i++) {
  +char *name = map_name_at(map, i);
  +if ('/' == *name) {
  +map_put(map2, name, map_value_at(map, i), &old);
  +} else {
  +jk_log(logger, JK_LOG_DEBUG,
  +   "Ignoring worker mount file entry %s=%s.\n",
  +   name, map_value_at(map, i));
  +}
  +}
  +
  +if (uri_worker_map_alloc(&uw_map, map2, logger)) {
  +rc = JK_TRUE;
  +}
  +
  +map_free(&map2);
   }
   }
   map_free(&map);
  @@ -893,10 +914,10 @@
   rc = JK_FALSE;
   if (map_alloc(&map)) {
   if (map_read_properties(map, worker_file)) {
  - /* we add the URI->WORKER MAP since workers using 
AJP14 will feed it */
  +/* we add the URI->WORKER MAP since workers using AJP14 will feed 
it */
   
  - worker_env.uri_to_worker = uw_map;
  - worker_env.server_name = serverName;
  +worker_env.uri_to_worker = uw_map;
  +worker_env.server_name = serverName;
   
   if (wc_open(map, &worker_env, logger)) {
   rc = JK_TRUE;
  @@ -906,7 +927,7 @@
   }
   }
   
  - return rc;
  +return rc;
   }
   
   static int initialize_extension(void)
  
  
  

--
To unsubscribe

Jk2: missing Makefiles/configure?

[GAWLAS,JULIUS (HP-Cupertino,ex1)]

Hi,

I wanted to build jk2, but I could not find neither configure nor 
makefiles in jk/native2. 

Could you give me some pointers?

thanks
Julius

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

DO NOT REPLY [Bug 5422] - HTTP Headers not being cleared after form 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=5422

HTTP Headers not being cleared after form authentication

[EMAIL PROTECTED] changed:

   What|Removed |Added

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



--- Additional Comments From [EMAIL PROTECTED]  2001-12-13 16:11 ---
It would make sense that this would affect only FORM based login, because that
is the only case where Tomcat itself saves and replays the original request.  In
BASIC, the browser does that.

Your comments imply that you have a test case available.  Can you attach that to
this bug report?

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

DO NOT REPLY [Bug 5422] - HTTP Headers not being cleared after form 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=5422

HTTP Headers not being cleared after form authentication





--- Additional Comments From [EMAIL PROTECTED]  2001-12-13 15:51 ---
This bug does not appear to occur for BASIC authentication.  I have not tried 
other authentication types.

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

DO NOT REPLY [Bug 5422] New: - HTTP Headers not being cleared after form 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=5422

HTTP Headers not being cleared after form authentication

   Summary: HTTP Headers not being cleared after form authentication
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: All
   URL: http://members.optushome.com.au/bwalding/tomcat/header.z
ip
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When using FORM authentication (for realm), it appears that HTTP headers are 
not being reset as the page is redirected to target page (after authentication).

Process (tested against stock 4.0.1 tomcat install)
1. Create new webapp (eg header)
2. Unpack zip file listed in URL to webapp
http://members.optushome.com.au/bwalding/tomcat/header.zip
3. Go to http://localhost:8080/header/HeaderServlet (or appropriate spot if you 
aren't running against localhost)
4. You should be redirected to the login.html page (user/pass = tomcat/tomcat  
(default memory realm))
5. After that you should go to header display page.  Note the duplicates?
If you invalidate the session and re-enter the page, you will see the session 
id's are different.

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

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

[seguin]

seguin  01/12/13 15:32:54

  Modified:jk/java/org/apache/ajp RequestHandler.java
  Log:
  added check for and handling of empty packet in refillReadBuffer.  the
  empty packet signals the end of the stream from the web server to the
  serlvet container.
  
  Revision  ChangesPath
  1.8   +11 -0 
jakarta-tomcat-connectors/jk/java/org/apache/ajp/RequestHandler.java
  
  Index: RequestHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/RequestHandler.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- RequestHandler.java   2001/11/26 16:56:19 1.7
  +++ RequestHandler.java   2001/12/13 23:32:54 1.8
  @@ -677,6 +677,17 @@
throw new IOException();
}

  +// check for empty packet, which means end of stream
  +if (ch.inBuf.getLen() == 0) {
  +if (debug > 0) {
  +log("refillReadBuffer():  "
  ++ "received empty packet -> end of stream");
  +}
  +ch.blen = 0;
  +ch.pos = 0;
  +return false;
  +}
  +
ch.blen = ch.inBuf.peekInt();
ch.pos = 0;
ch.inBuf.getBytes(ch.bodyBuff);
  
  
  

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

[patch] o-a-jasper-JspC Just a refactoring of the class

[David Hoag]

Lots of changes, so here's the URL:

http://www.objectwave.com/patch.txt


- Dave

_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


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

RE: Proposal for a JSP to JSP Document (XML view of JSP) Converter

[Ragy Eleish]

My comments are below:

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 13, 2001 2:29 PM
> To: Tomcat Developers List
> Subject: Re: Proposal for a JSP to JSP Document (XML view of JSP)
> Converter
> 
> 
> A couple of ideas/options to think about:
> 
> * There is a converter of the sort you suggest in the 
> jakarta-watchdog-4.0
>   repository at Apache (in the org.apache.jspxml package 
> under src/tools).
>   This is used in Watchdog to make a copy of all the JSP-syntax test
>   pages into XML syntax, to check identical functionality in either
>   syntax.

- I took a look at the jakarta-watchdog-4.0 tool, it is a simple pattern
matcher (as they described) and isn't a real parser like Jasper. It have
several limitation and can't handle the conversion of HTML to XHTML.

> 
> * In JSP 1.2, there is the concept of a Validator that is fed (at
>   compile time) a view of the page in XML syntax, no matter which
>   syntax you started with.  In the "exapmles" web app, there is a
>   really simple Validator implementation that simply writes this
>   out to System.out -- you might be able to adapt this.

- I see the validation to happen on two steps, a compile time step and a
runtime step. The Validator concept is a great way handle the runtime step,
since it can verify the JSP algorithm's output. I didn't know how we could
do it thanks. On the other hand working in a project with 400+ JSPs it is
nice to be able to perform compile time validation ut saves alot of time.
Once the JSPs are in XML format compile time validation is easy.


> 
> Craig McClanahan
> 
> 
> On Thu, 13 Dec 2001, Ragy Eleish wrote:
> 
> > Date: Thu, 13 Dec 2001 13:09:24 -0800
> > From: Ragy Eleish <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: "'[EMAIL PROTECTED]'" 
> <[EMAIL PROTECTED]>
> > Subject: Proposal for a JSP to JSP Document (XML view of 
> JSP) Converter
> >
> > Hi,
> >
> > I would like to propose the following (I tried to be as 
> brief as possible):
> >
> > Proposal:
> > -
> > Write a tool based on the Jasper code line to convert 
> normal JSPs to the XML
> > view of JSPs (aka JSP Document). This tools should have a 
> two modes; the
> > first one to convert any JSP to XML view of JSP. The second 
> mode to convert
> > HTML+JSP to XHTML+JSP document, where it fixes all HTML 
> tags incorrectness
> > and convert them to XHTML transient format (like an enhanced Tidy).
> >
> > Reason:
> > 
> > JSP document has many benefits that include the ability to 
> apply XSLT on the
> > pages to statically transform the pages to a different 
> view. It could allow
> > some compile time checking of JSP page, which would save 
> development time
> > for JSP writers.
> > Therefore to enhance the JSP document adoption, I thought 
> that such a tool
> > would facilitate the migration to JSP documents. By 
> allowing existing
> > applications to convert their normal JSPs automatically 
> instead of the doing
> > that manually.
> >
> > Research:
> > --
> > I did investigate Jasper code and found it doesn't 
> implement a full fledged
> > parser, but it is written in a way to allow easy 
> modifications. I wrote a
> > prototype of the converter. The main difficulty is that 
> Jasper is not
> > written for customization, so factories may need to be added to it.
> >
> > Development:
> > ---
> > I am going to build this tool for my company's internal 
> use, and would be
> > actively maintaining it. We will perform QA on that tool 
> in-house. I would
> > be great to get
> >
> > Time Frame:
> > --
> > I expect the initial version of the tool to take 3 to 4 
> weeks max worth of
> > development time.
> >
> > Open Questions:
> > ---
> > - Should this tool be a forked from Jasper code line or 
> should Jasper be
> > modified to add customizations to it?
> > - Is that an acceptable proposal? If yes, who should I 
> contact to commit to
> > code to CVS (since I don't have a commit status)?
> >
> > Regards
> >
> > 
> __
> >  Ragy Eleish  [EMAIL PROTECTED]
> >  Team Lead 650-232-5825
> >  Comergent Technologies   http://www.comergent.com
> >  1201 Radio Road  Fortune Magazine's 25 Coolest 
> Companies 2001
> >  Redwood City, CA 94065   Crossroads 2001 A-List Award Winner
> >   Upside's Hot 100 Private 
> Companies Award 2000
> >   Cisco System's Supplier of the 
> Year Award 1999
> >
> >  Comergent Technologies, Inc. is a leading provider of sell-side
> >  business-to-business e-commerce software solutions that enable
> >  enterprises to engage in collaborative commerce, fully leveraging
> >
> > --
> > To unsubscribe, e-mail:   
> 
> > For additional commands, e-mail: 
> 

RE: [j-t-c] patch for jakarta-tomcat-connectors/jk/native/common/jk_a jp_common.c

[Kevin Seguin]

> 
> this patch fixes a problem when posting with more than about 
> 8K of data.  it
> seems that when the java side of the ajp connection has to 
> ask the webserver
> (jk) side for more data, it goes into an infinite loop 
> because the next
> chunk of data isn't actually sent.
> 
> i'm 97% sure about this patch, but since i don't know this 
> code as well as
> some, i'd like someone else to review it.
> 
> attached is the patch and a servlet (FileUpload.java) and a client
> (Upload2.java) that demonstrate the problem.
> 
> the client uses HTTPClient, which can be downloaded from
> http://www.innovation.ch/java/HTTPClient/.  incidentally, i 
> would have used
> the http client in jakarta-commons, if i could have figured 
> out how to post
> using an output stream :)
> 
> this same test fails on the java side of ajp using the ajp 
> stuff on the head
> in j-t-c/jk.  again, an infinite loop.  i haven't been able 
> to figure it out
> yet...  if somebody wants extra points ... ;)
> 

well, i'm pretty sure i figured out this one.
RequestHandler.refillReadBuffer() is missing the all important check for the
empty packet that signals the end of the stream :)

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

RE: [j-t-c] patch for jakarta-tomcat-connectors/jk/native/common/jk_a jp_common.c

[Kevin Seguin]

> > i'm 97% sure about this patch, but since i don't know this 
> code as well as
> > some, i'd like someone else to review it.
> 
> This seems to be the main problem we had so far with jk - 
> buffers beeing
> reused before they're ready. For jk2 we must make sure we have more
> control over that or allocate enough buffers.
> 

i think in this case it's the wrong buffer being used -- the post data is
being read into the reply buffer rather than into the post buffer that will
be sent to the java side.

> > this same test fails on the java side of ajp using the ajp 
> stuff on the head
> > in j-t-c/jk.  again, an infinite loop.  i haven't been able 
> to figure it out
> > yet...  if somebody wants extra points ... ;)
> 
> You fixed what branch :-) ?  I'll try to reproduce this.
> 

i haven't checked anything in yet because i'm not positive i'm right -- not
familiar enough with the code, don't want to break anything else! :)

-kevin.

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

Re: [j-t-c] patch for jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c

[costinm]

On Thu, 13 Dec 2001, Kevin Seguin wrote:

> i'm 97% sure about this patch, but since i don't know this code as well as
> some, i'd like someone else to review it.

This seems to be the main problem we had so far with jk - buffers beeing
reused before they're ready. For jk2 we must make sure we have more
control over that or allocate enough buffers.

> this same test fails on the java side of ajp using the ajp stuff on the head
> in j-t-c/jk.  again, an infinite loop.  i haven't been able to figure it out
> yet...  if somebody wants extra points ... ;)

You fixed what branch :-) ?  I'll try to reproduce this.

Costin


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

DO NOT REPLY [Bug 5413] - JspWriterImpl causes, under certain circumstances, an IllegalStateException when releasing the PageContext

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

JspWriterImpl causes, under certain circumstances, an IllegalStateException when 
releasing the PageContext

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2001-12-13 14:40 ---
Tested with latest nightly (Dec 13) The tests pass.

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

cvs commit: jakarta-tomcat-connectors/jk/native/iis jk_isapi_plugin.c

[seguin]

seguin  01/12/13 14:31:30

  Modified:jk/native/iis jk_isapi_plugin.c
  Log:
  added a semi-colon so this would build (not sure how/if it
  was building for anybody else...).
  
  Revision  ChangesPath
  1.11  +2 -2  jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- jk_isapi_plugin.c 2001/12/08 15:42:25 1.10
  +++ jk_isapi_plugin.c 2001/12/13 22:31:30 1.11
  @@ -60,7 +60,7 @@
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
* Author:  Larry Isaacs <[EMAIL PROTECTED]>   *
* Author:  Ignacio J. Ortega <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.10 $   *
  + * Version: $Revision: 1.11 $   *
***/
   
   // This define is needed to include wincrypt,h, needed to get client certificates
  @@ -528,7 +528,7 @@
   
   BOOL WINAPI GetFilterVersion(PHTTP_FILTER_VERSION pVer)
   {
  -ULONG http_filter_revision = HTTP_FILTER_REVISION 
  +ULONG http_filter_revision = HTTP_FILTER_REVISION;
   
   pVer->dwFilterVersion = pVer->dwServerFilterVersion;
   
  
  
  

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

Re: Proposal for a JSP to JSP Document (XML view of JSP) Converter

[Craig R. McClanahan]

A couple of ideas/options to think about:

* There is a converter of the sort you suggest in the jakarta-watchdog-4.0
  repository at Apache (in the org.apache.jspxml package under src/tools).
  This is used in Watchdog to make a copy of all the JSP-syntax test
  pages into XML syntax, to check identical functionality in either
  syntax.

* In JSP 1.2, there is the concept of a Validator that is fed (at
  compile time) a view of the page in XML syntax, no matter which
  syntax you started with.  In the "exapmles" web app, there is a
  really simple Validator implementation that simply writes this
  out to System.out -- you might be able to adapt this.

Craig McClanahan


On Thu, 13 Dec 2001, Ragy Eleish wrote:

> Date: Thu, 13 Dec 2001 13:09:24 -0800
> From: Ragy Eleish <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: Proposal for a JSP to JSP Document (XML view of JSP) Converter
>
> Hi,
>
> I would like to propose the following (I tried to be as brief as possible):
>
> Proposal:
> -
> Write a tool based on the Jasper code line to convert normal JSPs to the XML
> view of JSPs (aka JSP Document). This tools should have a two modes; the
> first one to convert any JSP to XML view of JSP. The second mode to convert
> HTML+JSP to XHTML+JSP document, where it fixes all HTML tags incorrectness
> and convert them to XHTML transient format (like an enhanced Tidy).
>
> Reason:
> 
> JSP document has many benefits that include the ability to apply XSLT on the
> pages to statically transform the pages to a different view. It could allow
> some compile time checking of JSP page, which would save development time
> for JSP writers.
> Therefore to enhance the JSP document adoption, I thought that such a tool
> would facilitate the migration to JSP documents. By allowing existing
> applications to convert their normal JSPs automatically instead of the doing
> that manually.
>
> Research:
> --
> I did investigate Jasper code and found it doesn't implement a full fledged
> parser, but it is written in a way to allow easy modifications. I wrote a
> prototype of the converter. The main difficulty is that Jasper is not
> written for customization, so factories may need to be added to it.
>
> Development:
> ---
> I am going to build this tool for my company's internal use, and would be
> actively maintaining it. We will perform QA on that tool in-house. I would
> be great to get
>
> Time Frame:
> --
> I expect the initial version of the tool to take 3 to 4 weeks max worth of
> development time.
>
> Open Questions:
> ---
> - Should this tool be a forked from Jasper code line or should Jasper be
> modified to add customizations to it?
> - Is that an acceptable proposal? If yes, who should I contact to commit to
> code to CVS (since I don't have a commit status)?
>
> Regards
>
> __
>  Ragy Eleish  [EMAIL PROTECTED]
>  Team Lead   650-232-5825
>  Comergent Technologies   http://www.comergent.com
>  1201 Radio Road  Fortune Magazine's 25 Coolest Companies 2001
>  Redwood City, CA 94065   Crossroads 2001 A-List Award Winner
>   Upside's Hot 100 Private Companies Award 2000
>   Cisco System's Supplier of the Year Award 1999
>
>  Comergent Technologies, Inc. is a leading provider of sell-side
>  business-to-business e-commerce software solutions that enable
>  enterprises to engage in collaborative commerce, fully leveraging
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

[j-t-c] patch for jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c

[Kevin Seguin]

this patch fixes a problem when posting with more than about 8K of data.  it
seems that when the java side of the ajp connection has to ask the webserver
(jk) side for more data, it goes into an infinite loop because the next
chunk of data isn't actually sent.

i'm 97% sure about this patch, but since i don't know this code as well as
some, i'd like someone else to review it.

attached is the patch and a servlet (FileUpload.java) and a client
(Upload2.java) that demonstrate the problem.

the client uses HTTPClient, which can be downloaded from
http://www.innovation.ch/java/HTTPClient/.  incidentally, i would have used
the http client in jakarta-commons, if i could have figured out how to post
using an output stream :)

this same test fails on the java side of ajp using the ajp stuff on the head
in j-t-c/jk.  again, an infinite loop.  i haven't been able to figure it out
yet...  if somebody wants extra points ... ;)

thanks,
-kevin.




jtc.jk.patch
Description: Binary data


Upload2.java
Description: Binary data


FileUpload.java
Description: Binary data

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

getOutputStream() or getWriter() within a JSP

[JULIEN,TIMOTHY (HP-NewJersey,ex2)]

According to the Servlet spec, I know that calling
response.getOutputStream() after response.getWriter() has been called is an
IllegalStateException, and vice versa.

I have a question about a related area in JSP 1.2, section 2.7:

"Initially, out is a new JspWriter object. This object may be different from
the
stream object returned from response.getWriter(), and may be considered to
be
interposed on the latter in order to implement buffering (see
Section JSP.2.10.1, "The page Directive"). This is the initial out object.
JSP
page authors are prohibited from writing directly to either the PrintWriter
or
OutputStream associated with the ServletResponse."

I am unsure about what actions the container needs to take to fullfill the
last sentence.  Does this mean:

1) The container should throw an Exception (IllegalState?) if the jsp calls
getOutputStream() or getWriter().
2) If a jsp calls getOutputStream() or getWriter(), any methods called on
those objects should be ignored by the container.
3) It is discouraged for page authors to do this. ( JSP Container does
nothing )

I think 1) is correct, but the spec is ambiguous.

As far as I can tell, if 1) is true, Tomcat has a bug.
If 2) is true I think Tomcat has a bug, but I'm not sure.
If 3) is true Tomcat has no bug.

Side Note: Tomcat does throw an Exception for getOutputStream() inside
'ed jsps, but not for getWriter().  This I also don't quite
understand.

thanks,
Tim Julien
HP Middleware

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

RE: Proposal for a JSP to JSP Document (XML view of JSP) Converter

[Ragy Eleish]

Thanks Costin,

The use of JTidy code could help, I found the license


---
/*
  HTML parser and pretty printer

  Copyright (c) 1998-2000 World Wide Web Consortium (Massachusetts
  Institute of Technology, Institut National de Recherche en
  Informatique et en Automatique, Keio University). All Rights
  Reserved.

  Contributing Author(s):

 Dave Raggett <[EMAIL PROTECTED]>
 Andy Quick <[EMAIL PROTECTED]> (translation to Java)

  The contributing author(s) would like to thank all those who
  helped with testing, bug fixes, and patience.  This wouldn't
  have been possible without all of you.

  COPYRIGHT NOTICE:
 
  This software and documentation is provided "as is," and
  the copyright holders and contributing author(s) make no
  representations or warranties, express or implied, including
  but not limited to, warranties of merchantability or fitness
  for any particular purpose or that the use of the software or
  documentation will not infringe any third party patents,
  copyrights, trademarks or other rights. 

  The copyright holders and contributing author(s) will not be
  liable for any direct, indirect, special or consequential damages
  arising out of any use of the software or documentation, even if
  advised of the possibility of such damage.

  Permission is hereby granted to use, copy, modify, and distribute
  this source code, or portions hereof, documentation and executables,
  for any purpose, without fee, subject to the following restrictions:

  1. The origin of this source code must not be misrepresented.
  2. Altered versions must be plainly marked as such and must
 not be misrepresented as being the original source.
  3. This Copyright notice may not be removed or altered from any
 source or altered source distribution.
 
  The copyright holders and contributing author(s) specifically
  permit, without fee, and encourage the use of this source code
  as a component for supporting the Hypertext Markup Language in
  commercial products. If you use this source code in a product,
  acknowledgment is not required but would be appreciated.
*/



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 13, 2001 1:50 PM
To: Tomcat Developers List
Subject: Re: Proposal for a JSP to JSP Document (XML view of JSP)
Converter


On Thu, 13 Dec 2001, Ragy Eleish wrote:

> Write a tool based on the Jasper code line to convert normal JSPs to the
XML
> view of JSPs (aka JSP Document). This tools should have a two modes; the
> first one to convert any JSP to XML view of JSP. The second mode to
convert
> HTML+JSP to XHTML+JSP document, where it fixes all HTML tags incorrectness
> and convert them to XHTML transient format (like an enhanced Tidy).

For the second part, there is also 'jtidy' ( not sure about the licence ).

For the first part - the only problem is preserving the line numbers for
error reporting ! This problem is common to other systems ( cocoon,
probably most translators ). One possible solution is to add a special
attribute to the generated XML tags ( in a separate namespace ). Or just
make sure you generate with exactly the same line structure.

I assume you'll use CDATA for the content ( or translate to >... ) to
make sure it is a valid xml ( if the source is not HTML/XHTML ).

> Open Questions:
> ---
> - Should this tool be a forked from Jasper code line or should Jasper be
> modified to add customizations to it?

I would vote for the first option. Eventually make it an ant-like bean,
so it can be automatized/integrated into ant later.


> - Is that an acceptable proposal? If yes, who should I contact to commit
to
> code to CVS (since I don't have a commit status)?

I'm +1 on such a tool, I think it would be quite useful. You'll need to
send this as a patch first.

Costin



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

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

DO NOT REPLY [Bug 5413] - JspWriterImpl causes, under certain circumstances, an IllegalStateException when releasing the PageContext

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

JspWriterImpl causes, under certain circumstances, an IllegalStateException when 
releasing the PageContext





--- Additional Comments From [EMAIL PROTECTED]  2001-12-13 14:04 ---
On second look, I notice that the exception comes from flush called from
release.  I put a fix a couple days ago not to call flush if response had been
committed.  Looks like you are running with a version without my fix.  Anyway, I
also couldn't reproduce the problem here.

My "fix" does not stop write's from happening after call to sendError; so if the
buffer is full and autoFlush true, the problem would surface again.  So my
advice about inserting "return"'s is still valid.

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

Re: Proposal for a JSP to JSP Document (XML view of JSP) Converter

[costinm]

On Thu, 13 Dec 2001, Ragy Eleish wrote:

> Write a tool based on the Jasper code line to convert normal JSPs to the XML
> view of JSPs (aka JSP Document). This tools should have a two modes; the
> first one to convert any JSP to XML view of JSP. The second mode to convert
> HTML+JSP to XHTML+JSP document, where it fixes all HTML tags incorrectness
> and convert them to XHTML transient format (like an enhanced Tidy).

For the second part, there is also 'jtidy' ( not sure about the licence ).

For the first part - the only problem is preserving the line numbers for
error reporting ! This problem is common to other systems ( cocoon,
probably most translators ). One possible solution is to add a special
attribute to the generated XML tags ( in a separate namespace ). Or just
make sure you generate with exactly the same line structure.

I assume you'll use CDATA for the content ( or translate to >... ) to
make sure it is a valid xml ( if the source is not HTML/XHTML ).

> Open Questions:
> ---
> - Should this tool be a forked from Jasper code line or should Jasper be
> modified to add customizations to it?

I would vote for the first option. Eventually make it an ant-like bean,
so it can be automatized/integrated into ant later.


> - Is that an acceptable proposal? If yes, who should I contact to commit to
> code to CVS (since I don't have a commit status)?

I'm +1 on such a tool, I think it would be quite useful. You'll need to
send this as a patch first.

Costin



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

problems loading web_app module

[Jon Fraley]

We are running apache 1.3.19 and I have just installed tomcat 4.0 on HP-UX
11.0.  I have down loaded the webapp-module-1.0-tc40.  When I run the
./support/build.sh script I get two lines of output:

config.in :142 /usr/local/bin/m4: Non-numeric argument to built-in 'divert'
config.in :372 /usr/local/bin/m4: Non-numeric argument to built-in 'divert'

I don't know if they contribute to my problem.  Then I run

./configure -with-apxs=/opt/apache/bin/apxs

the output looks fine until after the line:

Checking for APR compilation flags .
OK

It just hangs at this point.  I have determined from looking in the
configuration script that the line it hangs on is

eval '${CAT} ${APR_VARFIL} | ${GREP} "EXTRA_" | ${SED} "s/EXTRA_/APR/g" '

I echoed the variable APR_VARFIL, but it was not assigned.  I have also
tried downloading

apr_20011212113958

and tried building the APR that way.  When I run the script

./configure - with-apr=/var/tmp/apr -with-apxs=/opt/apache/bin/apxs

it fails at the same point.  Any help with this will be greatly appreciated

Thanks!

Jon Fraley
Unix Systems Administrator
Glen Raven, Inc
(336) 586-1148


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

ClassLoader question

[Marx, Mitchell E (Mitch), ALSVC]

Configuration: Solaris 2.6, Java 1.2, Tomcat 3.2.3

I have a question about how the ClassLoader works.  I use a Java 1.1
style SecurityManager (doesn't use the .policy).  I restrict access to
files/directories and log when an unallowed access occurs.  Even though
I do not have user.dir in my CLASSPATH, Tomcat tries to load classes
from there.  So, I get exceptions like:

Denied access of
/usr/local/tomcat/config/mmarx/com/att/hrid/HridServlet.class 
from com.att.SecurityManager->
com.att.SecurityManager->
java.io.File->
sun.misc.URLClassPath$FileLoader->
sun.misc.URLClassPath->
java.net.URLClassLoader$1->
java.net.URLClassLoader->
java.lang.ClassLoader->
sun.misc.Launcher$AppClassLoader->
java.lang.ClassLoader->
org.apache.tomcat.loader.AdaptiveClassLoader->
org.apache.tomcat.loader.AdaptiveServletLoader->
org.apache.tomcat.core.ServletWrapper->
org.apache.tomcat.core.ServletWrapper->
org.apache.tomcat.core.Handler->
org.apache.tomcat.core.ServletWrapper->
org.apache.tomcat.core.ContextManager->
org.apache.tomcat.core.ContextManager->
org.apache.tomcat.service.connector.Ajp13ConnectionHandler->
org.apache.tomcat.service.TcpWorkerThread->
org.apache.tomcat.util.ThreadPool$ControlRunnable->
java.lang.Thread

TOMCAT_HOME=/usr/local/tomcat
Server started in /usr/local/tomcat/config/mmarx (user.dir)

The class is actually in 
/usr/local/tomcat/config/mmarx/webapps/hrid/WEB-INF/classes/com/att/hrid
/HridServlet.class 

Why is it looking where it's looking?  Everything seems to run OK, so
Tomcat does eventually find the file, but I generate A LOT of error
messages, and it would seem to be a security hole. 

Thanks in advance

Mitchell Evan Marx[EMAIL PROTECTED]
AT&T IP Network Configuration & Provisioning Development

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

Proposal for a JSP to JSP Document (XML view of JSP) Converter

[Ragy Eleish]

Hi,

I would like to propose the following (I tried to be as brief as possible):

Proposal:
-
Write a tool based on the Jasper code line to convert normal JSPs to the XML
view of JSPs (aka JSP Document). This tools should have a two modes; the
first one to convert any JSP to XML view of JSP. The second mode to convert
HTML+JSP to XHTML+JSP document, where it fixes all HTML tags incorrectness
and convert them to XHTML transient format (like an enhanced Tidy).

Reason:

JSP document has many benefits that include the ability to apply XSLT on the
pages to statically transform the pages to a different view. It could allow
some compile time checking of JSP page, which would save development time
for JSP writers. 
Therefore to enhance the JSP document adoption, I thought that such a tool
would facilitate the migration to JSP documents. By allowing existing
applications to convert their normal JSPs automatically instead of the doing
that manually.

Research:
--
I did investigate Jasper code and found it doesn't implement a full fledged
parser, but it is written in a way to allow easy modifications. I wrote a
prototype of the converter. The main difficulty is that Jasper is not
written for customization, so factories may need to be added to it.

Development:
---
I am going to build this tool for my company's internal use, and would be
actively maintaining it. We will perform QA on that tool in-house. I would
be great to get 

Time Frame:
--
I expect the initial version of the tool to take 3 to 4 weeks max worth of
development time. 

Open Questions:
---
- Should this tool be a forked from Jasper code line or should Jasper be
modified to add customizations to it?
- Is that an acceptable proposal? If yes, who should I contact to commit to
code to CVS (since I don't have a commit status)? 

Regards
 
__
 Ragy Eleish  [EMAIL PROTECTED] 
 Team Lead 650-232-5825 
 Comergent Technologies   http://www.comergent.com 
 1201 Radio Road  Fortune Magazine's 25 Coolest Companies 2001
 Redwood City, CA 94065   Crossroads 2001 A-List Award Winner
  Upside's Hot 100 Private Companies Award 2000
  Cisco System's Supplier of the Year Award 1999  
 
 Comergent Technologies, Inc. is a leading provider of sell-side 
 business-to-business e-commerce software solutions that enable 
 enterprises to engage in collaborative commerce, fully leveraging 

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

Re: Jk2: error handling and method signatures

[Daniel Rall]

I meant causal, not casual.

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

java.lang.IllegalStateException - Is Tomcat getting confused between twodifferent servlets OutpuStreams?

[RSEQUEIRA]

I'm calling a servlet from within another servlet using the URL class. The
calling servlet posts data, reads the output, and then passes on the output
to the browser. In JRun everything works fine. But on Tomcat the same
throws a java.lang.IllegalStateException

Error:
java.lang.IllegalStateException: Writer is already being used for this
request
at
org.apache.tomcat.facade.HttpServletResponseFacade.getOutputStream(HttpServletResponseFacade.java:158)

I'm using a PrintWriter (which I get from the response object) in the
called servlet. And I've a finally block which closes the stream. Also
assign the object to null.

The calling servlet which behaves like a proxy has a PrintStream (which it
gets from it's response object). This object is used to write the output
(that it reads from the called servlet) to the browser.

I know I'm missing something fundamental here. But can't seem to figure it
out. Is Tomcat getting mixed up with two  Outputstreams/Writers? Any
ideas/comments?

Thanks.
RS


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

Re: Jk2: error handling and method signatures

[Bill Barker]

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, December 13, 2001 12:28 PM
Subject: Re: Jk2: error handling and method signatures


> So far I have a -1, if Bill doesn't change his vote we'll keep the current
> mechanism. But if we are going to change error handling, I think jni style
> is better for our needs.
Sorry, I've had a busy morning. I'm won over to +1.
>
> Costin
>
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

Re: Jk2: error handling and method signatures

[Daniel Rall]

<[EMAIL PROTECTED]> writes:

> On Thu, 13 Dec 2001, Daniel Rall wrote:
>
>> http://svn.collab.net/repos/svn/trunk/subversion/include/svn_error.h
>
> It seems they are using a struct that is returned instead of a simple int,
> as status. It does solve the problem of propagating more info.

In practice, I've found casual error information to be extremely
useful.  It seems that I'm not the only one, as it's been incorporated
into the JDK for version 1.4.  Catalina, Commons Util, Ant, and other
project employ this technique with good results.  It's just another
tool to consider (which might not apply equally well to all
situations).

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

Re: Jk2: error handling and method signatures

[costinm]

On Thu, 13 Dec 2001, Daniel Rall wrote:

> Here's what Subversion does for error progation:
>
> http://svn.collab.net/repos/svn/trunk/subversion/include/svn_error.h
>
> Could propogate that in the suggested env.

It seems they are using a struct that is returned instead of a simple int,
as status. It does solve the problem of propagating more info.

However I would rather use the jni style and use the env parameters. I
think it has few benefits over svn:

- return values can be used ( I believe it can be easier to read than ** )

- it also provides access to logging, object registry, etc. We have to
pass this anyway.

- it's close to java - most people here are using java most of the time,
some have already experience with jni, so it would 'feel' more natural

- I believe it is a bit cleaner ( but that's a matter of taste ).


So far I have a -1, if Bill doesn't change his vote we'll keep the current
mechanism. But if we are going to change error handling, I think jni style
is better for our needs.

Costin




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

Re: Refactor of o-a-j-JspC

[Daniel Rall]

"David Hoag" <[EMAIL PROTECTED]> writes:

> How do I contribute these changes?

http://jakarta.apache.org/site/source.html

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

DO NOT REPLY [Bug 5413] - JspWriterImpl causes, under certain circumstances, an IllegalStateException when releasing the PageContext

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

JspWriterImpl causes, under certain circumstances, an IllegalStateException when 
releasing the PageContext





--- Additional Comments From [EMAIL PROTECTED]  2001-12-13 12:12 ---
I knew I hadn't seen the last of the problems related to sendRedirect, and
sendError!  :(

The root of the problem is jasper does not known that they are being called, so
it is the user's responsibility to make sure that write or flush never got
called again after a call to sendRedirect or sendError, including the write's or
fluses generated by Jasper!  It is either that, or we'll have to change the
Servlet spec so that sendRedirect, and sendError never returns (i.e. they should
throw an exception of some sort).

There are limits to what Jasper can do to hide the problem.  This is one that it
can do nothing about.

The proposal to check if response has been committed in initOut would not work,
because if getWriter is not called, "out" would be null, and you are going to
get a NullPointerException later.  The fact is by the time it get to initOut, it
is already too late.  Write should not have been called in the first place! 
Should we check if response is commited on every call to write?  That would be
very costly!

How can the user be sure that write never got called after sendError?  Make sure
that there is always a return after a call to sendError, and a return after a
call to methods that calls sendError (e.g. sendFail in the test), etc.  If you
think this is error-prone and too much to asked from the user, you are right,
but I already said the spec should be changed.

I'll probably close this one as INVLAID (since the test can be rewritten to get
it to work), or WONTFIX (since there is no fix); but I'll leave it open for a
couple of days, to let people argue it out.

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

DO NOT REPLY [Bug 5416] New: - A I18N Test Fails in Windows XP

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

A I18N Test Fails in Windows XP

   Summary: A I18N Test Fails in Windows XP
   Product: Tomcat 4
   Version: Nightly Build
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Tomcat returns the error HTML for the euc-jp I18N test

Expected:

...
   
   
   
   
   
   
 

 


CharacterEncoding:euc-jp





Returned:

.

   
   
   
   
   
   

 

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

DO NOT REPLY [Bug 5415] New: - manual rpm requires a webserver, but tomcat doesn't count?

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

manual rpm requires a webserver, but tomcat doesn't count?

   Summary: manual rpm requires a webserver, but tomcat doesn't
count?
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


I've installed tomcat from the rpm and am trying to install
tomcat4-manual-4.0.1-1.noarch.rpm . I get this message:

[root@jade download]# rpm --upgrade tomcat4-manual-4.0.1-1.noarch.rpm
error: failed dependencies:
webserver is needed by tomcat4-manual-4.0.1-1

Um... I'd hoped that Tomcat would do the webserver job. This is just my lap top,
so I'd rather keep things light and not install apache.

Thanks,

Dave

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

Refactor of o-a-j-JspC

[David Hoag]

I refactored this class, so I could better understand it. I've made no 
functional changes, but none the less, it should now be easier to maintain. 
How do I contribute these changes? I don't believe I've broken anything, but 
I'm human...is there a set of unit tests I can run against this class?

- David Hoag



_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


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

RE: org.apache.tomcat.util.net package in tomcat 3.x

[Ignacio J. Ortega]

+1

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: Larry Isaacs [mailto:[EMAIL PROTECTED]]
> Enviado el: jueves 13 de diciembre de 2001 20:00
> Para: 'Tomcat Developers List'
> Asunto: RE: org.apache.tomcat.util.net package in tomcat 3.x
> 
> 
> I would prefer to keep Tomcat 3.3.x able to build independently
> of JTC for now.
> 
> Larry
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, December 13, 2001 12:12 PM
> > To: Tomcat Developers List
> > Subject: RE: org.apache.tomcat.util.net package in tomcat 3.x
> > 
> > 
> > On Thu, 13 Dec 2001, Kevin Seguin wrote:
> > 
> > > ideally, you'd move the rcs archives to maintain history.  
> > however, doing
> > > that would presumably break all tomcat 3.x builds.  i guess 
> > the next best
> > > alternative would be to move the rcs archives.
> > 
> > For now just import the current snapshot. Short term, we must 
> > make sure we
> > keep them in sync.
> > 
> > If Larry is ok with that, we could either change the build 
> > process in 3.3
> > to get the util sources from jtc ( and import a jar for easy 
> > building ),
> > or something similar. When jtc is released we should probably 
> > deprecate
> > the ajp13 connector in 3.3.x ( whatever x will be at that time :-),
> > and include the one from jtc.
> > 
> > ( probably the best thing would be to wait this moment and 'update'
> > both the util package and the ajp13 connectors)
> > 
> > Costin
> > 
> > 
> > --
> > 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 5414] New: - nested jsp:include doesn't parse expression

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

nested jsp:include doesn't parse expression

   Summary: nested jsp:include doesn't parse expression
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have file page1.jsp with contents: (The contents have been reduced to keep
this bug report small)
---
<% String page2 = "page2.jsp" %>

---
page2.jsp contents:
---
<% String page3 = "page3.jsp" %>

---
page3.jsp contents: (Really don't matter but...)
---
Hello World.
---

The variable page3 is not getting converted to it's string value and the
following exception is thrown:

2001-12-13 12:57:35 StandardWrapperValve[jsp]: Servlet.service() for servlet jsp
threw exception
java.lang.IllegalArgumentException: Cannot URL decode request path /jsp/mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

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

[costin]

costin  01/12/13 11:06:36

  Modified:jk/native2/common jk_handler_logon.c
  Log:
  Eliminate warning.
  
  Revision  ChangesPath
  1.8   +2 -7  jakarta-tomcat-connectors/jk/native2/common/jk_handler_logon.c
  
  Index: jk_handler_logon.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_handler_logon.c,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- jk_handler_logon.c2001/12/13 18:49:01 1.7
  +++ jk_handler_logon.c2001/12/13 19:06:36 1.8
  @@ -58,7 +58,7 @@
   /**
* Description: AJP14 Login handler
* Author:  Henri Gomez <[EMAIL PROTECTED]>
  - * Version: $Revision: 1.7 $  
  + * Version: $Revision: 1.8 $  
*/
   
   #include "jk_global.h"
  @@ -102,11 +102,6 @@
   /* communication could use AJP14 */
   #define AJP14_PROTO_SUPPORT_AJP14_NEG   0x0001 
   
  -int JK_METHOD jk_handler_logon_factory( jk_env_t *env,
  -jk_pool_t *pool,
  -void **result,
  -char *type, char *name);
  -
   #define AJP14_ENTROPY_SEED_LEN   32  /* we're using MD5 => 32 chars */
   #define AJP14_COMPUTED_KEY_LEN   32  /* we're using MD5 also */
   
  @@ -259,7 +254,7 @@
*/
   int JK_METHOD jk_handler_logon_factory( jk_env_t *env, jk_pool_t *pool,
   void **result,
  -char *type, char *name)
  +const char *type, const char *name)
   {
   jk_map_t *map;
   jk_handler_t *h;
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_endpoint.h jk_service.h jk_worker.h

[costin]

costin  01/12/13 11:06:12

  Modified:jk/native2/include jk_endpoint.h jk_service.h jk_worker.h
  Log:
  Add the new methods, remove unused declarations, added few more comments.
  
  Revision  ChangesPath
  1.6   +3 -29 jakarta-tomcat-connectors/jk/native2/include/jk_endpoint.h
  
  Index: jk_endpoint.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_endpoint.h,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jk_endpoint.h 2001/12/12 22:00:06 1.5
  +++ jk_endpoint.h 2001/12/13 19:06:11 1.6
  @@ -61,7 +61,7 @@
* Author:  Gal Shachor <[EMAIL PROTECTED]>   
* Author:  Dan Milstein <[EMAIL PROTECTED]>
* Author:  Henri Gomez <[EMAIL PROTECTED]>   
  - * Version: $Revision: 1.5 $  
  + * Version: $Revision: 1.6 $  
***/
   
   #ifndef JK_ENDPOINT_H
  @@ -157,7 +157,8 @@
   
   struct jk_msg *request;   /* original request storage */
   int uploadfd;   /* future persistant storage id */
  -int recoverable;/* if exchange could be conducted on another TC */
  +int recoverable;/* if exchange could be conducted on
  +   another TC ??? */
   
   /* For redirecting endpoints like lb */
   jk_endpoint_t *realEndpoint;
  @@ -169,10 +170,6 @@
   
   char *servletContainerName;
   
  -/* int (JK_METHOD *sendRequest)(jk_endpoint_t *e,  */
  -/*  struct jk_ws_service *s, */
  -/*  jk_logger_t *l ); */
  -
   /*
* Forward a request to the servlet engine.  The request is described
* by the jk_ws_service_t object.  I'm not sure exactly how
  @@ -199,29 +196,6 @@
   int (JK_METHOD *done)(jk_endpoint_t **p,
 jk_logger_t *l);
   };
  -
  -int ajp_get_endpoint(struct jk_worker*pThis,
  - jk_endpoint_t **pend,
  - jk_logger_t*l,
  - int proto);
  -
  -int ajp_connect_to_endpoint(jk_endpoint_t *ae,
  -jk_logger_t*l);
  -
  -void ajp_close_endpoint(jk_endpoint_t *ae,
  -jk_logger_t*l);
  -
  -int ajp_send_request(jk_endpoint_t *e,
  - struct jk_ws_service *s,
  - jk_logger_t *l);
  -
  -int ajp_get_reply(jk_endpoint_t *e,
  -  struct jk_ws_service *s,
  -  jk_logger_t *l);
  -
  -void ajp_reset_endpoint(jk_endpoint_t *ae);
  -
  -
   
   #ifdef __cplusplus
   }
  
  
  
  1.5   +10 -1 jakarta-tomcat-connectors/jk/native2/include/jk_service.h
  
  Index: jk_service.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_service.h,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- jk_service.h  2001/12/12 22:02:30 1.4
  +++ jk_service.h  2001/12/13 19:06:11 1.5
  @@ -63,7 +63,7 @@
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
* Author:  Dan Milstein <[EMAIL PROTECTED]>*
* Author:  Henri Gomez <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.4 $   *
  + * Version: $Revision: 1.5 $   *
***/
   
   #ifndef JK_SERVICE_H
  @@ -233,6 +233,15 @@
* and JK_FALSE on failure.
*/
   
  +/* Initialize the service structure
  + */
  +int (*init)( jk_ws_service_t *_this,
  + struct jk_endpoint *e, void *serverObj);
  +
  +/* Post request cleanup.
  + */
  +void (*afterRequest)( jk_ws_service_t *_this );
  +
   /*
* Send the response headers to the browser.
*/
  
  
  
  1.7   +30 -17jakarta-tomcat-connectors/jk/native2/include/jk_worker.h
  
  Index: jk_worker.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_worker.h,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- jk_worker.h   2001/12/12 22:01:49 1.6
  +++ jk_worker.h   2001/12/13 19:06:11 1.7
  @@ -58,7 +58,7 @@
   /***
* Description: Workers controller header file *
* Author:  Gal Sh

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_logger_apache2.c jk_pool_apr.c jk_service_apache2.c mod_jk.c

[costin]

costin  01/12/13 11:05:31

  Modified:jk/native2/server/apache2 jk_logger_apache2.c jk_pool_apr.c
jk_service_apache2.c mod_jk.c
  Log:
  Renamed jk_service->finalize to afterRequest ( finalize is too overloaded ).
  
  Updates, make it compile again :-)
  
  Revision  ChangesPath
  1.7   +2 -0  
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_logger_apache2.c
  
  Index: jk_logger_apache2.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_logger_apache2.c,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- jk_logger_apache2.c   2001/12/12 23:36:01 1.6
  +++ jk_logger_apache2.c   2001/12/13 19:05:31 1.7
  @@ -83,6 +83,8 @@
   #include "httpd.h"
   #include "http_log.h"
   
  +#include "jk_apache2.h"
  +
   #define HUGE_BUFFER_SIZE (8*1024)
   
   int JK_METHOD jk_logger_apache2_factory(jk_env_t *env, jk_pool_t *pool,
  
  
  
  1.4   +5 -3  
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_pool_apr.c
  
  Index: jk_pool_apr.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_pool_apr.c,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jk_pool_apr.c 2001/12/06 22:50:25 1.3
  +++ jk_pool_apr.c 2001/12/13 19:05:31 1.4
  @@ -66,6 +66,8 @@
   #include "apr_pools.h"
   #include "apr_strings.h"
   
  +#include "jk_apache2.h"
  +
   int jk_pool_apr_create( jk_pool_t **newPool, jk_pool_t *parent, apr_pool_t *aprPool 
);
   
   int JK_METHOD jk_pool_apr_factory(jk_env_t *env,
  @@ -163,9 +165,9 @@
   }
   
   /* Not used yet */
  -int JK_METHOD jk_pool_apr_factory(jk_env_t *env, jk_pool_t *pool,
  -  void **result,
  -  char *type, char *name)
  +int  jk_pool_apr_factory(jk_env_t *env, jk_pool_t *pool,
  + void **result,
  + char *type, char *name)
   {
   jk_pool_t *_this=(jk_pool_t *)calloc( 1, sizeof(jk_pool_t));
   
  
  
  
  1.2   +6 -7  
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c
  
  Index: jk_service_apache2.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jk_service_apache2.c  2001/12/13 18:50:33 1.1
  +++ jk_service_apache2.c  2001/12/13 19:05:31 1.2
  @@ -59,7 +59,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat 
* Author:  Gal Shachor <[EMAIL PROTECTED]>   
* Henri Gomez <[EMAIL PROTECTED]>
  - * Version: $Revision: 1.1 $   
  + * Version: $Revision: 1.2 $   
*/
   
   #include "apu_compat.h"
  @@ -276,11 +276,10 @@
  jk_endpoint_t *e,
  void *serverObj)
   {
  -request_rec *r=s->ws_private;
  -jk_logger_t *l=workerEnv->l;
   apr_port_t port;
   char *ssl_temp  = NULL;
   jk_workerEnv_t *workerEnv=e->worker->workerEnv;
  +jk_logger_t *l=workerEnv->l;
   request_rec *r=serverObj;
   
   /* Common initialization */
  @@ -495,7 +494,7 @@
*  jk shouldn't do it instead, and the user should get the
*  error message !
*/
  -static int jk_service_apache2_finalize(jk_ws_service_t *s )
  +static void jk_service_apache2_afterRequest(jk_ws_service_t *s )
   {
   
   if (s->content_read < s->content_length ||
  @@ -521,10 +520,10 @@
   {
   jk_ws_service_t *s = *result;
   if( s==NULL ) {
  -s=(jk_ws_service_t *)pool->calloc(pool, sizeof(jk_service_t));
  +s=(jk_ws_service_t *)pool->calloc(pool, sizeof(jk_ws_service_t));
   }
   
  -if(l==NULL ) {
  +if(s==NULL ) {
   return JK_FALSE;
   }
   
  @@ -532,7 +531,7 @@
   s->read = ws_read;
   s->write= ws_write;
   s->init = init_ws_service;
  -s->finalize = jk_service_apache2_finalize;
  +s->afterRequest = jk_service_apache2_afterRequest;
   
   *result=(void *)s;
   
  
  
  
  1.10  +47 -455   jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk.c,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- mod_jk.c  2001/12/12 22:07:25 1.9
  +++ mod_jk.c  2001/12/13 19:05:31 1.10
  @@ -59,7 +59,7 @@
* De

RE: org.apache.tomcat.util.net package in tomcat 3.x

[Larry Isaacs]

I would prefer to keep Tomcat 3.3.x able to build independently
of JTC for now.

Larry

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 13, 2001 12:12 PM
> To: Tomcat Developers List
> Subject: RE: org.apache.tomcat.util.net package in tomcat 3.x
> 
> 
> On Thu, 13 Dec 2001, Kevin Seguin wrote:
> 
> > ideally, you'd move the rcs archives to maintain history.  
> however, doing
> > that would presumably break all tomcat 3.x builds.  i guess 
> the next best
> > alternative would be to move the rcs archives.
> 
> For now just import the current snapshot. Short term, we must 
> make sure we
> keep them in sync.
> 
> If Larry is ok with that, we could either change the build 
> process in 3.3
> to get the util sources from jtc ( and import a jar for easy 
> building ),
> or something similar. When jtc is released we should probably 
> deprecate
> the ajp13 connector in 3.3.x ( whatever x will be at that time :-),
> and include the one from jtc.
> 
> ( probably the best thing would be to wait this moment and 'update'
> both the util package and the ajp13 connectors)
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   

For additional commands, e-mail: 

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

Re: Jk2: error handling and method signatures

[Daniel Rall]

<[EMAIL PROTECTED]> writes:

> On Thu, 13 Dec 2001, Daniel Rall wrote:
>
>> This is reminiscent of what the Subersion folks are doing for error
>> handling.
>
> Could you give a URL ? If it was already invented... ( I was thinking to
> use a subset of what's 'invented' in jni, I believe there are
> quite a few people who'll feel 'familiar' with this and it's natural for
> java programmers ).

Here's what Subversion does for error progation:

http://svn.collab.net/repos/svn/trunk/subversion/include/svn_error.h

Could propogate that in the suggested env.

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

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

[costin]

costin  01/12/13 10:50:34

  Added:   jk/native2/server/apache2 jk_apache2.h jk_service_apache2.c
  Log:
  Header file to get rid of warnings and check signatures.
  
  Split the implementation of jk_service out of mod_jk, for consistency and
  to make it easier to read.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-connectors/jk/native2/server/apache2/jk_apache2.h
  
  Index: jk_apache2.h
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   *  Copyright (c) 1999-2001 The Apache Software Foundation.  *
   *   All rights reserved.*
   *   *
   * = *
   *   *
   * Redistribution and use in source and binary forms,  with or without modi- *
   * fication, are permitted provided that the following conditions are met:   *
   *   *
   * 1. Redistributions of source code  must retain the above copyright notice *
   *notice, this list of conditions and the following disclaimer.  *
   *   *
   * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
   *notice,  this list of conditions  and the following  disclaimer in the *
   *documentation and/or other materials provided with the distribution.   *
   *   *
   * 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 ."  *
   *   *
   *Alternately, this acknowlegement may appear in the software itself, if *
   *and wherever such third-party acknowlegements normally appear. *
   *   *
   * 4. The names  "The  Jakarta  Project",  "Jk",  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 Software Foundation.*
   *   *
   * 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 indivi- *
   * duals on behalf of the  Apache Software Foundation.  For more information *
   * on the Apache Software Foundation, please see .   *
   *   *
   * 

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_ajp14_worker.c jk_channel_socket.c jk_handler_discovery.c jk_handler_logon.c jk_handler_response.c jk_lb_worker.c jk_logger_file.c jk_uriMap.c jk_workerEnv.c

[costin]

costin  01/12/13 10:49:01

  Modified:jk/native2/common jk_ajp14_worker.c jk_channel_socket.c
jk_handler_discovery.c jk_handler_logon.c
jk_handler_response.c jk_lb_worker.c
jk_logger_file.c jk_uriMap.c jk_workerEnv.c
  Log:
  Cosmetic changes on messsages and code, minor fixes.
  
  Revision  ChangesPath
  1.8   +20 -20jakarta-tomcat-connectors/jk/native2/common/jk_ajp14_worker.c
  
  Index: jk_ajp14_worker.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_ajp14_worker.c,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- jk_ajp14_worker.c 2001/12/12 23:36:01 1.7
  +++ jk_ajp14_worker.c 2001/12/13 18:49:01 1.8
  @@ -82,7 +82,7 @@
   jk_logger_t *l, int *is_recoverable_error);
   
   static int JK_METHOD
  -jk_worker_ajp14_validate(jk_worker_t *pThis, jk_map_t*props,
  +jk_worker_ajp14_validate(jk_worker_t *_this, jk_map_t*props,
jk_workerEnv_t *we, jk_logger_t *l );
   
   static int JK_METHOD
  @@ -97,7 +97,7 @@
jk_workerEnv_t *we, jk_logger_t *l);
   
   static int JK_METHOD
  -jk_worker_ajp14_destroy(jk_worker_t **pThis, jk_logger_t *l);
  +jk_worker_ajp14_destroy(jk_worker_t **_this, jk_logger_t *l);
   
   
   #define AJP_DEF_RETRY_ATTEMPTS(2)
  @@ -123,7 +123,7 @@
   return JK_FALSE;
   }
   w->pool = pool;
  -w->name = (char *)pool->pstrdup(pool, name);
  +w->name = NULL;
   
   w->proto= AJP14_PROTO;
   
  @@ -140,9 +140,6 @@
   
   *result = w;
   
  -l->jkLog(l, JK_LOG_INFO, "ajp14.factory() Created %s %s\n",
  - w->name, name);
  -
   return JK_TRUE;
   }
   
  @@ -167,8 +164,6 @@
   secret_key = map_getStrProp( props, "worker", aw->name, "secretkey", NULL );
   
   if ((!secret_key) || (!strlen(secret_key))) {
  -l->jkLog(l, JK_LOG_INFO,
  -   "ajp14.validate() No secretkey, use AJP13\n");
   proto=AJP13_PROTO;
   aw->proto= AJP13_PROTO;
   }
  @@ -205,7 +200,8 @@
return err;
   }
   
  -l->jkLog(l, JK_LOG_INFO, "ajp14.validate() %s\n", _this->name);
  +l->jkLog(l, JK_LOG_INFO, "ajp14.validate() %s protocol=%s\n", _this->name,
  + ((_this->secret==NULL) ? "ajp13" : "ajp14"));
   
   return JK_TRUE;
   }
  @@ -219,11 +215,11 @@
   l->jkLog(l, JK_LOG_INFO, "endpoint.close() %s\n", ae->worker->name);
   
   ae->reuse = JK_FALSE;
  -ae->pool->reset( ae->pool );
  -ae->pool->close( ae->pool );
  +ae->worker->channel->close( ae->worker->channel, ae );
   ae->cPool->reset( ae->cPool );
   ae->cPool->close( ae->cPool );
  -ae->worker->channel->close( ae->worker->channel, ae );
  +ae->pool->reset( ae->pool );
  +ae->pool->close( ae->pool );
   }
   
   /** Connect a channel, implementing the logging protocol if ajp14
  @@ -442,7 +438,7 @@
   *eP = NULL;
   l->jkLog(l, JK_LOG_INFO, "ajp14.done() close endpoint %s\n",
w->name );
  -
  +
   return JK_TRUE;
   }
   
  @@ -548,7 +544,8 @@
   
   if (_this->secret == NULL) {
   /* No extra initialization for AJP13 */
  -l->jkLog(l, JK_LOG_INFO, "ajp14.init() ajp13 mode %s\n",_this->name);
  +l->jkLog(l, JK_LOG_INFO, "ajp14.init() ajp1x worker name=%s\n",
  + _this->name);
   return JK_TRUE;
   }
   
  @@ -580,19 +577,19 @@
   
   
   static int JK_METHOD
  -jk_worker_ajp14_destroy(jk_worker_t **pThis, jk_logger_t *l)
  +jk_worker_ajp14_destroy(jk_worker_t **_thisP, jk_logger_t *l)
   {
  -jk_worker_t *aw = *pThis;
  +jk_worker_t *_this = *_thisP;
   int i;
   
   l->jkLog(l, JK_LOG_DEBUG, "ajp14.destroy()\n");
   
  -if( aw->endpointCache != NULL ) {
  +if( _this->endpointCache != NULL ) {
   
  -for( i=0; i< aw->endpointCache->ep_cache_sz; i++ ) {
  +for( i=0; i< _this->endpointCache->ep_cache_sz; i++ ) {
   jk_endpoint_t *e;
   
  -e= aw->endpointCache->get( aw->endpointCache );
  +e= _this->endpointCache->get( _this->endpointCache );
   
   if( e==NULL ) {
   // we finished all endpoints in the cache
  @@ -601,11 +598,14 @@
   
   jk_close_endpoint(e, l);
   }
  -aw->endpointCache->destroy( aw->endpointCache );
  +_this->endpointCache->destroy( _this->endpointCache );
   
   l->jkLog(l, JK_LOG_DEBUG, "ajp14.destroy() closed %d cached endpoints\n",
i);
   }
   
  +_this->pool->close( _this->pool );
  +
  +*_thisP=NULL;
   return JK_TRUE;
   }
  
  
  
  1.8   +1 -0  jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c
  
  Index: jk

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

[costin]

costin  01/12/13 10:48:13

  Modified:jk/native2/common jk_registry.c
  Added:   jk/native2/common jk_registry.h
  Log:
  Split jk_registry so we can get rid of the warnings ( and let the compiler
  check our signatures ).
  
  Revision  ChangesPath
  1.6   +2 -51 jakarta-tomcat-connectors/jk/native2/common/jk_registry.c
  
  Index: jk_registry.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_registry.c,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jk_registry.c 2001/12/12 21:55:57 1.5
  +++ jk_registry.c 2001/12/13 18:48:13 1.6
  @@ -60,9 +60,10 @@
   #include "jk_service.h"
   #include "jk_env.h"
   
  +#include "jk_registry.h"
   /***
* Description: Worker list*
  - * Version: $Revision: 1.5 $   *
  + * Version: $Revision: 1.6 $   *
***/
   
   /** Static declarations for all 'hardcoded' modules. This is a hack, 
  @@ -83,56 +84,6 @@
* @author:  Costin Manolache
*  
*/
  -
  -int JK_METHOD jk_worker_ajp14_factory( jk_env_t *env, jk_pool_t *pool,
  -   void **result,
  -   const char *type, const char *name);
  -
  -   
  -int JK_METHOD jk_worker_lb_factory(jk_env_t *env, jk_pool_t *pool,
  -   void **result,
  -   const char *type, const char *name);
  -
  -
  -int JK_METHOD jk_worker_jni_factory(jk_env_t *env, jk_pool_t *pool,
  -void **result,
  -const char *type, const char *name);
  -
  -int JK_METHOD jk_worker_ajp12_factory(jk_env_t *env, jk_pool_t *pool,
  -  void **result,
  -  const char *type, const char *name);
  -
  -/* Factories for 'new' types. We use the new factory interface,
  - *  workers will be updated later 
  - */
  -int JK_METHOD jk_channel_socket_factory(jk_env_t *env, jk_pool_t *pool,
  -void **result,
  - const char *type, const char *name);
  -
  -int JK_METHOD jk_workerEnv_factory(jk_env_t *env, jk_pool_t *pool,
  -   void **result,
  -   const char *type, const char *name);
  -
  -int JK_METHOD jk_uriMap_factory(jk_env_t *env, jk_pool_t *pool, void **result,
  -const char *type, const char *name);
  -
  -int JK_METHOD jk_logger_file_factory(jk_env_t *env, jk_pool_t *pool,
  - void **result,
  - const char *type, const char *name);
  -
  -
  -int JK_METHOD jk_handler_logon_factory( jk_env_t *env, jk_pool_t *pool,
  -void **result,
  -const char *type, const char *name);
  -
  -int JK_METHOD jk_handler_discovery_factory( jk_env_t *env, jk_pool_t *pool,
  -void **result,
  -const char *type, const char *name);
  -
  -int JK_METHOD jk_handler_response_factory( jk_env_t *env, jk_pool_t *pool,
  -   void **result,
  -   const char *type, const char *name);
  -
   
   /**
*   Init the components that we compile in by default. 
  
  
  
  1.1  jakarta-tomcat-connectors/jk/native2/common/jk_registry.h
  
  Index: jk_registry.h
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   *  Copyright (c) 1999-2001 The Apache Software Foundation.  *
   *   All rights reserved.*
   *   *
   * = *
   *   *
   * Redistribution and use in source and binary forms,  with or without modi- *
   * fication, are permitted provided that the following conditions are met:   *
   *

Re: error handling and method signatures

[costinm]

On Wed, 12 Dec 2001, Bill Barker wrote:

> I'm probably just misunderstanding what situations you are trying to handle
> here, so if you can be a little bit more verbose, I'll probably change my
> vote.

More details:

jk_env will replace all jk_logger_t parameters. All methods will follow
the  pattern:

  method( jk_env *env, jk_foo *_this, ... other params ... );

The env will be guaranteed to be used single-threaded ( i.e. either each
thread has a per/thread env, or we use the objCache, or any other
mechanism ). mod_jk will get an instance and release it after it's done.

The env will be have few uses:

- save the error message and details. When an error is detected, besides
returning the right status ( or NULL for methods returning a real object
and not using ** ), we'll call env->throw() method. This will replace the
current jkLog( JK_ERROR, ... ) ( which will be implemented in throw() )
from each method. Caller could either check the rc, or env->error ( I
prefer the second because it's more consistent )

- logger. In addition, because env is per/thread we could do some tricks
here too ( right now it works because printf is synchronized - or I think
so ).

- temp pool/storage. Things like map, logger, etc need some temp storage.
Right now they either malloc/free or use some other ugly tricks ( per
stack, etc ).


Costin


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

Re: org.apache.tomcat.util.net package in tomcat 3.x

[Bill Barker]

I'm +1 on the move.  However I think that we should hold off on removing it
from 3.3 just yet, and just agree to freeze development there.
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, December 13, 2001 6:49 AM
Subject: Re: org.apache.tomcat.util.net package in tomcat 3.x


> +1 ( part of it has already been moved ).
>
> But if we do that, I would propose to _move_ it, not copy.
>
> Costin
>
>
> On Thu, 13 Dec 2001, Kevin Seguin wrote:
>
> > it seems like a bunch of the stuff in the org.apache.tomcat.util.net
package
> > in tomcat 3.x would be useful outside the scope of tomcat 3.  most
notably,
> > things like TcpConnection, TcpConnectionHandler, PoolTcpEndpoint.
> >
> > what would people think about moving (or at least copying for now) this
> > package into j-t-c/util?  a bunch of the subpackages of o.a.t.util in
tomcat
> > 3 have already been moved there.
> >
> > the reason i bring this up is i think i'd like to use some of this stuff
for
> > the refactored ajp stuff i'm doing in j-t-c/jk.
> >
> > -kevin.
> >
> > --
> > 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: Jk2: error handling and method signatures

[costinm]

On Thu, 13 Dec 2001, Daniel Rall wrote:

> This is reminiscent of what the Subersion folks are doing for error
> handling.

Could you give a URL ? If it was already invented... ( I was thinking to
use a subset of what's 'invented' in jni, I believe there are
quite a few people who'll feel 'familiar' with this and it's natural for
java programmers ).

Costin


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

Re: Jk2: error handling and method signatures

[Daniel Rall]

This is reminiscent of what the Subersion folks are doing for error
handling.

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

DO NOT REPLY [Bug 5413] - JspWriterImpl causes, under certain circumstances, an IllegalStateException when releasing the PageContext

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

JspWriterImpl causes, under certain circumstances, an IllegalStateException when 
releasing the PageContext





--- Additional Comments From [EMAIL PROTECTED]  2001-12-13 09:19 ---
Created an attachment (id=896)
The test(s) in question are the ScopedObject tests (page, request, session, and 
application)

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

DO NOT REPLY [Bug 5413] New: - JspWriterImpl causes, under certain circumstances, an IllegalStateException when releasing the PageContext

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

JspWriterImpl causes, under certain circumstances, an IllegalStateException when 
releasing the PageContext

   Summary: JspWriterImpl causes, under certain circumstances, an
IllegalStateException when releasing the PageContext
   Product: Tomcat 4
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have two JSP pages testing scope of beans.

Page 1:
  Creates a bean instance and forwards the request to another
  page (Page 2) to make a scope validity check.
Page 2:
  Consists of only scriplets, declarations, and JSP-comments.
  In either case, if the test fails or passes, a call is 
  made to response.sendError(int,String).

The problem here seems to be since sendError commits the response,
the call to initOut will fail when calling response.getWriter();
Looking at the code for initOut:

protected void initOut() throws IOException {
if (out == null) {
out = response.getWriter();
//System.out.println("JspWriterImpl: initOut: " + this + " " +out);
}
}

It would seem to make sense to make sure that the response isn't already
committed as well before making the call to getWriter.

NOTE:  This setup that I had, previously worked.  I don't think I'm doing
anything incorrectly, but I could be wrong.  

Stacktrace:
***
StandardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exception
java.lang.IllegalStateException
at
org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:159)
at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:166)
at
org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:158)
at org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:205)
at
org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:176)
at
org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:198)
at
org.apache.jasper.runtime.JspFactoryImpl.access$0(JspFactoryImpl.java:197)
at
org.apache.jasper.runtime.JspFactoryImpl$PrivilegedReleasePageContext.run(JspFactoryImpl.java:132)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:191)
at
org.apache.jsp.ScopeResultXML$jsp._jspService(ScopeResultXML$jsp.java:137)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:202)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:679)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:431)
at
org.apache.catalina.core.ApplicationDispatcher.access$0(ApplicationDispatcher.java:359)
at
org.apache.catalina.core.ApplicationDispatcher$PrivilegedForward.run(ApplicationDispatcher.java:130)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:347)
at
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:413)
at
org.apache.jsp.positivePageScopedObjectXML$jsp._jspService(positivePageScopedObjectXML$jsp.java:88)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:202)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.access$0(ApplicationFilterChain.java:197)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:176)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ApplicationFilterChain.d

RE: org.apache.tomcat.util.net package in tomcat 3.x

[costinm]

On Thu, 13 Dec 2001, Kevin Seguin wrote:

> ideally, you'd move the rcs archives to maintain history.  however, doing
> that would presumably break all tomcat 3.x builds.  i guess the next best
> alternative would be to move the rcs archives.

For now just import the current snapshot. Short term, we must make sure we
keep them in sync.

If Larry is ok with that, we could either change the build process in 3.3
to get the util sources from jtc ( and import a jar for easy building ),
or something similar. When jtc is released we should probably deprecate
the ajp13 connector in 3.3.x ( whatever x will be at that time :-),
and include the one from jtc.

( probably the best thing would be to wait this moment and 'update'
both the util package and the ajp13 connectors)

Costin


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

RE: Jk2: discovery and updates

[costinm]

On Thu, 13 Dec 2001, GOMEZ Henri wrote:

> >Tomcat could also decide to push config data, or context status, etc.
>
> Ok, we could have a little overhead (network latency) during this init
> phase but it's not a big problem since it's not too common. Which make
> me think that in multithreaded env like Apache 2.0 we could avoid to
> redo the full logging and discovery each time since we may allready
> know the list of webapps and related URIs.

Init happens only the first time, or when an error happens ( like tomcat
was restarted and we lost the connection ). In the second case, it's
possible ( even likely ) that tomcat has other settings/apps.
( XXX todo: detect webapp reload in aprconnector :-)

> Having a common code which will monitor for incoming message
> from tomcat is not a bad idea but we'll need in that case a
> state-machine, just to avoid handling illegal messages
>
> WebServer could be in state:
>
> a) physically connected (login to be sent)
> b) logically connected (login sent and granted)
> c) waiting for autoconf stuff (discovery request sent)
> d) waiting replies

After the first 'ping' message tomcat has 'control' - it can send any
message it wants. Apache doesn't need any state, it'll just receive
messaes from tomcat and execute them.

It tomcat wants md5 auth - it'll request it. If it fails - it'll send
a 'notok' message that would close the endpoint.

The state can be only maintained on tomcat side, we don't need any
complexity on the C side.

We could have tomcat set a 'state' field in endpoint if we need to,
and check it - but I think right now is not needed and would make things
complex.

What if tomcat wants a different auth mechanism ? For a unix domain socket
we probably don't need md5 auth.

Regarding discovery, tomcat is the one that knows what changed - it should
push the data. It may also use different message formats.

The benefit of this logic is flexibility and simplicity. Instead of a
state machine and RPC-style calls we have just messages.


> In multi-threaded env we could also reuse the socket
> to have a thread monitoring the tomcat state by sending
> heart-beat messages (usefull in out-process, uneeded in in-process)

That could be handled by jkctl and ping messages. It can also be
done periodically, but that can be controled by external logic.

Non-multi-threaded env is more problematic, and getting all
processes to update.

Costin


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

RE: Jk2: jkctl handler

[costinm]

On Thu, 13 Dec 2001, GOMEZ Henri wrote:

> >The most important feature ( for now ) will be the handling of 'ping',
> >where mod_jk will connect to any worker it knows about and send a ping
> >message.
>
> could you explain us more about ping ?

Jk now has a 'ping' message type, which replaces the login and discovery
messages.

It will send the 'ping' as the first packet when it opens the connection,
and also every time it is asked for ( or even periodically ). The ping
will be equivalent with an empty request - it will 'switch roles',
allowing tomcat to send messages and get/set information.

For example, tomcat can send a 'loginSeed' packet and request md5 auth. Or
it can request a different auth method. Then it can send uriMaps or
contextStatus messages.

The C side is very simple ( and clear - I hope ) - adding new message
handlers require just  adding a C file and adding it to the registry. See
the processCallbacks method in workerEnv.

Ping will get an 'ok' response, signaling tomcat is ok - but before the ok
message tomcat can update anything else or request anything.

> >Opinions ? Votes ( I'm looking for +1s == I will help :-)
>
> Seems good, what's the help you need there ?

Right now the most important thing is to make sure jk2 builds and works
as good as ( or better than ) jk1.
Then we have to port the other server connectors ( apache13, iis, etc ).
I want to finish ( or at least 'freeze' ) jk2 refactoring ( or at least
the first round ) in few days - but I also want to sleep, so any contribution would
be great - testing, updating connectors, implementing the 'jkctl' ( or
parts of it )...

Costin


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

RE: Jk2: jkctl handler

[GOMEZ Henri]

>This tries to solve the 'egg and chicken' config problem, and to
>fix/enable some other things.
>
>I want to add a second handler in mod_jk, similar with the 'status' for
>apache, mod_jserv, etc. ( same security issues - i.e. users will need
>access control, to use it, etc ).

good thing

>The most important feature ( for now ) will be the handling of 'ping',
>where mod_jk will connect to any worker it knows about and send a ping
>message.

could you explain us more about ping ?

>Whenever tomcat starts, the ajp connector ( if configured to ) 
>will access
>this control uri - Apache will then reconnect to it and update 
>it's info.

he he good idea, tomcat call Apache, i like it :)

>( apache does try to connect to workers when it starts, but it 
>is possible
>that tomcat was down ). It will also update it's up/down state for
>workers that were marked as down as result of connection failure.
>
>This will also alow user to add/remove application in a 'lb' 
>environment
>in a nice and clean manner.
>
>The handler will report the status of it's workers as result ( 
>in simple
>XHTML format, nothing fancy ).
>
>Opinions ? Votes ( I'm looking for +1s == I will help :-)

Seems good, what's the help you need there ?

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

RE: Jk2: discovery and updates

[GOMEZ Henri]

>I'm getting close with jk2, there are just few more details I need to
>resolve ( and then test, update the other server adapters, test again,
>etc).
>
>One change I'm making to get the things cleaner refers to the login and
>discovery protocol.
>
>Instead of a RPC-style, where Apache sends a command and read the
>response, I would use the same 'style' as for requests, where 
>apache sends
>a messages and then listen and dispatch other messages.

>A single message 'PING' will be used. This message will give control to
>tomcat ( like SEND_REQUEST does ). Tomcat can then decide what 
>it wants -
>if it wants auth, it'll send LOGIN_SEED message and expect the result (
>like it sends GET_CHUNK when reading post data ).

>Tomcat could also decide to push config data, or context status, etc.

Ok, we could have a little overhead (network latency) during this init 
phase but it's not a big problem since it's not too common. Which make
me think that in multithreaded env like Apache 2.0 we could avoid to
redo the full logging and discovery each time since we may allready 
know the list of webapps and related URIs.

>The same code will also handle config/status messages comming during
>normal operations.

Why not.

>This will make the code extremely simple and clear ( at least IMHO ),
>and we'll gain a lot of flexibility ( and that just by 
>_removing_ code ).
>
>I'll commit the code after some more testing, I'm pretty sure 
>it's a good
>idea, but I want some feedback ( especially from Henri, who 
>wrote most of
>the discovery and login code ).

Having a common code which will monitor for incoming message
from tomcat is not a bad idea but we'll need in that case a
state-machine, just to avoid handling illegal messages

WebServer could be in state:

a) physically connected (login to be sent)
b) logically connected (login sent and granted)
c) waiting for autoconf stuff (discovery request sent)
d) waiting replies 

In multi-threaded env we could also reuse the socket 
to have a thread monitoring the tomcat state by sending
heart-beat messages (usefull in out-process, uneeded in in-process)


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

DO NOT REPLY [Bug 5411] New: - JSP session does not work with IE/IIS5/Tomcat 3.3

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

JSP session does not work with IE/IIS5/Tomcat 3.3

   Summary: JSP session does not work with IE/IIS5/Tomcat 3.3
   Product: Tomcat 3
   Version: 3.3 Final
  Platform: PC
   URL: http://www.warf.ws/admin/
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We are using the auto-generated JSP session object to read and write session 
variables.  This works under IE/Apache/Tomcat 3.3 (with the same code) but does 
not work with IE/IIS5/Tomcat 3.3.  It is a browser-specific bug: Netscape and 
Opera work fine on IIS5/Tomcat 3.3.  IE seems to lose the session cookie, or at 
least it does not make it to Jasper for persistence of the session object.  
This is ONLY with the JSP instantiation of HttpSession; the example servlet 
SessionExample does work under IE/IIS5/Tomcat 3.3.  (This servlet explicitly 
instantiates an HttpSession object.)

Although it looks like an IE-specific bug, not a general Jasper bug, the 
predominance of IE may make this bug worth investigating.

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

RE: org.apache.tomcat.util.net package in tomcat 3.x

[Kevin Seguin]

> 
> +1 ( part of it has already been moved ).
> 

by part, you mean o.a.t.util.buf|collections|http|res, right?

> But if we do that, I would propose to _move_ it, not copy.
> 

ideally, you'd move the rcs archives to maintain history.  however, doing
that would presumably break all tomcat 3.x builds.  i guess the next best
alternative would be to move the rcs archives.

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

RE: Jk2: error handling and method signatures

[Kevin Seguin]

> One more change I want to do in jk2 is better error handling. 
> Most of us
> spent enough time with java that using an 'int' is very 
> uncomfortable :-)
> 

error handling good :)  whether this is done by return codes, exceptions,
etc., personally, i don't care.  what i do care about is consistency -- the
same error-handling techniques used throughout jk.

> My proposal is to use jk_env in the same 'style' as in JNI 
> programming.
> Each jk method will have as the first parameter a jk_env *env ( that
> requires just a bit of regexp ).
> 
> Before the first call to a jk method, we'll use a jk_getEnv, 
> which will
> return a (pooled) jk_env.
> 
> env will have "errorString", "errorFile", eventually a method 
> throw() that
> will set the things. This would allow mod_jk to report the 
> exact problem.
> 

yes!  an error string to explain exactly what went wrong would be great.

> Exactly the same method is used in jni - a jni worker could actually
> wrap JNIEnv.
> 
> I also believe the code will be easier to read this way.
> 
> This is obviously not 'required' - we can live without it. 
> Please let me
> know what you think - I implement it pretty quickly.
> 

it all sounds pretty reasonable to me.

-kevin.

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

RE: PATCH: Fix I18N problems in Tomcat 3.3

[Larry Isaacs]

I'll try to commit these tonight.  You can send
the resource bundles directly to me.  Thanks.

Cheers,
Larry

> -Original Message-
> From: Kazuhiro Kazama [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 13, 2001 2:52 AM
> To: [EMAIL PROTECTED]
> Subject: PATCH: Fix I18N problems in Tomcat 3.3
> 
> 
> Dear Tomcat 3.3 committers,
> 
> The atached two patches resolve character corruption problems when
> Tomcat 3.3 lists directories or displays an error message in
> non-ISO-8859-1 environments.
> 
> And I created Japanese resource bundles for Tomcat 3.3 according to
> Henri Gomez's advice (Note: they requires the attached patches). I
> think it is better to send them to one of committers because they are
> a little bit huge.
> 
> Could anyone recieve them and commit them to Tomcat 3.3 CVS?
> 
> Kazuhiro Kazama ([EMAIL PROTECTED])   NTT Network Innovation 
> Laboratories
> 
> 

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

DO NOT REPLY [Bug 5409] New: - Automatic removal of log files

[bugzilla]

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

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

Automatic removal of log files

   Summary: Automatic removal of log files
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Windows 9x
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,
TC generates quite a few log files and I think it's a good
idea to have TC remove these files automatically. Some of us
only look at log files if there are problems. This would
help to sorta make TC maintenance-free. Perhaps there should
be a parameter named something like 'maxLogFileAge' and with
a value of '5' and that all log files older than 5 days are
removed.

Thanks

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

Re: org.apache.tomcat.util.net package in tomcat 3.x

[costinm]

+1 ( part of it has already been moved ).

But if we do that, I would propose to _move_ it, not copy.

Costin


On Thu, 13 Dec 2001, Kevin Seguin wrote:

> it seems like a bunch of the stuff in the org.apache.tomcat.util.net package
> in tomcat 3.x would be useful outside the scope of tomcat 3.  most notably,
> things like TcpConnection, TcpConnectionHandler, PoolTcpEndpoint.
>
> what would people think about moving (or at least copying for now) this
> package into j-t-c/util?  a bunch of the subpackages of o.a.t.util in tomcat
> 3 have already been moved there.
>
> the reason i bring this up is i think i'd like to use some of this stuff for
> the refactored ajp stuff i'm doing in j-t-c/jk.
>
> -kevin.
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>


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

org.apache.tomcat.util.net package in tomcat 3.x

[Kevin Seguin]

it seems like a bunch of the stuff in the org.apache.tomcat.util.net package
in tomcat 3.x would be useful outside the scope of tomcat 3.  most notably,
things like TcpConnection, TcpConnectionHandler, PoolTcpEndpoint.

what would people think about moving (or at least copying for now) this
package into j-t-c/util?  a bunch of the subpackages of o.a.t.util in tomcat
3 have already been moved there.

the reason i bring this up is i think i'd like to use some of this stuff for
the refactored ajp stuff i'm doing in j-t-c/jk.

-kevin.

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

Sticky sessions with mod_jk

[Subbu Kaleyathodi]

We are using Tomcat 4.0.1 with Tomcat and would like to use mod_jk as the
connector from Apache to Tomcat. The main reason for going with mod_jk is
because I read some snippets of documentation that mentioned that it
supported sticky sessions. But I haven't found anything comprehensive on
this topic. 

I wanted to find out of people have used mod_jk with Tomcat 4.0.1 for sticky
sessions. Also I am not clear what is th advantage of using mod_webapp over
mod_jk (BTW, does mod_webapp support sticky sessions).

Any help is appreciated

Subbu Kaleyathodi

Client authentication implementation - user 'name' attribute = SubjectDN ?

[STANFORD, Jon-Paul, FM]

Anyone,
I am having a little difficulty setting up Tomcat (4.0.1) to perform
client authentication (actually mutual). For our purposes we are happy to
use the
MemoryRealm and perform authentication of a client's certificate against
tomcat
users in this realm.

I intialially posted this to the 'user' newsgroup, but have had no
responses. But
this I guess is more related to the specific implementation of the
authentication.

The question is what do you put in the user name attribute in
conf/tomcat-users.xml?
I saw a post which indicated this must be the "SubjectDN" of the certificate
-
but what exactly is this?
I exported the Digital ID from Netscape and imported it into the
Certificates
snap-in in MMC so I could see it's details, the Subject field is as follows
-

E = [EMAIL PROTECTED]
CN = Joe Bloggs
OU = Digital ID Class 1 - Netscape
OU = Persona Not Validated
OU = www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)98
OU = VeriSign Trust Network
O = VeriSign, Inc.

I set this as the user, but got the usual "Cannot authenticate with the
provided credentials" message - equally I tried combinations of some of the
fields.
So this would not appear to be correct, but I cannot tell whether this is
formatting
(i.e. quoted, escaped - how?) in the user name attribute or that I am doing
something wrong???


Can you confirm that the client certificate must only be installed on the
client
browser and not imported into the JSSE keystore? I can't imagine you would
have to
do this - but would like to make sure.


If anyone knows how to configure this correctly, or indeed whether Tomcat is
erally
able to do this - I would be very grateful. 


The rest of my config is as follows -

Cheers,
JP


conf\server.xml
...

...

...

conf\tomcat-users.xml







FXE\WEB-INF\web.xml
http://java.sun.com/dtd/web-app_2_3.dtd";>



AServlet


TheServlet
com.rbsfm.fxe.TheServlet



TheServlet
/TheServlet



Role based security constraint

Protected
Area
/TheServlet


tomcat



CONFIDENTIAL




CLIENT-CERT



tomcat





Jon-Paul Stanford

eCommerce Development - Financial Markets 
The Royal Bank of Scotland 
135 Bishopsgate
London 
EC2M 3UR 
Tel: 020 7375 5360




  Visit our Internet site at http://www.rbsmarkets.com

This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.


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

DO NOT REPLY [Bug 5405] New: - Powered by Tomcat

[bugzilla]

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

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

Powered by Tomcat

   Summary: Powered by Tomcat
   Product: Tomcat 4
   Version: Unknown
  Platform: All
   URL: http://www.mobic.com/images/tomcat/poweredbytomcatlarge.
gif
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi

I searched for a "Powered by Tomcat" on the site, but did not find any. So I 
had to make one, and I suppose others have the same need.

On the url, you find a large version, a small version is available at:

http://www.mobic.com/images/tomcat/poweredbytomcat.gif

Feel free to make the images available for all users, or make a better one

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

[PROPOSAL] Multi-localization of a Tomcat 4 startup page

[Kazuhiro Kazama]

Dear Tomcat 4 committers,

I would like to propose multi-localization of a Tomcat 4 startup page
(CATALINA_HOME/webapps/ROOT/index.html). 

For example, Apache Web server has already provided a MultiView
function for this purpose and use it for multi-localized startup page.
And Tomcat 3.x has such function implemented by Arieh Markel.

But Tomcat 4 don't have such function. Therefore I propose the
following alternative approach using JSP 1.2's dynamic content type:

<%@ page import="java.io.*" %>
<%@ page import="java.util.Locale" %>
<%
String language = "en";
String encoding = "iso-8859-1";
String file = "index.html";
Locale locale = request.getLocale();
if (locale != null) {
language = locale.getLanguage();
}
if (language.equalsIgnoreCase("ja")) {
encoding = "shift_jis";
} else if (language.equalsIgnoreCase("en")) {
encoding = "iso-8859-1";
}

InputStream in;
if ((in = config.getServletContext().getResourceAsStream(file + "." + 
language)) != null) {
response.setContentType("text/html; charset=" + encoding);
} else {
in = config.getServletContext().getResourceAsStream(file);
encoding = "iso-8859-1";
response.setContentType("text/html");
}
BufferedReader reader = new BufferedReader(new InputStreamReader(in, 
encoding));
String line;
while ((line = reader.readLine()) != null) {
out.println(line);
}
%>

In short, this script has the following functions:

1, According to language specified by user's HTTP request, Tomcat
select a startup page. Its naming scheme is the same as Apache Web
Server, not Tomcat 3.x.

2, If there is no startup page written in the specified language,
Tomcat returns default page named "index.html".

Now there are some problems in this code. For example, the relation
between a language and a charset is hardcoded. In Tomcat 4,
org.apache.tomcat.util.http.LocaleToCharsetMap class provides the
mapping but it isn't in Servlet API. Such class is desirable in
Servlet API 2.4.

Anyway, I am ready to provide Japanese translations of startup pages
(webapps/ROOT/index.html and webapps/webdav/index.html) if this
proposal (or alternative proposal) will be accepted,

I am one of Japanese Tomcat volunteers which Craig has already
announced in this mailing-list (Thank you, Craig!). We are trying to
translate all Tomcat documents but it takes more time.

Kazuhiro Kazama ([EMAIL PROTECTED]) NTT Network Innovation Laboratories

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

DO NOT REPLY [Bug 5404] New: - Can't set username/password in JDBCRealm with mysql driver

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

Can't set username/password in JDBCRealm with mysql driver

   Summary: Can't set username/password in JDBCRealm with mysql
driver
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: Other Connectors
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hello,
I'm using the JDBCRealm with mmmysqldriver (latest release, 2.0.7).
I have the following problem: it seems like the driver can't "see" the user and 
password information I set in the connectionURL attribute, so I can connect to mysql 
only if I leave no user/password restriction on the user table in mysql.
Since this is a great security risk, I would like to understand how to overcome this 
problem.
Checking the documentation of mysql driver seems like it requires an URL of this 
kind:
jdbc:mysql://localhost/tomcat?user=xxx&password=yyy
while the  tag not allows the use of an ampersand in the connectionURL 
attribute, infact the example given is:
jdbc:mysql://localhost/tomcat?user=xxx;password=yyy
Notice the use of ";" in place of the "&"

Where am I wrong?
A little help would be very appreciated.

Thanks,
Alex

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