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

[remm]

remm01/10/03 22:51:38

  Modified:webapps  build.xml
  Log:
  - Fix some problems with handling of the base directory path. The output
directory could apparently be wrong when invoking Ant in one of the
subprojects (although I never experienced the problem).
Patch submitted by Patrick Luby (Patrick.Luby at sun.com).
  
  Revision  ChangesPath
  1.18  +3 -3  jakarta-tomcat-4.0/webapps/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/build.xml,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- build.xml 2001/09/16 04:58:28 1.17
  +++ build.xml 2001/10/04 05:51:38 1.18
  @@ -10,9 +10,9 @@
 
   
 
  -  
  -  
  -  
  +  
  +  
  +  
   
   
 
  
  
  

cvs commit: jakarta-tomcat-4.0/tester build.xml

[remm]

remm01/10/03 22:51:22

  Modified:tester   build.xml
  Log:
  - Fix some problems with handling of the base directory path. The output
directory could apparently be wrong when invoking Ant in one of the
subprojects (although I never experienced the problem).
Patch submitted by Patrick Luby (Patrick.Luby at sun.com).
  
  Revision  ChangesPath
  1.16  +3 -3  jakarta-tomcat-4.0/tester/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/build.xml,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- build.xml 2001/10/03 21:39:12 1.15
  +++ build.xml 2001/10/04 05:51:22 1.16
  @@ -9,9 +9,9 @@
   
 
 
  -  
  -  
  -  
  +  
  +  
  +  
   
 
 
  
  
  

cvs commit: jakarta-tomcat-4.0/jasper build.xml

[remm]

remm01/10/03 22:51:12

  Modified:jasper   build.xml
  Log:
  - Fix some problems with handling of the base directory path. The output
directory could apparently be wrong when invoking Ant in one of the
subprojects (although I never experienced the problem).
Patch submitted by Patrick Luby (Patrick.Luby at sun.com).
  
  Revision  ChangesPath
  1.26  +3 -3  jakarta-tomcat-4.0/jasper/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/build.xml,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- build.xml 2001/10/03 21:39:12 1.25
  +++ build.xml 2001/10/04 05:51:12 1.26
  @@ -11,9 +11,9 @@
   
 
 
  -  
  -  
  -  
  +  
  +  
  +  
 
 
 
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina build.xml

[remm]

remm01/10/03 22:51:03

  Modified:catalina build.xml
  Log:
  - Fix some problems with handling of the base directory path. The output
directory could apparently be wrong when invoking Ant in one of the
subprojects (although I never experienced the problem).
Patch submitted by Patrick Luby (Patrick.Luby at sun.com).
  
  Revision  ChangesPath
  1.75  +3 -3  jakarta-tomcat-4.0/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
  retrieving revision 1.74
  retrieving revision 1.75
  diff -u -r1.74 -r1.75
  --- build.xml 2001/10/03 22:59:43 1.74
  +++ build.xml 2001/10/04 05:51:03 1.75
  @@ -11,9 +11,9 @@
   
 
 
  -  
  -  
  -  
  +  
  +  
  +  
 
 
 
  
  
  

DO NOT REPLY [Bug 3949] - Document with content-length of 0 results in resend headers

[bugzilla]

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

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

Document with content-length of 0  results in resend headers

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 22:48 ---
Fixed in the 10/04/2001 nightly.

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

[remm]

remm01/10/03 22:44:43

  Modified:catalina/src/share/org/apache/catalina/connector/http
HttpProcessor.java
  Log:
  - Add a flag to indicate that we'll finish the response. We don't if the problem
is an EOFException while parsing the request header.
Fixes bug 3949.
  
  Revision  ChangesPath
  1.37  +16 -8 
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.36
  retrieving revision 1.37
  diff -u -r1.36 -r1.37
  --- HttpProcessor.java2001/09/05 00:31:50 1.36
  +++ HttpProcessor.java2001/10/04 05:44:43 1.37
  @@ -1,6 +1,6 @@
  -/* * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
 1.36 2001/09/05 00:31:50 craigmcc Exp $
  - * $Revision: 1.36 $
  - * $Date: 2001/09/05 00:31:50 $
  +/* * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
 1.37 2001/10/04 05:44:43 remm Exp $
  + * $Revision: 1.37 $
  + * $Date: 2001/10/04 05:44:43 $
*
* 
*
  @@ -106,7 +106,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.36 $ $Date: 2001/09/05 00:31:50 $
  + * @version $Revision: 1.37 $ $Date: 2001/10/04 05:44:43 $
*/
   
   final class HttpProcessor
  @@ -919,6 +919,7 @@
   private void process(Socket socket) {
   
   boolean ok = true;
  +boolean finishResponse = true;
   SocketInputStream input = null;
   OutputStream output = null;
   
  @@ -935,6 +936,8 @@
   
   while (!stopped && ok && keepAlive) {
   
  +finishResponse = true;
  +
   try {
   request.setStream(input);
   request.setResponse(response);
  @@ -966,7 +969,10 @@
   }
   }
   } catch (EOFException e) {
  +// It's very likely to be a socket disconnect on either the 
  +// client or the server
   ok = false;
  +finishResponse = false;
   } catch (ServletException e) {
   ok = false;
   try {
  @@ -1028,10 +1034,12 @@
   
   // Finish up the handling of the request
   try {
  -response.finishResponse();
  -request.finishRequest();
  -if (output != null)
  -output.flush();
  +if (finishResponse) {
  +response.finishResponse();
  +request.finishRequest();
  +if (output != null)
  +output.flush();
  +}
   } catch (IOException e) {
   ok = false;
   }
  
  
  

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

[remm]

remm01/10/03 22:43:20

  Modified:catalina/src/share/org/apache/catalina/connector/http
HttpResponseStream.java
  Log:
  - Use setHeader to avoid setting duplicate headers.
  
  Revision  ChangesPath
  1.9   +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java
  
  Index: HttpResponseStream.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- HttpResponseStream.java   2001/09/28 23:34:02 1.8
  +++ HttpResponseStream.java   2001/10/04 05:43:20 1.9
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java,v
 1.8 2001/09/28 23:34:02 remm Exp $
  - * $Revision: 1.8 $
  - * $Date: 2001/09/28 23:34:02 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java,v
 1.9 2001/10/04 05:43:20 remm Exp $
  + * $Revision: 1.9 $
  + * $Date: 2001/10/04 05:43:20 $
*
* 
*
  @@ -218,14 +218,14 @@
   if (!response.isChunkingAllowed() && useChunking) {
   // If we should chunk, but chunking is forbidden by the connector,
   // we close the connection
  -response.addHeader("Connection", "close");
  +response.setHeader("Connection", "close");
   } else {
   response.removeHeader("Connection", "close");
   }
   // Don't chunk is the connection will be closed
   useChunking = (useChunking && !response.isCloseConnection());
   if (useChunking)
  -response.addHeader("Transfer-Encoding", "chunked");
  +response.setHeader("Transfer-Encoding", "chunked");
   else
   response.removeHeader("Transfer-Encoding", "chunked");
   }
  
  
  

Re: Volunteers for: - RE: TC 3.3: getRequestURI()

[Bojan Smojver]

Bojan Smojver wrote:
> 
> [EMAIL PROTECTED] wrote:
> 
> > I don't think I can do this alone ( if it sounded like I volunteer to fix
> > it - well, I need  help ).
> 
> > - Test.
> 
> I'm one of those overly brave and too stupid that put CVS versions of
> software in production environment. Promise to give it a bashing within
> my applications.

My first tests show that today's version of both Tomcat 3.3 and mod_jk
that comes with it are fine on this issue. Hurray!

Bojan

PS. OK, let's move this baby to production server... ;-)

[PATCH] 4 jakarta-tomcat-4.0 build.xml files

[Patrick Luby]

Hello,

Can someone review and commit the following 4 patches to the HEAD branch of 
jakarta-tomcat-4.0?

  catalina/build.xml
  jasper/build.xml
  tester/build.xml
  webapps/build.xml
  
These 4 patches correct a problem when invoking ant within any of the above 4 
directories. Prior to these patches, ant would create "build" and "dist" 
directories in a different place than if ant was invoked in the 
jakarta-tomcat-4.0 topmost directory. As a result, ant would create strange 
extraneous directories like the following in the distribution:

  webapps/build/examples/build/examples/build/examples

Thanks,

Patrick


Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.74
diff -u -r1.74 build.xml
--- build.xml   2001/10/03 22:59:43 1.74
+++ build.xml   2001/10/04 04:39:06
@@ -11,9 +11,9 @@
 
   
   
-  
-  
-  
+  
+  
+  
   
   
   


Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/jasper/build.xml,v
retrieving revision 1.25
diff -u -r1.25 build.xml
--- build.xml   2001/10/03 21:39:12 1.25
+++ build.xml   2001/10/04 04:39:27
@@ -11,9 +11,9 @@
 
   
   
-  
-  
-  
+  
+  
+  
   
   
   


Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/tester/build.xml,v
retrieving revision 1.15
diff -u -r1.15 build.xml
--- build.xml   2001/10/03 21:39:12 1.15
+++ build.xml   2001/10/04 04:41:31
@@ -9,9 +9,9 @@
 
   
   
-  
-  
-  
+  
+  
+  
 
   
   


Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/build.xml,v
retrieving revision 1.17
diff -u -r1.17 build.xml
--- build.xml   2001/09/16 04:58:28 1.17
+++ build.xml   2001/10/04 04:40:08
@@ -10,9 +10,9 @@
   
 
   
-  
-  
-  
+  
+  
+  
 
 
   

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

[remm]

remm01/10/03 20:36:50

  Modified:catalina/src/share/org/apache/catalina/connector
HttpResponseBase.java
  Log:
  - Remove dead code.
  
  Revision  ChangesPath
  1.39  +4 -12 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
  
  Index: HttpResponseBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
  retrieving revision 1.38
  retrieving revision 1.39
  diff -u -r1.38 -r1.39
  --- HttpResponseBase.java 2001/09/27 00:58:38 1.38
  +++ HttpResponseBase.java 2001/10/04 03:36:49 1.39
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
 1.38 2001/09/27 00:58:38 remm Exp $
  - * $Revision: 1.38 $
  - * $Date: 2001/09/27 00:58:38 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
 1.39 2001/10/04 03:36:49 remm Exp $
  + * $Revision: 1.39 $
  + * $Date: 2001/10/04 03:36:49 $
*
* 
*
  @@ -101,7 +101,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.38 $ $Date: 2001/09/27 00:58:38 $
  + * @version $Revision: 1.39 $ $Date: 2001/10/04 03:36:49 $
*/
   
   public class HttpResponseBase
  @@ -319,14 +319,6 @@
   
   return (this.status);
   
  -}
  -
  -
  -/**
  - * Recycle the facade object.
  - */
  -public void recycleFacade() {
  -facade = new HttpResponseFacade(this);
   }
   
   
  
  
  

cvs commit: jakarta-tomcat-4.0 tomcat.nsi

[remm]

remm01/10/03 20:01:46

  Modified:.tomcat.nsi
  Log:
  - Update for the new shared directories.
  
  Revision  ChangesPath
  1.18  +4 -4  jakarta-tomcat-4.0/tomcat.nsi
  
  Index: tomcat.nsi
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tomcat.nsi,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- tomcat.nsi2001/10/02 08:10:33 1.17
  +++ tomcat.nsi2001/10/04 03:01:46 1.18
  @@ -1,6 +1,6 @@
   
   ; Tomcat 4 script for Nullsoft Installer
  -; $Id: tomcat.nsi,v 1.17 2001/10/02 08:10:33 remm Exp $
  +; $Id: tomcat.nsi,v 1.18 2001/10/04 03:01:46 remm Exp $
   
   Name "apache-tomcat-4.0"
   Caption "Apache Tomcat 4.0"
  @@ -41,7 +41,7 @@
 File LICENSE
 File /r bin
 File /r common
  -  File /r lib
  +  File /r shared
 File /r logs
 File /r server
 File /r work
  @@ -248,7 +248,7 @@
 File LICENSE
 File /r bin
 File /r common
  -  File /r lib
  +  File /r shared
 File /r logs
 File /r server
 File /r work
  @@ -297,7 +297,7 @@
 RMDir /r "$INSTDIR\bin"
 RMDir /r "$INSTDIR\common"
 Delete "$INSTDIR\conf\*.dtd"
  -  RMDir /r "$INSTDIR\lib"
  +  RMDir /r "$INSTDIR\shared"
 RMDir "$INSTDIR\logs"
 RMDir /r "$INSTDIR\server"
 RMDir /r "$INSTDIR\webapps\manager"
  
  
  

RE: [half-off-topic] Java Compilers

[Deacon Marcus]

Hi,

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Craig R. McClanahan
> Sent: Thursday, October 04, 2001 4:42 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [half-off-topic] Java Compilers
[...]
> A conversation on a semi-related topic is currently running on the
> [EMAIL PROTECTED] list, about the potential contribution of the
> "bcel" library to Jakarta.

Thanks, I'll take a look.

> It would be quite interesting if BCEL and/or your code could be used to
> create the generated classes for JSP pages without going through a Java
> compiler.
>
> > Greetings, deacon Marcus
> >
> > p.s. Is it ok for me to use org.apache.jjc (or org.apache.
> whatever) before
> > I officialy donate it, assuming I won't be distributing it
> before donating
> > anyway?
>
> It would *not* be wise to use org.apache under false pretenses.  Even
> though you don't *intend* to distribute, it's difficult to move forward on
> an idea like this without showing it to some people.

Too bad I just did... don't sue me please :/ I'll change it next version.

> Also, there's no guarantee that Apache will accept it anyway -- especially
> if there is not already a development community built up around it.

> Craig

Greetings, deacon Marcus

RE: [half-off-topic] Java Compilers

[Deacon Marcus]

Hi,

