date:20001116


Bug report #395 has just been filed.

You can view the report at the following URL:

   http://znutar.cortexity.com/BugRatViewer/ShowReport/395

REPORT #395 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: serious
Confidence: public
Environment: 
   Release: 3.2 b7
   JVM Release: 1.3
   Operating System: NT
   OS Release: 4.0SP6
   Platform: Windows

Synopsis: 
getResource is buggy in AdaptiveClassLoader: does not go to parent

Description:
During our integration of Tomcat in jBoss we have uncovered a bug in the
AdaptiveClassLoader. The getResource() methods delegates to the system
classloader, which is wrong. It should instead simply delegate to the
parent classloader.

/Rickard ([EMAIL PROTECTED])


Title: 
BugRat Report #
395





BugRat Report #
395




Project:
Tomcat


Release:
3.2 b7




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
medium


Severity:
serious




Confidence:
public





Submitter:
_Anonymous ([EMAIL PROTECTED])

Date Submitted:
Nov 16 2000, 02:23:30 CST

Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])


Synopsis:

getResource is buggy in AdaptiveClassLoader: does not go to parent


 Environment: (jvm, os, osrel, platform)

1.3, NT, 4.0SP6, Windows



Additional Environment Description:





Report Description:

During our integration of Tomcat in jBoss we have uncovered a bug in the
AdaptiveClassLoader. The getResource() methods delegates to the system
classloader, which is wrong. It should instead simply delegate to the
parent classloader.

/Rickard ([EMAIL PROTECTED])




Workaround:

null



View this report online...

BugRat Report #396 has been filed.

Bug report #396 has just been filed.

You can view the report at the following URL:

http://znutar.cortexity.com/BugRatViewer/ShowReport/396

REPORT #396 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: critical
Confidence: public
Environment:
Release: 3.1
JVM Release: 1.3.0
Operating System: Solaris
OS Release: 2.6
Platform: Sun

Synopsis:
Asynchronous flushing of outputbuffers when using programmatic include in taglibs

Description:
Dear Sirs,
as part of a process of evaluating various JSP containers/app servers for a major
project, we have written a small tag library that employs server-side include as part
of a small framework for an application.
We have tried two flavors of include (three, actually, but the jsp:include tagged
version works OK):
programmatic using the include method contained in the RequestDispatcher
class, and
ditto in the PageContext class.
Both these seem to work OK, with one, grave exception: The output coming from the
included files precede any output
from the surrounding page(!) This causes things to be presented to the end user in a
somewhat undesireable way.
We have tried the code on other platforms, and the sequencing seems OK there.
Tomcat doesn't seem to flush the outstream from the surrounding page before output
from the included files is sent to the outstream.
Our question: Is this a (unintentional) feature, i.e. should we expect Tomcat and
other platforms to behave like this, or is this a bug in our build of tomcat?

sincerely
[EMAIL PROTECTED]

Title:
BugRat Report #
396

BugRat Report #
396

Project:
Tomcat

Release:
3.1

Category:
Bug Report

SubCategory:
New Bug Report

Class:
swbug

State:
received

Priority:
medium

Severity:
critical

Confidence:
public

Submitter:
_Anonymous ([EMAIL PROTECTED])

Date Submitted:
Nov 16 2000, 03:36:19 CST

Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])

Synopsis:

Asynchronous flushing of outputbuffers when using programmatic include in taglibs

Environment: (jvm, os, osrel, platform)

1.3.0, Solaris , 2.6, Sun

Additional Environment Description:

Report Description:

Dear Sirs,
as part of a process of evaluating various JSP containers/app servers for a major project, we have written a small tag library that employs server-side include as part of a small framework for an application.
We have tried two flavors of include (three, actually, but the tagged version works OK):
programmatic using the include method contained in the RequestDispatcher class, and
ditto in the PageContext class.
Both these seem to work OK, with one, grave exception: The output coming from the included files precede any output
from the surrounding page(!) This causes things to be presented to the end user in a somewhat undesireable way.
We have tried the code on other platforms, and the sequencing seems OK there.
Tomcat doesn't seem to flush the outstream from the surrounding page before output from the included files is sent to the outstream.
Our question: Is this a (unintentional) feature, i.e. should we expect Tomcat and other platforms to behave like this, or is this a bug in our build of tomcat?

sincerely
[EMAIL PROTECTED]

View this report online...

Using Jasper for template processing?

2000-11-16 Thread Jaroslav Gergic


NOTE: I posted the message below to the tomcat-user mailing list
several days ago, but without any meningful response.

I am NOT tomcat-dev mailing list member, so respond
directly to my email address, please.

Thanks for any help and suggestions,
in case I will succeed in my task, 
I can contribute back to the community of course...
***
Hello Tomcat developers and advanced users!

I have following question:

I would like to use Jasper engine for template processing.  I use
Tomcat with JSPs and its good, but I would like to alter Jasper usage
this way:

An JSP page is compiled into a Java source where the user's JSP
page extends the class HttpJspBase and overrides several methods
notably _jspService().

I want to use Jasper for more generic task. Template processing
independent on Servlets and HTTP. Imagine following interface:

public interface Template {
  void renderTemplate(Writer out) throws java.io.IOException;
}

I want to alter Jasper to process files with JSP-like syntax (of
course with other intrinsic variables accessible inside the
renderTemplate() method) and generate Java source code implementing
the Template interface and than compile the source code using Java
compiler into executable classes. Then load and run generated classes
as they have been written manually.

So I ask:
1) is it possible or is Jasper tightly coupled with HTTP and Servlet
API?
2) if it is possible, how to do that? (which classes can be re-used,
which interfaces and classes have to be re-implemented
3) how much time it can take (1 day, 3 days, a week, two weeks, ...)

Thanks for any comments and suggestions.

Jaroslav Gergic

=
Jaroslav Gergic (Gergi)
mailto:[EMAIL PROTECTED]
http://nenya.ms.mff.cuni.cz/~gergic/

__
Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!
http://calendar.yahoo.com/

Classloader

2000-11-16 Thread Rob Shaw


Given that I have 2 "contexts" defined (which I'm assuming
each has thier own classloader).

After making a request to the same servlet within each
context, I'm witnessing the creation of seperate instances
of the servlet per context, which I would expect, but
I'm also witnessing the sharing of classes
that have static members.

Is this intentional, or is this a bug?

According to Servlet 2.2 spec:

 4.6 Reloading Considerations
...
 Therefore, when a Container Provider implements a class
 reloading scheme for ease of development, they must ensure
 that all servlets, and classes that they may use, are loaded
 in the scope of a single class loader guaranteeing that the
 application will behave as expected by the Developer.
...

Thanks,
Rob.

RE: Using Jasper for template processing?

2000-11-16 Thread Christian Mallwitz


Please follow up on this in tomcat-dev as well ...
Thanks
Christian
-- 
Christian Mallwitz INTERSHOP Communications Germany
Senior Software Engineerphone: +49 3641 894 334

 -Original Message-
 From: Jaroslav Gergic [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, November 16, 2000 11:15
 To: [EMAIL PROTECTED]
 Subject: Using Jasper for template processing?
 
 
 NOTE: I posted the message below to the tomcat-user mailing list
 several days ago, but without any meningful response.
 
 I am NOT tomcat-dev mailing list member, so respond
 directly to my email address, please.
 
 Thanks for any help and suggestions,
 in case I will succeed in my task, 
 I can contribute back to the community of course...
 **
 *
 Hello Tomcat developers and advanced users!
 
 I have following question:
 
 I would like to use Jasper engine for template processing.  I use
 Tomcat with JSPs and its good, but I would like to alter Jasper usage
 this way:
 
 An JSP page is compiled into a Java source where the user's JSP
 page extends the class HttpJspBase and overrides several methods
 notably _jspService().
 
 I want to use Jasper for more generic task. Template processing
 independent on Servlets and HTTP. Imagine following interface:
 
 public interface Template {
   void renderTemplate(Writer out) throws java.io.IOException;
 }
 
 I want to alter Jasper to process files with JSP-like syntax (of
 course with other intrinsic variables accessible inside the
 renderTemplate() method) and generate Java source code implementing
 the Template interface and than compile the source code using Java
 compiler into executable classes. Then load and run generated classes
 as they have been written manually.
 
 So I ask:
 1) is it possible or is Jasper tightly coupled with HTTP and Servlet
 API?
 2) if it is possible, how to do that? (which classes can be re-used,
 which interfaces and classes have to be re-implemented
 3) how much time it can take (1 day, 3 days, a week, two weeks, ...)
 
 Thanks for any comments and suggestions.
 
 Jaroslav Gergic
 
 =
 Jaroslav Gergic (Gergi)
 mailto:[EMAIL PROTECTED]
 http://nenya.ms.mff.cuni.cz/~gergic/
 
 __
 Do You Yahoo!?
 Yahoo! Calendar - Get organized for the holidays!
 http://calendar.yahoo.com/

