cvs commit: jakarta-tomcat-connectors KEYS

[mturk]

mturk   2003/01/10 23:59:11

  Modified:.KEYS
  Log:
  Change my PGP Signing key
  
  Revision  ChangesPath
  1.10  +27 -27jakarta-tomcat-connectors/KEYS
  
  Index: KEYS
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/KEYS,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- KEYS  27 Nov 2002 08:20:30 -  1.9
  +++ KEYS  11 Jan 2003 07:59:11 -  1.10
  @@ -166,35 +166,35 @@
   -END PGP PUBLIC KEY BLOCK-
   
   Type Bits/KeyID Date   User ID
  -pub  1024D/881EBC94 2002/11/27 Mladen Turk <[EMAIL PROTECTED]>
  +pub  1024D/564C17A3 2003-01-11 Mladen Turk <[EMAIL PROTECTED]>
   
   -BEGIN PGP PUBLIC KEY BLOCK-
   Version: GnuPG v1.0.6 (MingW32)
   
  -mQGiBD3kfmsRBAD02S+HNaMX+TNdMIFs1PEEwSBOxoFd8Mh51nt8eS5Kp9+v747Q
  -lQIUPgmhOWWQa33HGapTe3b9CQuc9mGf1eR0NyRK5S2hjoYkEb7oPVNL5PMDcJ5M
  -uwBSU7pG1LossNUuhsTgEQdFR4gci+ElPilQtUriv1O579YkNNVwRDUBtwCg9fcq
  -DNvStKj67bvzGIRrr99w2MMEAOxCHKBd69uFzPkL0+7lFoJY/IyW6xJaCXWQGE8g
  -P9ZgWtfYDLliuUhsmGP10JxuAYEOk3cMGy84a7ez589GWqGXXutpJmX3lY/cr8G+
  -fyIT0MWxCDkKpyxz5k3XaCYigKbxrrJ+HhP7R9cZsC9kj18q9mWdku24sLEdhA+g
  -ewNcBADPghjTG6HOFCJb3xS6r3dbI3JVREyVPOSCWJY+A6RrRHfY4Ohw0zTt9zLi
  -OpuBdrpNE64bh3ftQhXg33A61fdJ19WS6YJ2WdwKlQtUiA60m8/D9qAwebuJ+1yM
  -LaUw3UUA5c38BiOgGND3bQp09fOR/JL5rYMopnZngByokc1AwbQ9TWxhZGVuIFR1
  -cmsgKE1sYWRlbiBUdXJrIFNpZ25pbmcgS2V5KSA8bXR1cmtAbWFwcGluZ3NvZnQu
  -Y29tPohdBBMRAgAdBQI95H5rBQkSz/eABQsHCgMEAxUDAgMWAgECF4AACgkQ0gmc
  -8IgevJSonACfRTku5Y3bBbpG7stbMv2TiojjKxAAoJq170XCq4kvBiJHhfqcKL0v
  -v9c9uQINBD3kfngQCADen9IZs4qYqkBZ0Hq3Qk0sMClrsSBnh6bKYXUlmjb3YMo8
  -i9m7CiwYIowElHvBRBw/0KFWIvwGAk2hcRuSN6nmR3Lnt8iw9Q68zJBAN8SeD0FP
  -pQ2Riv9tKeVfQyyOt4hzANLGV2JTk47eOrIyAskRfgR2RdMv5sn/gv8LjDBTE7rE
  -X4UW1xrtHI9mLQ7kbPLErLBA03S3HZX/dZQUF7+rd1oZYIfo54SgCu3YWwCA1zqb
  -fQXjcKjgRBf62AlvDAjHdVDGd9uGU8w64zs8yyQSFM0mJ91Gn3YUE2qEF7yV7NKT
  -fgiSTXlCWCp/IRQBwSj9qhbt08zbE9/LLfLD4ZMvAAMHCADCPYBsfyRdYdoeruFw
  -4Zf5Vh14jzHH2PJmKQgEmgIEMIAaU6vU/skHMFz9e7NXCBS7YXkjG6trLG/BGb7R
  -kI/lZpIQ9za/NeHQuxaOHCJuP9vcNpjeSWToF40C39Bdnu6I6Lf68DJQo5zxqfnD
  -XBRXQEB62S9irNEn/BP5pXjPrqWBJEkUVo/JnEDL+ljUfYXR1oqul35pvVa2XOrV
  -0VsWkkEQn/ZmYhmnt+HDWmne+CZi8N9n6uoO9YZSMneBIBbN7j8SFlzmrXLZlwRU
  -sPE74k9kxWWSvvIX+JZVs03oRARrNbVvoArWSlWPhGmqgva3N04m+sWYECfFWU68
  -YB2OiEwEGBECAAwFAj3kfngFCRLP94AACgkQ0gmc8IgevJT9PACfZbZeXuiTvTWc
  -ECLcb/hHsrA+NEMAoOvwi2DsvrSry/4HC6WaNx7xlIes
  -=PiR7
  +mQGiBD4fwXIRBAC7WRS8PYxi2YH0T1mX4HCYsF8aHoqxBzMnyFR4J896m1s96vGM
  +BTSAwH2NKbiVqtfLokTbQkUVxtrgrF2HMB5NfYBg/JzT7pZL/Q2ThWUS7SJQQA4f
  +a7/DpiLiHalp6iX45om6JTdIWEyXv26csIVhmtlkGBEPRhNRX8X4//BM0wCg7wcA
  +yQ7c5NmoOJLVs+uHsRrnHo0D/R/dMyuWt7/o0eGIEuRlDl2q+YL8xLuVyJMXQBnd
  +jo7jKpQ+Q1zl93aVTzsJa7mP2zZ7jqaJ855sdz6rvwyhGF1/qYMtm6zrmgBy2XPm
  +J+57sfwSZr0bhIeMpCWjIw98z9sObq0v2r2oA3+J9E3Na/BZsCVTZVb3ew7ILmEp
  +F5D7A/4zvjY41dakCAJsD1Xo8TS6hSqJf4zq9vX3ayJVvUjeo8n4sHNOwcbEnnui
  +9zZaUH3F0x+3cDo7mS1Y4pD8THuqCZoSbSkiHnlved6nLXsKbqvVrVo+esEhfZCn
  +Iji3gp+2TVNwdHXGM+4BAzMJCLsdXjByO6SNzB9a+H8RsRlZKrQ8TWxhZGVuIFR1
  +cmsgKCoqKiBERUZBVUxUIFNJR05JTkcgS0VZICoqKikgPG10dXJrQGFwYWNoZS5v
  +cmc+iF0EExECAB0FAj4fwXIFCRLP94AFCwcKAwQDFQMCAxYCAQIXgAAKCRAcUGQH
  +VkwXo0jxAKCgHzXPIB4IAgoD7GMAohPQfX7j2QCeL6pAsf4pPufmPvbrrpDp6rQH
  +GOS5Ag0EPh/BhhAIAKWzq7+/+nNYGpc7sXGkDNo9xncxcx/KbbJVT0rBteuaonQ4
  +vYar1ITjIhOPmF9yPmpUddNrqgQTSO+Or+ZrVOndn+qC1gdY3qpKIN3KTjXloW38
  +0Y84ezwdRLznQNkhgXwNcB55l/Z9kLaW2MS8CJzOuYSQT1CYbXg7XP3684ZmV1KC
  +cGgcUt9VkIGqwsa2RFDNGvMbySedSkJ/70Q+PJlkXN+W86f8hi3HTjw2MCkNa5NL
  ++Byg8FEAm95YWrO6kCY3qaJYV7NRt9oVd+2V/NNzwYp3Or/QoYofvfNerupfwBmU
  +GEXPyZCqqNH6nDv6chscsWvEA9KzhsWnsdKhmHsAAwUH/R6LwfWgtpaO42dQI4ZS
  +VRBmCeWrXCuyVk0d13Yz0xLi5Z5m4g3MON3d+cRVUiyNX+hbDGpi2mkbsnL559Ef
  +iqmzDmSz5GQHDutolhOPtLxLrC537ODn2q7hnYQwIQYYIUtYD5sYlzfGYC8olGCB
  +IcKIdlGRWcxxiFCIJm5CX/jnSBsyDRpanlSrdkxhzAGsifqj4NQ19ayoeNoZg2ZP
  +9SLIY7vbmOxJeHEYkx8AG25xOY1PLotb/0buSXPB8e71zb/DCV1rAhhUxAr/2JOQ
  +RqlZBq6PfcHKLRitXRCeVvfldRxuWBIzhuTLUfRPYR6phjP50EzZPlbJzIvGwsOI
  +RheITAQYEQIADAUCPh/BhgUJEs/3gAAKCRAcUGQHVkwXoy0JAJ9WTfqfYzW/F6qi
  +5MxmqDnU9/G+6ACfQVmhZNnGTSfcwQCttwCaW3CRhDY=
  +=MWUr
   -END PGP PUBLIC KEY BLOCK-
  
  
  

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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

[costin]

