date:20010111


remm01/01/11 22:59:08

  Modified:catalina/src/share/org/apache/naming/resources
BaseDirContext.java FileDirContext.java
  Added:   catalina/src/share/org/apache/naming/resources
DirContextURLConnection.java
DirContextURLStreamHandler.java
  Log:
  - Add a URL handler for the "jndi" protocol, which allow access to JNDI
directory contexts. I don't know yet if a StreamHandlerFactory will be
necessary to solve the classloader repository initialization problems.
  - Add additional constructors for the contexts.
  
  Revision  ChangesPath
  1.2   +13 -5 
jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/BaseDirContext.java
  
  Index: BaseDirContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/BaseDirContext.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- BaseDirContext.java   2001/01/10 04:46:49 1.1
  +++ BaseDirContext.java   2001/01/12 06:59:08 1.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/BaseDirContext.java,v
 1.1 2001/01/10 04:46:49 remm Exp $
  - * $Revision: 1.1 $
  - * $Date: 2001/01/10 04:46:49 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/BaseDirContext.java,v
 1.2 2001/01/12 06:59:08 remm Exp $
  + * $Revision: 1.2 $
  + * $Date: 2001/01/12 06:59:08 $
*
* 
*
  @@ -85,7 +85,7 @@
* Directory Context implementation helper class.
*
* @author Remy Maucherat
  - * @version $Revision: 1.1 $ $Date: 2001/01/10 04:46:49 $
  + * @version $Revision: 1.2 $ $Date: 2001/01/12 06:59:08 $