> From: Aaron Mulder [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 04, 2001 3:47 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [half-off-topic] Java Compilers
>
>
>   If you haven't seen it already, there's an article on the Swing
> Connection on creating dynamic event listeners or some such which seems to

Could you give me url please?

> have been the basis for the Dynamic Proxy support in JDK 1.3.  It has

If I'm thinking about the same thing, that's what I'm scared of - I want to
"staticize" things, not to make them more dynamic.
Consider the following example:
Program - let's assume it's HTTP server. The server calls "cache" for
RuleProcessor object, which has a single method like "boolean
clientAllowed(RequestData rd)". Then, Cache checks the file "rules.xml" - if
it was modified recently (or not read before), it's loaded, converted from
xml to source implementing the interface specifing method clientAllowed,
then compiled. Finally Server gets RuleProcessor compiled from xml file
(possibly using xsl transformation, but that's not my area). The point is,
rules.xml is interpreted, and then compiled, only after changes are
detected, then Server gets object running extremely fast compared even to
most optimized data structures.

Then again, maybe the savings aren't that much? Correct me if I'm wrong?

For example:


  
/localonly/*
1.2.3.4
1.2.3.5

  
  
/*
*.crackers.net

  


Could be compiled into:

public class Xxx implements RuleProcessor
 {

  public boolean clientAllowed(RequestData rd)
   {
if( rd.getUri().startsWith("/localonly/")
 {
  if( rd.getIp().equals("1.2.3.4") )
   {
return true;
   }
  //...
  return false;
 }
else if( rd.getUri().startsWith("/")
 {
  if( rd.getHost().endsWith(".crackers.net") )
   {
return false;
   }
  return true;
 }
else
 {
  return false;
 }
   }

 }


I'm attaching minimalistic proof-of-concept implementation.

> source code for generating classes on the fly that implement arbitrary
> interfaces, including some generic routines for writing useful bits of
> bytecode.  If your goals are limited enough in scope, you may want to skip
> the source code and just spew out bytecode directly based on the XML file
> you're reading.
>   Also, I have JDK 1.2 implementation of Dynamic Proxies that you're
> welcome to look at, based on the aforementioned article.
>
> Aaron
>

Greetings, deacon Marcus
~
HELP STARVING JAVA PROGRAMMER: If you need cheap and reliable JSP hosting,
please contact [EMAIL PROTECTED] (from 12$/m for 50mb WWW + 20mb mail)


=
> On Thu, 4 Oct 2001, Deacon Marcus wrote:
> > Hi,
> >
> > > From: Dmitri Colebatch [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, October 04, 2001 2:35 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: [half-off-topic] Java Compilers
> > >
> > >
> > > Hi,
> > >
> > > On Thu, 4 Oct 2001, Deacon Marcus wrote:
> > >
> > > > There would be two classes, CompileUnit and CompileContext.
> > > > First, you create a CompileContext, initialize it with
> working dir and
> > > > classpath, then you create CompileUnit, initialize it with
> > > CompileContext
> > > > and a .java file. Then, you can call .prepare() or .compile()
> > > to compile the
> > > > file, and .newInstance() to create an instance or .getClass()
> > > to get Class.
> > > > Or you could use Class.forName(), since in most cases
> CompileContext's
> > > > classpath would be active classpath.
> > > so you're talking about generating java source code, and
> compiling it on
> > > the fly?
> >
> > Exactly.
> > I'm coding it right now - looks like CompileContext is enough -
> I'll post
> > when I finish of course.
> >
> > > > I'm sure you see the similarity to .JSP now.
> > > if my interpretation is correct, yes (o:
> > >
> > > > While it may seem basic, having API for this wouldn't hurt.
> > > > Possible scenario:
> > > > Supponse, there's some kind of mail server with *extremely*
> complicated
> > > > rule-set in form of 200kb+ xml. Why not take it, convert it
> into .java
> > > > implementing some interface, convert it to java source with
> > > hundreds if not
> > > > more ifs and cases, and load it as compiled code.
> > > > What I need: since JDK 1.4b2, tools.jar just isn't what it used
> > > to be... so
> > > > I need some kind of 100% java java compiler. And, I have no
> > > idea where to
> > > > search for one. Of course, there's dozens, but it must be both
> > > stable and
> > > > compatible with JDK 1.1 - 1.4.
> > > Short of searching google, which I'm sure you're already
> doing I cant help
> > > you there.  What I can suggest though, is for source code
> generation, a
> > > project called Jenesis (http://www.inxar.org) which provides
> a nice API
> > > based on the Java Language spec.
> >
> > Generating source is out of scope of this project.
> > I need it mainly for the complicated configs etc - no point in
> generating
> > s

Re: DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[Bojan Smojver]

Bojan Smojver wrote:
> 
> I have done this with TC 3.3, Apache 1.3.20 + mod_jk and my own form
> based authentication:

Just to clarify here, 'my own' means in my own app, not something I've
coded separately from TC.

Bojan

Re: [half-off-topic] Java Compilers

[Craig R. McClanahan]

On Thu, 4 Oct 2001, Deacon Marcus wrote:

> Date: Thu, 4 Oct 2001 01:50:53 +0200
> From: Deacon Marcus <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [half-off-topic] Java Compilers
>
> Hi,
> First, I'm sorry for being off-topic, but I have no idea where it would be
> on-topic, so I write it here. Besides, at least some of you will be
> interested.
> I'm starting another project - run-time compiled java, which I would like to
> develop into stable beta and then donate to ASF.
>
> There would be two classes, CompileUnit and CompileContext.
> First, you create a CompileContext, initialize it with working dir and
> classpath, then you create CompileUnit, initialize it with CompileContext
> and a .java file. Then, you can call .prepare() or .compile() to compile the
> file, and .newInstance() to create an instance or .getClass() to get Class.
> Or you could use Class.forName(), since in most cases CompileContext's
> classpath would be active classpath.
> I'm sure you see the similarity to .JSP now.
> While it may seem basic, having API for this wouldn't hurt.
> Possible scenario:
> Supponse, there's some kind of mail server with *extremely* complicated
> rule-set in form of 200kb+ xml. Why not take it, convert it into .java
> implementing some interface, convert it to java source with hundreds if not
> more ifs and cases, and load it as compiled code.
> What I need: since JDK 1.4b2, tools.jar just isn't what it used to be... so
> I need some kind of 100% java java compiler. And, I have no idea where to
> search for one. Of course, there's dozens, but it must be both stable and
> compatible with JDK 1.1 - 1.4.
>

A conversation on a semi-related topic is currently running on the
[EMAIL PROTECTED] list, about the potential contribution of the
"bcel" library to Jakarta.

It would be quite interesting if BCEL and/or your code could be used to
create the generated classes for JSP pages without going through a Java
compiler.

> Greetings, deacon Marcus
>
> p.s. Is it ok for me to use org.apache.jjc (or org.apache. whatever) before
> I officialy donate it, assuming I won't be distributing it before donating
> anyway?

It would *not* be wise to use org.apache under false pretenses.  Even
though you don't *intend* to distribute, it's difficult to move forward on
an idea like this without showing it to some people.

Also, there's no guarantee that Apache will accept it anyway -- especially
if there is not already a development community built up around it.

Craig

Re: tools.jar, javac and JDK 1.4b2

[Craig R. McClanahan]

On Thu, 4 Oct 2001, Deacon Marcus wrote:

> Date: Thu, 4 Oct 2001 03:43:35 +0200
> From: Deacon Marcus <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: tools.jar, javac and JDK 1.4b2
>
> Hi,
> Are there any actions taken to convince Sun to leave tools.jar and javac as
> they were in JDK 1.4b1 and before? JDK 1.4 is still beta 2, so it's not too
> late for that, right?
>

The original plan (of the J2SE folks) was to remove the old entry point.
This has been changed - the current plan is to deprecate the old entry
point (you get a warning message if you use it) but still leave it in for
1.4 final.

> Greetings,
>  deacon Marcus
>

Craig

DO NOT REPLY [Bug 3920] - HttpSessionBindingListener partially working for session expiration

[bugzilla]

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

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

HttpSessionBindingListener partially working for session expiration

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 19:24 ---
This is now fixed in the latest CVS.

Note that the session is still "invalid", so get/setAttribute will still fail.  
However getId will work.

cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade HttpSessionFacade.java

[billbarker]

billbarker01/10/03 19:20:04

  Modified:src/facade22/org/apache/tomcat/facade HttpSessionFacade.java
  Log:
  Remove validity checks from where the spec doesn't require them.
  
  This fixes Bug #3920 submitted by Alessandro Polverini [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.17  +0 -3  
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java
  
  Index: HttpSessionFacade.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- HttpSessionFacade.java2001/09/23 00:24:52 1.16
  +++ HttpSessionFacade.java2001/10/04 02:20:04 1.17
  @@ -113,7 +113,6 @@
   //  public facade 
   
   public String getId() {
  - checkValid();
return realSession.getId().toString();
   }
   
  @@ -140,7 +139,6 @@
   }
   
   public long getLastAccessedTime() {
  - checkValid();
return realSession.getTimeStamp().getLastAccessedTime();
   }
   
  @@ -295,7 +293,6 @@
   }
   
   public int getMaxInactiveInterval() {
  - checkValid();
// We use long because it's better to do /1000 here than
// every time the internal code does expire
return (int)realSession.getTimeStamp().getMaxInactiveInterval()/1000;
  
  
  

Re: DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[Bojan Smojver]

I have done this with TC 3.3, Apache 1.3.20 + mod_jk and my own form
based authentication:

Pages:

/login/login.vm <-- login page
/login/error.vm <-- error page
/login/index.vm <-- default index page

If someone goes to /login/login.vm directly and gets authenticated, the
page /login/index.vm gets displayed, which can then do whatever it wants
(ie. redirect somewhere else, display error, content etc.)

The pages I use are Velocity pages, but I don't think that JSP would be
any different.

Bojan

Steve Downey wrote:
> 
> "Train the user not to do that" is a cop out. If an application doesn't work
> the way users expect, it's a problem with the application, not the user.
> That's usability 101.
> 
> If the user shouldn't bookmark the login page, they shouldn't ever be
> exposed to the URI for the login page. That makes it impossible to bookmark.
> The only URI that the user should see is the URI for the protected resource.

RE: [half-off-topic] Java Compilers

[Aaron Mulder]

If you haven't seen it already, there's an article on the Swing
Connection on creating dynamic event listeners or some such which seems to
have been the basis for the Dynamic Proxy support in JDK 1.3.  It has
source code for generating classes on the fly that implement arbitrary
interfaces, including some generic routines for writing useful bits of
bytecode.  If your goals are limited enough in scope, you may want to skip
the source code and just spew out bytecode directly based on the XML file
you're reading.
Also, I have JDK 1.2 implementation of Dynamic Proxies that you're
welcome to look at, based on the aforementioned article.

Aaron

On Thu, 4 Oct 2001, Deacon Marcus wrote:
> Hi,
>
> > From: Dmitri Colebatch [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, October 04, 2001 2:35 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [half-off-topic] Java Compilers
> >
> >
> > Hi,
> >
> > On Thu, 4 Oct 2001, Deacon Marcus wrote:
> >
> > > There would be two classes, CompileUnit and CompileContext.
> > > First, you create a CompileContext, initialize it with working dir and
> > > classpath, then you create CompileUnit, initialize it with
> > CompileContext
> > > and a .java file. Then, you can call .prepare() or .compile()
> > to compile the
> > > file, and .newInstance() to create an instance or .getClass()
> > to get Class.
> > > Or you could use Class.forName(), since in most cases CompileContext's
> > > classpath would be active classpath.
> > so you're talking about generating java source code, and compiling it on
> > the fly?
>
> Exactly.
> I'm coding it right now - looks like CompileContext is enough - I'll post
> when I finish of course.
>
> > > I'm sure you see the similarity to .JSP now.
> > if my interpretation is correct, yes (o:
> >
> > > While it may seem basic, having API for this wouldn't hurt.
> > > Possible scenario:
> > > Supponse, there's some kind of mail server with *extremely* complicated
> > > rule-set in form of 200kb+ xml. Why not take it, convert it into .java
> > > implementing some interface, convert it to java source with
> > hundreds if not
> > > more ifs and cases, and load it as compiled code.
> > > What I need: since JDK 1.4b2, tools.jar just isn't what it used
> > to be... so
> > > I need some kind of 100% java java compiler. And, I have no
> > idea where to
> > > search for one. Of course, there's dozens, but it must be both
> > stable and
> > > compatible with JDK 1.1 - 1.4.
> > Short of searching google, which I'm sure you're already doing I cant help
> > you there.  What I can suggest though, is for source code generation, a
> > project called Jenesis (http://www.inxar.org) which provides a nice API
> > based on the Java Language spec.
>
> Generating source is out of scope of this project.
> I need it mainly for the complicated configs etc - no point in generating
> structure out of xml which is then analyzed everytime when you can compile
> it into bytecode. I'm sure it's possible to do xml-config to java-source
> transformation in xsl, but I don't like it personally, so I'll leave it to
> someone else.
>
> > cheers
> > dim
>
> Greetings, deacon Marcus
> ~
> HELP STARVING JAVA PROGRAMMER: If you need cheap and reliable JSP hosting,
> please contact [EMAIL PROTECTED] (from 12$/m for 50mb WWW + 20mb mail)
>

RE: DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[Steve Downey]

"Train the user not to do that" is a cop out. If an application doesn't work
the way users expect, it's a problem with the application, not the user.
That's usability 101. 

If the user shouldn't bookmark the login page, they shouldn't ever be
exposed to the URI for the login page. That makes it impossible to bookmark.
The only URI that the user should see is the URI for the protected resource.



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 03, 2001 6:23 PM
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 3839] - Problem bookmarking login page
> 
> 
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> .
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
> INSERTED IN THE BUG DATABASE.
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839
> 
> Problem bookmarking login page
> 
> [EMAIL PROTECTED] changed:
> 
>What|Removed |Added
> --
> --
>  Status|REOPENED|RESOLVED
>  Resolution||WONTFIX
> 
> 
> 
> --- Additional Comments From [EMAIL PROTECTED]  
> 2001-10-03 15:23 ---
> The fact that you hd the same problems under WebLogic also 
> should have given you
> a hint that you might be mis-using this functionality :-).
> 
> Although the form login page (and form error page) are 
> physically contained in
> your web application archive, they should not be hyperlinked 
> to by any of your
> app's pages.  Most particularly, it should *not* be your welcome page.
> 
> If you (temporarily) switch your app to use BASIC 
> authentication instead, it
> should still work correctly - and there is no possibility to 
> bookmark the login
> page because there is no such thing.  If your app doesn't 
> work in this scenario,
> then you should modify it so that it can.
> 
> If you don't, then you're going to be dependent on 
> non-portable behavior of
> whatever container vendor happens to allow this technique to 
> work - the spec 
> doesn't require it.
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

tools.jar, javac and JDK 1.4b2

[Deacon Marcus]

Hi,
Are there any actions taken to convince Sun to leave tools.jar and javac as
they were in JDK 1.4b1 and before? JDK 1.4 is still beta 2, so it's not too
late for that, right?

Greetings,
 deacon Marcus

~
HELP STARVING JAVA PROGRAMMER: If you need cheap and reliable JSP hosting,
please contact [EMAIL PROTECTED] (from 12$/m for 50mb WWW + 20mb mail)

RE: [half-off-topic] Java Compilers

[Deacon Marcus]

Hi,

> From: Dmitri Colebatch [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 04, 2001 2:35 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [half-off-topic] Java Compilers
>
>
> Hi,
>
> On Thu, 4 Oct 2001, Deacon Marcus wrote:
>
> > There would be two classes, CompileUnit and CompileContext.
> > First, you create a CompileContext, initialize it with working dir and
> > classpath, then you create CompileUnit, initialize it with
> CompileContext
> > and a .java file. Then, you can call .prepare() or .compile()
> to compile the
> > file, and .newInstance() to create an instance or .getClass()
> to get Class.
> > Or you could use Class.forName(), since in most cases CompileContext's
> > classpath would be active classpath.
> so you're talking about generating java source code, and compiling it on
> the fly?

Exactly.
I'm coding it right now - looks like CompileContext is enough - I'll post
when I finish of course.

> > I'm sure you see the similarity to .JSP now.
> if my interpretation is correct, yes (o:
>
> > While it may seem basic, having API for this wouldn't hurt.
> > Possible scenario:
> > Supponse, there's some kind of mail server with *extremely* complicated
> > rule-set in form of 200kb+ xml. Why not take it, convert it into .java
> > implementing some interface, convert it to java source with
> hundreds if not
> > more ifs and cases, and load it as compiled code.
> > What I need: since JDK 1.4b2, tools.jar just isn't what it used
> to be... so
> > I need some kind of 100% java java compiler. And, I have no
> idea where to
> > search for one. Of course, there's dozens, but it must be both
> stable and
> > compatible with JDK 1.1 - 1.4.
> Short of searching google, which I'm sure you're already doing I cant help
> you there.  What I can suggest though, is for source code generation, a
> project called Jenesis (http://www.inxar.org) which provides a nice API
> based on the Java Language spec.

Generating source is out of scope of this project.
I need it mainly for the complicated configs etc - no point in generating
structure out of xml which is then analyzed everytime when you can compile
it into bytecode. I'm sure it's possible to do xml-config to java-source
transformation in xsl, but I don't like it personally, so I'll leave it to
someone else.

> cheers
> dim

Greetings, deacon Marcus
~
HELP STARVING JAVA PROGRAMMER: If you need cheap and reliable JSP hosting,
please contact [EMAIL PROTECTED] (from 12$/m for 50mb WWW + 20mb mail)

DO NOT REPLY [Bug 3822] - Drive letter causes a NumberFormatException when JSP compiler parses errors

[bugzilla]

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

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

Drive letter causes a NumberFormatException when JSP compiler parses errors

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|tomcat- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 18:16 ---
Can you attach a test case that causes this problem?  I am not quite sure what
you meant by "the extra colon".  Are you referring to the colon after the drive
(such as D:)?  That was being taken care of.  All my tests ran as expected.

Re: [half-off-topic] Java Compilers

[Dmitri Colebatch]

Hi,

On Thu, 4 Oct 2001, Deacon Marcus wrote:

> There would be two classes, CompileUnit and CompileContext.
> First, you create a CompileContext, initialize it with working dir and
> classpath, then you create CompileUnit, initialize it with CompileContext
> and a .java file. Then, you can call .prepare() or .compile() to compile the
> file, and .newInstance() to create an instance or .getClass() to get Class.
> Or you could use Class.forName(), since in most cases CompileContext's
> classpath would be active classpath.
so you're talking about generating java source code, and compiling it on
the fly?

> I'm sure you see the similarity to .JSP now.
if my interpretation is correct, yes (o:

> While it may seem basic, having API for this wouldn't hurt.
> Possible scenario:
> Supponse, there's some kind of mail server with *extremely* complicated
> rule-set in form of 200kb+ xml. Why not take it, convert it into .java
> implementing some interface, convert it to java source with hundreds if not
> more ifs and cases, and load it as compiled code.
> What I need: since JDK 1.4b2, tools.jar just isn't what it used to be... so
> I need some kind of 100% java java compiler. And, I have no idea where to
> search for one. Of course, there's dozens, but it must be both stable and
> compatible with JDK 1.1 - 1.4.
Short of searching google, which I'm sure you're already doing I cant help
you there.  What I can suggest though, is for source code generation, a
project called Jenesis (http://www.inxar.org) which provides a nice API
based on the Java Language spec.

cheers
dim

[half-off-topic] Java Compilers

[Deacon Marcus]

Hi,
First, I'm sorry for being off-topic, but I have no idea where it would be
on-topic, so I write it here. Besides, at least some of you will be
interested.
I'm starting another project - run-time compiled java, which I would like to
develop into stable beta and then donate to ASF.

There would be two classes, CompileUnit and CompileContext.
First, you create a CompileContext, initialize it with working dir and
classpath, then you create CompileUnit, initialize it with CompileContext
and a .java file. Then, you can call .prepare() or .compile() to compile the
file, and .newInstance() to create an instance or .getClass() to get Class.
Or you could use Class.forName(), since in most cases CompileContext's
classpath would be active classpath.
I'm sure you see the similarity to .JSP now.
While it may seem basic, having API for this wouldn't hurt.
Possible scenario:
Supponse, there's some kind of mail server with *extremely* complicated
rule-set in form of 200kb+ xml. Why not take it, convert it into .java
implementing some interface, convert it to java source with hundreds if not
more ifs and cases, and load it as compiled code.
What I need: since JDK 1.4b2, tools.jar just isn't what it used to be... so
I need some kind of 100% java java compiler. And, I have no idea where to
search for one. Of course, there's dozens, but it must be both stable and
compatible with JDK 1.1 - 1.4.

Greetings, deacon Marcus

p.s. Is it ok for me to use org.apache.jjc (or org.apache. whatever) before
I officialy donate it, assuming I won't be distributing it before donating
anyway?

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

[kinman]

kinman  01/10/03 16:45:02

  Modified:jasper/src/share/org/apache/jasper/compiler Tag:
tomcat_40_branch JspCompiler.java
  Log:
  PR: Bugzilla 3892
  If the name of a .jsp file does not start with a legal Java identifier
  letter, prepend the generated class name with a '$' to make it a legal
  Java id name.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.7.2.1   +5 -0  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspCompiler.java
  
  Index: JspCompiler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspCompiler.java,v
  retrieving revision 1.7
  retrieving revision 1.7.2.1
  diff -u -r1.7 -r1.7.2.1
  --- JspCompiler.java  2001/09/07 22:51:26 1.7
  +++ JspCompiler.java  2001/10/03 23:45:02 1.7.2.1
  @@ -132,6 +132,11 @@
   int iSep = jsp.lastIndexOf('/') + 1;
   int iEnd = jsp.length();
   StringBuffer modifiedClassName = new StringBuffer(jsp.length() - iSep);
  + if (!Character.isJavaIdentifierStart(jsp.charAt(iSep))) {
  + // If the first char is not a legal Java letter or digit,
  + // prepend a '$'.
  + modifiedClassName.append('$');
  + }
   for (int i = iSep; i < iEnd; i++) {
   char ch = jsp.charAt(i);
   if (Character.isLetterOrDigit(ch))
  
  
  

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

[kinman]

kinman  01/10/03 16:43:22

  Modified:jasper/src/share/org/apache/jasper/compiler JspCompiler.java
  Log:
  PR: Bugzilla 3892
  If the name of the .jsp file does not start with a legal Java identifier
  letter, prepend the generated class name with a '$' to make it a legal
  Java id name.
  
  Revision  ChangesPath
  1.8   +5 -0  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspCompiler.java
  
  Index: JspCompiler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspCompiler.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- JspCompiler.java  2001/09/07 22:51:26 1.7
  +++ JspCompiler.java  2001/10/03 23:43:22 1.8
  @@ -132,6 +132,11 @@
   int iSep = jsp.lastIndexOf('/') + 1;
   int iEnd = jsp.length();
   StringBuffer modifiedClassName = new StringBuffer(jsp.length() - iSep);
  + if (!Character.isJavaIdentifierStart(jsp.charAt(iSep))) {
  + // If the first char is not a legal Java letter or digit,
  + // prepend a '$'.
  + modifiedClassName.append('$');
  + }
   for (int i = iSep; i < iEnd; i++) {
   char ch = jsp.charAt(i);
   if (Character.isLetterOrDigit(ch))
  
  
  

THANKS

[Mister Nobody]

I've been working with TC4.0, installing and configuring, for the past 
week, and I just want to say to the active developers on this list:

THANK YOU

This is a beautifully functional, beautifully documented, really slick 
piece of work.  Y'all are GREAT.

DO NOT REPLY [Bug 3953] - If context is listed in server.xml then webapp servlets are loaded twice....

[bugzilla]

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

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

If context is listed in server.xml then webapp servlets are loaded twice





--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 16:25 ---
Well, it's rather large, but the webapp that's displaying this that I'm using 
is the expresso4ea application.

http://www.jcorporate.com/components/internal/projframe.jsp?category=65

Is where it can be downloaded.  [Although the good news is that if you modify 
the server.xml file after you download things you'll get the results I'm 
talking about right away :-) ]

I'm afraid I don't really develop outside this framework, so I don't really 
have any independent examples.  

Also the weird thing on my end is that if I set debugger breakpoints 
corresponding to the messages I see scrolling through the console, things only 
stop at the breakpoints once.  [Even though I see the appropriate message 
twice].  BUT if I stop at the breakpoint, continue on, and wait until I see all 
the initialization messages and then pause the debugger I can be stepping 
through the code that I expect to be hitting twice.  [I'm using Jbuilder 4 Pro, 
Jdk 1.3.0]

HTH,
-Mike

Re: Bug 3888/Class Loader Stopped

[Remy Maucherat]

> I noticed there were comments saying that it's hard to replicate.  I get
it
> pretty regularly, but the trick seems to be that it only occurs for me
once
> I reload a context.  Then pretty much my first servlet request generates
> this error.
>
> I couldn't figure out how to add a note to a bug in Bugzilla, so I figured
> I would post it here.

And do you have a test case ?

It never happened to me using the 'examples' context (which I use for
testing).

Remy

RE: Bug 3888/Class Loader Stopped

[Michael Rimov]

I noticed there were comments saying that it's hard to replicate.  I get it 
pretty regularly, but the trick seems to be that it only occurs for me once 
I reload a context.  Then pretty much my first servlet request generates 
this error.

I couldn't figure out how to add a note to a bug in Bugzilla, so I figured 
I would post it here.

HTH,
-Mike

cvs commit: jakarta-tomcat-site/xdocs index.xml

[craigmcc]

craigmcc01/10/03 16:15:43

  Modified:docs index.html
   xdocsindex.xml
  Log:
  Tweak the wording slightly to reflect the actual reality.
  
  Revision  ChangesPath
  1.10  +3 -1  jakarta-tomcat-site/docs/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/index.html,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- index.html2001/09/18 03:01:51 1.9
  +++ index.html2001/10/03 23:15:43 1.10
  @@ -107,7 +107,9 @@
 
 
   
  -Tomcat is the official Reference 
Implementation for the http://java.sun.com/products/servlets";>Java 
Servlet and http://java.sun.com/products/jsp";>JavaServer Pages 
technologies.  
  +Tomcat is the servlet container that is used 
in the official
  +Reference Implementation for the
  +http://java.sun.com/products/servlets";>Java Servlet and http://java.sun.com/products/jsp";>JavaServer Pages technologies.  
   The Java Servlet and JavaServer Pages specifications are developed by Sun 
   under the http://java.sun.com/aboutJava/communityprocess/";>Java 
   Community Process.  
  
  
  
  1.9   +3 -2  jakarta-tomcat-site/xdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/xdocs/index.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- index.xml 2001/09/18 03:01:51 1.8
  +++ index.xml 2001/10/03 23:15:43 1.9
  @@ -10,8 +10,9 @@
   
   
   
  -Tomcat is the official Reference Implementation for the http://java.sun.com/products/servlets";>Java Servlet and Tomcat is the servlet container that is used in the official
  +Reference Implementation for the
  +http://java.sun.com/products/servlets";>Java Servlet and http://java.sun.com/products/jsp";>JavaServer Pages technologies.  
   The Java Servlet and JavaServer Pages specifications are developed by Sun 
   under the http://java.sun.com/aboutJava/communityprocess/";>Java 
  
  
  

cvs commit: jakarta-tomcat-4.0 RELEASE-PLAN-4.0.1.txt

[remm]

remm01/10/03 16:05:01

  Added:   .Tag: tomcat_40_branch RELEASE-PLAN-4.0.1.txt
  Log:
  - Add release plan for Tomcat 4.0.1.
  - Note: I don't think release plans are needed for maintenance releases, and it
will be mainly used to keep track of must-fix issues. There will be a lazy vote
for the beta, and a vote for the release. I'll act as the release manager for
this release (unless someone disagrees).
  - Comments welcome.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.1   +99 -0 jakarta-tomcat-4.0/Attic/RELEASE-PLAN-4.0.1.txt
  
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina build.xml

[craigmcc]

craigmcc01/10/03 15:59:43

  Modified:catalina build.xml
  Log:
  Do not copy the "server" classes twice (once unpacked and once packed).
  
  Revision  ChangesPath
  1.74  +0 -9  jakarta-tomcat-4.0/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
  retrieving revision 1.73
  retrieving revision 1.74
  diff -u -r1.73 -r1.74
  --- build.xml 2001/10/03 21:39:11 1.73
  +++ build.xml 2001/10/03 22:59:43 1.74
  @@ -631,9 +631,6 @@
   
   
   
  -
  -  
  -
   
 
   
  @@ -644,17 +641,11 @@
   
   
   
  -
  -  
  -
   
 
   
   
   
  -
  -  
  -
   
 
   
  
  
  

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

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

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

Problem bookmarking login page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 15:23 ---
The fact that you hd the same problems under WebLogic also should have given you
a hint that you might be mis-using this functionality :-).

Although the form login page (and form error page) are physically contained in
your web application archive, they should not be hyperlinked to by any of your
app's pages.  Most particularly, it should *not* be your welcome page.

If you (temporarily) switch your app to use BASIC authentication instead, it
should still work correctly - and there is no possibility to bookmark the login
page because there is no such thing.  If your app doesn't work in this scenario,
then you should modify it so that it can.

If you don't, then you're going to be dependent on non-portable behavior of
whatever container vendor happens to allow this technique to work - the spec 
doesn't require it.

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Http10Interceptor.java

[mmanders]

mmanders01/10/03 15:13:45

  Modified:src/share/org/apache/tomcat/modules/server
Http10Interceptor.java
  Log:
  Fix Bug #3944 request.getRemoteAddr() alays returning 127.0.0.1
  Bug report from Alessandro Polverini
  
  Since the base Request object set remoteAddr and remoteHost to defaults,
  the checks around setting them off of the real request always succeed so the
  real values are never used.  Added calls to recycle these in the constructor.
  This still allows for delayed setting, since the calls to set the values can be
  expensive.
  
  Revision  ChangesPath
  1.26  +4 -0  
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Http10Interceptor.java
  
  Index: Http10Interceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Http10Interceptor.java,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- Http10Interceptor.java2001/09/22 22:05:31 1.25
  +++ Http10Interceptor.java2001/10/03 22:13:45 1.26
  @@ -209,6 +209,10 @@
   
   public HttpRequest() {
   super();
  +
  +// recycle these to remove the defaults
  +remoteAddrMB.recycle();
  +remoteHostMB.recycle();
   }
   public Object getAttribute(String name) {
   if (name.equals("javax.servlet.request.X509Certificate")) {
  
  
  

DO NOT REPLY [Bug 3892] - Can't compile 2092.jsp

[bugzilla]

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

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

Can't compile 2092.jsp

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|tomcat- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |
  Component|Unknown |Jasper

DO NOT REPLY [Bug 3953] - If context is listed in server.xml then webapp servlets are loaded twice....

[bugzilla]

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

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

If context is listed in server.xml then webapp servlets are loaded twice





--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 15:14 ---
Can you provide a web app that illustrates this?

The reason I ask is that the "examples" web app included with Tomcat is set up
exactly this way, but the load-on-startup servlets are executed only once.

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

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

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

Problem bookmarking login page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 14:11 ---
ohh, come on, you are saying "the solution is to fix the people who use your web 
application". What am I supposed to do, put in the login page something like this:"Do 
not bookmark this page, consider it a part of the *container*, not part of the 
*application*" Some of the users don't even know there is such thing as a container, 
and I don't see a reason why they should know.I don't see why the users should be 
instructed at all.Well, that really does not make it transparent for the users. I used 
to use weblogic and they had the same problem. They did change it to go to the default 
page in the web application after we contacted support.Plus the page IS part of the 
application, it has to be placed inside the war file, it is different for every web 
application, it has to be specified inside web.xml which is part of the standard. 
Exactly what part of the servlet standard is broken by fixing this?What good is the 
default page for the web application if it doesn't get shown by default?

DO NOT REPLY [Bug 3667] - Only one ValidationMessage processed

[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=3667>.
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=3667

Only one ValidationMessage processed

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 15:07 ---
Fixed with nightly build 20011003

DO NOT REPLY [Bug 3669] - Improve Jasper error reporting (stack traces)

[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=3669>.
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=3669

Improve Jasper error reporting (stack traces)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 15:05 ---
Fixed with nightly build 20011003

DO NOT REPLY [Bug 3953] New: - If context is listed in server.xml then webapp servlets are loaded twice....

[bugzilla]

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

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

If context is listed in server.xml then webapp servlets are loaded twice

   Summary: If context is listed in server.xml then webapp servlets
are loaded twice
   Product: Tomcat 4
   Version: 4.0 Final
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


It seems that if a context is listed in server.xml  Example:



Then my servlets that get loaded on startup as defined in the web.xml for the 
webapp get loaded twice. 

Thanks for looking into this.

-Mike

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

[craigmcc]

craigmcc01/10/03 15:00:41

  Modified:webapps/tomcat-docs class-loader-howto.xml
  Log:
  Update the Class Loader doc for the HEAD branch to reflect the revised
  state of the world.
  
  Revision  ChangesPath
  1.2   +36 -93jakarta-tomcat-4.0/webapps/tomcat-docs/class-loader-howto.xml
  
  Index: class-loader-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/class-loader-howto.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- class-loader-howto.xml2001/09/04 04:39:04 1.1
  +++ class-loader-howto.xml2001/10/03 22:00:41 1.2
  @@ -8,7 +8,7 @@
   
   
   Craig R. McClanahan
  -Class Loader INFO
  +Class Loader HOW-TO
   
   
   
  @@ -27,15 +27,11 @@
   application archive.
   For classes and resources that must be shared across all web applications,
   place unpacked classes and resources under
  -$CATALINA_HOME/classes, or place JAR files containing those
  -classes and resources under $CATALINA_HOME/lib.
  +$CATALINA_HOME/shared/classes, or place JAR files
  +containing those classes and resources under
  +$CATALINA_HOME/shared/lib.
   
   
  -WARNING - Unlike Tomcat 3.x, Tomcat 4 does
  -NOT make an XML parser visible to web applications by default.
  -If you need to do this, see Tomcat 4 and
  -XML Parsers, below.
  -
   
   
   
  @@ -70,8 +66,6 @@
Catalina   Shared
/   \
   Webapp1  Webapp2 ... 
  -  / /
  -   Jasper1  Jasper2 ...
   
   
   The characteristics of each of these class loaders, including the source
  @@ -118,13 +112,16 @@
   jndi.jar - The Java Naming and Directory Interface API
   classes (loaded ONLY on a JDK 1.2 system, because they
   are included automatically on JDK 1.3 and later).
  -naming.jar - The JNDI implementation used by Tomcat 4 to
  -represent the default JNDI naming context provided to web
  -applications.
  -resources.jar - Resource factory classes for the JNDI naming
  -context that is used internally to represent the static resources of
  -a web application.
  +naming-common.jar - The JNDI implementation used by Tomcat 4
  +to represent in-memory naming contexts.
  +naming-resources.jar - The specialized JNDI naming context
  +implementation used to represent the static resources of a web
  +application.
   servlet.jar - The Servlet and JSP API classes.
  +xerces.jar - The XML parser that is visible by default to
  +Tomcat internal classes and to web applications.  This can be
  +overridden, for a particular web application, by including your
  +desired parser in /WEB-INF/lib.
   
   Catalina - This class loader is initialized to include
   all classes and resources required to implement Tomcat 4 itself.  These
  @@ -137,34 +134,41 @@
   
   catalina.jar - Implementation of the Catalina servlet
   container portion of Tomcat 4.
  -crimson.jar - Parser portion of the JAXP/1.1 reference
  -implementation, used to parse web application deployment descriptor
  -(web.xml) files, as well as the server configuration file
  -($CATALINA_HOME/conf/server.xml).
   jakarta-regexp-X.Y.jar - The binary distribution of the
   http://jakarta.apache.org/regexp/";>Jakarta Regexp
   regular expression processing library, used in the implementation of
   request filters.
  -jaxp.jar - JAXP API portion of the JAXP/1.1 reference
  -implementation, used to parse web application deployment descriptor
  -(web.xml) files, as well as the server configuration file
  -($CATALINA_HOME/conf/server.xml).
  +servlets-x.jar - The classes associated with each
  +internal servlet that provides part of Tomcat's functionality.
  +These are separated so that they can be completely removed if the
  +corresponding service is not required, or they can be subject to
  +specialized security manager permissions.
  +tomcat-ajp.jar - Classes for the Java portion of the
  +mod_jk web server connector, which allows Tomcat to
  +run behind web servers such as Apache and iPlanet iAS and iWS.
  +tomcat-util.jar - Utility classes required by
  +tomcat-ajp.jar.
   warp.jar - Classes for the Java portion of the
   mod_webapp web server connector, which allows Tomcat to
   run behind web servers such as Apache and iPlanet iAS and iWS.
   
   Shared - This class loader is the place to put classes
   and resources that you wish to share across ALL
  -web applications (unless Tomcat internal classes also need access, which
  -is an unusual

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet JspServlet.java

[kinman]

kinman  01/10/03 15:00:35

  Modified:jasper/src/share/org/apache/jasper/compiler Tag:
tomcat_40_branch JspParseEventListener.java
   jasper/src/share/org/apache/jasper/resources Tag:
tomcat_40_branch messages.properties
messages_ja.properties
   jasper/src/share/org/apache/jasper/servlet Tag:
tomcat_40_branch JspServlet.java
  Added:   jasper/src/share/org/apache/jasper Tag: tomcat_40_branch
JasperError.java
  Log:
  PR: 3667, 3669
  All messages from all validators in tag libraries are now displayed,
  without throwing an exception that causes the stack trace to be printed.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.1   +0 -0  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JasperError.java
  
  Index: JasperError.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JasperError.java,v
  retrieving revision 1.1
  retrieving revision 1.1.2.1
  diff -u -r1.1 -r1.1.2.1
  
  
  
  No   revision
  
  
  No   revision
  
  
  1.33.2.1  +21 -10
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
  
  Index: JspParseEventListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
  retrieving revision 1.33
  retrieving revision 1.33.2.1
  diff -u -r1.33 -r1.33.2.1
  --- JspParseEventListener.java2001/07/25 01:08:13 1.33
  +++ JspParseEventListener.java2001/10/03 22:00:33 1.33.2.1
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.33 2001/07/25 01:08:13 craigmcc Exp $
  - * $Revision: 1.33 $
  - * $Date: 2001/07/25 01:08:13 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.33.2.1 2001/10/03 22:00:33 kinman Exp $
  + * $Revision: 1.33.2.1 $
  + * $Date: 2001/10/03 22:00:33 $
*
* 
*
  @@ -78,10 +78,10 @@
   import javax.servlet.jsp.tagext.TagLibraryInfo;
   import javax.servlet.jsp.tagext.ValidationMessage;
   
  +import org.apache.jasper.JasperError;
   import org.apache.jasper.JasperException;
   import org.apache.jasper.Constants;
   import org.apache.jasper.JspCompilationContext;
  -
   import org.apache.jasper.logging.Logger;
   
   import org.xml.sax.Attributes;
  @@ -1114,7 +1114,9 @@
* libraries used by the document.
*/
   public void validate() throws JasperException {
  + StringBuffer errMessage = new StringBuffer();
   Enumeration enum = libraries.getTagLibInfos();
  +boolean hasErrors = false;
   while (enum.hasMoreElements()) {
   TagLibraryInfo tli = (TagLibraryInfo)enum.nextElement();
//@@@ remove cast when TagLibraryInfo is fixed in spec
  @@ -1122,14 +1124,23 @@
ValidationMessage[] errors =
  ((TagLibraryInfoImpl)tli).validate(xo.getPageData());
   if ((errors != null) && (errors.length != 0)) {
  - // for now just report the first error!
  - String msg = errors[0].getMessage();
  -throw new JasperException(
  - Constants.getString(
  -"jsp.error.taglibraryvalidator.invalidpage",
  - new Object[]{tli.getShortName(), msg}));
  +hasErrors = true;
  +errMessage.append("");
  +errMessage.append(Constants.getString(
  +   "jsp.error.taglibraryvalidator.invalidpage",
  +   new Object[]{tli.getShortName()}));
  +errMessage.append("");
  +for (int i = 0; i < errors.length; i++) {
  +errMessage.append("");
  +errMessage.append(errors[i].getId());
  +errMessage.append(": ");
  +errMessage.append(errors[i].getMessage());
  +errMessage.append("");
  +}
   }
   }
  + if (hasErrors)
  +throw new JasperError(errMessage.toString());
   }
   
   /**
  
  
  
  No   revision
  
  
  No   revision
  
  
  1.20.2.1  +2 -2  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources/messages.properties
  
  Index: messages.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources/messag

DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance

[bugzilla]

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

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

SingleThreadModel servlets not pooled results in low performance





--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 14:55 ---
I'll just add a bit of text from JSDK 2.0 (a.k.a. Servlet API 2.0) in regards to
SingleThreadModel:

--
In essence, if the servlet implements this interface, the servlet will be thread
safe.
--

I have started at around that time with JServ and life was wonderful. All I
needed to do was to implement SingleThreadModel and not worry about anything
else ever again. Right?

That's where the whole thing with SingleThreadModel is actually wrong. It gives
people a false promise of something that is far more complicated than
implementing one interface. Java already has threading support, no need to
reinvent. After thinking about all the implications that people mentioned
related to SingleThreadModel, I agree with Jon - it was a bad idea in the first
place (although I didn't get it for some time Jon :-) 

As for pool support, let me quote JSDK 2.0 again:

--
This guarantee is ensured by maintaining a pool of servlet instances for each
such servlet, and dispatching each service call to a free servlet.
--

And compare that to Servlet API 2.2:

--
The servlet container can make this guarantee by synchronizing access to a
single instance of the servlet, or by maintaining a pool of servlet instances
and dispatching each new request to a free servlet.
--

I think someone out there realized that the pool thing does not solve the actual
problem of thread safety, complicates the code and increases the memory usage of
the container, so they said: let's make it simple. It does seem like someone was
sending a message to container providers, doesn't it?

My point here is: I also have code relying on SingleThreadModel, and I'll have
to rewrite. But I think it's time well spent.

DO NOT REPLY [Bug 3944] - request.getRemoteAddr() always returning 127.0.0.1

[bugzilla]

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

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

request.getRemoteAddr() always returning 127.0.0.1

[EMAIL PROTECTED] changed:

   What|Removed |Added

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

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

[kinman]

kinman  01/10/03 14:48:31

  Modified:jasper/src/share/org/apache/jasper/compiler
JspParseEventListener.java
   jasper/src/share/org/apache/jasper/servlet JspServlet.java
   jasper/src/share/org/apache/jasper/resources
messages.properties messages_ja.properties
  Added:   jasper/src/share/org/apache/jasper JasperError.java
  Log:
  PR: 3667, 3669
  All messages from all validators in tag libraries are now displayed,
  without throwing an exception that causes the stack trace to be printed.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JasperError.java
  
  Index: JasperError.java
  ===
  /*
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights 
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer. 
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:  
   *   "This product includes software developed by the 
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written 
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   */ 
  
  package org.apache.jasper;
  
  /**
   * Errors generated by the JSP engine.  It differs from JasperException in
   * that it does not print stack trace.
   *
   * @author Kin-man Chung
   */
  public class JasperError extends org.apache.jasper.JasperException {
  
  public JasperError(String reason) {
super(reason);
  }
  }
  
  
  
  1.34  +21 -10
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
  
  Index: JspParseEventListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- JspParseEventListener.java2001/07/25 01:08:13 1.33
  +++ JspParseEventListener.java2001/10/03 21:48:30 1.34
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.33 2001/07/25 01:08:13 craigmcc Exp $
  - * $Revision: 1.33 $
  - * $Date: 2001/07/25 01:08:13 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.34 2001/10/03 21:48:30 kinman Exp $
  + * $Revision: 1.34 $
  + * $Date: 2001/10/03 21:48:30 $
*
* 
*
  @@ -78,10 +78,10 @@
   import javax.servle

DO NOT REPLY [Bug 3944] - request.getRemoteAddr() always returning 127.0.0.1

[bugzilla]

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

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

request.getRemoteAddr() always returning 127.0.0.1

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

cvs commit: jakarta-tomcat-4.0/tester build.xml

[craigmcc]

craigmcc01/10/03 14:39:12

  Modified:.build.xml
   catalina build.xml
   catalina/src/share/org/apache/catalina/startup
Bootstrap.java BootstrapService.java
   jasper   build.xml
   tester   build.xml
  Log:
  Update the build processes (and initial class loader setup):
  * Old $CATALINA_HOME/classes is now $CATALINA_HOME/shared/classes
  * Old $CATALINA_HOME/lib is now $CATALINA_HOME/shared/lib
  
  Revision  ChangesPath
  1.44  +24 -11jakarta-tomcat-4.0/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/build.xml,v
  retrieving revision 1.43
  retrieving revision 1.44
  diff -u -r1.43 -r1.44
  --- build.xml 2001/10/02 23:48:24 1.43
  +++ build.xml 2001/10/03 21:39:11 1.44
  @@ -94,16 +94,16 @@
 
   
   
  -
   
   
   
   
  -
   
   
   
   
  +
  +
   
   
 
  @@ -112,6 +112,7 @@
 
 
   
  +
   
 
   
  @@ -123,24 +124,39 @@
 
   
   
  +
   
 
   
  -
  -  
  +
  +  
   
   
 
   
  -
  -  
  +
  +  
   
  +
  +  
  +
   
 
  +
  +
  +  
  +
  +
  +  
   
  -
  +
  +  
  +
  +
  +
  +
   
  -
  +
   
 
   
  @@ -179,9 +195,6 @@
 
 
  -
  -  
  -
 
   
   
  
  
  
  1.73  +59 -39jakarta-tomcat-4.0/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
  retrieving revision 1.72
  retrieving revision 1.73
  diff -u -r1.72 -r1.73
  --- build.xml 2001/10/02 23:20:43 1.72
  +++ build.xml 2001/10/03 21:39:11 1.73
  @@ -35,7 +35,7 @@
   
   
   
  -
  +
 
   
 
  @@ -55,7 +55,7 @@
   
   
   
  -
  +
   
 
   
  @@ -377,15 +377,15 @@
   
   
   
  -
  -
   
   
   
  -
  -
  +
   
   
  +
  +
  +
   
 
   
  @@ -468,13 +468,13 @@
 
   
   
  -
   
   
  -
  @@ -504,7 +504,7 @@
   
   
   
  -
  +
 
   
 
  @@ -607,11 +607,10 @@
   
   
   
  -
   
  -
  +
   
  -
  +
   
   
 
  @@ -624,7 +623,7 @@
   
 
   
  -
  +
   
   
   
  @@ -632,6 +631,9 @@
   
   
   
  +
  +  
  +
   
 
   
  @@ -641,16 +643,22 @@
 
   
   
  -
  -
  -  
  -
  -
   
  +
  +  
  +
   
 
   
   
  +
  +
  +  
  +
  +
  +  
  +
  +
 
   
   
  @@ -661,7 +669,7 @@
   
   
  -  
  +  
   
   
   
  @@ -677,7 +685,7 @@
   
   
   
  -  
  +  
   
   
   
  @@ -694,7 +702,7 @@
   
   
   
  -  
  +  
   
   
   
  @@ -703,8 +711,8 @@
   
   
   
  -
  -  
  +
  +  
   
   
 
  @@ -712,14 +720,14 @@
   
   
   
  -  
  +  
   
 
   
   
   
   
  -  
  +  
   
   
 
  @@ -727,42 +735,42 @@
   
   
   
  -  
  +  
   
 
   
   
   
   
  -  
  +  
   
 
   
   
   
   
  -  
  +  
   
 
   
   
   
   
  -  
  +  
   
 
   
   
   
   
  -  
  +  
   
 
   
   
   
   
  -  
  +  
   
   
 
  @@ -770,14 +778,14 @@
   
   
   
  -  
  +  
   
 
   
   
   
   
   
 
  @@ -800,6 +808,10 @@
   
   
   
  +
  +
  +  
  +
   
   
 
  @@ -811,16 +823,24 @@
 
   
   
  -
  -
  -
  -  
  -
  -
   
  +
  +
  +  
  +
   
   
 
  +
  +
  +
  +
  +
  +  
  +
  +
  +
  +  
   
   
 
  
  
  
  1.29  +6 -6  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
  
  Index: Bootstrap.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- Bootstrap.java2001/09/21 16:06:58 1.28
  +++ Bootstrap.java2001/10/03 21:39:12 1.29
  

DO NOT REPLY [Bug 3949] New: - Document with content-length of 0 results in resend headers

[bugzilla]

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

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

Document with content-length of 0  results in resend headers

   Summary: Document with content-length of 0  results in resend
headers
   Product: Tomcat 4
   Version: 4.0 Release Candidate 2
  Platform: Sun
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connectors
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


When Tomcat reaches the idle timeout on a persistent connection
it seems to return an additional HTTP response just prior to
closing the connection. Observed with telnet :-


% telnet tomcat 8080
Trying 10.5.21.109...
Connected to tomcat.
Escape character is '^]'.
GET /JAXPREP/familytree.dtd HTTP/1.1

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 0
Date: Mon, 01 Oct 2001 12:07:13 GMT
Server: Apache Tomcat/4.0-rc2 (HTTP/1.1 Connector)
Last-Modified: Thu, 20 Sep 2001 23:02:56 GMT
ETag: "0-1001026976000"

<<<>>

HTTP/1.1 200 OK
Content-Length: 0
Date: Mon, 01 Oct 2001 12:08:13 GMT
Server: Apache Tomcat/4.0-rc2 (HTTP/1.1 Connector)

Connection closed by foreign host.

DO NOT REPLY [Bug 3845] - Body content is supposed to be empty

[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=3845>.
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=3845

Body content is supposed to be empty

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 12:32 ---
Fixed in nightly build 20011003

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

[kinman]

kinman  01/10/03 12:29:28

  Modified:jasper/src/share/org/apache/jasper/compiler Parser.java
  Log:
  PR: Bugzilla 3845
  
  Revision  ChangesPath
  1.15  +8 -8  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- Parser.java   2001/09/20 21:47:32 1.14
  +++ Parser.java   2001/10/03 19:29:28 1.15
  @@ -834,20 +834,16 @@
   


  - if (reader.matches(CLOSE_1)
  - || bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY)) {
  - if (reader.matches(CLOSE_1))
  - reader.advance(CLOSE_1.length());
  - else
  - throw new ParseException(start, "Body is supposed to be empty for 
"+tag);
  -
  - listener.setTemplateInfo(parser.tmplStart, parser.tmplStop);   
 
  + if (reader.matches(CLOSE_1)) {
  + reader.advance(CLOSE_1.length());
  + listener.setTemplateInfo(parser.tmplStart, parser.tmplStop);
listener.handleTagBegin(start, reader.mark(), attrs, prefix,
shortTagName, tli, ti, true);
listener.handleTagEnd(start, reader.mark(), prefix, 
  shortTagName, attrs, tli, ti, true);
} else { 
// Body can be either
  + // - empty
// - JSP tags
// - tag dependent stuff
if (reader.matches(CLOSE)) {
  @@ -861,12 +857,16 @@
   if (bodyStop != null) {
   String bodyString = new String(reader.getChars(bodyStart, 
bodyStop));
   hasBody = (bodyString.length() > 0);
  + if (hasBody && 
bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY)) 
  + throw new ParseException(start,
  + "Body is supposed to be empty for "+tag);
   }
   reader.reset(bodyStart);
   
listener.handleTagBegin(start, bodyStart, attrs, prefix, 
shortTagName, tli, ti, hasBody);
   if (bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_TAG_DEPENDENT) ||
  + bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY) ||
   bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_JSP)) 
   {
   // Parse until the end of the tag body. 
  
  
  

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

[kinman]

kinman  01/10/03 12:26:47

  Modified:jasper/src/share/org/apache/jasper/compiler Tag:
tomcat_40_branch Parser.java
  Log:
  PR: Bugzilla 3845
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.13.2.2  +8 -8  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.13.2.1
  retrieving revision 1.13.2.2
  diff -u -r1.13.2.1 -r1.13.2.2
  --- Parser.java   2001/09/20 21:50:58 1.13.2.1
  +++ Parser.java   2001/10/03 19:26:47 1.13.2.2
  @@ -834,20 +834,16 @@
   


  - if (reader.matches(CLOSE_1)
  - || bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY)) {
  - if (reader.matches(CLOSE_1))
  - reader.advance(CLOSE_1.length());
  - else
  - throw new ParseException(start, "Body is supposed to be empty for 
"+tag);
  -
  - listener.setTemplateInfo(parser.tmplStart, parser.tmplStop);   
 
  + if (reader.matches(CLOSE_1)) {
  + reader.advance(CLOSE_1.length());
  + listener.setTemplateInfo(parser.tmplStart, parser.tmplStop);
listener.handleTagBegin(start, reader.mark(), attrs, prefix,
shortTagName, tli, ti, true);
listener.handleTagEnd(start, reader.mark(), prefix, 
  shortTagName, attrs, tli, ti, true);
} else { 
// Body can be either
  + // - empty
// - JSP tags
// - tag dependent stuff
if (reader.matches(CLOSE)) {
  @@ -861,12 +857,16 @@
   if (bodyStop != null) {
   String bodyString = new String(reader.getChars(bodyStart, 
bodyStop));
   hasBody = (bodyString.length() > 0);
  + if (hasBody && 
bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY)) 
  + throw new ParseException(start,
  + "Body is supposed to be empty for "+tag);
   }
   reader.reset(bodyStart);
   
listener.handleTagBegin(start, bodyStart, attrs, prefix, 
shortTagName, tli, ti, hasBody);
   if (bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_TAG_DEPENDENT) ||
  + bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY) ||
   bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_JSP)) 
   {
   // Parse until the end of the tag body. 
  
  
  

Re: Rebinding Resolved Objects

[Will Stranathan]

The nightly build is based on the HEAD branch, correct?
Doing a lookup on the same element produces different
hashCode() results.

Also, does the JDBC driver have to support something
specific in order for Tyrex to pool it correctly?  Even when
I get the same DataSource every time, it still creates new
connections on every single request.

Thanks,
Will Stranathan

On Tue, 2 Oct 2001 11:44:32 -0700
 "Remy Maucherat" <[EMAIL PROTECTED]> wrote:

> The HEAD branch should now rebind.
> 
> Remy
> 

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

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

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

Problem bookmarking login page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 11:15 ---
It is not valid to bookmark the form-based login page.  You should consider that
page to be part of the *container*, not part of the *application*.

Users should be trained to bookmark the page they really want to see -- exactly
as if you were using BASIC authentication instead.  The login page will be
presented by the container if necessary (i.e. if the user is not currently
authenticated).

Even if you figure out a way to do this that works in one servlet container, it
is pretty much guaranteed not to be portable to any other.

DO NOT REPLY [Bug 3941] - PrinWriter.flush() HttpServletResponse.flushBuffer() do not work

[bugzilla]

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

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

PrinWriter.flush() HttpServletResponse.flushBuffer() do not work





--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 11:03 ---
Works for me as well.  I would also add that your testing methodology is
suspect, because the *client* is buffering things (inside the buffered reader)
as well.

To accurately test this servlet, you should connect with a browser (but change
the content type to "text/plain" so the browser does not buffer things), or
connect directly to Tomcat with a Telnet connection.

DO NOT REPLY [Bug 3941] - PrinWriter.flush() HttpServletResponse.flushBuffer() do not work

[bugzilla]

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

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

PrinWriter.flush() HttpServletResponse.flushBuffer() do not work

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 10:56 ---
This works for me (HEAD branch + hacked HelloWorld servlet + IE).
Both writer.flush() and response.flushBuffer() work properly.

DO NOT REPLY [Bug 3823] - sendError and setStatus clear headers already set

[bugzilla]

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

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

sendError and setStatus clear headers already set

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 10:45 ---
*** Bug 3939 has been marked as a duplicate of this bug. ***

DO NOT REPLY [Bug 3939] - HttpServletResponse.SC_UNAUTHORIZED incorrectly trapped by Tomcat

[bugzilla]

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

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

HttpServletResponse.SC_UNAUTHORIZED incorrectly trapped by Tomcat

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 10:45 ---
It looks extremely likely this problem would be caused by bug 3823 (your auth 
challenge would get cleared).

Note that in the servlet model, the auth layer is supposed to be handled by the 
container.

*** This bug has been marked as a duplicate of 3823 ***

RE: ClassCastException

[Kevin Jones]

I had exactly this problem; but I had jdbc2_0-stdext.jar not in the
jre/lib/ext but in my webapp/web-inf/lib directory. Putting
jdbc2_0-stdext.jar in common/lib along with the tyrex files solved the
problem (classloaders, you gotta love 'em)

Kevin Jones
Developmentor
www.develop.com

> -Original Message-
> From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig
> R. McClanahan
> Sent: 03 October 2001 17:20
> To: [EMAIL PROTECTED]
> Subject: Re: ClassCastException
>
>
>
>
> On Wed, 3 Oct 2001, Alessandro Pizzolotto wrote:
>
> > Date: Wed, 3 Oct 2001 17:10:37 +0200
> > From: Alessandro Pizzolotto <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: Re: ClassCastException
> >
> > hehehe
> > if i use this class:
> > tyrex.jdbc.xa.EnabledDataSource
> > instead
> > javax.sql.DataSource
> > the program works fine
> > the problem is that EnableDataSource implements
> javax.sql.DataSource but i
> > can't cast javax.sql.DataSource.
> > why ???
> >
>
> Would you happen to have a copy of jdbc2_0-stdext.jar in your system
> extensions directory ($JAVA_HOME/jre/lib/ext)?  That would cause problems
> like this -- the same sort of problem that causes "Class foo is not a
> servlet" errors if you have servlet.jar there.
>
> > Alessandro
>
> Craig McClanahan
>
> > - Original Message -
> > From: "Will Stranathan" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, October 03, 2001 3:04 PM
> > Subject: Re: ClassCastException
> >
> >
> > > Can we see the appropriate parts of server.xml and web.xml?
> > >
> > > Will Stranathan
> > >
> > > Alessandro Pizzolotto wrote:
> > >
> > > > this code
> > > >
> > > > javax.naming.Context ctx = new javax.naming.InitialContext();
> > > > javax.naming.Context cto =
> > (javax.naming.Context)ctx.lookup("java:/comp/env");
> > > > javax.sql.DataSource ds =
> > (javax.sql.DataSource)cto.lookup("jdbc/domus");
> > > >
> > > > produce this error
> > > >
> > > > java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource
> > > >  at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74)
> > > >  at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> > > >  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
> > > >  at
> >
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(Jsp
> Servlet.ja
> > va:201)
> > > >  at
> > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
> > > >  at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
> > > >  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
> > > >  at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(A
> pplication
> > FilterChain.java:247)
> > > >  at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicati
> onFilterCh
> > ain.java:193)
> > > >  at
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapp
> erValve.ja
> > va:243)
> > > >  at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel
> ine.java:5
> > 66)
> > > >  at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
> java:472)
> > > >  at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > > >  at
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardConte
> xtValve.ja
> > va:215)
> > > >  at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel
> ine.java:5
> > 66)
> > > >  at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
> java:472)
> > > >  at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > > >  at
> >
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2366)
> > > >  at
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValv
> e.java:164
> > )
> > > >  at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel
> ine.java:5
> > 66)
> > > >  at
> >
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
> > > >  at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel
> ine.java:5
> > 64)
> > > >  at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
> java:472)
> > > >  at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > > >  at
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngine
> Valve.java
> > :163)
> > > >  at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel
> ine.java:5
> > 66)
> > > >  at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
> java:472)
> > > >  at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > > >  at
> >
> org.apache.catalina.connector.http.HttpProcessor.process(HttpProce
> ssor.java:
> > 1005)
> > > >  at
> >
> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor
> .java:1098
> > )
> > > >  at java.lang.Thread.run(T

Re: ClassCastException

[Alessandro Pizzolotto]

now is ok
i am delete 2 .jar from WEB-INF/lib
the jdbc extension
tanks :)
Alkessandro
- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 03, 2001 6:19 PM
Subject: Re: ClassCastException


