3.3 - top level files

[cmanolache]

Hi,

There are a number of doc files at the top level, some of them old release
plans, etc. What about moving them in doc/release ( so they will be
included in the distrib - right now we don't ) ?

( we need to clean up and update the docs - but this can be done after the
freeze ) 

Costin 


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

cvs commit: jakarta-tomcat/modules README

[costin]

costin  01/03/09 23:30:20

  Removed: apps README
   modules  README
  Log:
  Remove the 2 directories I created, for experimental modules and
  apps. I'll create them again in proposals.

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

cvs commit: jakarta-tomcat TODO

[costin]

costin  01/03/09 23:27:03

  Removed: .TODO
  Log:
  Removing the TODO from 3.1, most of it is done, what is not done is
  either part of status.html or unlikely to happen.
  
  There are a lot of TODO things ( or at least my list is bigger than ever),
  but status.html is the place to record them.

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

cvs commit: jakarta-tomcat generatedocs.bat generatedocs.sh

[costin]

costin  01/03/09 23:23:46

  Removed: .generatedocs.bat generatedocs.sh
  Log:
  Removing old generatedocs.sh/bat - they were used to generate
  javax.servlet docs, this was moved long ago in a separate tree.

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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config LoaderInterceptor11.java

[costin]

costin  01/03/09 23:22:20

  Modified:src/facade22/org/apache/tomcat/facade JspInterceptor.java
   src/share/org/apache/tomcat/modules/config
LoaderInterceptor11.java
  Removed: .ant.dtd
  Log:
  Remove ant.dtd ( it's outdated and not needed )
  
  Revision  ChangesPath
  1.18  +1 -1  
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/JspInterceptor.java
  
  Index: JspInterceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/JspInterceptor.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- JspInterceptor.java   2001/03/09 23:33:59 1.17
  +++ JspInterceptor.java   2001/03/10 07:22:20 1.18
  @@ -444,7 +444,7 @@
if( h!= null ) {
log( "Name already exists " + servletName +
 " while mapping " + uri);
  - return null; // exception ?
  + return (ServletHandler)h; // exception ?
}

ServletHandler wrapper=new ServletHandler();
  
  
  
  1.10  +0 -1  
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LoaderInterceptor11.java
  
  Index: LoaderInterceptor11.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LoaderInterceptor11.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- LoaderInterceptor11.java  2001/03/09 23:47:39 1.9
  +++ LoaderInterceptor11.java  2001/03/10 07:22:20 1.10
  @@ -62,7 +62,6 @@
   import org.apache.tomcat.core.*;
   import org.apache.tomcat.util.*;
   import org.apache.tomcat.util.compat.*;
  -import org.apache.tomcat.util.depend.*;
   import java.io.*;
   import java.net.*;
   import java.util.*;
  
  
  

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

cvs commit: jakarta-tomcat/src/tests/webpages/params includeISParams.jsp

[costin]

costin  01/03/09 23:21:38

  Modified:src/tests/webpages/jsp import.jsp
   src/tests/webpages/params includeISParams.jsp
  Log:
  Fix the sanity tests - Vector and Writer are not imported by default
  ( it was a bug that they were )
  
  Revision  ChangesPath
  1.4   +1 -0  jakarta-tomcat/src/tests/webpages/jsp/import.jsp
  
  Index: import.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/jsp/import.jsp,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- import.jsp1999/11/12 21:30:28 1.3
  +++ import.jsp2001/03/10 07:21:37 1.4
  @@ -1,5 +1,6 @@
   
   <%@ page import="java.util.Hashtable" %>
  +<%@ page import="java.util.Vector" %>
 
   <% 
   Hashtable hash = new Hashtable();
  
  
  
  1.2   +1 -1  jakarta-tomcat/src/tests/webpages/params/includeISParams.jsp
  
  Index: includeISParams.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/params/includeISParams.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- includeISParams.jsp   2001/02/10 22:37:32 1.1
  +++ includeISParams.jsp   2001/03/10 07:21:37 1.2
  @@ -1,6 +1,6 @@
   <% 
   response.setContentType("text/plain");
  -PrintWriter outW = response.getWriter();
  +java.io.PrintWriter outW = response.getWriter();
   
// No parameter is read 
   
  
  
  

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

cvs commit: jakarta-tomcat build.xml

[costin]

costin  01/03/09 23:18:51

  Modified:.build.xml
  Log:
  First small change to build.xml - use the same name pattern for
  jaxp ( jaxp.home - for the dir where jaxp is installed ), fix it
  to match the directory name in the distrib.
  
  Also - split the distrib, so you can build a distrib without javadocs
  ( very time consuming ) - the default distrib target works as before.
  
  Revision  ChangesPath
  1.120 +28 -28jakarta-tomcat/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/build.xml,v
  retrieving revision 1.119
  retrieving revision 1.120
  diff -u -r1.119 -r1.120
  --- build.xml 2001/03/04 03:27:25 1.119
  +++ build.xml 2001/03/10 07:18:50 1.120
  @@ -1,12 +1,4 @@
   
  -
   
   
 
  @@ -22,10 +14,15 @@
   
   
 
  +  
   
 
 
  -  
  +  
  +  
   
 

  @@ -75,18 +72,17 @@
   
   
   
  +
   
   
   
  +   file="${jaxp.home}/jaxp.jar"/>
   
  +   file="${jaxp.home}/parser.jar"/>
   
  -
  +   file="${jaxp.home}/jaxp.jar"/>
   
   
  @@ -422,7 +418,10 @@
 
   
 
  -  
  +  
  +   
  +
  +  
   
   
   
  @@ -432,13 +431,15 @@
   
 
   
  -
  -
  -
   
  +
  +
  +
  +
  +
  +  
  +
  +  
   
   
   
  -
  +  
  +  
   
  +  
  +
  +
  +
   
   
  -
  -
  -
  -
  -
  -
 
   
 
  
  
  

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

RE: where to plug-in startup/shutdown knowledge for internal tomcatcomponents

[cmanolache]

Hi Casey,

Welcome to the wonderful world of ClassLoading.

The default configuration for 3.3 is to use a separate class loader for
container ( i.e. tomcat.core, jasper, jaxp ) and web applications. 

This resolves a number of problems - like having a different parser in the
web application. 

It also resolves the problem of overriding and fine-control over what is
seen in the web app, and does enhance the security ( most classes that are
 visible in container are "trusted" ).

But what I love about this is that it forces us to make a clear
distinction between what is runtime and what is internal to the container.

To answer to your problem:  I assume TagPoolManager will be available at
runtime to jsps. So it should be included in the common runtime, shared by
both webapps and container. 

TagPoolInterceptor is a container extension, so it'll be part of the
container loader. You shouldn't use static fields in general, but if you
do keep in mind that "static" refers to the ClassLoader+Class combination
( you have one instance of the static field for each class loader ).

BTW, this operating mode ( with multiple loaders ) is the most flexible
for tomcat. The old mechanism still works ( with the old limitations ),
but requires some code to enable it ( it's mostly for embeded tomcat ).


Costin


On Sat, 10 Mar 2001, Casey Lucas wrote:
> 
> Now, I'm testing the pooling stuff out.  I've got a
> TagPoolManagerInterceptor that listens to contextInit, etc.  But my
> problem is that the static TagPoolManager reference that I initialize
> in contextInit always ends up null when the jsp runs.  I put a print statement
> in the static initializer of TagPoolManager and I can see that it is
> being called once when tomcat starts up (and the various contexts are
> loaded) and a second time when the jsp is run.  I assume that there's
> some class loader stuff going on that I don't understand.
> 
> I looked at JspFactory because I'm using the same set/getDefault idiom.
> It some how keeps its static reference that is initilized in contextInit.
> My code seems to be just like JspFactory, yet my static gets reinitialized
> to null.
> 
> Any suggestions?
> 
> -Casey
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, March 09, 2001 2:29 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: where to plug-in startup/shutdown knowledge for internal
> > tomcat components
> > 
> > 
> > On Fri, 9 Mar 2001, Casey Lucas wrote:
> > 
> > > So, given all that, I need to control lifetime of TagHandlerPoolManager's
> > > default instance.  By controlling it, I can have one TagHandlerPoolManager
> > > instance per web application and when the web application gets unloaded,
> > > all the Tag.release methods can be called.  Aren't the JspServlet and
> > > JspInterceptor mechanisms specific to an individual jsp file?  If so,
> > > I don't think that's what I need because pooling will be for the entire
> > > web application not a specific JSP.
> > 
> > > I was hoping that when the web application (not individual jsp) is
> > > loaded, unloaded, reloaded I could do the TagHandlerPoolManager initialization
> > > and cleanup tasks.  Maybe I'm making things too complicated.  Should
> > > managing the lifetime of a per-web-application object like
> > > TagHandlerPoolManager be simpler?
> > 
> > And you have 2 solutions:
> > 1. Use tomcat hooks. You can let a tomcat module manager the
> > TagHandlerPool and you'll get all the notifications you need. 
> > Just implement and TagPoolManagerInterceptor module, implement
> > the hooks you need ( addContext, contextInit, reload, etc).
> > 
> > 2. Use some "hacks" in the generated init()/destroy().
> > For example, in init() you can use a context attribute ( TagPoolManager ),
> > if not set you'll create it and init, if it's set you just use it. 
> > 
> > > Am I off base, with my general strategy?
> > 
> > No, it is ok.
> >  
> > > Also, regarding 3.x and 4.x, I'd like to keep it usable / adaptable
> > > to all.  We're currently using 3, but will eventually migrate to 4.
> > 
> > 4.x also have a mechanism to notify you about events - either a 2.3 filter
> > or use the internal Listener interfaces, and most decent servlet
> > containers will provide such a mechanism.
> > 
> > As long as you keep a simple interface to your tag pool, it should be easy
> > to write the container-specific adapter that will plug it in.
> > 
> > 
> > Costin
> > 
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> > 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 


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

BugZilla flood

[Ignacio J. Ortega]

Hola a todos:

As all of you know i'm shaking bugs another a bit :)

Mostly acting as dispatcher, I'm doing a brief review of all outstanding
bugs this weekend, i will try to classify them after reading assiging to
the appropiatted component owner ( thanks gos we have bugzilla :) or
fixing if i can along the way..

I did think a bit about to change bugzilla by sql brute force and
alleviate this flood for all of you . 

Well, shaking the bugs in the list it's no bad at all, Some of them are
orfaned by BugRat ( if you meet a. nonymous please let me know :) and
it's good if somebody adopt it ...

If anybody complaints i can change all outstanding bugs assigned to
[EMAIL PROTECTED] ( and hence mail flood ) to me or other
freely .

But if nobody complaints i will continue doing it the actual way.. thus
there 112 more bugs to chage : be ready..

Any comments?

Saludos ,
Ignacio J. Ortega

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

RE: where to plug-in startup/shutdown knowledge for internal tomcat components

[Casey Lucas]

Costin.

Thanks for the help and sorry for all the questions.  I wasn't familiar
with tomcat hooks and didn't understand the JspInterceptor.  But that
was then...  

Now, I'm testing the pooling stuff out.  I've got a
TagPoolManagerInterceptor that listens to contextInit, etc.  But my
problem is that the static TagPoolManager reference that I initialize
in contextInit always ends up null when the jsp runs.  I put a print statement
in the static initializer of TagPoolManager and I can see that it is
being called once when tomcat starts up (and the various contexts are
loaded) and a second time when the jsp is run.  I assume that there's
some class loader stuff going on that I don't understand.

I looked at JspFactory because I'm using the same set/getDefault idiom.
It some how keeps its static reference that is initilized in contextInit.
My code seems to be just like JspFactory, yet my static gets reinitialized
to null.

Any suggestions?

-Casey

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 09, 2001 2:29 PM
> To: [EMAIL PROTECTED]
> Subject: RE: where to plug-in startup/shutdown knowledge for internal
> tomcat components
> 
> 
> On Fri, 9 Mar 2001, Casey Lucas wrote:
> 
> > So, given all that, I need to control lifetime of TagHandlerPoolManager's
> > default instance.  By controlling it, I can have one TagHandlerPoolManager
> > instance per web application and when the web application gets unloaded,
> > all the Tag.release methods can be called.  Aren't the JspServlet and
> > JspInterceptor mechanisms specific to an individual jsp file?  If so,
> > I don't think that's what I need because pooling will be for the entire
> > web application not a specific JSP.
> 
> > I was hoping that when the web application (not individual jsp) is
> > loaded, unloaded, reloaded I could do the TagHandlerPoolManager initialization
> > and cleanup tasks.  Maybe I'm making things too complicated.  Should
> > managing the lifetime of a per-web-application object like
> > TagHandlerPoolManager be simpler?
> 
> And you have 2 solutions:
> 1. Use tomcat hooks. You can let a tomcat module manager the
> TagHandlerPool and you'll get all the notifications you need. 
> Just implement and TagPoolManagerInterceptor module, implement
> the hooks you need ( addContext, contextInit, reload, etc).
> 
> 2. Use some "hacks" in the generated init()/destroy().
> For example, in init() you can use a context attribute ( TagPoolManager ),
> if not set you'll create it and init, if it's set you just use it. 
> 
> > Am I off base, with my general strategy?
> 
> No, it is ok.
>  
> > Also, regarding 3.x and 4.x, I'd like to keep it usable / adaptable
> > to all.  We're currently using 3, but will eventually migrate to 4.
> 
> 4.x also have a mechanism to notify you about events - either a 2.3 filter
> or use the internal Listener interfaces, and most decent servlet
> containers will provide such a mechanism.
> 
> As long as you keep a simple interface to your tag pool, it should be easy
> to write the container-specific adapter that will plug it in.
> 
> 
> Costin
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

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

[Bug 300] New - include files fail to compile if pathname is too long BugRat Report#553

[bugzilla]

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

*** shadow/300  Fri Mar  9 22:05:18 2001
--- shadow/300.tmp.13728Fri Mar  9 22:05:18 2001
***
*** 0 
--- 1,31 
+ ++
+ | include files fail to compile if pathname is too long BugRat Report#553|
+ ++
+ |Bug #: 300 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Jasper  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED]   |
+ |  Reported By: [EMAIL PROTECTED]  |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ Have an app structured as follows (name of app doesn't matter):
+ /index.jsp
+ /includes/reservations_sub_menu_inc.jsp
+ /reservations/help/index.jsp
+ 
+ index.jsp includes reservations_sub_menu_inc.jsp using the following lines:
+ 
+ 
+   
+ 
+ 
+ 
+ When you try to hit the index.jsp page, the include throws an error because the 
+filename is too long.
+ 
+ This seems to happen because when tomcat is compiling included JSPs, it prepends the 
+including file pathname to the class file.  When the illegal class name characters 
+are escaped (./), the filename grows well beyond 256 characters.

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

Re: Implementation in 4.0.b1

[Remy Maucherat]

> Where is the interface document for tomcat object factories?

It's the standard JNDI interface : javax.naming.spi.ObjectFactory

The first parameter you get is a reference instance which contains a set of
parameters. The format of the reference is proprietary (since there is no
standard for this), but very straightforward.

> I would like to have an object factory for JBoss context.

I don't know how feasible that is ...

Remy


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

[Bug 330] New - Internal Servlet Error: Can't happen - classname is null, who added this ? BugRat Report#596

[bugzilla]

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

*** shadow/330  Fri Mar  9 21:54:02 2001
--- shadow/330.tmp.13668Fri Mar  9 21:54:02 2001
***
*** 0 
--- 1,29 
+ ++
+ | Internal Servlet Error: Can't happen - classname is null, who added this ? |
+ ++
+ |Bug #: 330 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Servlet |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]  |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ Internal Servlet Error:
+ java.lang.IllegalStateException: Can't happen - classname is null, who added this ?
+   at org.apache.tomcat.core.ServletWrapper.loadServlet(ServletWrapper.java:261)
+   at org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:289)
+   at org.apache.tomcat.core.Handler.service(Handler.java:254)
+   at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
+   at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049)
+   at 
+org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:775)
+   at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
+   at 
+org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210)
+   at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java, 
+Compiled Code)
+   at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, 
+Compiled Code)
+   at java.lang.Thread.run(Thread.java, Compiled Code)

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

[Bug 322] New - jsp:getProperty does not work on lUzzz field (lowercase-UPPERCASE) eg pNBR BugRat Report#585

[bugzilla]

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

