cvs commit: jakarta-tomcat-connectors/jk/native/jni Makefile.in

2001-10-26 Thread costin

costin  01/10/25 15:32:19

  Modified:jk/native/jni Makefile.in
  Log:
  Ok, I HATE libtool...
  
  I think now it's better, still no idea why -rpath is so important or why
  --mode=install is needed..
  
  Revision  ChangesPath
  1.2   +5 -4  jakarta-tomcat-connectors/jk/native/jni/Makefile.in
  
  Index: Makefile.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/jni/Makefile.in,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Makefile.in   2001/10/25 20:10:39 1.1
  +++ Makefile.in   2001/10/25 22:32:19 1.2
  @@ -12,11 +12,12 @@
   
   all: jni_connect.so
   
  -jni_connect.la: ${JNI_OBJECTS}
  - $(LIBTOOL) --mode=link $(COMPILE) -o $@ -module  -export-dynamic 
-avoid-version ${JNI_OBJECTS} 
  +jk_jnicb.la: ${JNI_OBJECTS}
  + touch jk_jnicb.slo
  + $(LIBTOOL) --mode=link $(COMPILE) -module -o $@ -rpath `pwd` -g -O2 
-avoid-version ${JNI_OBJECTS} 
   
  -jni_connect.so: jni_connect.la
  - cp $ $@ 
  +jni_connect.so: jk_jnicb.la
  + $(LIBTOOL) --mode=install cp $ `pwd`/jni_connect.so
   
   install:
   
  
  
  



Re: Getting HttpRequest inside Realm/Tomcat 4

2001-10-26 Thread Craig R. McClanahan