>
>
> On Wed, 3 Oct 2001, Alessandro Pizzolotto wrote:
>
> > Date: Wed, 3 Oct 2001 17:10:37 +0200
> > From: Alessandro Pizzolotto <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: Re: ClassCastException
> >
> > hehehe
> > if i use this class:
> > tyrex.jdbc.xa.EnabledDataSource
> > instead
> > javax.sql.DataSource
> > the program works fine
> > the problem is that EnableDataSource implements javax.sql.DataSource but
i
> > can't cast javax.sql.DataSource.
> > why ???
> >
>
> Would you happen to have a copy of jdbc2_0-stdext.jar in your system
> extensions directory ($JAVA_HOME/jre/lib/ext)?  That would cause problems
> like this -- the same sort of problem that causes "Class foo is not a
> servlet" errors if you have servlet.jar there.
>
> > Alessandro
>
> Craig McClanahan
>
> > - Original Message -
> > From: "Will Stranathan" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, October 03, 2001 3:04 PM
> > Subject: Re: ClassCastException
> >
> >
> > > Can we see the appropriate parts of server.xml and web.xml?
> > >
> > > Will Stranathan
> > >
> > > Alessandro Pizzolotto wrote:
> > >
> > > > this code
> > > >
> > > > javax.naming.Context ctx = new javax.naming.InitialContext();
> > > > javax.naming.Context cto =
> > (javax.naming.Context)ctx.lookup("java:/comp/env");
> > > > javax.sql.DataSource ds =
> > (javax.sql.DataSource)cto.lookup("jdbc/domus");
> > > >
> > > > produce this error
> > > >
> > > > java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource
> > > >  at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74)
> > > >  at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> > > >  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
> > > >  at
> >
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
> > va:201)
> > > >  at
> > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
> > > >  at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
> > > >  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
> > > >  at
> >
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
> > FilterChain.java:247)
> > > >  at
> >
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
> > ain.java:193)
> > > >  at
> >
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
> > va:243)
> > > >  at
> >
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> > 66)
> > > >  at
> >
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> > > >  at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > > >  at
> >
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
> > va:215)
> > > >  at
> >
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> > 66)
> > > >  at
> >
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> > > >  at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > > >  at
> >
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2366)
> > > >  at
> >
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164
> > )
> > > >  at
> >
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> > 66)
> > > >  at
> >
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
> > > >  at
> >
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> > 64)
> > > >  at
> >
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> > > >  at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > > >  at
> >
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
> > :163)
> > > >  at
> >
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> > 66)
> > > >  at
> >
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> > > >  at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > > >  at
> >
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:
> > 1005)
> > > >  at
> >
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1098
> > )
> > > >  at java.lang.Thread.run(Thread.java:484)
> > > >
> > > > the code not get the cast in DataSource
> > > > why ?
> > > > tanks
> > > > Alessadro
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>