*** shadow/322  Fri Mar  9 21:48:40 2001
--- shadow/322.tmp.13657Fri Mar  9 21:48:41 2001
***
*** 0 
--- 1,32 
+ ++
+ | jsp:getProperty does not work on lUzzz field (lowercase-UPPERCASE) eg pNBR |
+ ++
+ |Bug #: 322 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Jasper  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED]   |
+ |  Reported By: [EMAIL PROTECTED]  |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ Problem
+ In Tomcat 3.2.1
+  on a field with first letter lowercase 
+and second letter Uppercase generate error when trying to compile the JSP generated 
+JAVA code.
+ What even is more strange is that if I comment the line, still it does not compile.
+ If I remove the line then it copile (ouf!)
+ 
+ Solution
+ Use <%= bean.getLUxxx() %> instead.
+ 
+ Remark
+ I should have looked in the code myself.  Blame on me.
+ 
+ Vincent.
+ 
+ --- Additional Comments From [EMAIL PROTECTED]  2001-03-09 21:48 ---
+ Please provide a test case..

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

[Bug 316] New - AdaptiveClassLoader leaks file descriptors BugRat Report#575

[bugzilla]

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

*** shadow/316  Fri Mar  9 21:32:06 2001
--- shadow/316.tmp.13617Fri Mar  9 21:32:07 2001
***
*** 0 
--- 1,52 
+ ++
+ | AdaptiveClassLoader leaks file descriptors BugRat Report#575   |
+ ++
+ |Bug #: 316 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Servlet |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]|
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ Under JDK 1.1.8, the AdaptiveClassLoader leaks file 
+ descriptors from the getResource method.  This gets invoked
+ ( among other times ) every time Beans.instantiate is called
+ with the servlet classloader instead of null ( it tries to
+ find a serialized bean before creating a default instance ).
+ The ZipFile object used to look in jars found in the 
+ repository list is never explicitly closed ( and the finalize
+ method doesn't seem to do it either ).  The solution is
+ to close the ZipFile in a finally block.  Each time this 
+ method runs and searches a zip file ( or jar ), it will leak
+ one file descriptor for each file it processes ( we have 10
+ jars in our WEB-INF/lib so that's 10 file descriptors for 
+ each hit to a page with one jsp:useBean ).  A patch follows:
+ 
+ --- jakarta-tomcat-3.2.orig/src/org/apache/tomcat/loader/AdaptiveClassLoader.java
+   Wed Nov 29 20:47:52 2000
+ +++ jakarta-tomcat-3.2/src/org/apache/tomcat/loader/AdaptiveClassLoader.javaTue 
+Dec 12 13:47:05 2000
+ @@ -804,8 +804,9 @@
+  // a jar:-URL *could* change even between minor releases, but
+  // didn't between JVM's 1.1.6 and 1.3beta. Tested on JVM's from
+  // IBM, Blackdown, Microsoft, Sun @ Windows and Sun @ Solaris
+ +ZipFile zf = null;
+  try {
+ -ZipFile zf = new ZipFile(file.getAbsolutePath());
+ +zf = new ZipFile(file.getAbsolutePath());
+  ZipEntry ze = zf.getEntry(name);
+  
+  if (ze != null) {
+ @@ -819,6 +820,8 @@
+  } catch (IOException ioe) {
+  ioe.printStackTrace();
+  return null;
+ +} finally {
+ +if ( zf != null ) try { zf.close(); } catch ( IOException e ) { 
+} 
+  }
+  }   
+  }

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

[Bug 319] New - Tomcat does not launch with given Unix script files BugRat Report#581

[bugzilla]

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

*** shadow/319  Fri Mar  9 21:41:16 2001
--- shadow/319.tmp.13635Fri Mar  9 21:41:16 2001
***
*** 0 
--- 1,31 
+ ++
+ | Tomcat does not launch with given Unix script files BugRat Report#581  |
+ ++
+ |Bug #: 319 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Config  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]  |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ When launching Tomcat using ./startup.sh or ./tomcat.sh, the background process 
+never runs because it complains of invalid parameters being passed on the command 
+line.
+ 
+ Perform all necessary steps on Compaq Tru64 v4.0f and simply type in (from 
+$TOMCAT_HOME):
+ 
+ ./bin/startup.sh
+ 
+ To fix you must edit the tomcat.sh file (located in $TOMCAT_HOME/bin) and remove the 
+double quotes (") around each and EVERY instance of $@.  So instead of seeing a line 
+as the following:
+ 
+ $JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME}  org.apache.tomcat.startup.Tomcat 
+"$@" &
+ 
+ You should have:
+ 
+ $JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME}  org.apache.tomcat.startup.Tomcat 
+$@ &
+ 
+ The reason for this is that somehow an empty parameter is being passed to Tomcat and 
+it is continually complaining an invalid parameter was sent and subsequently displays 
+the usage info.

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

RE: [Bug 286] New - Tomcat mod_jk.so refuses to load with Apache 1.3.14 undefined symbol BugRat Report#532

[Shinta Tjio]

I had the same problem earlier too. 

You just need to edit the build-unix.sh and add -DSOLARIS
to the APXS call. My apxs doesn't have that by default.

hope this helps
shinta

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 09, 2001 11:22 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [Bug 286] New - Tomcat mod_jk.so refuses to load with Apache
> 1.3.14 undefined symbol BugRat Report#532
> 
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=286
> 
> *** shadow/286Fri Mar  9 21:21:33 2001
> --- shadow/286.tmp.13587  Fri Mar  9 21:21:33 2001
> ***
> *** 0 
> --- 1,26 
> + 
> +=
> ===+
> + | Tomcat mod_jk.so refuses to load with Apache 1.3.14 undefined 
> symbol BugRa |
> + 
> +-
> ---+
> + |Bug #: 286 Product: Tomcat 3   
>  |
> + |   Status: UNCONFIRMED Version: 3.2.1 
> Final |
> + |   Resolution:Platform: All
>  |
> + | Severity: Normal   OS/Version: All
>  |
> + | Priority: High  Component: Connectors 
>  |
> + 
> +-
> ---+
> + |  Assigned To: [EMAIL PROTECTED]
>  |
> + |  Reported By: [EMAIL PROTECTED]   
>  |
> + |  CC list: Cc: 
>  |
> + 
> +-
> ---+
> + |  URL: 
>  |
> + 
> +=
> ===+
> + |  DESCRIPTION  
>  |
> + I build Apache 1.3.14 from scratch on Solaris 2.8 using GCC
> + 2.95.2.  I also built the mod_jk.so from scratch on the 
> + same machine.  Apache 1.3.14 refuses to load the 
> + mod_jk.so module because of an undefined symbol fdatasync.
> + I found this in librt.so and libposix4.so on the machine.
> + 
> + The offending call is in jk_util.c:112
> + 
> + 
> + 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

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

[Bug 286] New - Tomcat mod_jk.so refuses to load with Apache 1.3.14 undefined symbol BugRat Report#532

[bugzilla]

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

*** shadow/286  Fri Mar  9 21:21:33 2001
--- shadow/286.tmp.13587Fri Mar  9 21:21:33 2001
***
*** 0 
--- 1,26 
+ ++
+ | Tomcat mod_jk.so refuses to load with Apache 1.3.14 undefined symbol BugRa |
+ ++
+ |Bug #: 286 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Connectors  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]|
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ I build Apache 1.3.14 from scratch on Solaris 2.8 using GCC
+ 2.95.2.  I also built the mod_jk.so from scratch on the 
+ same machine.  Apache 1.3.14 refuses to load the 
+ mod_jk.so module because of an undefined symbol fdatasync.
+ I found this in librt.so and libposix4.so on the machine.
+ 
+ The offending call is in jk_util.c:112
+ 
+ 
+ 

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

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

[nacho]

nacho   01/03/09 21:16:51

  Modified:src/share/org/apache/jasper/compiler Tag: tomcat_32
IncludeGenerator.java
  Log:
  Fix for Bug#284
  
   error message is not descriptive BugRat Report#529
  
  Submitted by : [EMAIL PROTECTED] (Arun Katkere)
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.4.2.3   +19 -19
jakarta-tomcat/src/share/org/apache/jasper/compiler/IncludeGenerator.java
  
  Index: IncludeGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/IncludeGenerator.java,v
  retrieving revision 1.4.2.2
  retrieving revision 1.4.2.3
  diff -u -r1.4.2.2 -r1.4.2.3
  --- IncludeGenerator.java 2000/12/19 23:44:40 1.4.2.2
  +++ IncludeGenerator.java 2001/03/10 05:16:50 1.4.2.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/IncludeGenerator.java,v 
1.4.2.2 2000/12/19 23:44:40 pierred Exp $
  - * $Revision: 1.4.2.2 $
  - * $Date: 2000/12/19 23:44:40 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/IncludeGenerator.java,v 
1.4.2.3 2001/03/10 05:16:50 nacho Exp $
  + * $Revision: 1.4.2.3 $
  + * $Date: 2001/03/10 05:16:50 $