On Thu, 25 Oct 2001, Antony Bowesman wrote:

 Date: Thu, 25 Oct 2001 14:12:36 +0300
 From: Antony Bowesman [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: Getting HttpRequest inside Realm/Tomcat 4

 Hi Craig,

 Thanks for your comments again.

  You're right ... there is nothing there to do this.  The original
  design was based on the idea that Realm simply encapsulates a
  service that authenticates a user, given a username and some
  credentials.  In addition, it needs to work even when HTTP sessions
  are not in use (for example, for BASIC authentication).
 
  One strategy for dealing with this might be to register a session
  event listener and registers your session in the sessionCreated()
  event handler.

 I like the realm and general design in TC4, it's much better and cleaner
 than 3.2.  However, I think there is something missing in the realm
 interface authenticate methods, particulary for form login:-

 If you modify a login form to include a field other than j_username and
 j_password so the user can select some kind of 'post login preferences'
 it is not possible to get this extra field to the realm.


The mechanics of form-based login was the subject of no little amount of
discussion in the JSR-053 expert group during the development of Servlet
2.3.  The idea of supporting additional fields was discussed somewhat, but
in the end we decided to punt on making any big-time changes, because it
became obvious that this problem has a larger scope than just logging
users in to a web application.

One of the outgrowths of that realization is another JSR that you might
want to keep track of (via http://www.jcp.org:

  JSR #115 -- Java(tm) Authorization Service Provider
  Contract for Containers

Once this is fleshed out, Tomcat can be modified to support the new
SPI contracts, and your Realm-equivalent implementation will itself be
portable to different containers if it conforms.  Until then, though, I'm
a little gunshy about mucking around with the Realm interface.

 We use JAAS for authentication.  JAAS allows  and one of the login
 modules authenticates against our EJB user repository and loads user
 preferences (groups/roles etc) and one feature the user can select is
 their preferred role set for the session.

 I don't think the event listener will work for our use, following login,
 so it seems the following is how I can achieve what I want.

 Replace the org.apache.catalina.authenticator.FormAuthenticator with my
 own FormAuthenticator class by modifying the Authenticators.properties
 and extend the realm interface to pass either a map of http request
 parameters, or in fact the http request itself.  My realm can do what it
 wants.


That seems like a reasonable strategy.

 What about passing the Request object as a parameter to the Realm
 interface authenticate() methods for 4.1 release.

 And how about having only a JAAS realm in standard tomcat and just
 provide different login modules for jdbc/jndi/other access.

 JAAS would of course tie Tomcat to JDK1.3+, is there a minimum for
 Tomcat 4?


The current supported minimum is JDK 1.2.2.  And, I thought JAAS required
1.4 -- am I mis-remembering?

 BTW, I saw you offered your BOF slides to someone, are they available?


I assume you mean my BOF on container-managed security, right?  Forwarded
under separate cover.

 Rgds
 Antony


Craig





cvs commit: jakarta-tomcat-connectors/jk/native/jni Makefile.in

2001-10-26 Thread costin

costin  01/10/25 16:42:06

  Modified:jk/native/apache-2.0 Makefile.in
   jk/native/jni Makefile.in
  Log:
  - Regenerate Makefile automatically
  - Link with the objects in the build directory
  
  Revision  ChangesPath
  1.10  +11 -5 jakarta-tomcat-connectors/jk/native/apache-2.0/Makefile.in
  
  Index: Makefile.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/Makefile.in,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- Makefile.in   2001/10/25 20:14:18 1.9
  +++ Makefile.in   2001/10/25 23:42:06 1.10
  @@ -19,12 +19,18 @@
   include ../scripts/build/rules.mk
   #include ${APACHE_DIR}/build/config_vars.mk
   
  +LOCAL_OBJECTS=$(subst ../common/,,$(APACHE_OBJECTS))
  +
   # OEXT=@APACHE20_OEXT@
   OEXT=.lo
   
  -all: @LIB_JK_TYPE@
  +all: Makefile @LIB_JK_TYPE@ 
   install: @INSTALL_TYPE@
   
  +Makefile: Makefile.in
  + echo Regenerating Makefile
  + ( cd ..; ./config.status )
  +
   lib_jk.la: mod_jk.lo
$(LIBTOOL) --mode=link $(CC) -o lib_jk.la -static -rpath 
${APACHE_DIR}/modules/jk mod_jk.lo $(APACHE_OBJECTS)
   
  @@ -46,13 +52,13 @@
    Dynamic .so file 
   # APXS will compile every file, this is derived from apxs
   
  -mod_jk.la: mod_jk.lo $(APACHE_OBJECTS)
  - $(LIBTOOL) --mode=link ${COMPILE} -o $@ -module -avoid-version $ 
  +mod_jk.la: mod_jk.lo $(LOCAL_OBJECTS)
  + $(LIBTOOL) --mode=link ${COMPILE} -o $@ -module -rpath `pwd` -avoid-version 
mod_jk.lo $(LOCAL_OBJECTS)
   
   #$(APXS) ${JK_INCL} ${JAVA_INCL} -c -o mod_jk.la mod_jk.c $(APACHE_OBJECTS)
   
   mod_jk.so: mod_jk.la
  - cp $ $@
  + $(LIBTOOL) --mode=install cp $ `pwd`/$@
   
   install_dynamic:
@echo 
  @@ -63,6 +69,6 @@
@echo 
   
   clean:
  - (cd ../common  $(MAKE) clean)
  +#(cd ../common  $(MAKE) clean)
rm -f *.o *.so *.lo *.la *.slo
rm -rf .libs
  
  
  
  1.3   +9 -5  jakarta-tomcat-connectors/jk/native/jni/Makefile.in
  
  Index: Makefile.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/jni/Makefile.in,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Makefile.in   2001/10/25 22:32:19 1.2
  +++ Makefile.in   2001/10/25 23:42:06 1.3
  @@ -1,19 +1,23 @@
   OEXT=.lo
   
  -JNI_OBJECTS=jk_jnicb${OEXT} ../common/jk_map${OEXT} ../common/jk_util${OEXT} \
  -  ../common/jk_pool${OEXT}
  +COMMON_OBJECTS=jk_map${OEXT} jk_util${OEXT} jk_pool${OEXT}
  +JNI_OBJECTS=jk_jnicb${OEXT} ${COMMON_OBJECTS}
   
  +
   JAVA_INCL=-I @JAVA_HOME@/include -I @JAVA_HOME@/include/@OS@ -I../common
   CFLAGS=@apache_include@ @CFLAGS@ ${JAVA_INCL} -D_REENTRANT -Wall
   
   include ../scripts/build/rules.mk
   
   JK=.
  +
  +all: Makefile jni_connect.so 
   
  -all: jni_connect.so
  +Makefile: Makefile.in
  + echo Regenerating Makefile
  + ( cd ..; ./config.status )
   
   jk_jnicb.la: ${JNI_OBJECTS}
  - touch jk_jnicb.slo
$(LIBTOOL) --mode=link $(COMPILE) -module -o $@ -rpath `pwd` -g -O2 
-avoid-version ${JNI_OBJECTS} 
   
   jni_connect.so: jk_jnicb.la
  @@ -22,4 +26,4 @@
   install:
   
   clean:
  - rm -f *.o *.slo *.lo *.so *.la
  + rm -f *.o *.slo *.lo *.so *.la .libs/*
  
  
  



cvs commit: jakarta-tomcat-connectors/jk/jkant - New directory

2001-10-26 Thread costin

costin  01/10/25 16:46:10

  jakarta-tomcat-connectors/jk/jkant - New directory



cvs commit: jakarta-tomcat-connectors/jk/jkant/java - New directory

2001-10-26 Thread costin

costin  01/10/25 16:46:22

  jakarta-tomcat-connectors/jk/jkant/java - New directory



cvs commit: jakarta-tomcat-connectors/jk/jkant/java/org - New directory

2001-10-26 Thread costin

costin  01/10/25 16:46:25

  jakarta-tomcat-connectors/jk/jkant/java/org - New directory



cvs commit: jakarta-tomcat-connectors/jk/jkant/java/org/apache - New directory

2001-10-26 Thread costin

costin  01/10/25 16:46:27

  jakarta-tomcat-connectors/jk/jkant/java/org/apache - New directory



cvs commit: jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk/ant - New directory

2001-10-26 Thread costin

costin  01/10/25 16:46:32

  jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk/ant - New directory



cvs commit: jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk/ant ApxsTask.java SoTask.java

2001-10-26 Thread costin

costin  01/10/25 16:48:00

  Added:   jk/jkant ant.tasks
   jk/jkant/java/org/apache/jk/ant ApxsTask.java SoTask.java
  Log:
  Experimental code. Not working ( and will take some time to get it working ).
  
  Ant tasks to do things equivalent with apxs and libtool ( wrappers for start,
  decent code later ).
  
  If you hate libtool please help :-)
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-connectors/jk/jkant/ant.tasks
  
  Index: ant.tasks
  ===
  apxs=org.apache.jk.ApxsTask
  
  
  1.1  
jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk/ant/ApxsTask.java
  
  Index: ApxsTask.java
  ===
  /*
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/).
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names The Jakarta Project, Ant, and Apache Software
   *Foundation must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called Apache
   *nor may Apache appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * http://www.apache.org/.
   */
  
  package org.apache.jk.ant;
  
  import org.apache.tools.ant.types.*;
  import org.apache.tools.ant.util.*;
  import org.apache.tools.ant.taskdefs.*;
  import org.apache.tools.ant.*;
  
  import java.io.*;
  
  /**
   * Task to compile Apache modules, using Apxs.
   * 
   * arguments:
   * ul
   * lisource
   * /ul
   *
   * p
   * When this task executes, it will recursively scan the sourcedir and
   * destdir looking for Java source files to compile. This task makes its
   * compile decision based on timestamp.
   *
   * @author Costin Manolache
   */
  public class ApxsTask extends Task {
  String apxs;
  Path src;
  Path include;
  Path libs;
  String module;
  
  public ApxsTask() {};
  
  /**
   *  Path to Apxs executable. Defaults to apxs using the current PATH.
   */
  public void setPath( String path ) {
this.apxs=path;
  }
  
  /**
   * Source files ( .c )
   *
   * @return a nexted src element.
   */
  public Path createSrc() {
  if (src == null) {
  src = new Path(project);
  }
  return src.createPath();
  }
  
  /**
   * Include files
   */
  public Path createInclude() {
  if (include == null) {
  include = new Path(project);
  }
  return include.createPath();
  }
  
  /**
   * Libraries ( .so or .dll ) files to link to.
   */
  public Path createLib() {
  if (libs == null) {
  libs = new 

RE: Filters on error/index pages

2001-10-26 Thread Craig R. McClanahan



On Thu, 25 Oct 2001, Deacon Marcus wrote:

 Date: Thu, 25 Oct 2001 14:08:36 +0200
 From: Deacon Marcus [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: RE: Filters on error/index pages

 Hi,

  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
  Behalf Of Craig R. McClanahan
  Sent: Thursday, October 25, 2001 12:26 AM
  To: [EMAIL PROTECTED]
  Subject: Re: Filters on error/index pages
 
 
 
 
  On Wed, 24 Oct 2001, Deacon Marcus wrote:
 
   Date: Wed, 24 Oct 2001 16:20:11 +0200
   From: Deacon Marcus [EMAIL PROTECTED]
   Reply-To: [EMAIL PROTECTED]
   To: [EMAIL PROTECTED]
   Subject: Filters on error/index pages
  
   Hi,
   Are Filters applied to index (default in folder) or error pages? I'm not
   100% positive from the documentation. Sorry if it's basic or
  obvious when
   looking at source, but I'm recovering from caffeine overdose
  (my doc says
   half of what I took should be enough to kill me ;/ ) and have killer
   headaches so my iq and concentration ability are at 25% normal, and my
   deadlines are near :(
  
   Thanks in advance, greetings, deacon Marcus
  
  
 
  The basic rule is that Filters are applied *only* on the originally
  requested URL from the client.  In practice, that means the following:
  - Request to a servlet or JSP page - yes
  - Static resources in the webapp - yes (*)
  - RequestDispatcher.include() - no
  - RequestDispatcher.forward() - no

 BTW, is there any way to simulate filtered RD.i and RD.f? That should be
 possible with a help of brigde servlet having access to Tomcat's
 configuration data, right? Could you give me some clues where to start?


In order to do this transparently to the servlet that is using the
RequestDispatcher, you would have to actually modify Tomcat internals to
change the implementation object returned when the servlet calls
ServletContext.getRequestDispatcher() and
ServletContext.getNamedDispatcher().  As a starting point, you would be
wanting to subclass the following classes:

* org.apache.catalina.core.StandardContext - The basic representation
  of a web application.  Modify the getServletContext() method to
  return your subclass of ApplicationContext.

* org.apache.catalina.core.ApplicationContext - Modify the implementation
  of getRequestDispatcher() and getNamedDispatcher() to return your
  subclass of ApplicationDispatcher.

* org.apache.catalina.core.ApplicationDispatcher - Change the processing
  in the invoke() method to construct a filter chain and use it.  You
  could use the code in StandardWrapperValve (which is used for the actual
  requests) as a model.

Of course, all of this would tie you now and forever more to this
architecture.  I would suggest you consider architecting your application
to conform to the standard, rather than modifying your container to
conform to your architecture.

 Is there any possibility for a webapp to get acces to Tomcat's classes? From
 what I thought, it would be easy to do providing custom valve saving
 reference to it's context in ServletContext's attribute, but maybe there's
 some more direct way?


Classes loaded from the Catalina class loader are not visible to web
applications.  Further, the webapp class loader disallows any attempt to
load an org.apache.catalina.* class from itself.  So, even if you created
a Valve as you describe and created a servlet context attribute, the web
app would still throw a ClassNotFoundException when it tried to access the
attribute.

The *only* way to have a servlet able to reference Catalina internal
classes is to make it an implementation of ContainerServlet (as the
servlets for the Manager and Invoker features are), and loaded from the
Catalina class loader (i.e. stored in server/classes or server/lib).

  - Error page - no

 That hurts. Any possible workaround? Where are error pages (I need 404 only)
 handled? Maybe that one should be changed and/or configurable in server.xml?


As of Tomcat 4.0.1, error pages are handled in
org.apache.catalina.valves.ErrorDispatcherValve, which is attached at the
Host level.

 Is there anything I can do for now besides duplicating filtering logic
 directly in my 404?

 
  (*) In a web-connected environment, you must ensure that your
  configuration respects this requirement.  The mod_webapp
  connector understands it already, but mod_jk must be explicitly
  configured to forward requests for static resources that must
  be filtered.

 That's no problem since I use stand-alone mode only.

  Craig

 Greetings, deacon Marcus



Craig





cvs commit: jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk - New directory

2001-10-26 Thread costin

costin  01/10/25 16:46:30

  jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk - New directory



DO NOT REPLY [Bug 4418] - Race Condition in net.serversocketfactory.java

2001-10-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4418.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Race Condition in net.serversocketfactory.java





--- Additional Comments From [EMAIL PROTECTED]  2001-10-25 18:09 ---
This is the double-check lock idiom, which is fatally flawed. 

q.v. : 
The Double-Checked Locking is Broken Declaration 
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Can double-checked locking be fixed? 
No matter how you rig it, double-checked locking still fails 
http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html

theFactory should be initialized as a static, that is

private static ServerSocketFactory theFactory = new ServerSocketFactory();

either that, or the getDefault() method must be synchronised.



DO NOT REPLY [Bug 4436] New: - DecodeInterceptor writes to log on every call.

2001-10-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4436.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

DecodeInterceptor writes to log on every call.

   Summary: DecodeInterceptor writes to log on every call.
   Product: Tomcat 3
   Version: 3.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Encoding
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


DecodeInterceptor writes to log on every call.  It should only write to the log 
if debug  0.  This unneccesarily fills up the log very quickly.  The 
workaround is to disable it which does not make sense.



cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans - New directory

2001-10-26 Thread craigmcc

craigmcc01/10/25 18:59:36

  jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans - New directory



Transfer data between portlets

2001-10-26 Thread tuandang

Hi
How can I transfer data from one portlet to another ? Is there any mechanism
to perform that ? I shall be happy to share my idea with you.
Thank in advance.
Dang Tuan
mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4362] - Cannot read init-params from within a JSP

2001-10-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4362.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Cannot read init-params from within a JSP





--- Additional Comments From [EMAIL PROTECTED]  2001-10-26 02:04 ---
OK, that works. Nevertheless it seems pretty strange to me that any JSP should 
be able to read internal initialization parameters...



Re: Getting HttpRequest inside Realm/Tomcat 4

2001-10-26 Thread Antony Bowesman

Craig,

 One of the outgrowths of that realization is another JSR that you
 might want to keep track of (via http://www.jcp.org:
 
   JSR #115 -- Java(tm) Authorization Service Provider
   Contract for Containers
 
 Once this is fleshed out, Tomcat can be modified to support the new
 SPI contracts, and your Realm-equivalent implementation will itself
 be portable to different containers if it conforms.  Until then,
 though, I'm a little gunshy about mucking around with the Realm 
 interface.

Yes, I had seen this, essentially, it looks to standardise what we are
already using, i.e. a JAAS subject wrapped inside the authenticated
container principal and each of the JAAS principals represents a role
(or something else) with associated permissions.  J2EE roles and
application roles are both supported.  This allows us to use principal
based access control.  Also with the configurable rolemapper class we
can effectively delegate as many access control decisions as we like.

 That seems like a reasonable strategy.

Well, it's done now :).  Is there any likelihood of these
interfaces/classes changing.  I've changed Realm, RealmBase and made my
own FormAuthenticator.  Are there any changes planed to these realm
parts?

  JAAS would of course tie Tomcat to JDK1.3+, is there a minimum for
  Tomcat 4?
 
 
 The current supported minimum is JDK 1.2.2.  And, I thought JAAS
 required 1.4 -- am I mis-remembering?

JAAS 1.0 was introduced as an extension to JDK1.3 but incorporated into
1.4 with some minor changes.

I'm glad to see that JAAS is now adopted as a requirement in J2EE 1.3
spec, although it only mandates version 1.0 of JAAS.

What is the roadmap for Tomcat to confirm to J2EE 1.3, presumably that
means some kind of JAAS support required (why not start now!!)

 I assume you mean my BOF on container-managed security, right? 
 Forwarded under separate cover.

Received. Many thanks.
Antony



RE: Filters on error/index pages

2001-10-26 Thread Deacon Marcus

Thanks,

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
 Behalf Of Craig R. McClanahan
 Sent: Friday, October 26, 2001 1:58 AM
 To: [EMAIL PROTECTED]
 Subject: RE: Filters on error/index pages




 On Thu, 25 Oct 2001, Deacon Marcus wrote:

  Date: Thu, 25 Oct 2001 14:08:36 +0200
  From: Deacon Marcus [EMAIL PROTECTED]
  Reply-To: [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Subject: RE: Filters on error/index pages
 
  Hi,
 
   -Original Message-
   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
   Behalf Of Craig R. McClanahan
   Sent: Thursday, October 25, 2001 12:26 AM
   To: [EMAIL PROTECTED]
   Subject: Re: Filters on error/index pages
  
  
  
  
   On Wed, 24 Oct 2001, Deacon Marcus wrote:
  
Date: Wed, 24 Oct 2001 16:20:11 +0200
From: Deacon Marcus [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Filters on error/index pages
   
Hi,
Are Filters applied to index (default in folder) or error
 pages? I'm not
100% positive from the documentation. Sorry if it's basic or
   obvious when
looking at source, but I'm recovering from caffeine overdose
   (my doc says
half of what I took should be enough to kill me ;/ ) and have killer
headaches so my iq and concentration ability are at 25%
 normal, and my
deadlines are near :(
   
Thanks in advance, greetings, deacon Marcus
   
   
  
   The basic rule is that Filters are applied *only* on the originally
   requested URL from the client.  In practice, that means the following:
   - Request to a servlet or JSP page - yes
   - Static resources in the webapp - yes (*)
   - RequestDispatcher.include() - no
   - RequestDispatcher.forward() - no
 
  BTW, is there any way to simulate filtered RD.i and RD.f? That should be
  possible with a help of brigde servlet having access to Tomcat's
  configuration data, right? Could you give me some clues where to start?
 

 In order to do this transparently to the servlet that is using the
 RequestDispatcher, you would have to actually modify Tomcat internals to
 change the implementation object returned when the servlet calls
 ServletContext.getRequestDispatcher() and
 ServletContext.getNamedDispatcher().  As a starting point, you would be
 wanting to subclass the following classes:

 * org.apache.catalina.core.StandardContext - The basic representation
   of a web application.  Modify the getServletContext() method to
   return your subclass of ApplicationContext.

 * org.apache.catalina.core.ApplicationContext - Modify the implementation
   of getRequestDispatcher() and getNamedDispatcher() to return your
   subclass of ApplicationDispatcher.

 * org.apache.catalina.core.ApplicationDispatcher - Change the processing
   in the invoke() method to construct a filter chain and use it.  You
   could use the code in StandardWrapperValve (which is used for the actual
   requests) as a model.

 Of course, all of this would tie you now and forever more to this
 architecture.  I would suggest you consider architecting your application
 to conform to the standard, rather than modifying your container to
 conform to your architecture.

I know all pros and cons, I'm generally not aganist vendor-lock-in as long
as it's not Microsoft or similar. I have nothing aganist vendor-lock-in when
it comes to a high quality product which itself is portable.

  Is there any possibility for a webapp to get acces to Tomcat's
 classes? From
  what I thought, it would be easy to do providing custom valve saving
  reference to it's context in ServletContext's attribute, but
 maybe there's
  some more direct way?
 

 Classes loaded from the Catalina class loader are not visible to web
 applications.  Further, the webapp class loader disallows any attempt to
 load an org.apache.catalina.* class from itself.  So, even if you created
 a Valve as you describe and created a servlet context attribute, the web
 app would still throw a ClassNotFoundException when it tried to access the
 attribute.

That what I not like in multiple classloaders...
So, basically if I want/need to write something which has its hands in
Tomcat's guts I need to make it part of custom Tomcat compilation?

What's the policy on distributing such modified versions as a part of a
out-of-box-workable webapps etc?

 The *only* way to have a servlet able to reference Catalina internal
 classes is to make it an implementation of ContainerServlet (as the
 servlets for the Manager and Invoker features are), and loaded from the
 Catalina class loader (i.e. stored in server/classes or server/lib).

   - Error page - no
 
  That hurts. Any possible workaround? Where are error pages (I
 need 404 only)
  handled? Maybe that one should be changed and/or configurable
 in server.xml?
 

 As of Tomcat 4.0.1, error pages are handled in
 org.apache.catalina.valves.ErrorDispatcherValve, which is attached at the
 Host level.

  Is there anything I can do for now besides 

cvs commit: jakarta-tomcat build.xml

2001-10-26 Thread marcsaeg

marcsaeg01/10/26 06:59:04

  Modified:.Tag: tomcat_32 build.xml
  Log:
  Changes to support building with different JAXP versions and parsers.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.53.2.8  +7 -6  jakarta-tomcat/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/build.xml,v
  retrieving revision 1.53.2.7
  retrieving revision 1.53.2.8
  diff -u -r1.53.2.7 -r1.53.2.8
  --- build.xml 2001/07/17 14:25:27 1.53.2.7
  +++ build.xml 2001/10/26 13:59:03 1.53.2.8
  @@ -5,7 +5,8 @@
 property name=ant.home value=../jakarta-ant/
 property name=debug value=on/
 property name=j2ee.home value=../../j2ee/build/unix/
  -  property name=jaxp value=../jaxp-1.0.1 /
  +  property name=jaxp value=../jaxp-1.1/jaxp.jar /
  +  property name=parser value=../jaxp-1.1/crimson.jar /
 property name=optimize value=true /
 property name=servlet.jar value=../jakarta-servletapi/lib/servlet.jar/
 property name=tomcat.build value=../build/tomcat/
  @@ -54,10 +55,10 @@
   file=${ant.home}/lib/ant.jar/
   copy tofile=${tomcat.build}/lib/servlet.jar
   file=${servlet.jar}/
  -copy tofile=${tomcat.build}/lib/jaxp.jar
  -file=${jaxp}/jaxp.jar/
  -copy tofile=${tomcat.build}/lib/parser.jar
  -file=${jaxp}/parser.jar/
  +copy todir=${tomcat.build}/lib
  +file=${jaxp}/
  +copy todir=${tomcat.build}/lib
  +file=${parser}/
   
   !-- Copy golden files for the tests webapp --
   copy todir=${tomcat.build}/lib/test/Golden
  @@ -89,7 +90,7 @@
   
   !-- Compile the standard Tomcat components --
   javac srcdir=src/share destdir=${tomcat.build}/classes
  -   classpath=${servlet.jar};${jaxp}/jaxp.jar 
  +   classpath=${servlet.jar};${jaxp};${parser} 
  debug=${debug} 
  optimize=${optimize}
  deprecation=off 
  
  
  



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

2001-10-26 Thread marcsaeg

marcsaeg01/10/26 07:01:10

  Modified:src/etc  Tag: tomcat_32 server.xml
  Log:
  Adds Jdk12Interceptor.  It is currently commented out.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.29.2.12 +7 -1  jakarta-tomcat/src/etc/server.xml
  
  Index: server.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/etc/server.xml,v
  retrieving revision 1.29.2.11
  retrieving revision 1.29.2.12
  diff -u -r1.29.2.11 -r1.29.2.12
  --- server.xml2001/07/15 23:09:31 1.29.2.11
  +++ server.xml2001/10/26 14:01:10 1.29.2.12
  @@ -125,7 +125,13 @@
   ContextInterceptor 
   className=org.apache.tomcat.context.WorkDirInterceptor /
   
  -!-- Request processing --
  + !--  Uncomment if you are using JDK1.2 or higher.  
  +  Insures proper thread context class loader is in effect for servlet 
execution
  + ContextInterceptor 
  +className=org.apache.tomcat.request.Jdk12Interceptor /
  + --
  +
  + !-- Request processing --
   !-- Session interceptor will extract the session id from cookies and 
deal with URL rewriting ( by fixing the URL ).  If you wish to
suppress the use of cookies for session identifiers, change the
  
  
  



cvs commit: jakarta-tomcat-connectors/jk/native/common jk_global.h

2001-10-26 Thread hgomez

hgomez  01/10/26 07:02:18

  Modified:jk/native/common jk_global.h
  Log:
  Oups a missing comment...
  
  Revision  ChangesPath
  1.11  +2 -2  jakarta-tomcat-connectors/jk/native/common/jk_global.h
  
  Index: jk_global.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_global.h,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- jk_global.h   2001/10/26 13:55:53 1.10
  +++ jk_global.h   2001/10/26 14:02:18 1.11
  @@ -59,7 +59,7 @@
* Description: Global definitions and include files that should exist *
*  anywhere   *
* Author:  Gal Shachor [EMAIL PROTECTED]   *
  - * Version: $Revision: 1.10 $   *
  + * Version: $Revision: 1.11 $   *
***/
   
   #ifndef JK_GLOBAL_H
  @@ -182,7 +182,7 @@
   
   #else /* CHARSET_EBCDIC */
   
  -/* We're in on an ASCII system
  +/* We're in on an ASCII system */
   
   #define jk_xlate_to_ascii(b, l) /* NOOP */
   #define jk_xlate_from_ascii(b, l)   /* NOOP */
  
  
  



DO NOT REPLY [Bug 4450] New: - Warn if incorrect DTD referenced

2001-10-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4450.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Warn if incorrect DTD referenced

   Summary: Warn if incorrect DTD referenced
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Specifying an incorrect DTD in the webapp descriptor file (WEB-INF/web.xml) 
doesn't seem to affect the use of the webapp. A good example of an incorrect 
DTD is:

!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
http://java.sun.com/j2ee/dtds/web-app_2_3.dtd;

Other JSP 1.2 servers refuse to startup webapps that don't specify the DTD as:

!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
http://java.sun.com/dtd/web-app_2_3.dtd;

This isn't a big issue, but can cause confusion when porting from Tomcat to 
other servers. Is it possible that a warning could be displayed in the console 
when an incorrect DTD is referenced? This would be similar to the way that 
errors in the web.xml file are shown.

Cheers
Simon



DO NOT REPLY [Bug 4418] - Race Condition in net.serversocketfactory.java

2001-10-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4418.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Race Condition in net.serversocketfactory.java

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-10-26 07:26 ---
Fixed for Tomcat 3.2.4 beta 1.  I synchronized the getDefaultFactory() method 
instead of using a static initializer so that derived classes to more easily 
change the default socket factory.



cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/net ServerSocketFactory.java

2001-10-26 Thread marcsaeg

marcsaeg01/10/26 07:18:01

  Modified:src/share/org/apache/tomcat/net Tag: tomcat_32
ServerSocketFactory.java
  Log:
  Fixed a race condition in getDefault().
  
  PR:  4418
  Submitted by: [EMAIL PROTECTED]
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.5.2.2   +8 -11 
jakarta-tomcat/src/share/org/apache/tomcat/net/Attic/ServerSocketFactory.java
  
  Index: ServerSocketFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/net/Attic/ServerSocketFactory.java,v
  retrieving revision 1.5.2.1
  retrieving revision 1.5.2.2
  diff -u -r1.5.2.1 -r1.5.2.2
  --- ServerSocketFactory.java  2000/10/04 20:23:50 1.5.2.1
  +++ ServerSocketFactory.java  2001/10/26 14:18:00 1.5.2.2
  @@ -122,22 +122,19 @@
   /**
* Returns a copy of the environment's default socket factory.
*/
  -public static ServerSocketFactory getDefault () {
  +public static synchronized ServerSocketFactory getDefault () {
   //
   // optimize typical case:  no synch needed
   //
   
   if (theFactory == null) {
  -synchronized (ServerSocketFactory.class) {
  -//
  -// Different implementations of this method could
  -// work rather differently.  For example, driving
  -// this from a system property, or using a different
  -// implementation than JavaSoft's.
  -//
  -
  -theFactory = new DefaultServerSocketFactory ();
  -}
  +//
  +// Different implementations of this method could
  +// work rather differently.  For example, driving
  +// this from a system property, or using a different
  +// implementation than JavaSoft's.
  +//
  +theFactory = new DefaultServerSocketFactory ();
   }
   
   try {
  
  
  



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

2001-10-26 Thread hgomez

hgomez  01/10/26 07:40:19

  Modified:jk/native/common jk_msg_buff.c
  Log:
  Next step on EBCDIC work
  
  Revision  ChangesPath
  1.7   +3 -2  jakarta-tomcat-connectors/jk/native/common/jk_msg_buff.c
  
  Index: jk_msg_buff.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_msg_buff.c,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- jk_msg_buff.c 2001/06/18 14:15:54 1.6
  +++ jk_msg_buff.c 2001/10/26 14:40:19 1.7
  @@ -60,7 +60,7 @@
* Author:  Costin [EMAIL PROTECTED]  *
* Author:  Gal Shachor [EMAIL PROTECTED]   *
* Author:  Henri Gomez [EMAIL PROTECTED]   *
  - * Version: $Revision: 1.6 $   *
  + * Version: $Revision: 1.7 $   *
***/
   
   #include jk_pool.h
  @@ -291,7 +291,8 @@
   jk_b_append_int(msg, (unsigned short )len);
   
   /* We checked for space !!  */
  -strncpy((char *)msg-buf + msg-len , param, len+1); /* including \0 */
  +strncpy((char *)msg-buf + msg-len , param, len+1);/* including \0 */
  +jk_xlate_to_ascii((char *)msg-buf + msg-len, len+1);  /* convert from EBCDIC 
if needed */
   msg-len += len + 1;
   
   return 0;
  
  
  



Tomcat 3.2.3 Documentation update request.

2001-10-26 Thread Prasanna Uppaladadium

Hello.

Could someone please update the Tomcat 3.2.3 documentation 
(http://jakarta.apache.org/tomcat/tomcat-3.2-doc/uguide/tomcat_ug.html)?

In the section on server.xml, the description for Connector in the table 
  in that section does not describe the inet option that can be used 
to make Tomcat 3.2.3 listen on a specific host interface. For example, 
the text can read as follows:

4. inet - The host interface (IP address or host name) on which to 
listen 
for connections.

The lack of this documentation has caused me a lot of grief for the last 
couple of days (until I was helped graciously in the user's mailing list).

Thanks much,
Prasanna.




DO NOT REPLY [Bug 4451] New: - Using ResourceBundle into a JSP doesn't work if .properties files is put into a subdirectory

2001-10-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4451.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Using ResourceBundle into a JSP doesn't work if .properties files is put into a 
subdirectory

   Summary: Using ResourceBundle into a JSP doesn't work if
.properties files is put into a subdirectory
   Product: Tomcat 3
   Version: 3.2.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am using a java.util.ResourceBundle into my JSP: java.util.ResourceBundle rb 
= java.util.ResourceBundle.getBundle(client);
If I put the client.properties file into the same directory as the JSP, 
everyting works fine. If I put the client.properties into a subdirectory (e.g. 
props/client.properties) and I change the constructor accordingly: 
java.util.ResourceBundle rb = java.util.ResourceBundle.getBundle
(props.client); I get the following error: javax.servlet.ServletException: 
Can't find bundle for base name props.client, locale it_IT.
The same directory structure works well with WebSphere v3.02.



IIS redirector green arrow but errors

2001-10-26 Thread Yeager, Jeffrey

I have installed so many versions so many times my head is spinning.  Each
time I get the same results.  I followed the instructions and
troubleshooting in the HowTo document.  I am left with no suggestions.

I installed various Tomcat versions (3.3, 3.3dev, 4.0) on a Win2000 box with
IIS 5.0.  I create the registry settings, the virtual directory, and the
filter.  The filter has a green arrow, so that is good.  Tomcat works if you
access it directly at port 8080.  However, trying to access Tomcat through
IIS always fails.  All log files are producing information.  Following the
troubleshooting section of the HowTo doc, I go all the way to the last
suggestion, saying to make certain I have execute rights in PWS, which I do.
Can anyone make sense of these log files and suggest something.  

Thanks

Steve Yeager
[EMAIL PROTECTED]

Windows error log:
13:55:14 127.0.0.1 GET /jakarta/isapi_redirect.dll 200

Tomcat error log:
[Thu Oct 25 08:55:08 2001]  [jk_isapi_plugin.c (555)]: HttpFilterProc
started
[Thu Oct 25 08:55:08 2001]  [jk_isapi_plugin.c (600)]: In HttpFilterProc
Virtual Host redirection of /localhost/examples/jsp/index.html
[Thu Oct 25 08:55:08 2001]  [jk_uri_worker_map.c (351)]: Into
jk_uri_worker_map_t::map_uri_to_worker
[Thu Oct 25 08:55:08 2001]  [jk_uri_worker_map.c (368)]: Attempting to map
URI '/localhost/examples/jsp/index.html'
[Thu Oct 25 08:55:08 2001]  [jk_uri_worker_map.c (456)]:
jk_uri_worker_map_t::map_uri_to_worker, done without a match
[Thu Oct 25 08:55:08 2001]  [jk_isapi_plugin.c (606)]: In HttpFilterProc
test Default redirection of /examples/jsp/index.html
[Thu Oct 25 08:55:08 2001]  [jk_uri_worker_map.c (351)]: Into
jk_uri_worker_map_t::map_uri_to_worker
[Thu Oct 25 08:55:08 2001]  [jk_uri_worker_map.c (368)]: Attempting to map
URI '/examples/jsp/index.html'
[Thu Oct 25 08:55:08 2001]  [jk_uri_worker_map.c (391)]:
jk_uri_worker_map_t::map_uri_to_worker, Found a context match ajp12 -
/examples/
[Thu Oct 25 08:55:08 2001]  [jk_isapi_plugin.c (617)]: HttpFilterProc
[/examples/jsp/index.html] is a servlet url - should redirect to ajp12
[Thu Oct 25 08:55:08 2001]  [jk_isapi_plugin.c (639)]: HttpFilterProc check
if [/examples/jsp/index.html] is points to the web-inf directory
[Thu Oct 25 08:55:08 2001]  [jk_isapi_plugin.c (555)]: HttpFilterProc
started
[Thu Oct 25 08:55:08 2001]  [jk_isapi_plugin.c (600)]: In HttpFilterProc
Virtual Host redirection of /localhost/jakarta/isapi_redirect.dll
[Thu Oct 25 08:55:08 2001]  [jk_uri_worker_map.c (351)]: Into
jk_uri_worker_map_t::map_uri_to_worker
[Thu Oct 25 08:55:08 2001]  [jk_uri_worker_map.c (368)]: Attempting to map
URI '/localhost/jakarta/isapi_redirect.dll'
[Thu Oct 25 08:55:08 2001]  [jk_uri_worker_map.c (456)]:
jk_uri_worker_map_t::map_uri_to_worker, done without a match
[Thu Oct 25 08:55:08 2001]  [jk_isapi_plugin.c (606)]: In HttpFilterProc
test Default redirection of /jakarta/isapi_redirect.dll
[Thu Oct 25 08:55:08 2001]  [jk_uri_worker_map.c (351)]: Into
jk_uri_worker_map_t::map_uri_to_worker
[Thu Oct 25 08:55:08 2001]  [jk_uri_worker_map.c (368)]: Attempting to map
URI '/jakarta/isapi_redirect.dll'
[Thu Oct 25 08:55:08 2001]  [jk_uri_worker_map.c (456)]:
jk_uri_worker_map_t::map_uri_to_worker, done without a match
[Thu Oct 25 08:55:08 2001]  [jk_isapi_plugin.c (630)]: HttpFilterProc
[/jakarta/isapi_redirect.dll] is not a servlet url
[Thu Oct 25 08:55:08 2001]  [jk_isapi_plugin.c (639)]: HttpFilterProc check
if [/jakarta/isapi_redirect.dll] is points to the web-inf directory
[Thu Oct 25 08:55:14 2001]  [jk_isapi_plugin.c (679)]: HttpExtensionProc
started
[Thu Oct 25 08:55:14 2001]  [jk_worker.c (123)]: Into wc_get_worker_for_name
ajp12
[Thu Oct 25 08:55:14 2001]  [jk_worker.c (127)]: wc_get_worker_for_name,
done  found a worker
[Thu Oct 25 08:55:14 2001]  [jk_isapi_plugin.c (701)]: HttpExtensionProc got
a worker for name ajp12
[Thu Oct 25 08:55:14 2001]  [jk_ajp12_worker.c (223)]: Into
jk_worker_t::get_endpoint
[Thu Oct 25 08:55:14 2001]  [jk_ajp12_worker.c (121)]: Into
jk_endpoint_t::service
[Thu Oct 25 08:55:14 2001]  [jk_connect.c (108)]: Into jk_open_socket
[Thu Oct 25 08:55:14 2001]  [jk_connect.c (115)]: jk_open_socket, try to
connect socket = 2236
[Thu Oct 25 08:55:14 2001]  [jk_connect.c (124)]: jk_open_socket, after
connect ret = 0
[Thu Oct 25 08:55:14 2001]  [jk_connect.c (132)]: jk_open_socket, set
TCP_NODELAY to on
[Thu Oct 25 08:55:14 2001]  [jk_connect.c (140)]: jk_open_socket, return, sd
= 2236
[Thu Oct 25 08:55:14 2001]  [jk_ajp12_worker.c (134)]: In
jk_endpoint_t::service, sd = 2236
[Thu Oct 25 08:55:14 2001]  [jk_ajp12_worker.c (357)]: Into
ajpv12_handle_request
[Thu Oct 25 08:55:14 2001]  [jk_ajp12_worker.c (361)]:
ajpv12_handle_request, sending the ajp12 start sequence
[Thu Oct 25 08:55:14 2001]  [jk_ajp12_worker.c (413)]:
ajpv12_handle_request, sending the headers
[Thu Oct 25 08:55:14 2001]  [jk_ajp12_worker.c (432)]:
ajpv12_handle_request, sending the terminating mark
[Thu Oct 25 08:55:14 2001]  

Re: jakarta-tomcat-4.0.1-src.tar.gz .gif corrupted

2001-10-26 Thread Pier Fumagalli

GOMEZ Henri at [EMAIL PROTECTED] wrote:

 Many .gif are corrupted in jakarta-tomcat-4.0.1-src.tar.gz.
 
 They are fine in binary jakarta-tomcat-4.0.1.tar.gz
 
 What about ?

Checked in as text from Windows? :)

Pier




DO NOT REPLY [Bug 4422] - Warp connector and non existing WebApps

2001-10-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4422.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Warp connector and non existing WebApps

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-10-26 08:19 ---
Indeed it is. The patch is good, and in CVS :)
Thanks to Brett Polivka [EMAIL PROTECTED]



DO NOT REPLY [Bug 4386] - webapp1.0 will not install on Redhat 7.1

2001-10-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4386.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

webapp1.0 will not install on Redhat 7.1

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||tomcat-
   ||[EMAIL PROTECTED]
 AssignedTo|tomcat- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |
 Status|REOPENED|NEW



DO NOT REPLY [Bug 4386] - webapp1.0 will not install on Redhat 7.1

2001-10-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4386.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

webapp1.0 will not install on Redhat 7.1

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



cvs commit: jakarta-tomcat-connectors/webapp/lib pr_warp_config.c

2001-10-26 Thread pier

pier01/10/26 08:18:33

  Modified:webapp/lib pr_warp_config.c
  Log:
  Bug # 4422:
  Thanks to Brett Polivka [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.7   +2 -1  jakarta-tomcat-connectors/webapp/lib/pr_warp_config.c
  
  Index: pr_warp_config.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/pr_warp_config.c,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- pr_warp_config.c  2001/08/09 20:04:31 1.6
  +++ pr_warp_config.c  2001/10/26 15:18:33 1.7
  @@ -54,7 +54,7 @@
*   *
* = */
   
  -/* @version $Id: pr_warp_config.c,v 1.6 2001/08/09 20:04:31 pier Exp $ */
  +/* @version $Id: pr_warp_config.c,v 1.7 2001/10/26 15:18:33 pier Exp $ */
   #include pr_warp.h
   
   wa_boolean c_check(wa_connection *conn, warp_packet *pack) {
  @@ -142,6 +142,7 @@
   }
   if (pack-type==TYPE_ERROR) {
   wa_log(WA_MARK,Cannot deploy application %s,appl-name);
  +elem=elem-next;
   continue;
   }
   if (pack-type!=TYPE_CONF_APPLIC) {
  
  
  



DO NOT REPLY [Bug 4430] - errors connected to using resources in a given WAR's WEB-INF/lib directory.

2001-10-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4430.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

errors connected to using resources in a given WAR's WEB-INF/lib directory.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]|tomcat-
   ||[EMAIL PROTECTED]
  Component|Errors  |Unknown
Product|BugZilla|Tomcat 3
Version|Current |Unknown



--- Additional Comments From [EMAIL PROTECTED]  2001-10-26 08:29 ---
Wrong component...



Testing new mailing list on nagoya.

2001-10-26 Thread Pier Fumagalli

Testing...


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




Re: Testing new mailing list on nagoya.

2001-10-26 Thread Pier Fumagalli

Ok, in theory, this should bounce back in a reasonable amount of time
Let's hope I'm right :) :) :)

Pier


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




Re: Testing new mailing list on nagoya.

2001-10-26 Thread Pier Fumagalli

Pier Fumagalli at [EMAIL PROTECTED] wrote:

 Ok, in theory, this should bounce back in a reasonable amount of time
 Let's hope I'm right :) :) :)

Yes... This is thru in few minutes.. The tomcat-dev mailing list is back
more-or-less to normal... Have fun (remember, there's a big backlog on
Daedalus ATM)

Pier


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




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

2001-10-26 Thread remm

remm01/10/26 10:17:08

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  - Cross context should default to false.
  
  Revision  ChangesPath
  1.84  +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.83
  retrieving revision 1.84
  diff -u -r1.83 -r1.84
  --- StandardContext.java  2001/10/13 01:38:46 1.83
  +++ StandardContext.java  2001/10/26 17:17:08 1.84
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.83 2001/10/13 01:38:46 remm Exp $
  - * $Revision: 1.83 $
  - * $Date: 2001/10/13 01:38:46 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.84 2001/10/26 17:17:08 remm Exp $
  + * $Revision: 1.84 $
  + * $Date: 2001/10/26 17:17:08 $
*
* 
*
  @@ -142,7 +142,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.83 $ $Date: 2001/10/13 01:38:46 $
  + * @version $Revision: 1.84 $ $Date: 2001/10/26 17:17:08 $
*/
   
   public class StandardContext
  @@ -235,7 +235,7 @@
* Should we allow the codeServletContext.getContext()/code method
* to access the context of other web applications in this server?
*/
  -private boolean crossContext = true;
  +private boolean crossContext = false;
   
   
   /**
  
  
  



cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml

2001-10-26 Thread remm

remm01/10/26 10:17:39

  Modified:catalina/src/conf server.xml
  Log:
  - Declare the examples webapp as cross context.
  
  Revision  ChangesPath
  1.41  +1 -1  jakarta-tomcat-4.0/catalina/src/conf/server.xml
  
  Index: server.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v
  retrieving revision 1.40
  retrieving revision 1.41
  diff -u -r1.40 -r1.41
  --- server.xml2001/10/26 02:03:28 1.40
  +++ server.xml2001/10/26 17:17:39 1.41
  @@ -215,7 +215,7 @@
   
   !-- Tomcat Examples Context --
   Context path=/examples docBase=examples debug=0
  - reloadable=true
  + reloadable=true crossContext=true
 Logger className=org.apache.catalina.logger.FileLogger
prefix=localhost_examples_log. suffix=.txt
  timestamp=true/
  
  
  



cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml

2001-10-26 Thread remm

remm01/10/26 10:17:52

  Modified:catalina/src/conf Tag: tomcat_40_branch server.xml
  Log:
  - Declare the examples webapp as cross context.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.29.2.10 +1 -1  jakarta-tomcat-4.0/catalina/src/conf/server.xml
  
  Index: server.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v
  retrieving revision 1.29.2.9
  retrieving revision 1.29.2.10
  diff -u -r1.29.2.9 -r1.29.2.10
  --- server.xml2001/10/13 19:25:29 1.29.2.9
  +++ server.xml2001/10/26 17:17:52 1.29.2.10
  @@ -207,7 +207,7 @@
   
   !-- Tomcat Examples Context --
   Context path=/examples docBase=examples debug=0
  - reloadable=true
  + reloadable=true crossContext=true
 Logger className=org.apache.catalina.logger.FileLogger
prefix=localhost_examples_log. suffix=.txt
  timestamp=true/
  
  
  



cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0.2-B1.txt

2001-10-26 Thread remm

remm01/10/26 12:06:58

  Added:   .Tag: tomcat_40_branch RELEASE-NOTES-4.0.2-B1.txt
  Log:
  - Start release notes for the future 4.0.2-b2 (note: no schedule yet, just adding
the release notes document). The document is almost empty at the moment;
I'll update it later to reflect the current status.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.1   +326 -0jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.2-B1.txt
  
  
  
  



Final test from daedalus...

2001-10-26 Thread apmail

this should be the last test...

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




cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config valve.xml

2001-10-26 Thread amyroh

amyroh  01/10/26 11:12:01

  Modified:webapps/tomcat-docs/config valve.xml
  Log:
  Add an optional '%S' item for logging user session id in the access log.  This will 
allow to better tracking the activities of a single user session.
  
  Revision  ChangesPath
  1.6   +1 -0  jakarta-tomcat-4.0/webapps/tomcat-docs/config/valve.xml
  
  Index: valve.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/valve.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- valve.xml 2001/10/12 17:09:37 1.5
  +++ valve.xml 2001/10/26 18:12:01 1.6
  @@ -121,6 +121,7 @@
   lib%q/b - Query string (prepended with a '?' if it exists)/li
   lib%r/b - First line of the request (method and request URI)/li
   lib%s/b - HTTP status code of the response/li
  +lib%s/b - User session ID/li
   lib%t/b - Date and time, in Common Log Format/li
   lib%u/b - Remote user that was authenticated (if any), else '-'/li
   lib%U/b - Requested URL path/li
  
  
  



Test #2

2001-10-26 Thread Craig R. McClanahan

Second test at 21:45, from Sun address.

Craig




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




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

2001-10-26 Thread remm

remm01/10/26 12:14:51

  Modified:catalina/src/share/org/apache/catalina/connector/http
HttpConnector.java
  Log:
  - Add a getter for allowChunking which follows the JavaBean naming conventions.
  
  Revision  ChangesPath
  1.27  +14 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java
  
  Index: HttpConnector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- HttpConnector.java2001/10/17 02:33:45 1.26
  +++ HttpConnector.java2001/10/26 19:14:51 1.27
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
 1.26 2001/10/17 02:33:45 craigmcc Exp $
  - * $Revision: 1.26 $
  - * $Date: 2001/10/17 02:33:45 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
 1.27 2001/10/26 19:14:51 remm Exp $
  + * $Revision: 1.27 $
  + * $Date: 2001/10/26 19:14:51 $
*
* 
*
  @@ -102,7 +102,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.26 $ $Date: 2001/10/17 02:33:45 $
  + * @version $Revision: 1.27 $ $Date: 2001/10/26 19:14:51 $
*/
   
   
  @@ -393,6 +393,16 @@
   public boolean isChunkingAllowed() {
   
   return (allowChunking);
  +
  +}
  +
  +
  +/**
  + * Get the allow chunking flag.
  + */
  +public boolean getAllowChunking() {
  +
  +return isChunkingAllowed();
   
   }
   
  
  
  



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

2001-10-26 Thread bip

bip 01/10/26 12:36:08

  Modified:catalina/src/share/org/apache/catalina/servlets
SsiInvokerServlet.java
  Log:
  Update/Refactoring
  
  Revision  ChangesPath
  1.12  +54 -59
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java
  
  Index: SsiInvokerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- SsiInvokerServlet.java2001/10/24 00:03:04 1.11
  +++ SsiInvokerServlet.java2001/10/26 19:36:08 1.12
  @@ -1,8 +1,8 @@
   /*
* SsiInvokerServlet.java
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
 1.11 2001/10/24 00:03:04 bip Exp $
  - * $Revision: 1.11 $
  - * $Date: 2001/10/24 00:03:04 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
 1.12 2001/10/26 19:36:08 bip Exp $
  + * $Revision: 1.12 $
  + * $Date: 2001/10/26 19:36:08 $
*
* 
*
  @@ -89,8 +89,8 @@
   import javax.naming.InitialContext;
   import org.apache.catalina.Globals;
   import org.apache.catalina.util.RequestUtil;
  -import org.apache.catalina.util.ssi.SsiCommand;
  -import org.apache.catalina.util.ssi.SsiMediator;
  +import org.apache.catalina.util.ssi.SsiDispatcher;
  +import org.apache.catalina.util.ssi.SsiEnvironment;
   import org.apache.catalina.util.ssi.ServletOutputStreamWrapper;
   
   /**
  @@ -99,7 +99,7 @@
*
* @author Bip Thelin
* @author Amy Roh
  - * @version $Revision: 1.11 $, $Date: 2001/10/24 00:03:04 $
  + * @version $Revision: 1.12 $, $Date: 2001/10/26 19:36:08 $
*/
   public final class SsiInvokerServlet extends HttpServlet {
   /** Debug level for this servlet. */
  @@ -111,15 +111,14 @@
   /** Expiration time in seconds for the doc. */
   private Long expires = null;
   
  -/** Should we ignore unsupported/misspelled SSI Directives */
  -private boolean ignoreUnsupportedDirective = false;
  +/** The SSI dispatcher for this servlet instance */
  +private SsiDispatcher ssiDispatcher = null;
   
  -/** virtual path can be webapp-relative */
  +/**
  + * virtual path can be webapp-relative
  + */
   private boolean isVirtualWebappRelative = false;
   
  -/** The Mediator object for the SsiCommands. */
  -private static SsiMediator ssiMediator = null;
  -
   /** The start pattern */
   private final static byte[] bStart = {
   (byte)'',(byte)'!',(byte)'-',(byte)'-',(byte)'#'
  @@ -137,7 +136,9 @@
* @exception ServletException if an error occurs
*/
   public void init() throws ServletException {
  +ssiDispatcher = new SsiDispatcher();
   String value = null;
  +
   try {
   value = getServletConfig().getInitParameter(debug);
   debug = Integer.parseInt(value);
  @@ -154,7 +155,7 @@
   
   try {
   value = 
getServletConfig().getInitParameter(ignoreUnsupportedDirective);
  -ignoreUnsupportedDirective = Integer.parseInt(value)  0 ? true : false;
  +
ssiDispatcher.setIgnoreUnsupportedDirective((Integer.parseInt(value)0)?true:false);
   } catch (Throwable t) {
   ;
   }
  @@ -226,7 +227,17 @@
   
   ServletContext servletContext = getServletContext();
   String path = getRelativePath(req);
  -URL resource = servletContext.getResource(path);
  +URL resource = servletContext.getResource(path);
  +SsiEnvironment ssiEnv = null;
  +StringBuffer command = new StringBuffer();
  +byte buf[] = new byte[4096];
  +int len = 0, bIdx = 0;
  +char ch;
  +boolean inside = false;
  +boolean disableOutput = false;
  +String strCmd;
  +String[] strParamType;
  +String[] strParam;
   
   if (debug  0)
   log(SsiInvokerServlet.requestHandler()\n +
  @@ -248,6 +259,11 @@
   return;
   }
   
  +// Get the SsiEnvironment instance for this request.
  +ssiEnv = SsiEnvironment.createSsiEnvironment(servletContext,
  +  req, res, path);
  +ssiEnv.setIsVirtualWebappRelative(isVirtualWebappRelative);
  +
   res.setContentType(text/html;charset=UTF-8);
   
   if (expires != null) {
  @@ -255,39 +271,20 @@
   new java.util.Date()).getTime() + expires.longValue() * 1000);
   }
   
  -OutputStream out = null;
   URLConnection resourceInfo = resource.openConnection();
   InputStream resourceInputStream = 

Test

2001-10-26 Thread Craig R. McClanahan

Sent at 21:45 Pacific Time.

Craig



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




cvs commit: jakarta-tomcat/src/doc readme

2001-10-26 Thread marcsaeg

marcsaeg01/10/26 08:46:58

  Modified:.Tag: tomcat_32 RELEASE-NOTES
   src/doc  Tag: tomcat_32 readme
  Log:
  Updates for 3.2.4 beta 1
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.10  +43 -32jakarta-tomcat/Attic/RELEASE-NOTES
  
  Index: RELEASE-NOTES
  ===
  RCS file: /home/cvs/jakarta-tomcat/Attic/RELEASE-NOTES,v
  retrieving revision 1.1.2.9
  retrieving revision 1.1.2.10
  diff -u -r1.1.2.9 -r1.1.2.10
  --- RELEASE-NOTES 2001/07/17 14:07:00 1.1.2.9
  +++ RELEASE-NOTES 2001/10/26 15:46:57 1.1.2.10
  @@ -1,8 +1,8 @@
  -$Id: RELEASE-NOTES,v 1.1.2.9 2001/07/17 14:07:00 marcsaeg Exp $
  +$Id: RELEASE-NOTES,v 1.1.2.10 2001/10/26 15:46:57 marcsaeg Exp $
   
   Release Notes for:
  
  -   TOMCAT Version 3.2.3
  +   TOMCAT Version 3.2.4
  
   
   
  @@ -83,11 +83,12 @@
   
   - Tomcat 3.2.1 was a security update.  See section 7.3 for details.
   
  -- Tomcat 3.2.2 was a bug fix release.  Section 7.1 describes the issues
  -that have been fixed in the version.
  +- Tomcat 3.2.2 was a bug fix release.  
   
   - Tomcat 3.2.3 is a security release.
   
  +- Tomcat 3.2.4 is a bug fix release.  See section 7.1 for details.
  +
   - Tomcat 4.0 is separate development from Tomcat 3.x.  It is based on the
   Catalina architecture, which is very different from the architecture of
   Tomcat 3.x.  In addition, Tomcat 4.0 is to be the reference implementation
  @@ -96,16 +97,9 @@
   
   =
   5.  NEW FEATURES IN THIS RELEASE
  -
  -5.1 Docbase and File Based Localization
  -
  -Tomcat 3.2.2 now supports a method mapping requests into localized resources
  -automatically based on the client's and the server's locale.  Localized
  -content can be organized using one directory per locale (Docbase) or
  -into a single directory the locale specified in the file names (File based).
   
  -A detailed description of this feature can be found in 
  -doc/tomcat-localization-how.html
  +Version 3.2.4 is strictly a bug fix release.  No new features have been 
  +added.
   
   
   =
  @@ -310,24 +304,41 @@
   7.  FIXES AND ENHANCEMENTS IN UPDATES
   
   
  -7.1 Fixes and Enhancements in Release 3.2.3
  +7.1 Fixes and Enhancements in Release 3.2.4
   
   This section highlights the bugs fixed in this release.  
  +
  +  -  Cookie name expires is a reserved token (#1114)
  +  -  Thread initialization problem in thread pool (#1745)
  +  -  AJP12 returned invalid HTTP headers when redirecting to very 
  + long URLS (#2333)
  +  -  Fixed casting problem in JspFactoryImpl.getPageContext().  (#4260)
  +  -  Setting sesstion-timeout in web.xml did not prevent sessions from 
  + timing out.  (#4412)
  +  -  Fixed race condition in ServerSocketFactory.getDefault().  (#4418)
  +  -  Removed the restrictions on encoded spcecial characters in URLs
  + that was added as a security precaution in 3.2.3.  The encoded
  + special characters are not decoded and remain the URL and 
  + path info returned to servlets.
  +  -  Jk_nt_service now supports the ability to be restarted automatically
  + by the Windows 2000 service control manager if Tomcat terminates
  + abnormally.
  +  -  Fixed invalid servlet mapping in web.xml generated by JspC (#3474, #3499)
  +  -  Added findResource() and findResources() to AdaptiveClassLoader12
  +  -  A Date: HTTP header is now sent in responses when running stand 
  + alone. (#345)
  +  -  Simple held on to a reference to removed objects preventing 
  + garbage collection.
  +
  + 
  +
  +7.2 Security Vulnerabilities fixed in Tomcat 3.2.4
   
  -  -  The show source links the examples web app didn't work.  (#372)
  -  -  Thread synchronization problems with servlet reloading.  (#1628)
  -  -  Recycling BufferedServletOutputStream didn't reset usingWriter.  (#1802)
  -  -  ZIP files in tomcat/lib were not automatically added to the CLASSPATH
  - by tomcat.bat  (#1935)
  -  -  A sign extension problem caused ServletInputStream to prematurely return
  - EOF.  (#1673, #1993)
  -  -  Multistatus codes for RFC 2518 were missing.  (#2069)
  -  -  Missing error pages caused Tomcat to enter an infinite loop.  (#2327)
  -  -  JDBCRealm SQL statements not being closed.  (#2149)
  -  -  Potential for message buffer overflow in AJP13.  (#1528)  
  +The randomness of generated session ids has been enhanced to prevent the
  +generation of guessable ids.
   
   
  -7.2 Security vulnerabilities fixed in Tomcat 3.2.3
  +7.3 Security vulnerabilities fixed in Tomcat 3.2.3
   
   

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

2001-10-26 Thread Jason Brittain

Remy Maucherat wrote:


Since the bug was likely originally my fault, I felt compelled to
report to you about this missing hunk.  :)
 
 I didn't backport this since I didn't think it was useful. It should just
 save a few operations if there's a race there, I think.
 Maybe it would be safer to add it too.
 
 Remy


Yeah, I was thinking it would be a good idea for consistency
(future patching across more than one branch, etc.).  Thanks
for fixing it..


-- 
Jason Brittain
jasonb(at)collab(dot)net
CollabNet http://www.collab.net




cvs commit: jakarta-tomcat-connectors/jk/native buildconf.sh

2001-10-26 Thread jfclere

jfclere 01/10/26 08:33:46

  Modified:jk/native buildconf.sh
  Log:
  Remove the mkdir: Directory named was wrong and a dummy file in the directory
  is already used to make  sure that the directory is created.
  
  Revision  ChangesPath
  1.3   +0 -2  jakarta-tomcat-connectors/jk/native/buildconf.sh
  
  Index: buildconf.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/buildconf.sh,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- buildconf.sh  2001/06/23 05:52:12 1.2
  +++ buildconf.sh  2001/10/26 15:33:45 1.3
  @@ -1,7 +1,5 @@
   #!/bin/sh
   
  -# if cvs -dP the dir will not exist. Alternative: create a dummy file in it
  -mkdir script/tool/unix
   echo libtoolize --force --automake
   libtoolize --force --automake
   echo automake -a --foreign -i
  
  
  



cvs commit: jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk/ant SoTask.java

2001-10-26 Thread costin

costin  01/10/26 12:53:45

  Modified:jk/jkant ant.tasks
   jk/jkant/java/org/apache/jk/ant SoTask.java
  Added:   jk/native build.xml
  Log:
  A bit more code into the ant builder. Still broken, but can compile the common/
  files. From strange reasons {os.name} system property is Linux, so I can't
  use it for include.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-connectors/jk/native/build.xml
  
  Index: build.xml
  ===
  project name=jk_native default=main basedir=.
  
!-- Experimental --
  
path id=jkant 
  pathelement location=../jkant/build/classes/
  pathelement location=../jkant/build/jkant.jar/
/path

taskdef resource=META-INF/ant.tasks 
   classpathref=jkant /
  
target name=main 
  so sofile=jni_connect 
src dir=.
include name=jni/jk_jnicb.c /
include name=common/jk_map.c /
include name=common/jk_util.c /
include name=common/jk_pool.c /
/src
includes
pathelement path=${java.home}/include /
pathelement path=${java.home}/include/${os.name} /
pathelement location=../common /
/includes
  /so
  
/target
  
  /project
  
  
  1.2   +2 -1  jakarta-tomcat-connectors/jk/jkant/ant.tasks
  
  Index: ant.tasks
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/jkant/ant.tasks,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ant.tasks 2001/10/25 23:48:00 1.1
  +++ ant.tasks 2001/10/26 19:53:45 1.2
  @@ -1 +1,2 @@
  -apxs=org.apache.jk.ApxsTask
  \ No newline at end of file
  +apxs=org.apache.jk.ant.ApxsTask
  +so=org.apache.jk.ant.SoTask
  \ No newline at end of file
  
  
  
  1.2   +220 -24   
jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk/ant/SoTask.java
  
  Index: SoTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk/ant/SoTask.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SoTask.java   2001/10/25 23:48:00 1.1
  +++ SoTask.java   2001/10/26 19:53:45 1.2
  @@ -60,7 +60,26 @@
   import org.apache.tools.ant.*;
   
   import java.io.*;
  +import java.util.*;
   
  +/** Global properties
  +
  +Same idea as in javac, some user .properties will set the local preferences,
  +including machine-specific. If one is not specified we'll guess it. The
  +build file will be clean.
  +
  +TODO: can we get configure to generate such a file ? 
  +
  +build.native.cc=gcc
  +# Path to libtool ( used as a backup )
  +build.native.libtool=
  +# Platform-specific flags for compilation.
  +build.native.extra_cflags=
  +
  +
  +*/
  +
  +
   /**
* Task to generate a .so file, similar with ( or using ) libtool.
* I hate libtool, so long term I would like to replace most of it
  @@ -78,18 +97,40 @@
*/
   public class SoTask extends Task {
   String apxs;
  -Path src;
  -Path include;
  +// or FileSet ?
  +FileSet src;
  +Path includes;
   Path libs;
   String module;
  -
  +String soFile;
  +String cflags;
  +File buildDir;
  +
   public SoTask() {};
   
  -/**
  - *  Path to Apxs executable. Defaults to apxs using the current PATH.
  +public void setSoFile(String s ) {
  + soFile=s;
  +}
  +
  +public void setTarget(String s ) {
  + soFile=s;
  +}
  +
  +/** Directory where intermediary objects will be
  + *  generated
  + */
  +public void setBuildDir( File s ) {
  + buildDir=s;
  +}
  +
  +public void setCflags(String s ) {
  + cflags=s;
  +}
  +
  +/** Directory where the .so file will be generated
*/
  -public void setPath( String path ) {
  - this.apxs=path;
  +public void setSoDir( String s ) {
  + 
   }
   
   /**
  @@ -97,33 +138,25 @@
*
* @return a nexted src element.
*/
  -public Path createSrc() {
  -if (src == null) {
  -src = new Path(project);
  -}
  -return src.createPath();
  +public void addSrc(FileSet fl) {
  + src=fl;
   }
   
   /**
* Include files
*/
  -public Path createInclude() {
  -if (include == null) {
  -include = new Path(project);
  -}
  -return include.createPath();
  +public Path createIncludes() {
  + includes=new Path(project);
  + return includes;
   }
   
   /**
  - * Libraries ( .so or .dll ) files to link to.
  + * Libraries ( .a, .so or .dll ) files to link to.
*/
  -public Path createLib() {
  -if (libs == null) {
  -libs = new 

DO NOT REPLY [Bug 4458] New: - StartMenu shortcuts fail to launch Tomcat when SSL enabled - command line launch works

2001-10-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4458.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

StartMenu shortcuts fail to launch Tomcat when SSL enabled - command line launch works

   Summary: StartMenu shortcuts fail to launch Tomcat when SSL
enabled - command line launch works
   Product: Tomcat 4
   Version: 4.0 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Win2000 Server
JDK1.3.1_01
JSSE1.0.2

CATALINA_HOME=D:\ApacheTomcat
JSSE_HOME=D:\JSSE1.0.2
JAVA_HOME=D:\JDK1.3.1_01

SSL enabled in server.xml such that:

!-- Define a non-SSL HTTP/1.1 Connector on port 8080 --
Connector className=org.apache.catalina.connector.http.HttpConnector
   port=8080 minProcessors=5 maxProcessors=75
   enableLookups=true redirectPort=8443
   acceptCount=10 debug=0 connectionTimeout=6/
!-- Note : To disable connection timeouts, set connectionTimeout value 
 to -1 --

!-- Define an SSL HTTP/1.1 Connector on port 8443 --

Connector className=org.apache.catalina.connector.http.HttpConnector
   port=8443 minProcessors=5 maxProcessors=75
   enableLookups=true
   acceptCount=10 debug=0 scheme=https secure=true
  Factory className=org.apache.catalina.net.SSLServerSocketFactory
   keystoreFile=cert/keystore
   clientAuth=false protocol=TLS/
/Connector

Note:  
keytool -genkey -alias tomcat -keyalg RSA \
-keystore D:\ApacheTomcat\cert\keystore

Observation:  

Correct behavior ensues when I launch D:\ApacheTomcat\bin\startup from any 
shell.  I am able to access both http://localhost:8080 and 
https://localhost:8443.

When I attempt to launch from Start/Run/Programs/Apache Tomcat 4.0/Start 
Tomcat  I get:

Exception during startup processing
java.lang.reflect.InvocationTargetException: java.lang.NoClassDefFoundError: jav
ax/net/ServerSocketFactory
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.apache.catalina.util.xml.ObjectCreate.start(XmlMapper.java:616)
at org.apache.catalina.util.xml.XmlMapper.matchStart(XmlMapper.java:412)

at org.apache.catalina.util.xml.XmlMapper.startElement(XmlMapper.java:91
)
at org.xml.sax.helpers.XMLReaderAdapter.startElement(XMLReaderAdapter.ja
va:329)
at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1451)
at org.apache.crimson.parser.Parser2.content(Parser2.java:1700)
at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1468)
at org.apache.crimson.parser.Parser2.content(Parser2.java:1700)
at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1468)
at org.apache.crimson.parser.Parser2.content(Parser2.java:1700)
at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1468)
at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:499)
at org.apache.crimson.parser.Parser2.parse(Parser2.java:304)
at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:433)

at org.xml.sax.helpers.XMLReaderAdapter.parse(XMLReaderAdapter.java:223)

at javax.xml.parsers.SAXParser.parse(SAXParser.java:317)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:260)

Note:  I am unable to capture the whole trace (I thought I did pretty good 
getting this much).

Am I missing something?  Is there something that is set corrrectly from the env 
when shell launched that is set incorrectly when shortcut launched?

Importance is not high - not even sure that this is a bug but the inconsistancy 
seems to confirm.

Kindly



cvs commit: jakarta-tomcat/src/webpages index.html

2001-10-26 Thread marcsaeg

marcsaeg01/10/26 08:55:11

  Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
Constants.java
   src/webpages Tag: tomcat_32 index.html
  Log:
  Updated version number for Tomcat 3.2.4 beta 1 release.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.22.2.20 +1 -1  
jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/Constants.java
  
  Index: Constants.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/Constants.java,v
  retrieving revision 1.22.2.19
  retrieving revision 1.22.2.20
  diff -u -r1.22.2.19 -r1.22.2.20
  --- Constants.java2001/07/22 12:18:42 1.22.2.19
  +++ Constants.java2001/10/26 15:55:11 1.22.2.20
  @@ -67,7 +67,7 @@
   
   public class Constants {
   public static final String TOMCAT_NAME = Tomcat Web Server;
  -public static final String TOMCAT_VERSION = 3.2.4-dev;
  +public static final String TOMCAT_VERSION = 3.2.4 beta 1;
   
   public static final String JSP_NAME = JSP;
   public static final String JSP_VERSION = 1.1;
  
  
  
  No   revision
  
  
  No   revision
  
  
  1.13.2.22 +2 -2  jakarta-tomcat/src/webpages/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/webpages/index.html,v
  retrieving revision 1.13.2.21
  retrieving revision 1.13.2.22
  diff -u -r1.13.2.21 -r1.13.2.22
  --- index.html2001/07/22 12:18:42 1.13.2.21
  +++ index.html2001/10/26 15:55:11 1.13.2.22
  @@ -4,13 +4,13 @@
   meta http-equiv=Content-Type content=text/html; charset=iso-8859-1
   meta name=GENERATOR content=Mozilla/4.72 [en] (WinNT; U) [Netscape]
   meta name=Author content=Anil K. Vijendran
  -titleTomcat v3.2.4-dev/title
  +titleTomcat v3.2.4 beta 1/title
   /head
   body bgcolor=#FF
   img SRC=tomcat.gif height=92 width=130 align=LEFTbfont face=Arial, 
Helvetica, sans-seriffont size=+3Tomcat/font/font/b 
   br
   bfont face=Arial, Helvetica, sans-seriffont size=-1Version
  -3.2.4-dev/font/font/b
  +3.2.4 beta 1/font/font/b
   pThis is the default Tomcat home page. This page serves as a quick reference
   guide to related resources and is located at:
   ul
  
  
  



DO NOT REPLY [Bug 4436] - DecodeInterceptor writes to log on every call.

2001-10-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4436.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

DecodeInterceptor writes to log on every call.





--- Additional Comments From [EMAIL PROTECTED]  2001-10-26 10:29 ---
A better workaround is to set debug=-1, which should shut it up.



cvs commit: jakarta-tomcat/src/doc readme

2001-10-26 Thread marcsaeg

marcsaeg01/10/26 09:07:49

  Modified:.Tag: tomcat_32 RELEASE-NOTES
   src/doc  Tag: tomcat_32 readme
  Log:
  Added note about JAXP 1.1
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.11  +6 -2  jakarta-tomcat/Attic/RELEASE-NOTES
  
  Index: RELEASE-NOTES
  ===
  RCS file: /home/cvs/jakarta-tomcat/Attic/RELEASE-NOTES,v
  retrieving revision 1.1.2.10
  retrieving revision 1.1.2.11
  diff -u -r1.1.2.10 -r1.1.2.11
  --- RELEASE-NOTES 2001/10/26 15:46:57 1.1.2.10
  +++ RELEASE-NOTES 2001/10/26 16:07:49 1.1.2.11
  @@ -1,4 +1,4 @@
  -$Id: RELEASE-NOTES,v 1.1.2.10 2001/10/26 15:46:57 marcsaeg Exp $
  +$Id: RELEASE-NOTES,v 1.1.2.11 2001/10/26 16:07:49 marcsaeg Exp $
   
   Release Notes for:
  
  @@ -329,7 +329,11 @@
alone. (#345)
 -  Simple held on to a reference to removed objects preventing 
garbage collection.
  -
  +  -  Tomcat 3.2.4 now ships with JAXP 1.1.  Prior releases used 
  + JAXP 1.0.1.  Tomcat 3.2.4 remains completely compatible with
  + the older version of JAXP and there is no requirement for users
  + to upgrade to JAXP 1.1 unless their applications require the new
  + version.

   
   7.2 Security Vulnerabilities fixed in Tomcat 3.2.4
  
  
  
  No   revision
  
  
  No   revision
  
  
  1.8.2.23  +6 -2  jakarta-tomcat/src/doc/readme
  
  Index: readme
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/readme,v
  retrieving revision 1.8.2.22
  retrieving revision 1.8.2.23
  diff -u -r1.8.2.22 -r1.8.2.23
  --- readme2001/10/26 15:46:57 1.8.2.22
  +++ readme2001/10/26 16:07:49 1.8.2.23
  @@ -1,4 +1,4 @@
  -$Id: readme,v 1.8.2.22 2001/10/26 15:46:57 marcsaeg Exp $
  +$Id: readme,v 1.8.2.23 2001/10/26 16:07:49 marcsaeg Exp $
   
   Release Notes for:
  
  @@ -329,7 +329,11 @@
alone. (#345)
 -  Simple held on to a reference to removed objects preventing 
garbage collection.
  -
  +  -  Tomcat 3.2.4 now ships with JAXP 1.1.  Prior releases used 
  + JAXP 1.0.1.  Tomcat 3.2.4 remains completely compatible with
  + the older version of JAXP and there is no requirement for users
  + to upgrade to JAXP 1.1 unless their applications require the new
  + version.

   
   7.2 Security Vulnerabilities fixed in Tomcat 3.2.4
  
  
  



DO NOT REPLY [Bug 4454] New: - pr_warp receives an invalid packet from client on simultaneous requests

2001-10-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4454.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

pr_warp receives an invalid packet from client on simultaneous requests

   Summary: pr_warp receives an invalid packet from client on
simultaneous requests
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: UNCONFIRMED
  Severity: Major
  Priority: Other
 Component: Connectors
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have installed on my pc win2k, apache 1.3.22 and tomcat 4.0.1 Final with the 
webapp connector properly configured to run cocoon 2.0.
Non concurrent requests work fine. 
Pages containing frames requesting to cocoon more than one page, produce a 
WebApp:Error 500 (file: pr_warp.c) in each frame.
Sometimes in that condition, Apache too crashed.
I made the same test replacing cocoon with another web application, with the 
same results.
I' ve tried the same tests on linux, anything works fine.

In the apache error.log I found:

[info] Parent: Created child process 1516
[info] Parent: Duplicating socket 432 and sending it to child process 1516
[info] BytesRead = 372 WSAProtocolInfo = 2006620
[error] (null)
[error] Invalid packet 4
[error] Communitcation interrupted
[error] Communitcation interrupted
[info] [client 127.0.0.1] (10054)Unknown error: client stopped connection 
before rflush completed
[error] (null)
[error] Cannot receive handshake WARP packet
[error] Cannot read packet (pr_warp_config.c:139)
[error] Cannot configure connection conn

Any tip could help :)



Security Question

2001-10-26 Thread Drasko . Kokic



Hi there,
I have read the Existing Risks and Problems (Chapter 8 in the internal
document of the TC-3.3) and spotted that there is a potentional security
risk in using Tomcat as a platform for the Application Gateway to an
enterprise business support system.
One of very important subprojects I still need to solve is providing a
secure environment and currently we are constructing a sort of Checking
Engine that basically test every parameter against predescribed conditions
and reject all invalid requests.
Has anybody already thought about this or eventually produced some
code/concept?  I hope some of original contributors will also read this
post.
I have some development resources allocated to this task, but would prefer
if we could join forces with other interested parties as this must be a
very important issue.
Drasko