*/
   
   public abstract class BaseDirContext implements DirContext {
  @@ -98,7 +98,15 @@
   
   
   /**
  - * Builds a proxy directory context using the given environment.
  + * Builds a base directory context.
  + */
  +public BaseDirContext() {
  +this.env = new Hashtable();
  +}
  +
  +
  +/**
  + * Builds a base directory context using the given environment.
*/
   public BaseDirContext(Hashtable env) {
   this.env = env;
  
  
  
  1.2   +16 -7 
jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java
  
  Index: FileDirContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- FileDirContext.java   2001/01/10 04:46:49 1.1
  +++ FileDirContext.java   2001/01/12 06:59:08 1.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
 1.1 2001/01/10 04:46:49 remm Exp $
  - * $Revision: 1.1 $
  - * $Date: 2001/01/10 04:46:49 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
 1.2 2001/01/12 06:59:08 remm Exp $
  + * $Revision: 1.2 $
  + * $Date: 2001/01/12 06:59:08 $
*
* 
*
  @@ -97,7 +97,7 @@
* Filesystem Directory Context implementation helper class.
*
* @author Remy Maucherat
  - * @version $Revision: 1.1 $ $Date: 2001/01/10 04:46:49 $
  + * @version $Revision: 1.2 $ $Date: 2001/01/12 06:59:08 $
*/
   
   public class FileDirContext extends BaseDirContext {
  @@ -118,6 +118,14 @@
   /**
* Builds a file directory context using the given environment.
*/
  +public FileDirContext() {
  +super();
  +}
  +
  +
  +/**
  + * Builds a file directory context using the given environment.
  + */
   public FileDirContext(Hashtable env) {
   super(env);
   }
  @@ -517,7 +525,7 @@
   public void bind(String name, Object obj, Attributes attrs)
   throws NamingException {
   // No custom attributes
  -bind(name, obj);
  +// FIXME
   }
   
   
  @@ -542,7 +550,7 @@
   public void rebind(String name, Object obj, Attributes attrs)
   throws NamingException {
   // No custom attributes
  -rebind(name, obj);
  +// FIXME
   }
   
   
  @@ -565,7 +573,8 @@
*/
   public DirContext createSubcontext(String name, Attributes attrs)
   throws NamingException {
  -return (DirContext) createSubcontext(name);
  +// FIXME
  +return null;
   }
   
   
  
  
  
  1.1  
jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java
  
  Index: DirContextURLConne

cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java WebdavServlet.java


remm01/01/11 22:55:35

  Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java WebdavServlet.java
  Log:
  - Partly rewritten the DefaultServlet and WebdavServlet to use DirContext.
  - Some parts of the code could be simplified to take advantage of the JNDI
naming conventions. For example, when the member of a collection are
requested, JNDI does return the names relative to the parent collection's
context. Before, the Resources were returning the full names of the child
resources.
  
  Revision  ChangesPath
  1.19  +363 -43   
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
  
  Index: DefaultServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- DefaultServlet.java   2001/01/08 16:45:55 1.18
  +++ DefaultServlet.java   2001/01/12 06:55:34 1.19
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.18 2001/01/08 16:45:55 remm Exp $
  - * $Revision: 1.18 $
  - * $Date: 2001/01/08 16:45:55 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.19 2001/01/12 06:55:34 remm Exp $
  + * $Revision: 1.19 $
  + * $Date: 2001/01/12 06:55:34 $
*
* 
*
  @@ -66,6 +66,8 @@
   
   
   import java.io.BufferedInputStream;
  +import java.io.ByteArrayOutputStream;
  +import java.io.ByteArrayInputStream;
   import java.io.File;
   import java.io.FileInputStream;
   import java.io.InputStream;
  @@ -95,16 +97,19 @@
   import javax.servlet.http.HttpServlet;
   import javax.servlet.http.HttpServletRequest;
   import javax.servlet.http.HttpServletResponse;
  +import javax.naming.NamingException;
  +import javax.naming.InitialContext;
  +import javax.naming.Context;
  +import javax.naming.NamingEnumeration;
  +import javax.naming.NameClassPair;
  +import javax.naming.directory.DirContext;
  +import javax.naming.directory.Attribute;
  +import javax.naming.directory.Attributes;
  +import org.apache.naming.resources.Resource;
  +import org.apache.naming.resources.ResourceAttributes;
   import org.apache.catalina.Globals;
  -import org.apache.catalina.Resources;
  -import org.apache.catalina.core.ApplicationContext;
  -import org.apache.catalina.resources.ResourceBean;
  -import org.apache.catalina.resources.DirectoryBean;
   import org.apache.catalina.util.MD5Encoder;
   import org.apache.catalina.util.StringManager;
  -import org.apache.catalina.util.xml.SaxContext;
  -import org.apache.catalina.util.xml.XmlAction;
  -import org.apache.catalina.util.xml.XmlMapper;
   
   
   /**
  @@ -113,7 +118,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.18 $ $Date: 2001/01/08 16:45:55 $
  + * @version $Revision: 1.19 $ $Date: 2001/01/12 06:55:34 $
*/
   
   public class DefaultServlet
  @@ -201,6 +206,12 @@
   
   
   /**
  + * JNDI resources name.
  + */
  +protected static final String RESOURCES_JNDI_NAME = "java:/comp/Resources";
  +
  +
  +/**
* The string manager for this package.
*/
   protected static StringManager sm =
  @@ -295,6 +306,38 @@
   
   
   /**
  + * Get resources. This method will try to retrieve the resources through
  + * JNDI first, then in the servlet context if JNDI has failed (it could be
  + * disabled). It will return null.
  + * 
  + * @return A JNDI DirContext, or null.
  + */
  +protected DirContext getResources() {
  +
  +// First : try JNDI
  +try {
  +return 
  +(DirContext) new InitialContext().lookup(RESOURCES_JNDI_NAME);
  +} catch (NamingException e) {
  +// Failed
  +} catch (ClassCastException e) {
  +// Failed : Not the right type
  +}
  +
  +// If it has failed, try the servlet context
  +try {
  +return (DirContext) getServletContext()
  +.getAttribute(Globals.RESOURCES_ATTR);
  +} catch (ClassCastException e) {
  +// Failed : Not the right type
  +}
  +
  +return null;
  +
  +}
  +
  +
  +/**
* Show HTTP header information.
*/
   protected void showRequestInfo(HttpServletRequest req) {
  @@ -494,13 +537,29 @@
   resp.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED);
   }
   
  -// Retrieve the Catalina context
  -ApplicationContext context = (ApplicationContext) getServletContext();
  -Resources resources = context.getResources();
  +

cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina Container.java Globals.java Resources.java


remm01/01/11 22:52:38

  Modified:catalina/src/share/org/apache/catalina Container.java
Globals.java
  Removed: catalina/src/share/org/apache/catalina Resources.java
  Log:
  - Update to DirContext.
  - Removed now useless Resources interface.
  
  Revision  ChangesPath
  1.3   +11 -10
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/Container.java
  
  Index: Container.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/Container.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Container.java2000/09/30 19:15:42 1.2
  +++ Container.java2001/01/12 06:52:37 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/Container.java,v 
1.2 2000/09/30 19:15:42 craigmcc Exp $
  - * $Revision: 1.2 $
  - * $Date: 2000/09/30 19:15:42 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/Container.java,v 
1.3 2001/01/12 06:52:37 remm Exp $
  + * $Revision: 1.3 $
  + * $Date: 2001/01/12 06:52:37 $
*
* 
*
  @@ -68,6 +68,7 @@
   import java.beans.PropertyChangeListener;
   import java.io.IOException;
   import javax.servlet.ServletException;
  +import javax.naming.directory.DirContext;
   
   
   /**
  @@ -112,14 +113,14 @@
* this Container.
* Realm - Read-only interface to a security domain, for
* authenticating user identities and their corresponding roles.
  - * Resources - Implementation of the resource access method
  - * signatures of the ServletContext interface, enabling
  - * custom linkages to existing server components when Catalina is embedded
  - * in a larger server.
  + * Resources - JNDI directory context enabling access to static
  + * resources, enabling custom linkages to existing server components when 
  + * Catalina is embedded in a larger server.
* 
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.2 $ $Date: 2000/09/30 19:15:42 $
  + * @author Remy Maucherat
  + * @version $Revision: 1.3 $ $Date: 2001/01/12 06:52:37 $
*/
   
   public interface Container {
  @@ -310,7 +311,7 @@
* is no associated Resources object, return the Resources associated with
* our parent Container (if any); otherwise return null.
*/
  -public Resources getResources();
  +public DirContext getResources();
   
   
   /**
  @@ -318,7 +319,7 @@
*
* @param resources The newly associated Resources
*/
  -public void setResources(Resources resources);
  +public void setResources(DirContext resources);
   
   
   // - Public Methods
  
  
  
  1.19  +12 -4 
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/Globals.java
  
  Index: Globals.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/Globals.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- Globals.java  2001/01/09 04:27:05 1.18
  +++ Globals.java  2001/01/12 06:52:37 1.19
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/Globals.java,v 
1.18 2001/01/09 04:27:05 craigmcc Exp $
  - * $Revision: 1.18 $
  - * $Date: 2001/01/09 04:27:05 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/Globals.java,v 
1.19 2001/01/12 06:52:37 remm Exp $
  + * $Revision: 1.19 $
  + * $Date: 2001/01/12 06:52:37 $
*
* 
*
  @@ -69,7 +69,7 @@
* Global constants that are applicable to multiple packages within Catalina.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.18 $ $Date: 2001/01/09 04:27:05 $
  + * @version $Revision: 1.19 $ $Date: 2001/01/12 06:52:37 $
*/
   
   public final class Globals {
  @@ -99,6 +99,14 @@
*/
   public static final String CLASS_LOADER_ATTR =
"org.apache.catalina.classloader";
  +
  +
  +/**
  + * The JNDI directory context which is associated with the context. This
  + * context can be used to manipulate static files.
  + */
  +public static final String RESOURCES_ATTR =
  + "org.apache.catalina.resources";
   
   
   /**
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

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


remm01/01/11 22:51:58

  Modified:catalina/src/share/org/apache/catalina/connector/http
SocketInputStream.java
  Log:
  - Merge with some code inspired from code from BufferedInputStream.
  - Removed some unnecessary synchronization (to be confirmed). If the
sync was necessary, I suggest doing it in the RequestInputStream.read()
instead.
  
  Revision  ChangesPath
  1.6   +107 -10   
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/connector/http/SocketInputStream.java
  
  Index: SocketInputStream.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/connector/http/SocketInputStream.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- SocketInputStream.java2001/01/04 19:49:20 1.5
  +++ SocketInputStream.java2001/01/12 06:51:58 1.6
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/connector/http/SocketInputStream.java,v
 1.5 2001/01/04 19:49:20 remm Exp $
  - * $Revision: 1.5 $
  - * $Date: 2001/01/04 19:49:20 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/connector/http/SocketInputStream.java,v
 1.6 2001/01/12 06:51:58 remm Exp $
  + * $Revision: 1.6 $
  + * $Date: 2001/01/12 06:51:58 $
*
* 
* 
  @@ -65,18 +65,17 @@
   package org.apache.catalina.connector.http;
   
   import java.io.IOException;
  -import java.io.BufferedInputStream;
   import java.io.InputStream;
   import java.io.EOFException;
   import org.apache.catalina.util.StringManager;
   
   /**
  - * Extends BufferedInputStream to be more efficient reading lines during HTTP
  + * Extends InputStream to be more efficient reading lines during HTTP
* header processing.
*
* @author mailto:[EMAIL PROTECTED]">Remy Maucherat
*/
  -public class SocketInputStream extends BufferedInputStream {
  +public class SocketInputStream extends InputStream {
   
   
   // -- Constants
  @@ -112,6 +111,30 @@
   private static final int LC_OFFSET = 'A' - 'a';
   
   
  +/**
  + * Internal buffer.
  + */
  +protected byte buf[];
  +
  +
  +/**
  + * Last valid byte.
  + */
  +protected int count;
  +
  +
  +/**
  + * Position in the buffer.
  + */
  +protected int pos;
  +
  +
  +/**
  + * Underlying input stream.
  + */
  +protected InputStream is;
  +
  +
   // --- Constructors
   
   
  @@ -124,7 +147,8 @@
*/
   public SocketInputStream(InputStream is, int bufferSize) {
   
  - super(is, bufferSize);
  + this.is = is;
  +buf = new byte[bufferSize];
   
   }
   
  @@ -174,9 +198,7 @@
   if (chr == -1)
   throw new EOFException
   (sm.getString("requestStream.readline.error"));
  -if ((chr != CR) || (chr != LF)) {
  -pos--;
  -}
  +pos--;
   
   // Reading the method name
   
  @@ -484,6 +506,81 @@
   
   header.valueEnd = readCount;
   
  +}
  +
  +
  +/**
  + * Read byte.
  + */
  +public int read()
  +throws IOException {
  +if (pos >= count) {
  +fill();
  + if (pos >= count)
  + return -1;
  +}
  + return buf[pos++] & 0xff;
  +}
  +
  +
  +/**
  + * 
  + */
  +/*
  +public int read(byte b[], int off, int len)
  +throws IOException {
  +
  +}
  +*/
  +
  +
  +/**
  + * 
  + */
  +/*
  +public long skip(long n)
  +throws IOException {
  +
  +}
  +*/
  +
  +
  +/**
  + * Returns the number of bytes that can be read from this input 
  + * stream without blocking.
  + */
  +public int available()
  +throws IOException {
  +return (count - pos) + is.available();
  +}
  +
  +
  +/**
  + * Close the input stream.
  + */
  +public void close()
  +throws IOException {
  +if (is == null)
  +return;
  +is.close();
  +is = null;
  +buf = null;
  +}
  +
  +
  +// -- Protected Methods
  +
  +
  +/**
  + * Fill the internal buffer using data from the undelying input stream.
  + */
  +protected void fill()
  +throws IOException {
  +pos = 0;
  +count = 0;
  +int nRead = is.read(buf, 0, buf.length);
  +if (nRead > 0)
  +count = nRead;
   }
   
   
  
  
  

-
To unsubscribe, e-mail: [EM

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


remm01/01/11 22:50:06

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java ContainerBase.java
StandardContext.java
  Log:
  - Updated the ServletContext facade to use the DirContext.
  - Will produce URLs using the new DirContextURLHandler.
  - ServletContext.getResourcePaths() is commeted out for now.
  - The standard context will put the associated DirContext in two places :
- in the naming environment, it is bound to java:/comp/Resources
- in the ServletContext, it is bound as org.apache.catalina.resources
  
  Revision  ChangesPath
  1.10  +35 -22
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
  
  Index: ApplicationContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- ApplicationContext.java   2001/01/03 00:17:06 1.9
  +++ ApplicationContext.java   2001/01/12 06:50:06 1.10
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
 1.9 2001/01/03 00:17:06 craigmcc Exp $
  - * $Revision: 1.9 $
  - * $Date: 2001/01/03 00:17:06 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
 1.10 2001/01/12 06:50:06 remm Exp $
  + * $Revision: 1.10 $
  + * $Date: 2001/01/12 06:50:06 $
*
* 
*
  @@ -74,18 +74,21 @@
   import java.util.HashMap;
   import java.util.HashSet;
   import java.util.Set;
  +import javax.naming.directory.DirContext;
   import javax.servlet.RequestDispatcher;
   import javax.servlet.Servlet;
   import javax.servlet.ServletContext;
   import javax.servlet.ServletContextAttributeEvent;
   import javax.servlet.ServletContextAttributesListener;
   import javax.servlet.http.HttpServletRequest;
  +import org.apache.naming.resources.Resource;
  +import org.apache.naming.resources.DirContextURLStreamHandler;
  +import org.apache.naming.resources.DirContextURLConnection;
   import org.apache.catalina.Container;
   import org.apache.catalina.Context;
   import org.apache.catalina.Globals;
   import org.apache.catalina.Host;
   import org.apache.catalina.Logger;
  -import org.apache.catalina.Resources;
   import org.apache.catalina.Wrapper;
   import org.apache.catalina.connector.HttpRequestBase;
   import org.apache.catalina.deploy.ApplicationParameter;
  @@ -100,7 +103,8 @@
* associated with each instance of StandardContext.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.9 $ $Date: 2001/01/03 00:17:06 $
  + * @author Remy Maucherat
  + * @version $Revision: 1.10 $ $Date: 2001/01/12 06:50:06 $
*/
   
   public final class ApplicationContext
  @@ -167,7 +171,7 @@
* The path must begin with a "/" and is interpreted as relative to the
* current context root.
*/
  -public Resources getResources() {
  +public DirContext getResources() {
   
return context.getResources();
   
  @@ -303,11 +307,15 @@
*/
   public String getMimeType(String file) {
   
  - Resources resources = context.getResources();
  - if (resources == null)
  + if (file == null)
return (null);
  - else
  - return (resources.getMimeType(file));
  + int period = file.lastIndexOf(".");
  + if (period < 0)
  + return (null);
  + String extension = file.substring(period + 1);
  + if (extension.length() < 1)
  + return (null);
  + return (context.findMimeMapping(extension));
   
   }
   
  @@ -343,11 +351,7 @@
*/
   public String getRealPath(String path) {
   
  - Resources resources = context.getResources();
  - if (resources == null)
  - return (null);
  - else
  - return (resources.getRealPath(path));
  +return (null);
   
   }
   
  @@ -415,11 +419,12 @@
*/
   public URL getResource(String path) throws MalformedURLException {
   
  - Resources resources = context.getResources();
  + DirContext resources = context.getResources();
if (resources == null)
return (null);
else
  - return (resources.getResource(path));
  + return new URL("jndi", null, 0, path, 
  +   new DirContextURLStreamHandler(resources));
   
   }
   
  @@ -434,11 +439,16 @@
*/
   public InputStream getResourceAsStream(String path) {
   
  - Resources resources = context.getResources();
  - if (resources == null)
  - return (null);
  - else
  - return (resources.getResourceAsStream(path));
  +DirContext resources = context.getResources();
  +

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


remm01/01/11 22:46:54

  Modified:catalina/src/share/org/apache/catalina/loader
StandardLoader.java
  Log:
  - Refactoring with loading repositories from DirContext.
  - Unfortunately, the Loader / ClassLoader was heavily biased towards
loading its class repositories from the filesystem. This causes Catalina to
crash on startup at the moment. Additional refactoring of the classloader is
needed to address this (and will be done ASAP).
  
  Revision  ChangesPath
  1.14  +11 -11
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/loader/StandardLoader.java
  
  Index: StandardLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- StandardLoader.java   2000/12/22 00:37:50 1.13
  +++ StandardLoader.java   2001/01/12 06:46:54 1.14
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
 1.13 2000/12/22 00:37:50 craigmcc Exp $
  - * $Revision: 1.13 $
  - * $Date: 2000/12/22 00:37:50 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
 1.14 2001/01/12 06:46:54 remm Exp $
  + * $Revision: 1.14 $
  + * $Date: 2001/01/12 06:46:54 $
*
* 
*
  @@ -83,7 +83,6 @@
   import org.apache.catalina.LifecycleListener;
   import org.apache.catalina.Loader;
   import org.apache.catalina.Logger;
  -import org.apache.catalina.Resources;
   import org.apache.catalina.util.LifecycleSupport;
   import org.apache.catalina.util.StringManager;
   
  @@ -101,7 +100,7 @@
* is not present, the system class loader will be used instead.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.13 $ $Date: 2000/12/22 00:37:50 $
  + * @version $Revision: 1.14 $ $Date: 2001/01/12 06:46:54 $
*/
   
   public final class StandardLoader
  @@ -823,12 +822,13 @@
   
   if (!(container instanceof Context))
   return;
  - Resources resources = ((Context) container).getResources();
  + ServletContext servletContext = 
  +((Context) container).getServletContext();
   
// Add the WEB-INF/classes subdirectory
URL classesURL = null;
try {
  - classesURL = resources.getResource("/WEB-INF/classes");
  +classesURL = servletContext.getResource("/WEB-INF/classes");
   } catch (MalformedURLException e) {
classesURL = null;
}
  @@ -860,12 +860,12 @@
// Add the WEB-INF/lib/*.jar files
URL libURL = null;
try {
  - libURL = resources.getResource("/WEB-INF/lib");
  + libURL = servletContext.getResource("/WEB-INF/lib");
} catch (MalformedURLException e) {
libURL = null;
}
   // FIXME - This still requires disk directory!  Scan JARs if present
  - if ((libURL != null) && "file".equals(libURL.getProtocol())) {
  +if ((libURL != null) && "file".equals(libURL.getProtocol())) {
File libFile = new File(libURL.getFile());
if (libFile.exists() && libFile.canRead() &&
libFile.isDirectory()) {
  @@ -884,8 +884,8 @@
   }
}
}
  - }
  -
  +}
  +
   }
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

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


remm01/01/11 22:43:51

  Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
ContextConfig.java
  Log:
  - Refactoring using DirContext to replace Resources.
  
  Revision  ChangesPath
  1.12  +10 -10
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/startup/Catalina.java
  
  Index: Catalina.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/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 2001/01/04 20:05:39 1.11
  +++ Catalina.java 2001/01/12 06:43:50 1.12
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
 1.11 2001/01/04 20:05:39 craigmcc Exp $
  - * $Revision: 1.11 $
  - * $Date: 2001/01/04 20:05:39 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
 1.12 2001/01/12 06:43:50 remm Exp $
  + * $Revision: 1.12 $
  + * $Date: 2001/01/12 06:43:50 $
*
* 
*
  @@ -96,7 +96,7 @@
* 
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.11 $ $Date: 2001/01/04 20:05:39 $
  + * @version $Revision: 1.12 $ $Date: 2001/01/12 06:43:50 $
*/
   
   public class Catalina {
  @@ -367,12 +367,12 @@
   
mapper.addRule("Server/Service/Engine/Host/Resources",
  mapper.objectCreate
  -("org.apache.catalina.core.StandardResources",
  +("org.apache.naming.resources.FileDirContext",
"className"));
mapper.addRule("Server/Service/Engine/Host/Resources",
  mapper.setProperties());
mapper.addRule("Server/Service/Engine/Host/Resources", mapper.addChild
  -("setResources", "org.apache.catalina.Resources"));
  +("setResources", "javax.naming.directory.DirContext"));
   
mapper.addRule("Server/Service/Engine/Host/Valve", mapper.objectCreate
   (null, "className"));
  @@ -402,12 +402,12 @@
   ("setRealm", "org.apache.catalina.Realm"));
   
mapper.addRule("Server/Service/Engine/Resources", mapper.objectCreate
  -("org.apache.catalina.core.StandardResources",
  +("org.apache.naming.resources.FileDirContext",
"className"));
mapper.addRule("Server/Service/Engine/Resources",
  mapper.setProperties());
mapper.addRule("Server/Service/Engine/Resources", mapper.addChild
  -("setResources", "org.apache.catalina.Resources"));
  +("setResources", "javax.naming.directory.DirContext"));
   
mapper.addRule("Server/Service/Engine/Valve", mapper.objectCreate
   (null, "className"));
  @@ -540,12 +540,12 @@
   
mapper.addRule(prefix + "/Resources",
   mapper.objectCreate
  -("org.apache.catalina.core.StandardResources",
  +("org.apache.naming.resources.FileDirContext",
"className"));
mapper.addRule(prefix + "/Resources",
   mapper.setProperties());
mapper.addRule(prefix + "/Resources", mapper.addChild
  -("setResources", "org.apache.catalina.Resources"));
  +("setResources", "javax.naming.directory.DirContext"));
   
mapper.addRule(prefix + "/Valve", mapper.objectCreate
   (null, "className"));
  
  
  
  1.36  +14 -14
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
  
  Index: ContextConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- ContextConfig.java2000/12/22 00:37:52 1.35
  +++ ContextConfig.java2001/01/12 06:43:50 1.36
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
 1.35 2000/12/22 00:37:52 craigmcc Exp $
  - * $Revision: 1.35 $
  - * $Date: 2000/12/22 00:37:52 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
 1.36 2001/01/12 06:43:50 remm Exp $
  + * $Revision: 1.36 $
  + * $Date: 2001/01/12 06:43:50 $
*
* 
*
  @@ -89,6 +89,7 @@
   import java.util.Stack;
   import java.util.jar.JarEntry;
   import java.util.jar.JarFile;
  +import javax.se

cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/resources Constants.java DirectoryBean.java FileResources.java JarResources.java LocalStrings.properties LocalStrings_es.properties ResourceBean.java ResourcesBase.java package.html


remm01/01/11 22:43:17

  Removed: catalina/src/share/org/apache/catalina/resources
Constants.java DirectoryBean.java
FileResources.java JarResources.java
LocalStrings.properties LocalStrings_es.properties
ResourceBean.java ResourcesBase.java package.html
  Log:
  - Remove resources package. Replaced by DirContext implementations.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

BugRat Report #749 has been filed.


Bug report #749 has just been filed.

You can view the report at the following URL:

   

REPORT #749 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: 3.2.1
   JVM Release: 1.3
   Operating System: RedHat 6.2
   OS Release: RedHat 6.2
   Platform: RedHat 6.2

Synopsis: 
I had same problem  like Bug Report #61

Description:
Dear:
I had same problem  like Bug Report #61. I am using Red Hat 6.2, apache 1.3.14, 
tomcat 3.2.1,
I had follow all the instruction of the Guildline "Working with mod_jk" in the doc 
directory.
I can't pass the jsp file located at the apache directory to tomcat process. Can 
you tell me all suggestion.=20
Yours


Title: 
BugRat Report #
749





BugRat Report #
749




Project:
Tomcat


Release:
3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
_Anonymous ( [EMAIL PROTECTED] )

Date Submitted:
Jan 11 2001, 10:57:42 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

I had same problem  like Bug Report #61


 Environment: (jvm, os, osrel, platform)

1.3, RedHat 6.2, RedHat 6.2, RedHat 6.2



Additional Environment Description:





Report Description:

Dear:
I had same problem  like Bug Report #61. I am using Red Hat 6.2, apache 1.3.14, tomcat 3.2.1,
I had follow all the instruction of the Guildline "Working with mod_jk" in the doc directory.
I can't pass the jsp file located at the apache directory to tomcat process. Can you tell me all suggestion.=20
Yours




View this report online...






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: acive session count?

2001-01-11 Thread cmanolache


> > 1. Extensible/Modular. Maybe you want to get other internal 
> > informations,
> > or change other parameters at run time.
> > 
> > 2. Minimal ( or no ) changes in the core or protocols. Changes are bad
> > bacause they add bugs, require releases , etc, and if we do (1) right,
> > then no other change is needed.
> > 
> 
> I agree. The less work done to the core, the better. ( and best left to the
> pros! :)

Don't get me wrong - I have nothing against changing the core per se, I
just think we have the hooks we need ( and if we don't we should add them
ASAP ), and it would be great to keep it frozen so that we can
start developing the needed modules and features.


> > Well, having Ajp13 or Http listeners is almost the same, you 
> > don't need
> > the HTTP running if you have Ajp13 ( and a Ajp13 client - 
> > like apache ).
> > Regarding login for each query - this is an admin task, so it's not
> > performance-critical.
> 
> 
> So, in addition to setting up AJP12 in the load balance list, you're saying
> to set up a AJP13 on each tomcat as well? (to allow [restricted] access to
> the specific TC) ? Sounds good.

Sorry, I meant Ajp12 ( i.e. if you have ajp12 or ajp13 or jni connector,
you don't need standalone http - just connect to apache and you can do any
http request - including /admin, and any other servlet ).

( in addition, you can use all Apache directives to double the security if
you want to - in addition to password ).


Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/request JspInterceptor.java


larryi  01/01/11 20:47:00

  Modified:src/share/org/apache/jasper Tag: tomcat_32
EmbededServletOptions.java JspC.java Options.java
   src/share/org/apache/jasper/compiler Tag: tomcat_32
Compiler.java JavaCompiler.java
JikesJavaCompiler.java SunJavaCompiler.java
   src/share/org/apache/jasper/resources Tag: tomcat_32
messages.properties messages_es.properties
messages_fr.properties
   src/share/org/apache/tomcat/request Tag: tomcat_32
JspInterceptor.java
  Log:
  Add classDebugInfo property to Options.java and related classes.
  Update handling so that Jasper can compile classes with debugging
  information if requested.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.4.2.2   +24 -3 
jakarta-tomcat/src/share/org/apache/jasper/EmbededServletOptions.java
  
  Index: EmbededServletOptions.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/EmbededServletOptions.java,v
  retrieving revision 1.4.2.1
  retrieving revision 1.4.2.2
  diff -u -r1.4.2.1 -r1.4.2.2
  --- EmbededServletOptions.java2000/12/22 14:19:10 1.4.2.1
  +++ EmbededServletOptions.java2001/01/12 04:46:58 1.4.2.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/EmbededServletOptions.java,v 
1.4.2.1 2000/12/22 14:19:10 pierred Exp $
  - * $Revision: 1.4.2.1 $
  - * $Date: 2000/12/22 14:19:10 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/EmbededServletOptions.java,v 
1.4.2.2 2001/01/12 04:46:58 larryi Exp $
  + * $Revision: 1.4.2.2 $
  + * $Date: 2001/01/12 04:46:58 $
*
* 
* 
  @@ -103,6 +103,11 @@
   public boolean sendErrorToClient = false;
   
   /**
  + * Do we want to include debugging information in the class file?
  + */
  +public boolean classDebugInfo = false;
  +
  +/**
* I want to see my generated servlets. Which directory are they
* in?
*/
  @@ -170,6 +175,13 @@
   }

   /**
  + * Should class files be compiled with debug information?
  + */
  +public boolean getClassDebugInfo() {
  +return classDebugInfo;
  +}
  +
  +/**
* Class ID for use in the plugin tag when the browser is IE. 
*/
   public String getIeClassId() {
  @@ -256,6 +268,15 @@
   else if (senderr.equalsIgnoreCase("false"))
   this.sendErrorToClient = false;
   else Constants.message ("jsp.warning.sendErrToClient", Logger.WARNING);
  +}
  +
  +String debugInfo = config.getInitParameter("classdebuginfo");
  +if (debugInfo != null) {
  +if (debugInfo.equalsIgnoreCase("true"))
  +this.classDebugInfo  = true;
  +else if (debugInfo.equalsIgnoreCase("false"))
  +this.classDebugInfo  = false;
  +else Constants.message ("jsp.warning.classDebugInfo", Logger.WARNING);
   }
   
   String ieClassId = config.getInitParameter("ieClassId");
  
  
  
  1.15.2.3  +8 -3  jakarta-tomcat/src/share/org/apache/jasper/JspC.java
  
  Index: JspC.java
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/JspC.java,v
  retrieving revision 1.15.2.2
  retrieving revision 1.15.2.3
  diff -u -r1.15.2.2 -r1.15.2.3
  --- JspC.java 2000/12/22 14:19:10 1.15.2.2
  +++ JspC.java 2001/01/12 04:46:58 1.15.2.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/JspC.java,v 
1.15.2.2 2000/12/22 14:19:10 pierred Exp $
  - * $Revision: 1.15.2.2 $
  - * $Date: 2000/12/22 14:19:10 $
  + * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/JspC.java,v 
1.15.2.3 2001/01/12 04:46:58 larryi Exp $
  + * $Revision: 1.15.2.3 $
  + * $Date: 2001/01/12 04:46:58 $
*
* 
* 
  @@ -174,6 +174,11 @@
   return true;
   }

  +public boolean getClassDebugInfo() {
  +// compile with debug info
  +return false;
  +}
  +
   public String getIeClassId() {
   return ieClassId;
   }
  
  
  
  1.11.2.2  +8 -3  jakarta-tomcat/src/share/org/apache/jasper/Options.java
  
  Index: Options.java
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/Options.java,v
  retrieving revision 1.11.2.1
  retrieving revision 1.11.2.2
  diff -u -r1.11.2.1 -r1.11.2.2
  --- Options.java  2000/12/22 14:19:11 1.11.2.1
  +++ Options.java

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java Handler.java Response.java ResponseImpl.java ServletWrapper.java


larryi  01/01/11 20:39:06

  Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
ContextManager.java Handler.java Response.java
ResponseImpl.java ServletWrapper.java
  Log:
  Update handling so that when an included servlet throws an
  UnavailableException that isn't handled, it doesn't mark the callers
  as unavailable too.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.100.2.21 +6 -2  
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
  
  Index: ContextManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
  retrieving revision 1.100.2.20
  retrieving revision 1.100.2.21
  diff -u -r1.100.2.20 -r1.100.2.21
  --- ContextManager.java   2001/01/04 21:23:59 1.100.2.20
  +++ ContextManager.java   2001/01/12 04:39:03 1.100.2.21
  @@ -1082,8 +1082,12 @@
the client. AFAIK the trace is the _best_ debugger.
*/
if (t instanceof UnavailableException) {
  - int unavailableTime = ((UnavailableException)t).getUnavailableSeconds();
  - if( unavailableTime > 0 ) {
  + int unavailableTime = -1;
  + if ( !((UnavailableException)t).isPermanent() ) {
  + unavailableTime = ((UnavailableException)t).getUnavailableSeconds();
  + // if unavailable time not known, use 1 second
  + if ( unavailableTime <= 0 )
  + unavailableTime = 1;
res.setHeader("Retry-After", Integer.toString(unavailableTime));
}
String msg=t.getMessage();
  
  
  
  1.7.2.8   +4 -3  jakarta-tomcat/src/share/org/apache/tomcat/core/Handler.java
  
  Index: Handler.java
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Handler.java,v
  retrieving revision 1.7.2.7
  retrieving revision 1.7.2.8
  diff -u -r1.7.2.7 -r1.7.2.8
  --- Handler.java  2000/11/11 02:56:58 1.7.2.7
  +++ Handler.java  2001/01/12 04:39:03 1.7.2.8
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Handler.java,v 1.7.2.7 
2000/11/11 02:56:58 larryi Exp $
  - * $Revision: 1.7.2.7 $
  - * $Date: 2000/11/11 02:56:58 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Handler.java,v 1.7.2.8 
2001/01/12 04:39:03 larryi Exp $
  + * $Revision: 1.7.2.8 $
  + * $Date: 2001/01/12 04:39:03 $
*
* 
*
  @@ -260,6 +260,7 @@
}
context.log("Exception in init  " + ex.getMessage(), ex );
   if (res.isIncluded()) { // Only propogate on includes
  + res.setErrorException(ex);
// save error URI if necessary
contextM.saveErrorURI( req, res );
   if (ex instanceof IOException)
  
  
  
  1.22.2.3  +10 -0 jakarta-tomcat/src/share/org/apache/tomcat/core/Response.java
  
  Index: Response.java
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Response.java,v
  retrieving revision 1.22.2.2
  retrieving revision 1.22.2.3
  diff -u -r1.22.2.2 -r1.22.2.3
  --- Response.java 2000/11/11 02:56:58 1.22.2.2
  +++ Response.java 2001/01/12 04:39:03 1.22.2.3
  @@ -143,6 +143,16 @@
*/
   public void setIncluded(boolean b);
   
  +/** Set the error Exception that occurred during
  + request processing.
  + */
  +public void setErrorException(Exception ex) ;
  +
  +/** Get the Exception that occurred during request
  + processing.
  + */
  +public Exception getErrorException() ;
  +
   /** Saves the request that originates an error.
*/
   public void setErrorURI(String uri) ;
  
  
  
  1.33.2.5  +12 -3 
jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/ResponseImpl.java
  
  Index: ResponseImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/ResponseImpl.java,v
  retrieving revision 1.33.2.4
  retrieving revision 1.33.2.5
  diff -u -r1.33.2.4 -r1.33.2.5
  --- ResponseImpl.java 2000/11/11 02:56:58 1.33.2.4
  +++ ResponseImpl.java 2001/01/12 04:39:04 1.33.2.5
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/ResponseImpl.java,v 
1.33.2.4 2000/11/11 02:56:58 larryi Exp $
  - * $Revision: 1.33.2.4 $
  - * $Date: 2000/11/11 02:56:58 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/ResponseImpl.java,v 
1.33.2.5 2001/01/12 04:39:04 larryi Exp $
  + * $Revision: 1.33

Re: An alternative to JSP

2001-01-11 Thread Geoff Soutter

"Jon Stevens" <[EMAIL PROTECTED]> wrote:
> on 1/11/01 6:32 PM, "Geoff Soutter" <[EMAIL PROTECTED]> wrote:
>
> > Certainly I've never seen what I consider to be a clean way of letting
HTML
> > people do HTML and Java people do Java. Yes, I've seen some that are
better
> > than others (XMLC is probably the cleanest I've seen)
>
> XMLC has the disadvantage of being entirely push based. It requires
changes
> to your Java code in order to change your HTML. That is bad.

Yeah, but thats an impl detail. You could easily modify it to load the HTML
on the fly, so that the HTML could be modified separately. The main thing I
like here is that you actually start with a "proper" HTML file, without a
proliferation of proprietary "Cold Fusion" style tags. That way HTML codes
can actually code real HTML, rather than some weird proprietary HTML
sublanguage. Allaires "content management" thingo Spectra defines 400 +
tags - how is your average HTML coder gonna deal with that? Course, it has
other problems but hey, that was my original thesis ... unfortunately the
real world is a complex place :-).

> >, but there are always
> > problems if you consider anything other than completely simplistic
examples.
> > Witness Jon's Pull Model document... :-)
> >
> > Geoff

Weren't you implying that under complex (read real world) scenarios, the
tradtional Webmacro "push" style way of doing things breaks down? Thats all
I was saying. Note your pull model Webmacro starts to sound like JSP to
me... interpreted HTML...

Geoff

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

BugRat Report #748 has been filed.


Bug report #748 has just been filed.

You can view the report at the following URL:

   

REPORT #748 Details.

Project: Jasper
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: low
Severity: non-critical
Confidence: public
Environment: 
   Release: 3.2.1
   JVM Release: 1.2.2
   Operating System: Redhat
   OS Release: 6.2
   Platform: linux

Synopsis: 
java.io.IOException shouldn't be imported

Description:
Jasper (3.2.1 and from CVS, 12/1/2001) imports java.io.IOException by default. This 
seems to go against the spec, p45, where it talks about "import" page directives:
The default import list is java.lang.*, javax.servlet.*,
 javax.servlet.jsp.* and javax.servlet.http.*.

JRun3.0 follows the spec, and therefore some JSP pages are not portable from Tomcat3.2 
to JRun3.0.

FYI, the relevant code is src/share/org/apache/jasper/Constants.java:

 /**
 * These classes/packages are automatically imported by the
 * generated code.
 *
 * FIXME: Need to trim this to what is there in PR2 and verify
 *with all our generators -akv.
 */
public static final String[] STANDARD_IMPORTS = {
"javax.servlet.*", "javax.servlet.http.*", "javax.servlet.jsp.*",
"javax.servlet.jsp.tagext.*",
"java.io.PrintWriter", "java.io.IOException", "java.io.FileInputStream",
"java.io.ObjectInputStream", "java.util.Vector",
"org.apache.jasper.runtime.*", "java.beans.*",
"org.apache.jasper.JasperException"
};


Thanks  :)

--Jeff

Title: 
BugRat Report #
748





BugRat Report #
748




Project:
Jasper


Release:
3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
low


Severity:
non-critical




Confidence:
public





Submitter:
Jeff Turner ( [EMAIL PROTECTED] )

Date Submitted:
Jan 11 2001, 10:27:41 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

java.io.IOException shouldn't be imported


 Environment: (jvm, os, osrel, platform)

1.2.2, Redhat, 6.2, linux



Additional Environment Description:





Report Description:

Jasper (3.2.1 and from CVS, 12/1/2001) imports java.io.IOException by default. This seems to go against the spec, p45, where it talks about "import" page directives:
The default import list is java.lang.*, javax.servlet.*,
 javax.servlet.jsp.* and javax.servlet.http.*.

JRun3.0 follows the spec, and therefore some JSP pages are not portable from Tomcat3.2 to JRun3.0.

FYI, the relevant code is src/share/org/apache/jasper/Constants.java:

 /**
 * These classes/packages are automatically imported by the
 * generated code.
 *
 * FIXME: Need to trim this to what is there in PR2 and verify
 *with all our generators -akv.
 */
public static final String[] STANDARD_IMPORTS = {
"javax.servlet.*", "javax.servlet.http.*", "javax.servlet.jsp.*",
"javax.servlet.jsp.tagext.*",
"java.io.PrintWriter", "java.io.IOException", "java.io.FileInputStream",
"java.io.ObjectInputStream", "java.util.Vector",
"org.apache.jasper.runtime.*", "java.beans.*",
"org.apache.jasper.JasperException"
};


Thanks  :)

--Jeff



How To Reproduce:

null



View this report online...






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service/http HttpRequestAdapter.java


larryi  01/01/11 20:27:04

  Modified:src/share/org/apache/tomcat/service/http Tag: tomcat_32
HttpRequestAdapter.java
  Log:
  Clear the protocal for bad request with only one "word", otherwise we will
  attempt to read headers.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.16.2.5  +1 -0  
jakarta-tomcat/src/share/org/apache/tomcat/service/http/Attic/HttpRequestAdapter.java
  
  Index: HttpRequestAdapter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/http/Attic/HttpRequestAdapter.java,v
  retrieving revision 1.16.2.4
  retrieving revision 1.16.2.5
  diff -u -r1.16.2.4 -r1.16.2.5
  --- HttpRequestAdapter.java   2000/12/20 16:17:41 1.16.2.4
  +++ HttpRequestAdapter.java   2001/01/12 04:27:04 1.16.2.5
  @@ -368,6 +368,7 @@
// we don't have 2 "words", probably only method
// startReq>0 => method is fine, request has at least one char
response.setStatus(HttpServletResponse.SC_BAD_REQUEST);
  + protocol=null;
return;
}

  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Any solution for bug#696?

2001-01-11 Thread Jin-Ling Kwang



Dear TomCat Bugs Team,

I also encountered the same problem as described in bug#696.
(Actually it also happened to '.doc' and '.ppt' and '.ps' file types
too.)

Could you please advise if you have any soluation for that problem
so far?

Please advise.

Thanks,

Best Regards,
Jin-Ling

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]

2001-01-11 Thread Marc Saegesser


Regarding BugReport #744.  I've been trying to duplicate it on my Win2000
system and haven't had any luck.  I always get back the executed page.  Has
anyone else been able to duplicate the problem behavior?

As for 3.2.2, I think we should give 3.2.1 a little more soak time.  The
flow of bug reports seems to have increased which means that people are
using the release.  I don't think there are any really critical bugs fixed
so far so another week or so should hurt and with the extra usage we might
find something that should be addressed.

With any luck, 3.2.2 puts this release to bed and there won't be a need for
a 3.2.3.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hans
> Bergsten
> Sent: Thursday, January 11, 2001 3:03 PM
> To: [EMAIL PROTECTED]
> Subject: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]
>
>
> "Craig R. McClanahan" wrote:
> >
> > Glenn Nielsen wrote:
> >
> > > I stand corrected.
> > >
> > > The below problem was a bug in Tomcat.  Wrapping the RequestDispatcher
> > > forward() and include() methods with a doPrivileged() if a
> SecurityManager
> > > is being used fixed the problem.  When Tomcat 3.2.2 is
> released you will
> > > no longer need to edit the jre/lib/security/java.security
> file to comment
> > > out the package.access=sun. line.
> > >
> > > This fix is in the 3.2 CVS branch, and will be in the Tomcat
> 3.2.2 release.
> > >
> >
> > Glenn (and others),
> >
> > Have we accumulated enough bug fixes where it's worth creating
> a 3.2.2 release,
> > or are there more issues that should be
> > dealt with first?
>
> I've seen the problem most recently reported in BugReport #744 described
> a
> few times now, but I haven't had a chance to verify it and look for a
> solution.
> Since this is a security bug, it seems like something that should be
> included
> in 3.2.2.
>
> I'll try to take a closer look at it this weekend, but can't promise
> anything.
>
> Hans
> --
> Hans Bergsten [EMAIL PROTECTED]
> Gefion Software   http://www.gefionsoftware.com
> Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP


on 1/11/01 6:32 PM, "Geoff Soutter" <[EMAIL PROTECTED]> wrote:

> I think the real problem with the whole JSP/WebMacro/XMLC/ASP/CF scenario is
> that HTML itself mixes presentation with logic to the point where any
> solution which needs to generate HTML is naturally going to be hacky.

I don't agree in the Velocity/WM case because there really isn't any "logic"
that you can embed into your HTML in this case.

> Certainly I've never seen what I consider to be a clean way of letting HTML
> people do HTML and Java people do Java. Yes, I've seen some that are better
> than others (XMLC is probably the cleanest I've seen)

XMLC has the disadvantage of being entirely push based. It requires changes
to your Java code in order to change your HTML. That is bad.

>, but there are always
> problems if you consider anything other than completely simplistic examples.
> Witness Jon's Pull Model document... :-)
> 
> Geoff

I'm confused by that statement. Please explain.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

BugRat Report #747 was closed (apparently by: Marc Saegesser)


Report #747 was closed by Person #0

   Synopsis: Jakarta NT service unable to log in to SQLserver machine unless service 
starts as a user

 (logged in as: Marc Saegesser)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP

2001-01-11 Thread Geoff Soutter

"Paul Speed" <[EMAIL PROTECTED]> wrote:
>
> Geoff Soutter wrote:
> >
> > "Paul Speed" <[EMAIL PROTECTED]> wrote:
> >
> > [snip]
> >
> > > For what it's worth, I think that custom tags are the thing
> > > that really saves JSP.  On my last project, we were able to
> > > encapsulate all logic into a servlet framework and custom tags.
> > > (Actually, our framework ended up looking very similar to struts
> > > which I think is a very natural evolution of the smart-servlet
> > > design.)
> >
> > Depends what you are trying to do. If you want non-java developers to
edit
> > the source, then custom tags _do_ save the day. Alternatively, Java in
HTML
> > ruins things nicely.
> >
> > IMHO, JSP is just an ASP/CF "me-too"... Not that it means it's not
_useful_,
> > it's just not _elegant_. Look at all the spagetti-code ASP and CF sites
> > there are out there. Course now it has the J2EE stamp of approval, how
good
> > it actually is becomes irrelevant. Sigh.
> >
>
> Yeah, but the nice thing is that it's easy to spot Java code
> in HTML during a code-review... it just looks ugly.  It would be nice
> if there was a switch on the JSP compiler that specifically
> disallowed it.
>
> Once you've clamped down on the use of Java code inside the
> JSP's then the developer is forced to use the custom tags.  If the
> custom tags only provide presentation control then you can be fairly
> sure that no business/application logic is creeping its way into the
> JSP code.

It reminds me of C or C++ compared to Java - any language where you require
too much self control in order to use it effectively is nasty.

> I've always found it funny that the custom tag examples put
> out by Sun inevitably show how to implement some SQL/JDBC custom
> tags.  It's nice as a comparison to Cold Fusion or PHP, but putting
> SQL code right into the HTML is the thing that makes most of us who
> have been doing this for a while cringe. :)

Yeah, it's funny huh. And of course thats exactly the kind of feature that
the majority of JSP coders probably use... sigh.

I think the real problem with the whole JSP/WebMacro/XMLC/ASP/CF scenario is
that HTML itself mixes presentation with logic to the point where any
solution which needs to generate HTML is naturally going to be hacky.
Certainly I've never seen what I consider to be a clean way of letting HTML
people do HTML and Java people do Java. Yes, I've seen some that are better
than others (XMLC is probably the cleanest I've seen), but there are always
problems if you consider anything other than completely simplistic examples.
Witness Jon's Pull Model document... :-)

Geoff

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP

2001-01-11 Thread Shawn McMurdo

Paul Speed wrote:
[...]

> As it turned out, for many of the custom tags we were able
> to write web-developer versions that didn't require the full back-end
> application server.  Our web developers were then able to run tomcat
> locally to help develop their pages and see what they looked like as
> they developed.  We were fortunate that most of our web designers
> steered away from WYSIWYG tools... even though they did use web edit
> tools like Homesite.  The more savvy web guys were even able to make
> the tool integration look pretty seamless.

One of the advantages of XMLC is that you don't have to write any special
prototype code.
The prototype HTML used for storyboarding is exactly the same HTML used in the
applicaiton
with no modifications.  The dummy data in the prototype is removed when the
real dynamic data
is inserted into the page.

With XMLC designers can use best of breed WYSIWYG design tools without
requiring special tool integration.

Shawn

--
Shawn McMurdo  mailto:[EMAIL PROTECTED]
Lutris Technologieshttp://www.lutris.com
Enhydra.Orghttp://www.enhydra.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

BugRat Report #747 has been filed.

Bug report #747 has just been filed.

You can view the report at the following URL:

REPORT #747 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: serious
Confidence: confidential
Environment:
Release: Tomcat 3.1
JVM Release: JDK 1.3.0, J2EE 1.2.1
Operating System: WinNT
OS Release: 4.0, SP6a
Platform: Dell PowerEdge 300

Synopsis:
Jakarta NT service unable to log in to SQLserver machine unless service starts as a
user

Description:
This is a problem that is probably specific to Windows implementations of Tomcat.

I apologize if it has already been reported or resolved. I'm kind of new at this.

I have a Java servlet that needs to talk to SQLServer 7 on another machine in our LAN.
The servlet uses a system DSN which defines the data source. It includes
specification of a SQLServer login (rather than an NT login), and that login is one
that has the necessary permission in SQLServer.

The problem is that Tomcat needs to run as a system service under NT. That is, it
needs to start automatically at boot and keep running regardless of who is logged in
to the box. When I use the Jakarta NT Service wrapper to install the service, and
then configure the service to be a *system* service, I lose the ability to talk to the
SQL server. If I configure the jakarta service to run as a user that has an NT login
for SQLServer, then everything works fine.

Windows makes this distinction between system services and desktop-interactive
services. The latter stop when the user logs off the box.

I haven't yet figured out how to get Tomcat to log when it is run as a system service,
so I don't have any log output. Our contractor writing the servlets has not yet
implemented logging of errors either :(.

So I hope someone will recognize this without any logs to help them, and tell me
either that it's fixed in a later release, or that it's being worked on, or that it
sounds like a servlet programming mistake, or else what I can do to provide more
information if it really is new and really is thought to be a bug.

Thanks!

Title:
BugRat Report #
747

BugRat Report #
747

Project:
Tomcat

Release:
Tomcat 3.1

Category:
Bug Report

SubCategory:
New Bug Report

Class:
swbug

State:
received

Priority:
medium

Severity:
serious

Confidence:
confidential

Submitter:
Rebeccah Prastein ( [EMAIL PROTECTED] )

Date Submitted:
Jan 11 2001, 08:22:08 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )

Synopsis:

Jakarta NT service unable to log in to SQLserver machine unless service starts as a user

Environment: (jvm, os, osrel, platform)

JDK 1.3.0, J2EE 1.2.1, WinNT, 4.0, SP6a, Dell PowerEdge 300

Additional Environment Description:

Tomcat to be used to serve a Java servlet that accepts 100K hits per day from the Internet, then writes to and reads from a SQLserver 7 machine on the local domain and returns a web page to the end user on the internet. The SQLserver machine is configured to accept both NT logins and SQLServer logins.

Report Description:

This is a problem that is probably specific to Windows implementations of Tomcat.

I apologize if it has already been reported or resolved. I'm kind of new at this.

I have a Java servlet that needs to talk to SQLServer 7 on another machine in our LAN. The servlet uses a system DSN which defines the data source. It includes specification of a SQLServer login (rather than an NT login), and that login is one that has the necessary permission in SQLServer.

The problem is that Tomcat needs to run as a system service under NT. That is, it needs to start automatically at boot and keep running regardless of who is logged in to the box. When I use the Jakarta NT Service wrapper to install the service, and then configure the service to be a *system* service, I lose the ability to talk to the SQL server. If I configure the jakarta service to run as a user that has an NT login for SQLServer, then everything works fine.

Windows makes this distinction between system services and desktop-interactive services. The latter stop when the user logs off the box.

I haven't yet figured out how to get Tomcat to log when it is run as a system service, so I don't have any log output. Our contractor writing the servlets has not yet implemented logging of errors either :(.

So I hope someone will recognize this without any logs to help them, and tell me either that it's fixed in a later release, or that it's being worked on, or that it sounds like a servlet programming mistake, or else what I can do to provide more information if it really is new and really is thought to be a bug.

Thanks!

How To Reproduce:

null

Workaround:

null

View this report online...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addi

Re: An alternative to JSP


on 1/11/01 4:53 PM, "Jon Stevens" <[EMAIL PROTECTED]> wrote:

> 

Now this is fun...

216.216.10.57 - - [11/Jan/2001:17:03:45 -0800] "GET /jsp.gif HTTP/1.1" 200
74620
216.216.10.57 - - [11/Jan/2001:17:06:54 -0800] "GET / HTTP/1.1" 200 5
216.216.10.57 - - [11/Jan/2001:17:07:01 -0800] "GET /WEB-INF HTTP/1.1" 404
287
216.216.10.57 - - [11/Jan/2001:17:07:08 -0800] "GET /index.html HTTP/1.1"
200 5
216.216.10.57 - - [11/Jan/2001:17:07:23 -0800] "GET /robots.txt HTTP/1.1"
404 29

Whatcha looking for: np.instantis.com ???

-jon (who is amazed at how many people have looked at that image)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP

2001-01-11 Thread Paul Speed

Geoff Soutter wrote:
> 
> "Paul Speed" <[EMAIL PROTECTED]> wrote:
> 
> [snip]
> 
> > For what it's worth, I think that custom tags are the thing
> > that really saves JSP.  On my last project, we were able to
> > encapsulate all logic into a servlet framework and custom tags.
> > (Actually, our framework ended up looking very similar to struts
> > which I think is a very natural evolution of the smart-servlet
> > design.)
> 
> Depends what you are trying to do. If you want non-java developers to edit
> the source, then custom tags _do_ save the day. Alternatively, Java in HTML
> ruins things nicely.
> 
> IMHO, JSP is just an ASP/CF "me-too"... Not that it means it's not _useful_,
> it's just not _elegant_. Look at all the spagetti-code ASP and CF sites
> there are out there. Course now it has the J2EE stamp of approval, how good
> it actually is becomes irrelevant. Sigh.
> 

Yeah, but the nice thing is that it's easy to spot Java code
in HTML during a code-review... it just looks ugly.  It would be nice 
if there was a switch on the JSP compiler that specifically 
disallowed it.

Once you've clamped down on the use of Java code inside the
JSP's then the developer is forced to use the custom tags.  If the
custom tags only provide presentation control then you can be fairly
sure that no business/application logic is creeping its way into the
JSP code.

I've always found it funny that the custom tag examples put
out by Sun inevitably show how to implement some SQL/JDBC custom 
tags.  It's nice as a comparison to Cold Fusion or PHP, but putting
SQL code right into the HTML is the thing that makes most of us who
have been doing this for a while cringe. :)

I can't think of a better generalized example though.
-Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP


on 1/11/01 4:25 PM, "Geoff Soutter" <[EMAIL PROTECTED]> wrote:

> IMHO, JSP is just an ASP/CF "me-too"... Not that it means it's not _useful_,
> it's just not _elegant_. Look at all the spagetti-code ASP and CF sites
> there are out there. Course now it has the J2EE stamp of approval, how good
> it actually is becomes irrelevant. Sigh.
> 
> Geoff.

This is one of my more memorable .gif images...



:-)

Nice to see NASA using our software.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: mod_jk.so


on 1/11/01 7:26 PM, "Aflatoon Aflatooni" <[EMAIL PROTECTED]> wrote:

> Hi,
> I didn't know where else to turn.
> I was wondering where and how I can get the source for mod_jk.so (the
> apache module)
> Thanks
> Aflatoon

>From CVS. Look on the website.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP

2001-01-11 Thread Geoff Soutter

"Paul Speed" <[EMAIL PROTECTED]> wrote:

[snip]

> For what it's worth, I think that custom tags are the thing
> that really saves JSP.  On my last project, we were able to
> encapsulate all logic into a servlet framework and custom tags.
> (Actually, our framework ended up looking very similar to struts
> which I think is a very natural evolution of the smart-servlet
> design.)

Depends what you are trying to do. If you want non-java developers to edit
the source, then custom tags _do_ save the day. Alternatively, Java in HTML
ruins things nicely.

IMHO, JSP is just an ASP/CF "me-too"... Not that it means it's not _useful_,
it's just not _elegant_. Look at all the spagetti-code ASP and CF sites
there are out there. Course now it has the J2EE stamp of approval, how good
it actually is becomes irrelevant. Sigh.

Geoff.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

mod_jk.so

2001-01-11 Thread Aflatoon Aflatooni


Hi,
I didn't know where else to turn.
I was wondering where and how I can get the source for mod_jk.so (the
apache module)
Thanks
Aflatoon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP

2001-01-11 Thread Craig R. McClanahan

Paul Speed wrote:

>
> I'll be curious to see where the JSP spec evolves next.  To
> me it seems logical to start incorporating more tags along the lines
> of the current bean tags.  Iteration and other control structures
> seems like the most common part of the wheel that tag libraries seem
> to be re-inventing.  Standard versions sure would be nice.
>

Funny you should mention that ... there is a current JCP specification request
(JSR-052) to do exactly that ... formulate a standard set of tags for commonly
required things.  (Yes, the Struts tags will be looked at as input to the
process, along with submissions from others who have already developed such
libraries).

For more info, see

http://java.sun.com/aboutJava/communityprocess/jsr/jsr_052_jsptaglib.html

Eduardo Pelegri-Llopart (who is also spec lead for JSP 1.2) is the specification
lead for this.

>
> -Paul
>

Craig McClanahan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: acive session count?

2001-01-11 Thread Michael Kuz

Title: RE: acive session count?





> Yes, both Apache and tomcat need a mechanism to get status and change
> configuration dynamically. 
> 
> Session count is a particular case. Adding/removing workers is another
> particular case. 
> 
> What I'm thinking about is a general solution. The goals:
> 
> 1. Extensible/Modular. Maybe you want to get other internal 
> informations,
> or change other parameters at run time.
> 
> 2. Minimal ( or no ) changes in the core or protocols. Changes are bad
> bacause they add bugs, require releases , etc, and if we do (1) right,
> then no other change is needed.
> 


I agree. The less work done to the core, the better. ( and best left to the pros! :)


> 
> Well, having Ajp13 or Http listeners is almost the same, you 
> don't need
> the HTTP running if you have Ajp13 ( and a Ajp13 client - 
> like apache ).
> Regarding login for each query - this is an admin task, so it's not
> performance-critical.



So, in addition to setting up AJP12 in the load balance list, you're saying to set up a AJP13 on each tomcat as well? (to allow [restricted] access to the specific TC) ? Sounds good.

> 
> > Whatever the front end is, I'll still need to add 
> getSessionCount() methods
> > to the ContextManager, StandardManager, and 
> StandardSessionManager. (yes?)
> 
> I'm not sure you need to change ContextManager for that - you 
> can get the
> list of Contexts, and for each Context you can access the 
> StandardManager
> - and get the session count from it. All that can be done ( 
> IMHO ) from a
> servlet, without any change in the core - the only special thing is
> getting a pointer to the ContextManager.
> 
Hmmm, I'll look closer at Context and the StandardManager.
thanks.
> 
> > Sorry for the long rant, but I think I'm working on some 
> good functionality
> > that others could use as well, and I want to get it right.
> 
> +1. 
> 
> Costin
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>

Re: An alternative to JSP

2001-01-11 Thread Paul Speed

"Craig R. McClanahan" wrote:
> 
[  snip  ]
> 
> * My personal preference for the presentation layer is JSP (and has
>   been since long before I adopted a "sun.com" email address :-), for
>   several reasons:
[  snip ] 
> 
> * Custom tags - can be used to encapsulate sophisticated
>   functionality in a variety of ways, including smarter generation
>   of HTML to configuring application functionality).  See the
>   Struts Framework project 
>   to get a feel for what's possible.  (And Struts/Turbine/Barracuda
>   each offers an alternative approach to the organization of the
>   business logic as well.)