Issues regarding class loading in tomcat3.2.1

[Subhadeep De]

Hi,

I am facing a problem regarding loading some of my classes at runtime.

The scene is as follows.

I download a jar and instantiate a class form it using my own class loader.
This class extends another class which is present in the
webapps/MYFOLDER/web-inf/classes folder.

Now tomcat is unable to instantiate the class from the jar saying that the
class from which it extends is not found.

This problem is resolved if i make a jar of my classes in
webapps/MYFOLDER/web-inf/classes folder and put it in the lib directory of
tomcat.

Can u please suggest me a better solution? and also let me know wht the
problem is occuring.


pls ASAP.

Thanks in advance,
Subhadeep.

Re: ClassCastException

[Craig R. McClanahan]

On Wed, 3 Oct 2001, Alessandro Pizzolotto wrote:

> Date: Wed, 3 Oct 2001 17:10:37 +0200
> From: Alessandro Pizzolotto <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: ClassCastException
>
> hehehe
> if i use this class:
> tyrex.jdbc.xa.EnabledDataSource
> instead
> javax.sql.DataSource
> the program works fine
> the problem is that EnableDataSource implements javax.sql.DataSource but i
> can't cast javax.sql.DataSource.
> why ???
>

Would you happen to have a copy of jdbc2_0-stdext.jar in your system
extensions directory ($JAVA_HOME/jre/lib/ext)?  That would cause problems
like this -- the same sort of problem that causes "Class foo is not a
servlet" errors if you have servlet.jar there.