costin  2003/01/10 23:08:33

  Modified:coyote/src/java/org/apache/coyote BaseHook.java
  Log:
  Added NotificationListener.
  
  JMX notifications are not as flexible - I really don't know
  what is the best solution here. Less flexibility might be very
  good - it can keep things simpler.
  
  I'll add a BaseNotification to modeler - with an int code,
  notes, etc. And then I'll try to find a way to use standard
  notifications side-by-side with the native mechanism ( ActionCode ).
  
  Opinions ?? I'm not very sure...
  
  Revision  ChangesPath
  1.2   +26 -4 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/BaseHook.java
  
  Index: BaseHook.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/BaseHook.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- BaseHook.java 10 Jan 2003 22:36:43 -  1.1
  +++ BaseHook.java 11 Jan 2003 07:08:33 -  1.2
  @@ -61,6 +61,8 @@
   import javax.management.MBeanRegistration;
   import javax.management.ObjectName;
   import javax.management.MBeanServer;
  +import javax.management.NotificationListener;
  +import javax.management.Notification;
   
   
   /**
  @@ -69,21 +71,33 @@
* @author Remy Maucherat
* @author Costin Manolache
*/
  -public class BaseHook implements ActionHook, MBeanRegistration {
  +public class BaseHook
  +implements ActionHook, MBeanRegistration, NotificationListener
  + {
   protected BaseHook next;
   
   /**
  + * XXX DO WE REALLY NEED THIS ? handleNotification should be enough !!
  + *
* Send an action to the connector.
* Both recursive and iterative invocation is possible - the
* hook may call itself the next hook ( like catalina ) or the
* controller may call the next.
  - * 
  + *
  + * The call pattern for this is:
  + *   while( hook!=null ) {
  + *  hook=action( code, param );
  + *   }
  + * If the hooks has special needs - it can call next itself and decide
  + * to return null or whatever the next hook returned.
  + *
  + * The reason for iterative calls - smaller stacks ( and stack traces ).
  + *
* @param param Action parameter
* @return  A hook that can be executed next.
*/
   public BaseHook action(int code, Object param) {
  -if( next==null ) return next;
  -return next.action( code, param );
  +return next;
   };
   
   /** Backward compat
  @@ -134,5 +148,13 @@
   public void postDeregister() {
   }
   
  +//  Notification listener  
  +
  +public void handleNotification(Notification notification, Object handback) {
  +// we need a special CoyoteNotification that will include the code
  +// and param.
  +
  +// It would be better to use a generic class in modeler.
  +}
   
   }
  
  
  

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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java

[costin]

costin  2003/01/10 22:55:24

  Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
  Log:
  Update ThreadPool.
  
  Revision  ChangesPath
  1.7   +20 -51
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
  
  Index: ThreadPool.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- ThreadPool.java   24 Dec 2002 17:02:54 -  1.6
  +++ ThreadPool.java   11 Jan 2003 06:55:24 -  1.7
  @@ -147,6 +147,18 @@
   stopThePool = false;
   }
   
  +
  +public static ThreadPool createThreadPool() {
  +try {
  +Class.forName( "org.apache.commons.modeler.Registry");
  +Class tpc=Class.forName( "org.apache.tomcat.util.threads.ThreadPoolMX");
  +ThreadPool res=(ThreadPool)tpc.newInstance();
  +return res;
  +} catch( Exception ex ) {
  +}
  +return new ThreadPool();
  +}
  +
   public synchronized void start() {
stopThePool=false;
   currentThreadCount  = 0;
  @@ -295,7 +307,7 @@
   }
   }
   
  -// If we are here it means that there is a free thred. Take it.
  +// If we are here it means that there is a free thread. Take it.
   c = pool[currentThreadCount - currentThreadsBusy - 1];
   currentThreadsBusy++;
   }
  @@ -371,7 +383,9 @@
   return;
   }
   
  +// atomic
   currentThreadsBusy--;
  +
   pool[currentThreadCount - currentThreadsBusy - 1] = c;
   notify();
   }
  @@ -424,6 +438,10 @@
   }
   }
   
  +/** Create missing threads.
  + *
  + * @param toOpen Total number of threads we'll have open
  + */
   protected void openThreads(int toOpen) {
   
   if(toOpen > maxThreads) {
  @@ -636,10 +654,7 @@
* @param toRun
*/
   public synchronized void runIt(ThreadPoolRunnable toRun) {
  - if( toRun == null ) {
  - throw new NullPointerException("No Runnable");
  - }
  -this.toRun = toRun;
  + this.toRun = toRun;
// Do not re-init, the whole idea is to run init only once per
// thread - the pool is supposed to run a single task, that is
// initialized once.
  @@ -659,52 +674,6 @@
   public synchronized void terminate() {
   shouldTerminate = true;
   this.notify();
  -}
  -}
  -
  -/** Special thread that allows storing of attributes and notes.
  - *  A guard is used to prevent untrusted code from accessing the
  - *  attributes.
  - *
  - *  This avoids hash lookups and provide something very similar
  - * with ThreadLocal ( but compatible with JDK1.1 and faster on
  - * JDK < 1.4 ).
  - *
  - * The main use is to store 'state' for monitoring ( like "processing
  - * request 'GET /' ").
  - */
  -public static class ThreadWithAttributes extends Thread {
  -private Object control;
  -public static int MAX_NOTES=16;
  -private Object notes[]=new Object[MAX_NOTES];
  -private Hashtable attributes=new Hashtable();
  -private String currentStage;
  -
  -public ThreadWithAttributes(Object control, Runnable r) {
  -super(r);
  -this.control=control;
  -}
  -
  -public void setNote( Object control, int id, Object value ) {
  -if( this.control != control ) return;
  -notes[id]=value;
  -}
  -
  -public String getCurrentStage() {
  -return currentStage;
  -}
  -
  -public void setCurrentStage(String currentStage) {
  -this.currentStage = currentStage;
  -}
  -
  -public Object getNote(Object control, int id ) {
  -if( this.control != control ) return null;
  -return notes[id];
  -}
  -
  -public Hashtable getAttributes(Object control) {
  -return attributes;
   }
   }
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadWithAttributes.java

[costin]

costin  2003/01/10 22:53:43

  Added:   util/java/org/apache/tomcat/util/threads
ThreadWithAttributes.java
  Log:
  Moved ThreadWithAttribute out of ThreadPool.
  
  All attribute operations are guarded by ThreadPool - if an application
  has a reference to ThreadPool, it can get/set attributes.
  
  The cost is one cast and a method access.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadWithAttributes.java
  
  Index: ThreadWithAttributes.java
  ===
  package org.apache.tomcat.util.threads;
  
  import java.util.Hashtable;
  
  /** Special thread that allows storing of attributes and notes.
   *  A guard is used to prevent untrusted code from accessing the
   *  attributes.
   *
   *  This avoids hash lookups and provide something very similar
   * with ThreadLocal ( but compatible with JDK1.1 and faster on
   * JDK < 1.4 ).
   *
   * The main use is to store 'state' for monitoring ( like "processing
   * request 'GET /' ").
   */
  public class ThreadWithAttributes extends Thread {
  private Object control;
  public static int MAX_NOTES=16;
  private Object notes[]=new Object[MAX_NOTES];
  private Hashtable attributes=new Hashtable();
  private String currentStage;
  private Object param;
  
  public ThreadWithAttributes(Object control, Runnable r) {
  super(r);
  this.control=control;
  }
  
  /** Notes - for attributes that need fast access ( array )
   * The application is responsible for id management
   */
  public final void setNote( Object control, int id, Object value ) {
  if( this.control != control ) return;
  notes[id]=value;
  }
  
  /** Information about the curent performed operation
   */
  public final String getCurrentStage(Object control) {
  if( this.control != control ) return null;
  return currentStage;
  }
  
  /** Information about the current request ( or the main object
   * we are processing )
   */
  public final Object getParam(Object control) {
  if( this.control != control ) return null;
  return param;
  }
  
  public final void setCurrentStage(Object control, String currentStage) {
  if( this.control != control ) return;
  this.currentStage = currentStage;
  }
  
  public final void setParam( Object control, Object param ) {
  if( this.control != control ) return;
  this.param=param;
  }
  
  public final Object getNote(Object control, int id ) {
  if( this.control != control ) return null;
  return notes[id];
  }
  
  /** Generic attributes. You'll need a hashtable lookup -
   * you can use notes for array access.
   */
  public final Hashtable getAttributes(Object control) {
  return attributes;
  }
  }
  
  
  

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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPoolMX.java

[costin]

costin  2003/01/10 22:52:27

  Added:   util/java/org/apache/tomcat/util/threads ThreadPoolMX.java
  Log:
  Added a "JMX" extension to threadpool.
  
  This will keep the ThreadPool independent of JMX.
  
  Also added few "informative" methods to display the threads and
  the status of each thread. ( I need to commit few changes in
  http and jk connector to take provide this info )
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPoolMX.java
  
  Index: ThreadPoolMX.java
  ===
  /*
   *
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   * [Additional notices, if required by prior licensing conditions]
   *
   */
  
  package org.apache.tomcat.util.threads;
  
  import java.util.*;
  import org.apache.commons.logging.Log;
  import org.apache.commons.logging.LogFactory;
  import org.apache.commons.modeler.Registry;
  
  /**
   * Manageable thread pool
   *
   * @author Costin Manolache
   */
  public class ThreadPoolMX extends ThreadPool {
  static Log log = LogFactory.getLog(ThreadPoolMX.class);
  Registry reg;
  protected String domain;
  
  protected String name;
  
  public ThreadPoolMX() {
  super();
  }
  
  public void setDomain(String domain) {
  this.domain=domain;
  }
  public String getDomain() {
  return domain;
  }
  
  public String getName() {
  return name;
  }
  
  public void setName(String name) {
  this.name=name;
  reg=Registry.getRegistry();
  try {
  reg.registerComponent(this, domain, "ThreadPool",
  "name=" + name);
  } catch( Exception ex ) {
  log.error( "Error registering thread pool", ex );
  }
  }
  
  public synchronized void start() {
  super.start();
  }
  
  public void addThread( Thread t, ControlRunnable cr ) {
  threads.put( t, cr );
  for( int i=0; i");
  while( it.hasNext()) {
  sb.append("");
  ThreadWithAttributes twa=(ThreadWithAttributes)
  it.next();
  sb.append(twa.getCurrentStage(this) ).append(" 

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

[Costin Manolache]

Bill Barker wrote:

>> Jeanfrancois Arcand wrote:
>>
>> > Hi Costin, (you beat me on the proposal :-) )
>>
>> Actually - this is a different story ( JMX-enabling different componets).
>> I'll check in similar additions to ValveBase, BaseContainer,
>> CoyoteConnector.
>>
> 
> I currently have custom Valves in 4.1.x that *don't* extend ValveBase (I
> feel strongly that my code shouldn't depend on anything other than
> o.a.catalina), which work quite well with JMX.   I'd really hate to lose
> this for 5.x.

I think it's ok. You can either implement MBeanRegistration - or just
do nothing. The main purpose of this addition is to have a consistent
getObjectName and getDomain, as well as access to the mbean server. 

I would also like to use the attributes from the name - and attach
the valve to the right component in preRegister(). Not sure if it's
worth it - but it could be usefull.

The problem with interfaces is that if you add a method, all
implementations will need to be changed. 

> Of course, the current JDK1.4.x dependency of 5.x prevents me from even
> thinking about using it  ;-).

Do we still have a 1.4 dependency ? We should fix that.

I just run it with JDK1.3 - and seemed fine.

Costin


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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves AccessLogValve.java

[costin]

costin  2003/01/10 21:12:48

  Modified:catalina/src/share/org/apache/catalina/valves
AccessLogValve.java
  Log:
  I did that long ago - it just add %D to display the time in millis
  ( like in apache )
  Usefull for people with fast servlets :-)
  
  Revision  ChangesPath
  1.3   +13 -5 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java
  
  Index: AccessLogValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- AccessLogValve.java   22 Nov 2002 22:23:44 -  1.2
  +++ AccessLogValve.java   11 Jan 2003 05:12:48 -  1.3
  @@ -118,7 +118,8 @@
* %u - Remote user that was authenticated
* %U - Requested URL path
* %v - Local server name
  - * 
  + * %D - Time taken to process the request, in millis
  +  * 
* In addition, the caller can specify one of the following aliases for
* commonly utilized patterns:
* 
  @@ -506,8 +507,13 @@
   throws IOException, ServletException {
   
   // Pass this request on to the next valve in our pipeline
  +long t1=System.currentTimeMillis();
  +
   context.invokeNext(request, response);
   
  +long t2=System.currentTimeMillis();
  +long time=t2-t1;
  +
   Date date = getDate();
   StringBuffer result = new StringBuffer();
   
  @@ -617,10 +623,10 @@
   } else {
   //D'oh - end of string - pretend we never did this
   //and do processing the "old way"
  -result.append(replace(ch, date, request, response));
  +result.append(replace(ch, date, request, response, 
time));
   }
   } else {
  -result.append(replace(ch, date, request, response));
  +result.append(replace(ch, date, request, response,time ));
   }
   replace = false;
   } else if (ch == '%') {
  @@ -756,7 +762,7 @@
* @param response Response being processed
*/
   private String replace(char pattern, Date date, Request request,
  -   Response response) {
  +   Response response, long time) {
   
   String value = null;
   
  @@ -798,6 +804,8 @@
   value = "";
   } else if (pattern == 'p') {
   value = "" + req.getServerPort();
  +} else if (pattern == 'D') {
  +value = "" + time;
   } else if (pattern == 'q') {
   String query = null;
   if (hreq != null)
  
  
  

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

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

[costin]

costin  2003/01/10 21:07:50

  Modified:catalina/src/share/org/apache/catalina/core
ContainerBase.java
  Log:
  Let ContainerBase know its own name ( and domain )
  
  We can't change the Container interface ( that would break backward
  compat ), but there is no need - all tomcat containers extend
  ContainerBase and external containers can do their own JMX interaction.
  
  Revision  ChangesPath
  1.3   +51 -9 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java
  
  Index: ContainerBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ContainerBase.java5 Nov 2002 21:31:14 -   1.2
  +++ ContainerBase.java11 Jan 2003 05:07:50 -  1.3
  @@ -1,8 +1,4 @@
   /*
  - * $Header$
  - * $Revision$
  - * $Date$
  - *
* 
*
* The Apache Software License, Version 1.1
  @@ -76,13 +72,16 @@
   import java.util.Iterator;
   import javax.servlet.ServletException;
   import javax.naming.directory.DirContext;
  +import javax.management.ObjectName;
  +import javax.management.MBeanRegistration;
  +import javax.management.MBeanServer;
  +
   import org.apache.naming.resources.ProxyDirContext;
   import org.apache.catalina.Cluster;
   import org.apache.catalina.Container;
   import org.apache.catalina.ContainerEvent;
   import org.apache.catalina.ContainerListener;
   import org.apache.catalina.Lifecycle;
  -import org.apache.catalina.LifecycleEvent;
   import org.apache.catalina.LifecycleException;
   import org.apache.catalina.LifecycleListener;
   import org.apache.catalina.Loader;
  @@ -160,8 +159,10 @@
*/
   
   public abstract class ContainerBase
  -implements Container, Lifecycle, Pipeline {
  +implements Container, Lifecycle, Pipeline, MBeanRegistration {
   
  +private static org.apache.commons.logging.Log log=
  +org.apache.commons.logging.LogFactory.getLog( ContainerBase.class );
   
   /**
* Perform addChild with the permissions of this class.
  @@ -1460,7 +1461,48 @@
   
   }
   
  -private static org.apache.commons.logging.Log log=
  -org.apache.commons.logging.LogFactory.getLog( ContainerBase.class );
  +//  JMX and Registration  
  +protected String domain;
  +protected String suffix;
  +protected ObjectName oname;
  +protected MBeanServer mserver;
  +
  +public ObjectName getObjectName() {
  +return oname;
  +}
  +
  +public String getDomain() {
  +return domain;
  +}
  +
  +public String getJSR77Suffix() {
  +return suffix;
  +}
  +
  +public ObjectName preRegister(MBeanServer server,
  +  ObjectName name) throws Exception {
  +oname=name;
  +mserver=server;
  +domain=name.getDomain();
  +String j2eeApp=name.getKeyProperty("J2EEApplication");
  +String j2eeServer=name.getKeyProperty("J2EEServer");
  +if( j2eeApp==null ) {
  +j2eeApp="none";
  +}
  +if( j2eeServer==null ) {
  +j2eeServer="none";
  +}
  +suffix=",J2EEApplication=" + j2eeApp + ",J2EEServer=" + j2eeServer;
  +return name;
  +}
  +
  +public void postRegister(Boolean registrationDone) {
  +}
  +
  +public void preDeregister() throws Exception {
  +}
  +
  +public void postDeregister() {
  +}
   }
   
  
  
  

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

JSR77 names for Context ( and ServletWrapper )

[Costin Manolache]

I'm not very familiar with the /admin - how difficult 
would it be to change the naming format for Contexts ? 

JSR77 defines some pretty clear names for Context and Servet -
and I think we should use that where possible. 

Another issue I have is the name of the Valves, which uses
the hashcode of the valve object. I would preffer to have 
an easier form - a counter indicating the position of the valve
in the chain ( unique for the container where the valve is attached ).

Again - need help with the /admin.

Finally, the issue of "domain". In JSR77 ( and in general ) 
the domain can be used to create separate namespaces - and I think
the "domain" should match the engine name and the jsrRoute. That
would simplify a lot:
 - a domain represents a particular tomcat Engine. 
 - each engine must have a unique identifier
 - this will be used for load balancing ( as jvmRoute - no longer separate 
config )
 - it will also be visible in the JMX console. Assuming remote-JMX
is supported - each tomcat will be visible in a separate domain.
 - you can have multiple Engines in the same VM ( just like today ),
but each will have a separate domain and will be completely separated
from each other.

Not sure if the /admin is using the domain somehere.

Opinions ? Anyone willing to help ? 


Costin


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

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

[Bill Barker]

- Original Message -
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 10, 2003 8:16 PM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java


> Jeanfrancois Arcand wrote:
>
> > Hi Costin, (you beat me on the proposal :-) )
>
> Actually - this is a different story ( JMX-enabling different componets).
> I'll check in similar additions to ValveBase, BaseContainer,
> CoyoteConnector.
>

I currently have custom Valves in 4.1.x that *don't* extend ValveBase (I
feel strongly that my code shouldn't depend on anything other than
o.a.catalina), which work quite well with JMX.   I'd really hate to lose
this for 5.x.

Of course, the current JDK1.4.x dependency of 5.x prevents me from even
thinking about using it  ;-).

> The idea is for each component to be aware of its name and domain,
> and to "bridge" whatever notification/hook mechanism into JMX
> notifications.
>
> I don't think we need an additional extension mechansim - for all
> that I need I think JMX notifications are good enough. I don't
> know how hard ( or usefull ) it is to bridge all existing extension
> points, but at least the connector should be able to send JMX
notifications
> and it can easily use this model for its own needs.
>
>
>
> > what about having a concept of a chain somewhere (meaning hooks chain
> > (handler :-) ). This way handler doesn't need to know which comes next
> > (or previous), but the handler chain knows it. What I was having in mind
> > was being able to define somewhere:
>
> I'm ok with that too. Valves have a Next - and I assumed many people
> preffer this model ( and it involves fewer interfaces :-).
> My only requirement is to be able to use it in iterative mode too
> ( I don't like the long stack traces and I feel better with iterative).
>
> For configuration: I would be -1 for any new API / tomcat-specific config
> format.
>
> All configuration should be done using JMX. I have no doubt about
> it ( well, JMX has its limitations, but the general model of
> manageable components with light coupling is essential ).
>
> Instead of param-name/value - use JMX attributes. The handler is a JMX
> component. For registration - I think we should use the standard JMX
> notifications ( or your proposed API if JMX proves too complicated or
> we can't get around its limitations )
>
> We could use a Chain MBean component where you declare ( as attributes )
> the various hooks in the chain. ActionCode will correspond to a Chain.
> That may be very nice - allowing hooks to be inserted at runtime, etc.
>
>
>
> > 
> >  But I think the HandlerContext should just be an instance
> of Notification ( with added notes and an int notification
> code for faster dispatch ).
>
> > Finally, that looks like a small proposal ;-)
>
> My preference is to try to just use JMX.
>
> It is not perfect - but I think it's good enough and we'll
> benefit more by using a standard and well-known API.
>
> Costin
>
>
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


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

Re: Duplicate session IDs are *common*

[Phil Steitz]

Dirk-Willem van Gulik wrote:


On 10 Jan 2003, Eric Rescorla wrote:



There's nothing wrong with what you propose, but it's sort of
like saying "maybe I should wear a helmet at all times
because a meteor might drop on my head". Sure, it could happen,
btu it's not the thing I'd worry about.



Except that hash( i++ . secret).i is generally a lot cheaper and easier to
code cross platform than using a true cryptographic random generator with
the right tie in with hardware. And it happens to have a hard-hat aspect
thrown in as a freebee.

Dw



Unfortunately, hashing blows away guaranteed uniqueness ("one-way" => 
not 1-1), so if your last step is a hash, you will need to keep the 
meteor helmets handy.  The "uniqueness bits" need to be either left 
alone or encrypted to preserve uniqueness of the result.

I strongly agree with Eric, however, that it is *incredibly* unlikely 
that the multiple reports of apparent collisions are in fact due to 
Tomcat's (unpatched) session key generation algorithm.  I ran some tests 
last year on an algorithm very similar to what Tomcat uses (using SHA-1 
instead of MD5 after adding some other stuff to the bytes from 
SecureRandom) and I found that the empirical probablility distribution 
of the number of matching bytes in pairs of generated strings followed 
the expected binomial distribution almost exactly.  Among other things, 
this implies that the probability of an exact match among two such 
strings really is 1/2^n where n is the number of bits in the strings. It 
also supports the expectation that if you generate m strings, the 
probability that any two of them are identical is less than C(m,2)/2^n 
(where C(m,2) = m(m-1)/2 -- the number of pairs that you can make among 
the m strings). To illustrate how silly the helmets look, here are some 
examples:

n = 128,  m = 1 => p(collision) < 1.5 E-31
n = 128,  m = 10 => p(collision) < 1.5 E-29
n = 128,  m = 100 => p(collision) < 1.5 E-27
n = 64, m = 100 => p(collision) < 2.7 E-8
...
n = 128, m = 2^64 ~ 3.4 E+38 => p(collision) < .5
(Eric's "reasonable chance" threshold)

If end users are reporting session collisions, this means that they must 
be happening with frequency too large to reasonably attribute to chance. 
  Therefore, either the applications or Tomcat itself must have some 
concurrency problems independent of the session ID generation.

-Phil


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






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

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

[Costin Manolache]

Jeanfrancois Arcand wrote:

> Hi Costin, (you beat me on the proposal :-) )

Actually - this is a different story ( JMX-enabling different componets).
I'll check in similar additions to ValveBase, BaseContainer, 
CoyoteConnector.

The idea is for each component to be aware of its name and domain, 
and to "bridge" whatever notification/hook mechanism into JMX
notifications.

I don't think we need an additional extension mechansim - for all
that I need I think JMX notifications are good enough. I don't
know how hard ( or usefull ) it is to bridge all existing extension
points, but at least the connector should be able to send JMX notifications
and it can easily use this model for its own needs.



> what about having a concept of a chain somewhere (meaning hooks chain
> (handler :-) ). This way handler doesn't need to know which comes next
> (or previous), but the handler chain knows it. What I was having in mind
> was being able to define somewhere:

I'm ok with that too. Valves have a Next - and I assumed many people 
preffer this model ( and it involves fewer interfaces :-).
My only requirement is to be able to use it in iterative mode too
( I don't like the long stack traces and I feel better with iterative).

For configuration: I would be -1 for any new API / tomcat-specific config
format.

All configuration should be done using JMX. I have no doubt about
it ( well, JMX has its limitations, but the general model of 
manageable components with light coupling is essential ).

Instead of param-name/value - use JMX attributes. The handler is a JMX 
component. For registration - I think we should use the standard JMX 
notifications ( or your proposed API if JMX proves too complicated or
we can't get around its limitations )

We could use a Chain MBean component where you declare ( as attributes )
the various hooks in the chain. ActionCode will correspond to a Chain.
That may be very nice - allowing hooks to be inserted at runtime, etc.



> 
>  Finally, that looks like a small proposal ;-)

My preference is to try to just use JMX.

It is not perfect - but I think it's good enough and we'll
benefit more by using a standard and well-known API.

Costin





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

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

[billbarker]

billbarker2003/01/10 19:00:07

  Modified:src/share/org/apache/tomcat/core Request.java
  Log:
  Make certain that the session still belong to us before returning it.
  
  If the Servlet invalidates the session, and then later requests a new one, it is 
possible for the one we have to be valid because it is now being used by somebody 
else.  Thus we have to make certain that it still belongs to us before returning it.
  
  Real Fix for bug #15894
  Reported By: Christian Wicke [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.116 +2 -0  jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java
  
  Index: Request.java
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java,v
  retrieving revision 1.115
  retrieving revision 1.116
  diff -u -r1.115 -r1.116
  --- Request.java  27 Apr 2002 03:45:18 -  1.115
  +++ Request.java  11 Jan 2003 03:00:06 -  1.116
  @@ -714,6 +714,8 @@
   public ServerSession getSession(boolean create) {
if (serverSession!=null && !serverSession.isValid())
serverSession=null;
  + if (serverSession != null && !serverSession.getId().equals(sessionId) )
  + serverSession=null;
   
if( ! create || serverSession!=null )
return serverSession;
  
  
  

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

DO NOT REPLY [Bug 15967] - IllegalStateException not thrown by HttpSession.getLastAccessedTime() if session has been invalidated.

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

IllegalStateException not thrown by HttpSession.getLastAccessedTime() if session has 
been invalidated.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-11 02:51 ---
I have added the proper exception.

Thanks :-)

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

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

[jfarcand]

jfarcand2003/01/10 18:50:06

  Modified:catalina/src/share/org/apache/catalina/session
LocalStrings.properties LocalStrings_fr.properties
StandardSession.java
  Log:
  According to the javadocs for HttpSession.getLastAccessedTime(), and 
IllegalStateException will be thrown if the session has been invalidated.
  
  PR: Bugzilla #15967
  
  Revision  ChangesPath
  1.3   +1 -0  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/LocalStrings.properties,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- LocalStrings.properties   31 Dec 2002 12:54:04 -  1.2
  +++ LocalStrings.properties   11 Jan 2003 02:50:06 -  1.3
  @@ -39,6 +39,7 @@
   standardSession.getAttribute.ise=getAttribute: Session already invalidated
   standardSession.getAttributeNames.ise=getAttributeNames: Session already invalidated
   standardSession.getCreationTime.ise=getCreationTime: Session already invalidated
  +standardSession.getLastAccessedTime.ise=getLastAccessedTime: Session already 
invalidated
   standardSession.getMaxInactiveInterval.ise=getMaxInactiveInterval: Session already 
invalidated
   standardSession.getValueNames.ise=getAttributeNames: Session already invalidated
   standardSession.notSerializable=Cannot serialize session attribute {0} for session 
{1}
  
  
  
  1.3   +2 -0  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/LocalStrings_fr.properties
  
  Index: LocalStrings_fr.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/LocalStrings_fr.properties,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- LocalStrings_fr.properties31 Dec 2002 12:54:04 -  1.2
  +++ LocalStrings_fr.properties11 Jan 2003 02:50:06 -  1.3
  @@ -61,3 +61,5 @@
   persistentManager.processSwaps=Recherche de sessions à basculer vers stockage (swap 
out), {0} sessions actives en mémoire
   persistentManager.activeSession=La session {0} a été en attente durant {1} secondes
   persistentManager.swapIn=Basculement depuis le stockage (swap in) de la session {0}
  +
  +standardSession.getLastAccessedTime.ise="getLastAccessedTime": Session 
d\u00E9j\u00E0 invalid\u00E9e
  
  
  
  1.11  +8 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java
  
  Index: StandardSession.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- StandardSession.java  31 Dec 2002 12:53:45 -  1.10
  +++ StandardSession.java  11 Jan 2003 02:50:06 -  1.11
  @@ -441,7 +441,11 @@
* a value associated with the session, do not affect the access time.
*/
   public long getLastAccessedTime() {
  +if ( !isValid ) {
  +throw new IllegalStateException(
  +sm.getString("standardSession.getLastAccessedTime"));
   
  +}
   return (this.lastAccessedTime);
   
   }
  
  
  

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

cvs commit: jakarta-tomcat-catalina/webapps/docs realm-howto.xml

[glenn]

glenn   2003/01/10 18:02:20

  Modified:webapps/docs realm-howto.xml
  Log:
  Port addition of menu to realm docs
  
  Revision  ChangesPath
  1.6   +29 -0 jakarta-tomcat-catalina/webapps/docs/realm-howto.xml
  
  Index: realm-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/realm-howto.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- realm-howto.xml   11 Jan 2003 01:57:39 -  1.5
  +++ realm-howto.xml   11 Jan 2003 02:02:20 -  1.6
  @@ -14,6 +14,32 @@
   
   
   
  +
  +
  +
  +Quick Start
  +
  +What is a Realm?
  +Configuring a Realm
  +
  +
  +Standard Realm Implementations
  +
  +JDBCRealm
  +DataSourceRealm
  +JNDIRealm
  +MemoryRealm
  +
  +Common Features
  +
  +Digested Passwords
  +Example Application
  +Manager Application
  +
  +
  +
  +
  +
   
   
   This document describes how to configure Tomcat to support container
  @@ -66,6 +92,9 @@
   Three standard plug-ins are provided, supporting connection to three different
   sources of authentication information:
   
  +DataSourceRealm - Accesses authentication
  +information stored in a relational database, accessed via a named JNDI
  +JDBC DataSource.
   JDBCRealm - Accesses authentication information
   stored in a relational database, accessed via a JDBC driver.
   JNDIRealm - Accesses authentication information
  
  
  

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

Re: JNDIRealm feature enhancements

[Glenn Nielsen]

I have applied your patch and updated the realm-howto.xml docs in
both Tomcat 4 and Tomcat 5.

Thanks for the patch.

Glenn

Bradley M. Handy wrote:

After setting up a JNDIRealm for the Manager app, I noticed after a 
while the connection times out and returns NULL automatically.  I was 
wondering, if instead of returning NULL, JNDIRealm to try to reconnect 
and then authenticate, and then return NULL, if a failure results from 
that attempt, otherwise return the JNDIRealm.User object.

 

Also I?ve notice there is no method for specifying an alternate 
connection URL in the event the URL specified in connectionURL is not 
available.  So, I took the liberty of adding an attribute ?alternateURL? 
to specify a secondary URL.  When the JNDIRealm opens a connection it 
will attempt the primary, and, upon failure, then attempt to connect to 
the alternate URL.  If this should fail, the JNDIRealm fails as it did 
before.

 

In both features the first exception is logged before the second attempt 
to connect proceeds.

 

I have attached the CVS diff between my copy of JNDIRealm and the 
current HEAD version of JNDIRealm.

 

Brad Handy

Programmer/Analyst

Spring Arbor University




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




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

cvs commit: jakarta-tomcat-catalina/webapps/docs realm-howto.xml

[glenn]

glenn   2003/01/10 17:57:39

  Modified:catalina/src/share/org/apache/catalina/realm JNDIRealm.java
   webapps/docs realm-howto.xml
  Log:
  Port JNDIRealm alternateURL patch to Tomcat 5
  
  Revision  ChangesPath
  1.4   +122 -30   
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
  
  Index: JNDIRealm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- JNDIRealm.java19 Nov 2002 01:27:59 -  1.3
  +++ JNDIRealm.java11 Jan 2003 01:57:39 -  1.4
  @@ -70,6 +70,7 @@
   import java.util.Hashtable;
   import java.util.List;
   import javax.naming.Context;
  +import javax.naming.CommunicationException;
   import javax.naming.NameNotFoundException;
   import javax.naming.NamingEnumeration;
   import javax.naming.NamingException;
  @@ -98,6 +99,10 @@
* element in the top level DirContext that is accessed
* via the connectionURL property.
*
  + * If a socket connection can not be made to the connectURL
  + * an attempt will be made to use the alternateURL if it
  + * exists.
  + *
* Each user element has a distinguished name that can be formed by
* substituting the presented username into a pattern configured by the
* userPattern property.
  @@ -188,13 +193,11 @@
   
   // - Instance Variables
   
  -
   /**
*  The type of authentication to use
*/
   protected String authentication = null;
   
  -
   /**
* The connection username for the server we will contact.
*/
  @@ -244,15 +247,15 @@
* The protocol that will be used in the communication with the directory 
server.
*/
   protected String protocol = null;
  -
  -
  +
  +
   /**
* How should we handle referrals?  Microsoft Active Directory can't handle 
* the default case, so an application authenticating against AD must 
* set referrals to "follow".
*/
   protected String referrals = null;
  -
  +
   
   /**
* The base element for user searches.
  @@ -339,11 +342,19 @@
*/
   protected boolean roleSubtree = false;
   
  -
  +/** 
  + * An alternate URL, to which, we should connect if connectionURL fails.
  + */
  +protected String alternateURL;  
  +
  +/**
  + * The number of connection attempts.  If greater than zero we use the
  + * alternate url.
  + */
  +protected int connectionAttempt = 0;
   
   // - Properties
   
  -
   /**
* Return the type of authentication to use.
*/  
  @@ -353,7 +364,6 @@
   
   }

  - 
   /**
* Set the type of authentication to use.
*
  @@ -364,8 +374,7 @@
   this.authentication = authentication;
   
   }
  -
  -
  +  
   /**
* Return the connection username for this Realm.
*/
  @@ -463,7 +472,6 @@

   }
   
  -
   /**
* Set the protocol for this Realm.
*
  @@ -491,7 +499,7 @@
   public void setReferrals (String referrals) {
   this.referrals = referrals;
   }
  -
  +
   
   /**
* Return the base element for user searches.
  @@ -723,6 +731,28 @@
   
   }
   
  +/**
  + * Getter for property alternateURL.
  + *
  + * @return Value of property alternateURL.
  + */
  +public String getAlternateURL() {
  +
  +return this.alternateURL;
  +
  +}
  +
  +/**
  + * Setter for property alternateURL.
  + *
  + * @param alternateURL New value of property alternateURL.
  + */
  +public void setAlternateURL(String alternateURL) {
  +
  +this.alternateURL = alternateURL;
  +
  +}
  +
   
   // -- Realm Methods
   
  @@ -743,15 +773,41 @@
   public Principal authenticate(String username, String credentials) {
   
   DirContext context = null;
  +Principal principal = null;
   
   try {
   
   // Ensure that we have a directory context available
   context = open();
  -
  -// Authenticate the specified username if possible
  -Principal principal = authenticate(context,
  -   username, credentials);
  +
  +// Occassionally the directory context will timeout.  Try one more
  +// time before giving up.
  +try {
  +
  +// Authenticate the specified username if possible
  + 

cvs commit: jakarta-tomcat-catalina/webapps/docs tomcat-docs.xsl

[glenn]

glenn   2003/01/10 17:52:21

  Modified:webapps/docs tomcat-docs.xsl
  Added:   webapps/docs/images printer.gif
  Log:
  Add support for generating printer friendly docs
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-catalina/webapps/docs/images/printer.gif
  
<>
  
  
  1.2   +8 -6  jakarta-tomcat-catalina/webapps/docs/tomcat-docs.xsl
  
  Index: tomcat-docs.xsl
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/tomcat-docs.xsl,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- tomcat-docs.xsl   18 Jul 2002 16:48:31 -  1.1
  +++ tomcat-docs.xsl   11 Jan 2003 01:52:21 -  1.2
  @@ -19,7 +19,7 @@
 
 
 
  -
  +  
   
 
 
  @@ -99,10 +99,12 @@
   
 
   
  -LEFT SIDE NAVIGATION
  -
  -  
  -
  +
  +  LEFT SIDE NAVIGATION
  +  
  +
  +  
  +
   
   RIGHT SIDE MAIN BODY
   
  
  
  

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

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs realm-howto.xml

[glenn]

glenn   2003/01/10 17:47:13

  Modified:.RELEASE-NOTES-4.1.txt
   catalina/src/share/org/apache/catalina/realm JNDIRealm.java
   webapps/tomcat-docs realm-howto.xml
  Log:
  Apply JNDIRealm patch to add alternateURL provided by Brad Handy
  
  Revision  ChangesPath
  1.45  +6 -1  jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
  
  Index: RELEASE-NOTES-4.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
  retrieving revision 1.44
  retrieving revision 1.45
  diff -u -r1.44 -r1.45
  --- RELEASE-NOTES-4.1.txt 10 Jan 2003 15:52:17 -  1.44
  +++ RELEASE-NOTES-4.1.txt 11 Jan 2003 01:47:13 -  1.45
  @@ -111,6 +111,11 @@
A new Realm implementation which can use a JNDI named JDBC
DataSource has been added.
   
  +[4.1.19] JNDIRealm:
  + Added support for using an alternateURL if a socket connection
  + can not be made to the provider at the connectionURL.
  +
  +
   ---
   Jasper New Features:
   ---
  
  
  
  1.11  +115 -16   
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
  
  Index: JNDIRealm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- JNDIRealm.java19 Nov 2002 01:26:38 -  1.10
  +++ JNDIRealm.java11 Jan 2003 01:47:13 -  1.11
  @@ -70,6 +70,7 @@
   import java.util.Hashtable;
   import java.util.List;
   import javax.naming.Context;
  +import javax.naming.CommunicationException;
   import javax.naming.NameNotFoundException;
   import javax.naming.NamingEnumeration;
   import javax.naming.NamingException;
  @@ -98,6 +99,10 @@
* element in the top level DirContext that is accessed
* via the connectionURL property.
*
  + * If a socket connection can not be made to the connectURL
  + * an attempt will be made to use the alternateURL if it
  + * exists.
  + *
* Each user element has a distinguished name that can be formed by
* substituting the presented username into a pattern configured by the
* userPattern property.
  @@ -337,6 +342,16 @@
*/
   protected boolean roleSubtree = false;
   
  +/** 
  + * An alternate URL, to which, we should connect if connectionURL fails.
  + */
  +protected String alternateURL;  
  +
  +/**
  + * The number of connection attempts.  If greater than zero we use the
  + * alternate url.
  + */
  +protected int connectionAttempt = 0;
   
   // - Properties
   
  @@ -716,6 +731,28 @@
   
   }
   
  +/**
  + * Getter for property alternateURL.
  + *
  + * @return Value of property alternateURL.
  + */
  +public String getAlternateURL() {
  +
  +return this.alternateURL;
  +
  +}
  +
  +/**
  + * Setter for property alternateURL.
  + *
  + * @param alternateURL New value of property alternateURL.
  + */
  +public void setAlternateURL(String alternateURL) {
  +
  +this.alternateURL = alternateURL;
  +
  +}
  +
   
   // -- Realm Methods
   
  @@ -736,15 +773,41 @@
   public Principal authenticate(String username, String credentials) {
   
   DirContext context = null;
  +Principal principal = null;
   
   try {
   
   // Ensure that we have a directory context available
   context = open();
  -
  -// Authenticate the specified username if possible
  -Principal principal = authenticate(context,
  -   username, credentials);
  +
  +// Occassionally the directory context will timeout.  Try one more
  +// time before giving up.
  +try {
  +
  +// Authenticate the specified username if possible
  +principal = authenticate(context, username, credentials);
  +
  +} catch (CommunicationException e) {
  +
  +// If not a "Socket closed." error then rethrow.
  +if (e.getMessage().indexOf("Socket closed") < 0)
  +throw(e);
  +
  +// log the exception so we know it's there.
  +log(sm.getString("jndiRealm.exception"), e);
  +
  +// close the connection so we know it will be reopened.
  +if (context != null)
  +close(context);
  +

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

[Jeanfrancois Arcand]

Hi Costin, (you beat me on the proposal :-) )

what about having a concept of a chain somewhere (meaning hooks chain 
(handler :-) ). This way handler doesn't need to know which comes next 
(or previous), but the handler chain knows it. What I was having in mind 
was being able to define somewhere:


   
  
  
   key
   value
  
 
 
   

Finally, that looks like a small proposal ;-)

--Jeanfrancois


[EMAIL PROTECTED] wrote:

costin  2003/01/10 14:36:43

 Added:   coyote/src/java/org/apache/coyote BaseHook.java
 Log:
 Added a base implementation of ActionHook - with some small additions :-)
 
 First, there is a getNext/setNext to allow multiple hooks to be chained.
 Both recursive and iterative will be supported - you can call next directly or
 just return it ( still need to tune this - only recursive works now )
 
 In addition, the hook implements MBeanRegistration ( again: we did vote on
 JMX dependency ). Tomcat3.3 may be a problem ( since it's using the same code),
 but if someone wants to use the new connector he can also add jmx in the
 path. If anyone has a problem with that - please let me know, I can hack
 some conditional compilation, but I would like to keep it simple.
 
 I'll change the 2 hook implementations to extend this after it settles down.
 
 Feel free to make changes - or ask for changes or just say -1.
 
 Revision  ChangesPath
 1.1  jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/BaseHook.java
 
 Index: BaseHook.java
 ===
 /*
  * 
  *
  * The Apache Software License, Version 1.1
  *
  * Copyright (c) 1999 The Apache Software Foundation.  All rights 
  * reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  *
  * 1. Redistributions of source code must retain the above copyright
  *notice, this list of conditions and the following disclaimer. 
  *
  * 2. Redistributions in binary form must reproduce the above copyright
  *notice, this list of conditions and the following disclaimer in
  *the documentation and/or other materials provided with the
  *distribution.
  *
  * 3. The end-user documentation included with the redistribution, if
  *any, must include the following acknowlegement:  
  *   "This product includes software developed by the 
  *Apache Software Foundation (http://www.apache.org/)."
  *Alternately, this acknowlegement may appear in the software itself,
  *if and wherever such third-party acknowlegements normally appear.
  *
  * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
  *Foundation" must not be used to endorse or promote products derived
  *from this software without prior written permission. For written 
  *permission, please contact [EMAIL PROTECTED]
  *
  * 5. Products derived from this software may not be called "Apache"
  *nor may "Apache" appear in their names without prior written
  *permission of the Apache Group.
  *
  * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
  * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
  * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
  * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
  * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
  * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
  * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  * SUCH DAMAGE.
  * 
  *
  * This software consists of voluntary contributions made by many
  * individuals on behalf of the Apache Software Foundation.  For more
  * information on the Apache Software Foundation, please see
  * .
  *
  * [Additional notices, if required by prior licensing conditions]
  *
  */ 
 package org.apache.coyote;
 
 import javax.management.MBeanRegistration;
 import javax.management.ObjectName;
 import javax.management.MBeanServer;
 
 
 /**
  * Action hook.
  *
  * @author Remy Maucherat
  * @author Costin Manolache
  */
 public class BaseHook implements ActionHook, MBeanRegistration {
 protected BaseHook next;
 
 /**
  * Send an action to the connector.
  * Both recursive and iterative invocation is possible - the
  * hook may call itself the next hook ( like catalina ) or the
  * controller may call t

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/images printer.gif

[glenn]

glenn   2003/01/10 17:18:17

  Added:   webapps/tomcat-docs/images printer.gif
  Log:
  Add a printer image for when we make printer friendly docs
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-4.0/webapps/tomcat-docs/images/printer.gif
  
<>
  
  

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets HTMLManagerServlet.java

[glenn]

glenn   2003/01/10 17:17:31

  Modified:catalina/src/share/org/apache/catalina/servlets
HTMLManagerServlet.java
  Log:
  Fix file upload install on Windows, reformat code to 80 col
  
  Revision  ChangesPath
  1.14  +40 -19
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
  
  Index: HTMLManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- HTMLManagerServlet.java   10 Jan 2003 15:52:18 -  1.13
  +++ HTMLManagerServlet.java   11 Jan 2003 01:17:31 -  1.14
  @@ -94,7 +94,7 @@
   * application deployment descriptor.  However, this requirement can be
   * relaxed during testing.
   * 
  -* The difference between this ManagerServlet and this
  +* The difference between the ManagerServlet and this
   * Servlet is that this Servlet prints out a HTML interface which
   * makes it easier to administrate.
   * 
  @@ -105,6 +105,7 @@
   *
   * @author Bip Thelin
   * @author Malcolm Edgar
  +* @author Glenn L. Nielsen
   * @version $Revision$, $Date$
   * @see ManagerServlet
   */
  @@ -165,7 +166,7 @@
   }
   
   /**
  - * Process a GET request for the specified resource.
  + * Process a POST request for the specified resource.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
  @@ -225,15 +226,25 @@
   }
   while(true) {
   if (warUpload == null) {
  -message = 
sm.getString("htmlManagerServlet.installUploadNoFile");
  +message = sm.getString
  +("htmlManagerServlet.installUploadNoFile");
   break;
   }
   war = warUpload.getName();
   if (!war.toLowerCase().endsWith(".war")) {
  -message = 
sm.getString("htmlManagerServlet.installUploadNotWar",war);
  +message = sm.getString
  +("htmlManagerServlet.installUploadNotWar",war);
   break;
   }
  -// Identify the appBase of the owning Host of this Context (if any)
  +// Get the filename if uploaded name includes a path
  +if (war.lastIndexOf('\\') >= 0) {
  +war = war.substring(war.lastIndexOf('\\') + 1);
  +}
  +if (war.lastIndexOf('/') >= 0) {
  +war = war.substring(war.lastIndexOf('/') + 1);
  +}
  +// Identify the appBase of the owning Host of this Context
  +// (if any)
   String appBase = null;
   File appBaseDir = null;
   appBase = ((Host) context.getParent()).getAppBase();
  @@ -244,7 +255,8 @@
   }
   File file = new File(appBaseDir,war);
   if (file.exists()) {
  -message = 
sm.getString("htmlManagerServlet.installUploadWarExists",war);
  +message = sm.getString
  +("htmlManagerServlet.installUploadWarExists",war);
   break;
   }
   warUpload.write(file.getCanonicalPath());
  @@ -261,6 +273,7 @@
   } catch(Exception e) {
   message = sm.getString
   ("htmlManagerServlet.installUploadFail", e.getMessage());
  +log(message, e);
   } finally {
   if (warUpload != null) {
   warUpload.delete();
  @@ -387,7 +400,8 @@
   }
   args[2] = new Boolean(context.getAvailable());
   args[3] = response.encodeURL
  -(request.getContextPath() + "/html/sessions?path=" + 
displayPath);
  +(request.getContextPath() +
  + "/html/sessions?path=" + displayPath);
   args[4] =
   new Integer(context.getManager().findSessions().length);
   writer.print
  @@ -395,16 +409,20 @@
   
   args = new Object[8];
   args[0] = response.encodeURL
  -(request.getContextPath() + "/html/start?path=" + displayPath);
  +(request.getContextPath() +
  + "/html/start?path=" + displayPath);
   args[1] = appsStart;
   args[2] = response.encodeURL
  -(request.getContextPath() + "/html/stop?path=" + displayPath);
  +(request.getContextPath() +
  + "/html/stop?path=" + displayPath);
   args[3] = appsS

cvs commit: jakarta-tomcat-4.0/webapps/manager build.xml

[glenn]

glenn   2003/01/10 17:16:59

  Modified:webapps/manager build.xml
  Log:
  Fix build, images were not being copied
  
  Revision  ChangesPath
  1.10  +1 -1  jakarta-tomcat-4.0/webapps/manager/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/manager/build.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- build.xml 10 Jan 2003 15:52:19 -  1.9
  +++ build.xml 11 Jan 2003 01:16:59 -  1.10
  @@ -52,7 +52,7 @@
   
   
 
  -
  +
 
   
   
  
  
  

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

DO NOT REPLY [Bug 15966] - Jasper parser is incorrectly handling empty jsp:body elements

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

Jasper parser is incorrectly handling empty jsp:body elements

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

DO NOT REPLY [Bug 15961] - getBodyContent() is not returning null when the action has only jsp:attribute actions within the body.

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

getBodyContent() is not returning null when the action has only jsp:attribute actions 
within the body.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

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

[luehe]

luehe   2003/01/10 16:52:14

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Node.java
  Log:
  Fixed 15961: getBodyContent() is not returning null when the action
  has only jsp:attribute actions within the body.
  
  Revision  ChangesPath
  1.147 +6 -6  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.146
  retrieving revision 1.147
  diff -u -r1.146 -r1.147
  --- Generator.java8 Jan 2003 22:15:56 -   1.146
  +++ Generator.java11 Jan 2003 00:52:14 -  1.147
  @@ -1958,7 +1958,7 @@
syncScriptingVars(n, VariableInfo.AT_BEGIN);
}
   
  - if (n.getBody() != null) {
  + if (!n.hasEmptyBody()) {
out.printin("if (");
out.print(tagEvalVar);
out.println(" != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {");
  @@ -2003,7 +2003,7 @@
   String tagHandlerVar,
   String tagEvalVar) {
   
  - if (n.getBody() != null) {
  + if (!n.hasEmptyBody()) {
if (n.implementsIterationTag()) {
out.printin("int evalDoAfterBody = ");
out.print(tagHandlerVar);
  @@ -2120,7 +2120,7 @@
 * and pass it to tag handler's setJspBody(), unless tag body
 * is empty
 */
  - if (n.getBody() != null) {
  + if (!n.hasEmptyBody()) {
out.printin(tagHandlerVar);
out.print(".setJspBody(");
generateJspFragment(n, tagHandlerVar);
  
  
  
  1.53  +34 -3 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
  
  Index: Node.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java,v
  retrieving revision 1.52
  retrieving revision 1.53
  diff -u -r1.52 -r1.53
  --- Node.java 11 Jan 2003 00:11:06 -  1.52
  +++ Node.java 11 Jan 2003 00:52:14 -  1.53
  @@ -1265,6 +1265,37 @@
}
return n;
}
  +
  + /**
  +  * Returns true if this custom action has an empty body, and false
  +  * otherwise.
  +  *
  +  * A custom action is considered to have an empty body if the 
  +  * following holds true:
  +  * - getBody() returns null, or
  +  * - all immediate children are jsp:attribute actions, or
  +  * - the action's jsp:body is empty.
  +  */
  +  public boolean hasEmptyBody() {
  +  boolean hasEmptyBody = true;
  +  Nodes nodes = getBody();
  +  if (nodes != null) {
  +  int numChildNodes = nodes.size();
  +  for (int i=0; imailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

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

[luehe]

luehe   2003/01/10 16:51:36

  Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
  Log:
  Fixed 15966: Jasper parser is incorrectly handling empty jsp:body elements
  
  Revision  ChangesPath
  1.55  +11 -29
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.54
  retrieving revision 1.55
  diff -u -r1.54 -r1.55
  --- Parser.java   11 Jan 2003 00:11:06 -  1.54
  +++ Parser.java   11 Jan 2003 00:51:36 -  1.55
  @@ -1597,38 +1597,20 @@
   }
   
   /*
  - * JspBodyBody ::=  ( S? '>' 
  - *( (   ScriptlessBody 
  - *| Body
  - *| TagDependentBody
  - *  ) - ''
  - *) '' 
  - *  )
  - *  |   ( ATTR[ !value ] S? JspBodyEmptyBody )
  - *
  - * JspBodyEmptyBody ::= '/>'
  - *  |   '>'
  - *  |   
  - *
  + * Parses jsp:body action.
*/
   private void parseJspBody(Node parent, String bodyType) 
   throws JasperException 
   {
   Mark start = reader.mark();
  -reader.skipSpaces();
  -
  -if (!reader.matches(">")) {
  - err.jspError(reader.mark(),
  -  "jsp.error.attributes.not.allowed",
  -  "" );
  - }
  -
Node bodyNode = new Node.JspBody(start, parent);
  - if( reader.matches( "" ) ) {
  - // Body was empty.  This is illegal, according to the grammar.
  - err.jspError(reader.mark(),"jsp.error.empty.body.not.allowed",
  -  "" );
  - } else {
  +
  + reader.skipSpaces();
  + if (!reader.matches("/>")) {
  + if (!reader.matches(">")) {
  + err.jspError(start, "jsp.error.unterminated",
  +  "
For additional commands, e-mail: 

cvs commit: jakarta-servletapi-5/jsr154/src/share/javax/servlet GenericServlet.java

[craigmcc]

craigmcc2003/01/10 16:26:02

  Modified:jsr154/src/share/javax/servlet GenericServlet.java
  Log:
  Remove spurious logging from init() and destroy(), ported forward from the
  same change made a while back in jakarta-servletapi-4.
  
  Revision  ChangesPath
  1.2   +0 -2  
jakarta-servletapi-5/jsr154/src/share/javax/servlet/GenericServlet.java
  
  Index: GenericServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-5/jsr154/src/share/javax/servlet/GenericServlet.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- GenericServlet.java   13 Aug 2002 16:21:42 -  1.1
  +++ GenericServlet.java   11 Jan 2003 00:26:02 -  1.2
  @@ -119,7 +119,6 @@
*/
   
   public void destroy() {
  - log("destroy");
   }
   
   
  @@ -254,7 +253,6 @@
   
   public void init(ServletConfig config) throws ServletException {
this.config = config;
  - log("init");
this.init();
   }
   
  
  
  

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

DO NOT REPLY [Bug 15851] - Parser generates a NullPointerException for invalid use case of jsp:attribute instead of a useful message.

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

Parser generates a NullPointerException for invalid use case of jsp:attribute instead 
of a useful message.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties messages_es.properties messages_fr.properties messages_ja.properties

[kinman]

kinman  2003/01/10 16:11:06

  Modified:jasper2/src/share/org/apache/jasper/compiler Node.java
Parser.java TagPluginManager.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
messages_fr.properties messages_ja.properties
  Log:
  - Fix 15851: nested jsp:attribute should be disallowed.
  
  Revision  ChangesPath
  1.52  +11 -8 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
  
  Index: Node.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java,v
  retrieving revision 1.51
  retrieving revision 1.52
  diff -u -r1.51 -r1.52
  --- Node.java 8 Jan 2003 18:42:43 -   1.51
  +++ Node.java 11 Jan 2003 00:11:06 -  1.52
  @@ -1333,11 +1333,14 @@
   }
   childInfo = new ChildInfo();
name = this.getAttributeValue("name");
  - localName = name;
  - int index = name.indexOf(':');
  - if (index != -1) {
  - prefix = name.substring(0, index);
  - localName = name.substring(index+1);
  +if (name != null) {
  +// Mandatary attribute "name" will be checked in Validator
  + localName = name;
  + int index = name.indexOf(':');
  + if (index != -1) {
  + prefix = name.substring(0, index);
  + localName = name.substring(index+1);
  +}
}
   }
   
  
  
  
  1.54  +7 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.53
  retrieving revision 1.54
  diff -u -r1.53 -r1.54
  --- Parser.java   9 Jan 2003 23:54:40 -   1.53
  +++ Parser.java   11 Jan 2003 00:11:06 -  1.54
  @@ -1568,6 +1568,10 @@
   err.jspError( reader.mark(), "jsp.error.not.in.template",
"Expression language" );
   } else if (reader.matches("mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors gump.xml

[costin]

costin  2003/01/10 16:05:10

  Modified:.gump.xml
  Log:
  Add jmx deps in gump.
  
  Revision  ChangesPath
  1.10  +23 -1 jakarta-tomcat-connectors/gump.xml
  
  Index: gump.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/gump.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- gump.xml  13 Nov 2002 00:12:49 -  1.9
  +++ gump.xml  11 Jan 2003 00:05:10 -  1.10
  @@ -32,12 +32,15 @@
 
   org.apache.coyote
   
  +  
  +  
  
   
   
   
   
  +
   
   
   
  @@ -53,12 +56,15 @@
 
   org.apache.coyote
   
  +  
  +  
  
 
   
   
   
  +
   
   
   
  @@ -75,11 +81,14 @@
   org.apache.jk
   
   
  +  
  +  
 
   
   
   
   
  +
   
   
   
  @@ -93,10 +102,23 @@
from="Craig McClanahan <[EMAIL PROTECTED]>"/>
 
   
  +  
  +
  +
  +
  +
  +
  +
  +  
  +  
 
  -
  +
   
  +
   
  +
  +
  +
 
 
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/coyote build.xml

[costin]

costin  2003/01/10 16:03:01

  Modified:coyote   build.xml
  Log:
  Add the jmx dependency.
  
  Add a separate target that just builds for tomcat5, to avoid
  all the detection.
  
  Revision  ChangesPath
  1.16  +12 -1 jakarta-tomcat-connectors/coyote/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/build.xml,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- build.xml 6 Jan 2003 18:35:20 -   1.15
  +++ build.xml 11 Jan 2003 00:03:01 -  1.16
  @@ -78,6 +78,7 @@
 
   
   
  +
   
   
   
  @@ -211,6 +212,16 @@
   
 
   
  +  
  +
  +  
  +
  +  
  +  
  +
 
   
 mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

DO NOT REPLY [Bug 15982] New: - jdbc realm - digest for cleartext pw does not work

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

jdbc realm - digest for cleartext pw does not work

   Summary: jdbc realm - digest for cleartext pw does not work
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


i just tried to create an additional jdbc realm and i thought its enough to 
enter nothing into the digest field (inside the administration webapp)

after storing the new server.xml, this file contains one empty attribute called 
digest (digest="") inside the realm tag 

the problem now is, that its impossible to start tomcat 4.1.18 .. its possible 
to start without such digest attribute, and its also possible to start tomcat 
with values like digest="MD5", but its impossible to start tomcat with digest=""

the only problem is, that its impossible to create realm elements without the 
digest attribute by means of your administration tool (this means its 
impossible to create unencrypted jdbc realms using your adminstration tool)

cybi

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

Email Rejected: Unknown or disallowed attachment type

[postmaster]

Received: from [198.76.25.3] (HELO nns.voyanttech.com)
  by voyanttech.com (CommuniGate Pro SMTP 3.4b3)
  with SMTP id 3430066 for [EMAIL PROTECTED]; Fri, 10 Jan 2003 16:06:16 -0700
Received: from exchange.sun.com (exchange.sun.com [192.18.33.10])
by nns.voyanttech.com (8.9.3+Sun/8.9.3) with SMTP id QAA26144
for <[EMAIL PROTECTED]>; Fri, 10 Jan 2003 16:54:21 -0500 (EST)
Received: (qmail 28659 invoked by uid 97); 10 Jan 2003 23:07:29 -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Unsubscribe: 
List-Subscribe: 
List-Help: 
List-Post: 
List-Id: "Tomcat Developers List" 
Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Delivered-To: mailing list [EMAIL PROTECTED]
Received: (qmail 28643 invoked by uid 98); 10 Jan 2003 23:07:28 -
X-Antivirus: nagoya (v4218 created Aug 14 2002)
From: "Bradley M. Handy" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: JNDIRealm feature enhancements
Date: Fri, 10 Jan 2003 18:06:02 -0500
Message-ID: <000a01c2b8fc$d8a77e00$[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_NextPart_000_000B_01C2B8D2.EFD17600"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Virus-Scanned: by AMaViS perl-10
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

--=_NextPart_000_000B_01C2B8D2.EFD17600
Content-Type: multipart/alternative;
boundary="=_NextPart_001_000C_01C2B8D2.EFD17600"


--=_NextPart_001_000C_01C2B8D2.EFD17600
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

After setting up a JNDIRealm for the Manager app, I noticed after a
while the connection times out and returns NULL automatically.  I was
wondering, if instead of returning NULL, JNDIRealm to try to reconnect
and then authenticate, and then return NULL, if a failure results from
that attempt, otherwise return the JNDIRealm.User object.
 
Also I've notice there is no method for specifying an alternate
connection URL in the event the URL specified in connectionURL is not
available.  So, I took the liberty of adding an attribute "alternateURL"
to specify a secondary URL.  When the JNDIRealm opens a connection it
will attempt the primary, and, upon failure, then attempt to connect to
the alternate URL.  If this should fail, the JNDIRealm fails as it did
before.
 
In both features the first exception is logged before the second attempt
to connect proceeds.
 
I have attached the CVS diff between my copy of JNDIRealm and the
current HEAD version of JNDIRealm.
 
Brad Handy
Programmer/Analyst
Spring Arbor University

--=_NextPart_001_000C_01C2B8D2.EFD17600
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

http://www.w3.org/TR/REC-html40";>








cid:[EMAIL PROTECTED]";>











After setting up a JNDIRealm for the =
Manager
app, I noticed after a while the connection times out and returns NULL
automatically.  I was =
wondering, if instead of returning NULL, JNDIRealm
to try to reconnect and then authenticate, and then return NULL, if a =
failure
results from that attempt, otherwise return the JNDIRealm.User
object.

 

Also I’ve notice there is no method for specifying an =
alternate
connection URL in the event the URL specified in connectionURL
is not available.  So, I =
took the liberty
of adding an attribute “alternateURL” to
specify a secondary URL.  =
When the JNDIRealm opens a connection it will attempt the =
primary,
and, upon failure, then attempt to connect to the alternate URL.  If this should fail, th

JNDIRealm feature enhancements

[Bradley M. Handy]

After setting up a JNDIRealm for the Manager
app, I noticed after a while the connection times out and returns NULL
automatically.  I was wondering, if instead of returning NULL, JNDIRealm
to try to reconnect and then authenticate, and then return NULL, if a failure
results from that attempt, otherwise return the JNDIRealm.User
object.

 

Also I’ve notice there is no method for specifying an alternate
connection URL in the event the URL specified in connectionURL
is not available.  So, I took the liberty
of adding an attribute “alternateURL” to
specify a secondary URL.  When the JNDIRealm opens a connection it will attempt the primary,
and, upon failure, then attempt to connect to the alternate URL.  If this should fail, the JNDIRealm fails as it did before.

 

In both features the first exception is logged before the second
attempt to connect proceeds.

 

I have attached the CVS diff between my copy of JNDIRealm
and the current HEAD version of JNDIRealm.

 

Brad Handy

Programmer/Analyst

Spring Arbor University








JNDI.diff
Description: Binary data
--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 15672] - DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC 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=15672

DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver





--- Additional Comments From [EMAIL PROTECTED]  2003-01-10 22:44 ---
I have been able to get Oracle's JDBC Driver working just fine with Tomcat
4.1.18.  Below are my specifics from server.xml.  Are you sure that
classes12.jar is in $CATALINA_HOME/common/lib?




factory
org.apache.commons.dbcp.BasicDataSourceFactory


maxActive
50


maxIdle
10


maxWait
1


username
scott


password
tiger


driverClassName
oracle.jdbc.driver.OracleDriver


url
jdbc:oracle:thin:@host:1521:database


removeAbandoned
true


removeAbandonedTimeout
60


logAbandoned
true



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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

[costin]

costin  2003/01/10 14:36:43

  Added:   coyote/src/java/org/apache/coyote BaseHook.java
  Log:
  Added a base implementation of ActionHook - with some small additions :-)
  
  First, there is a getNext/setNext to allow multiple hooks to be chained.
  Both recursive and iterative will be supported - you can call next directly or
  just return it ( still need to tune this - only recursive works now )
  
  In addition, the hook implements MBeanRegistration ( again: we did vote on
  JMX dependency ). Tomcat3.3 may be a problem ( since it's using the same code),
  but if someone wants to use the new connector he can also add jmx in the
  path. If anyone has a problem with that - please let me know, I can hack
  some conditional compilation, but I would like to keep it simple.
  
  I'll change the 2 hook implementations to extend this after it settles down.
  
  Feel free to make changes - or ask for changes or just say -1.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/BaseHook.java
  
  Index: BaseHook.java
  ===
  /*
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights 
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer. 
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:  
   *   "This product includes software developed by the 
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written 
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   * [Additional notices, if required by prior licensing conditions]
   *
   */ 
  package org.apache.coyote;
  
  import javax.management.MBeanRegistration;
  import javax.management.ObjectName;
  import javax.management.MBeanServer;
  
  
  /**
   * Action hook.
   *
   * @author Remy Maucherat
   * @author Costin Manolache
   */
  public class BaseHook implements ActionHook, MBeanRegistration {
  protected BaseHook next;
  
  /**
   * Send an action to the connector.
   * Both recursive and iterative invocation is possible - the
   * hook may call itself the next hook ( like catalina ) or the
   * controller may call the next.
   * 
   * @param param Action parameter
   * @return  A hook that can be executed next.
   */
  public BaseHook action(int code, Object param) {
  if( next==null ) return next;
  return next.action( code, param );
  };
  
  /** Backward compat
   *
   * @param actionCode
   * @param param
   */
  public void action( ActionCode actionCode, Obje

DO NOT REPLY [Bug 15672] - DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC 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=15672

DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver





--- Additional Comments From [EMAIL PROTECTED]  2003-01-10 22:23 ---
Hello,

I am having the same problem with the MySQL driver (connector/j 3.0.4). I
checked that the BasicDatasource instance is created. I did not check whether
the description is there but the important parameters (driver, url, username,
pass) were not there.

I am not attaching my sever.xml and web.xml files as they are alomst identical
except the driverClassName is com.mysql.jdbc.Driver and the url is mysql specific.

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

Re: Duplicate session IDs are *common*

[Eric Rescorla]

Costin Manolache <[EMAIL PROTECTED]> writes:

> Eric Rescorla wrote:
> 
> > Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes:
> > 
> >> > ID provides a statistical probability of collision so low that
> >> > there is no need to explicitly check for uniqueness.
> >> 
> >> Or just add a syncronized i++ to make sure.
> > Yes.
> > 
> > There's nothing wrong with what you propose, but it's sort of
> > like saying "maybe I should wear a helmet at all times
> > because a meteor might drop on my head". Sure, it could happen,
> > btu it's not the thing I'd worry about.
> 
> I find it amazing that 2 people reported beeing hit by meteors (duplicate 
> session ids ) in the same week.  
I do too. Something is wrong but I don't know what it is yet.

However, the solution isn't to add a bandaid, but rather to
examine the code and figure out what's broken.

-Ekr

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

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

Re: Duplicate session IDs are *common*

[Eric Rescorla]

Combining two messages...

Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes:

> > Securely random and unpredictable are effectively the same thing.
> 
> Depends on your definition; one-way-function((count++) + (secret)) is
> quite unpredictable; expcet for those knowing the secret. Secure random
> generators give you a value which is unpredictable for all. And are a lot
> more expensive generally.

...
> > Securely random and unpredictable are effectively the same thing.

> Depends on your definition; one-way-function((count++) + (secret)) is
> quite unpredictable; expcet for those knowing the secret. Secure random
> generators give you a value which is unpredictable for all. And are a lot
> more expensive generally.

What you've just described is a form of cryptographically secure
PRNG called a "message digest in counter mode". This isn't exactly
what I would use but it's roughly equivalent. 

-Ekr


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

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

Proposal: RUNNING.TXT classpath update

[Jan Wagner]

It seems many people are frustrated because Tomcat doesn't work right
away, which is mainly because of faulty classpath settings, a lack in
the setup documentation.

I'd suggest someone add to the RUNNING.TXT doc at the end of the
part "(1) Download and Install the Tomcat 4.0 Binary Distribution",
a couple of helpful lines like

--

* Configure your classpath:

  Update your environment variable CLASSPATH to contain at least
  the following entries (of course, adapted to your operating
  system and paths):

  .;
  E:\java\j2sdk14\lib;
  F:\Servlet\Jakarta\server\lib;
  F:\Servlet\Jakarta\lib;
  F:\servlet\jakarta\common\lib\servlet.jar;
  E:\java\j2sdk14\lib\tools.jar;
  F:\servlet\jakarta\lib\jasper-runtime.jar;

  Especially check that servlet.jar, tools.jar, and
  jasper-runtime.jar path names are specified correctly.
  Without these, Tomcat can not start.

---

(I'd do this myself if i had ever used CVS, but... ;)

cheers,
 - Jan

--
*
 high voltage at http://www.hut.fi/~jwagner/tesla
 Jan OH2GHR

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

trouble with jk2 vs. Apache2 on OSX 10.2.3: "Segmentation fault$HTTPD -k $ARGV"

[R Blake]

i've successfully installed Apache2 & Tomcat on OSX 10.2.3 

both run great in standalone . but Apache2 + Coyote jk2 refuses to 
launch/function 

Apache2 is a CVS build, & server-info is:

Server Version: Apache/2.1.0-dev (Unix) mod_perl/1.99_07-dev Perl/v5.8.0 
PHP/4.4.0-dev mod_auth_pgsql/2.0b6 DAV/2
Server Built: Jan 6 2003 00:37:56
API Version: 20020903:0
Hostname/port: testserver.internal.blakers.net:80
Timeouts: connection: 300keep-alive: 300
MPM Name: Worker
MPM Information: Max Daemons: 1 Threaded: yes Forked: yes
Server Root: /usr
Config File: /etc/apache2/httpd.conf

Tomcat is binary: jakarta-tomcat-4.1.18

jk2 is built/installed from CVS (timestamp: 01/10/03 01:18:27)

"LoadModule jk2_module libexec/apache2/mod_jk2.so" is added to httpd.conf

tomcat starts as usual -- fine

with/without tomcat running, an attempt to launch apache (apachectl start) 
results in:

apachectl start

/usr/sbin/apachectl: line 87:  1601 Segmentation fault  $HTTPD -k $ARGV

removing the jk2 LoadModule makes the error go away .

Apache's error_log is:

[Fri Jan 10 12:34:39 2003] [info] mod_unique_id: using ip addr 172.30.10.3
[Fri Jan 10 12:34:40 2003] [info] mod_unique_id: using ip addr 172.30.10.3
[Fri Jan 10 12:34:41 2003] [notice] Digest: generating secret for digest 
authentication ...
[Fri Jan 10 12:34:41 2003] [notice] Digest: done
[Fri Jan 10 12:34:41 2003] [notice] Apache/2.1.0-dev (Unix) 
mod_perl/1.99_07-dev Perl/v5.8.0 PHP/4.4.0-dev mod_auth_pgsql/2.0b6 DAV/2 
configured -- re
[Fri Jan 10 12:34:41 2003] [info] Server built: Jan  6 2003 00:37:56
[Fri Jan 10 12:34:41 2003] [debug] worker.c(1736): AcceptMutex: posixsem 
(default: posixsem)
[Fri Jan 10 12:35:47 2003] [info] removed PID file /var/run/httpd.pid 
(pid=1587)
[Fri Jan 10 12:35:47 2003] [notice] caught SIGTERM, shutting down
[Fri Jan 10 12:35:50 2003] [info] mod_unique_id: using ip addr 172.30.10.3

my first surmise is that there is a problem with the jk2 connector build, 
but i'm not sure, and haven't the foggiest as to how to check/where to 
begin 

thoughts/suggestion?

richard



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

Re: Duplicate session IDs are *common*

[Remy Maucherat]

Costin Manolache wrote:

I find it amazing that 2 people reported beeing hit by meteors (duplicate 
session ids ) in the same week.  

I find it odd that it actually happened ...


You're right - a counter is better than time. It'll duplicate the counter
if tomcat is restarted - so probably the initial value of the counter
should be random or derived from time.


Yes, since sessions are saved and then reloaded by Tomcat on restart.

Anyway, as far as I am concerned, I don't see any security problem so 
far, so I won't make any security bulletin.

I'll compile the list of changes since 4.1.18 early next week, for maybe 
a new alpha release.

Remy


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

Re: Duplicate session IDs are *common*

[Costin Manolache]

Eric Rescorla wrote:

> Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes:
> 
>> > ID provides a statistical probability of collision so low that
>> > there is no need to explicitly check for uniqueness.
>> 
>> Or just add a syncronized i++ to make sure.
> Yes.
> 
> There's nothing wrong with what you propose, but it's sort of
> like saying "maybe I should wear a helmet at all times
> because a meteor might drop on my head". Sure, it could happen,
> btu it's not the thing I'd worry about.

I find it amazing that 2 people reported beeing hit by meteors (duplicate 
session ids ) in the same week.  

You're right - a counter is better than time. It'll duplicate the counter
if tomcat is restarted - so probably the initial value of the counter
should be random or derived from time.


Costin


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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/res LocalStrings.properties LocalStrings_fr.properties

[remm]

remm2003/01/10 12:22:38

  Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
   util/java/org/apache/tomcat/util/net/res
LocalStrings.properties LocalStrings_fr.properties
  Log:
  - Refactor the server socket restart code.
  
  Revision  ChangesPath
  1.12  +76 -55
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
  
  Index: PoolTcpEndpoint.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- PoolTcpEndpoint.java  1 Jan 2003 13:55:22 -   1.11
  +++ PoolTcpEndpoint.java  10 Jan 2003 20:22:37 -  1.12
  @@ -122,6 +122,7 @@
   ThreadPoolRunnable listener;
   private volatile boolean running = false;
   private boolean initialized = false;
  +private boolean reinitializing = false;
   static final int debug=0;
   
   ThreadPool tp;
  @@ -311,28 +312,34 @@
if (running) {
tp.shutdown();
running = false;
  - try {
  - // Need to create a connection to unlock the accept();
  - Socket s;
  - if (inet == null) {
  - s=new Socket("127.0.0.1", port );
  - }else{
  - s=new Socket(inet, port );
  +if (serverSocket != null) {
  +closeServerSocket();
  +}
  + }
  +}
  +
  +protected void closeServerSocket() {
  +try {
  +// Need to create a connection to unlock the accept();
  +Socket s;
  +if (inet == null) {
  +s=new Socket("127.0.0.1", port );
  +}else{
  +s=new Socket(inet, port );
   // setting soLinger to a small value will help shutdown the
   // connection quicker
  -s.setSoLinger(true, 0);
  - }
  - s.close();
  - } catch(Exception e) {
  -log.error("Caught exception trying to unlock accept.", e);
  - }
  - try {
  - serverSocket.close();
  - } catch(Exception e) {
  -log.error("Caught exception trying to close socket.", e);
  - }
  - serverSocket = null;
  - }
  +s.setSoLinger(true, 0);
  +}
  +s.close();
  +} catch(Exception e) {
  +log.error("Caught exception trying to unlock accept.", e);
  +}
  +try {
  +serverSocket.close();
  +} catch(Exception e) {
  +log.error("Caught exception trying to close socket.", e);
  +}
  +serverSocket = null;
   }
   
   //  Private methods
  @@ -362,49 +369,62 @@
   }
   catch (IOException e) {
   
  -if (running) {
  +String msg = null;
   
  -String msg = sm.getString("endpoint.err.nonfatal",
  +if (running) {
  +msg = sm.getString("endpoint.err.nonfatal",
   serverSocket, e);
   log.error(msg, e);
  +}
   
  -if (accepted != null) {
  -try {
  -accepted.close();
  -accepted = null;
  -} catch(Exception ex) {
  -msg = sm.getString("endpoint.err.nonfatal",
  -accepted, ex);
  -log.warn(msg, ex);
  -}
  +if (accepted != null) {
  +try {
  +accepted.close();
  +accepted = null;
  +} catch(Exception ex) {
  +msg = sm.getString("endpoint.err.nonfatal",
  +   accepted, ex);
  +log.warn(msg, ex);
   }
  -// Restart endpoint when getting an IOException during accept
  -synchronized (threadSync) {
  +}
  +
  +reinitializing = true;
  +// Restart endpoint when getting an IOException during accept
  +synchronized (threadSync) {
  +if (reinitializing) {
  +reinitializing = false;
  +// 1) Attempt to close server socket
  +closeServerSocket();
  +initialized = false;
  +// 2) Reinit endpoint (recreate server socket)
   try {
  -serverSocket.close();
  -} catch(Exception ex) {
  +msg = sm.getString("endpoint.warn.reinit");
  +log.wa

DO NOT REPLY [Bug 15974] New: - Original stack trace is lost

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

Original stack trace is lost

   Summary: Original stack trace is lost
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

It seems that when an exception reaches the Jasper from an application, the 
component throws the root cause's stack trace away, keeping only the 
exception's message, which in some cases is not sufficient for the programmer 
to find the problem.

I believe this change (possibly a bug) has been made since early versions of 
Tomcat 4.x, as the Tomcat 3.3a shows the complete stack trace.

To isolate and demonstrate the problem, I've created a simple application, 
which consists of a Java class, and a JSP:

-- Java class source code --

package com.test;

public class StackTraceTest {
public static void throwError() throws Exception {
if (1 == 1) throw new Exception("just testing");
}
}
--

-- JSP source code --
<% com.test.StackTraceTest.throwError(); %>
--

On Tomcat 4.1.18 (think early versions of 4.x does the same), it produces the 
following content, in the browser and in the log:

--
HTTP Status 500 - 

type Exception report

message 

description The server encountered an internal error () that prevented it from 
fulfilling this request.

exception 

org.apache.jasper.JasperException: just testing
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:248)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
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.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:260)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke
(AuthenticatorBase.java:493)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:172)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:432)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnectio
n(Http11Protocol.java:386)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:534)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:530)
at java.lang

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

On 10 Jan 2003, Eric Rescorla wrote:

> There's nothing wrong with what you propose, but it's sort of
> like saying "maybe I should wear a helmet at all times
> because a meteor might drop on my head". Sure, it could happen,
> btu it's not the thing I'd worry about.

Except that hash( i++ . secret).i is generally a lot cheaper and easier to
code cross platform than using a true cryptographic random generator with
the right tie in with hardware. And it happens to have a hard-hat aspect
thrown in as a freebee.

Dw


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

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

> Securely random and unpredictable are effectively the same thing.

Depends on your definition; one-way-function((count++) + (secret)) is
quite unpredictable; expcet for those knowing the secret. Secure random
generators give you a value which is unpredictable for all. And are a lot
more expensive generally.

Dw


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

Re: Duplicate session IDs are *common*

[Eric Rescorla]

Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes:

> > ID provides a statistical probability of collision so low that
> > there is no need to explicitly check for uniqueness.
> 
> Or just add a syncronized i++ to make sure.
Yes.

There's nothing wrong with what you propose, but it's sort of
like saying "maybe I should wear a helmet at all times
because a meteor might drop on my head". Sure, it could happen,
btu it's not the thing I'd worry about.

-Ekr

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

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

Re: Duplicate session IDs are *common*

[Eric Rescorla]

Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes:

> On Fri, 10 Jan 2003, Glenn Olander wrote:
> 
> > 1) a good PRNG, such as secureRandom
> 
> Why does it need to be securely random; surely unpredicatable is good
> enough ?
Securely random and unpredictable are effectively the same thing.

-Ekr
 

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

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

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

> ID provides a statistical probability of collision so low that
> there is no need to explicitly check for uniqueness.

Or just add a syncronized i++ to make sure.

Dw.


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

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

On Fri, 10 Jan 2003, Glenn Olander wrote:

> 1) a good PRNG, such as secureRandom

Why does it need to be securely random; surely unpredicatable is good
enough ?

> 2) a uniqueness guarantee

count++ +":"+myip+":"+myport

is also quite unqiue :-)

DW.


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

Re: Duplicate session IDs are *common*

[Steve Plate]

I saw another problem that had similar symptoms to
duplicate
session ID's. My application was getting collisions
between different users having the same session ID
using
tomcat 4.0.5. I found that the request headers were
not
being cleared out when they were recycled so that
cookies
from a current request were added to the cookies on
the
previous request. Since only the first JSESSIONID
cookie
is used to obtain the session id both users ended up
with
the same session id. I solved this in my application
by
using rewritten URLs instead of cookies. I was unable
to
find a bug in examining the tomcat code. I did not
check
the mod_jk code.

Steve

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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

DO NOT REPLY [Bug 15967] New: - IllegalStateException not thrown by HttpSession.getLastAccessedTime() if session has been invalidated.

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

IllegalStateException not thrown by HttpSession.getLastAccessedTime() if session has 
been invalidated.

   Summary: IllegalStateException not thrown by
HttpSession.getLastAccessedTime() if session has been
invalidated.
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


According to the javadocs for HttpSession.getLastAccessedTime() will throw 
an IllegalStateException if called against a method that has been invalidated.

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

Re: Duplicate session IDs are *common*

[Eric Rescorla]

Costin Manolache <[EMAIL PROTECTED]> writes:

> Eric Rescorla wrote:
> 
> > Jim Jagielski <[EMAIL PROTECTED]> writes:
> > 
> >> Eric Rescorla wrote:
> >> > 
> >> > Glenn Olander <[EMAIL PROTECTED]> writes:
> >> > > 5) The strength of the PRNG is largely irrelevant
> >> > > 
> >> > > As a user, I wouldn't trust any solution which lacks a check for
> >> > > duplicate session id's, regardless of the strength of the PRNG.
> >> > This doesn't seem to me to be a plausible position in view
> >> > of the fact that all of our security mechanisms absolutely
> >> > depend on statistical uniqueness of randomly generated large
> >> > numbers.
> >> > 
> >> 
> >> These are 2 different points I think. If you randomly generate numbers
> >> between 1 and 1,000,000 you will, after a point in time, have
> >> duplicate numbers.
> > Yes, but if you randomly generate numbers between 1 and 2^128, you'll
> > have to generate roughly 2^64 random numbers to have a good chance of
> > getting a duplicate. Sure, over time you'll get a duplicate,
> > but in this context over time needs to be measured over a
> > time scale far in excess of the time scale that is interesting.
> 
> Adding the startup time doesn't hurt. 
> Or enough bits of the startup time to guarantee a duplicate won't
> happen in our life. 
No, it doesn't hurt. I just don't think it adds much value. Why not
use a simple counter, though?

-Ekr


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

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

Re: Duplicate session IDs are *common*

[Eric Rescorla]

Glenn Olander <[EMAIL PROTECTED]> writes:

> I think you may have misunderstood. I'm just pointing out that, from a
> user's
> 
> perspective, a good solution requires two elements:
> 
> 1) a good PRNG, such as secureRandom
> 2) a uniqueness guarantee
> 
> I'm not saying a PRNG is unneeded. I'm just saying a good one like
> PRNG is good
> 
> enough as long as it is accompanied by a uniqueness guarantee. Are you
> saying you
> 
> want to remove the uniqueness guarantee?
I'm saying that a strong PRNG with a sufficiently wide session
ID provides a statistical probability of collision so low that
there is no need to explicitly check for uniqueness.

-Ekr

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

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

Re: Duplicate session IDs are *common*

[Eric Rescorla]

Jim Jagielski <[EMAIL PROTECTED]> writes:
> Of course, as you said, it depends on the range and the timespan.
> 
> But it doesn't change the fact that randomness != uniqueness, which is
> what Glenn's point was I think.
Perhaps not from a theoretical persective, but from a practical
perspective it does. With a sufficiently large session ID, the
probability of a collision can be made vastly less than the
probability that some sort of programming error (or a hardware error)
making an invalid session appear valid.

As I said previously, the entire practice of modern security
depends on this.

-Ekr


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

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

Re: Duplicate session IDs are *common*

[Glenn Olander]

I think you may have misunderstood. I'm just pointing out that, from a 
user's
perspective, a good solution requires two elements:

1) a good PRNG, such as secureRandom
2) a uniqueness guarantee

I'm not saying a PRNG is unneeded. I'm just saying a good one like PRNG 
is good
enough as long as it is accompanied by a uniqueness guarantee. Are you 
saying you
want to remove the uniqueness guarantee?

- Glenn


Eric Rescorla <[EMAIL PROTECTED]> writes:

Glenn Olander <[EMAIL PROTECTED]> writes:
 

5) The strength of the PRNG is largely irrelevant

As a user, I wouldn't trust any solution which lacks a check for
duplicate session id's, regardless of the strength of the PRNG.

   

This doesn't seem to me to be a plausible position in view
of the fact that all of our security mechanisms absolutely
depend on statistical uniqueness of randomly generated large
numbers.




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

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

On Fri, 10 Jan 2003, Jim Jagielski wrote:

> But it doesn't change the fact that randomness != uniqueness, which is
> what Glenn's point was I think.

Just as an example; doing on issue

syncronized count++;
id = count.ipaddr
add port if you must :-)

gives you a rather unique (but predictable) session id. The uniqueness of
the ipaddres obviously relies on the registry function of iana/ripe/et.al.
combined with your site/provider IP management.

or if it must be un-prediable do something like:

on init
seed = true-rand... or config-file-entry

on issue
id = md5( seed . count . ipaddr );

or if you do not trust md5's or find them too expensive

id = hash(seed.count.ipaddr).count.ipaddr
with hash = md4, md5, sha1, crypt, ..
as long as it is one way -and-
seed is truly random or manually choosen
to be proper.

OR if you want to check a session id prior to spending
(lookup) cycles on them to counter DoS0-s then do something like

id = hash(seed.count.hisip.ipaddr).count.ipaddr.hisip

and on accept do
hisip = from-accept-stack-info()
s,c,i1,i2 = splice(id)
i2 == hisip ?
i1 == myip ?
hash(seed.c.hisip.myip) == s ?
now do the expensive stuff

add a time-of-issue if needed if you are worried about that. Obviously now
the seed -must- be a config secret; as otherwise you cannot restart your
server without blowing all sessions out of the water.

Dw.



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

Re: Duplicate session IDs are *common*

[Costin Manolache]

Eric Rescorla wrote:

> Jim Jagielski <[EMAIL PROTECTED]> writes:
> 
>> Eric Rescorla wrote:
>> > 
>> > Glenn Olander <[EMAIL PROTECTED]> writes:
>> > > 5) The strength of the PRNG is largely irrelevant
>> > > 
>> > > As a user, I wouldn't trust any solution which lacks a check for
>> > > duplicate session id's, regardless of the strength of the PRNG.
>> > This doesn't seem to me to be a plausible position in view
>> > of the fact that all of our security mechanisms absolutely
>> > depend on statistical uniqueness of randomly generated large
>> > numbers.
>> > 
>> 
>> These are 2 different points I think. If you randomly generate numbers
>> between 1 and 1,000,000 you will, after a point in time, have
>> duplicate numbers.
> Yes, but if you randomly generate numbers between 1 and 2^128, you'll
> have to generate roughly 2^64 random numbers to have a good chance of
> getting a duplicate. Sure, over time you'll get a duplicate,
> but in this context over time needs to be measured over a
> time scale far in excess of the time scale that is interesting.

Adding the startup time doesn't hurt. 
Or enough bits of the startup time to guarantee a duplicate won't
happen in our life. 

We'll still have the probability that 2 random number generated at the
same time ( same millis ) will be identical.  :-)

Costin






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

Re: Duplicate session IDs are *common*

[Costin Manolache]

The check will verify that the session id doesn't duplicate another 
active session.

If the session expires - it is still possible ( even if extremely unlikely )
that a user will reuse the same browser window and get into someone's else
session.

I think this is as likely as someone using a random session ID ( for any 
decent random generator, the fact that a number has been generated before 
shouldn't affect the probability of having it generated again - AFAIK )

We could completely eliminate this chance by including the time - so each
sessionID will have the start time included in it ( that may be used for
other purpose eventually ). 

Costin



Glenn Olander wrote:

> Here's a follow-up on the bug report I submitted that started this thread.
> 
> 1) We confirmed the problem is a duplicate session id.
> 
> Luckily we were logging session id's. It took a lot of hunting through
> access logs, but we did indeed find two sessions which were started a
> couple of minutes apart, with a number of intervening sessions, which
> had duplicate session id's. The pair of sessions corresponded to the user
> report of seeing someone else's session data. We're using 4.1.12.
> 
> 2) I don't believe this is *common*
> 
> The problem hasn't been duplicated in our app, so I'm not sure I'd call
> this a common problem, but that's a subjective term.
> 
> 3) I believe this is a serious vulnerability
> 
> There should probably be some sort of an alert delivered to tomcat
> users to let them know of this problem.
> 
> 4) A simple patch is available
> 
> It is not necessary to use the head version of tomcat to fix the problem.
> Simply install your own manager class, which subclasses StandardManager,
> which has the duplicate session id checking implemented. In other words,
> a simple patch on an existing tomcat installation can fix this.
> 
> 5) The strength of the PRNG is largely irrelevant
> 
> As a user, I wouldn't trust any solution which lacks a check for
> duplicate session id's, regardless of the strength of the PRNG. The head
> revision now includes such a check, so I believe the problem has been
> solved. Even the weakest of PRNG's would generate a collision only rarely,
> so I wouldn't worry about improving its strength.
> 
> - Glenn



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