For what it's worth, I think that custom tags are the thing
that really saves JSP.  On my last project, we were able to 
encapsulate all logic into a servlet framework and custom tags.
(Actually, our framework ended up looking very similar to struts 
which I think is a very natural evolution of the smart-servlet 
design.)  

We had _no_ Java code in any of our JSP pages.  This was a 
goal from the beginning of the project and it would have been 
impossible without custom tags.

As it turned out, for many of the custom tags we were able
to write web-developer versions that didn't require the full back-end
application server.  Our web developers were then able to run tomcat
locally to help develop their pages and see what they looked like as
they developed.  We were fortunate that most of our web designers 
steered away from WYSIWYG tools... even though they did use web edit
tools like Homesite.  The more savvy web guys were even able to make
the tool integration look pretty seamless.

I'll be curious to see where the JSP spec evolves next.  To
me it seems logical to start incorporating more tags along the lines
of the current bean tags.  Iteration and other control structures
seems like the most common part of the wheel that tag libraries seem
to be re-inventing.  Standard versions sure would be nice.

-Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Bug Report #531

2001-01-11 Thread Kirk Rasmussen


This is still incorrect behavior if you ask me.  If I have page "foo.html"
that as an href to "bar.jsp" then bar.jsp should be able to determine who
"referred" to it.  WebLogic does this..maybe this is only a convenience
feature.