> Alessandro

Craig McClanahan

> - Original Message -
> From: "Will Stranathan" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, October 03, 2001 3:04 PM
> Subject: Re: ClassCastException
>
>
> > Can we see the appropriate parts of server.xml and web.xml?
> >
> > Will Stranathan
> >
> > Alessandro Pizzolotto wrote:
> >
> > > this code
> > >
> > > javax.naming.Context ctx = new javax.naming.InitialContext();
> > > javax.naming.Context cto =
> (javax.naming.Context)ctx.lookup("java:/comp/env");
> > > javax.sql.DataSource ds =
> (javax.sql.DataSource)cto.lookup("jdbc/domus");
> > >
> > > produce this error
> > >
> > > java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource
> > >  at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74)
> > >  at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> > >  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
> > >  at
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
> va:201)
> > >  at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
> > >  at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
> > >  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
> > >  at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
> FilterChain.java:247)
> > >  at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
> ain.java:193)
> > >  at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
> va:243)
> > >  at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> 66)
> > >  at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> > >  at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > >  at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
> va:215)
> > >  at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> 66)
> > >  at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> > >  at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > >  at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2366)
> > >  at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164
> )
> > >  at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> 66)
> > >  at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
> > >  at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> 64)
> > >  at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> > >  at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > >  at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
> :163)
> > >  at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
> 66)
> > >  at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> > >  at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > >  at
> org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:
> 1005)
> > >  at
> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1098
> )
> > >  at java.lang.Thread.run(Thread.java:484)
> > >
> > > the code not get the cast in DataSource
> > > why ?
> > > tanks
> > > Alessadro
> > >
> > >
> >
> >
> >
>
>