*
* 
* 
  @@ -88,29 +88,29 @@
   boolean isExpression = false;
   Hashtable params;
   
  -public IncludeGenerator(Mark start, Hashtable attrs, Hashtable param) 
  -throws JasperException 
  -{
  - if (attrs.size() != 2)
  - throw new CompileException(start,
  -Constants.getString("jsp.error.include.tag"));
  -
  +public IncludeGenerator(Mark start,  Hashtable attrs, Hashtable param )
  +throws JasperException{
   page = (String) attrs.get("page");
  -if (page == null)
  - throw new CompileException(start,
  -Constants.getString("jsp.error.include.tag"));
  -
  +if (page == null){
  + throw new CompileException(start,
  +Constants.getString("jsp.error.include.tag"));
  +}
   String flush = (String) attrs.get("flush");
  -if (flush == null)
  +if (flush == null){
   throw new CompileException(start,
   
Constants.getString("jsp.error.include.noflush"));
  -
  -if (!flush.equals("true"))
  +}
  +if (!flush.equals("true")){
   throw new CompileException(start,
   
Constants.getString("jsp.error.include.badflush"));
  + }
  + if (attrs.size() != 2){
  + throw new CompileException(start,
  +Constants.getString("jsp.error.include.tag"));
  +}
   
  - this.params = param;
  - isExpression = JspUtil.isExpression (page);
  + this.params = param;
  + isExpression = JspUtil.isExpression (page);
   }
   
   public void generate(ServletWriter writer, Class phase) {
  
  
  

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

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

[nacho]

nacho   01/03/09 21:13:41

  Modified:src/share/org/apache/jasper/compiler IncludeGenerator.java
  Log:
  Fix for Bug#284
  
   error message is not descriptive BugRat Report#529
  
  Submitted by : [EMAIL PROTECTED] (Arun Katkere)
  
  Revision  ChangesPath
  1.7   +16 -16
jakarta-tomcat/src/share/org/apache/jasper/compiler/IncludeGenerator.java
  
  Index: IncludeGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/IncludeGenerator.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- IncludeGenerator.java 2001/01/07 19:24:17 1.6
  +++ IncludeGenerator.java 2001/03/10 05:13:40 1.7
  @@ -84,29 +84,29 @@
   boolean isExpression = false;
   Hashtable params;
   
  -public IncludeGenerator(Mark start, Hashtable attrs, Hashtable param) 
  -throws JasperException 
  -{
  - if (attrs.size() != 2)
  - throw new CompileException(start,
  -Constants.getString("jsp.error.include.tag"));
  -
  +public IncludeGenerator(Mark start,  Hashtable attrs, Hashtable param )
  +throws JasperException{
   page = (String) attrs.get("page");
  -if (page == null)
  - throw new CompileException(start,
  -Constants.getString("jsp.error.include.tag"));
  -
  +if (page == null){
  + throw new CompileException(start,
  +Constants.getString("jsp.error.include.tag"));
  +}
   String flush = (String) attrs.get("flush");
  -if (flush == null)
  +if (flush == null){
   throw new CompileException(start,
   
Constants.getString("jsp.error.include.noflush"));
  -
  -if (!flush.equals("true"))
  +}
  +if (!flush.equals("true")){
   throw new CompileException(start,
   
Constants.getString("jsp.error.include.badflush"));
  + }
  + if (attrs.size() != 2){
  + throw new CompileException(start,
  +Constants.getString("jsp.error.include.tag"));
  +}
   
  - this.params = param;
  - isExpression = JspUtil.isExpression (page);
  + this.params = param;
  + isExpression = JspUtil.isExpression (page);
   }
   
   public void generate(ServletWriter writer, Class phase) {
  
  
  

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

Re: Implementation in 4.0.b1

[Tim Tye]

Where is the interface document for tomcat object factories?
I would like to have an object factory for JBoss context.

- Original Message -
From: Remy Maucherat <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 09, 2001 7:13 PM
Subject: Re:   Implementation in 4.0.b1


> > I am trying to obtain a remote reference to an EJB in another machine.
> > I have set the ejb-ref in web.xml as follows:
> > 
> > Sample bean generated by coolgen placed here for ease
of
> >  early testing
> > ejb/S_STRESS_32K
> > Session
> > cool.models.coop07.java.S_STRESS_32KpsHome
> > cool.models.coop07.java.S_STRESS_32Kps
> > jndi:/ttt1.ca.com:1099/S_STRESS_32Kps
> > 
> > However, when I do ctx.lookup("java:/comp/ejb/S_STRESS_32K") I get a
null
> > reference instead of the necessary remote reference to the home
interface.
> > Is ejb-link implemented and documented?
> > Which code is involved in ejb-link lookup?
> > Is this fixed in the latest 4.0?
>
> Tomcat 4 will parse the web.xml file and bind references to the specified
> resources in the naming environment. To be able to resolve those
references,
> TC needs an appropriate object factory. If no object factory is available,
> null is returned when you do a lookup.
>
> Right now, there are two factories :
> - one for getting Tyrex managed data sources
> - one for getting Tyrex UserTransactions
> You can easily add additional factories for additional resource types
(EJBs,
> JMS resources ...). Contributed object factories (provided they are
generic
> enough) could be added to the repository.
>
> Remy
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>




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

[Bug 276] New - JNI problem: bufferedreader.read fails in Tomcat/IIS/JNI set-up BugRat Report#518

[bugzilla]

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

*** shadow/276  Fri Mar  9 19:13:52 2001
--- shadow/276.tmp.11958Fri Mar  9 19:13:52 2001
***
*** 0 
--- 1,256 
+ ++
+ | JNI problem: bufferedreader.read fails in Tomcat/IIS/JNI set-up BugRat Rep |
+ ++
+ |Bug #: 276 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Connectors  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]   |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ There seems to be a bug that interferes with servlet-to-servlet communication, when 
+Tomcat is running under IIS (Win 2000 Advanced), using JNI.  
+ 
+ I'm attaching source for a pair of simple servlets that demonstrate the bug.  The 
+first servlet (BadClient.java) opens a URLConnection to the second servlet 
+(BadServer.java).   BadClient uses the URLConnection to open an output stream, then 
+uses the output stream to print some text, which will be read by BadServer.  
+ 
+ The BadServer servlet then calls request.getReader to get a reader object, to read 
+the text that was sent by BadClient. 
+ 
+ This all works fine under Tomcat 3.2, when Tomcat is running stand-alone. But if 
+Tomcat 3.2 is running inside IIS, using the JNI connector, there's a problem.   
+BadServer is never able to read any of the text sent by BadClient.   The whole 
+process just seems to hang for exactly 1 minute... apparently, something times out 
+after 1 minute, and BadClient stops trying to read the text.  Under JNI, the read 
+call returns -1.  
+ 
+ (Other servlets work fine under JNI.) 
+ 
+ The two servlets go on and perform other tasks after that, with BadServer reading a 
+local .GIF file, then sending it back to BadClient, which send the image back to the 
+browser.  That part works; it's the first part that fails, as described above. 
+ 
+ I've tried various configurations of Tomcat -- using the JVM.DLL for classic, or 
+hotspot, or server (Java 1.3).   No difference.  I've looked in the various log files 
+for exceptions, and I don't see any.
+ 
+ Here's the source for both servlets (around 100 lines each). If the formatting is 
+messed up too badly, please let me know and I'll email a copy to anyone who wants to 
+investigate the problem. 
+ 
+ // Here is all of BadClient.java (118 lines): 
+ // BadClient.java -- demonstrates behavior that works fine in Tomcat 3.2
+ // but does not work when Tomcat runs under IIS using JNI
+ // Used in conjunction with BadServer.java
+ import javax.servlet.*;
+ import javax.servlet.http.*;
+ import java.io.*;
+ import java.util.*;
+ import java.net.URLConnection;
+ import java.net.URL;
+ 
+ public class BadClient extends HttpServlet {
+ 
+   // TODO:  Either modify the following string literal to represent
+   // the URL of the BadServer servlet, or specify that URL
+   // using an init parameter.
+   String m_url = "http://localhost:8100/test/servlet/BadServer";
+ 
+   public void init(ServletConfig config) throws ServletException {
+   super.init(config);
+   try {
+   String str = getInitParameter("url");   //URL to 2nd 
+servlet
+   if (str != null) {
+   m_url = str;
+   }
+   }
+   catch (Exception e) {
+   e.printStackTrace();
+   }
+   }
+ 
+   public void service(HttpServletRequest request, HttpServletResponse res)
+   throws ServletException, IOException
+   {
+   // Open an URLConnection to the BadServer servlet.
+   URL url = new URL(m_url);
+   URLConnection urlConnection = url.openConnection();
+   urlConnection.setDoOutput(true);
+   urlConnection.setUseCaches(false);
+   urlConnection.setRequestProperty("Connection", "close");
+   OutputStream os = null;
+   try {
+   os = u

[Bug 274] New - request.getUserPrincipal() doesn't work when user is authenticated with a X509 client certificate. BugRat Report#516

[bugzilla]

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

*** shadow/274  Fri Mar  9 19:12:21 2001
--- shadow/274.tmp.11949Fri Mar  9 19:12:21 2001
***
*** 0 
--- 1,17 
+ ++
+ | request.getUserPrincipal() doesn't work when user is authenticated with a  |
+ ++
+ |Bug #: 274 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Servlet |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED] |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ Shouldn't this method return the subject DN of the clients X509 certificate?

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

cvs commit: jakarta-tomcat/src/examples/jsp/snp snoop.html

[nacho]

nacho   01/03/09 19:00:56

  Modified:src/examples/jsp/cal calendar.html
   src/examples/jsp/colors clr.html
   src/examples/jsp/checkbox cresult.html
   src/examples/jsp/sessions crt.html
   src/examples/jsp/dates date.html
   src/examples/jsp/error er.html
   src/examples/jsp/simpletag foo.html
   src/examples/jsp/forward fwd.html
   src/examples/jsp/include inc.html
   src/examples/jsp/jsptoserv jts.html
   src/examples/jsp/plugin plugin.html
   src/examples/jsp/security security.html
   src/examples/jsp/snp snoop.html
  Log:
  Fix for 
  
  JSP Examples fail to show source. BugRat Report#494
  
  Submitted by : [EMAIL PROTECTED] (Hans Schmid)
  
  Revision  ChangesPath
  1.3   +2 -2  jakarta-tomcat/src/examples/jsp/cal/calendar.html
  
  Index: calendar.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/examples/jsp/cal/calendar.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- calendar.html 1999/10/20 20:39:18 1.2
  +++ calendar.html 2001/03/10 03:00:54 1.3
  @@ -13,9 +13,9 @@
   
   
Source Code for Calendar Example. 
  -cal1.jsp
  +cal1.jsp
  
  -cal2.jsp
  +cal2.jsp
  
   
   
  
  
  
  1.3   +1 -1  jakarta-tomcat/src/examples/jsp/colors/clr.html
  
  Index: clr.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/examples/jsp/colors/clr.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- clr.html  1999/10/20 23:17:15 1.2
  +++ clr.html  2001/03/10 03:00:54 1.3
  @@ -12,7 +12,7 @@
   
   
   
  -Source Code for Color Example
  +Source Code for Color 
Example
  
   
   Property Sheet for ColorGameBean
  
  
  
  1.3   +1 -1  jakarta-tomcat/src/examples/jsp/checkbox/cresult.html
  
  Index: cresult.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/examples/jsp/checkbox/cresult.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- cresult.html  1999/10/20 20:39:52 1.2
  +++ cresult.html  2001/03/10 03:00:54 1.3
  @@ -12,7 +12,7 @@
   
   
   
  -Source Code for Checkbox Example
  +Source Code 
for Checkbox Example
  
   
   Property Sheet for CheckTest
  
  
  
  1.3   +1 -1  jakarta-tomcat/src/examples/jsp/sessions/crt.html
  
  Index: crt.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/examples/jsp/sessions/crt.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- crt.html  1999/10/20 23:20:11 1.2
  +++ crt.html  2001/03/10 03:00:54 1.3
  @@ -12,7 +12,7 @@
   
   
   
  -Source Code for Cart Example
  +Source Code for Cart 
Example
  
   
   Property Sheet for DummyCart
  
  
  
  1.3   +1 -1  jakarta-tomcat/src/examples/jsp/dates/date.html
  
  Index: date.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/examples/jsp/dates/date.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- date.html 1999/10/20 23:17:46 1.2
  +++ date.html 2001/03/10 03:00:54 1.3
  @@ -12,7 +12,7 @@
   
   
   
  -Source Code for Date Example
  +Source Code for Date 
Example
  
   
   
  
  
  
  1.3   +1 -1  jakarta-tomcat/src/examples/jsp/error/er.html
  
  Index: er.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/examples/jsp/error/er.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- er.html   1999/10/20 23:18:12 1.2
  +++ er.html   2001/03/10 03:00:55 1.3
  @@ -12,7 +12,7 @@
   
   
   
  -Source Code for Error Example
  +Source Code for Error 
Example
  
   
   
  
  
  
  1.3   +1 -1  jakarta-tomcat/src/examples/jsp/simpletag/foo.html
  
  Index: foo.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/examples/jsp/simpletag/foo.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- foo.html  1999/11/08 03:13:21 1.2
  +++ foo.html  2001/03/10 03:00:55 1.3
  @@ -11,7 +11,7 @@
   
   
   
  -Source Code for the Simple Tag Example
  +Source Code for the 
Simple Tag Example
  
   
   
  
  
  
  1.3   +1 -1  jakarta-tomcat/src/examples/jsp/forward/fwd.html
  
  Index: fwd.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/examples/jsp/forward/fwd.html,v
  retrieving revision 1.2
  retrievin

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

[nacho]

nacho   01/03/09 17:37:36

  Modified:src/share/org/apache/jasper/compiler Tag: tomcat_32
PluginGenerator.java
  Log:
  Fix for 
  
  type field in jsp:plugin not correctly expanded BugRat Report#467
  
  Submitted by [EMAIL PROTECTED] (Mark Kettner)
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.7.2.2   +6 -6  
jakarta-tomcat/src/share/org/apache/jasper/compiler/PluginGenerator.java
  
  Index: PluginGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/PluginGenerator.java,v
  retrieving revision 1.7.2.1
  retrieving revision 1.7.2.2
  diff -u -r1.7.2.1 -r1.7.2.2
  --- PluginGenerator.java  2000/09/29 17:23:07 1.7.2.1
  +++ PluginGenerator.java  2001/03/10 01:37:35 1.7.2.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/PluginGenerator.java,v 
1.7.2.1 2000/09/29 17:23:07 pierred Exp $
  - * $Revision: 1.7.2.1 $
  - * $Date: 2000/09/29 17:23:07 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/PluginGenerator.java,v 
1.7.2.2 2001/03/10 01:37:35 nacho Exp $
  + * $Revision: 1.7.2.2 $
  + * $Date: 2001/03/10 01:37:35 $
*
* 
* 
  @@ -273,11 +273,11 @@
writer.indent ();
writer.print ("out.print (\"

[Bug 267] New - session.invalidate() method and response.sendRedirect BugRat Report#482

[bugzilla]

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

*** shadow/267  Fri Mar  9 17:27:45 2001
--- shadow/267.tmp.11100Fri Mar  9 17:27:45 2001
***
*** 0 
--- 1,77 
+ ++
+ | session.invalidate() method and response.sendRedirect BugRat Report#482|
+ ++
+ |Bug #: 267 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.1.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Servlet |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]   |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ Here is the problem I have encunter using tomcat3.1.
+ 
+ When I end the transaction with the session.invalidate() method, I call
+ the response.sendRedirect in order to send a message to the user. If I
+ try to come back into the session with the browser, I have got the same
+ message, so the same jsp file, than the one I got while ending the
+ transaction. I use the same method, response.sendRedirect, with another
+ jsp file.
+ 
+ If I use the same .class files under tomcat3.0, evething works well,
+ that is, I have got the good jsp page.
+ 
+ Here is my servlet. Notice the two differents jsp pages end.jsp and
+ out.jsp.
+ 
+ public void doPost(HttpServletRequest request, HttpServletResponse
+ response)  throws IOException
+ {
+ doGet(request, response);
+ }
+ 
+ public void doGet(HttpServletRequest request, HttpServletResponse
+ response)  throws IOException
+ {
+ HttpSession session=null;
+ TrecObject TxTrec=null;
+ try {
+ session=request.getSession(false);
+ if ( session == null )
+ response.sendRedirect("/examples/jsp/trec/out.jsp");
+ 
+ // get the TrecObject from the session
+ TxTrec = (TrecObject) session.getAttribute("TrecObject");
+ if (TxTrec == null ) {
+ response.sendRedirect("/examples/jsp/trec/out.jsp");
+ }
+ 
+ // previous page
+ if ( request.getParameterValues("prev") != null ) {
+ TxTrec.TrecTransaction.pageprecedente();
+ 
+ response.sendRedirect(response.encodeRedirectURL("/examples/jsp/trec/TREC.jsp"));
+ // next page
+ } else if ( request.getParameterValues("next") != null ) {
+ TxTrec.TrecTransaction.pagesuivante();
+ 
+ response.sendRedirect(response.encodeRedirectURL("/examples/jsp/trec/TREC.jsp"));
+ // End of the transaction
+ } else if ( request.getParameterValues("end") != null ) {
+ TxDisconnect(TxTrec);
+ session.invalidate();
+ response.sendRedirect("/examples/jsp/trec/end.jsp");
+ }
+ 
+ 
+ Also, the method request.getSession(false), should, according the the
+ api documentation, return null if it is called after a call to the
+ session.invalidate() has been made. I have experienced a creation of a
+ new session like if I had used true instead of false for the parameters.
+ Is somethig wrong with that?
+ 

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

cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime BodyContentImpl.java

[nacho]

nacho   01/03/09 17:20:24

  Modified:src/share/org/apache/jasper/runtime BodyContentImpl.java
  Log:
One last performance update to the previous commit.
  
Double the buffer size on a realloc instead of incrementing the length.
  
Submitted by:   Andrew Gilbert [[EMAIL PROTECTED]]
  
  Revision  ChangesPath
  1.8   +3 -3  
jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java
  
  Index: BodyContentImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- BodyContentImpl.java  2001/03/01 00:59:54 1.7
  +++ BodyContentImpl.java  2001/03/10 01:20:23 1.8
  @@ -88,7 +88,7 @@
   super(writer);
cb = new char[bufferSize];
nextChar = 0;
  -}
  +  }
   
   /**
* Write a single character.
  @@ -105,7 +105,7 @@
   
   private void reAllocBuff (int len) {
   //Need to re-allocate the buffer since it is to be
  - //unbounded according to the updated spec..
  + //unbounded according to the updated spec..
   
   char[] tmp = null;
   
  @@ -113,7 +113,7 @@
   
if (len <= Constants.DEFAULT_BUFFER_SIZE) {
tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
  - bufferSize += Constants.DEFAULT_BUFFER_SIZE;
  + bufferSize = bufferSize * 2;
} else {
tmp = new char [bufferSize + len];
bufferSize += len;
  
  
  

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

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

[nacho]

nacho   01/03/09 17:18:01

  Modified:src/share/org/apache/jasper/compiler PluginGenerator.java
  Log:
  Fix for 
  
  type field in jsp:plugin not correctly expanded BugRat Report#467
  
  Submitted by [EMAIL PROTECTED] (Mark Kettner)
  
  Revision  ChangesPath
  1.10  +3 -3  
jakarta-tomcat/src/share/org/apache/jasper/compiler/PluginGenerator.java
  
  Index: PluginGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/PluginGenerator.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- PluginGenerator.java  2001/01/07 19:24:20 1.9
  +++ PluginGenerator.java  2001/03/10 01:18:01 1.10
  @@ -164,11 +164,11 @@
writer.print ("out.println (\"

Re: Implementation in 4.0.b1

[Remy Maucherat]

> I am trying to obtain a remote reference to an EJB in another machine.
> I have set the ejb-ref in web.xml as follows:
> 
> Sample bean generated by coolgen placed here for ease of
>  early testing
> ejb/S_STRESS_32K
> Session
> cool.models.coop07.java.S_STRESS_32KpsHome
> cool.models.coop07.java.S_STRESS_32Kps
> jndi:/ttt1.ca.com:1099/S_STRESS_32Kps
> 
> However, when I do ctx.lookup("java:/comp/ejb/S_STRESS_32K") I get a null
> reference instead of the necessary remote reference to the home interface.
> Is ejb-link implemented and documented?
> Which code is involved in ejb-link lookup?
> Is this fixed in the latest 4.0?

Tomcat 4 will parse the web.xml file and bind references to the specified
resources in the naming environment. To be able to resolve those references,
TC needs an appropriate object factory. If no object factory is available,
null is returned when you do a lookup.

Right now, there are two factories :
- one for getting Tyrex managed data sources
- one for getting Tyrex UserTransactions
You can easily add additional factories for additional resource types (EJBs,
JMS resources ...). Contributed object factories (provided they are generic
enough) could be added to the repository.

Remy


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

[Bug 262] New - Method overloading problem using beans BugRat Report#466

[bugzilla]

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

*** shadow/262  Fri Mar  9 17:10:35 2001
--- shadow/262.tmp.11065Fri Mar  9 17:10:35 2001
***
*** 0 
--- 1,17 
+ ++
+ | Method overloading problem using beans BugRat Report#466   |
+ ++
+ |Bug #: 262 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Jasper  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED]   |
+ |  Reported By: [EMAIL PROTECTED] |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ For listboxes that have multiple selections the use of setproperty ... property="*" 
+does not call the method with the array signature. (This bug doesnt happen on 1.2.2 
+jvms).

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

[Bug 110] New - JCE 1.2.1 support is not handled correctly BugRat Report#116

[bugzilla]

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

*** shadow/110  Fri Mar  9 17:04:09 2001
--- shadow/110.tmp.11036Fri Mar  9 17:04:09 2001
***
*** 0 
--- 1,17 
+ ++
+ | JCE 1.2.1 support is not handled correctly BugRat Report#116   |
+ ++
+ |Bug #: 110 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.1.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Unknown |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]  |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ I am running the latest and greatest Java/Tomcat/JCE on a Solaris 2.7 intel box. I 
+have loaded all the OS patches per the sun and java sites. I have a couple classes 
+which implement the Blowfish encryption algorithm using the JCE. These work 
+standalone when compiled using javac and executed via java command line. Each works 
+if the JCE is statically configured via the java.security file or dynamically via the 
+addProvider() call. When I call these classes from a jsp using Tomcat I get an error 
+"Cannot set up certs for trusted CAs" I have tried using various JVMs by setting the 
+jvm.cfg file (Hotspot, et. al) Standalone things work fine, jsp compilation/execution 
+from Tomcat errors. Any help is appreciated.

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

[Bug 82] Changed - Jasper not affected by mod_rewrite BugRat Report#49

[bugzilla]

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

*** shadow/82   Sat Feb  3 11:09:51 2001
--- shadow/82.tmp.11030 Fri Mar  9 17:03:14 2001
***
*** 2,13 
  | Jasper not affected by mod_rewrite BugRat Report#49|
  ++
  |Bug #: 82  Product: Tomcat 3|
! |   Status: NEW Version: 3.1 Final   |
  |   Resolution:Platform: All |
  | Severity: Normal   OS/Version: All |
! | Priority: High  Component: Jasper  |
  ++
! |  Assigned To: [EMAIL PROTECTED]  |
  |  Reported By: [EMAIL PROTECTED]  |
  |  CC list: Cc:  |
  ++
--- 2,13 
  | Jasper not affected by mod_rewrite BugRat Report#49|
  ++
  |Bug #: 82  Product: Tomcat 3|
! |   Status: UNCONFIRMED Version: 3.1 Final   |
  |   Resolution:Platform: All |
  | Severity: Normal   OS/Version: All |
! | Priority: High  Component: Connectors  |
  ++
! |  Assigned To: [EMAIL PROTECTED] |
  |  Reported By: [EMAIL PROTECTED]  |
  |  CC list: Cc:  |
  ++

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

[Bug 246] Changed - MIME-TYPE handling BugRat Report#398

[bugzilla]

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

*** shadow/246  Fri Mar  9 15:06:46 2001
--- shadow/246.tmp.11043Fri Mar  9 17:04:41 2001
***
*** 2,13 
  | MIME-TYPE handling BugRat Report#398   |
  ++
  |Bug #: 246 Product: Tomcat 3|
! |   Status: NEW Version: 3.1.1 Final |
  |   Resolution:Platform: All |
  | Severity: Normal   OS/Version: All |
  | Priority: High  Component: Servlet |
  ++
! |  Assigned To: [EMAIL PROTECTED]|
  |  Reported By: [EMAIL PROTECTED]  |
  |  CC list: Cc:  |
  ++
--- 2,13 
  | MIME-TYPE handling BugRat Report#398   |
  ++
  |Bug #: 246 Product: Tomcat 3|
! |   Status: UNCONFIRMED Version: 3.1.1 Final |
  |   Resolution:Platform: All |
  | Severity: Normal   OS/Version: All |
  | Priority: High  Component: Servlet |
  ++
! |  Assigned To: [EMAIL PROTECTED] |
  |  Reported By: [EMAIL PROTECTED]  |
  |  CC list: Cc:  |
  ++

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

RE: 3.3 build

[Ignacio J. Ortega]

> Let me know what you think - I would be very happy to hear 
> you strongly
> disagree with mixing the source and build result, but if no 

I strongly %*+-=&/) but not disagree..

> commiter -1
> it I guess we should do it.
> 

I dont like it but i cant -1 it, everybody seems very conviced that this
is the right ( a least the less error prone for newbies ) way to build
things it's a lost war so ...

+0 ( with a pain on the heart :) 


Saludos ,
Ignacio J. Ortega


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

cvs commit: jakarta-tomcat/src/examples/WEB-INF/classes LocalStrings_es.properties

[nacho]

nacho   01/03/09 15:55:00

  Modified:src/examples/WEB-INF/classes Tag: tomcat_32
LocalStrings_es.properties
  Log:
  New strings added
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.2.2.1   +6 -1  
jakarta-tomcat/src/examples/WEB-INF/classes/LocalStrings_es.properties
  
  Index: LocalStrings_es.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/examples/WEB-INF/classes/LocalStrings_es.properties,v
  retrieving revision 1.2
  retrieving revision 1.2.2.1
  diff -u -r1.2 -r1.2.2.1
  --- LocalStrings_es.properties2000/05/25 16:29:37 1.2
  +++ LocalStrings_es.properties2001/03/09 23:55:00 1.2.2.1
  @@ -1,4 +1,4 @@
  -# $Id: LocalStrings_es.properties,v 1.2 2000/05/25 16:29:37 nacho Exp $
  +# $Id: LocalStrings_es.properties,v 1.2.2.1 2001/03/09 23:55:00 nacho Exp $
   #
   # Default localized string information
   # Localized para Locale es_ES
  @@ -36,3 +36,8 @@
   sessions.adddata=Añade datos a tu sesion:
   sessions.dataname=Nombre del atributo de sesion:
   sessions.datavalue=Valor del atributo de sesion:
  +sessions.requestedid=Id de sesion pedido:
  +sessions.requestedidvalid=El Id de sesion es valido:
  +sessions.fromcookie=El Id de sesion pedido llega desde una cookie:
  +sessions.fromurl=El Id de sesion pedido llega desde una URL:
  +sessions.isnew=Nueva sesion:
  
  
  

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

cvs commit: jakarta-tomcat/src/examples/WEB-INF/classes LocalStrings_es.properties

[nacho]

nacho   01/03/09 15:53:02

  Modified:src/examples/WEB-INF/classes LocalStrings_es.properties
  Log:
  New strings added
  
  Revision  ChangesPath
  1.3   +6 -1  
jakarta-tomcat/src/examples/WEB-INF/classes/LocalStrings_es.properties
  
  Index: LocalStrings_es.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/examples/WEB-INF/classes/LocalStrings_es.properties,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- LocalStrings_es.properties2000/05/25 16:29:37 1.2
  +++ LocalStrings_es.properties2001/03/09 23:53:02 1.3
  @@ -1,4 +1,4 @@
  -# $Id: LocalStrings_es.properties,v 1.2 2000/05/25 16:29:37 nacho Exp $
  +# $Id: LocalStrings_es.properties,v 1.3 2001/03/09 23:53:02 nacho Exp $
   #
   # Default localized string information
   # Localized para Locale es_ES
  @@ -36,3 +36,8 @@
   sessions.adddata=Añade datos a tu sesion:
   sessions.dataname=Nombre del atributo de sesion:
   sessions.datavalue=Valor del atributo de sesion:
  +sessions.requestedid=Id de sesion pedido:
  +sessions.requestedidvalid=El Id de sesion es valido:
  +sessions.fromcookie=El Id de sesion pedido llega desde una cookie:
  +sessions.fromurl=El Id de sesion pedido llega desde una URL:
  +sessions.isnew=Nueva sesion:
  
  
  

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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java

[costin]

costin  01/03/09 15:47:41

  Modified:src/share/org/apache/tomcat/core BaseInterceptor.java
   src/share/org/apache/tomcat/modules/config
LoaderInterceptor11.java
   src/share/org/apache/tomcat/modules/mappers
ReloadInterceptor.java
   src/share/org/apache/tomcat/modules/session
SimpleSessionStore.java
  Log:
  Fixes in reloading.
  
  - added a comment about "oldLoader" note
  
  - refactored LoaderInterceptor - it no longer depends ( or care ) about
  reloading details
  
  - ReloadIntereptor is taking care of hooking in the class loader, so
  it knows about automatic dependencies.
  
  - if a change is detected, re-do the contextMap ( this fixes 503 when
  the app is reloaded )
  
  Revision  ChangesPath
  1.45  +8 -0  
jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java
  
  Index: BaseInterceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java,v
  retrieving revision 1.44
  retrieving revision 1.45
  diff -u -r1.44 -r1.45
  --- BaseInterceptor.java  2001/03/08 07:23:01 1.44
  +++ BaseInterceptor.java  2001/03/09 23:47:39 1.45
  @@ -443,6 +443,14 @@
   /** Reload notification - called whenever a reload is done.
This can be used to serialize sessions, log the event,
remove any resource that was class-loader dependent.
  +
  + Note. The current implementation uses a note "oldLoader"
  + that will keep a reference to the previous class loader
  + during this hook. It will be set by the module that creates
  + the loaders, and should be destroyed when the hook is done.
  + This can also be implemented using a get/setOldClassLoader
  + in Context, but so far this is used in only 2 modules, adding
  + new API is not needed.
*/
   public void reload( Request req, Context ctx)
throws TomcatException
  
  
  
  1.9   +48 -67
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LoaderInterceptor11.java
  
  Index: LoaderInterceptor11.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LoaderInterceptor11.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- LoaderInterceptor11.java  2001/03/07 23:51:08 1.8
  +++ LoaderInterceptor11.java  2001/03/09 23:47:39 1.9
  @@ -72,8 +72,10 @@
* Set class loader based on WEB-INF/classes, lib.
* Compatible with JDK1.1, but takes advantage of URLClassLoader if
* java2 is detected.
  - * 
*
  + * Note. LoaderInterceptor must be the first in the reload and contextInit
  + * chains.
  + *
* @author [EMAIL PROTECTED]
*/
   public class LoaderInterceptor11 extends BaseInterceptor {
  @@ -95,7 +97,10 @@
   public void setUseNoParent( boolean b ) {
useNoParent=b;
   }
  -
  +
  +/** Add all WEB-INF/classes and WEB-INF/lib to the context
  + *  path
  + */
   public void addContext( ContextManager cm, Context context)
throws TomcatException
   {
  @@ -133,98 +138,74 @@
} catch( MalformedURLException ex ) {
}
}
  -
  - // Add servlet.jar and jasper.jar
   }
  -
  +
  +/** Construct a class loader to be used with the context
  + */
   public void contextInit( Context context)
throws TomcatException
   {
if( debug>0 ) log( "Init context " + context.getPath());
   ContextManager cm = context.getContextManager();
  - URL classP[]=context.getClassPath();
  - if( debug>5 ) {
  - log("  Context classpath URLs:");
  - for (int i = 0; i < classP.length; i++)
  - log("" + classP[i].toString() );
  - }
  -
  - DependManager dm=(DependManager)context.getContainer().
  - getNote("DependManager");
   
  - if( dm==null ) {
  - // No depend manager - that means no ReloadInterceptor.
  - }
  -
  - ClassLoader parent=null;
  - if( useAL && !context.isTrusted() )
  - parent=cm.getParentLoader();
  - else if( useNoParent )
  - parent=null;
  - else
  - parent=this.getClass().getClassLoader();
  -
  - ClassLoader loader=jdk11Compat.newClassLoaderInstance( classP, parent);
  - if( debug > 0 )
  - log("Loader " + loader.getClass().getName() + " " + parent);
  -
  - if( dm != null ) {
  - // If depend manager is present, create a wrapper loader
  - // that will add dependencies for reloading ( using depentManager)
  - loader=new DependClassLoader( dm, loader);
  - }
  - // If another reloading scheme is implemented, you'll
  - // have to plug it in here.
  - 
  + ClassLoader loader=con

RE: FW: problem w/ ajp13 - if Tomcat is shutdown

[Shinta Tjio]

Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown





Hi, Dan,
I may not understand all of the issues here. But I really
don't think we should close all connections when we
detect one ECONNRESET. In my opinion, it is not necessary
to close all connections, since the next ECONNRESET 
will close the proper dead socket, anyway. It's not
needed to add all of those complexity.


In the mean time, I have taken Henri's changes and back
port it to 3.2.1 (because I need it on 3.2.1). Everything
seems to work well. I've tested it in the normal scenarios
(one Apache, one Tomcat) and in the load-balanced scenarios.


In the load-balanced scenarios, when I restart TC worker 1, 
the code properly close the dead sockets and re-establish
new ones to the same worker (TC worker 1). The good 
connections to TC worker 2 are untouched. They stay 
connected.


I did notice something wierd. But this is un-related
to the code edits. This happens with or without Henri's
changes. When I restart TC worker 1, but shut down TC 
worker 2, requests that supposed to go to TC worker 2 
(because they belong to the same session, thus the load
balancer try to foward it to the same TC worker 2) took 
sometime to get forwarded to TC worker 1. This maybe
another one of those "improvements" that can be done
to the load balancer worker.


Anyway, I'm pretty happy with Henri's changes. (Thanks
Henri!). Henri, are you going to check in the changes?


Let me know if I can do something else to help for
this case.


shinta


> -Original Message-
> From: Dan Milstein [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 09, 2001 3:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown
> 
> 
> In terms of invalidating the cache:
> 
> The jk_ajp13_worker objects hold onto a cache of endpoints -- 
> ep_cache.  It
> would be relatively simple to loop through this cache and 
> close all the
> connections in case of ECONNRESET (you do have to call a 
> macro to enter a
> critical section -- take a look at reuse_connection()).
> 
> However, this cache only holds onto endpoints which are *not* 
> being used. 
> When an endpoint is checked out of the cache (by 
> get_endpoint), or if the
> open socket descriptor is transfered to another endpoint (in
> reuse_connection), that connection is replaced by NULL in the cache.
> 
> So if we shut down all the connections in the cache, we won't 
> shut down the
> other connections which are handling requests at that moment. 
>  My only fear
> then is that, when those connections get their own ECONNRESET 
> errors, they,
> too, will try to shutdown all the connections in the cache.  
> If TC hasn't
> come back up yet, this won't be a problem, because there won't be any
> connections in the cache.  But it does make me a bit nervous.
> 
> Hope that's helpful...
> 
> -Dan
> 
> 
> 
> GOMEZ Henri wrote:
> > 
> > La prise de conscience de votre propre ignorance est un 
> grand pas vers la
> > connaissance.
> > -- Benjamin Disraeli
> > 
> > 
> > >-Original Message-
> > >From: Dan Milstein [mailto:[EMAIL PROTECTED]]
> > >Sent: Friday, March 09, 2001 6:34 AM
> > >To: [EMAIL PROTECTED]
> > >Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown
> > >
> > >
> > >Henri,
> > >
> > >You say that checking errno isn't safe in a multithreaded env
> > >(which would
> > >certainly makes sense to me, since it looks like a global var).
> > >
> > >However, after searching online, and reading up in
> > >"Programming Threads", by
> > >Kleiman, Shah and Smaalders, I find on p. 47:
> > >
> > >"Each thread has its own independent version of the errno
> > >variable.  This
> > >allows different threads to make system calls that may change
> > >the value of errno without interfering with each other."
> > >They are describing Posix threads.  "errno" is actually a
> > >macro, apparently, which accesses the correct, 
> thread-specific errno
> > variable.
> > 
> > Right, I checked in Linux errno.h for pthread
> > 
> > >Now, I am the first to admit that I don't understand all the weird
> > >intersections between threads and sockets in C, but this looks
> > >to me like checking errno against ECONNRESET may be fine.
> > 
> > More generally when you got a read error on TCP/IP stream
> > you could consider that the link to your server (tomcat) is broken :
> > 
> > - no more route to tomcat (broken lan or routers)
> > - server not working (tomcat was stopped or server restarted)
> > 
> > >Are there platforms where that's not true?
> > 
> > I've no idea but we migth have problems in differents interpretation
> > of platform.
> > 
> > >The nice thing about getting that ECONNRESET error, is it lets
> > >us go ahead and close out that connection, and try another one.
> > 
> > Done.
> > 
> > >We could even close out a whole cache of connections,
> > >which would most likely be the right thing to do.
> > 
> > Good idea, I'll find how to do that.
> > 
> > >If we loop/retry, than how do we know to close the connec

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

[marcsaeg]

marcsaeg01/03/09 15:35:26

  Modified:src/share/org/apache/jasper/compiler Tag: tomcat_32
Compiler.java JspParseEventListener.java
JspReader.java
  Log:
  Change JSP default character encoding from 8859_1 to ISO-8859-1 which is
  the preferred name (not to mention the one in the specification).
  
  PR:  285
  Submitted by: [EMAIL PROTECTED] (Palle Girgensohn)
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.19.2.6  +4 -4  
jakarta-tomcat/src/share/org/apache/jasper/compiler/Compiler.java
  
  Index: Compiler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/Compiler.java,v
  retrieving revision 1.19.2.5
  retrieving revision 1.19.2.6
  diff -u -r1.19.2.5 -r1.19.2.6
  --- Compiler.java 2001/01/12 04:46:59 1.19.2.5
  +++ Compiler.java 2001/03/09 23:35:25 1.19.2.6
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/Compiler.java,v 1.19.2.5 
2001/01/12 04:46:59 larryi Exp $
  - * $Revision: 1.19.2.5 $
  - * $Date: 2001/01/12 04:46:59 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/Compiler.java,v 1.19.2.6 
2001/03/09 23:35:25 marcsaeg Exp $
  + * $Revision: 1.19.2.6 $
  + * $Date: 2001/03/09 23:35:25 $
*
* 
* 
  @@ -143,7 +143,7 @@
   //  - compiling the generated servlets (pass -encoding to javac).
   // XXX - There are really three encodings of interest.
   
  -String jspEncoding = "8859_1";  // default per JSP spec
  +String jspEncoding = "ISO-8859-1";  // default per JSP spec
   
// We try UTF8 by default. If it fails, we use the java encoding 
// specified for JspServlet init parameter "javaEncoding".
  
  
  
  1.17.2.4  +4 -4  
jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java
  
  Index: JspParseEventListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
  retrieving revision 1.17.2.3
  retrieving revision 1.17.2.4
  diff -u -r1.17.2.3 -r1.17.2.4
  --- JspParseEventListener.java2000/12/22 19:33:08 1.17.2.3
  +++ JspParseEventListener.java2001/03/09 23:35:25 1.17.2.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.17.2.3 2000/12/22 19:33:08 pierred Exp $
  - * $Revision: 1.17.2.3 $
  - * $Date: 2000/12/22 19:33:08 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.17.2.4 2001/03/09 23:35:25 marcsaeg Exp $
  + * $Revision: 1.17.2.4 $
  + * $Date: 2001/03/09 23:35:25 $
*
* 
*
  @@ -324,7 +324,7 @@
else
writer.println("response.setContentType(\"" +
   servletContentType +
  -";charset=8859_1\");");
  +";charset=ISO-8859-1\");");
writer.println("pageContext = _jspxFactory.getPageContext(this, request, 
response,\n"
+ "\t\t\t"
+ writer.quoteString(error) + ", "
  
  
  
  1.16.2.7  +1 -1  
jakarta-tomcat/src/share/org/apache/jasper/compiler/JspReader.java
  
  Index: JspReader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspReader.java,v
  retrieving revision 1.16.2.6
  retrieving revision 1.16.2.7
  diff -u -r1.16.2.6 -r1.16.2.7
  --- JspReader.java2000/12/22 19:33:08 1.16.2.6
  +++ JspReader.java2001/03/09 23:35:25 1.16.2.7
  @@ -278,7 +278,7 @@
   {
   this.context = ctx;
this.encoding = encoding;
  - if (this.encoding == null) this.encoding = "8859_1";
  + if (this.encoding == null) this.encoding = "ISO-8859-1";
pushFile(file, encoding);
   }
   
  
  
  

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

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

[costin]

costin  01/03/09 15:34:00

  Modified:src/facade22/org/apache/tomcat/facade
HttpServletRequestFacade.java
HttpSessionFacade.java JspInterceptor.java
  Log:
  Fix for #429 - different session facade returned in different requests.
  
  Now the session facade is 1-1 associated with the real session,
  instead of beeing recycled with the request.
  
  Thanks [EMAIL PROTECTED] (Gokul Singh) for reporting the bug.
  
  Revision  ChangesPath
  1.21  +9 -4  
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletRequestFacade.java
  
  Index: HttpServletRequestFacade.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletRequestFacade.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- HttpServletRequestFacade.java 2001/03/06 16:07:44 1.20
  +++ HttpServletRequestFacade.java 2001/03/09 23:33:59 1.21
  @@ -111,7 +111,7 @@
usingReader=false;
usingStream=false;
parametersProcessed=false;
  - if( sessionFacade!=null) sessionFacade.recycle();
  + sessionFacade=null;
if( isFacade != null ) isFacade.recycle();
isFacadeInitialized=false;
   }
  @@ -437,12 +437,17 @@
   
// No real session, return null
if( realSession == null ) {
  - if( sessionFacade!= null) sessionFacade.recycle();
  + sessionFacade=null;
return null;
}
  - if(sessionFacade==null)
  +
  + 
  + sessionFacade=(HttpSessionFacade)realSession.getFacade();
  + if( sessionFacade==null ) {
sessionFacade=new HttpSessionFacade();
  - sessionFacade.setRealSession( realSession );
  + sessionFacade.setRealSession( realSession );
  + realSession.setFacade( sessionFacade );
  + }
   return sessionFacade;
   }
   
  
  
  
  1.8   +1 -1  
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.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- HttpSessionFacade.java2001/02/20 03:34:11 1.7
  +++ HttpSessionFacade.java2001/03/09 23:33:59 1.8
  @@ -107,7 +107,7 @@
   /** Package-level method - accessible only by core
*/
   void recycle() {
  - realSession=null;
  + //  realSession=null;
   }
   
   //  public facade 
  
  
  
  1.17  +1 -1  
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/JspInterceptor.java
  
  Index: JspInterceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/JspInterceptor.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- JspInterceptor.java   2001/02/27 16:56:33 1.16
  +++ JspInterceptor.java   2001/03/09 23:33:59 1.17
  @@ -336,7 +336,7 @@
}
   
Handler wrapper=req.getHandler();
  -
  + 
if( wrapper==null )
return 0;
   
  
  
  

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

cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime BodyContentImpl.java

[marcsaeg]

marcsaeg01/03/09 15:31:55

  Modified:src/share/org/apache/jasper/runtime Tag: tomcat_32
BodyContentImpl.java
  Log:
  One last performance update to the previous commit.
  
  Double the buffer size on a realloc instead of incrementing the length.
  
  Submitted by: Andrew Gilbert [[EMAIL PROTECTED]]
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.6.6.3   +1 -1  
jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java
  
  Index: BodyContentImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java,v
  retrieving revision 1.6.6.2
  retrieving revision 1.6.6.3
  diff -u -r1.6.6.2 -r1.6.6.3
  --- BodyContentImpl.java  2001/03/04 03:42:19 1.6.6.2
  +++ BodyContentImpl.java  2001/03/09 23:31:54 1.6.6.3
  @@ -113,7 +113,7 @@
   
if (len <= Constants.DEFAULT_BUFFER_SIZE) {
tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
  - bufferSize += Constants.DEFAULT_BUFFER_SIZE;
  + bufferSize = bufferSize * 2;
} else {
tmp = new char [bufferSize + len];
bufferSize += len;
  
  
  

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

RE: Bugtraq categories

[cmanolache]

> +1 
> 
> ( you know you can doit by yourself? just looked at bugzilla and you
> have the permissions already  )

Yes, but still need the +1 before I do it :-)
( well, lazy consensus should be ok - if nobody -1 in 24h I'll add them )

Costin


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

RE: Bugtraq categories

[Ignacio J. Ortega]

+1 

( you know you can doit by yourself? just looked at bugzilla and you
have the permissions already  )

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Enviado el: sábado 10 de marzo de 2001 0:08
> Para: [EMAIL PROTECTED]
> Asunto: Bugtraq categories
> 
> 
> Hi,
> 
> I would like to add few more categories to bugzilla:
> 
> 1. install ( better name ? ) - problems in the distrib 
> packages - zip,tar,
> missing files, comments/problems on the README and release notes, 
> install issues
> 
> 2. reloading 
> 
> 3. session
> 
> This will help us clasify the issues much better.
> 
> Costin
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> 

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

Bugtraq categories

[cmanolache]

Hi,

I would like to add few more categories to bugzilla:

1. install ( better name ? ) - problems in the distrib packages - zip,tar,
missing files, comments/problems on the README and release notes, 
install issues

2. reloading 

3. session

This will help us clasify the issues much better.

Costin


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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa AccessInterceptor.java

[nacho]

nacho   01/03/09 14:54:07

  Modified:src/examples/jsp/security/login login.jsp
   src/examples/jsp index.html
   src/share/org/apache/tomcat/modules/aaa
AccessInterceptor.java
  Added:   src/examples/jsp/security index.jsp
  Log:
  Fix for < http://nagoya.apache.org/bugzilla/show_bug.cgi?id=539 >
  
  Added a way to show up the changes throught examples/jsp/security/protected.
  
  Reported by: [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.3   +1 -1  jakarta-tomcat/src/examples/jsp/security/login/login.jsp
  
  Index: login.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/examples/jsp/security/login/login.jsp,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- login.jsp 2000/10/09 02:38:15 1.2
  +++ login.jsp 2001/03/09 22:54:06 1.3
  @@ -2,7 +2,7 @@
   
   Login page for examples
   
  -
  +
Username: 
Password:  

  
  
  
  1.1  jakarta-tomcat/src/examples/jsp/security/index.jsp
  
  Index: index.jsp
  ===
  
  
  
  
  
  Security Examples
  
  
  Protected 
Directory, browse it with cookies disabled
  
  
  Protected Directory, Use with cookies enabled 
browser
  
  
  
  
  
  
  
  1.5   +1 -1  jakarta-tomcat/src/examples/jsp/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/examples/jsp/index.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- index.html2000/10/09 02:40:01 1.4
  +++ index.html2001/03/09 22:54:06 1.5
  @@ -152,7 +152,7 @@
   
   Security 
   
  -Execute
  +Execute
   
   Source
   
  
  
  
  1.8   +11 -4 
jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/AccessInterceptor.java
  
  Index: AccessInterceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/AccessInterceptor.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- AccessInterceptor.java2001/02/20 03:16:51 1.7
  +++ AccessInterceptor.java2001/03/09 22:54:07 1.8
  @@ -55,7 +55,7 @@
*
* [Additional notices, if required by prior licensing conditions]
*
  - */ 
  + */
   
   package org.apache.tomcat.modules.aaa;
   
  @@ -459,7 +459,7 @@
ServerSession session=req.getSession( false );
if( session == null ) {
}
  - 
  +
String page=ctx.getFormLoginPage();
String errorPage=ctx.getFormErrorPage();
// assert errorPage!=null ( AccessInterceptor will check
  @@ -481,8 +481,15 @@
}
   
String originalLocation = req.requestURI().toString();
  - if (req.queryString().toString() != null)
  + if (req.queryString().toString() != null
  +&& !req.queryString().toString().equals(""))
originalLocation += "?" + req.queryString().toString();
  +//XXX is needed to put the JVM route too?
  +if (req.getSessionIdSource().equals(Request.SESSIONID_FROM_URL)){
  +String id=";jsessionid="+req.getSessionId() ;
  +originalLocation += id ;
  +page += id ;
  +}
session.setAttribute( "tomcat.auth.originalLocation",
  originalLocation);
if( debug > 0 )
  @@ -502,7 +509,7 @@
   This is called after the user POST the form login page.
   */
   class FormSecurityCheckHandler extends Handler {
  -
  +
   FormSecurityCheckHandler() {
//  setOrigin( Handler.ORIGIN_INTERNAL );
name="tomcat.formSecurityCheck";
  
  
  

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

[Bug 215] New - .java Package names that start with a '.' BugRat Report#329

[bugzilla]

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

*** shadow/215  Fri Mar  9 14:44:01 2001
--- shadow/215.tmp.7637 Fri Mar  9 14:44:01 2001
***
*** 0 
--- 1,48 
+ ++
+ | .java Package names that start with a '.' BugRat Report#329|
+ ++
+ |Bug #: 215 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Jasper  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED]   |
+ |  Reported By: [EMAIL PROTECTED]  |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ This snippet is take from an error I get when I invoke a jsp in a new window
+ Error: 500
+ 
+ Location:
+ //Portal302/pane/mypicture/fileUpload.jsp
+ 
+ Internal Servlet Error:
+ 
+ org.apache.jasper.JasperException: Unable to compile class for 
+JSPC:\j\work\localhost_8080\_0002f_0002fPortal_00033_00030_00032_0002fpane_0002fmypicture_0002ffileUpload_0002ejspfileUpload_jsp_0.java:1:
+ Identifier expected.
+ package .Portal_00033_00030_00032.pane.mypicture;
+^
+ 
+C:\j\work\localhost_8080\_0002f_0002fPortal_00033_00030_00032_0002fpane_0002fmypicture_0002ffileUpload_0002ejspfileUpload_jsp_0.java:19:
+ Superclass HttpJspBase of class 
+_0002f_0002fPortal_00033_00030_00032_0002fpane_0002fmypicture_0002ffileUpload_0002ejspfileUpload_jsp_0
+ not found.
+ public class 
+_0002f_0002fPortal_00033_00030_00032_0002fpane_0002fmypicture_0002ffileUpload_0002ejspfileUpload_jsp_0
+ extends HttpJspBase {
+  
+   ^
+ 2 errors
+ 
+ at org.apache.jasper.compiler.Compiler.compile(Compiler.java:247)
+ at org.apache.jasper.runtime.JspServlet.loadJSP(JspServlet.java:413)
+ at 
+org.apache.jasper.runtime.JspServlet$JspServletWrapper.loadIfNecessary(JspServlet.java:149)
+ at 
+org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet.java:161)
+ at org.apache.jasper.runtime.JspServlet.serviceJspFile(JspServlet.java:261)
+ at org.apache.jasper.runtime.JspServlet.service(JspServlet.java:369)
+ at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
+ at 
+org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java:503)
+ at org.apache.tomcat.core.ContextManager.service(ContextManager.java:559)
+ at 
+org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12ConnectionHandler.java:156)
+ at 
+org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:338)
+ at java.lang.Thread.run(Unknown Source)
+ 
+ 
+ it seems to have lost touch with the parent servlet and hence cannot use it to 
+generate the name for the (.java) files
+ This wouldn't be a problem but this short package name starts with a '.' and javac 
+won't compile it

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

[Bug 201] New - http session is invalidated too frequently. BugRat Report#310

[bugzilla]

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

*** shadow/201  Fri Mar  9 14:33:53 2001
--- shadow/201.tmp.7612 Fri Mar  9 14:33:53 2001
***
*** 0 
--- 1,21 
+ ++
+ | http session is invalidated too frequently. BugRat Report#310  |
+ ++
+ |Bug #: 201 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.1.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Servlet |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]   |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ I am using TOMCAT as our JSP referenced implementation. We have several JSP's being 
+used in a single web session and we use a Java Bean with session scope using the 
+ tag. The problem is that the http session gets invalidated between 
+JSP requests for some unknown reason and the Java Bean is lost. Any reference to the 
+bean raises a null pointer exception.
+ 
+ How can I prevent the http session from being invalidated so frequently? it happens 
+to 1 out of 6 requests. Is this a bug in TOMCAT? how do I work around this?
+ 
+ Thanks.

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

[Bug 218] New - IIS & in-process tomcat BugRat Report#333

[bugzilla]

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

*** shadow/218  Fri Mar  9 14:45:09 2001
--- shadow/218.tmp.7653 Fri Mar  9 14:45:09 2001
***
*** 0 
--- 1,21 
+ ++
+ | IIS & in-process tomcat BugRat Report#333  |
+ ++
+ |Bug #: 218 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.1.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Connectors  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]   |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ Applet sends an Object through ObjectOutputStream created from URLConnection.
+ Servlet-side: While trying create ObjectInputStream from HttpServletRequest, 
+StreamCorruptedException: Caught EOF exception while reading, is thrown.
+ 
+ Servlet responds fine again using ObjectOutputStream.
+ Out-of-process/Stand-alone no corruption occurs.

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

[Bug 223] New - security.authentication port must be True or False BugRat Report#347

[bugzilla]

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

*** shadow/223  Fri Mar  9 14:46:18 2001
--- shadow/223.tmp.7663 Fri Mar  9 14:46:18 2001
***
*** 0 
--- 1,21 
+ ++
+ | security.authentication port must be True or False BugRat Report#347   |
+ ++
+ |Bug #: 223 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.1 Final   |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Auth|
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED] |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ tomcat.properties:
+ security.authentication=false
+ 
+ logged error:
+ port must be TRUE or FALSE

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

[Bug 202] New - If browser send russian locale (ru) then StaticInterceptor traps with a "non ISO-8859-1" charset exception at attempt to write buf to ServletOutputStream, the date gets cyricllic characters BugRat Report#311

[bugzilla]

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

*** shadow/202  Fri Mar  9 14:34:37 2001
--- shadow/202.tmp.7617 Fri Mar  9 14:34:37 2001
***
*** 0 
--- 1,69 
+ ++
+ | If browser send russian locale (ru) then StaticInterceptor traps with a "n |
+ ++
+ |Bug #: 202 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Encoding|
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]|
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ in src/share/org/apache/tomcat/request/StaticInterceptor.java, line apporx 354, 
+we've got
+ 
+ public void doService(Request req, Response res)
+ throws Exception
+ {
+ // this is how ge...
+ // the next round of optimizations
+ Locale locale=RequestUtil.getLocale(req);
+ StringManager 
+sm=StringManager.getManager("org.apache.tomcat.resources",locale);
+ DateFormat dateFormat =
+ new SimpleDateFormat(datePattern,locale );
+ ...
+ and later, at line around 488 (at the end of doService()) we've got
+ ...
+ buf.append("");
+ buf.append(dateFormat.format(new Date(f.lastModified(;
+ ...
+ which resulted in the following exception 
+ 
+ java.io.IOException: Not an ISO 8859_1 character:?
+   at java.lang.Throwable.(Throwable.java:96)
+   at java.lang.Exception.(Exception.java:44)
+   at java.io.IOException.(IOException.java:49)
+   at 
+org.apache.tomcat.core.BufferedServletOutputStream.print(BufferedServletOutputStream.java(Compiled
+ Code))
+   at org.apache.tomcat.request.DirHandler.doService(StaticInterceptor.java:538)
+   at org.apache.tomcat.core.Handler.service(Handler.java:263)
+   at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:371)
+   at 
+org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:786)
+   at org.apache.tomcat.core.ContextManager.service(ContextManager.java:732)
+   at 
+org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210)
+   at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:407)
+   at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
+   at java.lang.Thread.run(Thread.java:498)
+ 
+ when the request contains russina locale
+ (don't pay too much attention to line numbers I've got 'em a little bit wrong cause 
+to my modifications .. ;) 
+ 
+ 
+ In short that is the line 
+  ServletOutputStream out=res.getOutputStream();
+   out.print(buf.toString());
+ 
+ 
+ I've also dumped the buf to a file (just for my pleasure), here it is:
+ =
+ java.io.IOException: Not an ISO 8859_1 character:?   
+  
+   
+   Directory Listing 
+for:/ Directory Listing for:/   
+ Subdirectories: 
+  
+  cocoonsamples/   
+  
+   ??, 21 ??? 2000 00:39 
+GMT+04:00 Files:  
+m.html     
+  0.0 KB??, 23 ??? 2000 15:04 GMT+04:00
+ Tomcat Web Server v3.2 beta 6
+  
+ 
+ Here we can see that some parts of the date got wrong...

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

[Bug 190] New - Indexed property setter does not get called if first field in array of fields is blank BugRat Report#277

[bugzilla]

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

*** shadow/190  Fri Mar  9 14:32:52 2001
--- shadow/190.tmp.7603 Fri Mar  9 14:32:52 2001
***
*** 0 
--- 1,19 
+ ++
+ | Indexed property setter does not get called if first field in array of fie |
+ ++
+ |Bug #: 190 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.1.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Jasper  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED]   |
+ |  Reported By: [EMAIL PROTECTED]  |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ If an array of fields is created by defining multiple input fields in an HTML form 
+with the same name, and field to property mapping is enabled via the 
+setProperty..."*" (wildcard) and the first field in the HTML form is left blank the 
+property setter for the corresponding indexed property does not get called. If the 
+first field is filled in, the setter does get called, regardless if any of the other 
+fields are filled or not. JavaWebServer 2.0 does not seem to exhibit this behavior.
+ 
+ By the way I was unable to "Show All Bugs in Project" for Tomcat, or create a new 
+user fr reporting bugs - I never get a response from the web server. 

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

Re: Any news on bug 208?

[Gerard van Enk]

Gerard van Enk wrote:
> 
> Hello,
> 
> I ran into a problem similar to bug 208, but I'm using mod_jk, ajp13,
> tomcat3.1.1, I've added this information to the bugreport. But I am

oops this has to be tomcat3.2.1 :)

> curious if there was any news about this bug, because it reported as if
> I remember correctly a few months ago for the first time.
> 
> It's a problem when using apache and mod_jk getRemoteHost() is returning
> null, or does this have something to do with a configuration error on my
> account?
> 
> I looked into the native c files for the connector, but it's a long time
> ago I used c :) and I couldn't find anything (but this doesn't say
> anything :) ).
> 


Hmmm...I just discovered when using tomcat 3.2 beta 6 and mod_jk (ajp12)
it returns "" instead of null. Don't know if this information is
usefull.

Gerard

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

Re: Implementation in 4.0.b1

[Remy Maucherat]

Quoting [EMAIL PROTECTED]:

> YET: this same code works when I run it from a standalone Java
> application.
> I believe that tomcat's InitialContext() is preventing the remote
> connection from being established.

Actually, it's a classloader related issue which has been fixed after beta 1.

Remy

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

Any news on bug 208?

[Gerard van Enk]

Hello,

I ran into a problem similar to bug 208, but I'm using mod_jk, ajp13,
tomcat3.1.1, I've added this information to the bugreport. But I am
curious if there was any news about this bug, because it reported as if
I remember correctly a few months ago for the first time. 

It's a problem when using apache and mod_jk getRemoteHost() is returning
null, or does this have something to do with a configuration error on my
account?

I looked into the native c files for the connector, but it's a long time
ago I used c :) and I couldn't find anything (but this doesn't say
anything :) ).