Kirk




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-4.0/catalina/docs/dev todo.html

2001-01-11 Thread glenn


glenn   01/01/11 15:07:09

  Modified:catalina/docs/dev todo.html
  Log:
  Assign myself the SecurityManager item
  
  Revision  ChangesPath
  1.2   +2 -2  jakarta-tomcat-4.0/catalina/docs/dev/todo.html
  
  Index: todo.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/docs/dev/todo.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- todo.html 2000/08/30 22:32:07 1.1
  +++ todo.html 2001/01/11 23:07:09 1.2
  @@ -124,7 +124,7 @@
   High
   Implement the Tomcat 3.x feature of being able to configure a
   security policy for each deployed web application.
  ----
  +Glenn Nielsen
 
 
   Medium
  @@ -337,7 +337,7 @@
   
   
   
  -$Id: todo.html,v 1.1 2000/08/30 22:32:07 craigmcc Exp $
  +$Id: todo.html,v 1.2 2001/01/11 23:07:09 glenn Exp $
   
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: acive session count?

2001-01-11 Thread cmanolache


> I agree that a jk_admin type application to control the load balancer and
> get session info would be great and very usefull, but that would have to
> access information from the web server (who's in the list, who's active) and
> each TC (how many sessions). So even if I built an Apache admin app, I would
> still have to add methods to Tomcat to return active session counts.
> (Although I would not have to modify AJP12...)

Yes, both Apache and tomcat need a mechanism to get status and change
configuration dynamically. 

Session count is a particular case. Adding/removing workers is another
particular case. 

What I'm thinking about is a general solution. The goals:

1. Extensible/Modular. Maybe you want to get other internal informations,
or change other parameters at run time.

2. Minimal ( or no ) changes in the core or protocols. Changes are bad
bacause they add bugs, require releases , etc, and if we do (1) right,
then no other change is needed.


> As another solution, I could leave 8080 running on each TC and have a
> servlet that accesses the Response to get the session count (with the
> getSessionCount() methods I've added) (ie the /admin app as you suggested
> before with minor modifications). Although, I'm not too fond of this
> solution because I'd have to keep the 8080 TCP listener, (in order to access
> a specific TC) and have a login for each query...
> But for simplicity's sake, it may be the way to go.

Well, having Ajp13 or Http listeners is almost the same, you don't need
the HTTP running if you have Ajp13 ( and a Ajp13 client - like apache ).
Regarding login for each query - this is an admin task, so it's not
performance-critical.

> Whatever the front end is, I'll still need to add getSessionCount() methods
> to the ContextManager, StandardManager, and StandardSessionManager. (yes?)

I'm not sure you need to change ContextManager for that - you can get the
list of Contexts, and for each Context you can access the StandardManager
- and get the session count from it. All that can be done ( IMHO ) from a
servlet, without any change in the core - the only special thing is
getting a pointer to the ContextManager.


> Sorry for the long rant, but I think I'm working on some good functionality
> that others could use as well, and I want to get it right.

+1. 

Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat/src/native/apache/jserv jserv_wrapper_unix.c jserv_wrapper_win.c


larryi  01/01/11 13:40:10

  Modified:src/native/apache/jserv Tag: tomcat_32 jserv_wrapper_unix.c
jserv_wrapper_win.c
  Log:
  Remove old JServ argument that Tomcat doesn't want to see, in case
  others want to play with this.  I haven't see any problems on NT4.
  Documentation still says that autostarting of Tomat is not supported.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.3.4.1   +0 -1  
jakarta-tomcat/src/native/apache/jserv/Attic/jserv_wrapper_unix.c
  
  Index: jserv_wrapper_unix.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/native/apache/jserv/Attic/jserv_wrapper_unix.c,v
  retrieving revision 1.3
  retrieving revision 1.3.4.1
  diff -u -r1.3 -r1.3.4.1
  --- jserv_wrapper_unix.c  2000/04/01 17:37:29 1.3
  +++ jserv_wrapper_unix.c  2001/01/11 21:40:09 1.3.4.1
  @@ -57,7 +57,7 @@
* Description: wrapper protocol implementation for Win32 systems*
* Author:  Pierpaolo Fumagalli ,  *
*  Ed Korthof *
  - * Version: $Revision: 1.3 $ *
  + * Version: $Revision: 1.3.4.1 $ *
*/
   #include "jserv.h"
   #include "http_conf_globals.h"
  @@ -244,7 +244,6 @@
   binparams = binparams->next;
   }
   if (cfg->class[0]!='\0') arg[x++]=strdup(cfg->class);
  -arg[x++]=strdup(cfg->config->properties);
   if (cfg->classparam[0]!='\0') arg[x++]=strdup(cfg->classparam);
   arg[x]=NULL;
   
  
  
  
  1.1.6.1   +2 -2  jakarta-tomcat/src/native/apache/jserv/Attic/jserv_wrapper_win.c
  
  Index: jserv_wrapper_win.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/native/apache/jserv/Attic/jserv_wrapper_win.c,v
  retrieving revision 1.1
  retrieving revision 1.1.6.1
  diff -u -r1.1 -r1.1.6.1
  --- jserv_wrapper_win.c   1999/11/25 01:29:57 1.1
  +++ jserv_wrapper_win.c   2001/01/11 21:40:09 1.1.6.1
  @@ -56,7 +56,7 @@
   /*
* Description: wrapper protocol implementation for Win32 systems*
* Author:  Pierpaolo Fumagalli <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.1 $*
  + * Version: $Revision: 1.1.6.1 $*
*/
   #include "jserv_wrapper.h"
   
  @@ -204,7 +204,7 @@
   
   /* Setup command line */
   commandline=ap_pstrcat(wrapper_pool, cfg->bin, " ", binparam, " ", 
  -   cfg->class, " \"", cfg->config->properties, "\" ",
  +   cfg->class,
  cfg->classparam, NULL);
  
   /* Setup environment */
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat/src/native/jk jk_util.c