Re: welcome files being forwarded to rather than redirected to?

[Craig R. McClanahan]

On Wed, 3 Oct 2001, Jan Grant wrote:

> Date: Wed, 3 Oct 2001 13:59:10 +0100 (BST)
> From: Jan Grant <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: tomcat-dev <[EMAIL PROTECTED]>
> Subject: welcome files being forwarded to rather than redirected to?
>
> A while ago I sent a message about the behaviour of welcome files going
> against the recommendations at http://www.w3.org/Provider/Style/URI; at
> the time the servlet spec was in PFD and was fairly explicit that
> sending a redirect wasn't acceptable.
>
> Looking at the final spec, it appears that they've toned down their
> language a little - nevertheless, this kind of behaviour (avoiding
> redirects) seems preferable.
>
> Unfortunately, the latest stable tomcat/catalina (congrats on this, by
> the way!) still behaves in the old way.
>
> I know I can explicitly map any URIs to particular JSPs or html files;
> however, I'd like to avoid having to do that (the convenience of welcome
> files is completely lost).
>
> Is this set in stone?
>

It's not at all clear that the "Persistent URI" article you referenced has
anything to do with whether a redirect is used for a welcome file or not
 (the original persistent URI that the *human* used is still the same,
no matter what technology is used on the server end) ... but there is a
practical reason for the current behavior as well.

Originally (back in the pre-3.2-final days), Tomcat did the equivalent of
a RequestDispatcher.forward() to display welcome pages.  This caused
massive problems for people who didn't understand the difference between:

  http://foo.bar/webapp

and

  http://foo.bar/webapp/

In the former case, any relative urls on the "real" welcome page are
broken.  This caused bug reports about welcome files not working (never
mind that using a  element in your welcome page would have fixed
it), which led to the current behavior.


> Cheers,
> jan
>

Craig


> PS. original message here:
>   http://w4.metronet.com/~wjm/tomcat/2001/Apr/msg00234.html
> - in a nutshell: if I request http://foo.bar/webapp/
> I'd like to see the contents of .../webapp/index.html, but _not_ see a
> redirect to http://foo.bar/webapp/index.html
>
>
> --
> jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
> Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 [EMAIL PROTECTED]
> ( echo "ouroboros"; cat ) > /dev/fd/0 # it's like talking to yourself sometimes
>
>

DO NOT REPLY [Bug 3944] New: - request.getRemoteAddr() always returning 127.0.0.1

[bugzilla]

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

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

request.getRemoteAddr() always returning 127.0.0.1

   Summary: request.getRemoteAddr() always returning 127.0.0.1
   Product: Tomcat 3
   Version: 3.3 Release Candidate 1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hello,
I recently upgraded to tomcat 3.3rc1 and I'm not able any more to detect 
address of people connecting to my web site since I always get 127.0.0.1 as 
RemoteAddress and always localhost as RemoteHost.
Is it a know issue and is there any work around? I need it also because I do 
some computation/statistics on network addresses.

Thanks for the help and keep up the great work,
Alex

DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance

[bugzilla]

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

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

SingleThreadModel servlets not pooled results in low performance





--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 09:09 ---
If you (or anyone else) would like STM pooling support added, please submit a
patch to make it so.

Re: [Tomcat 4.1] Proposed Slight Binary Distribution Rearrangement

[Craig R. McClanahan]

On Wed, 3 Oct 2001, Jeff Turner wrote:

> Date: Wed, 3 Oct 2001 19:41:47 +1000
> From: Jeff Turner <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [Tomcat 4.1] Proposed Slight Binary Distribution
> Rearrangement
>
> How about naming it "common" instead of "shared", to match Tomcat 3.3?
>

There is already a "common" directory, whose "common/classes" and
"common/lib" subdirectories are added to the "Common" class loader.  In
fact, it is *this* pattern that I want "shared" to match :-).

> --Jeff
>

Craig

Re: ClassCastException

[Fernando_Salazar]

I believe you have the various jar's in the "wrong" locations.  They're
wrong because, even though all the classes
you need are there, they end up in incompatible class loaders.  Make sure
that:

* tyrex jar, jta jar, and jdbc optional jar are in common/lib.
* your JDBC driver jar is in common/lib, and *not* also in WEB-INF/lib