Apache don't accept mod_jserv or mod_jk

2000-11-16 Thread Stein Langorgen


I have compiled mod_jserv without any problems, but when I restart Apache,
I get this error message:

  httpd: module "mod_jserv.c" is not compatible with this version 
  of Apache. Please contact the vendor for the correct version.

I am using Digital Unix 4.0D and Apache 1.3.14. mod_jserv was build from
the tomcat 3.2b6 release. The same error msg also came when I tried to use
mod_jk. What am I doing wrong? Does anyone have an compile/install
procedure that is supposed to work on Digital Unix 4.0 ?

SteinL.

BugRat Report #398 has been filed.

Bug report #398 has just been filed.

You can view the report at the following URL:

http://znutar.cortexity.com/BugRatViewer/ShowReport/398

REPORT #398 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: serious
Confidence: public
Environment:
Release: 3.1
JVM Release: 1.3
Operating System: Windows
OS Release: 2000
Platform: IntelX86

Synopsis:
MIME-TYPE handling

Description:
/tomcat/conf/web.xml supports MIME type addtions. However, the added types works fine
in only ROOT repository. For example, I deployed /tomcat/webapps/bbs application(i.e.
bbs repository) and I put test.jnlp(for Java Web Start) into the directory. Although
definitely I added some necessary MIME types to /tomcat/conf/web.xml, I couldn't
launch my JWS application from bbs app. I tried to put a new web.xml which also
contained jnlp mime type into /tomcat/webapps/bbs/WEB-INF, but the result was the
same. So I tested the launcher html and jnlp into /tomcat/webapps/ROOT and I found it
worked well. Through all the possible cases I could examine, I concluded that Tomcat
MIME type addition now supports only ROOT app.

Title:
BugRat Report #
398

BugRat Report #
398

Project:
Tomcat

Release:
3.1

Category:
Bug Report

SubCategory:
New Bug Report

Class:
swbug

State:
received

Priority:
high

Severity:
serious

Confidence:
public

Submitter:
_Anonymous ([EMAIL PROTECTED])

Date Submitted:
Nov 16 2000, 07:25:35 CST

Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])

Synopsis:

MIME-TYPE handling

Environment: (jvm, os, osrel, platform)

1.3, Windows, 2000, IntelX86

Additional Environment Description:

Report Description:

/tomcat/conf/web.xml supports MIME type addtions. However, the added types works fine in only ROOT repository. For example, I deployed /tomcat/webapps/bbs application(i.e. bbs repository) and I put test.jnlp(for Java Web Start) into the directory. Although definitely I added some necessary MIME types to /tomcat/conf/web.xml, I couldn't launch my JWS application from bbs app. I tried to put a new web.xml which also contained jnlp mime type into /tomcat/webapps/bbs/WEB-INF, but the result was the same. So I tested the launcher html and jnlp into /tomcat/webapps/ROOT and I found it worked well. Through all the possible cases I could examine, I concluded that Tomcat MIME type addition now supports only ROOT app.

View this report online...

Re: FW: lock

2000-11-16 Thread Pierre Delisle


Well,

It is now 5:30 am, and the situation still has not changed regarding the
following lock (I've had this since 6pm last night).

...
cvs server: [05:29:59] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src
/share/org/apache/jasper/compiler
cvs server: [05:30:29] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src
/share/org/apache/jasper/compiler
cvs server: [05:30:59] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src
/share/org/apache/jasper/compiler
cvs server: [05:31:29] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src
/share/org/apache/jasper/compiler
cvs server: [05:31:59] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src
/share/org/apache/jasper/compiler
...

Any cvs expert that could fix the situation?

Thanks,

-- Pierre


Larry Isaacs wrote:
 
 Sorry, typo in the Cc:
 
 -Original Message-
 From: Larry Isaacs
 To: 'Pierre Delisle '
 Cc: '[EMAIL PROTECTED]'
 Sent: 11/15/00 9:55 PM
 Subject: RE: lock
 
 Hi Pierre,
 
 I saw the same thing a little after 5:00 PM when I tried a commit some
 changes to this directory. After about 5 minutes of this, I aborted and
 logged out of jakarta.apache.org.  I have tried to commit two more times
 with the same result.
 
 I'm supprised to see my username on the "lock".  I thought it was a
 "lock"
 that was more general, not something tagged to me.  I'm not aware of
 anything intentional on my part that created this "lock".
 
 I have been using WinCVS 1.1b15/16 for a while with no problems.  Any
 suggestions on how I might release this "lock" from my end?  Otherwise,
 hope this can be fixed from the server side.
 
 Larry
 
 -Original Message-
 From: Pierre Delisle
 To: [EMAIL PROTECTED]
 Sent: 11/15/00 9:21 PM
 Subject: lock
 
 Larry,
 
 I cannot commit to tomcat_32.
 
 I've been getting this message for the last 5 minutes:
 
 .
 cvs server: [18:18:18] waiting for larryi's lock in
 /home/cvs/jakarta-tomcat/src
 /share/org/apache/jasper/compiler
 cvs server: [18:18:48] waiting for larryi's lock in
 /home/cvs/jakarta-tomcat/src
 /share/org/apache/jasper/compiler
 ...
 
 Any idea?
 
 -- Pierre
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

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

2000-11-16 Thread pierred


pierred 00/11/16 07:57:38

  Modified:src/share/org/apache/jasper/compiler Tag: tomcat_32
TagLibraryInfoImpl.java
  Log:
  Do not copy taglib jar file to the work directory
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.22.2.6  +7 -5  
jakarta-tomcat/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
  
  Index: TagLibraryInfoImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
  retrieving revision 1.22.2.5
  retrieving revision 1.22.2.6
  diff -u -r1.22.2.5 -r1.22.2.6
  --- TagLibraryInfoImpl.java   2000/10/06 11:09:38 1.22.2.5
  +++ TagLibraryInfoImpl.java   2000/11/16 15:57:38 1.22.2.6
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
 1.22.2.5 2000/10/06 11:09:38 larryi Exp $
  - * $Revision: 1.22.2.5 $
  - * $Date: 2000/10/06 11:09:38 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
 1.22.2.6 2000/11/16 15:57:38 pierred Exp $
  + * $Revision: 1.22.2.6 $
  + * $Date: 2000/11/16 15:57:38 $
*
* The Apache Software License, Version 1.1
*
  @@ -234,6 +234,8 @@
}

// FIXME Take this stuff out when taglib changes are thoroughly tested.
  +// 2000.11.15 commented out the 'copy to work dir' section,
  +// which I believe is what this FIXME comment referred to. (pierred)