larryi  01/01/11 13:33:38

  Modified:src/native/jk Tag: tomcat_32 jk_util.c
  Log:
  When the plugin is shutting down, the thread that the code is being run on
  will likely only have a 16k stack. Since jk_log creates an 8k buffer on
  the stack, there were some cases that we ran off the stack.
  
  Submitted by: Mike Anderson ([EMAIL PROTECTED])
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.6.2.3   +14 -1 jakarta-tomcat/src/native/jk/Attic/jk_util.c
  
  Index: jk_util.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/jk/Attic/jk_util.c,v
  retrieving revision 1.6.2.2
  retrieving revision 1.6.2.3
  diff -u -r1.6.2.2 -r1.6.2.3
  --- jk_util.c 2000/09/13 23:06:27 1.6.2.2
  +++ jk_util.c 2001/01/11 21:33:35 1.6.2.3
  @@ -56,7 +56,7 @@
   /***
* Description: Utility functions (mainly configuration)   *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.6.2.2 $   *
  + * Version: $Revision: 1.6.2.3 $   *
***/
   
   
  @@ -194,7 +194,13 @@
   }
   
   if(l->level <= level) {
  +#ifdef NETWARE
  +/* On NetWare, this can get called on a thread that has a limited stack so */
  +/* we will allocate and free the temporary buffer in this function */
  +char *buf;
  +#else
   char buf[HUGE_BUFFER_SIZE];
  +#endif
   char *f = (char *)(file + strlen(file) - 1);
   va_list args;
   int used = 0;
  @@ -209,6 +215,10 @@
   #ifdef WIN32
   used = _snprintf(buf, HUGE_BUFFER_SIZE, "[%s (%d)]: ", f, line);
   #elif defined(NETWARE) // until we get a snprintf function
  +buf = (char *) malloc(HUGE_BUFFER_SIZE);
  +if (NULL == buf)
  +   return -1;
  +
   used = sprintf(buf, "[%s (%d)]: ", f, line);
   #else 
   used = snprintf(buf, HUGE_BUFFER_SIZE, "[%s (%d)]: ", f, line);
  @@ -227,6 +237,9 @@
   #endif
   va_end(args);
   l->log(l, level, buf);
  +#ifdef NETWARE
  +free(buf);
  +#endif
   }
   
   return rc;
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

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


larryi  01/01/11 13:31:35

  Modified:src/native/netscape Tag: tomcat_32 jk_nsapi_plugin.c
  Log:
  Fix a problem when submitting dating from a form with a POST request.
  NetWare 5.1 doesn't have some of the assumed functionality
  (netbuf_getbytes).
  
  Submitted by: Mike Anderson ([EMAIL PROTECTED])
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.3.2.1   +4 -2  jakarta-tomcat/src/native/netscape/Attic/jk_nsapi_plugin.c
  
  Index: jk_nsapi_plugin.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/netscape/Attic/jk_nsapi_plugin.c,v
  retrieving revision 1.3
  retrieving revision 1.3.2.1
  diff -u -r1.3 -r1.3.2.1
  --- jk_nsapi_plugin.c 2000/06/23 10:36:07 1.3
  +++ jk_nsapi_plugin.c 2001/01/11 21:31:32 1.3.2.1
  @@ -56,7 +56,7 @@
   /***
* Description: NSAPI plugin for Netscape servers  *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.3 $   *
  + * Version: $Revision: 1.3.2.1 $   *
***/
   
   
  @@ -188,7 +188,9 @@
   unsigned i;
   netbuf *inbuf = p->sn->inbuf;
   
  -#ifdef netbuf_getbytes
  +/* Until we get a service pack for NW5.1 and earlier that has the latest */
  +/* Enterprise Server, we have to go through the else version of this code*/
  +#if defined(netbuf_getbytes) && !defined(NETWARE)
   i = netbuf_getbytes(inbuf, b, l);
   if(NETBUF_EOF == i || NETBUF_ERROR == i) {
   return JK_FALSE;
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]

2001-01-11 Thread Hans Bergsten


"Craig R. McClanahan" wrote:
> 
> Glenn Nielsen wrote:
> 
> > I stand corrected.
> >
> > The below problem was a bug in Tomcat.  Wrapping the RequestDispatcher
> > forward() and include() methods with a doPrivileged() if a SecurityManager
> > is being used fixed the problem.  When Tomcat 3.2.2 is released you will
> > no longer need to edit the jre/lib/security/java.security file to comment
> > out the package.access=sun. line.
> >
> > This fix is in the 3.2 CVS branch, and will be in the Tomcat 3.2.2 release.
> >
> 
> Glenn (and others),
> 
> Have we accumulated enough bug fixes where it's worth creating a 3.2.2 release, 
> or are there more issues that should be
> dealt with first?

I've seen the problem most recently reported in BugReport #744 described
a 
few times now, but I haven't had a chance to verify it and look for a
solution. 
Since this is a security bug, it seems like something that should be
included 
in 3.2.2.

I'll try to take a closer look at it this weekend, but can't promise
anything.

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: jaxp 1.0.1 and 1.1 RPMs


Not a problem of room but a legal problem of distributions.

Solution : Sun give jaxp 1.0 and 1.1 to Apache Foundation ;-)

"Pour la plupart des hommes, se corriger consiste à changer de défauts."
-- Voltaire 