Possibly other setups will work correctly -- the stuff above works for us.
I know definitely that mislocating jar's
-- like putting drivers in server/lib -- results in the exact CCE that you
list below.

- Fernando



   

"Alessandro

Pizzolotto"  To: <[EMAIL PROTECTED]>   

  Subject: Re: ClassCastException   

   

10/03/2001 

11:10 AM   

Please respond 

to tomcat-dev  

   

   





hehehe
if i use this class:
tyrex.jdbc.xa.EnabledDataSource
instead
javax.sql.DataSource
the program works fine
the problem is that EnableDataSource implements javax.sql.DataSource but i
can't cast javax.sql.DataSource.
why ???

Alessandro
- Original Message -
From: "Will Stranathan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 03, 2001 3:04 PM
Subject: Re: ClassCastException


> Can we see the appropriate parts of server.xml and web.xml?
>
> Will Stranathan
>
> Alessandro Pizzolotto wrote:
>
> > this code
> >
> > javax.naming.Context ctx = new javax.naming.InitialContext();
> > javax.naming.Context cto =
(javax.naming.Context)ctx.lookup("java:/comp/env");
> > javax.sql.DataSource ds =
(javax.sql.DataSource)cto.lookup("jdbc/domus");
> >
> > produce this error
> >
> > java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource
> >  at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74)
> >  at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> >  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
> >  at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja

va:201)
> >  at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
> >  at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
> >  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
> >  at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application

FilterChain.java:247)
> >  at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh

ain.java:193)
> >  at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja

va:243)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5

66)
> >  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >  at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >  at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja

va:215)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5

66)
> >  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >  at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >  at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2366)
> >  at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164

)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5

66)
> >  at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5

64)
> >  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >  at
org.apache.catalina.core.Contain

DO NOT REPLY [Bug 3941] New: - PrinWriter.flush() HttpServletResponse.flushBuffer() do not work

[bugzilla]

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

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

PrinWriter.flush() HttpServletResponse.flushBuffer() do not work

   Summary: PrinWriter.flush() HttpServletResponse.flushBuffer() do
not work
   Product: Tomcat 4
   Version: 4.0 Release Candidate 2
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Flushing of buffered output from a servlet to a client does not work as shown in  
the following Servlet code and Clinet code. This problem only occured in Tomcat 
4 where the output only occures after closing the PrintWriter. The flushing 
works fine with Tomcat 3.2.3 for both the Prinwriter and the 
HttpServletResponse.

HERE IS THE SERVLET TEST CODE:

import java.io.IOException;
import java.io.PrintWriter;
import java.util.Enumeration;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public final class Server extends HttpServlet {

/**
 * Respond to a GET request for the content produced by
 * this servlet.
 *
 * @param request The servlet request we are processing
 * @param response The servlet response we are producing
 *
 * @exception IOException if an input/output error occurs
 * @exception ServletException if a servlet error occurs
 */
public void doGet(HttpServletRequest request,
  HttpServletResponse response)
throws IOException, ServletException {

response.setContentType("text/xml");
PrintWriter writer = response.getWriter();
writer.println("buffersize:" + response.getBufferSize());


writer.println("\nTest:");
writer.println("initial isCommited:" + response.isCommitted());

writer.println("\nresponse");
writer.flush();
writer.println("after writer.flush() isCommited:" + 
response.isCommitted());

writer.println("\nParameters"); 
response.flushBuffer();
writer.println("after response.flushBuffer() isCommited:" + 
response.isCommitted());

Enumeration names = request.getParameterNames();
while (names.hasMoreElements()) {
String name = (String) names.nextElement();
writer.println(name + ": " + request.getParameter(name));
writer.println("Waiting 2secs\n");
//THESE ARE THE 2 PROBLEMATIC LINES -NONE OF THEM WORKS WITH TOMCAT 4
writer.flush();
response.flushBuffer();

try {
Thread.sleep(2000);
}
catch (InterruptedException e){
}
}
}

public void doPost(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
doGet(request, response);
}
}

AND HERE IS THE CLIENT CODE:

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.IOException;
import java.io.PrintWriter;
import java.net.URL;
import java.net.URLDecoder;
import java.net.URLEncoder;
import java.net.URLConnection;

public class Client {

public static void main(String[] args) {
String query = 
"http://localhost:8080/Server1/Server1?banana=yellow&snow=white&sea=blue";;

try {
URL url = new URL(query);
BufferedReader in = new BufferedReader(new 
InputStreamReader(url.openStream()));
String line;
while ((line = in.readLine()) != null)
System.out.println(line);

} catch(IOException e) {
System.out.println("Error " + e);
}
}
}

Re: ClassCastException

[Alessandro Pizzolotto]

hehehe
if i use this class:
tyrex.jdbc.xa.EnabledDataSource
instead
javax.sql.DataSource
the program works fine
the problem is that EnableDataSource implements javax.sql.DataSource but i
can't cast javax.sql.DataSource.
why ???

Alessandro
- Original Message -
From: "Will Stranathan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 03, 2001 3:04 PM
Subject: Re: ClassCastException


> Can we see the appropriate parts of server.xml and web.xml?
>
> Will Stranathan
>
> Alessandro Pizzolotto wrote:
>
> > this code
> >
> > javax.naming.Context ctx = new javax.naming.InitialContext();
> > javax.naming.Context cto =
(javax.naming.Context)ctx.lookup("java:/comp/env");
> > javax.sql.DataSource ds =
(javax.sql.DataSource)cto.lookup("jdbc/domus");
> >
> > produce this error
> >
> > java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource
> >  at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74)
> >  at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> >  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
> >  at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
va:201)
> >  at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
> >  at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
> >  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
> >  at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
> >  at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
> >  at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:243)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
> >  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >  at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >  at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:215)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
> >  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >  at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >  at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2366)
> >  at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164
)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
> >  at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
> >  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >  at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >  at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:163)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
> >  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >  at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >  at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:
1005)
> >  at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1098
)
> >  at java.lang.Thread.run(Thread.java:484)
> >
> > the code not get the cast in DataSource
> > why ?
> > tanks
> > Alessadro
> >
> >
>
>
>

DO NOT REPLY [Bug 3939] New: - HttpServletResponse.SC_UNAUTHORIZED incorrectly trapped by Tomcat

[bugzilla]

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

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

HttpServletResponse.SC_UNAUTHORIZED incorrectly trapped by Tomcat

   Summary: HttpServletResponse.SC_UNAUTHORIZED incorrectly trapped
by Tomcat
   Product: Tomcat 4
   Version: 4.0 Final
  Platform: PC
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


My application managed security sends a HttpServletResponse.SC_UNAUTHORIZED
error to trigger the browser to ask for details from the user.  However, Tomcat
traps this error and redirects to an error page instead of passing the HTTP 401
error on to the browser.  I cannot find a workaround, hence my application is
unusable.  Broken in Mozilla and IE, strangely works in Netscape 4.7x

Re: ClassCastException

[Alessandro Pizzolotto]

sure :)
WEB.XML


http://java.sun.com/dtd/web-app_2_3.dtd";>


  jdbc/domus
  javax.sql.DataSource
  Container


#
SERVER.XML
##à
 

   

user
user


  
password
password


driverClassName
weblogic.jdbc.mssqlserver4.Driver


driverName
jdbc:weblogic:mssqlserver4:domus@localhost:1433

   
 
##


i tink that this part is correct ??

- Original Message -
From: "Will Stranathan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 03, 2001 3:04 PM
Subject: Re: ClassCastException


> Can we see the appropriate parts of server.xml and web.xml?
>
> Will Stranathan
>
> Alessandro Pizzolotto wrote:
>
> > this code
> >
> > javax.naming.Context ctx = new javax.naming.InitialContext();
> > javax.naming.Context cto =
(javax.naming.Context)ctx.lookup("java:/comp/env");
> > javax.sql.DataSource ds =
(javax.sql.DataSource)cto.lookup("jdbc/domus");
> >
> > produce this error
> >
> > java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource
> >  at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74)
> >  at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> >  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
> >  at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
va:201)
> >  at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
> >  at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
> >  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
> >  at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
> >  at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
> >  at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:243)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
> >  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >  at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >  at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:215)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
> >  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >  at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >  at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2366)
> >  at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164
)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
> >  at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
> >  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >  at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >  at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:163)
> >  at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
> >  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >  at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >  at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:
1005)
> >  at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1098
)
> >  at java.lang.Thread.run(Thread.java:484)
> >
> > the code not get the cast in DataSource
> > why ?
> > tanks
> > Alessadro
> >
> >
>
>
>

RE: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows

[Marc Saegesser]

It probably isn't a big deal now.  I've got the .dsp file working now.  Once
I'm satisfied everything is OK I'll commit the changes and also export a
Windows makefile so that I can build without using the damned IDE.


Marc Saegesser

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of jean-frederic clere
> Sent: Wednesday, October 03, 2001 3:30 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows
>
>
> Justin Erenkrantz wrote:
> >
> > On Tue, Oct 02, 2001 at 01:24:53PM -0500, Marc Saegesser wrote:
> > > I'll grab the latest CVS and see how that works.
> > >
> > > The buildconf.sh in jk/native/Apache-2.0 runs libtoolize,
> automake, aclocal
> > > and autoconf.  Cygwin includes all of these except libtool.
> I built it and
> > > installed it into /usr/local/bin and bad things happened.  I
> put it into
> > > /usr/bin and things ran fine.
> >
> > Ah, that's jk-specific.  It might be a good idea to try to remove the
> > automake dependency if at all possible as we don't require it for
> > httpd.
>
> That is possible - But that means to commit some automake
> generated files or to
> duplicate these files -
>
> >  All of the others are required for Apache 2.0.
> >
> > Pier has a good build system with 2.0 for mod_webapp.  =)  -- justin

Re: [PATCH] mod_webapp build cleanups...

[jean-frederic clere]

Justin Erenkrantz wrote:
> 
> I finally got a chance to build mod_webapp from j-t-c with Apache 2.0.
> Looks good and is quite easy to do.  Only problem is that we aren't
> handling directories properly.  If you do the examples webapp, you
> see a link to:
> 
> http://localhost:8080/examples/servlets/
> 
> Going there results in a bad response (actually nothing returned!),
> but
> 
> http://localhost:8080/examples/servlets/index.html
> 
> works.  I'm not terribly sure if httpd or Tomcat should be handling
> this case (i.e. redirecting or handling DirectoryIndex-type semantics).
> Somebody isn't handling it and that's not good.

I have fixed it (The port handling was wrong).

> 
> You will find attached a patch that cleans up some of the build
> process in j-t-c so that it works with Apache 2.0 cleanly and
> fixes some tpyos and formatting quirks.

I have committed the patch (it builds better with it ;-)).
 