Gerard

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

[Bug 154] New - Setting Last-Modified within doGet results in duplicate Last-Modified headers BugRat Report#185

[bugzilla]

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

*** shadow/154  Fri Mar  9 14:17:12 2001
--- shadow/154.tmp.7453 Fri Mar  9 14:17:12 2001
***
*** 0 
--- 1,33 
+ ++
+ | Setting Last-Modified within doGet results in duplicate Last-Modified head |
+ ++
+ |Bug #: 154 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: Nightly Build   |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Servlet |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED] |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ Within my doGet() routine, I manually
+ set Last-Modified using:
+ 
+ setDateHeader("Last-Modified", modificationTime);
+ 
+ I also implement getLastModified().
+ 
+ If getLastModified returns a valid value, then
+ the response generated has duplicate Last-Modified
+ headers.  Looking at
+ jakarta-servletapi/.../javax/servlet/http/HttpServlet.java,
+ it appears that the service() routine sets a Last-Modified
+ header before calling doGet(), which suggests that
+ setDateHeader() is broken and fails to correctly
+ override the previous definition.  I looked through
+ jakarta-tomcat/.../util/MimeHeaders.java and couldn't
+ see what might cause this behavior.

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

[Bug 182] Changed - JSP error-page doesn't work with virtual hosts BugRat Report#253