>-Original Message-
>From: Rajiv Mordani [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, January 11, 2001 9:50 PM
>To: [EMAIL PROTECTED]
>Subject: Re: jaxp 1.0.1 and 1.1 RPMs
>
>
>Hi Gomez,
>   If you forward the RPMs to me or put them in a place where I can
>pick it up from, I'll try and get them hosted. No promises but will see
>what I can do. 
>
>- Rajiv
>
>--
>:wq
>
>On Thu, 11 Jan 2001, GOMEZ Henri wrote:
>
>> Hi to all Suners.
>> 
>> I finished some time ago RPM for jaxp 1.0.1 and jaxp 1.1 
>EARLY ADOPTERs.
>> Who could do something to have these RPMS available at Sun or Apache
>> site ?
>> 
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, email: [EMAIL PROTECTED]
>> 
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: jaxp 1.0.1 and 1.1 RPMs

2001-01-11 Thread Rajiv Mordani

Hi Gomez,
If you forward the RPMs to me or put them in a place where I can
pick it up from, I'll try and get them hosted. No promises but will see
what I can do. 

- Rajiv

--
:wq

On Thu, 11 Jan 2001, GOMEZ Henri wrote:

> Hi to all Suners.
> 
> I finished some time ago RPM for jaxp 1.0.1 and jaxp 1.1 EARLY ADOPTERs.
> Who could do something to have these RPMS available at Sun or Apache
> site ?
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP


on 1/11/01 12:12 PM, "Brad Cox" <[EMAIL PROTECTED]> wrote:

> I think these two quotes from the website will address your concern.

My concern?

> There is no official release yet, but there will be one shortly.

However, you can get daily snapshots which are quite stable and ready to
use.

> Velocity's design concept is borrowed from WebMacro.

However, it is vastly different in implementation.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

PATCH

2001-01-11 Thread Bill Hayden


In developing a servlet, I came across a bug in the tomcat code. The problem
was that the server was leaking file handle resources. I could run my
servlet a couple of times, but then it would cause an OutOf Memory
exception. The problem was in the (partial path here)
org/apache/tomcat/loader/AdaptiveClassLoader.java class. Specifically, in
the getResource(String name) method, a ZipFile object is instantiated. This
opens a zip file. The file is never closed. A source code snippet follows
with the fix in bold: 
   // a jar:-URL *could* change even between minor releases, but 
   // didn't between JVM's 1.1.6 and 1.3beta. Tested on JVM's from 
   // IBM, Blackdown, Microsoft, Sun @ Windows and Sun @ Solaris 
   try { 
   ZipFile zf = new ZipFile(file.getAbsolutePath()); 
   ZipEntry ze = zf.getEntry(name); 

   zf.close() ; 
   if (ze != null) { 

A small oversight, but this was a show stopper for me. I'm happy to
contribute something back for the use of this software. 
Kindest regards, 
William D. Hayden 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

BugRat Report #746 has been filed.


Bug report #746 has just been filed.

You can view the report at the following URL:

   

REPORT #746 Details.

Project: Tomcat
Category: Feature Requests
SubCategory: Enhancement
Class: suggest
State: received
Priority: medium
Severity: cosmetic
Confidence: public
Environment: 
   Release: 3.2.1
   JVM Release: any
   Operating System: any
   OS Release: any
   Platform: any

Synopsis: 
Additional logging in jk_uri_worker_map.c, function map_uri_to_worker

Description:
I suggest that additional logging be added that specifically describes the mapping 
taking place within the Apache or IIS plugins by modifying the function 
map_uri_to_worker in jk_uri_worker_map.c.  My version of the function is given below 
and differs only in the addition of 4 jk_log statements and the removal of one jk_log 
statement which was made redundant.




char *map_uri_to_worker(jk_uri_worker_map_t *uw_map,
const char *uri,
jk_logger_t *l)
{
jk_log(l, JK_LOG_DEBUG, 
   "Into jk_uri_worker_map_t::map_uri_to_worker\n");

if(uw_map && uri && '/' == uri[0]) {
unsigned i;
unsigned best_match = -1;
unsigned longest_match = 0;
char clean_uri[4096];
char *url_rewrite = strstr(uri, JK_PATH_SESSION_IDENTIFIER);

if(url_rewrite) {
strcpy(clean_uri, uri);
url_rewrite = strstr(clean_uri, JK_PATH_SESSION_IDENTIFIER);
*url_rewrite = '\0';
uri = clean_uri;
}

jk_log(l, JK_LOG_DEBUG, "Attempting to map URI %s\n", uri);
for(i = 0 ; i < uw_map->size ; i++) {

if(uw_map->maps[i].ctxt_len < longest_match) {
continue; /* can not be a best match anyway */
}

if(0 == strncmp(uw_map->maps[i].context, 
uri, 
uw_map->maps[i].ctxt_len)) {
if(MATCH_TYPE_EXACT == uw_map->maps[i].match_type) {
if(strlen(uri) == uw_map->maps[i].ctxt_len) {
jk_log( l,
JK_LOG_DEBUG, 

"jk_uri_worker_map_t::map_uri_to_worker, Found an exact match %s -> %s\n",

uw_map->maps[i].worker_name,

uw_map->maps[i].context );
return uw_map->maps[i].worker_name;
}
} else if(MATCH_TYPE_CONTEXT == uw_map->maps[i].match_type) {
if(uw_map->maps[i].ctxt_len > longest_match) {
jk_log( l,
JK_LOG_DEBUG, 

"jk_uri_worker_map_t::map_uri_to_worker, Found a context match %s -> %s\n",

uw_map->maps[i].worker_name,

uw_map->maps[i].context );
longest_match = uw_map->maps[i].ctxt_len;
best_match = i;
}
} else /* suffix match */ {
int suffix_start;

for(suffix_start = strlen(uri) - 1 ; 
suffix_start > 0 && '.' != uri[suffix_start]; 
suffix_start--) 
;
if('.' == uri[suffix_start]) {
const char *suffix = uri + suffix_start + 1;

/* for WinXX, fix the JsP != jsp problems */
#ifdef WIN32
if(0 == strcasecmp(suffix, uw_map->maps[i].suffix))  {
#else
if(0 == strcmp(suffix, uw_map->maps[i].suffix)) {
#endif
if(uw_map->maps[i].ctxt_len >= longest_match) {
jk_log( l,
JK_LOG_DEBUG, 

"jk_uri_worker_map_t::map_uri_to_worker, Found a suffix match %s -> *.%s\n",

uw_map->maps[i].worker_name,

uw_map->maps[i].suffix );
longest_match = uw_map->maps[i].ctxt_len;
best_match = i;
}
}
}   
}
}
}

if(-1 != best_match) {
return uw_map->maps[best_mat

Re: An alternative to JSP


I think these two quotes from the website will address your concern.

There is no official release yet, but there will be one shortly.
Velocity's design concept is borrowed from WebMacro.


At 11:42 AM -0800 01/11/2001, Jon Stevens wrote:
>on 1/11/01 11:21 AM, "Brad Cox" <[EMAIL PROTECTED]> wrote:
>
>>>  Please take a look at:
>>>  http://www.enhydra.org
>>>  and
>>>  http://xmlc.enhydra.org
>>>  for more information.
>>
>>  Will do. Looks a lot like WebMacro at first glance.
>>  --
>
>Absolutely not. XMLC is way different than WM or Velocity.
>
>Also, look at:
>
>
>
>p.s. It is interesting that you are a PhD. yet you haven't done any research
>into the alternatives that are out there. Instead you just invented your
>own. Sigh.
>
>-jon
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]

-- 
---
Dr. Brad Cox; [EMAIL PROTECTED]
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://superdistributed.com: A new paradigm for a new millinneum
PGP Signature: E194 C6E5 92D8 B8FB 20E8  8667 929A 95A0 FCB6 7C62

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

BugRat Report #745 has been filed.


Bug report #745 has just been filed.

You can view the report at the following URL:

   

REPORT #745 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: webbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: 3.2.1
   JVM Release: N.A.
   Operating System: Solaris
   OS Release: 2.6
   Platform: Unix SPARC

Synopsis: 
"tar: directory checksum error" on jakarta-tomcat-3.2.1-src.tar

Description:
The jakarta-tomcat-3.2.1-src.tar file produced by
uncompressing the *.Z file or deflating the *.gz file
causes /usr/bin/tar to report
"tar: directory checksum error"
when extracting all the files from the tar file.

It gets as far as
...
x 
jakarta-tomcat-3.2.1-src/src/webpages/docs/api/javax/servlet/http/class-use/HttpServletRequest.htm
l, 13710 bytes, 27 tape blocks

Also, when listing the table of contents, tar prints this
message to the standard error stream
"tar: impossible file typetar: impossible file typetar: impossible file typetar: 
impossible file typetar: impossible file typetar: impossible file typetar: impossible 
file type"

but, it doesn't associate any filenames with the error
messages.

I need the tomcat 3.2.1 source to compile mod_jk for
integrating Tomcat as an out of process servlet container
with Apache.


Title: 
BugRat Report #
745





BugRat Report #
745




Project:
Tomcat


Release:
3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
webbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
_Anonymous ( [EMAIL PROTECTED] )

Date Submitted:
Jan 11 2001, 02:04:38 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

"tar: directory checksum error" on jakarta-tomcat-3.2.1-src.tar


 Environment: (jvm, os, osrel, platform)

N.A., Solaris, 2.6, Unix SPARC



Additional Environment Description:





Report Description:

The jakarta-tomcat-3.2.1-src.tar file produced by
uncompressing the *.Z file or deflating the *.gz file
causes /usr/bin/tar to report
"tar: directory checksum error"
when extracting all the files from the tar file.

It gets as far as
...
x jakarta-tomcat-3.2.1-src/src/webpages/docs/api/javax/servlet/http/class-use/HttpServletRequest.htm
l, 13710 bytes, 27 tape blocks

Also, when listing the table of contents, tar prints this
message to the standard error stream
"tar: impossible file typetar: impossible file typetar: impossible file typetar: impossible file typetar: impossible file typetar: impossible file typetar: impossible file type"

but, it doesn't associate any filenames with the error
messages.

I need the tomcat 3.2.1 source to compile mod_jk for
integrating Tomcat as an out of process servlet container
with Apache.




View this report online...






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: BugRat Report #690 has been filed.

2001-01-11 Thread Glenn Nielsen


Craig,

Bug fixes for use of the Java SecurityManager are done and working well.

I do want to add another doc for setting up the SecurityManager when using
MS Windows OS's.

Glenn

"Craig R. McClanahan" wrote:
> 
> Glenn Nielsen wrote:
> 
> > I stand corrected.
> >
> > The below problem was a bug in Tomcat.  Wrapping the RequestDispatcher
> > forward() and include() methods with a doPrivileged() if a SecurityManager
> > is being used fixed the problem.  When Tomcat 3.2.2 is released you will
> > no longer need to edit the jre/lib/security/java.security file to comment
> > out the package.access=sun. line.
> >
> > This fix is in the 3.2 CVS branch, and will be in the Tomcat 3.2.2 release.
> >
> 
> Glenn (and others),
> 
> Have we accumulated enough bug fixes where it's worth creating a 3.2.2 release, or 
>are there more issues that should be
> dealt with first?
> 
> >
> > Regards,
> >
> > Glenn
> >
> 
> Craig
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

-- 
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP

At 11:12 AM -0800 01/11/2001, Craig R. McClanahan wrote:
>* I don't see any reasoning for why HTML-in-Java is better
>   than any of the alternatives -- just a presumptive conclusion.
>   The vast majority of the article is simply a description of your
>   recommended approach.

Good point. I'll expand on this argument in the article even though 
it is most relevant in the context of JSP *AND* MLS versus the 
template approaches I'm aware of. That's because both JSP and MLS use 
a general purpose language for executable inclusions, whereas the 
template systems I've examined closely (one at this point) do not 
provide general-purpose language capabilities.

>* Worse, this approach does other things:
>
> * Embeds presentation and business logic in one class,
   which is not a particularly scalable approach

> * Requires a Java developer to do your page development
>
> * Makes it difficult to leverage page authoring tools

Perhaps I miscommunicated. The private methods that contain the 
{{html}} need not be private methods in the controller class, 
although that is the style I demonstrated in the paper and that I use 
in my own work.

Noting requires the view methods to contain hardcoded strings, other 
than the crude measurements in the Conclusion section that makes me 
doubt that the space issue is a primary concern. Each method could 
aim MLS at an html file at runtime (using the doStream() method that 
MLS provides for this purpose but which I didn't mention in the 
article) and let it do the executable inclusion at runtime. But good 
point; I'll make this explicit in the article.

This would also eliminate the need for the outermost enclosing {{...}}, but
the executable inclusion brackets would remain. Do you object to my 
belief that html experts and their tools couldn't be trained to 
ignore the {{...}} wrappers around the html? I'd be interested in 
hearing more about this. After all, JSP has the same problem its <%= 
... %> executable inclusion syntax.

>
>* My personal preference for the presentation layer is JSP (and has
>   been since long before I adopted a "sun.com" email address :-), for
>   several reasons:
>
> * Separation of concerns - Mixing business logic and presentation
>   logic in one file (no matter what the syntax) works OK for simple
>   applications, but is not a particularly flexible long term approach.
>   All of the alternatives you compare yourself to have learned (and
>   implemented) this lesson.  Is there perhaps a message here that
>   you are missing?

I never advocated this. Syntactic validation is the responsibility of 
each field, low-level semantic validation is the responsibility of 
the controller, and high-level semantic validation is the 
responsibility of the Bean, in some cases even in the DBMS (although 
MySQL doesn't support this).

> * Custom tags - can be used to encapsulate sophisticated
>   functionality in a variety of ways, including smarter generation
>   of HTML to configuring application functionality).  See the
>   Struts Framework project 
>   to get a feel for what's possible.  (And Struts/Turbine/Barracuda
>   each offers an alternative approach to the organization of the
>   business logic as well.)

I've looked at struts but not at the others. Struts sounds like a great
improvement to JSP and I'd probably have adopted it were it not for 
the base objection to the whole java-in-html approach.

> * Development tools - Watch what tools like Macromedia Ultradev
>   do for page developers (*not* Java developers!!!) who want to
>   author pages that use custom tags for dynamic pages.  I do
>   not see a big future in hand coded HTML.

See above re reading html from files through MLS.

> * Alternative implementations - If Tomcat doesn't generate "good
>   enough" or "fast enough" code for you (and it's pretty minimally
>   acceptable at the moment), you've got choices of other vendors,
>   with a reasonable shot at your pages being portable if you take

MLS relies only on Java and the servlet API. Should be portable to 
anywhere, right?

-- 
---
Dr. Brad Cox; [EMAIL PROTECTED]
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://superdistributed.com: A new paradigm for a new millinneum
PGP Signature: E194 C6E5 92D8 B8FB 20E8  8667 929A 95A0 FCB6 7C62

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Tomcat 3.2.2 Was (BugRat Report #690 has been filed.)

2001-01-11 Thread Larry Isaacs


> Glenn (and others),
> 
> Have we accumulated enough bug fixes where it's worth 
> creating a 3.2.2 release, or are there more issues that should be
> dealt with first?
> 
Hi Craig,

I'm +1 for 3.2.2.

The UnavailableException handling in 3.2.1 is still not quite
right in Tomcat 3.2.  I have a patch that at least fixes the
problem where an included servlet throws an UnavailableException
which isn't handled.  It can travel up the chain of callers
marking each as unavailable.  A simple test case easily causes
the JspServlet to get marked permanently unavailable. :-(

I would also like to finally update Jasper to add the ability
to get class debugging information.  Hopefully this would be
viewed as "filling a hole" as opposed to adding a feature.
(Last chance to -1).

Both patches will be ready with a little more testing.
I will try to commit both of these to Tomcat 3.2 tonight.

Cheers,
Larry

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP

on 1/11/01 11:21 AM, "Brad Cox" <[EMAIL PROTECTED]> wrote:

>> Please take a look at:
>> http://www.enhydra.org
>> and
>> http://xmlc.enhydra.org
>> for more information.
> 
> Will do. Looks a lot like WebMacro at first glance.
> -- 

Absolutely not. XMLC is way different than WM or Velocity.

Also, look at:

p.s. It is interesting that you are a PhD. yet you haven't done any research
into the alternatives that are out there. Instead you just invented your
own. Sigh.

-jon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP

At 11:30 AM -0500 01/11/2001, Shawn McMurdo wrote:
>I agree with most of your discussion of the disadvantages of JSP/ASP/etc,
>but I believe your solution does not address a fundamental problem, which
>is the complete separation of presentation resources from presentation logic.

That is correct. My goal at this point is to get free of JSP so the 
goal was only to duplicate what JSP does in a way I can live with.

>Having the HTML embedded in a java class may be suitable for small
>applications
>built by engineers but does not address the vast majority of applications
>where designers work on HTML using many different HTML editing tools
>while developers work on the application logic in Java using various IDEs and
>editors.

Perhaps I miscommunicated. The private methods that contain the 
{{html}} need not be private methods in the controller class, 
although that is the style I demonstrated in the paper and that I use 
in my own I-do-it-all work.

Also there is nothing that requires these view methods to contain 
hardcoded strings, other than the crude measurements in the 
Conclusion section that makes me doubt that the space issue is a 
primary concern. Each method could aim MLS at an html file at runtime 
(using the doStream() method that it provides for this purpose but 
which I didn't mention in the article) and let it do the executable 
inclusion at runtime. But good point; I'll make this explicit in the 
article.

This would also eliminate the need for the outermost enclosing {{...}}, but
the executable inclusion brackets would remain. Do you object to my 
belief that html experts and their tools couldn't be trained to 
ignore the {{...}} wrappers around the html? I'd be interested in 
hearing more about this. After all, JSP has the same problem its <%= 
... %> executable inclusion syntax.

>Please take a look at:
>http://www.enhydra.org
>and
>http://xmlc.enhydra.org
>for more information.

Will do. Looks a lot like WebMacro at first glance.
-- 
---
Dr. Brad Cox; [EMAIL PROTECTED]
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://superdistributed.com: A new paradigm for a new millinneum
PGP Signature: E194 C6E5 92D8 B8FB 20E8  8667 929A 95A0 FCB6 7C62

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat/src/shell tomcat.bat


larryi  01/01/11 11:13:21

  Modified:src/shell tomcat.bat
  Log:
  Undo prior "fix" per Craig's note below:
  
  The double equals sign (==) tells the default security policy reader that the
  specified policy file completely *replaces* the standard one (which is what we
  want here, same as in Tomcat 3.2).  Otherwise, the specified policy file is
  merely *appended* to the standard one.
  
  Revision  ChangesPath
  1.33  +2 -2  jakarta-tomcat/src/shell/tomcat.bat
  
  Index: tomcat.bat
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/shell/tomcat.bat,v
  retrieving revision 1.32
  retrieving revision 1.33
  diff -u -r1.32 -r1.33
  --- tomcat.bat2001/01/08 12:11:46 1.32
  +++ tomcat.bat2001/01/11 19:13:18 1.33
  @@ -22,7 +22,7 @@
   rem
   rem   JAVA_HOMEMust point at your Java Development Kit installation.
   rem
  -rem $Id: tomcat.bat,v 1.32 2001/01/08 12:11:46 larryi Exp $
  +rem $Id: tomcat.bat,v 1.33 2001/01/11 19:13:18 larryi Exp $
   rem -
   
   
  @@ -152,7 +152,7 @@
   
   :startSecure
   echo Starting Tomcat with a SecurityManager
  -%_SECSTARTJAVA% %TOMCAT_OPTS% -Djava.security.manager 
-Djava.security.policy="%TOMCAT_HOME%/conf/tomcat.policy" 
-Dtomcat.home="%TOMCAT_HOME%" org.apache.tomcat.startup.Tomcat %3 %4 %5 %6 %7 %8 %9
  +%_SECSTARTJAVA% %TOMCAT_OPTS% -Djava.security.manager 
-Djava.security.policy=="%TOMCAT_HOME%/conf/tomcat.policy" 
-Dtomcat.home="%TOMCAT_HOME%" org.apache.tomcat.startup.Tomcat %3 %4 %5 %6 %7 %8 %9
   goto cleanup
   
   :runServer
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat/src/shell tomcat.bat


larryi  01/01/11 11:12:48

  Modified:src/shell Tag: tomcat_32 tomcat.bat
  Log:
  Undo prior "fix" per Craig's note below:
  
  The double equals sign (==) tells the default security policy reader that the
  specified policy file completely *replaces* the standard one (which is what we
  want here, same as in Tomcat 3.2).  Otherwise, the specified policy file is
  merely *appended* to the standard one.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.24.2.6  +2 -2  jakarta-tomcat/src/shell/tomcat.bat
  
  Index: tomcat.bat
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/shell/tomcat.bat,v
  retrieving revision 1.24.2.5
  retrieving revision 1.24.2.6
  diff -u -r1.24.2.5 -r1.24.2.6
  --- tomcat.bat2001/01/08 12:10:29 1.24.2.5
  +++ tomcat.bat2001/01/11 19:12:45 1.24.2.6
  @@ -22,7 +22,7 @@
   rem
   rem   JAVA_HOMEMust point at your Java Development Kit installation.
   rem
  -rem $Id: tomcat.bat,v 1.24.2.5 2001/01/08 12:10:29 larryi Exp $
  +rem $Id: tomcat.bat,v 1.24.2.6 2001/01/11 19:12:45 larryi Exp $
   rem -
   
   
  @@ -154,7 +154,7 @@
   
   :runSecure
   rem Running Tomcat with a SecurityManager
  -%_RUNJAVA% %TOMCAT_OPTS% -Djava.security.manager 
-Djava.security.policy="%TOMCAT_HOME%/conf/tomcat.policy" 
-Dtomcat.home="%TOMCAT_HOME%" org.apache.tomcat.startup.Tomcat %3 %4 %5 %6 %7 %8 %9
  +%_RUNJAVA% %TOMCAT_OPTS% -Djava.security.manager 
-Djava.security.policy=="%TOMCAT_HOME%/conf/tomcat.policy" 
-Dtomcat.home="%TOMCAT_HOME%" org.apache.tomcat.startup.Tomcat %3 %4 %5 %6 %7 %8 %9
   goto cleanup
   
   :stopServer
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

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


remm01/01/11 11:12:11

  Modified:catalina/src/share/org/apache/catalina/connector/http
HttpConnector.java
  Log:
  - Make sure that TC will only bind one IP when a hostname is specified.
Patch submitted by Thomas Butter <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.7   +8 -14 
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java
  
  Index: HttpConnector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- HttpConnector.java2000/12/23 19:39:54 1.6
  +++ HttpConnector.java2001/01/11 19:12:08 1.7
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
 1.6 2000/12/23 19:39:54 craigmcc Exp $
  - * $Revision: 1.6 $
  - * $Date: 2000/12/23 19:39:54 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
 1.7 2001/01/11 19:12:08 remm Exp $
  + * $Revision: 1.7 $
  + * $Date: 2001/01/11 19:12:08 $
*
* 
*
  @@ -94,7 +94,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.6 $ $Date: 2000/12/23 19:39:54 $
  + * @version $Revision: 1.7 $ $Date: 2001/01/11 19:12:08 $
*/
   
   
  @@ -734,17 +734,11 @@
}
   
// Open a server socket on the specified address
  - InetAddress[] addresses =
  - InetAddress.getAllByName(InetAddress.getLocalHost().getHostName());
  - int i;
  - for (i = 0; i < addresses.length; i++) {
  - if (addresses[i].getHostAddress().equals(address))
  - break;
  - }
  - if (i < addresses.length) {
  +try {
  +InetAddress is = InetAddress.getByName(address);
log(sm.getString("httpConnector.anAddress", address));
  -return (factory.createSocket(port, acceptCount, addresses[i]));
  - } else {
  +return (factory.createSocket(port, acceptCount, is));
  + } catch (Exception e) {
log(sm.getString("httpConnector.noAddress", address));
   return (factory.createSocket(port, acceptCount));
}
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP

2001-01-11 Thread Craig R. McClanahan

Brad Cox wrote:

> I've uploaded an early rough draft of a pair of articles that boils
> down to a critique of the JSP approach plus source code for a quite
> different approach. I'd be very interested in feedback... of the
> constructive variety, of course ;)
>
> The articles are at http://virtualschool.edu/wap
>

I didn't (and won't) have time to study the article in depth, but would make the
following observations:

* I don't see any reasoning for why HTML-in-Java is better
  than any of the alternatives -- just a presumptive conclusion.
  The vast majority of the article is simply a description of your
  recommended approach.

* The Multi-line Strings style will certainly appeal to PERL
  developers, but to me it is YATL (yet another template language)
  and does nothing to improve the expressive abilities or
  productivity of a page designer.

* Worse, this approach does other things:

* Embeds presentation and business logic in one class,
  which is not a particularly scalable approach

* Requires a Java developer to do your page development

* Makes it difficult to leverage page authoring tools

* My personal preference for the presentation layer is JSP (and has
  been since long before I adopted a "sun.com" email address :-), for
  several reasons:

* Separation of concerns - Mixing business logic and presentation
  logic in one file (no matter what the syntax) works OK for simple
  applications, but is not a particularly flexible long term approach.
  All of the alternatives you compare yourself to have learned (and
  implemented) this lesson.  Is there perhaps a message here that
  you are missing?

* Custom tags - can be used to encapsulate sophisticated
  functionality in a variety of ways, including smarter generation
  of HTML to configuring application functionality).  See the
  Struts Framework project 
  to get a feel for what's possible.  (And Struts/Turbine/Barracuda
  each offers an alternative approach to the organization of the
  business logic as well.)

* Development tools - Watch what tools like Macromedia Ultradev
  do for page developers (*not* Java developers!!!) who want to
  author pages that use custom tags for dynamic pages.  I do
  not see a big future in hand coded HTML.

* Alternative implementations - If Tomcat doesn't generate "good
  enough" or "fast enough" code for you (and it's pretty minimally
  acceptable at the moment), you've got choices of other vendors,
  with a reasonable shot at your pages being portable if you take
  care not to use platform-specific features.  If I like a template
  language, but don't like the one and only implementation, what
  can I do?  (NOTE:  Yes, Jon, I recognize that Velocity and
  WebMacro intend to implement common features -- "two" is
  better than "one" but still not as good as "many".)

* Wide acceptance - Go onto monster.com etc. and see how many
  jobs want JSP experience nowdays.  If I have a project that is due
  next month, do I really want to have to take the time to train my
  developers on the details of the template approach being used?  And
  know that I'm going to have to do that *every* time I hire someone
  new from now on?

I'm not going to have time to get into any extended discussion on this, but it
was worth a cup of coffee to write down some quick thoughts.

> --
> ---
> Dr. Brad Cox; [EMAIL PROTECTED]

Craig McClanahan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP


Thanks. No I'm not aware of Turbine, but I am aware of the approach 
described in the paper. That's what the company I was consulting for 
took
that I (perhaps inaccurately) described as "similar to WebMacro".

MLS? Preprocess code? WHAT?

Could you explain what you mean by this?

At 9:41 PM -0800 01/10/2001, Jon Stevens wrote:
>on 1/10/01 7:52 PM, "Brad Cox" <[EMAIL PROTECTED]> wrote:
>
>>  I've uploaded an early rough draft of a pair of articles that boils
>>  down to a critique of the JSP approach plus source code for a quite
>>  different approach. I'd be very interested in feedback... of the
>>  constructive variety, of course ;)
>>
>>  The articles are at http://virtualschool.edu/wap
>>  --
>>  ---
>>  Dr. Brad Cox; [EMAIL PROTECTED]
>>  Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
>>  http://superdistributed.com: A new paradigm for a new millinneum
>>  PGP Signature: E194 C6E5 92D8 B8FB 20E8  8667 929A 95A0 FCB6 7C62
>
>MLS? Preprocess code? WHAT?
>
>Have you even looked at what we are doing in Turbine/Velocity land?
>
>Also, let me also refer you to:
>
>
>
>-jon
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]

-- 
---
Dr. Brad Cox; [EMAIL PROTECTED]
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://superdistributed.com: A new paradigm for a new millinneum
PGP Signature: E194 C6E5 92D8 B8FB 20E8  8667 929A 95A0 FCB6 7C62

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: An alternative to JSP

2001-01-11 Thread Jef Newsom

I have used Excelon Stylus for creating xsl. Although you do a lot of
stuff by hand, I found it to be useful for wysiwyg development. I only
used it for a short time, so caveat emptor. Too bad it isn't integrated
with Dreamweaver. Also too bad that you have to download their portal
server to get the eval. $199 per license (blech)...
luckily, we're all rich, right?

Jef

-Original Message-
From: Kyle F. Downey [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 11, 2001 1:35 PM
To: Paul Libbrecht
Cc: [EMAIL PROTECTED]
Subject: Re: An alternative to JSP

>
> On Thursday, January 11, 2001, at 06:38 PM, Kyle F. Downey wrote:
>
> > Our chosen solution is to generate XML and style it with XSL. The
only
> > thing missing from that picture is a really solid XSL designer
integrated
> > with a well-known editor like Dreamweaver. Given that, your
designers can
>
> How did you solve this trouble then ??

We haven't. We're still writing XSL by hand, along with almost everyone
else.

> Unless such a designer tool is EXTREMELY INTELLIGENT, meaning it makes
some
> reasoning about the way xml elements are placed on an HTML page, or,
of
> course, if your xml content is reasonably static (say two dimensional
> like an SQL database result-set) then you have the chance to see such
a
> tool, otherwise, I don't view this as a possible thing...
>

I think the solution will look a lot like Allaire Cold Fusion Studio
when
it comes: a mixture of a solid design tool with a "developer" copy of a
rendering engine (Cold Fusion in Allaire's case; an XML app server in
this case). That way the designer can get immediate feedback on what the
data + view looks like. I agree with you that this is much thornier than
simple HTML design, but I think it can be done.

--kd

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

NullPointerException from HttpSessionFacade.invalidate()

2001-01-11 Thread Gokul Singh





Hi,I am trying to build a login servlet and get a 
NullPointerException from HttpSessionFacade class in Tomcat 3.2.1.The code 
of the simple version of the servlet which reproduces theproblem is attached 
at the end of this mail along with the stack trace of the Exception 
thrown.This piece of code works fine on tomcat 3.1.1 but fails on tomcat 
3.2.1
To reproduce the error,1. start tomcat 3.2.1 afresh.2. Login from a 
browser.The password field is not required as for now.3. Open another 
browser (not a new instance of the same browser) on the samemachine or 
another machine.4. Login with the same username.the servlet does the 
following1.it invalidates any existing session on this request.2.it 
checks the context to find if the present user has any associatedsession and 
if it is there tries to invalidate it. (This is where I get theexception, 
given below).3. creates a new session.4. puts the new session into the 
context with the user id.In tomcat 3.2 is the session object which I get 
( actually HttpSessionFacade) valid only for the request or can span multiple 
Requests?
Any help would be greatly appreciated.
 
I am not on this mailing list. Please send a CC to me at [EMAIL PROTECTED] when replying to 
this mailRegds,Gokul= 8< SERVLET CODE 
= 8< ===import javax.servlet.*;import 
javax.servlet.http.*;import java.io.*;public class 
TestSessionBehaviourextends HttpServlet{ private static String 
STR="LOGIN.SESSION.USER."; public void doGet(HttpServletRequest req, 
HttpServletResponse res) throws IOException, 
ServletException {  res.setContentType("text/html");  
PrintWriter out = res.getWriter();  sendLoginPage(out);  
out.close(); } public void doPost(HttpServletRequest req, 
HttpServletResponse res) throws IOException {  String 
name = req.getParameter("id");  HttpSession objSession = 
req.getSession(false);  // if the present request has a session 
invalidate it.  if(objSession != null)   
objSession.invalidate();  // if this user has a valid session, 
invalidate it.  objSession = 
(HttpSession)getServletContext().getAttribute(STR+name);  if 
(objSession != null)  {   System.out.println("The session 
from context retrieved");   try   
{    objSession.invalidate();   
}catch(IllegalStateException ex)   {   }  
}  // create new session  objSession = 
req.getSession(true);  // store in the context the username and 
session.  
getServletContext().setAttribute(STR+name,objSession);  // send 
reciept html  res.setContentType("text/html");  PrintWriter 
out = res.getWriter();  sendReceipt(out);  
out.close(); } private void sendReceipt(PrintWriter 
out) {  
out.println("ReceiptThe login 
isrecorded"); } private 
void sendLoginPage(PrintWriter out) {  
out.println("Test LoginPlease 
login method=post> ");  
out.println("Name  
");  
out.println("Passwordname=pass>");  
out.println("type=submit 
value=login>");  
out.println(""); }}= 
8<= EXCEPTION THROWN 8< =Internal Servlet 
Error:java.lang.NullPointerException atorg.apache.tomcat.facade.HttpSessionFacade.invalidate(HttpSessionFacade.java:136) at 
TestSessionBehaviour.doPost(TestSessionBehaviour.java:33) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at 
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at 
org.apache.tomcat.core.Handler.service(Handler.java:286) at 
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) atorg.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) at 
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) atorg.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210) atorg.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) atorg.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at 
java.lang.Thread.run(Thread.java:484)= 8<= 8< 
=
 
---"The 
proverb warns that, 'You should not bite the hand that 
feeds you.'  But maybe you should, if it prevents you from feeding 
yourself."--Thomas 
Szasz---

Re: jaxp 1.0.1 and 1.1 RPMs


on 1/11/01 8:16 AM, "GOMEZ Henri" <[EMAIL PROTECTED]> wrote:

> So I'll stay with xerces-j much larger but redistribuable ?-)

Yep.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories

2001-01-11 Thread Craig R. McClanahan

Bob Jamison wrote:

> Hi, all,
>
> Will 4.1 be read-visible in the "cvspublic" repository?
>

Ooops ... forgot a couple steps.  The two new repositories ("jakarta-tomcat-4.1" and
"jakarta-servletapi-4") are now visible to anonymous CVS.  Web site updates are
forthcoming.

>
> Bob Jamison
> LinCom Corp
>

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

BugRat Bug #18 - response.flushBuffer() fails to flush


Bug #18 Details

Project: Jasper
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: closed
Priority: high
Severity: serious
Confidence: public
Environment: 
   Release: 3.3
   JVM Release: 1.2.2
   Operating System: Linux
   OS Release: RedHat 6.2
   Platform: i386

Synopsis: 
response.flushBuffer() fails to flush

Description:
Calling response.flushBuffer() doesn't actually flush the buffer.

>From my posting on the tomcat-dev list:

Note that in a JSP, out.flush() does the right thing now, but
response.flushBuffer() does not.)
 
The problem comes because Jasper JspWriter has its own buffer --
apparently this was written before Costin added OutputBuffer to the
servlet output stream.  But the Response object used by Jasper is the
exact same one that Tomcat passes it.  Unfortunately, this response
object has no idea of the existence of Jasper's JspWriter buffer.
Thus, its flushBuffer() method just flushes the Tomcat stream, not the
Jasper stream, and characters remain in Jasper until the response is
closed.
 
Possible solutions:
 
1. Remove the buffer from JspWriter.  This would be cleanest, but may
cause problems, since this kind of surgery would require modifying
lots of code throughout JspWriterImpl, possibly leading to odd bugs,
or at least a lot of work.  Also, I haven't thought through the
implications viz the autoFlush attribute, though on first blush I
don't think it would be a problem (we'd just say "Jasper is a
buffering JSP engine" which it actually already is).
 
2. Make Jasper implement a facade over Response (actually over
HttpServletResponse) that correctly implements flushBuffer by calling
jspwriter.flush(); this would have to be done inside _jspService,
meaning inside generated code, which seems flakey to me.  Also, a
trivial implementation of such a facade would lead to performance
issues (making a few new objects per JSP request), unless we use
pooling, which seems also like a lot of work.

3. Add a private callback method to our HttpServletResponse (in our
facade manager, called from Response.java to make the
HttpServletResponse facade) that calls Jasper when flushBuffer is
called; this would break compatibility with other servlet engines.

I'm leaning towards #1.  Any doubts?

Clarification:  flushBuffer is a method on *response*, which was passed
in from Tomcat, which has its own buffer.  Which it flushes.  But
Jasper's buffer is somewhere else (inside JspWriterImpl), that
Response doesn't know about, so it stays full.

There's a JspWriter whose flush method works fine.  But there's no
"JspResponse" or equivalent (that would be my facade solution).

This is really the fault of the API; I see no reason for having a
Response.flushBuffer() call when out.flush() should (and does) do the
job perfectly well.  Maybe I should ask the JSR 53 experts why they
added this method to Response.


Title: 
BugRat Bug #
18





BugRat Bug #
18




Project:
Jasper


Release:
3.3




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
closed




Priority:
high


Severity:
serious




Confidence:
public





Date Opened:
Aug 25 2000, 07:29:43 CDT

Date Closed:
Aug 27 2000, 05:56:26 CDT

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

response.flushBuffer() fails to flush


 Environment: (jvm, os, osrel, platform)

1.2.2, Linux, RedHat 6.2, i386



Additional Environment Description:





Report Description:

Calling response.flushBuffer() doesn't actually flush the buffer.

>From my posting on the tomcat-dev list:

Note that in a JSP, out.flush() does the right thing now, but
response.flushBuffer() does not.)
 
The problem comes because Jasper JspWriter has its own buffer --
apparently this was written before Costin added OutputBuffer to the
servlet output stream.  But the Response object used by Jasper is the
exact same one that Tomcat passes it.  Unfortunately, this response
object has no idea of the existence of Jasper's JspWriter buffer.
Thus, its flushBuffer() method just flushes the Tomcat stream, not the
Jasper stream, and characters remain in Jasper until the response is
closed.
 
Possible solutions:
 
1. Remove the buffer from JspWriter.  This would be cleanest, but may
cause problems, since this kind of surgery would require modifying
lots of code throughout JspWriterImpl, possibly leading to odd bugs,
or at least a lot of work.  Also, I haven't thought through the
implications viz the autoFlush attribute, though on first blush I
don't think it would be a problem (we'd just say "Jasper is a
buffering JSP engine" which it actually already is).
 
2. Make Jasper implement a facade over Response (actually over
HttpServletResponse) that correctly implements flushBuffer by calling
jspwriter.flush(); this would have to be done inside _jspService,
meaning inside generated code, which seems flakey to me.  Also, a
trivial implementation of such a facade would lead to performance
issues (making a few new objects per JSP request), unless we use
pooli

Re: possible problems in org.apache.catalina.connector.http.SocketInputStream

2001-01-11 Thread Remy Maucherat


> I attached a little patch that reimplements the used methods of the BIS.
> It should be a little bit faster because it doesn't implement marks.
> Not sure if it is worth the extra code because read() isn't called very
> often anyway and if read(byte []) is used anywhere then it should be
> rewritten too (didn't do it here because I wasn't sure if it is ever
used).

I already had "rewritten" it in my local copy, actually. I didn't implement
read(byte[]) and skip(n) yet. I don't think it would impact performance a
lot. It could help a bit when uploading, but it can safely be done later.

Servlet spec question : Does the ServletInputStream we give to a servlet has
to be thread safe ?

Remy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

BugRat Report #744 has been filed.


Bug report #744 has just been filed.

You can view the report at the following URL:

   

REPORT #744 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: serious
Confidence: confidential
Environment: 
   Release: 3.2.1
   JVM Release: 1.2.2.04
   Operating System: HPUX
   OS Release: 11
   Platform: PA-RISC

Synopsis: 
security hole - can download jsp page source code

Description:
When tomcat 3.2.1 is running in stand-alone mode, simply using telnet to connect to it 
and issuing "GET /path/file.jsp" downloads the raw source code for the file.

If the command sent is "GET /path/file.jsp HTTP 1.0" then
the page is correctly *run* and the *results* are sent back.

Title: 
BugRat Report #
744





BugRat Report #
744




Project:
Tomcat


Release:
3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
serious




Confidence:
confidential





Submitter:
Simon Kitching ( [EMAIL PROTECTED] )

Date Submitted:
Jan 11 2001, 11:10:38 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

security hole - can download jsp page source code


 Environment: (jvm, os, osrel, platform)

1.2.2.04, HPUX, 11, PA-RISC



Additional Environment Description:

Same behaviour on Sun Solaris with:

OS:
SunOS vdcrola1 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-250

JVM:
Solaris VM (build Solaris_JDK_1.2.2_06, native threads, sunwjit)



Report Description:

When tomcat 3.2.1 is running in stand-alone mode, simply using telnet to connect to it and issuing "GET /path/file.jsp" downloads the raw source code for the file.

If the command sent is "GET /path/file.jsp HTTP 1.0" then
the page is correctly *run* and the *results* are sent back.



How To Reproduce:

null



View this report online...






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: BugRat Report #690 has been filed.

2001-01-11 Thread Glenn Nielsen


I stand corrected.

The below problem was a bug in Tomcat.  Wrapping the RequestDispatcher
forward() and include() methods with a doPrivileged() if a SecurityManager
is being used fixed the problem.  When Tomcat 3.2.2 is released you will
no longer need to edit the jre/lib/security/java.security file to comment
out the package.access=sun. line.

This fix is in the 3.2 CVS branch, and will be in the Tomcat 3.2.2 release.

Regards,

Glenn

Glenn Nielsen wrote:
> 
> This isn't a Tomcat bug, its the way security works (whether correct or not).
> Perhaps this should be sent in as a Java bug report to Sun.
> 
> This is documented in tomcat-security.html, you have to comment out
> the line:
> 
> package.access=sun.
> 
> in your $JAVA_HOME/jre/lib/security/java.security file.
> 
> BugRat Mail System wrote:
> >
> > Bug report #690 has just been filed.
> >
> > You can view the report at the following URL:
> >
> >
> >
> > REPORT #690 Details.
> >
> > Project: Tomcat
> > Category: Bug Report
> > SubCategory: New Bug Report
> > Class: swbug
> > State: received
> > Priority: high
> > Severity: serious
> > Confidence: public
> > Environment:
> >Release: Tomcat 3.2.1
> >JVM Release: 1.2.2
> >Operating System: Windows 2000 Pro
> >OS Release: ?
> >Platform: Intel
> >
> > Synopsis:
> > jsp compliation error
> >
> > Description:
> > The default javasoft/JRE/1.2/lib/security/java.security file restricts use of the 
>sun. packages.
> >
> > Both Tomcat and EmbededTomcat fail with the following error:
> >
> > Unable to compile class for JSP
> > java.security.AccessControlException: access denied (java.lang.RuntimePermission 
>accessClassInPackage.sun.tools.java
> >
> > Adding the following to the default tomcat.policy file does not correct the error:
> >
> > grant {
> >   permission java.lang.RuntimePermission "accessClassInPackage.sun.tools.java";
> > };
> >
> >   
>--
> >  Name: Report-690.html
> >Report-690.html   Type: Hypertext Markup Language (text/html)
> >  Encoding: 7bit
> >   Description: DataSource attachment 'Report-690.html'
> >
> >Part 1.3Type: Plain Text (text/plain)
> 
> --
> --
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> MOREnet System Programming   |  * if iz ina coment.  |
> Missouri Research and Education Network  |  */   |
> --
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

-- 
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP

2001-01-11 Thread Kyle F. Downey



Right on. HTML-in-Java vs. Java-in-HTML is a silly argument AFAIK.
Neither's a very good solution long-term. The Java-in-HTML makes it
near-impossible for designers to collaborate with coders, while the
HTML-in-Java has that problem, plus the code bloat problem (the bytecode
format will choke on overly large HTML strings in classes), and the fact
that it's just a bitch to edit HTML inside Java files. The author of
FreeMarker or WebMacro wrote an article on this subject a while back.

Our chosen solution is to generate XML and style it with XSL. The only
thing missing from that picture is a really solid XSL designer integrated
with a well-known editor like Dreamweaver. Given that, your designers can
work 100% independently of the coders, and you get many other benefits in
the bargain, like ability to morph your sites appearance to the needs of
the incoming browser and ability to publish XML-only Web services using
the same content.

regards,
kd

> I agree with most of your discussion of the disadvantages of JSP/ASP/etc,
> but I believe your solution does not address a fundamental problem, which
> is the complete separation of presentation resources from presentation logic.
>
> Having the HTML embedded in a java class may be suitable for small
> applications
> built by engineers but does not address the vast majority of applications
> where designers work on HTML using many different HTML editing tools
> while developers work on the application logic in Java using various IDEs and
> editors.

>
> Having the HTML and Java mixed together whether it is in a JSP file or in a
> servlet
> with multiline strings is a maintanence problem.
> It becomes difficult for designers to change the layout or developers to
> change the
> logic without walking all over each other.
> These mixed files are also problematic for many design or development tools.
>
> A superior approach is to completely separate the HTML presetation from the
> Java logic as is done in XMLC (the Enhydra XML Compiler).
> With XMLC, HTML (as well as any XML resource such as WML, cHTML,
> XHTML, VoiceML, etc) files are compiled into Java class files that use the
> W3C (World Wide Web Consortioum)'s DOM (Document Ovject Model) standard
> to represent the document.  The developer can then manipulate the presentation
>
> directly from within the Java presentation logic.
>
> After 4+ years of working with templating languages (including one we wrote
> that
> predates JSP), we have found this to be a vastly superior way to develop web
> applications.
>
> Please take a look at:
> http://www.enhydra.org
> and
> http://xmlc.enhydra.org
> for more information.
>
> XMLC is open source and freely available.
>
> Shawn
>
>
> Brad Cox wrote:
>
> > I've uploaded an early rough draft of a pair of articles that boils
> > down to a critique of the JSP approach plus source code for a quite
> > different approach. I'd be very interested in feedback... of the
> > constructive variety, of course ;)
> >
> > The articles are at http://virtualschool.edu/wap
> > --
> > ---
> > Dr. Brad Cox; [EMAIL PROTECTED]
> > Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
> > http://superdistributed.com: A new paradigm for a new millinneum
> > PGP Signature: E194 C6E5 92D8 B8FB 20E8  8667 929A 95A0 FCB6 7C62
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
>
> --
> Shawn McMurdo  mailto:[EMAIL PROTECTED]
> Lutris Technologieshttp://www.lutris.com
> Enhydra.Orghttp://www.enhydra.org
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: An alternative to JSP

2001-01-11 Thread Shawn McMurdo

Hi Brad,
Interesting articles.

I agree with most of your discussion of the disadvantages of JSP/ASP/etc,
but I believe your solution does not address a fundamental problem, which
is the complete separation of presentation resources from presentation logic.

Having the HTML embedded in a java class may be suitable for small
applications
built by engineers but does not address the vast majority of applications
where designers work on HTML using many different HTML editing tools
while developers work on the application logic in Java using various IDEs and
editors.

Having the HTML and Java mixed together whether it is in a JSP file or in a
servlet
with multiline strings is a maintanence problem.
It becomes difficult for designers to change the layout or developers to
change the
logic without walking all over each other.
These mixed files are also problematic for many design or development tools.

A superior approach is to completely separate the HTML presetation from the
Java logic as is done in XMLC (the Enhydra XML Compiler).
With XMLC, HTML (as well as any XML resource such as WML, cHTML,
XHTML, VoiceML, etc) files are compiled into Java class files that use the
W3C (World Wide Web Consortioum)'s DOM (Document Ovject Model) standard
to represent the document.  The developer can then manipulate the presentation

directly from within the Java presentation logic.

After 4+ years of working with templating languages (including one we wrote
that
predates JSP), we have found this to be a vastly superior way to develop web
applications.

Please take a look at:
http://www.enhydra.org
and
http://xmlc.enhydra.org
for more information.

XMLC is open source and freely available.

Shawn

Brad Cox wrote:

> I've uploaded an early rough draft of a pair of articles that boils
> down to a critique of the JSP approach plus source code for a quite
> different approach. I'd be very interested in feedback... of the
> constructive variety, of course ;)
>
> The articles are at http://virtualschool.edu/wap
> --
> ---
> Dr. Brad Cox; [EMAIL PROTECTED]
> Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
> http://superdistributed.com: A new paradigm for a new millinneum
> PGP Signature: E194 C6E5 92D8 B8FB 20E8  8667 929A 95A0 FCB6 7C62
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