> 
> The only questionable thing is that lib/libwebapp.a isn't built by
> libtool.  The simple straightforward ar and ranlib should work fine,
> but it may not work on all systems.  When linking mod_webapp.lo with
> libwebapp.a, libtool emits a warning.  It may be worth it to try and
> use APR's libtool to compile and link all of the files in lib (this
> would produce lib/libwebapp.la).
> 
> Enjoy.  Oh, and Pier, thanks for dinner.  =-)  This is my
> payback...  -- justin
> 
> Index: webapp/Makefile.in
> ===
> RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/Makefile.in,v
> retrieving revision 1.20
> diff -u -r1.20 Makefile.in
> --- webapp/Makefile.in  2001/09/17 05:06:27 1.20
> +++ webapp/Makefile.in  2001/10/01 06:39:24
> @@ -107,6 +107,12 @@
>  apache-1.3-clean:
> @$(MAKE) template MFLG="$(MAKEFLAGS)" MDIR="apache-1.3" MTGT="clean"
> 
> +apache-2.0-build:
> +   @$(MAKE) template MFLG="$(MAKEFLAGS)" MDIR="apache-2.0" MTGT="build"
> +
> +apache-2.0-clean:
> +   @$(MAKE) template MFLG="$(MAKEFLAGS)" MDIR="apache-2.0" MTGT="clean"
> +
>  template:
> @ { \
> $(ECHO) "" ; \
> Index: webapp/configure.in
> ===
> RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/configure.in,v
> retrieving revision 1.39
> diff -u -r1.39 configure.in
> --- webapp/configure.in 2001/09/17 05:07:01 1.39
> +++ webapp/configure.in 2001/10/01 06:39:24
> @@ -177,7 +177,7 @@
>  dnl Upd vars: N/A
>  dnl -
>  AC_ARG_WITH(tomcat,
> -  [  --with-tomcat[=DIR] path of a Tomcat 4.0 distribution. (DIR defaults
> +  [  --with-tomcat[=DIR]   path of a Tomcat 4.0 distribution. (DIR defaults
>to \"/usr/local/tomcat\"). Not required and ignored
>when the --enable-java option is not specified.],
>[
> @@ -241,7 +241,7 @@
>  AC_MSG_CHECKING([for C API documentation])
>  AC_ARG_ENABLE(apidocs-c,
>[  --enable-apidocs-c[=PERL]
> -  enbale generation of C API documentation using
> +  enable generation of C API documentation using
>ScanDoc (PERL is the name of the Perl interpreter
>used to run ScanDoc. If not specified this is
>looked up in your current path).],
> @@ -302,7 +302,7 @@
>  AC_MSG_CHECKING([for Java API documentation])
>  AC_ARG_ENABLE(apidocs-java,
>[  --enable-apidocs-java[=JAVADOC]
> -  enbale generation of Java API documentation using
> +  enable generation of Java API documentation using
>JavaDoc (If JAVADOC is not set its value will be
>discovered by \"--enable-java\").],
>[
> @@ -347,10 +347,10 @@
>  dnl Upd vars: APR_SRCDIR
>  dnl --
>  AC_ARG_WITH(apr,
> -  [  --with-apr[=DIR]path of an APR (Apache Portable Runtime) source
> +  [  --with-apr[=DIR]  path of an APR (Apache Portable Runtime) source
>distribution or CVS snapshot. (DIR defaults to
> -  \"./apr\"). Not required and ignored when the
> -  --with-apxs2 option is specified.],
> +  \"./apr\"). Not required and ignored when an
> +  Apache 2.0 apxs is specified (--with-apxs).],
>[
>  case "${withval}" in
>  ""|"yes"|"YES"|"true"|"TRUE")
> @@ -382,7 +382,7 @@
>  dnl --
>  AC_MSG_CHECKING([for Apache apxs])
>  AC_ARG_WITH(apxs,
> -  [  --with-apxs[=FILE]  build a shared Apache module. If FILE was not
> +  [  --with-apxs[=FILE]build a shared Apache module. If FILE was not
>specified, 

cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_webapp.c

[jfclere]

jfclere 01/10/03 06:42:57

  Modified:webapp/apache-2.0 mod_webapp.c
  Log:
  Fix the port (the direct was not working).
  
  Revision  ChangesPath
  1.4   +3 -3  jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c
  
  Index: mod_webapp.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- mod_webapp.c  2001/09/12 16:29:05 1.3
  +++ mod_webapp.c  2001/10/03 13:42:57 1.4
  @@ -57,7 +57,7 @@
   
   /**
* @author  Pier Fumagalli 
  - * @version $Id: mod_webapp.c,v 1.3 2001/09/12 16:29:05 pier Exp $
  + * @version $Id: mod_webapp.c,v 1.4 2001/10/03 13:42:57 jfclere Exp $
*/
   
   #include 
  @@ -459,9 +459,9 @@
   req->serv->addr=apr_pstrdup(req->pool,con->local_ip);
   req->clnt->addr=apr_pstrdup(req->pool,con->remote_ip);
   apr_sockaddr_port_get(&port, con->local_addr);
  -req->serv->port=ntohs(port);
  +req->serv->port= (int) port;
   apr_sockaddr_port_get(&port, con->remote_addr);
  -req->clnt->port=ntohs(port);
  +req->clnt->port= (int) port;
   
   /* Set up all other members of the request structure */
   req->meth=apr_pstrdup(req->pool,(char *)r->method);
  
  
  

welcome files being forwarded to rather than redirected to?

[Jan Grant]

A while ago I sent a message about the behaviour of welcome files going
against the recommendations at http://www.w3.org/Provider/Style/URI; at
the time the servlet spec was in PFD and was fairly explicit that
sending a redirect wasn't acceptable.

Looking at the final spec, it appears that they've toned down their
language a little - nevertheless, this kind of behaviour (avoiding
redirects) seems preferable.

Unfortunately, the latest stable tomcat/catalina (congrats on this, by
the way!) still behaves in the old way.

I know I can explicitly map any URIs to particular JSPs or html files;
however, I'd like to avoid having to do that (the convenience of welcome
files is completely lost).

Is this set in stone?

Cheers,
jan

PS. original message here:
http://w4.metronet.com/~wjm/tomcat/2001/Apr/msg00234.html
- in a nutshell: if I request http://foo.bar/webapp/
I'd like to see the contents of .../webapp/index.html, but _not_ see a
redirect to http://foo.bar/webapp/index.html


-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 [EMAIL PROTECTED]
( echo "ouroboros"; cat ) > /dev/fd/0 # it's like talking to yourself sometimes

Re: ClassCastException

[Will Stranathan]

Can we see the appropriate parts of server.xml and web.xml?

Will Stranathan

Alessandro Pizzolotto wrote:

> this code 
> 
> javax.naming.Context ctx = new javax.naming.InitialContext();
> javax.naming.Context cto = (javax.naming.Context)ctx.lookup("java:/comp/env");
> javax.sql.DataSource ds = (javax.sql.DataSource)cto.lookup("jdbc/domus");
> 
> produce this error
> 
> java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource
>  at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74)
>  at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
>  at 
>org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:201)
>  at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
>  at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
>  at 
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
>  at 
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
>  at 
>org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
>  at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
>  at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>  at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>  at 
>org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:215)
>  at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
>  at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>  at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>  at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2366)
>  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
>  at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
>  at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
>  at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
>  at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>  at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)
>  at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
>  at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>  at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>  at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1005)
>  at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1098)
>  at java.lang.Thread.run(Thread.java:484)
> 
> the code not get the cast in DataSource 
> why ?
> tanks
> Alessadro
> 
> 

cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 Makefile.in

[jfclere]

jfclere 01/10/03 05:35:14

  Modified:webapp   Makefile.in configure.in
   webapp/apache-2.0 Makefile.in
  Log:
  mod_webapp build cleanups
  Submitted by: Justin Erenkrantz [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.21  +7 -1  jakarta-tomcat-connectors/webapp/Makefile.in
  
  Index: Makefile.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/Makefile.in,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- Makefile.in   2001/09/17 05:06:27 1.20
  +++ Makefile.in   2001/10/03 12:35:14 1.21
  @@ -56,7 +56,7 @@
   # = #
   
   # @author  Pier Fumagalli 
  -# @version $Id: Makefile.in,v 1.20 2001/09/17 05:06:27 pier Exp $
  +# @version $Id: Makefile.in,v 1.21 2001/10/03 12:35:14 jfclere Exp $
   
   include @TGTDIR@/Makedefs
   
  @@ -106,6 +106,12 @@
   
   apache-1.3-clean:
@$(MAKE) template MFLG="$(MAKEFLAGS)" MDIR="apache-1.3" MTGT="clean"
  +
  +apache-2.0-build:
  +   @$(MAKE) template MFLG="$(MAKEFLAGS)" MDIR="apache-2.0" MTGT="build"
  +
  +apache-2.0-clean:
  +   @$(MAKE) template MFLG="$(MAKEFLAGS)" MDIR="apache-2.0" MTGT="clean"
   
   template:
@ { \
  
  
  
  1.40  +9 -9  jakarta-tomcat-connectors/webapp/configure.in
  
  Index: configure.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v
  retrieving revision 1.39
  retrieving revision 1.40
  diff -u -r1.39 -r1.40
  --- configure.in  2001/09/17 05:07:01 1.39
  +++ configure.in  2001/10/03 12:35:14 1.40
  @@ -58,7 +58,7 @@
   dnl --
   dnl Author Pier Fumagalli 
   dnl Author Jon S. Stevens 
  -dnl Version $Id: configure.in,v 1.39 2001/09/17 05:07:01 pier Exp $
  +dnl Version $Id: configure.in,v 1.40 2001/10/03 12:35:14 jfclere Exp $
   dnl --
   
   dnl --
  @@ -177,7 +177,7 @@
   dnl Upd vars: N/A
   dnl -
   AC_ARG_WITH(tomcat,
  -  [  --with-tomcat[=DIR] path of a Tomcat 4.0 distribution. (DIR defaults
  +  [  --with-tomcat[=DIR]   path of a Tomcat 4.0 distribution. (DIR defaults
 to \"/usr/local/tomcat\"). Not required and ignored
 when the --enable-java option is not specified.],
 [
  @@ -241,7 +241,7 @@
   AC_MSG_CHECKING([for C API documentation])
   AC_ARG_ENABLE(apidocs-c,
 [  --enable-apidocs-c[=PERL]
  -  enbale generation of C API documentation using
  +  enable generation of C API documentation using
 ScanDoc (PERL is the name of the Perl interpreter
 used to run ScanDoc. If not specified this is
 looked up in your current path).],
  @@ -302,7 +302,7 @@
   AC_MSG_CHECKING([for Java API documentation])
   AC_ARG_ENABLE(apidocs-java,
 [  --enable-apidocs-java[=JAVADOC]
  -  enbale generation of Java API documentation using
  +  enable generation of Java API documentation using
 JavaDoc (If JAVADOC is not set its value will be
 discovered by \"--enable-java\").],
 [
  @@ -347,10 +347,10 @@
   dnl Upd vars: APR_SRCDIR
   dnl --
   AC_ARG_WITH(apr,
  -  [  --with-apr[=DIR]path of an APR (Apache Portable Runtime) source
  +  [  --with-apr[=DIR]  path of an APR (Apache Portable Runtime) source
 distribution or CVS snapshot. (DIR defaults to
  -  \"./apr\"). Not required and ignored when the
  -  --with-apxs2 option is specified.],
  +  \"./apr\"). Not required and ignored when an
  +  Apache 2.0 apxs is specified (--with-apxs).],
 [
   case "${withval}" in
   ""|"yes"|"YES"|"true"|"TRUE")
  @@ -382,7 +382,7 @@
   dnl --
   AC_MSG_CHECKING([for Apache apxs])
   AC_ARG_WITH(apxs,
  -  [  --with-apxs[=FILE]  build a shared Apache module. If FILE was not
  +  [  --with-apxs[=FILE]build a shared Apache module. If FILE was not
 specified, then APXS will be searched within the
 current PATH. The Apache server version (1.3 or 2.0)
 

DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance

[bugzilla]

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

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

SingleThreadModel servlets not pooled results in low performance





--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 04:59 ---
First, let me clarify that my arguments are mainly
for the servlet SingleThreadModel interface, the JSP
'isThreadSafe="false"' declaration I can do without.


It seems like you have two major arguments,

1: many users don't understand how STM works and

2: it doesn't solve any real problems.


The first one is a documentation and education problem imho.
(Maybe removing the JSP 'isThreadSafe="false"' declaration
partially solves this problem. No doubt naming it 'isThreadSafe'
has contributed to the confusion.)

Note also that the assumption that there exists only one instance
of a (non-STM) servlet is broken anyway in any real world
installation using more than one web server and servlet engine.


For the second one, we have a servlet library providing different
kinds of functionality for JSPs using our product. The servlet
library is a small tree of classes. The functionality provided
consists of both methods and members. The JSPs extends a servlet
to import the wanted functionality.

SingleThreadModel is used to make this scheme work when
a servlet implements members with request specific data.

These members can be replaced with access methods, but for
all but the most trivial cases the access method now
needs to store the computed information in the request scope
instead (this is just an optimization for read-only data,
but absolutely necessary for read-write data).

Storing the data in members simplifies the code internally
but the main reason we use it is that it provides a simpler API
for our clients (implementing JSPs). Adding members adds
implicit objects that can be used directly in the JSP just as the
default implicit objects ('request', 'response', 'out' etc).
This is a much more seamless extension of a standard JSP than
possible with access methods.

Re: [Tomcat 4.1] Proposed Slight Binary Distribution Rearrangement

[jean-frederic clere]

Jeff Turner wrote:
> 
> How about naming it "common" instead of "shared", to match Tomcat 3.3?

There is already a  common/lib in TC4.0

> 
> --Jeff
> 
> On Tue, Oct 02, 2001 at 04:54:54PM -0700, Craig R. McClanahan wrote:
> > I'd like to propose a small change in the binary distribution layout for
> > the next version of Tomcat (4.1).  It's probably not a good idea to
> > introduce this in a 4.0.1 maintenance update, though.
> >
> > Currently, the "Shared" class loader is set up based on unpacked classes
> > in the "$CATALINA_HOME/classes" directory plus JAR files in the
> > "$CATALINA_HOME/lib" directory.  I would like to suggest that we change
> > this to "$CATALINA_HOME/shared/classes" and "$CATALINA_HOME/shared/lib"
> > instead, to have the directory names be more consistent with the class
> > loader names.
> >
> > Anybody have any comments or thoughts on this?
> >
> > Craig
> >

Re: [Tomcat 4.1] Proposed Slight Binary Distribution Rearrangement

[Jeff Turner]

How about naming it "common" instead of "shared", to match Tomcat 3.3?

--Jeff


On Tue, Oct 02, 2001 at 04:54:54PM -0700, Craig R. McClanahan wrote:
> I'd like to propose a small change in the binary distribution layout for
> the next version of Tomcat (4.1).  It's probably not a good idea to
> introduce this in a 4.0.1 maintenance update, though.
> 
> Currently, the "Shared" class loader is set up based on unpacked classes
> in the "$CATALINA_HOME/classes" directory plus JAR files in the
> "$CATALINA_HOME/lib" directory.  I would like to suggest that we change
> this to "$CATALINA_HOME/shared/classes" and "$CATALINA_HOME/shared/lib"
> instead, to have the directory names be more consistent with the class
> loader names.
> 
> Anybody have any comments or thoughts on this?
> 
> Craig
> 

ClassCastException

[Alessandro Pizzolotto]

this code 

javax.naming.Context ctx = new javax.naming.InitialContext();
javax.naming.Context cto = (javax.naming.Context)ctx.lookup("java:/comp/env");
javax.sql.DataSource ds = (javax.sql.DataSource)cto.lookup("jdbc/domus");

produce this error

java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource
 at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74)
 at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
 at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:201)
 at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
 at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
 at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:215)
 at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
 at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
 at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2366)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
 at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
 at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
 at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
 at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)
 at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
 at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
 at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1005)
 at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1098)
 at java.lang.Thread.run(Thread.java:484)

the code not get the cast in DataSource 
why ?
tanks
Alessadro

DO NOT REPLY [Bug 3936] New: - getResources does not work

[bugzilla]

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

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

getResources does not work

   Summary: getResources does not work
   Product: Tomcat 4
   Version: 4.0 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


WebappClassLoader does not seem to implement getResources properly. There is an
implementation for getResource that does things properly, but findResources
simply delegates to super(). 

For example, this means that if I have multiple JAR files in WEB-INF/lib each of
which contains a file foo.txt, and I want to get URL's to all of those files, I
cannot use getResources("foo.txt") as I should be able to.

Re: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows

[jean-frederic clere]

Justin Erenkrantz wrote:
> 
> On Tue, Oct 02, 2001 at 01:24:53PM -0500, Marc Saegesser wrote:
> > I'll grab the latest CVS and see how that works.
> >
> > The buildconf.sh in jk/native/Apache-2.0 runs libtoolize, automake, aclocal
> > and autoconf.  Cygwin includes all of these except libtool.  I built it and
> > installed it into /usr/local/bin and bad things happened.  I put it into
> > /usr/bin and things ran fine.
> 
> Ah, that's jk-specific.  It might be a good idea to try to remove the
> automake dependency if at all possible as we don't require it for
> httpd.

That is possible - But that means to commit some automake generated files or to
duplicate these files -

>  All of the others are required for Apache 2.0.
> 
> Pier has a good build system with 2.0 for mod_webapp.  =)  -- justin