[bugzilla]

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

*** shadow/182  Fri Mar  9 14:31:04 2001
--- shadow/182.tmp.7589 Fri Mar  9 14:31:33 2001
***
*** 2,13 
  | JSP error-page doesn't work with virtual hosts BugRat Report#253   |
  ++
  |Bug #: 182 Product: Tomcat 3|
! |   Status: NEW Version: 3.2.1 Final |
  |   Resolution:Platform: All |
  | Severity: Normal   OS/Version: All |
  | Priority: High  Component: Config  |
  ++
! |  Assigned To: [EMAIL PROTECTED]|
  |  Reported By: [EMAIL PROTECTED] |
  |  CC list: Cc:  |
  ++
--- 2,13 
  | JSP error-page doesn't work with virtual hosts BugRat Report#253   |
  ++
  |Bug #: 182 Product: Tomcat 3|
! |   Status: UNCONFIRMED Version: 3.2.1 Final |
  |   Resolution:Platform: All |
  | Severity: Normal   OS/Version: All |
  | Priority: High  Component: Config  |
  ++
! |  Assigned To: [EMAIL PROTECTED] |
  |  Reported By: [EMAIL PROTECTED] |
  |  CC list: Cc:  |
  ++

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

[Bug 169] Changed - Overflow where JSP tag embedded in HTML tag BugRat Report#226