--
Shawn McMurdo  mailto:[EMAIL PROTECTED]
Lutris Technologieshttp://www.lutris.com
Enhydra.Orghttp://www.enhydra.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: acive session count?

2001-01-11 Thread Michael Kuz

Title: RE: acive session count?





Morning, Comments below...


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 10, 2001 11:20 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: acive session count?
> 
> 
> Hi,
> 
> > Solution: Dan Milstein is adding my patch to mod_jk. It 
> forces an instance
> > of Tomcat in the load balance list to reject new 
> connections, but continue
> > to service existing sessions. (by setting worker.name.active=0, and
> > restarting my apaches) 
> 
> Question: can this be done _without_ restarting apache ? 
> 


Not without having some platform/product specific code...
As you suggest below, I would have to add function to Apache only, and I would really like this to work for all web servers. Granted, it would be good to be able to change a containers status without a restart, but I didn't/don't consider restarting the web server to be bad. (In our case, we do it as required with a 'killall -USR1 httpd' for a graceful restart), but we do have 6 Apaches LVS'd...)


> I was thinking about the whole 
> "configuration/reconfiguration/signales" mechanism,
> and IMHO there is a simpler solution: instead of using 
> signals and AJP13
> extensions, it may be better to just use plain HTTP and normal
> servlets/apache handlers. 