Re: Duplicate session IDs are *common*

[Jim Jagielski]

At 10:42 AM -0800 1/10/03, Eric Rescorla wrote:
>Jim Jagielski <[EMAIL PROTECTED]> writes:
>
>> Eric Rescorla wrote:
>> >
>> > Glenn Olander <[EMAIL PROTECTED]> writes:
>> > > 5) The strength of the PRNG is largely irrelevant
>> > >
>> > > As a user, I wouldn't trust any solution which lacks a check for
>> > > duplicate session id's, regardless of the strength of the PRNG.
>> > This doesn't seem to me to be a plausible position in view
>> > of the fact that all of our security mechanisms absolutely
>> > depend on statistical uniqueness of randomly generated large
>> > numbers.
>> >
>>
>> These are 2 different points I think. If you randomly generate numbers
>> between 1 and 1,000,000 you will, after a point in time, have
>> duplicate numbers.
>Yes, but if you randomly generate numbers between 1 and 2^128, you'll
>have to generate roughly 2^64 random numbers to have a good chance of
>getting a duplicate. Sure, over time you'll get a duplicate,
>but in this context over time needs to be measured over a
>time scale far in excess of the time scale that is interesting.
>

Of course, as you said, it depends on the range and the timespan.

But it doesn't change the fact that randomness != uniqueness, which is
what Glenn's point was I think.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

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

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