[bugzilla]

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

*** shadow/169  Sat Feb  3 11:14:20 2001
--- shadow/169.tmp.7529 Fri Mar  9 14:24:52 2001
***
*** 2,13 
  | Overflow where JSP tag embedded in HTML tag BugRat Report#226  |
  ++
  |Bug #: 169 Product: Tomcat 3|
! |   Status: NEW Version: 3.1 Final   |
  |   Resolution:Platform: All |
  | Severity: Normal   OS/Version: All |
  | Priority: High  Component: Jasper  |
  ++
! |  Assigned To: [EMAIL PROTECTED]  |
  |  Reported By: [EMAIL PROTECTED] |
  |  CC list: Cc:  |
  ++
--- 2,13 
  | Overflow where JSP tag embedded in HTML tag BugRat Report#226  |
  ++
  |Bug #: 169 Product: Tomcat 3|
! |   Status: UNCONFIRMED Version: 3.1 Final   |
  |   Resolution:Platform: All |
  | Severity: Normal   OS/Version: All |
  | Priority: High  Component: Jasper  |
  ++
! |  Assigned To: [EMAIL PROTECTED]   |
  |  Reported By: [EMAIL PROTECTED] |
  |  CC list: Cc:  |
  ++

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

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

[costin]

costin  01/03/09 14:29:24

  Modified:src/share/org/apache/jasper/compiler
JspParseEventListener.java
  Log:
  The previous patch had another change, the flushBuffer() fix.
  
  Added few comments and commited again, to have a separate message for it.
  
  Revision  ChangesPath
  1.24  +2 -0  
jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java
  
  Index: JspParseEventListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- JspParseEventListener.java2001/03/09 22:26:13 1.23
  +++ JspParseEventListener.java2001/03/09 22:29:23 1.24
  @@ -356,6 +356,8 @@
/* Do stuff here for finally actions... */
   //writer.println("out.close();");
   
  + // Use flush buffer ( which just empty JspWriterImpl buffer )
  + // instead of commiting the response.