if (uri.endsWith("jar")) {

if (!isRelativeURI(uri)) {
  @@ -248,6 +250,7 @@
this.jarEntries = new Hashtable();
this.ctxt = ctxt;

  +/* NOT COMPILED
// First copy this file into our work directory! 
{
File jspFile = new File(ctxt.getJspFile());
  @@ -278,8 +281,7 @@

ctxt.addJar(jarFileName);
}
  - 
  - 
  +*/ // END NOT COMPILED
boolean tldFound = false;
ZipEntry entry;
while ((entry = zin.getNextEntry()) != null) {

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

2000-11-16 Thread nacho


nacho   00/11/16 08:59:18

  Modified:src/share/org/apache/tomcat/core OutputBuffer.java
  Log:
  Flushing the byte buffer after a flush of char buffer.
  
  Revision  ChangesPath
  1.9   +6 -4  
jakarta-tomcat/src/share/org/apache/tomcat/core/OutputBuffer.java
  
  Index: OutputBuffer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/OutputBuffer.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- OutputBuffer.java 2000/11/02 21:44:37 1.8
  +++ OutputBuffer.java 2000/11/16 16:59:18 1.9
  @@ -168,7 +168,6 @@
if( debug  0 ) log("write(b,off,len)");
int avail=buf.length - count;
   
  - bytesWritten += len;
   
// fit in buffer, great.
if( len = avail ) {
  @@ -176,6 +175,7 @@
  // want to flush now
System.arraycopy(b, off, buf, count, len);
count += len;
  + bytesWritten += len;
}
   
// Optimization:
  @@ -193,7 +193,7 @@
System.arraycopy(b, off, buf, count, avail);
count += avail;
flushBytes();
  - 
  +
System.arraycopy(b, off+avail, buf, count, len - avail);
count+= len - avail;
bytesWritten += len - avail;
  @@ -202,6 +202,7 @@
// long write - flush the buffer and write the rest
// directly from source
flushBytes();
  + bytesWritten += len;
realWrite( req, resp, b, off, len );
}
   
  @@ -358,9 +359,10 @@
   
   synchronized public void flush() throws IOException {
   doFlush = true;
  -if( state==CHAR_STATE )
  +if( state==CHAR_STATE ){
   flushChars();
  -else if (state==BYTE_STATE)
  +flushBytes();
  +}else if (state==BYTE_STATE)
   flushBytes();
   else if (state==INITIAL_STATE)
   realWrite( req, resp, null, 0, 0 );   // nothing written yet

Re: Instances of a Servlet


Rob Shaw wrote:

 I'm seeing a behaviour that suggests instantiation of servlets
 due to an invocation via a "servlet-mapping" or via the
 InvokerServlet (/servlet) are handled differently.

 More specifically, given that I've set up a Context for
 the path "/foo", and within that context, I've mapped
 "/some" to SomeServlet.

 If I make a request to http://localhost/foo/some, I can
 see the creation of an instantiation of SomeServlet.
 But, if I also make the request to
 http://localhost/foo/servlet/SomeServlet, I see an additional
 creation of an instance of SomeServlet.

 Is this an intentional behaviour or a bug?
 (Note: I have servlet reloading enabled)

 According to Servlet 2.2 Spec:

  3.2 Number of Instances
  By default, there must be only one instance of a servlet
  class per servlet definition in a container.
  ...

  3.3.1 Loading and Instantiation
  ...
  It is important to note that there can be more than one
  instance of a given Servlet class in the servlet
  container. For example, this can occur where there
  was more than one servlet definition that utilized a
  specific servlet class with different initialization parameters.
  ...

 Does the above two usage scenarios constitute a
 different "servlet definition"?


Yes.

The concept of an "invoker" servlet (i.e. the "/servlet/*" handler) is
not in the servlet specification at all (which only considers servlet
to be a servlet definition), but is commonly implemented in servlet
containers.  What happens is, the first time you invoke a servlet via
/servlet/x, a new servlet definition is created dynamically.  The
dynamically created servlet definition will have its own ServletConfig
structure with no servlet initialization parameters.



 Thanks,
 Rob.

Craig McClanahan

Re: Classloader


Rob Shaw wrote:

 Given that I have 2 "contexts" defined (which I'm assuming
 each has thier own classloader).


That is correct.


 After making a request to the same servlet within each
 context, I'm witnessing the creation of seperate instances
 of the servlet per context, which I would expect, but
 I'm also witnessing the sharing of classes
 that have static members.

 Is this intentional, or is this a bug?


It depends on where the classes are loaded from.  The following details
are Tomcat-specific, but something similar is probably true for most
containers.

The web-app class loader that Tomcat creates for each web app will
delegate to the system class loader (i.e. the one that processes the
CLASSPATH) if a class is not found in "/WEB-INF/classes" or
"/WEB-INF/lib/*.jar".  In such a case, there will be only one copy of
such classes (because the system class loader is delegated to from each
web app), so statics are shared across web apps.

On the other hand, if you made a copy of the class underneath WEB-INF
for each web app, the statics would *not* be shared.


 According to Servlet 2.2 spec:

  4.6 Reloading Considerations
 ...
  Therefore, when a Container Provider implements a class
  reloading scheme for ease of development, they must ensure
  that all servlets, and classes that they may use, are loaded
  in the scope of a single class loader guaranteeing that the
  application will behave as expected by the Developer.
 ...


In fact, there is an explicit documented restriction in Tomcat that it
only applies to classes found under WEB-INF -- class reloading for
things found on the system class path is not supported.


 Thanks,
 Rob.

Craig

Re: Closing Bug Reports?

2000-11-16 Thread Jon Stevens


on 11/15/2000 11:11 PM, "Hans Bergsten" [EMAIL PROTECTED] wrote:

 Jon, what's the status of Scarab?

Well, yesterday we finally hired John Mcnally (he is one of the co-authors
of Turbine) to help me work on it full time. So, that is good news. He kicks
ass.

Given that I currently have been working on Scarab less than part time (I
have been pulled off for other CollabNet engineering stuff recently as well
as ApacheCon and Comdex 2000 as well as the fact that I now have a nasty
cold I'm trying to fight), lets just say that the going has been pretty
slow. :-(

-jon

-- 
twice of not very much is still a lot more than not very much

Re: lock

2000-11-16 Thread Jon Stevens


on 11/16/2000 5:35 AM, "Pierre Delisle" [EMAIL PROTECTED] wrote:

 It is now 5:30 am, and the situation still has not changed regarding the
 following lock (I've had this since 6pm last night).
 
 ...
 cvs server: [05:29:59] waiting for larryi's lock in
 /home/cvs/jakarta-tomcat/src
 /share/org/apache/jasper/compiler
 cvs server: [05:30:29] waiting for larryi's lock in
 /home/cvs/jakarta-tomcat/src
 /share/org/apache/jasper/compiler
 cvs server: [05:30:59] waiting for larryi's lock in
 /home/cvs/jakarta-tomcat/src
 /share/org/apache/jasper/compiler
 cvs server: [05:31:29] waiting for larryi's lock in
 /home/cvs/jakarta-tomcat/src
 /share/org/apache/jasper/compiler
 cvs server: [05:31:59] waiting for larryi's lock in
 /home/cvs/jakarta-tomcat/src
 /share/org/apache/jasper/compiler
 ...
 
 Any cvs expert that could fix the situation?

Brian Behlendorf is the sysadmin for www.apache.org. I have already
forwarded your earlier message as well as this message to him.

In the future, you should contact him directly at [EMAIL PROTECTED] or send
email to [EMAIL PROTECTED] instead of discussing this on the mailing list
where no one can help you. :-(

-jon

-- 
twice of not very much is still a lot more than not very much

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

2000-11-16 Thread craigmcc


craigmcc00/11/16 10:25:22

  Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
ContextManager.java
  Log:
  Correctly shut down *all* contexts (which will trigger the destroy()
  method of all initialized servlets being called).  Previously, the code
  was relying on being able to enumerate over a collection that is being
  modified, which is undefined behavior -- and does not work as intended in
  many JVMs.
  
  Submitted by: Marc Saegesser [EMAIL PROTECTED]
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.100.2.19 +3 -5  
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.18
  retrieving revision 1.100.2.19
  diff -u -r1.100.2.18 -r1.100.2.19
  --- ContextManager.java   2000/11/11 02:56:58 1.100.2.18
  +++ ContextManager.java   2000/11/16 18:25:21 1.100.2.19
  @@ -466,11 +466,9 @@
   /** Will shutdown all contexts
*/
   public void shutdown() throws TomcatException {
  - Enumeration enum = getContexts();
  - while (enum.hasMoreElements()) {
  - removeContext((Context)enum.nextElement());
  - }
  -
  +while (!contextsV.isEmpty()) {
  +removeContext((Context) contextsV.firstElement());
  +}
ContextInterceptor cI[]=getContextInterceptors();
for( int i=0; i cI.length; i++ ) {
cI[i].engineShutdown( this );

Re: 3.2 status -- no taglibs in jars

2000-11-16 Thread Brian Bucknam


I wrote:

  I haven't tried simply commenting out or removing the code that says "Take this 
stuff out..." because that would remove the entire section devoted opening the jar 
and finding the .tld inside. Maybe I'm missing something, but this doesn't sound like 
the right fix.

Then Pierre Delisle replied:

 Only the 'copy' part needs to be commented out. Here is the diff since I cannot
 commit to the master for now.

OK, that makes a lot more sense.

I'll rebuild with the change, run some tests, and let the list know.

Thanks, Pierre!
Brian

WAP and sessions in Tomcat3.1

2000-11-16 Thread Scott Clasen


Hi-

I am experiencing some wierd behavior with a WAP application under
tomcat.

I have the application functioning properly under jServ,
now I am trying to move it into .war format, under tomcat.

Whenever

HttpSession session = req.getSession(false);

is called during a request from a wap phone or emulator, it will never
return null, even when that is the correct thing to do.

I have the app set up for debugging with a web browser, and when that
line of code is called during a request from a browser, it does the
right thing and returns null when it is supposed to.

I checked the archives, and there was an unanswered post about
req.getSession(false) never returning null, and also checked the bug
system, I couldn't find any answers.

Does any one have any ideas?

Thanks
Scott Clasen
[EMAIL PROTECTED]

Re: [PROPOSED 3.2B7 PATCH] error displayed for case mismatch in JSP URL


+1

Craig


Larry Isaacs wrote:

 In Tomcat 3.2b7 (and earlier), invoking
 http://localhost:8080/test/jsp/Helloworld.jsp results in an NPE in
 JspCompiler.isOutDated().  This occurs because getRealPath() returns
 null since the 'w' should be uppercase, hence it is considered an
 "unsafe" path.  To make this error return "file not found", I propose
 the following patches for 3.2b7.

 = JspCompiler.java Patch =
 RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspCompiler.java,v
 retrieving revision 1.14.2.1
 diff -u -r1.14.2.1 JspCompiler.java
 --- JspCompiler.java2000/07/25 20:45:09 1.14.2.1
 +++ JspCompiler.java2000/11/15 12:13:12
 @@ -304,7 +304,11 @@
  public boolean isOutDated() {
  File jspReal = null;

 -jspReal = new File(ctxt.getRealPath(jsp.getPath()));
 +String realPath = ctxt.getRealPath(jsp.getPath());
 +if (realPath == null)
 +return true;
 +
 +jspReal = new File(realPath);

  File classFile = new File(getClassFileName());
  if (classFile.exists()) {
 ==

 = JspReader.java patch =
 RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspReader.java,v
 retrieving revision 1.16.2.4
 diff -u -r1.16.2.4 JspReader.java
 --- JspReader.java  2000/11/06 04:08:14 1.16.2.4
 +++ JspReader.java  2000/11/15 12:12:29
 @@ -171,6 +171,9 @@
 ? file.getAbsolutePath()
 : context.getRealPath(file.toString());

 +   if (longName == null)
 +   throw new FileNotFoundException(file.toString());
 +
 int fileid = registerSourceFile(longName);

  if (fileid == -1)
 

 This probably won't eliminate the head scratching, but at least they will
 be scratching their heads for the right reason. :-)  Also, this will make
 section 6.7 in the Readme correct about the error seen due to a case mismatch.

 If no one objects, I'll commit these changes this afternoon.

 Cheers,
 Larry

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

#36

2000-11-16 Thread Maryellen Rothberg


don't see the answer to bug #36 which is exactly the problem i have - i
don't think it's a bug necessarily, but rather something i'm doing wrong.
in any case, someone else had the same problem and i'd be gateful for an
answer (#40 or whoever closed did not say what it was).

please help.

maryellen rothberg

BugRat Report #399 has been filed.


Bug report #399 has just been filed.

You can view the report at the following URL:

   http://znutar.cortexity.com/BugRatViewer/ShowReport/399

REPORT #399 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: 3.1
   JVM Release: 1.3
   Operating System: NT 4
   OS Release: SP6a
   Platform: Windows

Synopsis: 
Unable to restart Tomcat after shutdown.

Description:
I get this error when I shutdown and restart Tomcat(standalone).
I have configured tomcat to run on port 80.
When I run netstat to see the activity,after shutdown, it says listening on port 80.
I double click the 'bat' files to both start and shut tomcat.

This is the error, when I try to restart tomcat after a shutdown:

FATAL:java.net.BindException: Address in use: bind
java.net.BindException: Address in use: bind
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:390)
at java.net.ServerSocket.init(ServerSocket.java:173)
at java.net.ServerSocket.init(ServerSocket.java:124)
at org.apache.tomcat.net.DefaultServerSocketFactory.createSocket(Default
ServerSocketFactory.java:97)
at org.apache.tomcat.service.SimpleTcpEndpoint.startEndpoint(SimpleTcpEn
dpoint.java:186)
at org.apache.tomcat.service.SimpleTcpConnector.start(SimpleTcpConnector
.java:142)
at org.apache.tomcat.core.ContextManager.start(ContextManager.java, Comp
iled Code)
at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:157)
at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:163)

Title: 
BugRat Report #
399





BugRat Report #
399




Project:
Tomcat


Release:
3.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
Imran Ahmed ([EMAIL PROTECTED])

Date Submitted:
Nov 16 2000, 03:37:56 CST

Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])


Synopsis:

Unable to restart Tomcat after shutdown.


 Environment: (jvm, os, osrel, platform)

1.3, NT 4, SP6a, Windows



Additional Environment Description:

1. Somehow the shutdown is not closing the socket.
2. When I run apache immidietly after tomcat fails,also configured on port 80, apache works fine.



Report Description:

I get this error when I shutdown and restart Tomcat(standalone).
I have configured tomcat to run on port 80.
When I run netstat to see the activity,after shutdown, it says listening on port 80.
I double click the 'bat' files to both start and shut tomcat.

This is the error, when I try to restart tomcat after a shutdown:

FATAL:java.net.BindException: Address in use: bind
java.net.BindException: Address in use: bind
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:390)
at java.net.ServerSocket.(ServerSocket.java:173)
at java.net.ServerSocket.(ServerSocket.java:124)
at org.apache.tomcat.net.DefaultServerSocketFactory.createSocket(Default
ServerSocketFactory.java:97)
at org.apache.tomcat.service.SimpleTcpEndpoint.startEndpoint(SimpleTcpEn
dpoint.java:186)
at org.apache.tomcat.service.SimpleTcpConnector.start(SimpleTcpConnector
.java:142)
at org.apache.tomcat.core.ContextManager.start(ContextManager.java, Comp
iled Code)
at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:157)
at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:163)



Workaround:

null



View this report online...

Client side SSL Information for - Tomcat 3.2b6 + mod_ssl + Apache 1.3.14 + mod_jk

2000-11-16 Thread Bobby Sardana


Greetings:

After searching the bug database, I have been unable to determine and
operate the following: (Apache 1.3.14 + mod_ssl + Tomcat 3.2b6 + mod_jk)

a. How is client side SSL information (SSL_CLIENT_CERT) available in a
servlet which is invoked by Tomcat.?
b. The information is available if I run a shell program under cgi-bin,
so the SSLOptions settings are right.

Are the environment variables exported at all by mod_jk? Or is it not
supported in 3.2b6?

Any information on the above is appreciated.

Regards,

[EMAIL PROTECTED]




begin:vcard 
n:Sardana;Bobby
x-mozilla-html:FALSE
org:MobileRain Technologies, Inc.;Telecommunications
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Engineer
x-mozilla-cpt:;0
fn:Bobby Sardana
end:vcard

BugRat Report #395 was closed (apparently by: Craig R. McClanahan)


Report #395 was closed by Person #0

   Synopsis: getResource is buggy in AdaptiveClassLoader: does not go to parent

 (logged in as: Craig R. McClanahan)

cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler JspCompiler.java JspReader.java

2000-11-16 Thread larryi


larryi  00/11/16 14:10:35

  Modified:src/share/org/apache/jasper/compiler Tag: tomcat_32
JspCompiler.java JspReader.java
  Log:
  Make isOutDated() return true if ctxt.getRealPath() returns null, instead of
  throwing an NPE.
  
  Make pushFile() throw a FNFE if context.getRealPath() returns null, instead
  of throwing a parse exception later.
  
  On case insensitive OS's, getRealPath() can return null if there is a case
  mismatch in the path.  These changes result in a more useful error response.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.14.2.2  +5 -1  
jakarta-tomcat/src/share/org/apache/jasper/compiler/JspCompiler.java
  
  Index: JspCompiler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspCompiler.java,v
  retrieving revision 1.14.2.1
  retrieving revision 1.14.2.2
  diff -u -r1.14.2.1 -r1.14.2.2
  --- JspCompiler.java  2000/07/25 20:45:09 1.14.2.1
  +++ JspCompiler.java  2000/11/16 22:10:35 1.14.2.2
  @@ -304,7 +304,11 @@
   public boolean isOutDated() {
   File jspReal = null;
   
  -jspReal = new File(ctxt.getRealPath(jsp.getPath()));
  +String realPath = ctxt.getRealPath(jsp.getPath());
  +if (realPath == null)
  +return true;
  +
  +jspReal = new File(realPath);
   
   File classFile = new File(getClassFileName());
   if (classFile.exists()) {
  
  
  
  1.16.2.5  +3 -0  
jakarta-tomcat/src/share/org/apache/jasper/compiler/JspReader.java
  
  Index: JspReader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspReader.java,v
  retrieving revision 1.16.2.4
  retrieving revision 1.16.2.5
  diff -u -r1.16.2.4 -r1.16.2.5
  --- JspReader.java2000/11/06 04:08:14 1.16.2.4
  +++ JspReader.java2000/11/16 22:10:35 1.16.2.5
  @@ -171,6 +171,9 @@
? file.getAbsolutePath()
: context.getRealPath(file.toString());
   
  + if (longName == null)
  + throw new FileNotFoundException(file.toString());
  +
int fileid = registerSourceFile(longName);

   if (fileid == -1)

[TC4] ResourcesBase.setCheckInterval() bug

2000-11-16 Thread Jason Brittain



Hi guys!

In reading through the org.apache.catalina.resources package code, I found
a small omission from the ResourcesBase.setCheckInterval() method:

public void setCheckInterval(int checkInterval) {

  // Perform the property update
  int oldCheckInterval = this.checkInterval;
  this.checkInterval = checkInterval;
  support.firePropertyChange("checkInterval",
 new Integer(oldCheckInterval),
 new Integer(this.checkInterval));

  // Start or stop the background thread (if necessary)
  if (started) {
  if ((oldCheckInterval  0)  (this.checkInterval = 0))
  threadStop();
  else if ((oldCheckInterval = 0)  (this.checkInterval  0))
  threadStart();
  }

}


At the end of this method, we changed the check interval, and then we
need to either start or stop the background thread that periodically
checks for resource updates.  The code in this method handles the
following:

1. When the background thread is already running and we should be shutting
   it down because the new check interval doesn't require a background
   thread at all.
2. When the thread is supposedly already running, the old check interval
   didn't require a background thread (really, an illegal state -- and 
since
   this code looks basically like my patch below, was this just bad 
placement
   of this code?), and the new check interval does require a background
   thread..  In that case the code at least makes sure that we have
   a reference to a thread.

But, what it doesn't handle is:

3. When the background thread isn't already running, the previous check
   interval didn't require a background thread, and the new check interval
   does require a background thread..  It should start one.

So, here's the patch I'd suggest:

280a281,284
else {
if ((oldCheckInterval = 0)  (this.checkInterval  0))
threadStart();
}

Thanks!

-- 
Jason Brittain  (415)354-6645
Software Engineer, Olliance Inc.http://www.Olliance.com
Current Maintainer, Locomotive Project  http://www.Locomotive.org

Re: FW: sessionID within URL and loadbalance (was: WAP and sessionIDs)




Shai,
Your suggested bugfix is in my stack of changes that I'm going through
at the moment. I don't expect to run into any problems with it, and
plan to incorporate it into post-beta7. I will definitely let you
know if I have any questions.
Thanks for submitting the patch!
Craig

[EMAIL PROTECTED] wrote:



Hi,




This
is my fix to all the WAP question going around lately.

I
have sent last week interceptor that is doing the same (URLSeessionInterceptor)
and you replied that it will be add it to sources after b7.



This
is better way to solve the problem of URL embedded sessionIDs and no-cookie
browsers (WAP).



Please
let me know whether you are going to include that in tomcat 3.2.



(this
fix bug #328)



TIA.



--Shai



-Original
Message-
From:
Shai Fultheim (BRM IL)
Sent:
Thursday, November 16, 2000 01:03
To:
'[EMAIL PROTECTED]'
Cc:
'Craig R. McClanahan'
Subject:
sessionID within URL and loadbalance (was: WAP and sessionIDs)
Importance:
High



Hi
all,



The
patch below fix a bug that didnt let tomcat to run in loadbalance configuration,
while having the session managed only in URL.



The
mail problem with load balancing is that the jvmRoute param (which is the
tomcat name as known from apache side) must be added to the session (ie.
Assuming the sessionid was xxx it have to be changed to xxx.t1 assuming
that t1 is the name of that tomcat instance).



Now,
tomcat handle jvmRoute at his side by adding that parameter to the jsessionid
cookie. THIS IS A BUG, since encode URL still use the original sessionID
(without the .jvmRoute).



In
order to fix that sessionID must be changed so it contains jvmRoute (assuming
we have it). Please see the code fix below.



Please
approve this (and merge with the code ASAP), since cellular phones, which
use WAP (and does not support cookies) cant work with loadbalnce configuration
of apache+tomcat.



Thanks
in advance.





--Shai
Fultheim.



Shai
Fultheim

Chief
Technology Officer

BRM
Seed



E-Mail:
[EMAIL PROTECTED]

Mobile:
972-53-866-459

Office:
972-2-5891-459







Index:
tomcat/request/SessionInterceptor.java

===

RCS
file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/request/SessionInterceptor.java,v

retrieving
revision 1.24.2.2

diff
-u -w -r1.24.2.2 SessionInterceptor.java

---
tomcat/request/SessionInterceptor.java2000/11/11
02:07:021.24.2.2

+++
tomcat/request/SessionInterceptor.java2000/11/15
22:44:05

@@
-75,6 +75,7 @@

*
This implementation only handles Cookies sessions, please extend or

*
add new interceptors for other methods.

*

+
* @author Shai Fultheim [[EMAIL PROTECTED]]Session
contains jsIdent

*/

public
class SessionInterceptor extendsBaseInterceptor

{

@@
-112,8 +113,6 @@



if
((foundAt=uri.indexOf(sig))!=-1){

sessionId=uri.substring(foundAt+sig.length());

-//
I hope the optimizer does it's job:-)

-sessionId
= fixSessionId( request, sessionId );



//
rewrite URL, do I need to do anything more?

request.setRequestURI(uri.substring(0,
foundAt));

@@
-126,24 +125,6 @@

return
0;

}



-/**
Fix the session id. If the session is not valid return null.

-*It
will also clean up the session from load-balancing strings.

-*
@return sessionId, or null if not valid

-*/

-private
String fixSessionId(Request request, String sessionId){

-//
GS, We piggyback the JVM id on top of the session cookie

-//
Separate them ...

-

-if(
debug>0 ) cm.log(" Orig sessionId"
+ sessionId );

-if
(null != sessionId) {

-int
idex = sessionId.lastIndexOf(SESSIONID_ROUTE_SEP);

-if(idex
> 0) {

-sessionId
= sessionId.substring(0, idex);

-}

-}

-return
sessionId;

-}

-

public
int beforeBody( Request rrequest, Response response ) {

String
reqSessionId = response.getSessionId();

if(
debug>0 ) cm.log("Before Body " + reqSessionId );

@@
-159,11 +140,6 @@

sessionPath
= "/";

}



-//
GS, piggyback the jvm route on the session id.

-String
jvmRoute = rrequest.getJvmRoute();

-if(null
!= jvmRoute) {

-reqSessionId
= reqSessionId + SESSIONID_ROUTE_SEP + jvmRoute;

-}



Cookie
cookie = new Cookie("JSESSIONID",

reqSessionId);







Index:
tomcat/session/StandardManager.java

===

RCS
file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/session/Attic/StandardManager.java,v

retrieving
revision 1.11

diff
-u -w -r1.11 StandardManager.java

---
tomcat/session/StandardManager.java2000/06/18
20:14:131.11

+++
tomcat/session/StandardManager.java2000/11/15
22:44:06

@@
-1,5 +1,5 @@

/*

-
* $Header: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/session/Attic/StandardManager.java,v
1.11 2000/06/18 20:14:13 jon Exp $

+
* $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/session/Attic/StandardManager.java,v
1.11 2000/06/18 20:14:13 jon Exp $

*
$Revision: 1.11 $

*
$Date: 2000/06/18 20:14:13 $

*

@@
-102,6 +102,7 @@

*
@author Craig R.

BugRat Report #400 has been filed.


Bug report #400 has just been filed.

You can view the report at the following URL:

   http://znutar.cortexity.com/BugRatViewer/ShowReport/400

REPORT #400 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: 3.1
   JVM Release: 1.2.2
   Operating System: nt
   OS Release: 4.0
   Platform: winnt

Synopsis: 
addCookie will not work if it is followed by sendRedirect

Description:


Title: 
BugRat Report #
400





BugRat Report #
400




Project:
Tomcat


Release:
3.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
_Anonymous ([EMAIL PROTECTED])

Date Submitted:
Nov 16 2000, 05:33:24 CST

Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])


Synopsis:

addCookie will not work if it is followed by sendRedirect


 Environment: (jvm, os, osrel, platform)

1.2.2, nt, 4.0, winnt



Additional Environment Description:





Report Description:





View this report online...

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

2000-11-16 Thread craigmcc


craigmcc00/11/16 15:52:14

  Modified:src/share/org/apache/tomcat/request Tag: tomcat_32
JDBCRealm.java
   src/share/org/apache/tomcat/util Tag: tomcat_32
SecurityTools.java
  Log:
  Avoid "index out of bound" exceptions in the following scenarios:
  * JDBCRealm is configured, user is authenticated successfully,
user has no defined roles, debug output is enabled
  * JDBCRealm is configured, user is authenticated successfully,
security constraint has no defined roles, debug output is enabled
  * Null is passed as an argument to either SecurityTools.haveRole() method.
  
  PR: BugRat Bug Report #372
  Submitted by: Tero Piirainen [EMAIL PROTECTED]
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.9.2.2   +12 -2 
jakarta-tomcat/src/share/org/apache/tomcat/request/JDBCRealm.java
  
  Index: JDBCRealm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/JDBCRealm.java,v
  retrieving revision 1.9.2.1
  retrieving revision 1.9.2.2
  diff -u -r1.9.2.1 -r1.9.2.2
  --- JDBCRealm.java2000/10/17 23:36:24 1.9.2.1
  +++ JDBCRealm.java2000/11/16 23:52:13 1.9.2.2
  @@ -509,12 +509,22 @@
userRoles = getUserRoles( user );
req.setUserRoles( userRoles );
   
  -if( debug  0 ) log( "Auth ok, first role=" + userRoles[0] );
  +if( debug  0 ) {
  +if ((userRoles != null)  (userRoles.length  0))
  +log( "Auth ok, first role=" + userRoles[0] );
  +else
  +log( "Auth ok, user has no roles");
  +}
   
   if( SecurityTools.haveRole( userRoles, roles ))
   return 0;
   
  -if( debug  0 ) log( "UnAuthorized " + roles[0] );
  +if( debug  0 ) {
  +if ((roles != null)  (roles.length  0))
  +log( "UnAuthorized " + roles[0] );
  +else
  +log( "UnAuthorized - no roles specified");
  +}
return 401; //HttpServletResponse.SC_UNAUTHORIZED
   // XXX check transport
   }
  
  
  
  No   revision
  
  
  No   revision
  
  
  1.5.2.1   +5 -1  
jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/SecurityTools.java
  
  Index: SecurityTools.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/SecurityTools.java,v
  retrieving revision 1.5
  retrieving revision 1.5.2.1
  diff -u -r1.5 -r1.5.2.1
  --- SecurityTools.java2000/06/23 02:16:30 1.5
  +++ SecurityTools.java2000/11/16 23:52:14 1.5.2.1
  @@ -192,6 +192,8 @@
   }
   
   public static boolean haveRole( String userRoles[], String requiredRoles[] ) {
  +if ((userRoles == null) || (requiredRoles == null))
  +return false;
for( int i=0; i userRoles.length; i ++ ) {
if( haveRole( userRoles[i], requiredRoles )) return true;
}
  @@ -199,8 +201,10 @@
   }
   
   public static boolean haveRole( String element, String set[] ) {
  +if ((element == null) || (set == null))
  +return false;
for( int i=0; i set.length; i ++ ) {
  - if( element!=null  element.equals( set[i] ))
  + if( element.equals( set[i] ))
return true;
}
return false;

BugRat Report #372 was closed (apparently by: Craig R. McClanahan)


Report #372 was closed by Person #0

   Synopsis: Container managed security bug

 (logged in as: Craig R. McClanahan)

Re: [TC4] ResourcesBase.setCheckInterval() bug


 At the end of this method, we changed the check interval, and then we
 need to either start or stop the background thread that periodically
 checks for resource updates.  The code in this method handles the
 following:

 1. When the background thread is already running and we should be shutting
it down because the new check interval doesn't require a background
thread at all.
 2. When the thread is supposedly already running, the old check interval
didn't require a background thread (really, an illegal state -- and
 since
this code looks basically like my patch below, was this just bad
 placement
of this code?), and the new check interval does require a background
thread..  In that case the code at least makes sure that we have
a reference to a thread.

 But, what it doesn't handle is:

 3. When the background thread isn't already running, the previous check
interval didn't require a background thread, and the new check interval
does require a background thread..  It should start one.

 So, here's the patch I'd suggest:

 280a281,284
 else {
 if ((oldCheckInterval = 0)  (this.checkInterval  0))
 threadStart();
 }

The "started" flag indicates that the component has been started. It's
related to the thread state since the thread cannot be started if the
started flag is not set to true. The flag is set by the start() and stop()
method. If the component hasn't been started yet, I don't think it should
start the thread (or try to stop it).
Does it make sense (or did I miss something ?) ?

Remy (going back to optimizing the HTTP connector)

Tomcat working with Netscape Enterprise Server on Solaris

2000-11-16 Thread Joan Xiao


I tried "make -f Makefiel.solaris" in jakarta-tomcat/src/native/iis_netscape
directory,
and got the following error:

jk_nsapi_plugin.c:71: nsapi.h: No such file or directory
*** Error code 1
make: Fatal error: Command failed for traget 'jk_nsapi_plugin.o'

I used the souce code from release 3.1. There is no nsapi.h in this
directory. Any help 
is highly appreciated. 

Joan

Re: [TC4] ResourcesBase.setCheckInterval() bug


Hi Jason,

See below.

Jason Brittain wrote:

 Hi guys!

 In reading through the org.apache.catalina.resources package code, I found
 a small omission from the ResourcesBase.setCheckInterval() method:

 public void setCheckInterval(int checkInterval) {

   // Perform the property update
   int oldCheckInterval = this.checkInterval;
   this.checkInterval = checkInterval;
   support.firePropertyChange("checkInterval",
  new Integer(oldCheckInterval),
  new Integer(this.checkInterval));

   // Start or stop the background thread (if necessary)
   if (started) {
   if ((oldCheckInterval  0)  (this.checkInterval = 0))
   threadStop();
   else if ((oldCheckInterval = 0)  (this.checkInterval  0))
   threadStart();
   }

 }

 At the end of this method, we changed the check interval, and then we
 need to either start or stop the background thread that periodically
 checks for resource updates.  The code in this method handles the
 following:

 1. When the background thread is already running and we should be shutting
it down because the new check interval doesn't require a background
thread at all.
 2. When the thread is supposedly already running, the old check interval
didn't require a background thread (really, an illegal state -- and
 since
this code looks basically like my patch below, was this just bad
 placement
of this code?), and the new check interval does require a background
thread..  In that case the code at least makes sure that we have
a reference to a thread.

 But, what it doesn't handle is:

 3. When the background thread isn't already running, the previous check
interval didn't require a background thread, and the new check interval
does require a background thread..  It should start one.

 So, here's the patch I'd suggest:

 280a281,284
 else {
 if ((oldCheckInterval = 0)  (this.checkInterval  0))
 threadStart();
 }


You're correct that this kind of code is appropriate (because the component
has already been started without the thread).  What's puzzling me is that my
copy of ResourcesBase.java (version 1.3, last updated 2000/10/17) already
includes code very similar to this.  Checking the CVS logs, it seems that this
code has been there at least since we moved Catalina over to the new
"jakarta-tomcat-4.0" CVS repository in August.

What version of Tomcat 4.0 sources are you looking at?


 Thanks!

 --
 Jason Brittain  (415)354-6645

Craig

Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug

2000-11-16 Thread Jason Brittain



Hi Remy.

Oops, yes, you're right about this (of course).  I misunderstood the use 
of the
"started" variable to mean whether or not the background thread was already
started, instead of whether the component's lifecycle had started.  Sorry.

BTW: I really like the resources package!  I can think of several useful
implementations that I'd like to use, like one for CVS, or one for JavaMail,
or ...  lots more.

Remy Maucherat wrote:

 At the end of this method, we changed the check interval, and then we
 need to either start or stop the background thread that periodically
 checks for resource updates.  The code in this method handles the
 following:
 
 1. When the background thread is already running and we should be shutting
it down because the new check interval doesn't require a background
thread at all.
 2. When the thread is supposedly already running, the old check interval
didn't require a background thread (really, an illegal state -- and
 since
this code looks basically like my patch below, was this just bad
 placement
of this code?), and the new check interval does require a background
thread..  In that case the code at least makes sure that we have
a reference to a thread.
 
 But, what it doesn't handle is:
 
 3. When the background thread isn't already running, the previous check
interval didn't require a background thread, and the new check interval
does require a background thread..  It should start one.
 
 So, here's the patch I'd suggest:
 
 280a281,284
 else {
 if ((oldCheckInterval = 0)  (this.checkInterval  0))
 threadStart();
 }
 
 
 The "started" flag indicates that the component has been started. It's
 related to the thread state since the thread cannot be started if the
 started flag is not set to true. The flag is set by the start() and stop()
 method. If the component hasn't been started yet, I don't think it should
 start the thread (or try to stop it).
 Does it make sense (or did I miss something ?) ?
 
 Remy (going back to optimizing the HTTP connector)
 
-- 
Jason Brittain
Software Engineer, Olliance Inc.http://www.Olliance.com
Current Maintainer, Locomotive Project  http://www.Locomotive.org

Re: [TC4] ResourcesBase.setCheckInterval() bug


 You're correct that this kind of code is appropriate (because the
component
 has already been started without the thread).

Really ? The threadStart() call is in the start() method, and threadStop()
is always called in stop(). How would the thread need to be started if the
component is not started yet ?

 What's puzzling me is that my
 copy of ResourcesBase.java (version 1.3, last updated 2000/10/17) already
 includes code very similar to this.  Checking the CVS logs, it seems that
this
 code has been there at least since we moved Catalina over to the new
 "jakarta-tomcat-4.0" CVS repository in August.

Remy

Re: Tomcat working with Netscape Enterprise Server on Solaris

2000-11-16 Thread Mike Anderson




nsapi.h is included with the webserver install. It will 
be in an include directory underneath the main netscape directory.

Mike Anderson [EMAIL PROTECTED] 
11/16/00 04:55PM I tried "make -f Makefiel.solaris" in 
jakarta-tomcat/src/native/iis_netscapedirectory,and got the following 
error:jk_nsapi_plugin.c:71: nsapi.h: No such file or directory*** 
Error code 1make: Fatal error: Command failed for traget 
'jk_nsapi_plugin.o'I used the souce code from release 3.1. There is no 
nsapi.h in thisdirectory. Any help is highly appreciated. 
Joan

Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug


Jason Brittain wrote:


 BTW: I really like the resources package!  I can think of several useful
 implementations that I'd like to use, like one for CVS, or one for JavaMail,
 or ...  lots more.

I like the Resources abstraction as well.  Before we go whole hog at creating new
implementations, though, I'd like us to consider one (possibly hair-brained)
idea.

The major purpose for creating the Resources abstraction in the first place was
to hide the distinctions about *how* resources were accessed from the rest of the
servlet container.  The Resources interface (as extended by Remy to support what
WebDAV needs) does this, but is not the only way to accomplish it.

What would you think about using a JNDI DirContext as a representation of the
resources available to a web application?  The idea would be to use directory
entry attributes for the commonly used information like "last modified date" and
"number of bytes in this resource", rather than Java properties.  We'd want to
standardize on attribute names to be used (perhaps starting from the File
directory context already available with JNDI) so that the rest of the servlet
container can access them.  Obviously, this would be a per-webapp structure, just
like the naming context for env-entry and resource-entry things is.  In fact
... maybe it could even be a subcontext of that very same context ...

What do you think?

Craig McClanahan

Re: [TC4] ResourcesBase.setCheckInterval() bug and HTTP


 Remy Maucherat wrote:

   You're correct that this kind of code is appropriate (because the
  component
   has already been started without the thread).
 
  Really ? The threadStart() call is in the start() method, and
threadStop()
  is always called in stop(). How would the thread need to be started if
the
  component is not started yet ?
 

 Consider that you might initialize a resources object with this (among
other
 stuff):

 resources.setCheckInterval(0);
 resources.start();

 and later on, while the container is running, an admin application
executes
 this:

 resources.setCheckInterval(15);

 The thread wasn't started inside resources.start() because the check
interval
 was zero at that time.  Therefore, it *does* need to be started if
 setCheckInterval() is called later.

 if (started) {
 if ((oldCheckInterval  0)  (this.checkInterval = 0))
  threadStop();
 else if ((oldCheckInterval = 0)  (this.checkInterval  0))
  threadStart();
 }

I think it is.
In your case, the first setCheckInterval(0) won't start the thread, as
started = false.
The started flag is switched to true by start().
The setCheckInterval(15) will start the thread correctly, since (started) is
true, and ((oldCheckInterval = 0)  (this.checkInterval  0)) is true too
(the old value was too low, the new one is right).

 For long-running servers, we need to remember that configuration is not a
 one-time event.  (By the way, IMHO, this is one of the few places where
Avalon
 doesn't quite "get it".)

There was a reconfigurable interface at some point. I don't know if it's
still there.

The new HTTP stuff looks like it's working. I tested with all my servlets
suite (including Slide), and I was using ridiculously small buffers (between
1 and 4 bytes) while testing.
HttpProcessor is still very similar to what it was before (but not for
long). Basically, what I did is I wrote a set of buffer classes (which I can
recycle), and I wraped the socket input stream using a tweaked
BufferedInputStream. This input stream directly manipulates the internal
buffer and the position pointer to achieve maximum performance. I don't
think that part can be optimized more, since whatever happens, I'm only
reading a character (from the internal buffer) once for every operation
(reading the request line or reading the headers).
What is coming next is that the HttpProcessor and the Request object will
only use those recyclable objects (instead of Strings). Hopefully, the only
things which will have to be garbage collected is the Strings generated for
many of the servlet API function calls. That should bring another very nice
increase in performance :)
After that, I'll optimize the output, as Costin suggested.

Remy

Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug


  BTW: I really like the resources package!  I can think of several useful
  implementations that I'd like to use, like one for CVS, or one for
JavaMail,
  or ...  lots more.

 I like the Resources abstraction as well.  Before we go whole hog at
creating new
 implementations, though, I'd like us to consider one (possibly
hair-brained)
 idea.

 The major purpose for creating the Resources abstraction in the first
place was
 to hide the distinctions about *how* resources were accessed from the rest
of the
 servlet container.  The Resources interface (as extended by Remy to
support what
 WebDAV needs) does this, but is not the only way to accomplish it.

 What would you think about using a JNDI DirContext as a representation of
the
 resources available to a web application?  The idea would be to use
directory
 entry attributes for the commonly used information like "last modified
date" and
 "number of bytes in this resource", rather than Java properties.  We'd
want to
 standardize on attribute names to be used (perhaps starting from the File
 directory context already available with JNDI) so that the rest of the
servlet
 container can access them.  Obviously, this would be a per-webapp
structure, just
 like the naming context for env-entry and resource-entry things is.
In fact
 ... maybe it could even be a subcontext of that very same context ...

 What do you think?

Here's what I'll do.
I'll add an org.apache.naming.resource.FileDirContext class, which will be
an implementation of javax.naming.DirContext. It will be built by the
factory.ResourceFactory.
The Resource will be declared in the web app descriptor as a resource-ref
element. Additional parameters (path, ...) will be specified there too.
The factory will actually return an
org.apache.naming.resource.CacheDirContext which wraps the real DirContext
to provide transparent caching.
The resources will be availible through the usual java:/ URL.

Questions :
- Do we keep the current Resources ?
- Isn't it a bit late in the release process to do that big change ? I can
do the FileDirContext and CacheDirContext, and test them with a few
servlets, no problem, but I'm thinking about rewriting DefaultServlet and
WebdavServlet (ouch, that hurts ...). Can we do that for 4.1 ?

Remy

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

2000-11-16 Thread remm


remm00/11/16 18:58:59

  Modified:catalina/src/share/org/apache/catalina/connector
RequestBase.java
  Log:
  - Opening the stream is useless if there's nothing to read.
  
  Revision  ChangesPath
  1.7   +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java
  
  Index: RequestBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- RequestBase.java  2000/11/15 00:46:41 1.6
  +++ RequestBase.java  2000/11/17 02:58:59 1.7
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java,v
 1.6 2000/11/15 00:46:41 remm Exp $
  - * $Revision: 1.6 $
  - * $Date: 2000/11/15 00:46:41 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java,v
 1.7 2000/11/17 02:58:59 remm Exp $
  + * $Revision: 1.7 $
  + * $Date: 2000/11/17 02:58:59 $
*
* 
*
  @@ -97,7 +97,7 @@
* the connector-specific methods need to be implemented.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.6 $ $Date: 2000/11/15 00:46:41 $
  + * @version $Revision: 1.7 $ $Date: 2000/11/17 02:58:59 $
*/
   
   public abstract class RequestBase
  @@ -485,7 +485,7 @@
   
   // If neither a reader or an is have been opened, do it to consume
   // request bytes, if any
  -if ((reader == null)  (stream == null))
  +if ((reader == null)  (stream == null)  (getContentLength() != 0))
   getInputStream();
   
// If a Reader has been acquired, close it

Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug

2000-11-16 Thread Boyd Waters


[...this un-lurking is getting habit-forming...]

"Craig R. McClanahan" wrote:
 
 What would you think about using a JNDI DirContext as a representation of the
 resources available to a web application?  The idea would be to use directory
 entry attributes for the commonly used information like "last modified date" and
 "number of bytes in this resource", rather than Java properties.  We'd want to
 standardize on attribute names to be used (perhaps starting from the File
 directory context already available with JNDI) so that the rest of the servlet
 container can access them.  Obviously, this would be a per-webapp structure, just
 like the naming context for env-entry and resource-entry things is.  In fact
 ... maybe it could even be a subcontext of that very same context ...

Craig:

 I think that the *option* for Catalina to interact with a larger
namespace is a Good Idea, but my experiments with JNDI implementations
show these to be rather heavyweight systems.

OK, so a relational database is heavyweight, too... hmm.

I am working on RDF indexes of web content, and am planning a WebDAV
properties store thingy that might use Guha's RDFdb.

OK, I suppose a JNDI thing is the same design pattern. FWIW, I say go
for it...

--boyd

-
Boyd Waters  [EMAIL PROTECTED]
National Radio Astronomy Observatory  http://www.nrao.edu
PO Box 0 Socorro, NM 87801   505.835.7346

http://www.zocalo.net/~waters
[EMAIL PROTECTED]
-

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpHeader.java HttpRequestLine.java SocketInputStream.java HttpProcessor.java LocalStrings.properties

2000-11-16 Thread remm


remm00/11/16 19:30:43

  Modified:catalina/src/share/org/apache/catalina/connector/http
HttpProcessor.java LocalStrings.properties
  Added:   catalina/src/share/org/apache/catalina/connector/http
HttpHeader.java HttpRequestLine.java
SocketInputStream.java
  Log:
  - Optimized the socket byte reading, which results in a big boost of the
connector performance. Overall servlet performance is increased by around
30%, and is on par with the current CVS version of Tomcat 3.3.
  - Add some recyclable specilized buffer objects for the handling of the
request line and the headers.
  - HttpProcessor currently do not take advantage of these objects, and wrap
them into String objects immediately after reading them. Very little changes
have been made to the HTTP processor, so far.
  - The request header parsing is now done inside the socket stream, to get
maximum performance.
  - The new buffer objects will eventually allow to have 0 GC inside the
connector.
  
  Revision  ChangesPath
  1.12  +57 -76
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java
  
  Index: HttpProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- HttpProcessor.java2000/11/11 01:38:09 1.11
  +++ HttpProcessor.java2000/11/17 03:30:43 1.12
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
 1.11 2000/11/11 01:38:09 craigmcc Exp $
  - * $Revision: 1.11 $
  - * $Date: 2000/11/11 01:38:09 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
 1.12 2000/11/17 03:30:43 remm Exp $
  + * $Revision: 1.12 $
  + * $Date: 2000/11/17 03:30:43 $
*
* 
*
  @@ -106,7 +106,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.11 $ $Date: 2000/11/11 01:38:09 $
  + * @version $Revision: 1.12 $ $Date: 2000/11/17 03:30:43 $
*/
   
   final class HttpProcessor
  @@ -272,6 +272,24 @@
   private static final byte[] CRLF = (new String("\r\n")).getBytes();
   
   
  +/**
  + * Line buffer.
  + */
  +private char[] lineBuffer = new char[4096];
  +
  +
  +/**
  + * Request line buffer.
  + */
  +private HttpRequestLine requestLine = new HttpRequestLine();
  +
  +
  +/**
  + * HTTP header.
  + */
  +private HttpHeader header = new HttpHeader();
  +
  +
   //  Package Methods
   
   
  @@ -497,27 +515,33 @@
* @exception IOException if an input/output error occurs
* @exception ServletException if a parsing error occurs
*/
  -private void parseHeaders(InputStream input)
  +private void parseHeaders(SocketInputStream input)
   throws IOException, ServletException {
   
while (true) {
  -
  - // Read the next header line
  - String line = read(input);
  - if ((line == null) || (line.length()  1))
  - break;
   
  - // Parse the header name and value
  - int colon = line.indexOf(":");
  - if (colon  0)
  - throw new ServletException
  - (sm.getString("httpProcessor.parseHeaders.colon"));
  - String name = line.substring(0, colon).trim();
  - String match = name.toLowerCase();
  - String value = line.substring(colon + 1).trim();
  +try {
  +// Read the next header
  +input.readHeader(header);
  +} catch (Throwable t) {
  +t.printStackTrace();
  +}
  +if (header.nameEnd == 0) {
  +if (header.valueEnd == 0) {
  +return;
  +} else {
  +throw new ServletException
  +(sm.getString("httpProcessor.parseHeaders.colon"));
  +}
  +}
  +
  + String name = new String(header.name, 0, header.nameEnd);
  + String match = name;
  + String value = new String(header.value, 0, header.valueEnd);
  +//System.out.println("  Header:" + name + "_ Value:" + value + "_");
if (debug = 1)
log(" Header " + name + " = " + value);
  -
  +
// Set the corresponding request headers
if (match.equals("authorization")) {
request.setAuthorization(value);
  @@ -603,26 +627,20 @@
* @exception

Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug

2000-11-16 Thread Boyd Waters


Boyd Waters wrote:
 
 [...this un-lurking is getting habit-forming...]
 
 "Craig R. McClanahan" wrote:
 
  What would you think about using a JNDI DirContext as a representation of the
  resources available to a web application? 

 Craig:
 
  I think that the *option* for Catalina to interact with a larger
 namespace is a Good Idea, but my experiments with JNDI implementations
 show these to be rather heavyweight systems.

um, never mind...

Sorry about this, I'm just coming up to speed on the Tomcat/Catalina
architecture. I see that you're using JNDI internally already.

I'm studying the code, trying to figure out where I can patch my RDF
properties storage in...

[...resume lurking mode...]

-- boyd

-
Boyd Waters  [EMAIL PROTECTED]
National Radio Astronomy Observatory  http://www.nrao.edu
PO Box 0 Socorro, NM 87801   505.835.7346

http://www.zocalo.net/~waters
[EMAIL PROTECTED]
-

BugRat Report #402 has been filed.