[costin]

costin  2003/01/10 10:59:50

  Modified:catalina/src/share/org/apache/catalina/loader
WebappLoader.java
  Log:
  Some info for the jmx console. It's nice to see the repositories.
  
  It would also be nice to have a method to display info about how
   a class will be loaded ( from parent or what repo ) as well as last mod time.
  
  I'll try to use WebppLoader as a basis for a loader to be used in modeler -
  and merge it with the StandardLoader ( i.e. support both filesystem and
  jndi sources ).
  
  Having more JMX support in the loader will help track a lot of problems.
  Wish I had more time...
  
  Revision  ChangesPath
  1.6   +16 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java
  
  Index: WebappLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- WebappLoader.java 16 Oct 2002 16:08:29 -  1.5
  +++ WebappLoader.java 10 Jan 2003 18:59:50 -  1.6
  @@ -545,6 +545,18 @@
   
   }
   
  +public String[] getRepositories() {
  +return ((String[])repositories.clone());
  +}
  +
  +public String getRepositoriesString() {
  +StringBuffer sb=new StringBuffer();
  +for( int i=0; imailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans GlobalResourcesLifecycleListener.java

[costin]

costin  2003/01/10 10:57:06

  Modified:catalina/src/share/org/apache/catalina/mbeans
GlobalResourcesLifecycleListener.java
  Log:
  If no java: naming is found - report it but don't be too verbose.
  
  Revision  ChangesPath
  1.2   +6 -7  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/GlobalResourcesLifecycleListener.java
  
  Index: GlobalResourcesLifecycleListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/GlobalResourcesLifecycleListener.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- GlobalResourcesLifecycleListener.java 18 Jul 2002 16:47:58 -  1.1
  +++ GlobalResourcesLifecycleListener.java 10 Jan 2003 18:57:06 -  1.2
  @@ -166,9 +166,8 @@
   try {
   context = (Context) (new InitialContext()).lookup("java:/");
   } catch (NamingException e) {
  -e.printStackTrace();
  -throw new IllegalStateException
  -("No global naming context defined for server");
  +log("No global naming context defined for server");
  +return;
   }
   
   // Recurse through the defined global JNDI resources context
  
  
  

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans ServerLifecycleListener.java

[costin]

costin  2003/01/10 10:55:58

  Modified:catalina/src/share/org/apache/catalina/mbeans
ServerLifecycleListener.java
  Log:
  Use commons-logging. Most of the code here should disapear as we
  add it in the core objects ( remember - we voted that 5.0 will require and
  use jmx )
  
  Revision  ChangesPath
  1.6   +190 -192  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
  
  Index: ServerLifecycleListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- ServerLifecycleListener.java  10 Dec 2002 18:49:06 -  1.5
  +++ ServerLifecycleListener.java  10 Jan 2003 18:55:57 -  1.6
  @@ -66,15 +66,9 @@
   
   import java.beans.PropertyChangeEvent;
   import java.beans.PropertyChangeListener;
  -import java.io.File;
  -import java.io.InputStream;
  -import java.net.URL;
  -import java.util.Collection;
  -import java.util.Iterator;
   import java.util.StringTokenizer;
   import javax.management.MBeanException;
  -import javax.management.MBeanServer;
  -import javax.management.ObjectName;
  +
   import org.apache.catalina.Connector;
   import org.apache.catalina.Container;
   import org.apache.catalina.ContainerEvent;
  @@ -84,12 +78,12 @@
   import org.apache.catalina.Engine;
   import org.apache.catalina.Globals;
   import org.apache.catalina.Host;
  -import org.apache.catalina.Loader;
  -import org.apache.catalina.Logger;
  -import org.apache.catalina.Manager;
   import org.apache.catalina.Lifecycle;
   import org.apache.catalina.LifecycleEvent;
   import org.apache.catalina.LifecycleListener;
  +import org.apache.catalina.Loader;
  +import org.apache.catalina.Logger;
  +import org.apache.catalina.Manager;
   import org.apache.catalina.Realm;
   import org.apache.catalina.Server;
   import org.apache.catalina.ServerFactory;
  @@ -104,7 +98,8 @@
   import org.apache.catalina.deploy.ContextResource;
   import org.apache.catalina.deploy.ContextResourceLink;
   import org.apache.catalina.deploy.NamingResources;
  -import org.apache.catalina.deploy.ResourceParams;
  +import org.apache.commons.logging.Log;
  +import org.apache.commons.logging.LogFactory;
   
   
   /**
  @@ -120,6 +115,9 @@
   public class ServerLifecycleListener
   implements ContainerListener, LifecycleListener, PropertyChangeListener {
   
  +private static Log log = LogFactory.getLog(ServerLifecycleListener.class);
  +
  +
   
   // - Properties
   
  @@ -193,7 +191,7 @@
   (Valve) event.getData());
   }
   } catch (Exception e) {
  -log("Exception processing event " + event, e);
  +log.error("Exception processing event " + event, e);
   }
   
   }
  @@ -223,7 +221,7 @@
   try {
   MBeanUtils.createRMIAdaptor(adaptor);
   } catch (Exception e) {
  -log("createAdaptor: Exception", e);
  +log.error("createAdaptor: Exception", e);
   }
   }
   
  @@ -292,7 +290,7 @@
  event.getOldValue(),
  event.getNewValue());
   } catch (Exception e) {
  -log("Exception handling Container property change", e);
  +log.error("Exception handling Container property change", e);
   }
   } else if (event.getSource() instanceof DefaultContext) {
   try {
  @@ -302,7 +300,7 @@
event.getOldValue(),
event.getNewValue());
   } catch (Exception e) {
  -log("Exception handling DefaultContext property change", e);
  +log.error("Exception handling DefaultContext property change", e);
   }
   } else if (event.getSource() instanceof NamingResources) {
   try {
  @@ -312,7 +310,7 @@
event.getOldValue(),
event.getNewValue());
   } catch (Exception e) {
  -log("Exception handling NamingResources property change", e);
  +log.error("Exception handling NamingResources property change", e);
   }
   } else if (event.getSource() instanceof Server) {
   try {
  @@ -321,7 +319,7 @@
   event.getOldValue(),
   event.getNewValue());
   } catch (Exception e) {
  -log("Exception handing Server property change", e);
  +   

DO NOT REPLY [Bug 15966] New: - Jasper parser is incorrectly handling empty jsp:body elements

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

Jasper parser is incorrectly handling empty jsp:body elements

   Summary: Jasper parser is incorrectly handling empty jsp:body
elements
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Given the following productions:

JspBodyBody ::= (S? JspBodyEmptyBody)
  | (S> '>' (JspBodyBodyContent - '') ''

and

JspBodyEmptyBody ::=   '/>'
 | '>'
 | 

Jasper generates a translation error with the error message of 
" must not have any attributes" When it encounters 
something like:

  
 
  


For the following code snippet:

   
  
   

This error message is generated at translation time:

  "Empty body not allowed for "  

which is incorrect according to the grammar.

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

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

[costin]

costin  2003/01/10 10:48:49

  Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
  Log:
  Some versions of digester ( head ? ) seem to require the classloader to
  be set. It doesn't hurt to set it explicitely.
  
  Revision  ChangesPath
  1.12  +6 -7  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java
  
  Index: Catalina.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- Catalina.java 5 Dec 2002 15:57:48 -   1.11
  +++ Catalina.java 10 Jan 2003 18:48:49 -  1.12
  @@ -70,13 +70,11 @@
   import java.io.IOException;
   import java.io.OutputStream;
   import java.net.Socket;
  -import java.util.Stack;
   import org.apache.catalina.Container;
   import org.apache.catalina.Lifecycle;
   import org.apache.catalina.LifecycleException;
  -import org.apache.catalina.LifecycleListener;
   import org.apache.catalina.Server;
  -import org.apache.catalina.Loader;
  +import org.apache.catalina.core.StandardServer;
   import org.apache.catalina.security.SecurityConfig;
   import org.apache.commons.digester.Digester;
   import org.apache.commons.digester.Rule;
  @@ -289,6 +287,7 @@
   if (debug>0)
   digester.setDebug(debug);
   digester.setValidating(false);
  +digester.setClassLoader(StandardServer.class.getClassLoader());
   
   // Configure the actions we will be using
   digester.addObjectCreate("Server",
  
  
  

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

Re: Duplicate session IDs are *common*

[Eric Rescorla]

Jim Jagielski <[EMAIL PROTECTED]> writes:

> Eric Rescorla wrote:
> > 
> > Glenn Olander <[EMAIL PROTECTED]> writes:
> > > 5) The strength of the PRNG is largely irrelevant
> > > 
> > > As a user, I wouldn't trust any solution which lacks a check for
> > > duplicate session id's, regardless of the strength of the PRNG.
> > This doesn't seem to me to be a plausible position in view
> > of the fact that all of our security mechanisms absolutely
> > depend on statistical uniqueness of randomly generated large
> > numbers.
> > 
> 
> These are 2 different points I think. If you randomly generate numbers
> between 1 and 1,000,000 you will, after a point in time, have
> duplicate numbers.
Yes, but if you randomly generate numbers between 1 and 2^128, you'll
have to generate roughly 2^64 random numbers to have a good chance of
getting a duplicate. Sure, over time you'll get a duplicate,
but in this context over time needs to be measured over a
time scale far in excess of the time scale that is interesting.

-Ekr

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

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

DO NOT REPLY [Bug 15964] New: - Wrong source paths in generated SMAP file entries

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

Wrong source paths in generated SMAP file entries

   Summary: Wrong source paths in generated SMAP file entries
   Product: Tomcat 5
   Version: 5.0.0
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


One of the new features of Jasper in Tomcat 5 is that it attaches a "Source
Map" attribute to class files to describe the file name and line number
mapping from a JSP source file to the generated Java source file.

According to JSR-45, each file entry in the SMAP defines a source name,
and optionally, a source path.  The SMAP that I see in the class files
generated by Jasper doesn't specify a source path.  This means that the
source path defaults to a subdirectory based on the package of the class
file.  In other words, for class files generated by Jasper, the source
path ends up being "org/apache/jsp".  This is the source path for both
the "JSP" stratum and the "Java" stratum.  The problem is that this
source path is wrong for both strata, given how Jasper stores files.

An example would help explain this.  Say the user wants to debug the
"numguess.jsp" file that's part of the "jsp-examples" web application
that comes with Tomcat.  I've written a debugger that allows the user to
enter directory names that the debugger should search for source files.
Other debuggers have pretty much the same technique for finding source
files.  For this discussion, let's call this the debugger's "search
path".  Let's say the entries in the search path are "A" and "B".  When
a debugger wants to locate a source file corresponding to a particular
location in a class, it uses the Java Debugging Interface (JDI) API to
read the source name and source path for the stratum it intends to use
for the display.  Let's assume for the moment it wants to use the JSP
stratum.  So the debugger first looks for the file
"A/org/apache/jsp/numguess.jsp", then for
"B/org/apache/jsp/numguess.jsp".  You get the idea.  The problem is that
there's no directory that the user could specify in the debugger's
search path that allows the debugger to find the file, because the jsp
file doesn't reside in a "org/apache/jsp" subdirectory of any directory.
Instead, it resides in the "TH/webapps/jsp-examples/num" directory,
where "TH" is the Tomcat home directory.

One possibility would be for Jasper to specify "." (just a dot, meaning
the current directory) as the source path in the SMAP for the JSP
stratum.  Then the user could enter "TH/webapps/jsp-examples/num" as the
path to search.  The debugger would be able to locate the file, since it
would then be looking for "TH/webapps/jsp-examples/num/./numguess.jsp".
But I have a better suggestion:  How about specifying the subdirectory
of the directory in which the web application is expanded?  Continuing
the example, this means specifying the source path "num" for the file
"numguess.jsp".  The user would then enter "TH/webapps/jsp-examples"
into the debugger's search path.  When the debugger tries to locate the
file, it will paste together these three pieces and come up with
"TH/webapps/jsp-examples/num/numguess.jsp", successfully finding the
file.  The advantage of this approach is that the user need only enter
the top directory of the web application into the debugger's search path
and the debugger will then be able to locate any JSP file for the web
application.  If "." were used, the user would need to enter every
directory under the web application's top directory that contains a JSP
to be debugged into the debugger's search path.

A similar problem exists for the "Java" stratum.  If the user of the
debugger wanted to debug the JSP using the Java stratum, the debugger
would try to locate the "numguess_jsp.java" file by searching the
subdirectories of the debugger's search path.  But again, the debugger
would be unable to find the java file because it doesn't reside in a
"org/apache/jsp" subdirectory of any directory.  Just poking around,
Jasper seems to put the Java source file under the "TH/work" directory, in
my case in the directory "TH/work/Standalone/localhost/jsp-examples/num".
The solution here isn't as simple as for the JSP stratum, however, since I
don't think it's possible to change the source path for a file in the Java
stratum in the SMAP.  In other words, the source path for
"numguess_jsp.java" is stuck being "org/apache/jsp", since that's the
package the class is in.  So, I can think of only two solutions:

1. Put the java file into the expected hierarchy.  Perhaps designate that
   

cvs commit: jakarta-servletapi-5/jsr152/examples/WEB-INF/jsp2 jsp2-example-taglib.tld

[kinman]

kinman  2003/01/10 10:21:38

  Modified:jsr152/examples/WEB-INF/jsp2 jsp2-example-taglib.tld
  Log:
  - Patch by Jan Luehe:
  
   has always been mandatory, but is only now being enforced.
  
  Revision  ChangesPath
  1.2   +1 -0  
jakarta-servletapi-5/jsr152/examples/WEB-INF/jsp2/jsp2-example-taglib.tld
  
  Index: jsp2-example-taglib.tld
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-5/jsr152/examples/WEB-INF/jsp2/jsp2-example-taglib.tld,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jsp2-example-taglib.tld   7 Sep 2002 00:47:59 -   1.1
  +++ jsp2-example-taglib.tld   10 Jan 2003 18:21:38 -  1.2
  @@ -6,6 +6,7 @@
   version="2.0">
   A tag library exercising SimpleTag handlers.
   1.0
  +2.0
   SimpleTagLibrary
   /SimpleTagLibrary
   
  
  
  

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

cvs commit: jakarta-servletapi-5/jsr154/src/share/dtd jsp_2_0.xsd

[kinman]

kinman  2003/01/10 10:17:03

  Modified:jsr152/src/share/dtd jsp_2_0.xsd
   jsr152/src/share/javax/servlet/jsp/tagext TagInfo.java
VariableInfo.java
   jsr154/src/share/dtd jsp_2_0.xsd
  Log:
  - Patch by Mark Roth:
  
  Fixes leading up to the second proposed final draft
  release of the specification.
  
  jsr152/src/share/dtd/jsp_2_0.xsd
 - Updated comments for jsp-property-groupType
  
  jsr154/src/share/dtd/jsp_2_0.xsd
 - Updated comments for jsp-property-groupType
  
  jsr152/src/share/javax/servlet/jsp/tagext/TagInfo.java
 - Fixed typo: 'the the'
  
  jsr152/src/share/javax/servlet/jsp/tagext/VariableInfo.java
 - Fixed typo: 'AT_NESTED' --> 'NESTED'
 - Fixed table - AT_BEGIN and NESTED should be synchronized
   after doStartTag() if EVAL_BODY_INCLUDE is returned.
  
  Revision  ChangesPath
  1.6   +4 -4  jakarta-servletapi-5/jsr152/src/share/dtd/jsp_2_0.xsd
  
  Index: jsp_2_0.xsd
  ===
  RCS file: /home/cvs/jakarta-servletapi-5/jsr152/src/share/dtd/jsp_2_0.xsd,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jsp_2_0.xsd   8 Nov 2002 21:30:20 -   1.5
  +++ jsp_2_0.xsd   10 Jan 2003 18:17:02 -  1.6
  @@ -8,7 +8,7 @@
version="2.0">
   
   
  -@(#)jsp_2_0.xsds 1.14 11/06/02
  +@(#)jsp_2_0.xsds 1.15 01/02/03
   
   
   
  @@ -136,10 +136,10 @@
   All files so described are deemed to be JSP files.  The
   following additional properties can be described:
   
  -- Control enabling of EL evaluation.
  -- Control enabling of Scripting elements.
  +- Control whether EL is ignored
  +- Control whether scripting elements are invalid
   - Indicate pageEncoding information.
  -- Indicating that a resource is a JSP document
  +- Indicate that a resource is a JSP document (XML)
   - Prelude and Coda automatic includes.
   
   
  
  
  
  1.5   +1 -1  
jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/TagInfo.java
  
  Index: TagInfo.java
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/TagInfo.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- TagInfo.java  4 Nov 2002 17:44:24 -   1.4
  +++ TagInfo.java  10 Jan 2003 18:17:02 -  1.5
  @@ -268,7 +268,7 @@
*
* @param data TagData describing this action.
* @return if a TagExtraInfo object is associated with this TagInfo, the
  - * the result of getTagExtraInfo().getVariableInfo( data ), otherwise
  + * result of getTagExtraInfo().getVariableInfo( data ), otherwise
* null if the tag has no "id" attribute or new VariableInfo[] {
* new VariableInfo( data.getId(), "java.lang.Object", true,
* VariableInfo.NESTED ) } if an "id" attribute is present.
  
  
  
  1.7   +5 -2  
jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/VariableInfo.java
  
  Index: VariableInfo.java
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/VariableInfo.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- VariableInfo.java 18 Dec 2002 18:35:37 -  1.6
  +++ VariableInfo.java 10 Jan 2003 18:17:02 -  1.7
  @@ -193,9 +193,9 @@
*   
* BodyTag
* 
  - * 
  + * AT_BEGIN, 
NESTED1
* 
  - * AT_BEGIN, AT_NESTED
  + * AT_BEGIN, 
NESTED1
* 
* AT_BEGIN, NESTED
* 
  @@ -220,6 +220,9 @@
*   
* 
* 
  + * 1 Called after doStartTag() if 
  + * EVAL_BODY_INCLUDE is returned, or after 
  + * doInitBody() otherwise.
* 
*
* Variable Information in the TLD
  
  
  
  1.6   +4 -4  jakarta-servletapi-5/jsr154/src/share/dtd/jsp_2_0.xsd
  
  Index: jsp_2_0.xsd
  ===
  RCS file: /home/cvs/jakarta-servletapi-5/jsr154/src/share/dtd/jsp_2_0.xsd,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jsp_2_0.xsd   8 Nov 2002 21:30:21 -   1.5
  +++ jsp_2_0.xsd   10 Jan 2003 18:17:03 -  1.6
  @@ -8,7 +8,7 @@
version="2.0">
   
   
  -@(#)jsp_2_0.xsds 1.14 11/06/02
  +@(#)jsp_2_0.xsds 1.15 01/02/03
   
   
   
  @@ -136,10 +136,10 @@
   All files so described are deemed to be JSP files.  The
   following additional properties can be described:
   
  -- Control enabling of EL evaluation.
  -- Control enabling of Scripting elements.
  +- Control whether EL is ignored
  +- Control whether scripting elements are invalid
   - Indicate pageEncoding information.
  -- Indicating that a resource is a J

Re: Duplicate session IDs are *common*

[Jim Jagielski]

Eric Rescorla wrote:
> 
> Glenn Olander <[EMAIL PROTECTED]> writes:
> > 5) The strength of the PRNG is largely irrelevant
> > 
> > As a user, I wouldn't trust any solution which lacks a check for
> > duplicate session id's, regardless of the strength of the PRNG.
> This doesn't seem to me to be a plausible position in view
> of the fact that all of our security mechanisms absolutely
> depend on statistical uniqueness of randomly generated large
> numbers.
> 

These are 2 different points I think. If you randomly generate numbers
between 1 and 1,000,000 you will, after a point in time, have
duplicate numbers. In fact, all will be duplicated over some time.
Valid and "trusted" session ids should be random and unique at the
same time. PRNG takes care of one aspect.

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

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

DO NOT REPLY [Bug 15962] New: - New option to create the package name based on the jsp directory structure

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

New option to create the package name based on the jsp directory structure

   Summary: New option to create the package name based on the jsp
directory structure
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
   URL: http://www.mail-archive.com/tomcat-
[EMAIL PROTECTED]/msg37375.html
OS/Version: Windows NT/2K
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Excerpted from http://www.mail-archive.com/tomcat-
[EMAIL PROTECTED]/msg37375.html

"I'd like to propose a change to org.apache.jasper.JspC in Tomcat4.1.12.  
Specifically, I'd like to introduce a new command line argument: "-pp" to apply 
a package name prefix and create the package name based on the jsp directory 
structure.  Tomcat4's "-p" option applies the package name prefix, but creates 
all the jsps in the same package.  This leads to "duplicate class" problems if 
two jsps in different directories share the same name."

I would also like to see this enhancement made to jspc.  Please see the above 
URL for a complete description of the problem and a proposed solution (source 
code included).

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

Re: Duplicate session IDs are *common*

[Eric Rescorla]

Glenn Olander <[EMAIL PROTECTED]> writes:
> 5) The strength of the PRNG is largely irrelevant
> 
> As a user, I wouldn't trust any solution which lacks a check for
> duplicate session id's, regardless of the strength of the PRNG.
This doesn't seem to me to be a plausible position in view
of the fact that all of our security mechanisms absolutely
depend on statistical uniqueness of randomly generated large
numbers.

-Ekr

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

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

DO NOT REPLY [Bug 15961] New: - getBodyContent() is not returning null when the action has only jsp:attribute actions within the body.

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

getBodyContent() is not returning null when the action has only jsp:attribute actions 
within the body.

   Summary: getBodyContent() is not returning null when the action
has only jsp:attribute actions within the body.
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


JSP.5.11 states:

"If one or more jsp:attribute elements appear in the body of a tag invocation
but no jsp:body element appears, it is the equivalent of the tag having an empty
body"

Consider the following example using a tag handler that extends BodyTagSupport
and implements DynamicAttributes


value1
value2


The cemptybody action attempts to validate that a call to getBodyContent()
returns null.

Keep in mind that the javadocs state that setBodyContent() will not be invoked for 
an empty tag.

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

DO NOT REPLY [Bug 15959] New: - Confusing Error Message with jsp:forward

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

Confusing Error Message with jsp:forward

   Summary: Confusing Error Message with jsp:forward
   Product: Tomcat 4
   Version: 4.1.18
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When a user added an invalid attribute to jsp:param in a jsp:forward tag they 
got an error "org.apache.jasper.JasperException: /fixedData/cpEdit.jsp(21,3) 
Param action: Invalid attribute, type".  The code is below...

   



 
  
   

Could it not say "jsp:param does not accept attribute 'type'."

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

Re: Duplicate session IDs are *common*

[Glenn Olander]

Here's a follow-up on the bug report I submitted that started this thread.

1) We confirmed the problem is a duplicate session id.

Luckily we were logging session id's. It took a lot of hunting through
access logs, but we did indeed find two sessions which were started a
couple of minutes apart, with a number of intervening sessions, which
had duplicate session id's. The pair of sessions corresponded to the user
report of seeing someone else's session data. We're using 4.1.12.

2) I don't believe this is *common*

The problem hasn't been duplicated in our app, so I'm not sure I'd call
this a common problem, but that's a subjective term.

3) I believe this is a serious vulnerability

There should probably be some sort of an alert delivered to tomcat
users to let them know of this problem.

4) A simple patch is available

It is not necessary to use the head version of tomcat to fix the problem.
Simply install your own manager class, which subclasses StandardManager, 
which has the duplicate session id checking implemented. In other words,
a simple patch on an existing tomcat installation can fix this.

5) The strength of the PRNG is largely irrelevant

As a user, I wouldn't trust any solution which lacks a check for
duplicate session id's, regardless of the strength of the PRNG. The head 
revision now includes such a check, so I believe the problem has been solved.
Even the weakest of PRNG's would generate a collision only rarely, so
I wouldn't worry about improving its strength.

- Glenn

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

Re: Proposal: CanAccessLink(..) test

[Jeanfrancois Arcand]

Hi Marki, see inline

Mark Harwood wrote:


Its cool having authorisation restrictions enforced when accessing a page but 
it would also be useful to query these restrictions when choosing to offer a 
link in other pages.

I have an implementation which offers this query capability based on a hack of 
Tomcat authorisation code. The method signature is:

boolean canIAccess(String url, String method, HttpServletRequest 
currentRequest, ServletContext context)


Is this sort of thing worth rolling into Tomcat somewhere? Without such a 
feature you effectively end up declaring security restrictions twice - once in 
web.xml declarations and once in pages that choose to offer links to these 
secured pages.

-1 for portable reason. The security mechanism will not work the same 
way if I define my web app using Tomcat and then moving it under another 
Servlet container. Some user may think their application are secure 
under Tomcat, and then move it to another container (security issue).

If you think that every Servlet container should support your method, 
you can submit your proposal to [EMAIL PROTECTED] 


If other tomcat-dev are interested to your proposal,  at least make that 
behaviour optional and turned off by default :-)

-- Jeanfrancois





Cheers
Mark Harwood


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


 

RE: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

On Thu, 9 Jan 2003, Schnitzer, Jeff wrote:

> One thing to contemplate is that if you have 100,000 sessions and you
> get 10 new sessions created every second, that's the equivalent of 1
> million inadvertent hack attempts every single second.  Granted that's
> still small compared to the total size of a truly randomly generated
> 128-bit number, but I wouldn't run a banking application on it.

Am I right to understand that what is needed is only:

->  an unguessible ID ?
->  which is unique within a certain realm ?

If that is the case one can tailor the ID to do exactly that. And,
espcially, not a bit more.

Dw




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

Proposal: CanAccessLink(..) test

[Mark Harwood]

Its cool having authorisation restrictions enforced when accessing a page but 
it would also be useful to query these restrictions when choosing to offer a 
link in other pages.

I have an implementation which offers this query capability based on a hack of 
Tomcat authorisation code. The method signature is:

boolean canIAccess(String url, String method, HttpServletRequest 
currentRequest, ServletContext context)


Is this sort of thing worth rolling into Tomcat somewhere? Without such a 
feature you effectively end up declaring security restrictions twice - once in 
web.xml declarations and once in pages that choose to offer links to these 
secured pages.

Cheers
Mark Harwood


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

RE: Duplicate session IDs are *common*

[Martin Algesten]

> Note that you would need 1 million sessions that are active 
> at the same time - if a session expires and the id is reused 
> there is no harm.

If I leave my browser open and go for lunch and someone else gets my
expired session id, I return and continue browsing, wouldn't that cause
problems?

Martin

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

Re: Duplicate session IDs are *common*

[Tim Funk]

I was unable to reproduce a collision too. I took ManagerBase and 
converted it to a standalone java program (by stripping out code) to see 
if I might get duplicates. But I keep running out of memory near 1 
million sessions.

java Collide 1
Generates 1 ids. (Change the number to change the number of sessions 
to create)

In case someone is really bored ...


-Tim

Remy Maucherat wrote:
Schnitzer, Jeff wrote:


I've already patched the 4.1.12 version we are running with the fix that
is currently in CVS.  Unfortunately our only notification of when the
problem occurs is when users notice (which they probably wouldn't unless
they acquired an administrative session) and choose to inform us.  I
won't "know" the fix worked without waiting some number of weeks.



You could icrement a variable to list the number of duplicates detected. 
The patch should guarantee uniqueness of the ids, and this is supposed 
to fix the issue.

One thing to contemplate is that if you have 100,000 sessions and you
get 10 new sessions created every second, that's the equivalent of 1
million inadvertent hack attempts every single second.  Granted that's
still small compared to the total size of a truly randomly generated
128-bit number, but I wouldn't run a banking application on it.



In theory, the odds are so small it just cannot happen. I can't 
reproduce an id collision so far.

Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



/*
 * 
 *
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 1999 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:
 *   "This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
 *Foundation" must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache"
 *nor may "Apache" appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of the Apache Software Foundation.  For more
 * information on the Apache Software Foundation, please see
 * .
 *
 * [Additional notices, if required by prior licensing conditions]
 *
 */

import java.io.IOException;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.Random;

public class Collide {
protected MessageDigest digest = null;
protected String entropy = null;
protected Random random = null;
protected String randomClass = "java.security.SecureRandom";
protected static final String DEFAULT_ALGORITHM = "MD5";
protected static final int SESSION_ID_BYTES = 16;
protected String algorithm = DEFAULT_ALGORITHM;

/**
 * Return the MessageDigest object to be used for calculating
 * session identifiers.  If none has been created yet, initialize
 * one the first time this method is called.
 *

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote ActionCode.java

[remm]

remm2003/01/10 02:21:34

  Modified:coyote/src/java/org/apache/coyote ActionCode.java
  Log:
  - Fix code number.
  
  Revision  ChangesPath
  1.12  +1 -1  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java
  
  Index: ActionCode.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- ActionCode.java   4 Dec 2002 23:33:27 -   1.11
  +++ ActionCode.java   10 Jan 2003 10:21:34 -  1.12
  @@ -134,7 +134,7 @@
* Callback for lazy evaluation - extract the SSL-certificate 
* (including forcing a re-handshake if necessary)
*/
  -public static final ActionCode ACTION_REQ_SSL_CERTIFICATE = new ActionCode(14);
  +public static final ActionCode ACTION_REQ_SSL_CERTIFICATE = new ActionCode(15);
   
   
   // --- Constructors
  
  
  

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

Re: Calling into Servlet Container without HTTP

[Remy Maucherat]

Kelly Chen wrote:

Hi, there:

I am looking for a way to invoke a Servlet without going through HTTP. I 
understand that this has to be container specific logic, so I would like 
to do this on Tomcat 4.1.18.

The idea is to use JSP as a template system, but JSP has be to run 
inside a Servlet Container. So I would like to be able to invoke JSP 
through Tomcat and get result directly without going through HTTP.

I just wonder if anyone has attempt the similar task  or has some points 
to share.

I don't see that much benefit in avoiding HTTP, as there's a lot of code 
there already, and the code is fast. What should be avoided are the 
socket operations, which are expensive.

If you take a look at Coyote, you could write a new protocol handler 
which would read/write HTTP stuff in memory, while reusing the 
Http11Processor class.

Alternately, you can create a brand new protocol handler. That would be 
the most efficient, and it's not that hard. You can use the JK and 
HTTP/1.1 handlers as examples (but no, there are no docs right now).

Remy



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

[Fwd: Tomcat manager - Java client]

[Henri Gomez]

FYI.

--- Begin Message ---
I've written a Java client that talks to the Tomcat servlet manager application. The 
program allows you to view, stop, start and reload servlet applications and acts as a 
visual front end to the Tomcat manager.

The program isn't complete but is still useful in its current form. 

I'm wondering if you would have an interest in using or developing the application 
further. I'm happy to donate the source code. Attached you'll find an executable JAR 
file that has been  tested under Windows (98 and NT).

To run, you need to enter the URL of a server (local or remote), then Connect. It will 
prompt for authentication then display a list of servlet applications.

Please let me know if the program is of interest.

John Hamilton
Teacher, Computing and Information Technology.
Swinburne University, Technical and Further Education division.



tcman.jar
Description: PKZIP (compressed) files
--- End Message ---
--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14391] - tomcat.exe Fails with an Application Exception (access violation)

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

tomcat.exe Fails with an Application Exception (access violation)





--- Additional Comments From [EMAIL PROTECTED]  2003-01-10 09:19 ---
For information, I'm observing a similar problem with 4.1.18, Win2k and SP3.
Can anyone shed any further light on this?

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

DO NOT REPLY [Bug 15950] New: - automatic assignment of context path leads to http 404 errors for servlets

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

automatic assignment of context path leads to http 404 errors for servlets

   Summary: automatic assignment of context path leads to http 404
errors for servlets
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In /tomcat-docs/appdev/deployment.html a method is described to deploy a web 
app, ie: "Copy unpacked directory hierarchy into a subdirectory in directory 
$CATALINA_HOME/webapps/." I'm a total newbie and there may be a way around this 
but I've spent 2 days trying to figure out why my servlets work when I put them 
in the examples folder but not when I put them into a folder created as above. 
It appears that the docbase Tomcat creates this way is an absolute path that is 
not recognized when trying to run any servlets in /WEB-INF/classes. It just 
gives HTTP 404 errors saying the requested resource is not available. When I 
edited server.xml to change docbase="F:\Tomcat\webapps\myProjects" to 
just "myProjects" everything worked fine. Several folders created by Tomcat, 
including ROOT and tomcat-docs, also have absolute paths in server.xml and I 
could not get the servlets to work in these folders either until I changed to 
relative paths.

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

DO NOT REPLY [Bug 15944] - Compiled JSP page includes default setContentType() Call when not specified in the JSP page.

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

Compiled JSP page includes default setContentType() Call when not specified in the JSP 
page.





--- Additional Comments From [EMAIL PROTECTED]  2003-01-10 08:53 ---

according to jsp spec 1.2, section 2.10.1:
jsp pages always generate a setContentType that defaults to 
text/html;charset:iso-8859-1.

Dynamic setting of content type relies on an underlying invocation on
response.setContentType(). That method can be invoked as long as no content has
been been sent to the response stream.

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