writer.println("if (out instanceof org.apache.jasper.runtime.JspWriterImpl) { 
");
   writer.println("
((org.apache.jasper.runtime.JspWriterImpl)out).flushBuffer();");
writer.println("}");
  
  
  

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

[Bug 171] New - Auto xfer of DocBase info from server.xml to tomcat-apache.conf is not accurate BugRat Report#229

[bugzilla]

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

*** shadow/171  Fri Mar  9 14:27:38 2001
--- shadow/171.tmp.7556 Fri Mar  9 14:27:38 2001
***
*** 0 
--- 1,20 
+ ++
+ | Auto xfer of DocBase info from server.xml to tomcat-apache.conf is not acc |
+ ++
+ |Bug #: 171 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.1.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Config  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]  |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ *IT MAY NOT BE A BUG AFTER ALL. IF SO, PARDON MY IGNORANCE*
+ 
+ When tomcat starts, it creates a new tomcat-apache.conf file. It includes Alias and 
+ApJservMount information dervied from enteries in server.xml. The Alias and directory 
+attributes' information does not match the DOCBASE information given in the 
+server.xml *IF* the docbase was reported to be someplace other than 
+/webapps/.
+ It seems that no matter what the value of docbase, the auto generated tomcat-apache 
+file just hardcodes the directory and alias information to be 
+/webapps/.

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

[Bug 159] New - xml.jar or parser.jar incompatible with latest Xerces parser BugRat Report#191

[bugzilla]

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

*** shadow/159  Fri Mar  9 14:22:07 2001
--- shadow/159.tmp.7499 Fri Mar  9 14:22:07 2001
***
*** 0 
--- 1,28 
+ ++
+ | xml.jar or parser.jar incompatible with latest Xerces parser BugRat Report |
+ ++
+ |Bug #: 159 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Jasper  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED]   |
+ |  Reported By: [EMAIL PROTECTED]|
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ The JSP processor has its own xml parser in xml.jar(3.1) or
+ parser.xml(3.2). I am developing an application using Xerces 
+ 3.01. Unfortunately the JSP jar defines the org.w3c.dom.Document
+ interface and doesn't include the importNode method.
+ 
+ I get a NoMethod failure on calling importNodes. This is due
+ to the old document interface in xml/parser.jar. My reference
+ to w3c.org.dom.Document is resolving to the JSP jar not the
+ Xerces.jar I include in webapps/examples/web-inf/lib.
+ 
+ Most preferable would be to not use the org.w3c.dom path in these
+ jars.

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

[Bug 156] New - cast exception in servletWrapper.service. BugRat Report#188

[bugzilla]

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

*** shadow/156  Fri Mar  9 14:18:58 2001
--- shadow/156.tmp.7464 Fri Mar  9 14:18:58 2001
***
*** 0 
--- 1,19 
+ ++
+ | cast exception in servletWrapper.service. BugRat Report#188|
+ ++
+ |Bug #: 156 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Servlet |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]   |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ An exception was raised in doInit() call. If the exception
+ is thrown and it is not an UnavailableException, the unavailable is casted to be an 
+Exception. Later in service() call, the unavailable is casted to UnavailableException
+ which case cast exception. 

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

cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler BeanGenerator.java GetPropertyGenerator.java JspParseEventListener.java SetPropertyGenerator.java StoredCharDataGenerator.java TagBeginGenerator.java TagEndGenerator.java

[costin]

costin  01/03/09 14:26:15

  Modified:src/share/org/apache/jasper Constants.java
   src/share/org/apache/jasper/compiler BeanGenerator.java
GetPropertyGenerator.java
JspParseEventListener.java
SetPropertyGenerator.java
StoredCharDataGenerator.java TagBeginGenerator.java
TagEndGenerator.java
  Log:
  Fix bug 434, jasper importing more than it should
  
  javax.servlet.jsp.tagext is still imported ( even if it is not in the
  list), watchdog must be fixed first.
  
  Thanks to [EMAIL PROTECTED] for reporting the bug.
  
  Revision  ChangesPath
  1.17  +16 -7 jakarta-tomcat/src/share/org/apache/jasper/Constants.java
  
  Index: Constants.java
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/Constants.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- Constants.java2001/02/20 03:36:00 1.16
  +++ Constants.java2001/03/09 22:26:12 1.17
  @@ -72,7 +72,8 @@
   /**
* The base class of the generated servlets. 
*/
  -public static final String JSP_SERVLET_BASE = "HttpJspBase";
  +public static final String JSP_SERVLET_BASE =
  + "org.apache.jasper.runtime.HttpJspBase";
   
   /**
* _jspService is the name of the method that is called by 
  @@ -94,13 +95,21 @@
*with all our generators -akv.
*/
   public static final String[] STANDARD_IMPORTS = { 
  - "javax.servlet.*", "javax.servlet.http.*", "javax.servlet.jsp.*", 
  -"javax.servlet.jsp.tagext.*",
  - "java.io.PrintWriter", "java.io.IOException", "java.io.FileInputStream",
  -"java.io.ObjectInputStream", "java.util.Vector",
  - "org.apache.jasper.runtime.*", "java.beans.*",
  - "org.apache.jasper.JasperException"
  + "javax.servlet.*",
  + "javax.servlet.http.*",
  + "javax.servlet.jsp.*",
  + // This one is not in spec, but a lot of tests depend on it.
  + // The code is fixed to use explicit deps, when we test
  + // the watchdog tests we can remove this
  + "javax.servlet.jsp.tagext.*"
   };
  +
  +// "javax.servlet.jsp.tagext.*",
  +//   "java.io.PrintWriter", "java.io.IOException", "java.io.FileInputStream",
  +// "java.io.ObjectInputStream", "java.util.Vector",
  +//   "org.apache.jasper.runtime.*", "java.beans.*",
  +//   "org.apache.jasper.JasperException"
  +// };
   
   /**
* ServletContext attribute for classpath. This is tomcat specific. 
  
  
  
  1.9   +5 -5  
jakarta-tomcat/src/share/org/apache/jasper/compiler/BeanGenerator.java
  
  Index: BeanGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/BeanGenerator.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- BeanGenerator.java2000/07/13 16:51:57 1.8
  +++ BeanGenerator.java2001/03/09 22:26:13 1.9
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/BeanGenerator.java,v 1.8 
2000/07/13 16:51:57 alex Exp $
  - * $Revision: 1.8 $
  - * $Date: 2000/07/13 16:51:57 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/BeanGenerator.java,v 1.9 
2001/03/09 22:26:13 costin Exp $
  + * $Revision: 1.9 $
  + * $Date: 2001/03/09 22:26:13 $
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation.  All rights 
  @@ -345,11 +345,11 @@
writer.pushIndent ();
if (beanRT == false)
writer.println(varname+" = ("+ convert + 
  -") Beans.instantiate(this.getClass().getClassLoader(), "+
  +") 
java.beans.Beans.instantiate(this.getClass().getClassLoader(), "+
   writer.quoteString(clsname) +");");
else
writer.println(varname+" = ("+ convert + 
  -") Beans.instantiate(this.getClass().getClassLoader(), "+
  +") 
java.beans.Beans.instantiate(this.getClass().getClassLoader(), "+
   clsname +");");
writer.popIndent ();
writer.println ("} catch (Exception exc) {");
  
  
  
  1.4   +5 -5  
jakarta-tomcat/src/share/org/apache/jasper/compiler/GetPropertyGenerator.java
  
  Index: GetPropertyGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/GetPropertyGenerator.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- GetPropertyGenerator.java 2000/01/12 07:11:14 1.3
  +++ GetPropertyGenerator.java 2001/03/09 22:26:13 1.4

Re: Implementation in 4.0.b1

[tttye]

Weining Qi writes:

> if you are running tomcat 3.x in the same window (tomcat run), look at the
> feedback from tomcat when call the ejb that way, you can see that tomcat 
> does not recognize the namespace "java:com/env/" for calling ejb as 
  The name is "java:comp/ejb"  NOT --.
  And yes tomcat does recognize it
  Because it is defined in web.xml as shown in the snip.

> the sun j2ee specification v1.3. you should call ejb directly by its jndi 
> name, which you gave when you deployed it.
I tried that, it does not work.  I get "NamingException".
Note: the EJB is deployed in a different machine than tomcat.  
When I try to open the context to that machine directly from a servlet in
tomcat, I get:
javax.naming.NoInitialContextException: Cannot instantiate class:
org.jnp.interfaces.NamingContextFactory.  Root exception is
java.lang.ClassCastException: org.jnp.interfaces.NamingContextFactory
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:659)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:250)
at javax.naming.InitialContext.init(InitialContext.java:226)
at javax.naming.InitialContext.(InitialContext.java:202)
at SimpleServlet.printContextInfo(SimpleServlet.java:168)
at SimpleServlet.doIt(SimpleServlet.java:99)
at SimpleServlet.doGet(SimpleServlet.java:30)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:573)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:321)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:236)
at
org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:386)
at
org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:144)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:180)
at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:180)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:251)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:196)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:464)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2041)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:159)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:818)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:897)
at java.lang.Thread.run(Thread.java:484)

YET: this same code works when I run it from a standalone Java application.
I believe that tomcat's InitialContext() is preventing the remote
connection from being established.

> 
> Weining
> 
> Weining Qi
> RabobankICT and Info.nl, Amsterdam
> IPO, TU/e, Eindhoven, The Netherlands
> http://weining.n3.net/
> Tel: +31.628161183
> 
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, March 09, 2001 5:55 PM
> Subject:   Implementation in 4.0.b1
> 
> 
> >
> > I am trying to obtain a remote reference to an EJB in another machine.
> > I have set the ejb-ref in web.xml as follows:
> > 
> > Sample bean generated by coolgen placed here for ease of
> >  early testing
> > ejb/S_STRESS_32K
> > Session
> > cool.models.coop07.java.S_STRESS_32KpsHome
> > cool.models.coop07.java.S_STRESS_32Kps
> > jndi:/ttt1.ca.com:1099/S_STRESS_32Kps
> > 
> > However, when I do ctx.lookup("java:/comp/ejb/S_STRESS_32K") I get a null
> > reference instead of the necessary remote reference to the home interface.
> > Is ejb-link implemented and documented?
> > Which code is involved in ejb-link 

3.3 build

[cmanolache]

Hi,

I'm doing some fixes in the nightly build, and I was wondering about
changing the default to what most other jakarta projects are using.

I hate creating build in jakarta-tomcat - but since most other projects
adopted this we should do it in 3.3 too. Now it's the right moment ( since
we are preparing to build M2 - so we'll deal with all the build details
and scripts ).

Let me know what you think - I would be very happy to hear you strongly
disagree with mixing the source and build result, but if no commiter -1
it I guess we should do it.

Costin  


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

[Bug 117] New - IllegalStateException when error in jsp servlet include encountered BugRat Report#124

[bugzilla]

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

*** shadow/117  Fri Mar  9 14:10:39 2001
--- shadow/117.tmp.7379 Fri Mar  9 14:10:39 2001
***
*** 0 
--- 1,71 
+ ++
+ | IllegalStateException when error in jsp servlet include encountered BugRat |
+ ++
+ |Bug #: 117 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.2.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Jasper  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED]   |
+ |  Reported By: [EMAIL PROTECTED]|
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ If a jsp page references a servlet after including some other content, and gets a 
+ClassNotFoundException on that servlet, an IllegalStateException occurs during a 
+buffer reset.
+ This error is very misleading, and doesn't point to the classpath or servlet setup 
+in web.xml as the cause. It looks like it's an internal error in Tomcat
+ instead of a simple configuration error.
+ 
+ Stacktraces:
+ 
+ Location:/test/foobar.jsp
+ 
+ Internal Servlet Error:
+ 
+ javax.servlet.ServletException: can't reset buffer after writing to client
+ at 
+org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:448)
+ at 
+_0002ffoobar_0002ejspfoobar_jsp_1._jspService(_0002ffoobar_0002ejspfoobar_jsp_1.java:75)
+ at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
+ at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
+ at 
+org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177)
+ at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:309)
+ at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:382)
+ at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
+ at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:387)
+ at org.apache.tomcat.core.Handler.service(Handler.java:263)
+ at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:371)
+ at 
+org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:749)
+ at org.apache.tomcat.core.ContextManager.service(ContextManager.java:695)
+ at 
+org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:207)
+ at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:403)
+ at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
+ at java.lang.Thread.run(Thread.java:475)
+ 
+ Root cause: 
+ 
+ java.lang.IllegalStateException: can't reset buffer after writing to client
+ at 
+org.apache.tomcat.core.BufferedServletOutputStream.reset(BufferedServletOutputStream.java:296)
+ at org.apache.tomcat.core.ResponseImpl.resetBuffer(ResponseImpl.java:395)
+ at 
+org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:953)
+ at org.apache.tomcat.core.Handler.service(Handler.java:249)
+ at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:371)
+ at 
+org.apache.tomcat.facade.RequestDispatcherImpl.include(RequestDispatcherImpl.java:308)
+ at 
+org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:407)
+ at 
+_0002ffoobar_0002ejspfoobar_jsp_1._jspService(_0002ffoobar_0002ejspfoobar_jsp_1.java:65)
+ at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
+ at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
+ at 
+org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177)
+ at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:309)
+ at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:382)
+ at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
+ at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:387)
+ at org.apache.tomcat.core.Handler.service(Handler.java:263)
+ at org.apache.tomcat.core.Serv

[Bug 142] New - Feature to forward requests using request dispatcher even if the servlet input stream is empty BugRat Report#161

[bugzilla]

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

*** shadow/142  Fri Mar  9 14:15:47 2001
--- shadow/142.tmp.7443 Fri Mar  9 14:15:47 2001
***
*** 0 
--- 1,19 
+ ++
+ | Feature to forward requests using request dispatcher even if the servlet i |
+ ++
+ |Bug #: 142 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.1.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Servlet |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]   |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ When i process multipart/form data in my servlet, I need to read the input stream to 
+parse the binary data. I use HttpUtils.parsePostData to do this. Note that I do not 
+use getParameter on the HttpRequest anywhere after this(since that would definitely 
+fail - I have emptied the input stream into my own data structures). But I need to 
+forward this request to a JSP now. The JSP uses my data structures for the form 
+parameters (that i have passed in as attribute in the HTTP request). It looks like 
+internally, tomcat uses the getParameter call on the http request while invoking the 
+dispatcher.forward, which in turn calls httpUtils.parsePostData , thus landing up 
+with a short read !!
+ 
+ Is there any way, the forward can happen with an empty input stream of parameters ?

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

[Bug 141] New - Directory directive being ignored BugRat Report#159

[bugzilla]

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

*** shadow/141  Fri Mar  9 14:13:48 2001
--- shadow/141.tmp.7427 Fri Mar  9 14:13:48 2001
***
*** 0 
--- 1,24 
+ ++
+ | Directory directive being ignored BugRat Report#159|
+ ++
+ |Bug #: 141 Product: Tomcat 3|
+ |   Status: UNCONFIRMED Version: 3.1.1 Final |
+ |   Resolution:Platform: All |
+ | Severity: Normal   OS/Version: All |
+ | Priority: High  Component: Connectors  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED] |
+ |  Reported By: [EMAIL PROTECTED]  |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ The  Directive to disallow the display of
+ directory listings specifically 
+ 
+ Options FollowSymLinks
+ AllowOverride None
+ 
+ 
+ 

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

Re: Implementation in 4.0.b1

[Weining Qi]

hi,

if you are running tomcat 3.x in the same window (tomcat run), look at the
feedback from tomcat when call the ejb that way, you can see that tomcat does
not recognize the namespace "java:com/env/" for calling ejb as recommended by
the sun j2ee specification v1.3. you should call ejb directly by its jndi name,
which you gave when you deployed it.

tomcat 4.0-beta has also the same problem, but it improves with interpreting the
 element: you can get environment entries defined within deployment
descriptor of the tomcat app the same way of j2ee speci v1.3 (p. 5-4). but, with
tomcat 4.0-beta you cannot call ejb by jndi name!? i just test this today. the
ejb server i am using is j2ee sun reference implementation, winnt and win2000.

is there anybody who has met the same on other ejb servers?

Weining

Weining Qi
RabobankICT and Info.nl, Amsterdam
IPO, TU/e, Eindhoven, The Netherlands
http://weining.n3.net/
Tel: +31.628161183

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 09, 2001 5:55 PM
Subject:   Implementation in 4.0.b1


>
> I am trying to obtain a remote reference to an EJB in another machine.
> I have set the ejb-ref in web.xml as follows:
> 
> Sample bean generated by coolgen placed here for ease of
>  early testing
> ejb/S_STRESS_32K
> Session
> cool.models.coop07.java.S_STRESS_32KpsHome
> cool.models.coop07.java.S_STRESS_32Kps
> jndi:/ttt1.ca.com:1099/S_STRESS_32Kps
> 
> However, when I do ctx.lookup("java:/comp/ejb/S_STRESS_32K") I get a null
> reference instead of the necessary remote reference to the home interface.
> Is ejb-link implemented and documented?
> Which code is involved in ejb-link lookup?
> Is this fixed in the latest 4.0?
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config LogSetter.java

[larryi]

larryi  01/03/09 13:39:32

  Modified:src/share/org/apache/tomcat/modules/config LogSetter.java
  Log:
  Update to set the default ServletLog for a Context if it hasn't been set
  already.  Defaulting provided in Context, defaults ServletLog output to the
  main Context log.
  
  Revision  ChangesPath
  1.10  +12 -0 
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LogSetter.java
  
  Index: LogSetter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LogSetter.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- LogSetter.java2001/03/02 04:49:13 1.9
  +++ LogSetter.java2001/03/09 21:39:32 1.10
  @@ -261,6 +261,18 @@
   
   }
   
  +/** Set default ServletLog for Context if necessary
  + */
  +
  +public void addContext( ContextManager cm, Context ctx )
  + throws TomcatException
  +{
  + if( "org/apache/tomcat/facade".equals( name ) &&
  + ctx.getServletLog() == null ) {
  + ctx.setServletLog( Log.getLog( name, ctx.getId() ) );
  + }
  +}
  +
   /** Adapter and registry for QueueLoggers
*/
   static class TomcatLogManager extends LogManager {
  
  
  

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

Re: FW: problem w/ ajp13 - if Tomcat is shutdown

[Dan Milstein]

In terms of invalidating the cache:

The jk_ajp13_worker objects hold onto a cache of endpoints -- ep_cache.  It
would be relatively simple to loop through this cache and close all the
connections in case of ECONNRESET (you do have to call a macro to enter a
critical section -- take a look at reuse_connection()).

However, this cache only holds onto endpoints which are *not* being used. 
When an endpoint is checked out of the cache (by get_endpoint), or if the
open socket descriptor is transfered to another endpoint (in
reuse_connection), that connection is replaced by NULL in the cache.

So if we shut down all the connections in the cache, we won't shut down the
other connections which are handling requests at that moment.  My only fear
then is that, when those connections get their own ECONNRESET errors, they,
too, will try to shutdown all the connections in the cache.  If TC hasn't
come back up yet, this won't be a problem, because there won't be any
connections in the cache.  But it does make me a bit nervous.

Hope that's helpful...

-Dan



GOMEZ Henri wrote:
> 
> La prise de conscience de votre propre ignorance est un grand pas vers la
> connaissance.
> -- Benjamin Disraeli
> 
> 
> >-Original Message-
> >From: Dan Milstein [mailto:[EMAIL PROTECTED]]
> >Sent: Friday, March 09, 2001 6:34 AM
> >To: [EMAIL PROTECTED]
> >Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown
> >
> >
> >Henri,
> >
> >You say that checking errno isn't safe in a multithreaded env
> >(which would
> >certainly makes sense to me, since it looks like a global var).
> >
> >However, after searching online, and reading up in
> >"Programming Threads", by
> >Kleiman, Shah and Smaalders, I find on p. 47:
> >
> >"Each thread has its own independent version of the errno
> >variable.  This
> >allows different threads to make system calls that may change
> >the value of errno without interfering with each other."
> >They are describing Posix threads.  "errno" is actually a
> >macro, apparently, which accesses the correct, thread-specific errno
> variable.
> 
> Right, I checked in Linux errno.h for pthread
> 
> >Now, I am the first to admit that I don't understand all the weird
> >intersections between threads and sockets in C, but this looks
> >to me like checking errno against ECONNRESET may be fine.
> 
> More generally when you got a read error on TCP/IP stream
> you could consider that the link to your server (tomcat) is broken :
> 
> - no more route to tomcat (broken lan or routers)
> - server not working (tomcat was stopped or server restarted)
> 
> >Are there platforms where that's not true?
> 
> I've no idea but we migth have problems in differents interpretation
> of platform.
> 
> >The nice thing about getting that ECONNRESET error, is it lets
> >us go ahead and close out that connection, and try another one.
> 
> Done.
> 
> >We could even close out a whole cache of connections,
> >which would most likely be the right thing to do.
> 
> Good idea, I'll find how to do that.
> 
> >If we loop/retry, than how do we know to close the connection?
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

-- 

Dan Milstein // [EMAIL PROTECTED]

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

RE: where to plug-in startup/shutdown knowledge for internal tomcatcomponents

[cmanolache]

On Fri, 9 Mar 2001, Casey Lucas wrote:

> So, given all that, I need to control lifetime of TagHandlerPoolManager's
> default instance.  By controlling it, I can have one TagHandlerPoolManager
> instance per web application and when the web application gets unloaded,
> all the Tag.release methods can be called.  Aren't the JspServlet and
> JspInterceptor mechanisms specific to an individual jsp file?  If so,
> I don't think that's what I need because pooling will be for the entire
> web application not a specific JSP.

> I was hoping that when the web application (not individual jsp) is
> loaded, unloaded, reloaded I could do the TagHandlerPoolManager initialization
> and cleanup tasks.  Maybe I'm making things too complicated.  Should
> managing the lifetime of a per-web-application object like
> TagHandlerPoolManager be simpler?

And you have 2 solutions:
1. Use tomcat hooks. You can let a tomcat module manager the
TagHandlerPool and you'll get all the notifications you need. 
Just implement and TagPoolManagerInterceptor module, implement
the hooks you need ( addContext, contextInit, reload, etc).

2. Use some "hacks" in the generated init()/destroy().
For example, in init() you can use a context attribute ( TagPoolManager ),
if not set you'll create it and init, if it's set you just use it. 

> Am I off base, with my general strategy?

No, it is ok.
 
> Also, regarding 3.x and 4.x, I'd like to keep it usable / adaptable
> to all.  We're currently using 3, but will eventually migrate to 4.

4.x also have a mechanism to notify you about events - either a 2.3 filter
or use the internal Listener interfaces, and most decent servlet
containers will provide such a mechanism.

As long as you keep a simple interface to your tag pool, it should be easy
to write the container-specific adapter that will plug it in.


Costin




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

RE: where to plug-in startup/shutdown knowledge for internal tomcat components

[Casey Lucas]

Costin,

Thanks for the information, but because I'm still new to the tomcat
code base, I'm a bit confused.

Maybe it will help if I explain a little more about what I was playing
around with:

1. Add a few classes (pooling interfaces/implementation) to jasper.runtime
package so that rendered jsp's could use them.

2. Change Jasper to render code to use tag pooling.  This means changes
to ...jasper.compiler.JspParseEventListener and maybe a couple of 
additional  jasper.compiler.*Generator classes that would render
tag pooling specific stuff.

Given these assumptions:
  - org.apache.jasper.runtime.TagHandlerPool is the interface that
specifies tag pooling.
  - org.apache.jasper.runtime.TagHandlerPoolManager is the interface that
allows different pooling strategies and gives out TagHandlerPools
  - poolForTagX will be some better _jspx_... generated name.
  - "pool name for tagX" will be some unique name (per reuse scope -
taking into account attributes, tld, etc.)
  - TagHandlerX is substituted for the tld specified tag handler

The new rendered code could look something like:

public class _0002ftestdocs_0002fquestions_0002ejspquestions_jsp_4 extends HttpJspBase 
{

static {
}

// 2 lines below are new.
private TagHandlerPool poolForTag1;
private TagHandlerPool poolForTag2;

public _0002ftestdocs_0002fquestions_0002ejspquestions_jsp_4( ) {
   // 2 lines below new.  assume that TagHandler1 and TagHandler2 are
   // tag handler classes (from tld)
   poolForTag1 = TagHandlerPoolManager.getDefaultManager().
   getPool("pool name for tag1", TagHandler1.class);
   poolForTag2 = TagHandlerPoolManager.getDefaultManager().
   getPool("pool name for tag2", TagHandler2.class);
}

private static boolean _jspx_inited = false;

public final void _jspx_init() throws JasperException {
}

public void _jspService(HttpServletRequest request, HttpServletResponse  response)
throws IOException, ServletException {

 end of code 

Then inside of _jspService, code would be rendered to use the appropriate "poolForTagX"
object to get/release tag handlers.


So, given all that, I need to control lifetime of TagHandlerPoolManager's
default instance.  By controlling it, I can have one TagHandlerPoolManager
instance per web application and when the web application gets unloaded,
all the Tag.release methods can be called.  Aren't the JspServlet and
JspInterceptor mechanisms specific to an individual jsp file?  If so,
I don't think that's what I need because pooling will be for the entire
web application not a specific JSP.

I was hoping that when the web application (not individual jsp) is
loaded, unloaded, reloaded I could do the TagHandlerPoolManager initialization
and cleanup tasks.  Maybe I'm making things too complicated.  Should
managing the lifetime of a per-web-application object like
TagHandlerPoolManager be simpler?

Am I off base, with my general strategy?

Also, regarding 3.x and 4.x, I'd like to keep it usable / adaptable
to all.  We're currently using 3, but will eventually migrate to 4.

thanks.
-Casey


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 09, 2001 11:48 AM
> To: [EMAIL PROTECTED]
> Subject: Re: where to plug-in startup/shutdown knowledge for internal
> tomcat components
> 
> 
> Hi Casey,
> 
> This is a hard question :-)
> 
> The main decision you must make is that: 
> 
> Do you want to use JspServlet or JspInterceptor ?
> 
> The first solution ( using Jasper via JspServlet ) is what is used in
> tomcat 3.1, 3.2 and 4.0 - and it has the big advantage that the full
> Jasper in interfaced using a normal servlet. That means jasper can be used
> in any place where a servlet can be used, and integrating it into any
> servlet container should be trivial.
> 
> The second solution is used in tomcat 3.3 ( JspServlet is still
> supported). JspInterceptor is an adapter between tomcat 3.3 internals (
> i.e. the hooks provided to tomcat 3.3 modules ) and Jasper's APIs (
> Mangler, JspCompiler, etc). It works in the same way as JSPC - where a
> command-line interface to jasper is provided, with a lot of options.
> This is extremely flexible and gives you full access to all jasper's
> features, it allows a number of optimizations ( like avoiding the double
> redirection - JspServet->generated servlet), allows treating
> jsp-generated servlets as normal servlets ( i.e. absolutely no extra
> overhead or difference between a jsp and servlet after the compilation),
> and is much cleaner.
> 
> It is also possible to adapt jasper ( not as easy as with a servlet ) to
> other containers by writing an adapter between Jasper's APIs and the
> container's internal APIs. 
> 
> In any case, remember that Jasper-generated servlets can be used via JspC
> - i.e. pre-compiled into servlets, without any jsp-specific code (
> JspInterceptor acts like a runtime JspC ). So puttin

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

[marcsaeg]

marcsaeg01/03/09 10:52:21

  Modified:src/webpages Tag: tomcat_32 index.html
  Log:
  Fix path to the readme file.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.13.2.13 +1 -1  jakarta-tomcat/src/webpages/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/webpages/index.html,v
  retrieving revision 1.13.2.12
  retrieving revision 1.13.2.13
  diff -u -r1.13.2.12 -r1.13.2.13
  --- index.html2001/02/26 17:20:36 1.13.2.12
  +++ index.html2001/03/09 18:52:18 1.13.2.13
  @@ -38,7 +38,7 @@
   Packages
   
    
  -The README file, which can be found at /README, contains
  +The README file, which can be found at /doc/readme, contains
   a list of known bugs, incompatibilities and limitations.
   You can find more information about the Servlet and JSP technologies
   at:
  
  
  

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

cvs commit: jakarta-tomcat/src/doc readme

[marcsaeg]

marcsaeg01/03/09 10:51:43

  Modified:src/doc  Tag: tomcat_32 readme
  Log:
  More updates for the 3.2.2 release.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.8.2.14  +8 -22 jakarta-tomcat/src/doc/readme
  
  Index: readme
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/readme,v
  retrieving revision 1.8.2.13
  retrieving revision 1.8.2.14
  diff -u -r1.8.2.13 -r1.8.2.14
  --- readme2001/03/05 14:26:29 1.8.2.13
  +++ readme2001/03/09 18:51:40 1.8.2.14
  @@ -1,4 +1,4 @@
  -$Id: readme,v 1.8.2.13 2001/03/05 14:26:29 marcsaeg Exp $
  +$Id: readme,v 1.8.2.14 2001/03/09 18:51:40 marcsaeg Exp $
   
   Release Notes for:
  
  @@ -14,7 +14,7 @@
   4.  Tomcat: Past, Present, and Future
   5.  New Features In This Release
   6.  Known Bugs and Issues
  -7.  Security Vulnerabilities Fixed in 3.2.1
  +7.  Fixes and Enhancements in Updates
   
   
   =
  @@ -30,17 +30,10 @@
   You should read the License Agreement (in the LICENSE file of the top level
   directory), which applies to all software included in this release.
   
  -Tomcat Version 3.2.1 is a security related update!  See Section 7, below,
  -for details on the changes that have been made.  All other existing issues with
  -Tomcat 3.2 will remain in 3.2.1 -- they will be addressed in subsequent
  -maintenance updates (3.2.2, and so on).
  -
  -No changes to the native code components of Tomcat 3.2 have been made.
  -Therefore, you should *not* need to recompile components such as mod_jserv
  -in order to take advantage of this release.  You only need to replace the
  -Java based modules in the "jakarta-tomcat-3.2.*" distribution.
  +Tomcat Version 3.2.2 is a bug fix release.  No new features have been
  +added in this release.  The bugs known to be fixed in Version 3.2.2
  +are described in section 7.1 below.
   
  -
   =
   2.  INSTALLING AND RUNNING TOMCAT
   
  @@ -88,16 +81,8 @@
   
   =
   5.  NEW FEATURES IN THIS RELEASE
  -
  -Tomcat 3.2.1 is a maintenance and bug fix release, based on the Tomcat 3.2
  -(final) code base.  The following changes are included:
  -
  -- Disallowed requesting JSP pages under the WEB-INF directory
  -  (/WEB-INF/dummy.jsp).  Previously, only requests for static files
  -  were being disallowed.
   
  -- The JDBCRealm request interceptor will now log the description of any
  -  JDBC exception that occurs, to aid in debugging.
  +Tomcat Version 3.2.2 is a bug release only.  No new features were added.
   
   
   =
  @@ -318,6 +303,8 @@
 -  Better initialization of psuedo-random number generator improves
response time for first request that generates a session.
 -  Fix session tracking through forward().  (#504)
  +  -  Fix problem with getSession() overwritting the requested session ID
  + and related URL rewritting problems.  (#160)
   
   Jasper
 -  Fix for UnsupportedEncodingException due to UTF8 instead of UTF-8.  (#269)
  @@ -330,7 +317,6 @@
 -  Better error reporting if compile fails due to missing tag library.
 -  Fix thread synchronization problem that can cause page compilation to 
fail (#44).
  -  
   
   Connectors
 -  Fix infinite loop on invalid content-length for ajp12.  (#264)
  
  
  

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

Re: where to plug-in startup/shutdown knowledge for internal tomcatcomponents

[cmanolache]

Hi Casey,

This is a hard question :-)

The main decision you must make is that: 

Do you want to use JspServlet or JspInterceptor ?

The first solution ( using Jasper via JspServlet ) is what is used in
tomcat 3.1, 3.2 and 4.0 - and it has the big advantage that the full
Jasper in interfaced using a normal servlet. That means jasper can be used
in any place where a servlet can be used, and integrating it into any
servlet container should be trivial.

The second solution is used in tomcat 3.3 ( JspServlet is still
supported). JspInterceptor is an adapter between tomcat 3.3 internals (
i.e. the hooks provided to tomcat 3.3 modules ) and Jasper's APIs (
Mangler, JspCompiler, etc). It works in the same way as JSPC - where a
command-line interface to jasper is provided, with a lot of options.
This is extremely flexible and gives you full access to all jasper's
features, it allows a number of optimizations ( like avoiding the double
redirection - JspServet->generated servlet), allows treating
jsp-generated servlets as normal servlets ( i.e. absolutely no extra
overhead or difference between a jsp and servlet after the compilation),
and is much cleaner.

It is also possible to adapt jasper ( not as easy as with a servlet ) to
other containers by writing an adapter between Jasper's APIs and the
container's internal APIs. 

In any case, remember that Jasper-generated servlets can be used via JspC
- i.e. pre-compiled into servlets, without any jsp-specific code (
JspInterceptor acts like a runtime JspC ). So putting your code into
JspServlet will be a bad choice. 

One way is to use tomcat3.3 hooks ( contextInit, reload, 
requestMap, pre/postRequest, etc ), and eventually take advantage of the
 per/request ( and thread ) and per context storage ( in 3.3, each Thread
has it's own set of Request/Response - so request notes are equivalent
with per thread data ). 

The other way is to do tricks in the generated servlet. For example
on init() you can check a context attribute, and if not set you can do the
context initialization and set the attribute. As long as you use
"global" objects, reloading shouldn't affect you. You can use jasper
runtime object to put the common code, so the generated code will remain
small. 

Both solutions have advantages - and it's even possible to do a
mix. 

My recomandation - just use a SimplePool, implement the "real" code ( tag
pooling ), without worry about how the pool will look like or will be
hooked. After this works, we'll find a solution ( or 2 ) for this issue. 

 
Costin


On Fri, 9 Mar 2001, Casey Lucas wrote:

> 
> I'm doing some prototyping for tag pooling in tomcat (based on
> the 3.3 tree.)  I'd like to implement tag handler pooling
> per web application.  Can someone point me to where I can
> hook into in order to setup the internal pool stuff when
> each web application starts, stop, reloads, etc.?
> 
> I need to do things like setup the pooling strategy
> when each web application starts and release all the tag
> handlers when the application shuts down.
> 
> Sorry if this is a dumb question, but hopefully someone
> can save me a lot of time.
> 
> thanks.
> 
> -Casey
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 


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

beginners question

[JeremyRayYoo]

Hi I want to know how do you execute servlets on tomcat. I tried:
bin\tomcat.bat ant -f  -location of servlet- client- --and I get a 
message saying that it is not an xml file. How do you execute an .html 
servlet file. Do you have to first compile it first??

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

where to plug-in startup/shutdown knowledge for internal tomcat components

[Casey Lucas]

I'm doing some prototyping for tag pooling in tomcat (based on
the 3.3 tree.)  I'd like to implement tag handler pooling
per web application.  Can someone point me to where I can
hook into in order to setup the internal pool stuff when
each web application starts, stop, reloads, etc.?

I need to do things like setup the pooling strategy
when each web application starts and release all the tag
handlers when the application shuts down.

Sorry if this is a dumb question, but hopefully someone
can save me a lot of time.

thanks.

-Casey

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

Implementation in 4.0.b1

[tttye]

I am trying to obtain a remote reference to an EJB in another machine.  
I have set the ejb-ref in web.xml as follows:
 
Sample bean generated by coolgen placed here for ease of
 early testing
ejb/S_STRESS_32K
Session
cool.models.coop07.java.S_STRESS_32KpsHome
cool.models.coop07.java.S_STRESS_32Kps
jndi:/ttt1.ca.com:1099/S_STRESS_32Kps

However, when I do ctx.lookup("java:/comp/ejb/S_STRESS_32K") I get a null
reference instead of the necessary remote reference to the home interface.
Is ejb-link implemented and documented?
Which code is involved in ejb-link lookup?
Is this fixed in the latest 4.0?

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

Re: beginners question

[Casper Gjerris]

Hi Jeremy,

Please use [EMAIL PROTECTED] 
instead of [EMAIL PROTECTED] 

I believe you are using the wrong mailing list.

/Casper

- Original Message - 
From: <[EMAIL PROTECTED]>


> Hi I want to know how do you execute servlets on tomcat. I tried:
> bin\tomcat.bat ant -f  -location of servlet- client- --and I get a 
> message saying that it is not an xml file. How do you execute an .html 
> servlet file. Do you have to first compile it first??
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 



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

RE: please help

[Lin, Raymond]

Look at your DOS user's guide, you need more space for environment
variables.

Raymond

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 09, 2001 11:07 AM
To: [EMAIL PROTECTED]
Subject: Re: please help


you mean in my config.sys I have to add it just like this

shell=C:\command.com (now do I skip a line or put a semicolon between these 
two)  c:Vp/e:32  -why does this one have a from slash after Vp??? Is

it a typo What exactly is this and why wasn't it mentioned in the 
user guide?

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



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

Auth/Az for tomcat using xml standards!

[Falcon cheetah]

Regards,
I came across this site that is pitching a standard for e-commerce security using xml. Please take a look at 
http://www.s2ml.org and see if it can help in the development of a more robust tomcat auth/az system.
 
Ahmed.Do You Yahoo!?
Yahoo! Mail Personal Address - 
Get email at your own domain with Yahoo! Mail.

Re: please help

[JeremyRayYoo]

you mean in my config.sys I have to add it just like this

shell=C:\command.com (now do I skip a line or put a semicolon between these 
two)  c:Vp/e:32  -why does this one have a from slash after Vp??? Is 
it a typo What exactly is this and why wasn't it mentioned in the 
user guide?

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

RE: FW: problem w/ ajp13 - if Tomcat is shutdown

[GOMEZ Henri]

La prise de conscience de votre propre ignorance est un grand pas vers la
connaissance.
-- Benjamin Disraeli
 

>-Original Message-
>From: Dan Milstein [mailto:[EMAIL PROTECTED]]
>Sent: Friday, March 09, 2001 6:34 AM
>To: [EMAIL PROTECTED]
>Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown
>
>
>Henri,
>
>You say that checking errno isn't safe in a multithreaded env 
>(which would
>certainly makes sense to me, since it looks like a global var).
>
>However, after searching online, and reading up in 
>"Programming Threads", by
>Kleiman, Shah and Smaalders, I find on p. 47:
>
>"Each thread has its own independent version of the errno 
>variable.  This
>allows different threads to make system calls that may change 
>the value of errno without interfering with each other."
>They are describing Posix threads.  "errno" is actually a 
>macro, apparently, which accesses the correct, thread-specific errno
variable.

Right, I checked in Linux errno.h for pthread

>Now, I am the first to admit that I don't understand all the weird
>intersections between threads and sockets in C, but this looks 
>to me like checking errno against ECONNRESET may be fine.

More generally when you got a read error on TCP/IP stream
you could consider that the link to your server (tomcat) is broken :

- no more route to tomcat (broken lan or routers)
- server not working (tomcat was stopped or server restarted)

>Are there platforms where that's not true? 

I've no idea but we migth have problems in differents interpretation
of platform.

>The nice thing about getting that ECONNRESET error, is it lets 
>us go ahead and close out that connection, and try another one.  

Done.

>We could even close out a whole cache of connections, 
>which would most likely be the right thing to do.  

Good idea, I'll find how to do that.

>If we loop/retry, than how do we know to close the connection?



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

RE: FW: problem w/ ajp13 - if Tomcat is shutdown

[GOMEZ Henri]

Here how we could do :


>Okay, I basically agree with you. I'll take out 
>the check for errno and just have recv() == -1 
>be considered a recoverable error (i.e: retry it). 
>However, I disagree with making the retry in a 
>loop for RETRIES times. This is because if one 
>retry fails, this means this error condition may 
>not be recoverable without any human interventions. 

We must retry against eventual other workers in a
LoadBalancing system. I must verify that my patch
allow that.

>What is the point of retrying more than once? 

No problem, I'll retry 3 times. It's a special
case, exception, so we could spend some time to
re-establish the connection to a working unit.

>My goal is not to wait for TC to come back up 
>or to wait for TC to be in a good state. My goal 
>is, if TC is in a good state already, why tell 
>the caller that it's an error. 

+1

>Opinions? 

I agree, with the new version you could see that we try
X time to send the request. It wasn't the case previously
which make me think that load-balancing was only working
on active server, but failed completly when one of then
was stopped.

We 


 jk_ajp13_worker.c.diff

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

TOMCAT4.0 and REGEXP for CVS

[jean-frederic clere]

Hi,

I have noted that jakarta-regexp from CVS produces
jakarta-regexp-1.3-dev.jar.
But catalina/build.xml expects jakarta-regexp-1.2.jar...

A note it the README telling that TOMCAT4.0 requires jakarta-regexp-1.2
will not be bad.

Cheers

Jean-frederic

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