The extensions I made to AJP12 were to _query_ the TC instance for an acive session count (from the command line). 


> 
> Creating a simple /jk_admin is not difficult ( a simple 
> handler that will
> accept an authenticated HTTP request and alter the 
> configuration ). That
> will allow run-time addition of apps and workers without restarting
> apache. 
> 
> For tomcat side, few extra servlets on the admin app will be 
> much easier
> and safer to develop than changing the protocols or other 
> internals ( and
> will probably be more re-usable ). 


I have to agree that the changes I've made to the protocol are quite intrusive. 
Again, I'm looking for a simple way to get the active session count from a specific TC instance. 


I agree that a jk_admin type application to control the load balancer and get session info would be great and very usefull, but that would have to access information from the web server (who's in the list, who's active) and each TC (how many sessions). So even if I built an Apache admin app, I would still have to add methods to Tomcat to return active session counts. (Although I would not have to modify AJP12...)

As another solution, I could leave 8080 running on each TC and have a servlet that accesses the Response to get the session count (with the getSessionCount() methods I've added) (ie the /admin app as you suggested before with minor modifications). Although, I'm not too fond of this solution because I'd have to keep the 8080 TCP listener, (in order to access a specific TC) and have a login for each query...

But for simplicity's sake, it may be the way to go.


Whatever the front end is, I'll still need to add getSessionCount() methods to the ContextManager, StandardManager, and StandardSessionManager. (yes?)

Sorry for the long rant, but I think I'm working on some good functionality that others could use as well, and I want to get it right.

Thanks,
mk

RE: jaxp 1.0.1 and 1.1 RPMs


So I'll stay with xerces-j much larger but redistribuable ?-)


"Pour la plupart des hommes, se corriger consiste à changer de défauts."
-- Voltaire 

>-Original Message-
>From: Peter Donald [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, January 11, 2001 4:56 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: Re: jaxp 1.0.1 and 1.1 RPMs
>
>
>At 04:42  11/1/01 +0100, GOMEZ Henri wrote:
>>Hi to all Suners.
>>
>>I finished some time ago RPM for jaxp 1.0.1 and jaxp 1.1 
>EARLY ADOPTERs.
>>Who could do something to have these RPMS available at Sun or Apache
>>site ?
>
>Unfortunately it's not legal to have jaxp1.1 available via 
>apache as there
>is 6 or so classes that are not owned by Apache but are owned 
>by sun and
>under their EA license  - which means Apache can't distribute them ;(
>
>
>Cheers,
>
>Pete
>
>*-*
>| "Faced with the choice between changing one's mind, |
>| and proving that there is no need to do so - almost |
>| everyone gets busy on the proof."   |
>|  - John Kenneth Galbraith   |
>*-*
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: jaxp 1.0.1 and 1.1 RPMs

2001-01-11 Thread Peter Donald


At 04:42  11/1/01 +0100, GOMEZ Henri wrote:
>Hi to all Suners.
>
>I finished some time ago RPM for jaxp 1.0.1 and jaxp 1.1 EARLY ADOPTERs.
>Who could do something to have these RPMS available at Sun or Apache
>site ?

Unfortunately it's not legal to have jaxp1.1 available via apache as there
is 6 or so classes that are not owned by Apache but are owned by sun and
under their EA license  - which means Apache can't distribute them ;(


Cheers,

Pete

*-*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."   |
|  - John Kenneth Galbraith   |
*-*


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

BugRat Report #743 has been filed.


Bug report #743 has just been filed.

You can view the report at the following URL:

   

REPORT #743 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: serious
Confidence: public
Environment: 
   Release: 3.2.1
   JVM Release: 1.3
   Operating System: Windows 2000
   OS Release: Service Pack 1
   Platform: Intel P2/350

Synopsis: 
request.getServerPort() reports wrong port with SSL (https)

Description:
I've written a simple servlet which prints out request.getServerPort().
It is running on a Tomcat 3.2.1 (win32) configured to http on port 80 and
https on port 443.
When I try to access the servlet under http://localhost/..., it prints out
port 80.
ERROR: When I try to access the servlet via https://localhost/..., it also
prints out port 80!
Why? Shouldn't it print out port 443?
As a result, HttpUtils.getRequestURI contructs the wrong URI
(https://localhost:80/...) when accessing via https.



Title: 
BugRat Report #
743





BugRat Report #
743




Project:
Tomcat


Release:
3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
serious




Confidence:
public





Submitter:
Andreas Schildbach ( [EMAIL PROTECTED] )

Date Submitted:
Jan 11 2001, 09:45:07 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

request.getServerPort() reports wrong port with SSL (https)


 Environment: (jvm, os, osrel, platform)

1.3, Windows 2000, Service Pack 1, Intel P2/350



Additional Environment Description:





Report Description:

I've written a simple servlet which prints out request.getServerPort().
It is running on a Tomcat 3.2.1 (win32) configured to http on port 80 and
https on port 443.
When I try to access the servlet under http://localhost/..., it prints out
port 80.
ERROR: When I try to access the servlet via https://localhost/..., it also
prints out port 80!
Why? Shouldn't it print out port 443?
As a result, HttpUtils.getRequestURI contructs the wrong URI
(https://localhost:80/...) when accessing via https.





How To Reproduce:

null



Workaround:

null



View this report online...






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

jaxp 1.0.1 and 1.1 RPMs


Hi to all Suners.

I finished some time ago RPM for jaxp 1.0.1 and jaxp 1.1 EARLY ADOPTERs.
Who could do something to have these RPMS available at Sun or Apache
site ?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

BugRat Report #741 has been filed.


Bug report #741 has just been filed.

You can view the report at the following URL:

   

REPORT #741 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: serious
Confidence: public
Environment: 
   Release: 2.3.1
   JVM Release: 1.2.2
   Operating System: Linux
   OS Release: 2.4.0
   Platform: x86

Synopsis: 
url-pattern in security constraint broken

Description:
When defining a security constraint, the following 
url-pattern: "/foobar/*", matches not only resources 
under /foobar/, but also /foobar.jsp at the root of the 
context, which is incorrect.





Title: 
BugRat Report #
741





BugRat Report #
741




Project:
Tomcat


Release:
2.3.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
serious




Confidence:
public





Submitter:
Taso Lyristis ( [EMAIL PROTECTED] )

Date Submitted:
Jan 11 2001, 08:01:27 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

url-pattern in security constraint broken


 Environment: (jvm, os, osrel, platform)

1.2.2, Linux, 2.4.0, x86



Additional Environment Description:





Report Description:

When defining a security constraint, the following 
url-pattern: "/foobar/*", matches not only resources 
under /foobar/, but also /foobar.jsp at the root of the 
context, which is incorrect.







Workaround:

null



View this report online...






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

BugRat Report #741 has been filed.


Bug report #741 has just been filed.

You can view the report at the following URL:

   

REPORT #741 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: serious
Confidence: public
Environment: 
   Release: 2.3.1
   JVM Release: 1.2.2
   Operating System: Linux
   OS Release: 2.4.0
   Platform: x86

Synopsis: 
url-pattern in security constraint broken

Description:
When defining a security constraint, the following 
url-pattern: "/foobar/*", matches not only resources 
under /foobar/, but also /foobar.jsp at the root of the 
context, which is incorrect.





Title: 
BugRat Report #
741





BugRat Report #
741




Project:
Tomcat


Release:
2.3.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
serious




Confidence:
public





Submitter:
Taso Lyristis ( [EMAIL PROTECTED] )

Date Submitted:
Jan 11 2001, 08:01:27 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

url-pattern in security constraint broken


 Environment: (jvm, os, osrel, platform)

1.2.2, Linux, 2.4.0, x86



Additional Environment Description:





Report Description:

When defining a security constraint, the following 
url-pattern: "/foobar/*", matches not only resources 
under /foobar/, but also /foobar.jsp at the root of the 
context, which is incorrect.







Workaround:

null



View this report online...






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories

2001-01-11 Thread Bob Jamison


Craig R. McClanahan wrote:

> 
> 
> (2) Tomcat 4.1 Repository
> 
> As we approach a release quality build for Tomcat 4.0, it is also time to split
> the development of major new functionality (such as the distributed session
> management currently under discussion) into a development process that does not
> destabilize the 4.0 release code.  We can do this with a branch or a new
> repository.  After thinking about the relative merits of this for a bit, and
> consulting with others who have managed similar evoluations, I think a new
> repository is the way to go.
> 
> Therefore, I propose to create a new "jakarta-tomcat-4.1" repository on Friday
> as well, based originally on the code that is marked for Tomcat 4.0 beta 1.
> Because this code is just another portion of the overall code base for Tomcat,
> all existing Tomcat committers will have write access to it (just as they do
> with "jakarta-tomcat" and "jakarta-tomcat-4.0" today) -- no extra committer
> votes are required.
> 
> NOTE:  Pending this change, I would ask that we *not* commit changes to the 4.0
> repository for new features that will appear in 4.1, until *after* the split.
> 
> At the same time, I will modify the build processes that create nightly
> distributions of Tomcat to create a build of the most recent 4.0 tree and the
> most recent 4.1 tree, so that people interested in either version can follow
> along as they prefer.
> 
Hi, all,

Will 4.1 be read-visible in the "cvspublic" repository?




Bob Jamison
LinCom Corp





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

BugRat Report #739 has been filed.


Bug report #739 has just been filed.

You can view the report at the following URL:

   

REPORT #739 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: 3.2.1
   JVM Release: java version "1.3.0_01" Java(TM) 2 Runtime Environment, Standard 
Edition (build 1.3.0_01) Java HotSpot(TM) Client VM (build 1.3.0_01, mixed mode)
   Operating System: Windows 95
   OS Release: 4.00.095 B
   Platform: x86

Synopsis: 
Problem when I try to store a referance to the session in the context and then when I 
try to access it in the next request I get NullPointerException

Description:
The same code works just fine on tomcat 3.1.1.

The problem to me appears to be due the fact that I save a referance to the 
HttpSessionFacade ( HttpSession to the servlet) in the ServletContext.
In the next request when I try to access this object after retrieving it from the 
context, tomcat has already called the method recycle() on the facade object and the 
HttpSession reference inside the class HttpSessionFacade is null and I end up with 
NullPointerException. 

= 8<= EXCEPTION THROWN 8< =

java.lang.NullPointerException
 at
org.apache.tomcat.facade.HttpSessionFacade.invalidate(HttpSessionFacade.java
:136)
 at TestSessionBehaviour.doPost(TestSessionBehaviour.java:33)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
 at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
 at org.apache.tomcat.core.Handler.service(Handler.java:286)
 at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
 at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79
7)
 at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
 at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC
onnectionHandler.java:210)
 at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
 at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
 at java.lang.Thread.run(Thread.java:484)


Title: 
BugRat Report #
739





BugRat Report #
739




Project:
Tomcat


Release:
3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
Gokul Singh ( [EMAIL PROTECTED] )

Date Submitted:
Jan 11 2001, 06:11:18 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

Problem when I try to store a referance to the session in the context and then when I try to access it in the next request I get NullPointerException


 Environment: (jvm, os, osrel, platform)

java version "1.3.0_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_01) Java HotSpot(TM) Client VM (build 1.3.0_01, mixed mode), Windows 95, 4.00.095 B, x86



Additional Environment Description:





Report Description:

The same code works just fine on tomcat 3.1.1.

The problem to me appears to be due the fact that I save a referance to the HttpSessionFacade ( HttpSession to the servlet) in the ServletContext.
In the next request when I try to access this object after retrieving it from the context, tomcat has already called the method recycle() on the facade object and the HttpSession reference inside the class HttpSessionFacade is null and I end up with NullPointerException. 

= 8<= EXCEPTION THROWN 8< =

java.lang.NullPointerException
 at
org.apache.tomcat.facade.HttpSessionFacade.invalidate(HttpSessionFacade.java
:136)
 at TestSessionBehaviour.doPost(TestSessionBehaviour.java:33)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
 at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
 at org.apache.tomcat.core.Handler.service(Handler.java:286)
 at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
 at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79
7)
 at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
 at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC
onnectionHandler.java:210)
 at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
 at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
 at java.lang.Thread.run(Thread.java:484)




How To Reproduce:

null



Workaround:

null



View this report online...






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Question regarding org.apache.jasper.runtime.BodyContentImpl

2001-01-11 Thread Christopher Kirk



BodyContentImpl does not override javax.servlet.jsp.BodyContent.flush();

The implementation of BodyContent.flush is:

public void flush() throws IOException {
  throw new IOException("Illegal to flush within a custom tag");
}



My question is why. Is it an over sight that BodyContentImpl does not
override this behaviour or is it really illegal to flush from within
a custom tag; and if it is illegal then where in the JSP1.1 spec is
this stated?


Thanx,

- Chris.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: possible problems in org.apache.catalina.connector.http.SocketInputStream

2001-01-11 Thread Thomas Butter


Remy Maucherat wrote:

> 
> I can't see why. Is my interpretation on what will happen at the next
> iteration wrong ?
> 
You are perfectly right. Sorry, I misunderstood the loop (didn't realize 
the pos=0 after the read()).

A problem could only arrise if somewhere else a mark is set before your 
functions, then pos=0 would set the wrong position. But marks are not 
used anywhere so this won't be a problem.

> 
> Especially since we don't care about marking here.

I attached a little patch that reimplements the used methods of the BIS. 
It should be a little bit faster because it doesn't implement marks.
Not sure if it is worth the extra code because read() isn't called very 
often anyway and if read(byte []) is used anywhere then it should be 
rewritten too (didn't do it here because I wasn't sure if it is ever used).

-- 
Thomas Butter <[EMAIL PROTECTED]>  ICQ: 891617

"Unix IS user friendly, it is just selective about who his friends are."



--- SocketInputStream.java.orig Thu Jan 11 09:18:45 2001
+++ SocketInputStream.java  Thu Jan 11 10:14:41 2001
@@ -65,7 +65,7 @@
 package org.apache.catalina.connector.http;
 
 import java.io.IOException;
-import java.io.BufferedInputStream;
+import java.io.FilterInputStream;
 import java.io.InputStream;
 import java.io.EOFException;
 import org.apache.catalina.util.StringManager;
@@ -76,7 +76,7 @@
  *
  * @author mailto:[EMAIL PROTECTED]">Remy Maucherat
  */
-public class SocketInputStream extends BufferedInputStream {
+public class SocketInputStream extends FilterInputStream {
 
 
 // -- Constants
@@ -112,8 +112,54 @@
 private static final int LC_OFFSET = 'A' - 'a';
 
 
-// --- Constructors
+// BufferInputStream rewrite without marks
 
+private byte buf[];
+private int count=0;
+private int pos=0;
+
+public void close() throws IOException {
+   if(in!=null) in.close();
+   in=null;
+   buf=null;
+}
+
+public synchronized int available() throws IOException {
+   if(in==null)
+   throw (new IOException("Stream was closed"));
+   return (count-pos)+in.available();
+}
+
+public synchronized int read()
+   throws IOException
+{
+   if(in==null)
+   throw (new IOException("Stream was closed"));
+   if(pos>=count) {
+   pos=0;
+   count=in.read(buf);
+   if(count<=0) return -1;
+   }
+
+   return buf[pos++] & 0xff;
+}
+
+public synchronized long skip(long n) throws IOException {
+   if(in==null)
+   throw (new IOException("Stream was closed"));
+   long skipped=0;
+if(n<=0) return 0;
+   if(n>count-pos) {
+   skipped=count-pos;
+   n-=skipped;
+   pos=count;
+   skipped+=in.skip(n);
+   } else {
+   skipped=n;
+   count+=n;
+   }
+   return skipped;
+}  
 
 /**
  * Construct a servlet input stream associated with the specified socket
@@ -123,9 +169,9 @@
  * @param bufferSize size of the internal buffer
  */
 public SocketInputStream(InputStream is, int bufferSize) {
-
-   super(is, bufferSize);
-
+   super(is);
+if(bufferSize<=0) bufferSize=1024; // switch back to default
+buf=new byte[bufferSize];
 }
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

mod_webapp and cookies