Réf. : RE: Proposal for Compression Filter example

[JULE, Nicolas - DSIA]

De :Craig R. McClanahan@craigmcc le 20/03/2001 23:31
Pour :  tomcat-dev@[EMAIL PROTECTED]@SMTP@Hays Hub
cc : 
Faxer à:
Objet : RE: Proposal for Compression Filter example



On Tue, 20 Mar 2001, GOMEZ Henri wrote:

> >I created an example web application using Filter technology 
> >and would like to 
> >add to Tomcat 4 example webapps.  This example includes Data 
> >Compression Filter 
> >which compresses ServletResponse according to the threshold 
> >that can be set by 
> >users.  I think it'll be a good example usage of filters.
> >
> >What do you think?
> 
> +1 (may be a module for 3.3 ?)
> 

| Anyone who wants to create a module for this kind of functionality
can, of
| course, do so.  The advantage of impementing it as a Filter is
that it
| will be portable to any 2.3 servlet container.

Both are really interesting, but another Advantage for Filter is
that it allow selective  compression (I hope it will !)
Systematic compression could break flows that are not destinated to
Browsers, but other Applications
using HTTP as a Tunnel, in backend of the HTTPServer.


Nicolas

> I also recommand you to take a look at mod_gzip which
> done that beautifully 
> 
> http://www.remotecommunications.com/apache/mod_gzip/
> 

Craig




**
Ce message électronique et tous les fichiers attachés qu'il contient
sont confidentiels et destinés exclusivement à l'usage de la personne
à laquelle ils sont adressés. Si vous avez reçu ce message par erreur,
merci de le retourner à son émetteur. Les idées et opinions présentées
dans ce messages sont celles de son auteur, et ne représentent pas
nécessairement celles du Groupe HAYS plc ou d'une quelconque de ses filiales.
La publication, l'usage, la distribution, l'impression ou la copie non
autorisée de ce message et des attachements qu'il contient sont strictement
interdits.

Nous vous informons également que nous avons vérifié l'absence de virus dans
ce message mais que, malgré ce contrôle, nous ne saurions être tenus pour
responsables d'éventuels dégâts occasionnés par un virus non détecté.

This e-mail and any attached files are confidential and intended
solely for the use of the individual to whom it is addressed. If you have
received this email in error please send it back to the person that sent it
to you. Any views or opinions presented are solely those of author and
do not necessarily represent those the HAYS plc group or any of its subsidiary
companies. Unauthorized publication, use, dissemination, forwarding, printing
or copying of this email and its associated attachments is strictly prohibited.

We also inform you that we have checked that this message does not contain
any virus but we decline any responsability in case of any damage caused
by an a non detected virus.

**

Re: FYI: Tomcat 4.0 Release Planning Futures

[James Duncan Davidson]

> This membership position gives ASF (and the open source developers that
> ASF represents) a powerful voice in shaping the future of the Java
> platform.  In addition, however, it imposes responsibilities to follow 
> the
> rules of the Java Community Process -- the same rules that software
> vendors creating products based on these specifications must follow.

Actually, it's not the fact that the ASF is part of the JCP that makes 
us follow that. The restrictions are placed on anybody who uses the spec 
by the spec license on the back front page. This means that anybody 
implementing servlets is required, by "accepting" that license to follow 
it. At least the way the license is designed.

Do not assume that I agree with the way things are -- I'm just reporting 
my understanding of the way things are set up.

.duncan

Re: NullPointerException from HttpSessionFacade.invalidate()

[Greg Brouelette]

I've been lurking and searching through the archives searching for an
answer to the issue which was eventually reported as bug #739   I've
found some excellent descriptions of the problem but have been unable to
discover a solution in the archives.  I was hoping that someone can
point me towards a workaround.

Essentially we've written an app server that runs process on different
threads.  These threads all have access to an object which I'll just
call an Mcache object.   Part of the MCache is a hash table so when we
pass the Mcache a session ID it returns that particular session.  As is
standard procedure when dealing with servlets we are saving data that
must be available for the life of the session in the session object
(which is now actually an HttpSessionFacade object).

The problem of course is that I need to call setAttribute and
getAttribute on this session.  And when I do this I have to expect that
the session that the Mcache object refers to by a particular sessionID
is the same object at all times.  However, it seems that any particular
HttpSessionFacade may wrap any particular HttpSession, or even a null if
that facade has been recycled.  Obviously, when we create a session or
get a session or do any of the things which are standard operating
procedure with sessions we would not expect a particular instance of
that session to suddenly change, or even suddenly become null.  This is
not standard behavior of a java.servlet.http.HttpSession and I would not
expect the facade to do so either.

So there must be some workaround.  Because if all my sessions are being
wrapped with HttpSessionFacade against my will, and those facades will
change or nullify themselves against my will then we're basically saying
"If you use Tomcat you can't use a session object because we can no
longer guarantee that your session objects will even exist when you need
them".

This is obviously not what the Tomcat team intended.  So there must be a
way for me to get my session back based on a session ID that I have
saved in my Mcache.  What would be the correct procedure for getting the
HttpSessionFacade that refers to an instance of a
java.servlet.http.HttpSession  that has a particular sessionID ?

I thank you in advance for you assistance.

Greg

Using Jikes instead of JavaC with Tomcat/Jasper

[Yair Zadik]

I've been trying to get Tomcat to use Jikes instead of javac
as its Java compiler for JSP pages.  All the information I've
found says to edit the conf/web.xml file.  As far as I could
tell, this did nothing, so I poked around the sources.
According to 'WebXmlReader.java' (in 3.2.1):

// We may read a "default" web.xml from INSTALL/conf/web.xml -
// the code is commented out right now because we want to
// consolidate the config in server.xml ( or API calls ),
// we may put it back for 3.2 if needed.
// note that web.xml have to be cleaned up - only diff from
// default should be inside
// readDefaultWebXml( ctx );

so it appears that conf/web.xml is no longer read.  However,
adding 

  

  jsp


  org.apache.jasper.servlet.JspServlet


jspCompilerPlugin
org.apache.jasper.orgpiler.JikesJavaCompiler


-2147483646

  

  
  
jsp
  
  
*.jsp
  
  

(basically, the jsp servlet definition and mapping from conf/web.xml) into
my webapp's 'web.xml' file seems to do the trick.

Is there a way of doing this now without altering my webapp?  I'd like to
make this mapping the default rather then the standard JavaC mapping.  Does
this require writing a WebXmlReader replacement?

Yair

Re: JSPC on Windows (RE: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler ParserController.java)

[horwat]

The inline patch you sent along with the patch I'm including would also fix
Bugzilla #412.

Justy


> Justyna,
>
> Would this update also fix Bugzilla 412?
>
> Marc Saegesser
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 14, 2001 6:32 PM
> > To: [EMAIL PROTECTED]
> > Subject: cvs commit:
> > jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler
> > ParserController.java
> >
> >
> > horwat  01/03/14 16:31:41
> >
> >   Modified:jasper/src/share/org/apache/jasper/compiler
> > ParserController.java
> >   Log:
> >   Bug Fix: jspc didn't work well under windows since file
> > separator assumed to be "/" in ParserController.resolveFileName
> >
> >   Bugzilla: #821 & #487
> >
> >   Revision  ChangesPath
> >   1.10  +2 -2
> > jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Par
> serController.java
> >
> >   Index: ParserController.java
> >   ===
> >   RCS file:
> > /home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/co
> mpiler/ParserController.java,v
> >   retrieving revision 1.9
> >   retrieving revision 1.10
> >   diff -u -r1.9 -r1.10
> >   --- ParserController.java 2000/12/22 18:37:39 1.9
> >   +++ ParserController.java 2001/03/15 00:31:41 1.10
> >   @@ -417,12 +417,12 @@
> > * baseDirStack.
> > */
> >private String resolveFileName(String inFileName) {
> >   -boolean isAbsolute = inFileName.startsWith("/");
> >   +boolean isAbsolute = inFileName.startsWith(File.separator);
> >String fileName =
> >isAbsolute ?
> >inFileName : (String)baseDirStack.peek() + inFileName;
> >String baseDir =
> >   - inFileName.substring(0, inFileName.lastIndexOf("/") + 1);
> >   + inFileName.substring(0,
> > inFileName.lastIndexOf(File.separator) + 1);
> >baseDirStack.push(baseDir);
> >return fileName;
> >}
> >
> >
> >
>



horwat  01/03/15 14:42:15

  Modified:jasper/src/share/org/apache/jasper/compiler
ParserController.java
  Log:
  On a windows system need to convert filepath to match file separator.
  
  Revision  ChangesPath
  1.11  +3 -2  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java
  
  Index: ParserController.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- ParserController.java 2001/03/15 00:31:41 1.10
  +++ ParserController.java 2001/03/15 22:42:12 1.11
  @@ -417,12 +417,13 @@
* baseDirStack.
*/
   private String resolveFileName(String inFileName) {
  -boolean isAbsolute = inFileName.startsWith(File.separator);
  + File file = new File(inFileName);
  +boolean isAbsolute = file.getPath().startsWith(File.separator);
String fileName = 
isAbsolute ?
inFileName : (String)baseDirStack.peek() + inFileName;
String baseDir = 
  - inFileName.substring(0, inFileName.lastIndexOf(File.separator) + 1);
  + inFileName.substring(0, file.getPath().lastIndexOf(File.separator) + 1);
baseDirStack.push(baseDir);
return fileName;
   }
  
  
  

Re: TOMCAT 4.x SSI Status

[Bip Thelin]

Attached is the latest SSI package, it's not heavily tested. It supports expiration on
the SSI page and buffering. Check below how to use it also ook below on what's 
implemented
and what's not. Amy, check the files and mail me and we can decide how to work on the
package towards a "stable" release.

BTW; Anyone know where to buy those old pimp-ass Kung Fu movies in San Francisco?
I'm talking about stuff like: 36chambers, Chess Boxing, 5 deadly Venoms, Wu-tang.

Cheers, Bip

---

::: Implemented / Not implemented
#+Echo
#Config
*errmsg
*sizefmt
timefmt
#@Fsize
flastmod
exec
#@include

* == fully supported.
# == partly supported.
@ == virtual directive not supported.
+ == Missing enviromental variables: 
DOCUMENT_NAME: The current filename. 
DOCUMENT_URI: The virtual path to this document (such as /docs/tutorials/foo.shtml). 
QUERY_STRING_UNESCAPED: The unescaped version of any search query the client sent, 
with all shell-special characters escaped with \. 
DATE_LOCAL: The current date, local time zone. Subject to the timefmt parameter to the 
config command. 
DATE_GMT: Same as DATE_LOCAL but in Greenwich mean time. 
LAST_MODIFIED: The last modification date of the current document. Subject to timefmt 
like the others. 


::: To use add the following to your web.xml:
8<--

ssi
org.apache.catalina.servlets.SsiInvokerServlet


debug
1



expires
666



buffered
1

5



ssi
*.shtml

8<--

[Fwd: Re: TOMCAT 4.x SSI Status]

[Bip Thelin]

And here's the file I proMISSED.

..bip

 Original Message 
Subject: Re: TOMCAT 4.x SSI Status
Date: Tue, 20 Mar 2001 17:20:30 -0800
From: Bip Thelin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: Razorfish
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Attached is the latest SSI package, it's not heavily tested. It supports expiration on
the SSI page and buffering. Check below how to use it also ook below on what's 
implemented
and what's not. Amy, check the files and mail me and we can decide how to work on the
package towards a "stable" release.

BTW; Anyone know where to buy those old pimp-ass Kung Fu movies in San Francisco?
I'm talking about stuff like: 36chambers, Chess Boxing, 5 deadly Venoms, Wu-tang.

Cheers, Bip

---

::: Implemented / Not implemented
#+Echo
#Config
*errmsg
*sizefmt
timefmt
#@Fsize
flastmod
exec
#@include

* == fully supported.
# == partly supported.
@ == virtual directive not supported.
+ == Missing enviromental variables: 
DOCUMENT_NAME: The current filename. 
DOCUMENT_URI: The virtual path to this document (such as /docs/tutorials/foo.shtml). 
QUERY_STRING_UNESCAPED: The unescaped version of any search query the client sent, 
with all shell-special characters escaped with \. 
DATE_LOCAL: The current date, local time zone. Subject to the timefmt parameter to the 
config command. 
DATE_GMT: Same as DATE_LOCAL but in Greenwich mean time. 
LAST_MODIFIED: The last modification date of the current document. Subject to timefmt 
like the others. 


::: To use add the following to your web.xml:
8<--

ssi
org.apache.catalina.servlets.SsiInvokerServlet


debug
1



expires
666



buffered
1

5



ssi
*.shtml

8<--

 tomcat-4.x.SSI.zip

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

[glenn]

glenn   01/03/21 04:36:57

  Modified:jasper/src/share/org/apache/jasper Constants.java
  Log:
  The classpath needed by javac is now built dynamically by using getURLs
  on the Context URLClassLoader and all its parent class loaders except
  for the system class loader.  This removes the need to pass a context
  attribute for the classpath between Tomcat and Jasper.
  
  This also fixed a problem with a bad class path element due to
  Jasper not understanding jndi named URL's.
  
  Revision  ChangesPath
  1.9   +0 -9  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/Constants.java
  
  Index: Constants.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/Constants.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- Constants.java2001/02/08 13:37:08 1.8
  +++ Constants.java2001/03/21 12:36:51 1.9
  @@ -104,15 +104,6 @@
* Other servlet engines can choose to have this attribute if they 
* want to have this JSP engine running on them. 
*/
  -//public static final String SERVLET_CLASSPATH = 
"org.apache.tomcat.jsp_classpath";
  -public static final String SERVLET_CLASSPATH = 
"org.apache.catalina.jsp_classpath";
  -
  -/**
  - * FIXME
  - * ServletContext attribute for classpath. This is tomcat specific. 
  - * Other servlet engines can choose to have this attribute if they 
  - * want to have this JSP engine running on them. 
  - */
   //public static final String SERVLET_CLASS_LOADER = 
"org.apache.tomcat.classloader";
   public static final String SERVLET_CLASS_LOADER = 
"org.apache.catalina.classloader";
   
  
  
  

FW: missing file

[Pier P. Fumagalli]

Not Acked... :)

Pier (freezing his butt in Dublin)

-- 

Pier Fumagalli    

-- Forwarded Message
> From: "Curt Siffert" <[EMAIL PROTECTED]>
> Date: Tue, 20 Mar 2001 23:11:53 -0800
> To: <[EMAIL PROTECTED]>
> Subject: missing file
> 
> 
> I apologize if this is my mistake, but I am just learning.
> 
> In the release bundle for jakarta3.2.1, the examples
> directory for jsp seems to point to a file on your server
> that isn't there.  Can you add it back in or let me know
> what the location should be?
> 
> /webapps/examples/jsp/source.jsp:
> <%@ taglib uri="http://java.apache.org/tomcat/examples-taglib" prefix="eg"
> %>
> 
> (etc)
> 
> I get an error every time I try and run the servlet.
> 
> Thanks,
> Curt Siffert
> 

-- End of Forwarded Message

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

[glenn]

glenn   01/03/21 04:37:29

  Modified:jasper/src/share/org/apache/jasper JspEngineContext.java
  Log:
  The classpath needed by javac is now built dynamically by using getURLs
  on the Context URLClassLoader and all its parent class loaders except
  for the system class loader.  This removes the need to pass a context
  attribute for the classpath between Tomcat and Jasper.
  
  This also fixed a problem with a bad class path element due to
  Jasper not understanding jndi named URL's.
  
  Revision  ChangesPath
  1.6   +33 -6 
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspEngineContext.java
  
  Index: JspEngineContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspEngineContext.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- JspEngineContext.java 2001/02/08 13:37:27 1.5
  +++ JspEngineContext.java 2001/03/21 12:37:20 1.6
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspEngineContext.java,v
 1.5 2001/02/08 13:37:27 glenn Exp $
  - * $Revision: 1.5 $
  - * $Date: 2001/02/08 13:37:27 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspEngineContext.java,v
 1.6 2001/03/21 12:37:20 glenn Exp $
  + * $Revision: 1.6 $
  + * $Date: 2001/03/21 12:37:20 $
*
* 
* 
  @@ -145,17 +145,44 @@
   
   /**
* The classpath that is passed off to the Java compiler. 
  + *
  + * Uses the URLClassLoader getURLs to build the classpath
  + * for the Context ClassLoader and all parent
  + * ClassLoader's except for the system class loader.
*/
   public String getClassPath() {
  +StringBuffer cpath = new StringBuffer();
  + ClassLoader cl = loader;
  + while( cl != null && cl.getParent() != null ) {
  + if( (cl instanceof URLClassLoader) ) {
  + cpath.append(getClassLoaderPaths((URLClassLoader)cl));
  + }
  + cl = cl.getParent();
  + }
  +return cpath.toString() + classpath;
  +}
  +
  +/**
  + * The classpaths for a URLClassLoader
  + */
  +private String getClassLoaderPaths(URLClassLoader loader) {
URL [] urls = loader.getURLs();
   StringBuffer cpath = new StringBuffer();
   String sep = System.getProperty("path.separator");
   
   for(int i = 0; i < urls.length; i++) {
  -cpath.append((String)urls[i].getFile()+sep);
  + String file = null;
  + String url = urls[i].toString();
  + if( url.startsWith("jndi:") ) {
  + file = getRealPath(url.substring(5));
  + } else if( url.startsWith("jar:jndi:") ) {
  + file = getRealPath(url.substring(9,url.length()-2));
  + } else {
  + file = (String)urls[i].getFile();
  + }
  +cpath.append(file + sep);
   }
  - 
  -return cpath.toString() + classpath;
  +return cpath.toString();
   }
   
   /**
  
  
  

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

[glenn]

glenn   01/03/21 04:38:03

  Modified:jasper/src/share/org/apache/jasper/servlet JspServlet.java
  Log:
  The classpath needed by javac is now built dynamically by using getURLs
  on the Context URLClassLoader and all its parent class loaders except
  for the system class loader.  This removes the need to pass a context
  attribute for the classpath between Tomcat and Jasper.
  
  This also fixed a problem with a bad class path element due to
  Jasper not understanding jndi named URL's.
  
  Revision  ChangesPath
  1.15  +4 -21 
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet/JspServlet.java
  
  Index: JspServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet/JspServlet.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- JspServlet.java   2001/02/28 22:05:52 1.14
  +++ JspServlet.java   2001/03/21 12:37:55 1.15
  @@ -150,27 +150,10 @@
private void loadIfNecessary(HttpServletRequest req, HttpServletResponse res) 
   throws JasperException, ServletException, FileNotFoundException 
   {
  -// First try context attribute; if that fails then use the 
  -// classpath init parameter. 
  -
  -// Should I try to concatenate them if both are non-null?
  -
  -String cp = (String) context.getAttribute(Constants.SERVLET_CLASSPATH);
  -
  -String accordingto;
  -
  -if (cp == null || cp.equals("")) {
  -accordingto = "according to the init parameter";
  -cp = options.getClassPath();
  -} else 
  -accordingto = "according to the Servlet Engine";
  -
  -Constants.message("jsp.message.cp_is", 
  -  new Object[] { 
  -  accordingto,
  -  cp == null ? "" : cp
  -  }, 
  -  Logger.INFORMATION);
  + // Get the classpath init parameter
  +String cp = options.getClassPath();
  + if( cp == null )
  + cp = "";
   
   if (loadJSP(jspUri, cp, isErrorPage, req, res) 
   || theServlet == null) {
  
  
  

Re: Proposal for Compression Filter example

[Pier P. Fumagalli]

Amy Roh <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> I created an example web application using Filter technology and would like to
> add to Tomcat 4 example webapps.  This example includes Data Compression
> Filter 
> which compresses ServletResponse according to the threshold that can be set by
> users.  I think it'll be a good example usage of filters.
> 
> What do you think?

Like it... CVS commit it :)

Pier (freezing his butt in Dublin)

-- 

Pier Fumagalli    

Tomcat 3.2.1 Scalability

[Claude LALYRE]

Hello,

I downloaded the release build Tomcat 3.2.1
in order to develop a tiny Webmail application
based on JSP technology.

I tested it with 20 connections, it was working
fine. But with 150 connections, the tomcat server
shutdown.

So I do think that it should interesting to
improve Tomcat scalability.


Best regards.


Claude LALYRE
Internet Mail Developer
Research & Development
X and Mail PARIS
Phone: (33) 01 48 36 89 03
Fax  : (33) 01 48 36 43 77

http://www.xandmail.com
http://demo.xandmail.com/XWebMailV2

Re: mod_webapp status?

[jean-frederic clere]

"Eric L. Anderson" wrote:
> 
> What is the current status of mod_webapp? I have tried building the connector
> from cvs but the build fails with webapplib. The errors seem to indicate there
> are some missing source files.
> 
> wa.c:69: `wa_connections' undeclared (first use in this function)
> wa.c:69: (Each undeclared identifier is reported only once
> wa.c:69: for each function it appears in.)
> wa.c:72: `cb' undeclared (first use in this function)
> wa.c:73: `wa_callbacks' undeclared (first use in this function)
> 
> I can not find any trace of an actual definition of "wa_connections" in any
> of the source files.

? It is in "webapplib/wa_connection.c" 

>
> --
> Eric L. Anderson
> [EMAIL PROTECTED]

I have also problems with mod_webapp.

Pier has changed a lot of things, you will have to little.

Cheers

Jean-frederic

Re: mod_webapp status?

[Pier P. Fumagalli]

jean-frederic clere <[EMAIL PROTECTED]> wrote:

> "Eric L. Anderson" wrote:
>> 
>> What is the current status of mod_webapp? I have tried building the connector
>> from cvs but the build fails with webapplib. The errors seem to indicate
>> there
>> are some missing source files.
>> 
>> wa.c:69: `wa_connections' undeclared (first use in this function)
>> wa.c:69: (Each undeclared identifier is reported only once
>> wa.c:69: for each function it appears in.)
>> wa.c:72: `cb' undeclared (first use in this function)
>> wa.c:73: `wa_callbacks' undeclared (first use in this function)
>> 
>> I can not find any trace of an actual definition of "wa_connections" in any
>> of the source files.
> 
> ? It is in "webapplib/wa_connection.c"
> 
>> 
>> --
>> Eric L. Anderson
>> [EMAIL PROTECTED]
> 
> I have also problems with mod_webapp.
> 
> Pier has changed a lot of things, you will have to little.

I'm rewriting it using APR... As we speak...

Pier (under the snow in Dublin)

-- 

Pier Fumagalli    

RE: Using Jikes instead of JavaC with Tomcat/Jasper

[Larry Isaacs]

AFAIK, this is the only way to use Jikes in Tomcat 3.2.x,
unless you change the default in Jasper source and rebuild
Jasper.

In Tomcat 3.3, server.xml contains .
Adding javaCompiler="jikes" will enable Jikes.

Cheers,
Larry

> -Original Message-
> From: Yair Zadik [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 5:44 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Using Jikes instead of JavaC with Tomcat/Jasper
> 
> 
> 
> I've been trying to get Tomcat to use Jikes instead of javac
> as its Java compiler for JSP pages.  All the information I've
> found says to edit the conf/web.xml file.  As far as I could
> tell, this did nothing, so I poked around the sources.
> According to 'WebXmlReader.java' (in 3.2.1):
> 
>   // We may read a "default" web.xml from 
> INSTALL/conf/web.xml -
>   // the code is commented out right now because we want to
>   // consolidate the config in server.xml ( or API calls ),
>   // we may put it back for 3.2 if needed.
>   // note that web.xml have to be cleaned up - only diff from
>   // default should be inside
>   // readDefaultWebXml( ctx );
> 
> so it appears that conf/web.xml is no longer read.  However,
> adding 
> 
>   
> 
>   jsp
> 
> 
>   org.apache.jasper.servlet.JspServlet
> 
> 
> jspCompilerPlugin
> 
> org.apache.jasper.orgpiler.JikesJavaCompiler
> 
> 
> -2147483646
> 
>   
> 
>   
>   
> jsp
>   
>   
> *.jsp
>   
>   
> 
> (basically, the jsp servlet definition and mapping from 
> conf/web.xml) into
> my webapp's 'web.xml' file seems to do the trick.
> 
> Is there a way of doing this now without altering my webapp?  
> I'd like to
> make this mapping the default rather then the standard JavaC 
> mapping.  Does
> this require writing a WebXmlReader replacement?
> 
> Yair
> 

Re: Tomcat 4, webapp running from WAR file

[Glenn Nielsen]

Remy,

The ability to compile JSP pages directly from a WAR file without
unarchiving jar files and class files into a work directory will not
be possible until javac can use URL's instead of a file system classpath.
Those changes to javac will not be available for quite a while.

Until that time I think the Context path should exist so that
getRealPath(), getResource(), getPathTranslated() work for jar and
class files broken out into the work directory.

I have implemented a way to dynamically build the classpath needed
by javac using the URLClassLoader.getURLs() that works great in Jasper
except for web apps running from a war file because I can't find any
way to get the real system file path to the jar files or classes directory.
This allows decoupling of Jasper from Tomcat for the CLASSPATH attribute.

We can put comments in both Tomcat & Jasper that this can be removed once
javac supports URL's in addition to the classpath.

Regards,

Glenn

Remy Maucherat wrote:
> 
> Quoting Glenn Nielsen <[EMAIL PROTECTED]>:
> 
> > Is the ability to run from a WAR file directly without unarchiving it
> > into the webapps directory completely implemented?
> 
> No, I'm working on some fixes for Jasper (including one for the trace you
> included).
> 
> > Jasper gives me a null pointer when it tries to see if a JSP needs
> > to be recompiled in its Outdated method because getRealPath() returns
> > null,
> > getServletConfig().getServletContext().getRealPath(jspUri));
> 
> Here, it should use getServletConfig().getServletContext().getResource
> (jspUri).openConnection().getLastModified().
> 
> There are other places where Jasper will break because of over reliance on
> getRealPath() and getPathTranslated() (in both cases, the servlet container is
> allowed to return null, and will do so when there is no physical file on the
> filesystem).
> 
> Remy

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

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

[Mel Martinez]

--- [EMAIL PROTECTED] wrote:
> remm01/03/20 16:08:53
> 
>   Modified:   
> jasper/src/share/org/apache/jasper/compiler
> JspCompiler.java
> JspReader.java
> ParserController.java
> TagLibraryInfoImpl.java
>   Log:
>   - Jasper should run from WARs (or any other
> repository which provides a directory
> context to access it).
>   - All Watchdog 4 tests pass (servlets, JSP,
> JSP-XML).
>   - Of course, the classes and JARs are still
> extracted from the WAR until the
> compilation technology is updated (javac wants
> files :(( ).
>   

:-)  But javac doesn't have any reason to deal with
the contents of the WAR directly.  JSP 'files' read
out of the .war are being converted to .java files
stored in the working directory (i.e. /tmp or
wherever).  Javac just has to deal with the latter
files.

It should be possible to modify Jasper to work with an
unexpanded .war archive.  Not necessarily trivial, but
definitely possible, in principle, with no need for
new javac compilation tech.

Cheers,

Mel

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Re: mod_webapp status?

[Glenn Nielsen]

"Pier P. Fumagalli" wrote:
> 
> jean-frederic clere <[EMAIL PROTECTED]> wrote:
> 
> > "Eric L. Anderson" wrote:
> >>
> >> What is the current status of mod_webapp? I have tried building the connector
> >> from cvs but the build fails with webapplib. The errors seem to indicate
> >> there
> >> are some missing source files.
> >>
> >> wa.c:69: `wa_connections' undeclared (first use in this function)
> >> wa.c:69: (Each undeclared identifier is reported only once
> >> wa.c:69: for each function it appears in.)
> >> wa.c:72: `cb' undeclared (first use in this function)
> >> wa.c:73: `wa_callbacks' undeclared (first use in this function)
> >>
> >> I can not find any trace of an actual definition of "wa_connections" in any
> >> of the source files.
> >
> > ? It is in "webapplib/wa_connection.c"
> >
> >>
> >> --
> >> Eric L. Anderson
> >> [EMAIL PROTECTED]
> >
> > I have also problems with mod_webapp.
> >
> > Pier has changed a lot of things, you will have to little.
> 
> I'm rewriting it using APR... As we speak...
> 
> Pier (under the snow in Dublin)
> 

APR is for Apache 2.0, correct?  What about Apache 1.3?

What _is_ the status of mod_webapp/WARP, this is a critical componenet
for Tocmat 4.  Tomcat 4 is useless to me without an Apache connector.

Regards,

Glenn

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

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory EjbFactory.java

[tttye]

I am happy with this version of EjbFactory.  
Thanks, Tim Tye

[EMAIL PROTECTED] writes:

> remm01/03/20 15:17:37
> 
>   Modified:catalina/src/share/org/apache/naming/factory EjbFactory.java
>   Log:
>   - Comment out the type checking, as suggested by Tim Tye.
>   
>   Revision  ChangesPath
>   1.6   +10 -10
>jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java
>   

Re: Tomcat 3.2.1 Scalability

[cmanolache]

Hi Claude,

It would be great if you could help improve the 
scalability - it's a difficult task, and we need 
all the help we can get :-)

If tomcat shuts down with 150 threads I would suspect
it's a JVM problem - I did tests up to 200 threads.
It is slow - but that's a different issue ( 3.3 will be
faster ). 

Could you try to "debug" the problem - for example,
try with a different VM. What do you mean by "shutdown" ? 
Do you get a core dump ? Any report on the command line ?
Is it hunged ?

Costin

On Wed, 21 Mar 2001, Claude LALYRE wrote:

> Hello,
> 
> I downloaded the release build Tomcat 3.2.1
> in order to develop a tiny Webmail application
> based on JSP technology.
> 
> I tested it with 20 connections, it was working
> fine. But with 150 connections, the tomcat server
> shutdown.
> 
> So I do think that it should interesting to
> improve Tomcat scalability.
> 
> 
> Best regards.
> 
> 
> Claude LALYRE
> Internet Mail Developer
> Research & Development
> X and Mail PARIS
> Phone: (33) 01 48 36 89 03
> Fax  : (33) 01 48 36 43 77
> 
> http://www.xandmail.com
> http://demo.xandmail.com/XWebMailV2
> 
> 
> 

to trim or not to trim (was Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util FileUtil.java)

[Arieh Markel]

> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> list-help: 
> list-unsubscribe: 
> list-post: 
> Delivered-To: mailing list [EMAIL PROTECTED]
> From: Yoshiyuki Karezaki <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util 
FileUtil.java
> User-Agent: Wanderlust/2.4.1 (Stand By Me) Emacs/20.4 Mule/4.1 (AOI)
> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
> 
> Hi arieh,
> 
> In article ,
>   [EMAIL PROTECTED] wrote:
> |public static String patch(String path) {
> |   - String patchPath = path;
> |   + String patchPath = path.trim();
> 
> The fix of 1.9.2.6 becomes ineffective.
> trim() should be removed ?

Yoshiyuki,

Thanks for your comments.

Before I go ahead with reverting the code to what it was before.

Can you explain why the addition of trim makes the fix ineffective ?

The trim() protects from generating invalid paths that may result
from appended spaces.

Are you suggesting that we don't try to fix the possible existence of
appended spaces (or CR LF) ?

Have you seen any problem with the current version ?

Other opinions ?

Thanks,

Arieh

> 
> Yoshiyuki Karezaki   [EMAIL PROTECTED]

--
 Arieh Markel   Sun Microsystems Inc.
 Network Storage500 Eldorado Blvd. MS UBRM11-194
 e-mail: [EMAIL PROTECTED]   Broomfield, CO 80021
 Pray for snow  Phone: (303) 272-8547 x78547
 (e-mail me with subject SEND PUBLIC KEY to get public key)

Re: Tomcat 4, webapp running from WAR file

[Remy Maucherat]

- Original Message -
From: "Glenn Nielsen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 21, 2001 6:54 AM
Subject: Re: Tomcat 4, webapp running from WAR file


> Remy,
>
> The ability to compile JSP pages directly from a WAR file without
> unarchiving jar files and class files into a work directory will not
> be possible until javac can use URL's instead of a file system classpath.
> Those changes to javac will not be available for quite a while.

I know.

> Until that time I think the Context path should exist so that
> getRealPath(), getResource(), getPathTranslated() work for jar and
> class files broken out into the work directory.

GetRealPath and getPathTranslated will return the right values if running
from the filesystem.

> I have implemented a way to dynamically build the classpath needed
> by javac using the URLClassLoader.getURLs() that works great in Jasper
> except for web apps running from a war file because I can't find any
> way to get the real system file path to the jar files or classes
directory.
> This allows decoupling of Jasper from Tomcat for the CLASSPATH attribute.

-1 for this patch.
Could you revert that, please ?
The whole thing was working very fine from a WAR yesterday evening.

The JARs and classes are copied in the work directory if they are not real
files on the filesystem, and the classpath property in the classpath can be
used by javac.

> We can put comments in both Tomcat & Jasper that this can be removed once
> javac supports URL's in addition to the classpath.

Remy

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

[marcsaeg]

marcsaeg01/03/21 09:11:43

  Modified:src/share/org/apache/tomcat/service Tag: tomcat_32
PoolTcpEndpoint.java
   src/share/org/apache/tomcat/service/http Tag: tomcat_32
HttpConnectionHandler.java
  Log:
  Moving the recently added socket timeout handling from PoolTcpEndpoint into
  the HTTP connection handler where it belongs (thanks Henri).  There
  are other users of the PoolTcpEndpoint code that will break if the
  socket read times out.
  
  PR:  1006
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.8.2.5   +3 -6  
jakarta-tomcat/src/share/org/apache/tomcat/service/Attic/PoolTcpEndpoint.java
  
  Index: PoolTcpEndpoint.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/Attic/PoolTcpEndpoint.java,v
  retrieving revision 1.8.2.4
  retrieving revision 1.8.2.5
  diff -u -r1.8.2.4 -r1.8.2.5
  --- PoolTcpEndpoint.java  2001/03/20 22:21:25 1.8.2.4
  +++ PoolTcpEndpoint.java  2001/03/21 17:11:29 1.8.2.5
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/Attic/PoolTcpEndpoint.java,v
 1.8.2.4 2001/03/20 22:21:25 marcsaeg Exp $
  - * $Revision: 1.8.2.4 $
  - * $Date: 2001/03/20 22:21:25 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/Attic/PoolTcpEndpoint.java,v
 1.8.2.5 2001/03/21 17:11:29 marcsaeg Exp $
  + * $Revision: 1.8.2.5 $
  + * $Date: 2001/03/21 17:11:29 $
*
* 
*
  @@ -290,9 +290,6 @@
accepted = null;
}
}
  -
  -if(accepted != null)
  -accepted.setSoTimeout(timeout);
   if( factory != null && accepted != null)
   factory.initSocket( accepted );
}
  
  
  
  No   revision
  
  
  No   revision
  
  
  1.26.2.4  +18 -3 
jakarta-tomcat/src/share/org/apache/tomcat/service/http/Attic/HttpConnectionHandler.java
  
  Index: HttpConnectionHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/http/Attic/HttpConnectionHandler.java,v
  retrieving revision 1.26.2.3
  retrieving revision 1.26.2.4
  diff -u -r1.26.2.3 -r1.26.2.4
  --- HttpConnectionHandler.java2000/10/04 20:23:56 1.26.2.3
  +++ HttpConnectionHandler.java2001/03/21 17:11:38 1.26.2.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/http/Attic/HttpConnectionHandler.java,v
 1.26.2.3 2000/10/04 20:23:56 costin Exp $
  - * $Revision: 1.26.2.3 $
  - * $Date: 2000/10/04 20:23:56 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/http/Attic/HttpConnectionHandler.java,v
 1.26.2.4 2001/03/21 17:11:38 marcsaeg Exp $
  + * $Revision: 1.26.2.4 $
  + * $Date: 2001/03/21 17:11:38 $
*
* 
*
  @@ -77,6 +77,8 @@
   
   public class HttpConnectionHandler  implements  TcpConnectionHandler {
   
  +private int timeout = 30;  // 5 minutes
  +
   boolean secure=false;
   ContextManager contextM;
   
  @@ -139,6 +141,7 @@
return;
//  System.out.print("1");
socket=connection.getSocket();
  +socket.setSoTimeout(timeout);
if (socket == null)
return;
//  System.out.print("2");
  @@ -230,6 +233,18 @@
// SocketExceptions are normal
contextM.doLog( "SocketException reading request, ignored", e, 
Logger.INFORMATION);
}
  +catch (java.io.InterruptedIOException ioe) {
  +// InterruptedIOException are timeout and we must abort process
  +ioe.printStackTrace();
  +contextM.doLog( "Timeout while reading request, aborting", ioe, 
Logger.ERROR);
  +try{
  +if (socket != null)
  +socket.close ();
  +}
  +catch (IOException e){
  + /* ignore */
  +}
  +}
catch (java.io.IOException e) {
// IOExceptions are normal 
contextM.doLog( "IOException reading request, ignored", e, 
Logger.INFORMATION);
  
  
  

Tomcat - Ghost/Rogue Sessions

[Mark Lane]

Title: Tomcat - Ghost/Rogue Sessions





Here's the scenario ...


We have a JSP/Servlet application - The JSPs post requests to the Servlets, the Servlets do some work and then forward the requests back to the JSPs. We are also using session tracking.

We are using MS IIS 4.0 & Jakarta Tomcat 3.2.1 (Release Build).



EG ...


Login.jsp
- Displays a user login screen
- Posts the request to LoginServlet



LoginServlet
- Handles the post request (Logs the user in or returns an error)
- Initiates a new session
HttpSession httpSession = req.getSession( true );


- Forwards the requests to Login.jsp
rd = this.getServletContext().getRequestDispatcher("/WMLLogin.jsp");
rd.forward( req, res );



Login.jsp
- Checks for a valid session
HttpSession httpSession = request.getSession(false);


if (httpSession != null)
{
    String sessionID = httpSession.getId();
    ...
    ...
    ...
}


- Displays a menu or an error (Login error or session error)



However, in some cases the JSP sees a different session than the one created by the Servlet - Printing the Session ID in the JSP & Servlet shows this quite clearly ...

The very next attempt works fine - The JSP & Servlet both see/use the same session and the login attempt is successful. The interesting thing here is that the Session ID used is the same as what the JSP thought the Session ID was in the previous attempt ... ???

Is this a bug ? If not then what's wrong ???



Regards,



Mark Lane



Mark Lane
Software Engineer
XIAM Limited - The Information Router Company
Alexandra House, Ballsbridge Park, Dublin 4, Ireland
DDI    : +353 1 6642474
Switch : +353 1 6642400
Fax    : +353 1 6642499
Mobile : +353 87 6182279
E-Mail : mailto:[EMAIL PROTECTED]
Web    : http://www.xiam.com/


Meet XIAM at the CeBIT Exhibition in Hannover on March 22-28. You will find us in Hall 4, Stand A62.


The information transmitted in this e-mail is intended for the addressee only and may contain confidential and/or privileged material.  Any review, 

re-transmission, dissemination, reliance upon or other use of this information by persons or entities other than the addressee is prohibited.  If you think, for any reason, that this message may have been addressed to you in error, we would ask you to notify the sender immediately by return e-mail and delete the material.

bug in Jasper - bad lookups to Constants.getString()

[Julien, Timothy]

I believe there is a bug in Jasper when resources (such as web.xml's dtd)
can't be loaded.
The basic problem is that keys are getting passed into Constants.getString()
which aren't keys in the message resources file.  This happens because of
some exception handling, which basically constructs an invalid key - namely,
a *value* in the message resources file.

JspUtil.parseXMLDocJaxp(String, InputStream)
{
try
{
...
}
catch(IOException io)
  {
throw new
JasperException(Constants.getString("jsp.error.parse.xml", new Object[] {
uri, io.toString()
}));
  }
}
and then lower down the call stack:

public TldLocationsCache(ServletContext ctxt)
{
 mappings = new Hashtable();
 try
 {
 processWebDotXml(ctxt);
 processJars(ctxt);
 }
 catch(JasperException ex)
 {
 Constants.message(ex.getMessage(), 1);
 }
}

The trouble is that ex.getMessage() here contains a *value* from the message
resource file, (as looked up in the first caught Exception) not a *key*.

One fix would be in JspUtil.parseXMLDocJaxp(String, InputStream) to pass
only the key (jsp.error.parse.xml) as the JasperException's message - and
delay the lookup.  But then you lose some information (i.e., io.String()).

Maybe a better solution is to set a flag on JasperException which marks its
message as being either key or value - so that Constants.getString can be
called only when necessary.  I realize this would effect alot of code.

anyway, I'm happy to help in any way with the fix.
Tim Julien
HP Middleware

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

[Steve Downey]

Javac does need to get at the class files in WEB-INF/classes, for any jsp
that, say, uses a bean or tag defined in the WAR.

It isn't a requirement that the .java files for those classes be accessible.


> -Original Message-
> From: Mel Martinez [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 9:57 AM
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit:
> jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler
> JspCompiler.java JspReader.java ParserController.java
> TagLibraryInfoImpl.java
> 
> 
> 
> --- [EMAIL PROTECTED] wrote:
> > remm01/03/20 16:08:53
> > 
> >   Modified:   
> > jasper/src/share/org/apache/jasper/compiler
> > JspCompiler.java
> > JspReader.java
> > ParserController.java
> > TagLibraryInfoImpl.java
> >   Log:
> >   - Jasper should run from WARs (or any other
> > repository which provides a directory
> > context to access it).
> >   - All Watchdog 4 tests pass (servlets, JSP,
> > JSP-XML).
> >   - Of course, the classes and JARs are still
> > extracted from the WAR until the
> > compilation technology is updated (javac wants
> > files :(( ).
> >   
> 
> :-)  But javac doesn't have any reason to deal with
> the contents of the WAR directly.  JSP 'files' read
> out of the .war are being converted to .java files
> stored in the working directory (i.e. /tmp or
> wherever).  Javac just has to deal with the latter
> files.
> 
> It should be possible to modify Jasper to work with an
> unexpanded .war archive.  Not necessarily trivial, but
> definitely possible, in principle, with no need for
> new javac compilation tech.
> 
> Cheers,
> 
> Mel
> 
> __
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail. 
> http://personal.mail.yahoo.com/
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

Re: Tomcat 4, webapp running from WAR file

[Craig R. McClanahan]

On Wed, 21 Mar 2001, Glenn Nielsen wrote:

> Remy,
> 
> The ability to compile JSP pages directly from a WAR file without
> unarchiving jar files and class files into a work directory will not
> be possible until javac can use URL's instead of a file system classpath.
> Those changes to javac will not be available for quite a while.
> 

Glenn, I'd like you to revert the recent patches you did regarding the
Jasper classpath attribute ... at least until after beta 2.  It broke
things that were already working for me.

> Until that time I think the Context path should exist so that
> getRealPath(), getResource(), getPathTranslated() work for jar and
> class files broken out into the work directory.
> 

Nope ... there is no such thing as a disk file pathname to the context
root when you are running out of a WAR
file.  ServletContext.getRealPath() (and therefore
HttpServletRequest.getPathTranslated()) will return null in such a
case.  It's up to Jasper to deal with that issue, and figure out the last
modified date a different way -- by opening the URLConnection and checking
the lastModified property.

ServletContext.getResource() and ServletContext.getResourceAsStream() are
the portable mechanisms to access the static resources of the web app,
including the source code to JSP pages.

> I have implemented a way to dynamically build the classpath needed
> by javac using the URLClassLoader.getURLs() that works great in Jasper
> except for web apps running from a war file because I can't find any
> way to get the real system file path to the jar files or classes directory.
> This allows decoupling of Jasper from Tomcat for the CLASSPATH attribute.
> 

That's why the previous code pulled out a copy of the JAR files into the
WORK directory.  This was working right, and got broken by your patch.

> We can put comments in both Tomcat & Jasper that this can be removed once
> javac supports URL's in addition to the classpath.
> 
> Regards,
> 
> Glenn
> 

Craig


> Remy Maucherat wrote:
> > 
> > Quoting Glenn Nielsen <[EMAIL PROTECTED]>:
> > 
> > > Is the ability to run from a WAR file directly without unarchiving it
> > > into the webapps directory completely implemented?
> > 
> > No, I'm working on some fixes for Jasper (including one for the trace you
> > included).
> > 
> > > Jasper gives me a null pointer when it tries to see if a JSP needs
> > > to be recompiled in its Outdated method because getRealPath() returns
> > > null,
> > > getServletConfig().getServletContext().getRealPath(jspUri));
> > 
> > Here, it should use getServletConfig().getServletContext().getResource
> > (jspUri).openConnection().getLastModified().
> > 
> > There are other places where Jasper will break because of over reliance on
> > getRealPath() and getPathTranslated() (in both cases, the servlet container is
> > allowed to return null, and will do so when there is no physical file on the
> > filesystem).
> > 
> > Remy
> 
> -- 
> --
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> MOREnet System Programming   |  * if iz ina coment.  |
> Missouri Research and Education Network  |  */   |
> --
> 

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

[Craig R. McClanahan]

On Wed, 21 Mar 2001, Steve Downey wrote:

> Javac does need to get at the class files in WEB-INF/classes, for any jsp
> that, say, uses a bean or tag defined in the WAR.
> 
> It isn't a requirement that the .java files for those classes be accessible.
> 

The Java sources do not have to be available, but the .class files
do.  Otherwise, when you compile a JSP page that uses a scriptlet
reference to a bean class in WEB-INF/classes, the compile will fail with a
class not found.

If you are running out of a WAR, there is no way to tell the compiler "use
this subdirectory of files out of this WAR file here".  That's why the
(previously working) code pulls out the appropriate stuff and *adds* the
appropriate work directories and JARs to the classpath provided by
Catalina.

Craig

Re: Sorry! was: RE: ISAPI Filter: Bug? in jk_isapi_plugin.c found andfixed

[Srinivasa Reddy Gumbula]

Hi!

Following the idea of the jason I fix the defect.
Since I cannot send the attachment. I am putting the
code that needs to be changed.
In the HttpFilterProc add these two lines after
p->SetHeader(pfc, "url", extension_uri);

p->AddHeader(pfc, "TOMCATURI:",uri);
p->AddHeader(pfc, "TOMCATWORKER:",worker);

And replace the else block  of
if(from_filt){ } with the following code
in the init_ws_service:



else {
// code added by srini
char *uri = (char*)malloc(1024*sizeof(char));
char *worker = (char*)malloc(1024*sizeof(char));
int bufSize;

jk_log(logger, JK_LOG_DEBUG, "filter_ext_record_t is NULL:\n");


private_data->lpEcb->GetServerVariable(private_data->lpEcb->ConnID,"HTTP_TOMCATURI",uri,&bufSize);
jk_log(logger, JK_LOG_DEBUG, "uri %s:\n",uri);

private_data->lpEcb->GetServerVariable(private_data->lpEcb->ConnID,"HTTP_TOMCATWORKER",worker,&bufSize);
jk_log(logger, JK_LOG_DEBUG, "worker %s:\n",worker);
if(uri[0]!='\0'){
char *t = strchr(uri, '?');
if(t) {
*t = '\0';
t++;
if(!strlen(t)) {
t = NULL;
}
 s->query_string = t;
 s->req_uri  = uri;
 *worker_name= worker;
 jk_log(logger, JK_LOG_DEBUG, "worker_name %s: 
\n",*worker_name);
 jk_log(logger, JK_LOG_DEBUG, "s->req_uri %s: \n",s->req_uri);
}
}  else {
  s->query_string = private_data->lpEcb->lpszQueryString;
  *worker_name= JK_AJP12_WORKER_NAME;
  GET_SERVER_VARIABLE_VALUE("URL", s->req_uri);
}
   //end
}


Thanks,
Srini.

-
Jason,

Send me ([EMAIL PROTECTED] and [EMAIL PROTECTED]) the bug fix
directly and I will
check it in

Also, thank you very much for the class A bug report + fix.

Gal Shachor

Jason Reid wrote:
>
>Ok, well, I guess I can't attach the source code to the
>bugfix.  That's pretty embarrassing.  Sorry to flood the
>list.
>
>For anyone that wants the modified source file, I can email it
>directly.
>
> >   Jason Reid
> Technical Consultant
> AGENCY.COM
> 100 Woodbridge Center Drive, Suite 102
> Woodbridge, NJ 07095
> Email: [EMAIL PROTECTED]
> 
>
> "Do not meddle in the affairs of programmers,
>  for they are subtle and quick to anger."
>
> > -Original Message-
> > From: Jason Reid []
> > Sent: Friday, May 12, 2000 10:02 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: FW: ISAPI Filter: Bug? in jk_isapi_plugin.c found and fixed
> >
> >
> > Hi, I tried sending this directly to Gal Schacor,
> > but the message was unable to be successfully
> > delivered, so I decided to forward it onto
> > Tomcat-Dev.
> >
> >   >   Jason Reid
> >   Technical Consultant
> >   AGENCY.COM
> >   100 Woodbridge Center Drive, Suite 102
> >   Woodbridge, NJ 07095
> >   Email: [EMAIL PROTECTED]
> >   
> >
> >   "Do not meddle in the affairs of programmers,
> >for they are subtle and quick to anger."
> >
> >
> > -Original Message-
> > From: Jason Reid
> > Sent: Friday, May 12, 2000 9:49 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: ISAPI Filter: Bug? in jk_isapi_plugin.c found and fixed
> >
> >
> > Hi,
> >
> > I recently posted a message to tomcat-dev describing a
> > problem I had with IIS + Tomcat...that message has been
> > attached to the end of this one.
> >
> > Anyway, I traced the behavior to the isapi filter,
> > did some logging, and found what I think was the problem.
> > In the comments, you say that the plugin uses a TLS to
> > pass values from the filter to the extension.
> >
> > In the filter, the filter_ext_record_t rec was always
> > being successfully stored in the Tls.  However, in the
> > extension (function init_ws_service), sometimes the
> > TlsGetValue would return NULL.
> >
> > Now, I don't know very much about programming C in
> > Windows, and I know even less about doing ISAPI Filters
> > and Extensions (yesterday was actually the first time
> > I'd even seen one!).  But I was left to assume that
> > perhaps a separate thread was invoking the extension then
> > had invoked the filter?  And in that case, I gathered,
> > the TlsGetValue would not find the filter_ext_record that
> > had been previously stored.
> >
> > I went through Microsoft's Knowledge base, and found an
> > article on passing information from a Filter to an 

RE: to trim or not to trim (was Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util FileUtil.java)

[Larry Isaacs]

> -Original Message-
> From: Arieh Markel [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 11:16 AM
> To: [EMAIL PROTECTED]
> Subject: to trim or not to trim (was Re: cvs commit:
> jakarta-tomcat/src/share/org/apache/tomcat/util FileUtil.java)
> 
> 
> 
> > Mailing-List: contact [EMAIL PROTECTED]; 
> run by ezmlm
> > list-help: 
> > list-unsubscribe: 
> > list-post: 
> > Delivered-To: mailing list [EMAIL PROTECTED]
> > From: Yoshiyuki Karezaki <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Re: cvs commit: 
> jakarta-tomcat/src/share/org/apache/tomcat/util 
> FileUtil.java
> > User-Agent: Wanderlust/2.4.1 (Stand By Me) Emacs/20.4 Mule/4.1 (AOI)
> > X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
> > 
> > Hi arieh,
> > 
> > In article  jakarta-tomcat/src/share/org/apache/tomcat/util 
> FileUtil.java>,
> > [EMAIL PROTECTED] wrote:
> > |public static String patch(String path) {
> > |   -   String patchPath = path;
> > |   +   String patchPath = path.trim();
> > 
> > The fix of 1.9.2.6 becomes ineffective.
> > trim() should be removed ?
> 
> Yoshiyuki,
> 
> Thanks for your comments.
> 
> Before I go ahead with reverting the code to what it was before.
> 
> Can you explain why the addition of trim makes the fix ineffective ?
> 
> The trim() protects from generating invalid paths that may result
> from appended spaces.
> 
> Are you suggesting that we don't try to fix the possible existence of
> appended spaces (or CR LF) ?

The trim() was removed to fix a security vulnerability that can
occur if the URL ends with ".jsp%20".  This results in the JSP
being served statically.  See Bugzilla Bug #748.

Where would valid spaces or CRLF come from?  Perhaps we can look
for a better place to trim them.  Doing this in patch() means
that some portions of Tomcat will see a request that is
technically different from what other portions see.

Cheers,
Larry

> 
> Have you seen any problem with the current version ?
> 
> Other opinions ?
> 
> Thanks,
> 
> Arieh
> 
> > 
> > Yoshiyuki Karezaki   [EMAIL PROTECTED]
> 
> --
>  Arieh Markel Sun Microsystems Inc.
>  Network Storage500 Eldorado Blvd. MS 
> UBRM11-194
>  e-mail: [EMAIL PROTECTED]   Broomfield, CO 80021
>  Pray for snow  Phone: (303) 272-8547 x78547
>  (e-mail me with subject SEND PUBLIC KEY to get public key)
> 

Re: mod_webapp status?

[Dave Oxley]

Correct me if I'm wrong, but APR is meant as a library of API's that are 
separate from Apache2 and should therefore be able to be used with 
Apache1.3. What I would be concerned about is that there hasn't been a final 
(let alone beta) of APR/Apache2 and is therefore subject to change. If 
APR/Apache2 was to be made final before Tomcat4 becomes final then I don't 
see a problem, but

Dave ...under a bit less snow in England :)
[EMAIL PROTECTED]

> >
> > I'm rewriting it using APR... As we speak...
> >
> > Pier (under the snow in Dublin)
>
>APR is for Apache 2.0, correct?  What about Apache 1.3?
>
>Glenn
>

_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml

[craigmcc]

craigmcc01/03/21 11:38:54

  Modified:tester   build.xml
   tester/src/bin tester.xml
   tester/web/WEB-INF web.xml
  Added:   tester/src/tester/org/apache/tester Resources05.java
Resources05.txt
  Log:
  Add test cases where the URL returned by getResource() is actually opened
  and read, to ensure that the appropriate stream handler is provided.
  
  Revision  ChangesPath
  1.7   +2 -0  jakarta-tomcat-4.0/tester/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/build.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- build.xml 2001/03/13 19:06:09 1.6
  +++ build.xml 2001/03/21 19:38:28 1.7
  @@ -70,6 +70,8 @@
   
tofile="${tester.build}/web/WEB-INF/classes/org/apache/tester/Unpacked01.txt"/>
   
  +
   
   
   
  
  
  
  1.22  +27 -0 jakarta-tomcat-4.0/tester/src/bin/tester.xml
  
  Index: tester.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- tester.xml2001/03/17 19:48:20 1.21
  +++ tester.xml2001/03/21 19:38:40 1.22
  @@ -350,6 +350,33 @@

request="${context.path}/Resources04?mode=class&path=/org/apache/tester/Unpacked04.txt.bad"
 outContent="Resources04 PASSED"/>
   
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
 
   
   
  
  
  
  1.1  
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Resources05.java
  
  Index: Resources05.java
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   * Copyright (c) 1999, 2000, 2001  The Apache Software Foundation.   *
   *   All rights reserved.*
   *   *
   * = *
   *   *
   * Redistribution and use in source and binary forms,  with or without modi- *
   * fication, are permitted provided that the following conditions are met:   *
   *   *
   * 1. Redistributions of source code  must retain the above copyright notice *
   *notice, this list of conditions and the following disclaimer.  *
   *   *
   * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
   *notice,  this list of conditions  and the following  disclaimer in the *
   *documentation and/or other materials provided with the distribution.   *
   *   *
   * 3. The end-user documentation  included with the redistribution,  if any, *
   *must include the following acknowlegement: *
   *   *
   *   "This product includes  software developed  by the Apache  Software *
   *Foundation ."  *
   *   *
   *Alternately, this acknowlegement may appear in the software itself, if *
   *and wherever such third-party acknowlegements normally appear. *
   *   *
   * 4. The names  "The  Jakarta  Project",  "Tomcat",  and  "Apache  Software *
   *Foundation"  must not be used  to endorse or promote  products derived *
   *from this  software without  prior  written  permission.  For  written *
   *permission, please contact <[EMAIL PROTECTED]>.*
   *   *
   * 5. Products derived from this software may not be called "Apache" nor may *
   *"Apache" appear in their names without prior written permission of the *
   *Apache Software Foundation.*
   *   *
   * THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES *
   * INCLUDING, BUT NOT LIMITED TO,  THE IMPLIED WARRANTIES OF MERCHAN

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

[costin]

costin  01/03/21 11:51:06

  Modified:src/share/org/apache/jasper/runtime BodyContentImpl.java
  Log:
  Lucky fix - it shows up for some JSPs generating a lot of content.
  Nacho - nice tuneup ( remove double copy ), you forgot one line :-)
  
  Revision  ChangesPath
  1.9   +4 -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.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- BodyContentImpl.java  2001/03/10 01:20:23 1.8
  +++ BodyContentImpl.java  2001/03/21 19:50:51 1.9
  @@ -113,7 +113,8 @@
   
if (len <= Constants.DEFAULT_BUFFER_SIZE) {
tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
  - bufferSize = bufferSize * 2;
  + //  bufferSize = bufferSize * 2;
  + bufferSize += Constants.DEFAULT_BUFFER_SIZE;
} else {
tmp = new char [bufferSize + len];
bufferSize += len;
  @@ -179,6 +180,8 @@
if (len >= bufferSize - nextChar)
reAllocBuff(len);
   
  + //System.out.println("XXX " + off + " " + (off+len) + " " +
  + // nextChar + " " + bufferSize + " "+  cb.length);
   s.getChars(off, off + len, cb, nextChar);
nextChar += len;
   }
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources DirContextURLConnection.java

[remm]

remm01/03/21 11:51:55

  Modified:catalina/src/share/org/apache/naming/resources
DirContextURLConnection.java
  Log:
  - Throw an IllegalArgumentException if the context specified is null.
  
  Revision  ChangesPath
  1.4   +7 -4  
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java
  
  Index: DirContextURLConnection.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- DirContextURLConnection.java  2001/03/16 05:47:51 1.3
  +++ DirContextURLConnection.java  2001/03/21 19:51:48 1.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
 1.3 2001/03/16 05:47:51 remm Exp $
  - * $Revision: 1.3 $
  - * $Date: 2001/03/16 05:47:51 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
 1.4 2001/03/21 19:51:48 remm Exp $
  + * $Revision: 1.4 $
  + * $Date: 2001/03/21 19:51:48 $
*
* 
*
  @@ -89,7 +89,7 @@
* content is directly returned.
* 
* @author mailto:[EMAIL PROTECTED]">Remy Maucherat
  - * @version $Revision: 1.3 $
  + * @version $Revision: 1.4 $
*/
   public class DirContextURLConnection 
   extends URLConnection {
  @@ -100,6 +100,9 @@
   
   public DirContextURLConnection(DirContext context, URL url) {
   super(url);
  +if (context == null)
  +throw new IllegalArgumentException
  +("Directory context can't be null");
   this.context = context;
   }
   
  
  
  

cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester Resources05.java

[craigmcc]

craigmcc01/03/21 12:28:34

  Modified:tester/src/bin tester.xml
   tester/src/tester/org/apache/tester Resources05.java
  Log:
  Update the new combined getResource()/openStream() test so that it
  optionally converts the URL returned by getResource() to a string and
  back, emulating what some applications might do.  NOTE:  Tomcat 4.0 still
  passes these tests, both with and without the "-usenaming" switch at
  startup time.
  
  Revision  ChangesPath
  1.23  +27 -0 jakarta-tomcat-4.0/tester/src/bin/tester.xml
  
  Index: tester.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- tester.xml2001/03/21 19:38:40 1.22
  +++ tester.xml2001/03/21 20:28:24 1.23
  @@ -377,6 +377,33 @@

request="${context.path}/Resources05?mode=class&path=/org/apache/tester/Unpacked05.txt"
 outContent="Resources05 PASSED"/>
   
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
 
   
   
  
  
  
  1.2   +16 -2 
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Resources05.java
  
  Index: Resources05.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Resources05.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Resources05.java  2001/03/21 19:38:46 1.1
  +++ Resources05.java  2001/03/21 20:28:31 1.2
  @@ -76,10 +76,13 @@
* test, or class for class loader test.  [context]
* path - Resource path to the requested resource,
* starting with a slash.  [/WEB-INF/web.xml]
  + * stringify - If set to any arbitrary value, the URL
  + * returned by getResource() will be converted to a String and then back
  + * to a URL before being opened.  [not set]
* 
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.1 $ $Date: 2001/03/21 19:38:46 $
  + * @version $Revision: 1.2 $ $Date: 2001/03/21 20:28:31 $
*/
   
   public class Resources05 extends HttpServlet {
  @@ -94,6 +97,7 @@
   String path = request.getParameter("path");
   if (path == null)
   path = "/WEB-INF/web.xml";
  +boolean stringify = (request.getParameter("stringify") != null);
   
   // Prepare for the desired test
   response.setContentType("text/plain");
  @@ -115,8 +119,18 @@
   ok = false;
   }
   } catch (MalformedURLException e) {
  -results.append(" MalformedURLException");
  +results.append(" getResource MalformedURLException");
   ok = false;
  +}
  +
  +// Stringify the URL if requested
  +try {
  +if (ok) {
  +String urlString = url.toString();
  +url = new URL(urlString);
  +}
  +} catch (MalformedURLException e) {
  +results.append(" stringify MalformedURLException");
   }
   
   // Open an input stream and input stream reader on this URL
  
  
  

RE: [Bug 1059] Changed - JSP pages fail to compile when referencing classes from apps classloader

[Arun Katkere]

Unless you are going with the new classloader architecture for 3.2.2, which
I doubt, this bug doesn't apply to 3.2.2. It applies to 3.3m2 (I had to mark
the version as "Unknown" since 3.3 doesn't have an entry in bugzilla). 

Are we accepting only bugs that apply to 3.2.2 and everything that won't be
done for 3.2.2 will be unceremoniously closed?

-arun

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 12:29 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [Bug 1059] Changed - JSP pages fail to compile when 
> referencing
> classes from apps classloader
> 
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1059
> 
> *** shadow/1059   Tue Mar 20 23:32:48 2001
> --- shadow/1059.tmp.21761 Wed Mar 21 12:29:05 2001
> ***
> *** 2,11 
>   | JSP pages fail to compile when referencing classes from 
> apps classloader   |
>   
> +-
> ---+
>   |Bug #: 1059Product: Tomcat 
> 3|
> ! |   Status: NEW Version: 
> Unknown |
> ! |   Resolution:Platform: All
>  |
>   | Severity: MajorOS/Version: All
>  |
> ! | Priority:   Component: Jasper 
>  |
>   
> +-
> ---+
>   |  Assigned To: [EMAIL PROTECTED]  
>  |
>   |  Reported By: [EMAIL PROTECTED]   
>  |
> --- 2,11 
>   | JSP pages fail to compile when referencing classes from 
> apps classloader   |
>   
> +-
> ---+
>   |Bug #: 1059Product: Tomcat 
> 3|
> ! |   Status: RESOLVEDVersion: 
> Unknown |
> ! |   Resolution: LATER  Platform: All
>  |
>   | Severity: MajorOS/Version: All
>  |
> ! | Priority: High  Component: Jasper 
>  |
>   
> +-
> ---+
>   |  Assigned To: [EMAIL PROTECTED]  
>  |
>   |  Reported By: [EMAIL PROTECTED]   
>  |
> ***
> *** 36,39 
>   
>   Workaround is to use the common classloader, but we hear 
> talks of more 
>   classloaders (for groups of webapps), and please keep 
> Jasper in sync with these 
> ! excellent changes.
> --- 36,43 
>   
>   Workaround is to use the common classloader, but we hear 
> talks of more 
>   classloaders (for groups of webapps), and please keep 
> Jasper in sync with these 
> ! excellent changes.
> ! 
> ! --- Additional Comments From [EMAIL PROTECTED] 
>  2001-03-21 12:29 ---
> ! This won't be addressed in Tomcat 3.2.2.  It will be 
> evaluated for a later 
> ! release.
> 

Re: Réf. : RE: Proposal for Compression Filter example

[Amy Roh]

Quoting "JULE, Nicolas - DSIA" <[EMAIL PROTECTED]>:

> 
> 
> 
>   De :Craig R. McClanahan@craigmcc le 20/03/2001 23:31
>   Pour :  tomcat-dev@[EMAIL PROTECTED]@SMTP@Hays Hub
>   cc : 
>   Faxer à:
>   Objet : RE: Proposal for Compression Filter example
> 
> 
> 
>   On Tue, 20 Mar 2001, GOMEZ Henri wrote:
> 
>   > >I created an example web application using Filter technology 
>   > >and would like to 
>   > >add to Tomcat 4 example webapps.  This example includes Data 
>   > >Compression Filter 
>   > >which compresses ServletResponse according to the threshold 
>   > >that can be set by 
>   > >users.  I think it'll be a good example usage of filters.
>   > >
>   > >What do you think?
>   > 
>   > +1 (may be a module for 3.3 ?)
>   > 
> 
>   | Anyone who wants to create a module for this kind of functionality
> can, of
>   | course, do so.  The advantage of impementing it as a Filter is
> that it
>   | will be portable to any 2.3 servlet container.
> 
>   Both are really interesting, but another Advantage for Filter is
> that it allow selective  compression (I hope it will !)

Yes, it does.  It checks for compression support first then does the 
compression.

Amy

>   Systematic compression could break flows that are not destinated to
> Browsers, but other Applications
>   using HTTP as a Tunnel, in backend of the HTTPServer.
> 
> 
>   Nicolas
> 
>   > I also recommand you to take a look at mod_gzip which
>   > done that beautifully 
>   > 
>   > http://www.remotecommunications.com/apache/mod_gzip/
>   > 
> 
>   Craig
> 
> 
> 
> 
> **
> Ce message électronique et tous les fichiers attachés qu'il contient
> sont confidentiels et destinés exclusivement à l'usage de la personne
> à laquelle ils sont adressés. Si vous avez reçu ce message par erreur,
> merci de le retourner à son émetteur. Les idées et opinions présentées
> dans ce messages sont celles de son auteur, et ne représentent pas 
> nécessairement celles du Groupe HAYS plc ou d'une quelconque de ses
> filiales.
> La publication, l'usage, la distribution, l'impression ou la copie non
> autorisée de ce message et des attachements qu'il contient sont
> strictement
> interdits.
> 
> Nous vous informons également que nous avons vérifié l'absence de virus
> dans
> ce message mais que, malgré ce contrôle, nous ne saurions être tenus
> pour 
> responsables d'éventuels dégâts occasionnés par un virus non détecté.
> 
> This e-mail and any attached files are confidential and intended
> solely for the use of the individual to whom it is addressed. If you
> have
> received this email in error please send it back to the person that sent
> it
> to you. Any views or opinions presented are solely those of author and 
> do not necessarily represent those the HAYS plc group or any of its
> subsidiary
> companies. Unauthorized publication, use, dissemination, forwarding,
> printing
> or copying of this email and its associated attachments is strictly
> prohibited.
> 
> We also inform you that we have checked that this message does not
> contain 
> any virus but we decline any responsability in case of any damage caused
> 
> by an a non detected virus.
> 
> **
> 

cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester Resources05.java

[craigmcc]

craigmcc01/03/21 12:47:11

  Modified:tester/src/tester/org/apache/tester Resources05.java
  Log:
  Update the Resoruces05 test to include a debugging message confirming
  that stringifying was actually being performed.
  
  Revision  ChangesPath
  1.3   +1 -0  
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Resources05.java
  
  Index: Resources05.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Resources05.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Resources05.java  2001/03/21 20:28:31 1.2
  +++ Resources05.java  2001/03/21 20:47:06 1.3
  @@ -82,7 +82,7 @@
* 
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.2 $ $Date: 2001/03/21 20:28:31 $
  + * @version $Revision: 1.3 $ $Date: 2001/03/21 20:47:06 $
*/
   
   public class Resources05 extends HttpServlet {
  @@ -126,6 +126,7 @@
   // Stringify the URL if requested
   try {
   if (ok) {
  +StaticLogger.write("Stringifying the URL");
   String urlString = url.toString();
   url = new URL(urlString);
   }
  
  
  

RE: [Bug 1059] Changed - JSP pages fail to compile when referencing classes from apps classloader

[Marc Saegesser]

Arun,

This bug wasn't closed.  The status was updated to RESOLVED the and the
resolution was changed to LATER.  All this means is that it won't be address
in 3.2.2 but is still open for 3.3 and later releases.

Also, it would have been helpful if the description in initial bug report
indcated the exact version it was being reported against.  That would have
saved me the time I spent trying to decide if it really applied to 3.2.2 or
not.

> -Original Message-
> From: Arun Katkere [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 2:43 PM
> To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Bug 1059] Changed - JSP pages fail to compile when
> referencing classes from apps classloader
>
>
> Unless you are going with the new classloader architecture for
> 3.2.2, which
> I doubt, this bug doesn't apply to 3.2.2. It applies to 3.3m2 (I
> had to mark
> the version as "Unknown" since 3.3 doesn't have an entry in bugzilla).
>
> Are we accepting only bugs that apply to 3.2.2 and everything
> that won't be
> done for 3.2.2 will be unceremoniously closed?
>
> -arun
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 21, 2001 12:29 PM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: [Bug 1059] Changed - JSP pages fail to compile when
> > referencing
> > classes from apps classloader
> >
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1059
> >
> > *** shadow/1059 Tue Mar 20 23:32:48 2001
> > --- shadow/1059.tmp.21761   Wed Mar 21 12:29:05 2001
> > ***
> > *** 2,11 
> >   | JSP pages fail to compile when referencing classes from
> > apps classloader   |
> >
> > +-
> > ---+
> >   |Bug #: 1059Product: Tomcat
> > 3|
> > ! |   Status: NEW Version:
> > Unknown |
> > ! |   Resolution:Platform: All
> >  |
> >   | Severity: MajorOS/Version: All
> >  |
> > ! | Priority:   Component: Jasper
> >  |
> >
> > +-
> > ---+
> >   |  Assigned To: [EMAIL PROTECTED]
> >  |
> >   |  Reported By: [EMAIL PROTECTED]
> >  |
> > --- 2,11 
> >   | JSP pages fail to compile when referencing classes from
> > apps classloader   |
> >
> > +-
> > ---+
> >   |Bug #: 1059Product: Tomcat
> > 3|
> > ! |   Status: RESOLVEDVersion:
> > Unknown |
> > ! |   Resolution: LATER  Platform: All
> >  |
> >   | Severity: MajorOS/Version: All
> >  |
> > ! | Priority: High  Component: Jasper
> >  |
> >
> > +-
> > ---+
> >   |  Assigned To: [EMAIL PROTECTED]
> >  |
> >   |  Reported By: [EMAIL PROTECTED]
> >  |
> > ***
> > *** 36,39 
> >
> >   Workaround is to use the common classloader, but we hear
> > talks of more
> >   classloaders (for groups of webapps), and please keep
> > Jasper in sync with these
> > ! excellent changes.
> > --- 36,43 
> >
> >   Workaround is to use the common classloader, but we hear
> > talks of more
> >   classloaders (for groups of webapps), and please keep
> > Jasper in sync with these
> > ! excellent changes.
> > !
> > ! --- Additional Comments From [EMAIL PROTECTED]
> >  2001-03-21 12:29 ---
> > ! This won't be addressed in Tomcat 3.2.2.  It will be
> > evaluated for a later
> > ! release.
> >

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

[craigmcc]

craigmcc01/03/21 12:49:23

  Modified:jasper/src/share/org/apache/jasper Constants.java
JspEngineContext.java
   jasper/src/share/org/apache/jasper/servlet JspServlet.java
  Log:
  Revert Glenn's changes to classpath construction, at least until after
  Beta 2.  The current changes break things.
  
  Revision  ChangesPath
  1.10  +9 -0  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/Constants.java
  
  Index: Constants.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/Constants.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- Constants.java2001/03/21 12:36:51 1.9
  +++ Constants.java2001/03/21 20:49:07 1.10
  @@ -104,6 +104,15 @@
* Other servlet engines can choose to have this attribute if they 
* want to have this JSP engine running on them. 
*/
  +//public static final String SERVLET_CLASSPATH = 
"org.apache.tomcat.jsp_classpath";
  +public static final String SERVLET_CLASSPATH = 
"org.apache.catalina.jsp_classpath";
  +
  +/**
  + * FIXME
  + * ServletContext attribute for classpath. This is tomcat specific. 
  + * Other servlet engines can choose to have this attribute if they 
  + * want to have this JSP engine running on them. 
  + */
   //public static final String SERVLET_CLASS_LOADER = 
"org.apache.tomcat.classloader";
   public static final String SERVLET_CLASS_LOADER = 
"org.apache.catalina.classloader";
   
  
  
  
  1.7   +3 -30 
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspEngineContext.java
  
  Index: JspEngineContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspEngineContext.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- JspEngineContext.java 2001/03/21 12:37:20 1.6
  +++ JspEngineContext.java 2001/03/21 20:49:10 1.7
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspEngineContext.java,v
 1.6 2001/03/21 12:37:20 glenn Exp $
  - * $Revision: 1.6 $
  - * $Date: 2001/03/21 12:37:20 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspEngineContext.java,v
 1.7 2001/03/21 20:49:10 craigmcc Exp $
  + * $Revision: 1.7 $
  + * $Date: 2001/03/21 20:49:10 $
*
* 
* 
  @@ -145,44 +145,17 @@
   
   /**
* The classpath that is passed off to the Java compiler. 
  - *
  - * Uses the URLClassLoader getURLs to build the classpath
  - * for the Context ClassLoader and all parent
  - * ClassLoader's except for the system class loader.
*/
   public String getClassPath() {
  -StringBuffer cpath = new StringBuffer();
  - ClassLoader cl = loader;
  - while( cl != null && cl.getParent() != null ) {
  - if( (cl instanceof URLClassLoader) ) {
  - cpath.append(getClassLoaderPaths((URLClassLoader)cl));
  - }
  - cl = cl.getParent();
  - }
  -return cpath.toString() + classpath;
  -}
  -
  -/**
  - * The classpaths for a URLClassLoader
  - */
  -private String getClassLoaderPaths(URLClassLoader loader) {
URL [] urls = loader.getURLs();
   StringBuffer cpath = new StringBuffer();
   String sep = System.getProperty("path.separator");
   
   for(int i = 0; i < urls.length; i++) {
  - String file = null;
  - String url = urls[i].toString();
  - if( url.startsWith("jndi:") ) {
  - file = getRealPath(url.substring(5));
  - } else if( url.startsWith("jar:jndi:") ) {
  - file = getRealPath(url.substring(9,url.length()-2));
  - } else {
  - file = (String)urls[i].getFile();
  - }
  -cpath.append(file + sep);
  +cpath.append((String)urls[i].getFile()+sep);
   }
  -return cpath.toString();
  + 
  +return cpath.toString() + classpath;
   }
   
   /**
  
  
  
  1.16  +21 -4 
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet/JspServlet.java
  
  Index: JspServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet/JspServlet.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- JspServlet.java   2001/03/21 12:37:55 1.15
  +++ JspServlet.java   2001/03/21 20:49:20 1.16
  @@ -150,10 +150,27 @@
private void loadIfNecessary(HttpServletRequest req, HttpServletResponse res) 
   throws JasperException, ServletExceptio

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

[Mel Martinez]

--- Mel Martinez <[EMAIL PROTECTED]> wrote:
> 
> --- [EMAIL PROTECTED] wrote:
> >   - Of course, the classes and JARs are still
> > extracted from the WAR until the
> > compilation technology is updated (javac wants
> > files :(( ).
> >   
> 
> :-)  But javac doesn't have any reason to deal with
> the contents of the WAR directly.  JSP 'files' read
> out of the .war are being converted to .java files
> stored in the working directory (i.e. /tmp or
> wherever).  Javac just has to deal with the latter
> files.
> 

Please disregard this stupid inaccuracy.  'Brain
momentarily dumped the fact that the compiler might
need to see inside the .war for imported classes used
in the compilation of the .jsp/.java file.

Sigh...

Mel

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/facade HttpServletRequestFacade.java

[costin]

costin  01/03/21 13:13:56

  Modified:src/share/org/apache/tomcat/facade Tag: tomcat_32
HttpServletRequestFacade.java
  Log:
  Disable creation of session facades. A better solution is implemented in 3.3,
  where the same facade is returned during servlet execution.
  
  The session facade was added for security - to prevent the servlet from
  accessing public methods and to prevent the servlet to "keep" the reference
  and use it later ( when the object may be associated with another session ).
  
  Securing tomcat and support for untrusted apps is a long process, and 3.2
  has other places where untrusted apps could hold references to recycled
  objects - as long as the HttpServletRequest is recycled there is no
  point in beeing paranoic about the session.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.6.2.2   +2 -1  
jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletRequestFacade.java
  
  Index: HttpServletRequestFacade.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletRequestFacade.java,v
  retrieving revision 1.6.2.1
  retrieving revision 1.6.2.2
  diff -u -r1.6.2.1 -r1.6.2.2
  --- HttpServletRequestFacade.java 2001/03/06 01:13:05 1.6.2.1
  +++ HttpServletRequestFacade.java 2001/03/21 21:13:54 1.6.2.2
  @@ -89,7 +89,7 @@
   HttpSessionFacade sessionFacade;
   ServletInputStreamFacade isFacade=null;
   BufferedReader reader;
  -
  +static final NO_SESSION_FACADE=true;   
   private boolean usingStream = false;
   private boolean usingReader = false;
   
  @@ -385,6 +385,7 @@
*/
   public HttpSession getSession(boolean create) {
HttpSession realSession = request.getSession( create );
  + if( NO_SESSION_FACADE ) return realSession;
// No real session, return null
if( realSession == null ) {
if( sessionFacade!= null) sessionFacade.recycle();
  
  
  

RE: [Bug 1059] Changed - JSP pages fail to compile when referencing classes from apps classloader

[Arun Katkere]

I apologize for not mentioning the version number. I guess I am used to
selecting the version I am reporting against and didn't remember to type it
in the description.

Can someone add an entry for Tomcat 3.3m2 in bugzilla? That is a little less
error prone than expecting folks to enter the version number in bug
description.

-arun

> -Original Message-
> From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 12:48 PM
> To: Arun Katkere; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Bug 1059] Changed - JSP pages fail to compile when
> referencing classes from apps classloader
> 
> 
> Arun,
> 
> This bug wasn't closed.  The status was updated to RESOLVED 
> the and the
> resolution was changed to LATER.  All this means is that it 
> won't be address
> in 3.2.2 but is still open for 3.3 and later releases.
> 
> Also, it would have been helpful if the description in 
> initial bug report
> indcated the exact version it was being reported against.  
> That would have
> saved me the time I spent trying to decide if it really 
> applied to 3.2.2 or
> not.
> 
> > -Original Message-
> > From: Arun Katkere [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 21, 2001 2:43 PM
> > To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: [Bug 1059] Changed - JSP pages fail to compile when
> > referencing classes from apps classloader
> >
> >
> > Unless you are going with the new classloader architecture for
> > 3.2.2, which
> > I doubt, this bug doesn't apply to 3.2.2. It applies to 3.3m2 (I
> > had to mark
> > the version as "Unknown" since 3.3 doesn't have an entry in 
> bugzilla).
> >
> > Are we accepting only bugs that apply to 3.2.2 and everything
> > that won't be
> > done for 3.2.2 will be unceremoniously closed?
> >
> > -arun
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, March 21, 2001 12:29 PM
> > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > > Subject: [Bug 1059] Changed - JSP pages fail to compile when
> > > referencing
> > > classes from apps classloader
> > >
> > >
> > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1059
> > >
> > > *** shadow/1059   Tue Mar 20 23:32:48 2001
> > > --- shadow/1059.tmp.21761 Wed Mar 21 12:29:05 2001
> > > ***
> > > *** 2,11 
> > >   | JSP pages fail to compile when referencing classes from
> > > apps classloader   |
> > >
> > > +-
> > > ---+
> > >   |Bug #: 1059Product: Tomcat
> > > 3|
> > > ! |   Status: NEW Version:
> > > Unknown |
> > > ! |   Resolution:Platform: All
> > >  |
> > >   | Severity: MajorOS/Version: All
> > >  |
> > > ! | Priority:   Component: Jasper
> > >  |
> > >
> > > +-
> > > ---+
> > >   |  Assigned To: [EMAIL PROTECTED]
> > >  |
> > >   |  Reported By: [EMAIL PROTECTED]
> > >  |
> > > --- 2,11 
> > >   | JSP pages fail to compile when referencing classes from
> > > apps classloader   |
> > >
> > > +-
> > > ---+
> > >   |Bug #: 1059Product: Tomcat
> > > 3|
> > > ! |   Status: RESOLVEDVersion:
> > > Unknown |
> > > ! |   Resolution: LATER  Platform: All
> > >  |
> > >   | Severity: MajorOS/Version: All
> > >  |
> > > ! | Priority: High  Component: Jasper
> > >  |
> > >
> > > +-
> > > ---+
> > >   |  Assigned To: [EMAIL PROTECTED]
> > >  |
> > >   |  Reported By: [EMAIL PROTECTED]
> > >  |
> > > ***
> > > *** 36,39 
> > >
> > >   Workaround is to use the common classloader, but we hear
> > > talks of more
> > >   classloaders (for groups of webapps), and please keep
> > > Jasper in sync with these
> > > ! excellent changes.
> > > --- 36,43 
> > >
> > >   Workaround is to use the common classloader, but we hear
> > > talks of more
> > >   classloaders (for groups of webapps), and please keep
> > > Jasper in sync with these
> > > ! excellent changes.
> > > !
> > > ! --- Additional Comments From [EMAIL PROTECTED]
> > >  2001-03-21 12:29 ---
> > > ! This won't be addressed in Tomcat 3.2.2.  It will be
> > > evaluated for a later
> > > ! release.
> > >
> 

bug in Jasper - bad calls to Constants.getString

[Julien, Timothy]

I believe there is a bug in Jasper when resources (such as web.xml's dtd)
can't be loaded.
The basic problem is that keys are getting passed into Constants.getString()
which aren't keys in the message resources file.  This happens because of
some exception handling, which basically constructs an invalid key - namely,
a *value* in the message resources file.

JspUtil.parseXMLDocJaxp(String, InputStream)
{
try
{
...
}
catch(IOException io)
  {
throw new
JasperException(Constants.getString("jsp.error.parse.xml", new Object[] {
uri, io.toString()
}));
  }
}
and then lower down the call stack:

public TldLocationsCache(ServletContext ctxt)
{
 mappings = new Hashtable();
 try
 {
 processWebDotXml(ctxt);
 processJars(ctxt);
 }
 catch(JasperException ex)
 {
 Constants.message(ex.getMessage(), 1);
 }
}

The trouble is that ex.getMessage() here contains a *value* from the message
resource file, (as looked up in the first caught Exception) not a *key*.

One fix would be in JspUtil.parseXMLDocJaxp(String, InputStream) to pass
only the key (jsp.error.parse.xml) as the JasperException's message - and
delay the lookup.  But then you lose some information (i.e., io.String()).

Maybe a better solution is to set a flag on JasperException which marks its
message as being either key or value - so that Constants.getString can be
called only when necessary.  I realize this would effect alot of code.

anyway, I'm happy to help in any way with the fix.
Tim Julien
HP Middleware

[PATCH] [Bug 1001] - available() method on ServletInputStreamalways returns 0

[Mike Anderson]

I noticed that this bug was marked RESOLVED/LATER and was wondering if there was any 
way to get this into 3.2.2 since that is the version that is closest to being 
released.  I've already found 2 ways to fix this issue but am willing to abide by the 
groups decision and concentrate on getting this into the 3.3 release instead.
The 2 ways to fix this are:

1.  In BufferedServletInputStream, implement an available() method that returns limit 
- bytesRead or 0 whichever is greater.  The limit class variable is set to the value 
of the Content-Length header and bytesRead is the number of bytes read since limit was 
set (see the attached diff1.txt).  This is the easy fix but doesn't address the 
feature of available that says it will return the number of bytes that can be read 
"without blocking".  Obviously, if there is a large amount of data, a read will most 
likely block at some point depending on how much is asked for, however this prevents a 
condition where one of the adapters returns 0 because a read hasn't actually been 
requested from the webserver.

2.  Update BufferedServletInputStream to call reqA.available and then update the 
following files to provide this interface:
  Request.java
  RequestImpl.java
  HttpRequestAdapter.java
  Ajp12ConnectionHandler.java
  Ajp13ConnectorRequest.java
  JNIConnectionHandler.java
  MsgConnector.java
  TcpConnector.java
Each of these classes would need to provide an appropriate available() method.  I've 
also done the work on these files as well (see the attached diff2.txt) but noticed 
that since some of the protocols (particularly AJP13) actually have to request a read 
to fill their internal buffer, the adapter (i.e. Ajp13ConnectorRequest.java) will 
return a 0 if doRead is called and it exactly empties the internal buffer.  Also the 
JNIRequestAdapter (in JNIConnectionHandler.java) makes a native call back into the 
webserver to do the reads and so available is implemented similar to #1 above; it just 
returns the max of contentLength - bytesRead or 0.  This was because I'm not sure of a 
way to imp

After testing both of these, implementation 1 is actually faster and more reliable.  
Typically if someone is calling available and they get back a 0, they would block the 
thread anyways and so it makes some sense to let it block on the read plus it gets 
around the issue of an adapter requiring one of it's read methods to be called to 
actually have something available.

Any response positive or negative would be appreciated so that I know where to focus 
my energy (i.e. 3.2.2 or 3.3).





Index: BufferedServletInputStream.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/BufferedServletInputStream.java,v
retrieving revision 1.8
diff -u -r1.8 BufferedServletInputStream.java
--- BufferedServletInputStream.java 2000/05/26 17:32:04 1.8
+++ BufferedServletInputStream.java 2001/03/21 21:03:59
@@ -151,6 +151,10 @@
}
 }
 
+public int available() throws IOException {
+return Math.max((limit - bytesRead), 0);
+}
+
 
 // /**
 //  * @deprecated Not part of Servlet API, without it we can avoid a lot of GC.


Index: BufferedServletInputStream.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/BufferedServletInputStream.java,v
retrieving revision 1.8
diff -u -r1.8 BufferedServletInputStream.java
--- BufferedServletInputStream.java 2000/05/26 17:32:04 1.8
+++ BufferedServletInputStream.java 2001/03/21 21:04:23
@@ -151,6 +151,10 @@
}
 }
 
+public int available() throws IOException {
+return reqA.available();
+}
+
 
 // /**
 //  * @deprecated Not part of Servlet API, without it we can avoid a lot of GC.


Index: Request.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java,v
retrieving revision 1.46
diff -u -r1.46 Request.java
--- Request.java2000/06/22 19:49:35 1.46
+++ Request.java2001/03/21 21:05:31
@@ -274,6 +274,9 @@
 
 public  int doRead( byte b[], int off, int len ) throws IOException;
 
+// provide a way to overload available from InputStream
+public int available() throws IOException;
+
 //  Internal methods 
 /** Support for "pools"
  */


Index: RequestImpl.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/RequestImpl.java,v
retrieving revision 1.52.2.7
diff -u -r1.52.2.7 RequestImpl.java
--- RequestImpl.java2001/03/15 19:00:37 1.52.2.7
+++ RequestImpl.java2001/03/21 21:05:41
@@ -818,6 +818,11 @@
return -1;
 }
 
+// provide a way to ove

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

[Ignacio J. Ortega]

Glups sorry..

Now i'm trying to rebuild Tomcat 3.3 with that nice build and dist
dirs.., about 10 days out of tomcat almost enterely, biffed up of work,
i will try this night ( here ) to put up all my little things.. and
start doing another dev cycle, perhaps doing it better than the last
time ;), 

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Enviado el: miércoles 21 de marzo de 2001 20:51
> Para: [EMAIL PROTECTED]
> Asunto: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime
> BodyContentImpl.java
> 
> 
> costin  01/03/21 11:51:06
> 
>   Modified:src/share/org/apache/jasper/runtime 
> BodyContentImpl.java
>   Log:
>   Lucky fix - it shows up for some JSPs generating a lot of content.
>   Nacho - nice tuneup ( remove double copy ), you forgot one line :-)
>   
>   Revision  ChangesPath
>   1.9   +4 -1  
> jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContent
> Impl.java
>   
>   Index: BodyContentImpl.java
>   ===
>   RCS file: 
> /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/B
> odyContentImpl.java,v
>   retrieving revision 1.8
>   retrieving revision 1.9
>   diff -u -r1.8 -r1.9
>   --- BodyContentImpl.java2001/03/10 01:20:23 1.8
>   +++ BodyContentImpl.java2001/03/21 19:50:51 1.9
>   @@ -113,7 +113,8 @@
>
>   if (len <= Constants.DEFAULT_BUFFER_SIZE) {
>   tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
>   -   bufferSize = bufferSize * 2;
>   +   //  bufferSize = bufferSize * 2;
>   +   bufferSize += Constants.DEFAULT_BUFFER_SIZE;
>   } else {
>   tmp = new char [bufferSize + len];
>   bufferSize += len;
>   @@ -179,6 +180,8 @@
>   if (len >= bufferSize - nextChar)
>   reAllocBuff(len);
>
>   +   //System.out.println("XXX " + off + " " + (off+len) + " " +
>   +   // nextChar + " " + bufferSize + " "+  cb.length);
>s.getChars(off, off + len, cb, nextChar);
>   nextChar += len;
>}
>   
>   
>   
> 

RE: [Bug 1059] Changed - JSP pages fail to compile when referencing classes from apps classloader

[Craig R. McClanahan]

On Wed, 21 Mar 2001, Arun Katkere wrote:

> I apologize for not mentioning the version number. I guess I am used to
> selecting the version I am reporting against and didn't remember to type it
> in the description.
> 
> Can someone add an entry for Tomcat 3.3m2 in bugzilla? That is a little less
> error prone than expecting folks to enter the version number in bug
> description.
> 

Done.  I also added separate entries for the 3.2.x and 3.3.x nightly
builds, to help error reports point at the right thing.

> -arun
> 

Craig McClanahan

Bugzilla issues

[Ignacio J. Ortega]

Hola a todos:

There are so many Tomcat 3/Jasper bugs and the component itself assigned
to Justyna Horward, it seems Justyna will not do much to help us with
3.X, if nobody complaints, if nobody complaints i will make somebody
responsible of that component...( myself as a last resort to contact
reporters at least )

Who wants to volunteer to own the Jasper component on Tomcat 3?

Casey,  Mel or Marc perhaps? 

Another issue on bugzilla, It's time for creating the 3.3 version on
bugzilla? I think people does not know where to put the bugs relate dto
3.3, and it's starting to use unknown for 3.3 .., with 2 milestones out
in the wild, we can think on add 3.3 version to Bugzilla, if nobody
complaints i will do that tomorrow.

Any comments will be highly appreciatted...

Saludos ,
Ignacio J. Ortega

Re: bug in Jasper - bad lookups to Constants.getString()

[Mel Martinez]

Would the following be an acceptable solution?

We change the
Constants.message(key,args,verbosityLevel) method
behavior so that if getString(key,args) throws
a missing resource exception that it logs using the
key itself as the log message. Note that this would
also require changing the getString() method to throw
the MissingResourceException instead of the Error
object that it currently throws.  

Looking at this, I am not sure why an Error is being
thrown here (in Constants.getString()).  If Jasper is
operating in JspServlet mode inside some other
container (i.e. WebLogic, JRun, whatever) then should
it necessarily throw an Error?  According to the spec,
Errors are reserved for conditions that are so serious
that they should normally not be caught by the
application.  I.E., they should bring the JVM down. 
The fact that Jasper (a servlet) is unable to find a
String in it's resource file sounds more like enough
error to throw a RuntimeException or even a
ServletException, but not an Error.  That would allow
the containing ServletEngine to handl the error to
Jasper without bringing down other servlets - without
having to catch 'Error'.

I think the right way to handle this is to change the
getString() to just throw the
MissingResourceException.  This requires no change to
the interfaces.

Then in org.apache.jasper.Constants change message()
to:

public static final void message(
   String key, 
   Object[] args, 
   int
verbosityLevel){
if (jasperLog == null)
  jasperLog = Log.getLog("JASPER_LOG", null);

if (jasperLog != null){
  try{
  jasperLog.log(
getString(key,args),
verbosityLevel);
  }catch(MissingResourceException e){
  jasperLog.log(
key,verbosityLevel);
  }
}


This should work 99% of the time the way you describe
with much less pain in implementation.

Feedback welcome.  If no one sends a -1 on this, I can
put this patch in fairly rapidly in tc3.3.

Mel


--- "Julien, Timothy" <[EMAIL PROTECTED]> wrote:
> I believe there is a bug in Jasper when resources
> (such as web.xml's dtd)
> can't be loaded.
> The basic problem is that keys are getting passed
> into Constants.getString()
> which aren't keys in the message resources file. 
> This happens because of
> some exception handling, which basically constructs
> an invalid key - namely,
> a *value* in the message resources file.
> 
> JspUtil.parseXMLDocJaxp(String, InputStream)
> {
>   try
>   {
>   ...
>   }
>   catch(IOException io)
>   {
> throw new
>
JasperException(Constants.getString("jsp.error.parse.xml",
> new Object[] {
> uri, io.toString()
> }));
>   }
> }
> and then lower down the call stack:
> 
> public TldLocationsCache(ServletContext ctxt)
> {
>  mappings = new Hashtable();
>  try
>  {
>  processWebDotXml(ctxt);
>  processJars(ctxt);
>  }
>  catch(JasperException ex)
>  {
>  Constants.message(ex.getMessage(), 1);
>  }
> }
> 
> The trouble is that ex.getMessage() here contains a
> *value* from the message
> resource file, (as looked up in the first caught
> Exception) not a *key*.
> 
> One fix would be in JspUtil.parseXMLDocJaxp(String,
> InputStream) to pass
> only the key (jsp.error.parse.xml) as the
> JasperException's message - and
> delay the lookup.  But then you lose some
> information (i.e., io.String()).
> 
> Maybe a better solution is to set a flag on
> JasperException which marks its
> message as being either key or value - so that
> Constants.getString can be
> called only when necessary.  I realize this would
> effect alot of code.
> 
> anyway, I'm happy to help in any way with the fix.
> Tim Julien
> HP Middleware
> 
> 


__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

http 1.0 timeout patch

[GOMEZ Henri]

Hi,

I notice you corrected the patch which is a good thing
but settings timeout to 5mn (300s) is a little too high
for an http 1.0 connection. The timeout could be as low as 15s.
The timeout is activated if you have more that 15s between 2 
read() and since connector read stream byte by byte.

300s is valid for http 1.1 connection with keep-alive.
I'll commit the patch for 3.3 but with a 15 seconds timeout ;-)

Si la fortune vient en dormant, ça n'empêche pas les emmerdements de venir
au réveil.
-- Pierre Dac

>-Original Message-
>From: Glenn Nielsen [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, March 21, 2001 4:14 PM
>To: [EMAIL PROTECTED]
>Subject: Re: mod_webapp status?
>
>
>"Pier P. Fumagalli" wrote:
>> 
>> jean-frederic clere <[EMAIL PROTECTED]> wrote:
>> 
>> > "Eric L. Anderson" wrote:
>> >>
>> >> What is the current status of mod_webapp? I have tried 
>building the connector
>> >> from cvs but the build fails with webapplib. The errors 
>seem to indicate
>> >> there
>> >> are some missing source files.
>> >>
>> >> wa.c:69: `wa_connections' undeclared (first use in this function)
>> >> wa.c:69: (Each undeclared identifier is reported only once
>> >> wa.c:69: for each function it appears in.)
>> >> wa.c:72: `cb' undeclared (first use in this function)
>> >> wa.c:73: `wa_callbacks' undeclared (first use in this function)
>> >>
>> >> I can not find any trace of an actual definition of 
>"wa_connections" in any
>> >> of the source files.
>> >
>> > ? It is in "webapplib/wa_connection.c"
>> >
>> >>
>> >> --
>> >> Eric L. Anderson
>> >> [EMAIL PROTECTED]
>> >
>> > I have also problems with mod_webapp.
>> >
>> > Pier has changed a lot of things, you will have to little.
>> 
>> I'm rewriting it using APR... As we speak...
>> 
>> Pier (under the snow in Dublin)
>> 
>
>APR is for Apache 2.0, correct?  What about Apache 1.3?
>
>What _is_ the status of mod_webapp/WARP, this is a critical componenet
>for Tocmat 4.  Tomcat 4 is useless to me without an Apache connector.
>
>Regards,
>
>Glenn
>
>--
>Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
>MOREnet System Programming   |  * if iz ina coment.  |
>Missouri Research and Education Network  |  */   |
>--
>

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

[Casey Lucas]

Just curious... why did you take out the buffer size double?  Is that too
much memory to sacrifice?  Someone ? recently sent this in as a performance
improvement patch.

You know I love anything that makes tags faster. :)

-Casey

[EMAIL PROTECTED] wrote:
> 
> costin  01/03/21 11:51:06
> 
>   Modified:src/share/org/apache/jasper/runtime BodyContentImpl.java
>   Log:
>   Lucky fix - it shows up for some JSPs generating a lot of content.
>   Nacho - nice tuneup ( remove double copy ), you forgot one line :-)
> 
>   Revision  ChangesPath
>   1.9   +4 -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.8
>   retrieving revision 1.9
>   diff -u -r1.8 -r1.9
>   --- BodyContentImpl.java  2001/03/10 01:20:23 1.8
>   +++ BodyContentImpl.java  2001/03/21 19:50:51 1.9
>   @@ -113,7 +113,8 @@
> 
> if (len <= Constants.DEFAULT_BUFFER_SIZE) {
> tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
>   - bufferSize = bufferSize * 2;
>   + //  bufferSize = bufferSize * 2;
>   + bufferSize += Constants.DEFAULT_BUFFER_SIZE;
> } else {
> tmp = new char [bufferSize + len];
> bufferSize += len;
>   @@ -179,6 +180,8 @@
> if (len >= bufferSize - nextChar)
> reAllocBuff(len);
> 
>   + //System.out.println("XXX " + off + " " + (off+len) + " " +
>   + // nextChar + " " + bufferSize + " "+  cb.length);
>s.getChars(off, off + len, cb, nextChar);
> nextChar += len;
>}
> 
> 
>

cvs commit: jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/compressionFilters - New directory

[amyroh]

amyroh  01/03/21 13:24:37

  jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/compressionFilters - New 
directory

cvs commit: jakarta-tomcat-4.0/webapps/examples/WEB-INF web.xml

[amyroh]

amyroh  01/03/21 13:31:47

  Modified:webapps/examples/WEB-INF web.xml
  Log:
  Add compression filter and test servlet mapping
  
  Revision  ChangesPath
  1.10  +40 -0 jakarta-tomcat-4.0/webapps/examples/WEB-INF/web.xml
  
  Index: web.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/WEB-INF/web.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- web.xml   2000/12/23 20:36:26 1.9
  +++ web.xml   2001/03/21 21:31:46 1.10
  @@ -28,6 +28,20 @@
   filters.RequestDumperFilter
   
   
  +
  +Compression Filter
  +compressionFilters.CompressionFilter
  +
  +
  +  compressionThreshold
  +  10
  +
  +
  +  debug
  +  1
  +
  +
  +
   
   
   Servlet Mapped Filter
  @@ -37,6 +51,13 @@
   Path Mapped Filter
/servlet/*
   
  +
  +
  +  Compression Filter
  +  /*
  + 
  +
  +
   

RE: http 1.0 timeout patch

[Marc Saegesser]

I picked 5 minutes because that seemed to be the default timeout for Apache
httpd.  If I open telnet session to Apache and never enter any data the
connection times out after 5 minutes.

In Apache this is configured in httpd.conf as

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300


> -Original Message-
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 4:01 PM
> To: [EMAIL PROTECTED]
> Cc: Marc Saegesser
> Subject: http 1.0 timeout patch
>
>
> Hi,
>
> I notice you corrected the patch which is a good thing
> but settings timeout to 5mn (300s) is a little too high
> for an http 1.0 connection. The timeout could be as low as 15s.
> The timeout is activated if you have more that 15s between 2
> read() and since connector read stream byte by byte.
>
> 300s is valid for http 1.1 connection with keep-alive.
> I'll commit the patch for 3.3 but with a 15 seconds timeout ;-)
>
> Si la fortune vient en dormant, ça n'empêche pas les emmerdements de venir
> au réveil.
> -- Pierre Dac
>
> >-Original Message-
> >From: Glenn Nielsen [mailto:[EMAIL PROTECTED]]
> >Sent: Wednesday, March 21, 2001 4:14 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: mod_webapp status?
> >
> >
> >"Pier P. Fumagalli" wrote:
> >>
> >> jean-frederic clere <[EMAIL PROTECTED]> wrote:
> >>
> >> > "Eric L. Anderson" wrote:
> >> >>
> >> >> What is the current status of mod_webapp? I have tried
> >building the connector
> >> >> from cvs but the build fails with webapplib. The errors
> >seem to indicate
> >> >> there
> >> >> are some missing source files.
> >> >>
> >> >> wa.c:69: `wa_connections' undeclared (first use in this function)
> >> >> wa.c:69: (Each undeclared identifier is reported only once
> >> >> wa.c:69: for each function it appears in.)
> >> >> wa.c:72: `cb' undeclared (first use in this function)
> >> >> wa.c:73: `wa_callbacks' undeclared (first use in this function)
> >> >>
> >> >> I can not find any trace of an actual definition of
> >"wa_connections" in any
> >> >> of the source files.
> >> >
> >> > ? It is in "webapplib/wa_connection.c"
> >> >
> >> >>
> >> >> --
> >> >> Eric L. Anderson
> >> >> [EMAIL PROTECTED]
> >> >
> >> > I have also problems with mod_webapp.
> >> >
> >> > Pier has changed a lot of things, you will have to little.
> >>
> >> I'm rewriting it using APR... As we speak...
> >>
> >> Pier (under the snow in Dublin)
> >>
> >
> >APR is for Apache 2.0, correct?  What about Apache 1.3?
> >
> >What _is_ the status of mod_webapp/WARP, this is a critical componenet
> >for Tocmat 4.  Tomcat 4 is useless to me without an Apache connector.
> >
> >Regards,
> >
> >Glenn
> >
> >--
> >Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> >MOREnet System Programming   |  * if iz ina coment.  |
> >Missouri Research and Education Network  |  */   |
> >--
> >

Re: [PATCH] [Bug 1001] - available() method on ServletInputStreamalways returns 0

[cmanolache]

Mike, 

I'm not sure I understand ( not your mail - the "available" definition ).

Isn't availabe supposed to return how many bytes can be returned without a
read() on the "primary" source ( that would block ) ? 

What you describe is slightly different - and I'm not sure it's a good
idea. In any case, I would prefer the second choice - have the protocol
return what it has in it's buffers ( if any ). 

Of course, a big question is what is available :-) If the data has been
read by Apache but not yet sent to tomcat - is it available ? Probably so
( AFAIK this shouldn't happen - actual read from network is driven by a
tomcat request and no data is buffered on apache ). But that would be a
bit too complex even for 3.3 ( but may be implemented in a future ajp14 )

I don't think this would have any significant impact on code stability -
since you replace a method that returns 0 to something a bit more acurate,
and I see no problem with adding a patch to 3.3 ( 3.2 is quite close to 
a release, it's up to Marc to decide ). But I'm a bit concerned about the
corectness of the result.


Costin  




On Wed, 21 Mar 2001, Mike Anderson wrote:

> I noticed that this bug was marked RESOLVED/LATER and was wondering if there was any 
>way to get this into 3.2.2 since that is the version that is closest to being 
>released.  I've already found 2 ways to fix this issue but am willing to abide by the 
>groups decision and concentrate on getting this into the 3.3 release instead.
> The 2 ways to fix this are:
> 
> 1.  In BufferedServletInputStream, implement an available() method that returns 
>limit - bytesRead or 0 whichever is greater.  The limit class variable is set to the 
>value of the Content-Length header and bytesRead is the number of bytes read since 
>limit was set (see the attached diff1.txt).  This is the easy fix but doesn't address 
>the feature of available that says it will return the number of bytes that can be 
>read "without blocking".  Obviously, if there is a large amount of data, a read will 
>most likely block at some point depending on how much is asked for, however this 
>prevents a condition where one of the adapters returns 0 because a read hasn't 
>actually been requested from the webserver.
> 
> 2.  Update BufferedServletInputStream to call reqA.available and then update the 
>following files to provide this interface:
>   Request.java
>   RequestImpl.java
>   HttpRequestAdapter.java
>   Ajp12ConnectionHandler.java
>   Ajp13ConnectorRequest.java
>   JNIConnectionHandler.java
>   MsgConnector.java
>   TcpConnector.java
> Each of these classes would need to provide an appropriate available() method.  I've 
>also done the work on these files as well (see the attached diff2.txt) but noticed 
>that since some of the protocols (particularly AJP13) actually have to request a read 
>to fill their internal buffer, the adapter (i.e. Ajp13ConnectorRequest.java) will 
>return a 0 if doRead is called and it exactly empties the internal buffer.  Also the 
>JNIRequestAdapter (in JNIConnectionHandler.java) makes a native call back into the 
>webserver to do the reads and so available is implemented similar to #1 above; it 
>just returns the max of contentLength - bytesRead or 0.  This was because I'm not 
>sure of a way to imp
> 
> After testing both of these, implementation 1 is actually faster and more reliable.  
>Typically if someone is calling available and they get back a 0, they would block the 
>thread anyways and so it makes some sense to let it block on the read plus it gets 
>around the issue of an adapter requiring one of it's read methods to be called to 
>actually have something available.
> 
> Any response positive or negative would be appreciated so that I know where to focus 
>my energy (i.e. 3.2.2 or 3.3).
> 
> 
> 
> 

RE: to trim or not to trim (was Re: cvs commit: jakarta-tomcat/sr c/share/org/apache/tomcat/util FileUtil.java)

[Arieh Markel]

> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> list-help: 
> list-unsubscribe: 
> list-post: 
> Delivered-To: mailing list [EMAIL PROTECTED]
> From: Larry Isaacs <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: RE: to trim or not to trim (was Re: cvs commit: jakarta-tomcat/sr 
c/share/org/apache/tomcat/util FileUtil.java)
> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
> 

> 
> The trim() was removed to fix a security vulnerability that can
> occur if the URL ends with ".jsp%20".  This results in the JSP
> being served statically.  See Bugzilla Bug #748.
> 
> Where would valid spaces or CRLF come from?  Perhaps we can look
> for a better place to trim them.  Doing this in patch() means
> that some portions of Tomcat will see a request that is
> technically different from what other portions see.

I will remove the 'trim()' call.

Arieh

> 
> Cheers,
> Larry
> 
> > 
> > Have you seen any problem with the current version ?
> > 
> > Other opinions ?
> > 
> > Thanks,
> > 
> > Arieh
> > 
> > > 
> > > Yoshiyuki Karezaki   [EMAIL PROTECTED]
> > 
> > --
> >  Arieh Markel   Sun Microsystems Inc.
> >  Network Storage500 Eldorado Blvd. MS 
> > UBRM11-194
> >  e-mail: [EMAIL PROTECTED]   Broomfield, CO 80021
> >  Pray for snow  Phone: (303) 272-8547 x78547
> >  (e-mail me with subject SEND PUBLIC KEY to get public key)
> > 

--
 Arieh Markel   Sun Microsystems Inc.
 Network Storage500 Eldorado Blvd. MS UBRM11-194
 e-mail: [EMAIL PROTECTED]   Broomfield, CO 80021
 Pray for snow  Phone: (303) 272-8547 x78547
 (e-mail me with subject SEND PUBLIC KEY to get public key)

RE: mod_webapp status?

[GOMEZ Henri]

>> I'm rewriting it using APR... As we speak...
>> 
>> Pier (under the snow in Dublin)
>> 
>

APR is a great piece of code but it will restrict Tomcat
to have only one front-end, Apache Web Server. 

A solution will be to add ajp13 support to Tomcat 4.0.

I saw 3 main advantages :

1) Tomcat 4.0 could be used with NES, IIS, Apache
   and you'll be able to replace Tomcat 3.2.x by
   Tomcat 4.0

2) Less pression, since a working a stable Apache 
   connector is really needed for the TC 4.0 startup

3) We could see how to use mod_webapp in TC 3.3


Weather announce:

Chambery is under rain, but no snow yet in town ;-)

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

[arieh]

arieh   01/03/21 14:23:08

  Modified:src/share/org/apache/tomcat/util Tag: tomcat_32
FileUtil.java
  Log:
  Remove the trim() call.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.9.2.8   +4 -4  
jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/FileUtil.java
  
  Index: FileUtil.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/FileUtil.java,v
  retrieving revision 1.9.2.7
  retrieving revision 1.9.2.8
  diff -u -r1.9.2.7 -r1.9.2.8
  --- FileUtil.java 2001/03/16 23:39:50 1.9.2.7
  +++ FileUtil.java 2001/03/21 22:23:06 1.9.2.8
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/FileUtil.java,v 
1.9.2.7 2001/03/16 23:39:50 arieh Exp $
  - * $Revision: 1.9.2.7 $
  - * $Date: 2001/03/16 23:39:50 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/FileUtil.java,v 
1.9.2.8 2001/03/21 22:23:06 arieh Exp $
  + * $Revision: 1.9.2.8 $
  + * $Date: 2001/03/21 22:23:06 $
*
* 
*
  @@ -228,7 +228,7 @@
   }
   
   public static String patch(String path) {
  - String patchPath = path.trim();
  + String patchPath = path;
   
// Move drive spec to the front of the path
if (patchPath.length() >= 3 &&
  
  
  

RE: http 1.0 timeout patch

[GOMEZ Henri]

>I picked 5 minutes because that seemed to be the default 
>timeout for Apache
>httpd.  If I open telnet session to Apache and never enter any data the
>connection times out after 5 minutes.
>
>In Apache this is configured in httpd.conf as
>
>#
># Timeout: The number of seconds before receives and sends time out.
>#
>Timeout 300

Yep, but it's a value for both http 1.0 and 1.1. 
I really find that 300s is a long period to wait for.

I'm waiting for answer for Apache HTTPD gurus and will
tell you more later but I'll commit the patch to TC 3.3
with 15s as default and add getter/setter functions to
let user set it in server.xml
 
 

RE: Bugzilla issues

[Ignacio J. Ortega]

Maillist is so slowww this days... :)

Thanks Craig..

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
> Enviado el: miércoles 21 de marzo de 2001 22:43
> Para: 'tomcat-dev'
> Asunto: Bugzilla issues
> 
> 
> Hola a todos:
> 
> There are so many Tomcat 3/Jasper bugs and the component 
> itself assigned
> to Justyna Horward, it seems Justyna will not do much to help us with
> 3.X, if nobody complaints, if nobody complaints i will make somebody
> responsible of that component...( myself as a last resort to contact
> reporters at least )
> 
> Who wants to volunteer to own the Jasper component on Tomcat 3?
> 
> Casey,  Mel or Marc perhaps? 
> 
> Another issue on bugzilla, It's time for creating the 3.3 version on
> bugzilla? I think people does not know where to put the bugs 
> relate dto
> 3.3, and it's starting to use unknown for 3.3 .., with 2 
> milestones out
> in the wild, we can think on add 3.3 version to Bugzilla, if nobody
> complaints i will do that tomorrow.
> 
> Any comments will be highly appreciatted...
>   
> Saludos ,
> Ignacio J. Ortega
> 

Re: bug in Jasper - bad lookups to Constants.getString()

[cmanolache]

On Wed, 21 Mar 2001, Mel Martinez wrote:

> Would the following be an acceptable solution?
> 
> We change the
> Constants.message(key,args,verbosityLevel) method
> behavior so that if getString(key,args) throws
> a missing resource exception that it logs using the
> key itself as the log message. Note that this would
> also require changing the getString() method to throw
> the MissingResourceException instead of the Error
> object that it currently throws.  

+1 ( please check the tomcat side is doing the
same - we never had the problem but you never know )

Would StringManager be a better place for the fix ?

Costin

> 
> Looking at this, I am not sure why an Error is being
> thrown here (in Constants.getString()).  If Jasper is
> operating in JspServlet mode inside some other
> container (i.e. WebLogic, JRun, whatever) then should
> it necessarily throw an Error?  According to the spec,
> Errors are reserved for conditions that are so serious
> that they should normally not be caught by the
> application.  I.E., they should bring the JVM down. 
> The fact that Jasper (a servlet) is unable to find a
> String in it's resource file sounds more like enough
> error to throw a RuntimeException or even a
> ServletException, but not an Error.  That would allow
> the containing ServletEngine to handl the error to
> Jasper without bringing down other servlets - without
> having to catch 'Error'.
> 
> I think the right way to handle this is to change the
> getString() to just throw the
> MissingResourceException.  This requires no change to
> the interfaces.
> 
> Then in org.apache.jasper.Constants change message()
> to:
> 
> public static final void message(
>String key, 
>Object[] args, 
>int
> verbosityLevel){
>   if (jasperLog == null)
>   jasperLog = Log.getLog("JASPER_LOG", null);
> 
>   if (jasperLog != null){
>   try{
> jasperLog.log(
> getString(key,args),
> verbosityLevel);
>   }catch(MissingResourceException e){
>   jasperLog.log(
> key,verbosityLevel);
>   }
> }
> 
> 
> This should work 99% of the time the way you describe
> with much less pain in implementation.
> 
> Feedback welcome.  If no one sends a -1 on this, I can
> put this patch in fairly rapidly in tc3.3.
> 
> Mel
> 
> 
> --- "Julien, Timothy" <[EMAIL PROTECTED]> wrote:
> > I believe there is a bug in Jasper when resources
> > (such as web.xml's dtd)
> > can't be loaded.
> > The basic problem is that keys are getting passed
> > into Constants.getString()
> > which aren't keys in the message resources file. 
> > This happens because of
> > some exception handling, which basically constructs
> > an invalid key - namely,
> > a *value* in the message resources file.
> > 
> > JspUtil.parseXMLDocJaxp(String, InputStream)
> > {
> > try
> > {
> > ...
> > }
> > catch(IOException io)
> >   {
> > throw new
> >
> JasperException(Constants.getString("jsp.error.parse.xml",
> > new Object[] {
> > uri, io.toString()
> > }));
> >   }
> > }
> > and then lower down the call stack:
> > 
> > public TldLocationsCache(ServletContext ctxt)
> > {
> >  mappings = new Hashtable();
> >  try
> >  {
> >  processWebDotXml(ctxt);
> >  processJars(ctxt);
> >  }
> >  catch(JasperException ex)
> >  {
> >  Constants.message(ex.getMessage(), 1);
> >  }
> > }
> > 
> > The trouble is that ex.getMessage() here contains a
> > *value* from the message
> > resource file, (as looked up in the first caught
> > Exception) not a *key*.
> > 
> > One fix would be in JspUtil.parseXMLDocJaxp(String,
> > InputStream) to pass
> > only the key (jsp.error.parse.xml) as the
> > JasperException's message - and
> > delay the lookup.  But then you lose some
> > information (i.e., io.String()).
> > 
> > Maybe a better solution is to set a flag on
> > JasperException which marks its
> > message as being either key or value - so that
> > Constants.getString can be
> > called only when necessary.  I realize this would
> > effect alot of code.
> > 
> > anyway, I'm happy to help in any way with the fix.
> > Tim Julien
> > HP Middleware
> > 
> > 
> 
> 
> __
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail. 
> http://personal.mail.yahoo.com/
> 

Re: Bugzilla issues

[Mel Martinez]

--- "Ignacio J. Ortega" <[EMAIL PROTECTED]> wrote:
> Hola a todos:
> 
> There are so many Tomcat 3/Jasper bugs and the
> component itself assigned
> to Justyna Horward, it seems Justyna will not do
> much to help us with
> 3.X, if nobody complaints, if nobody complaints i
> will make somebody
> responsible of that component...( myself as a last
> resort to contact
> reporters at least )
> 
> Who wants to volunteer to own the Jasper component
> on Tomcat 3?
> 
> Casey,  Mel or Marc perhaps? 
> 

nacho,

I will be glad to help as much as possible on tc3.3
Jasper, as that module is pretty important to The Damn
Day Job(tm) and i'm much more familiar with Jasper
than any other part of the codebase.  I'm a bit of a
newbie still with the tomcat project in general
though, so don't ask me to manage releases or anything
like that.  I'm also still learning bugzilla.

I guess that qualifies as a "I'll only own it if no
one else wants it".  I think I might be more valuable
as a #2 guy here for now.

mel (walking backwards ...)


__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

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

[Casey Lucas]

Casey Lucas wrote:
> 
> Just curious... why did you take out the buffer size double?  Is that too
> much memory to sacrifice?  Someone ? recently sent this in as a performance
> improvement patch.

Of course the line

tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];

also needs to be tweeked, if you add the 2X buffer.

> 
> You know I love anything that makes tags faster. :)
> 
> -Casey
> 
> [EMAIL PROTECTED] wrote:
> >
> > costin  01/03/21 11:51:06
> >
> >   Modified:src/share/org/apache/jasper/runtime BodyContentImpl.java
> >   Log:
> >   Lucky fix - it shows up for some JSPs generating a lot of content.
> >   Nacho - nice tuneup ( remove double copy ), you forgot one line :-)
> >
> >   Revision  ChangesPath
> >   1.9   +4 -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.8
> >   retrieving revision 1.9
> >   diff -u -r1.8 -r1.9
> >   --- BodyContentImpl.java  2001/03/10 01:20:23 1.8
> >   +++ BodyContentImpl.java  2001/03/21 19:50:51 1.9
> >   @@ -113,7 +113,8 @@
> >
> > if (len <= Constants.DEFAULT_BUFFER_SIZE) {
> > tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
> >   - bufferSize = bufferSize * 2;
> >   + //  bufferSize = bufferSize * 2;
> >   + bufferSize += Constants.DEFAULT_BUFFER_SIZE;
> > } else {
> > tmp = new char [bufferSize + len];
> > bufferSize += len;
> >   @@ -179,6 +180,8 @@
> > if (len >= bufferSize - nextChar)
> > reAllocBuff(len);
> >
> >   + //System.out.println("XXX " + off + " " + (off+len) + " " +
> >   + // nextChar + " " + bufferSize + " "+  cb.length);
> >s.getChars(off, off + len, cb, nextChar);
> > nextChar += len;
> >}
> >
> >
> >

Re: http 1.0 timeout patch

[Casey Lucas]

I'm -1 on the 15 sec.  You never know what type of network a client
may be traversing.

-Casey

GOMEZ Henri wrote:
> 
> Hi,
> 
> I notice you corrected the patch which is a good thing
> but settings timeout to 5mn (300s) is a little too high
> for an http 1.0 connection. The timeout could be as low as 15s.
> The timeout is activated if you have more that 15s between 2
> read() and since connector read stream byte by byte.
> 
> 300s is valid for http 1.1 connection with keep-alive.
> I'll commit the patch for 3.3 but with a 15 seconds timeout ;-)
> 
> Si la fortune vient en dormant, ça n'empêche pas les emmerdements de venir
> au réveil.
> -- Pierre Dac
> 
> >-Original Message-
> >From: Glenn Nielsen [mailto:[EMAIL PROTECTED]]
> >Sent: Wednesday, March 21, 2001 4:14 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: mod_webapp status?
> >
> >
> >"Pier P. Fumagalli" wrote:
> >>
> >> jean-frederic clere <[EMAIL PROTECTED]> wrote:
> >>
> >> > "Eric L. Anderson" wrote:
> >> >>
> >> >> What is the current status of mod_webapp? I have tried
> >building the connector
> >> >> from cvs but the build fails with webapplib. The errors
> >seem to indicate
> >> >> there
> >> >> are some missing source files.
> >> >>
> >> >> wa.c:69: `wa_connections' undeclared (first use in this function)
> >> >> wa.c:69: (Each undeclared identifier is reported only once
> >> >> wa.c:69: for each function it appears in.)
> >> >> wa.c:72: `cb' undeclared (first use in this function)
> >> >> wa.c:73: `wa_callbacks' undeclared (first use in this function)
> >> >>
> >> >> I can not find any trace of an actual definition of
> >"wa_connections" in any
> >> >> of the source files.
> >> >
> >> > ? It is in "webapplib/wa_connection.c"
> >> >
> >> >>
> >> >> --
> >> >> Eric L. Anderson
> >> >> [EMAIL PROTECTED]
> >> >
> >> > I have also problems with mod_webapp.
> >> >
> >> > Pier has changed a lot of things, you will have to little.
> >>
> >> I'm rewriting it using APR... As we speak...
> >>
> >> Pier (under the snow in Dublin)
> >>
> >
> >APR is for Apache 2.0, correct?  What about Apache 1.3?
> >
> >What _is_ the status of mod_webapp/WARP, this is a critical componenet
> >for Tocmat 4.  Tomcat 4 is useless to me without an Apache connector.
> >
> >Regards,
> >
> >Glenn
> >
> >--
> >Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> >MOREnet System Programming   |  * if iz ina coment.  |
> >Missouri Research and Education Network  |  */   |
> >--
> >

RE: Bugzilla issues

[Marc Saegesser]

Yep, the Jakarta mailing lists have been running way behind recently.

You can put me down as the default owner for new Jasper reports for
Tomcat-3.  The last few weeks have given me a fair amount of practice at
this stuff.

> -Original Message-
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 4:27 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Bugzilla issues
>
>
> Maillist is so slowww this days... :)
>
> Thanks Craig..
>
> Saludos ,
> Ignacio J. Ortega
>
>
> > -Mensaje original-
> > De: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
> > Enviado el: miércoles 21 de marzo de 2001 22:43
> > Para: 'tomcat-dev'
> > Asunto: Bugzilla issues
> >
> >
> > Hola a todos:
> >
> > There are so many Tomcat 3/Jasper bugs and the component
> > itself assigned
> > to Justyna Horward, it seems Justyna will not do much to help us with
> > 3.X, if nobody complaints, if nobody complaints i will make somebody
> > responsible of that component...( myself as a last resort to contact
> > reporters at least )
> >
> > Who wants to volunteer to own the Jasper component on Tomcat 3?
> >
> > Casey,  Mel or Marc perhaps?
> >
> > Another issue on bugzilla, It's time for creating the 3.3 version on
> > bugzilla? I think people does not know where to put the bugs
> > relate dto
> > 3.3, and it's starting to use unknown for 3.3 .., with 2
> > milestones out
> > in the wild, we can think on add 3.3 version to Bugzilla, if nobody
> > complaints i will do that tomorrow.
> >
> > Any comments will be highly appreciatted...
> >
> > Saludos ,
> > Ignacio J. Ortega
> >

Re: bug in Jasper - bad lookups to Constants.getString()

[Mel Martinez]

--- [EMAIL PROTECTED] wrote:
> On Wed, 21 Mar 2001, Mel Martinez wrote:
> 
> > Would the following be an acceptable solution?
> > 
> > We change the
> > Constants.message(key,args,verbosityLevel) method
> > behavior so that if getString(key,args) throws
> > a missing resource exception that it logs using
> the
> > key itself as the log message. Note that this
> would
> > also require changing the getString() method to
> throw
> > the MissingResourceException instead of the Error
> > object that it currently throws.  
> 
> +1 ( please check the tomcat side is doing the
> same - we never had the problem but you never know )
> 
> Would StringManager be a better place for the fix ?
> 
> Costin

Possibly.  I'll take a look tonight.  I have to run
home now to watch my daughter watch disney movies and
then run around the house carrying her while she
pretends to fly for a few hours.  :-)

Later,

Mel


> 
> > 
> > Looking at this, I am not sure why an Error is
> being
> > thrown here (in Constants.getString()).  If Jasper
> is
> > operating in JspServlet mode inside some other
> > container (i.e. WebLogic, JRun, whatever) then
> should
> > it necessarily throw an Error?  According to the
> spec,
> > Errors are reserved for conditions that are so
> serious
> > that they should normally not be caught by the
> > application.  I.E., they should bring the JVM
> down. 
> > The fact that Jasper (a servlet) is unable to find
> a
> > String in it's resource file sounds more like
> enough
> > error to throw a RuntimeException or even a
> > ServletException, but not an Error.  That would
> allow
> > the containing ServletEngine to handl the error to
> > Jasper without bringing down other servlets -
> without
> > having to catch 'Error'.
> > 
> > I think the right way to handle this is to change
> the
> > getString() to just throw the
> > MissingResourceException.  This requires no change
> to
> > the interfaces.
> > 
> > Then in org.apache.jasper.Constants change
> message()
> > to:
> > 
> > public static final void message(
> >String key, 
> >Object[] args, 
> >int
> > verbosityLevel){
> > if (jasperLog == null)
> >   jasperLog = Log.getLog("JASPER_LOG",
> null);
> > 
> > if (jasperLog != null){
> >   try{
> >   jasperLog.log(
> > getString(key,args),
> > verbosityLevel);
> >   }catch(MissingResourceException e){
> >   jasperLog.log(
> > key,verbosityLevel);
> >   }
> > }
> > 
> > 
> > This should work 99% of the time the way you
> describe
> > with much less pain in implementation.
> > 
> > Feedback welcome.  If no one sends a -1 on this, I
> can
> > put this patch in fairly rapidly in tc3.3.
> > 
> > Mel
> > 
> > 
> > --- "Julien, Timothy" <[EMAIL PROTECTED]>
> wrote:
> > > I believe there is a bug in Jasper when
> resources
> > > (such as web.xml's dtd)
> > > can't be loaded.
> > > The basic problem is that keys are getting
> passed
> > > into Constants.getString()
> > > which aren't keys in the message resources file.
> 
> > > This happens because of
> > > some exception handling, which basically
> constructs
> > > an invalid key - namely,
> > > a *value* in the message resources file.
> > > 
> > > JspUtil.parseXMLDocJaxp(String, InputStream)
> > > {
> > >   try
> > >   {
> > >   ...
> > >   }
> > >   catch(IOException io)
> > >   {
> > > throw new
> > >
> >
>
JasperException(Constants.getString("jsp.error.parse.xml",
> > > new Object[] {
> > > uri, io.toString()
> > > }));
> > >   }
> > > }
> > > and then lower down the call stack:
> > > 
> > > public TldLocationsCache(ServletContext ctxt)
> > > {
> > >  mappings = new Hashtable();
> > >  try
> > >  {
> > >  processWebDotXml(ctxt);
> > >  processJars(ctxt);
> > >  }
> > >  catch(JasperException ex)
> > >  {
> > >  Constants.message(ex.getMessage(), 1);
> > >  }
> > > }
> > > 
> > > The trouble is that ex.getMessage() here
> contains a
> > > *value* from the message
> > > resource file, (as looked up in the first caught
> > > Exception) not a *key*.
> > > 
> > > One fix would be in
> JspUtil.parseXMLDocJaxp(String,
> > > InputStream) to pass
> > > only the key (jsp.error.parse.xml) as the
> > > JasperException's message - and
> > > delay the lookup.  But then you lose some
> > > information (i.e., io.String()).
> > > 
> > > Maybe a better solution is to set a flag on
> > > JasperException which marks its
> > > message as being either key or value - so that
> > > Constants.getString can be
> > > called only when necessary.  I realize this
> would
> > > effect alot of code.
> > > 
> > > anyway, I'm happy to help in any way with the
> fix.
> > > Tim Julien
> > > HP Middleware
> > > 
> > > 
> > 
> > 
> > __

cvs commit: jakarta-tomcat/src/doc readme

[marcsaeg]

marcsaeg01/03/21 15:07:01

  Modified:src/doc  Tag: tomcat_32 readme
  Log:
  Another round of updates to the release notes prior to releasing
  3.2.2-beta 2
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.8.2.15  +22 -2 jakarta-tomcat/src/doc/readme
  
  Index: readme
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/readme,v
  retrieving revision 1.8.2.14
  retrieving revision 1.8.2.15
  diff -u -r1.8.2.14 -r1.8.2.15
  --- readme2001/03/09 18:51:40 1.8.2.14
  +++ readme2001/03/21 23:06:58 1.8.2.15
  @@ -1,4 +1,4 @@
  -$Id: readme,v 1.8.2.14 2001/03/09 18:51:40 marcsaeg Exp $
  +$Id: readme,v 1.8.2.15 2001/03/21 23:06:58 marcsaeg Exp $
   
   Release Notes for:
  
  @@ -82,9 +82,17 @@
   =
   5.  NEW FEATURES IN THIS RELEASE
   
  -Tomcat Version 3.2.2 is a bug release only.  No new features were added.
  +5.1 Docbase and File Based Localization
   
  +Tomcat 3.2.2 now supports a method mapping requests into localized resources
  +automatically based on the client's and the server's locale.  Localized
  +content can be organized using one directory per locale (Docbase) or
  +into a single directory the locale specified in the file names (File based).
   
  +A detailed description of this feature can be found in 
  +doc/tomcat-localization-how.html
  +
  +
   =
   6.  KNOWN BUGS AND ISSUES
   
  @@ -305,6 +313,11 @@
 -  Fix session tracking through forward().  (#504)
 -  Fix problem with getSession() overwritting the requested session ID
and related URL rewritting problems.  (#160)
  +  -  Better error reporting for load-on-startup servler load failures.  ((#489)
  +  -  Static files (e.g. .html) can how be used as the location for
  +  tags in web.xml.  (#291)
  +  -  URL encoded data in servlet paths and path info are now decoded 
  + properly. (#657)
   
   Jasper
 -  Fix for UnsupportedEncodingException due to UTF8 instead of UTF-8.  (#269)
  @@ -317,16 +330,23 @@
 -  Better error reporting if compile fails due to missing tag library.
 -  Fix thread synchronization problem that can cause page compilation to 
fail (#44).
  +  -  Fixed the defualt character encoding.  The default charset is now
  + ISO-8859-1.  (#285)
  +  -  jsp:plugin was not being expanded correctly.  (#467)
   
  +
   Connectors
 -  Fix infinite loop on invalid content-length for ajp12.  (#264)
 -  Fix infinite llop if Tomcat connector closed connection.  (#510)
 -  For ajp13 protocol, add support for multipart form encoding
and file uploads now work.
 -  Reading session ids from cookies in the load balancer. (#603) 
  +  -  HTTP connections now time out if no data is received from the 
  + client.  (#1006)
   
 IIS
-  Better error logging for startup failures.
  +
 NetWare
-  Fix for netbuf_getbytes() not supported on NetWare 5.1.
   
  
  
  

Re: Bugzilla issues

[Casey Lucas]

Hola.

I'm sure I wont have enough time to take over Jasper for 3, but I may find some
time to help out.  I'll try to take a look after I wrap up some other stuff.

-Casey

"Ignacio J. Ortega" wrote:
> 
> Hola a todos:
> 
> There are so many Tomcat 3/Jasper bugs and the component itself assigned
> to Justyna Horward, it seems Justyna will not do much to help us with
> 3.X, if nobody complaints, if nobody complaints i will make somebody
> responsible of that component...( myself as a last resort to contact
> reporters at least )
> 
> Who wants to volunteer to own the Jasper component on Tomcat 3?
> 
> Casey,  Mel or Marc perhaps?
> 
> Another issue on bugzilla, It's time for creating the 3.3 version on
> bugzilla? I think people does not know where to put the bugs relate dto
> 3.3, and it's starting to use unknown for 3.3 .., with 2 milestones out
> in the wild, we can think on add 3.3 version to Bugzilla, if nobody
> complaints i will do that tomorrow.
> 
> Any comments will be highly appreciatted...
> 
> Saludos ,
> Ignacio J. Ortega

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

[cmanolache]

On Wed, 21 Mar 2001, Casey Lucas wrote:

> 
> 
> Casey Lucas wrote:
> > 
> > Just curious... why did you take out the buffer size double?  Is that too
> > much memory to sacrifice?  Someone ? recently sent this in as a performance
> > improvement patch.

Ops :-) 

No, there is no problem with doubling the size, the fix was to match the 
new buffer size with bufSize - and I guess I picked the first value
and changed the second.

I'll revert to double size ( in both places ).

Costin

Re: http 1.0 timeout patch

[cmanolache]

What about 33 sec. ? It matches the version :-)

( seriously - does the HTTP spec have any number ? If not, can we use
whatever apache is using ? )

In any case - 300s is better than no timeout - and if it's too much we can
reduce it later ( and make it configurable anyway ).   

Costin

On Wed, 21 Mar 2001, Casey Lucas wrote:

> 
> I'm -1 on the 15 sec.  You never know what type of network a client
> may be traversing.
> 
> -Casey
> 
> GOMEZ Henri wrote:
> > 
> > Hi,
> > 
> > I notice you corrected the patch which is a good thing
> > but settings timeout to 5mn (300s) is a little too high
> > for an http 1.0 connection. The timeout could be as low as 15s.
> > The timeout is activated if you have more that 15s between 2
> > read() and since connector read stream byte by byte.
> > 
> > 300s is valid for http 1.1 connection with keep-alive.
> > I'll commit the patch for 3.3 but with a 15 seconds timeout ;-)
> > 
> > Si la fortune vient en dormant, ça n'empêche pas les emmerdements de venir
> > au réveil.
> > -- Pierre Dac
> > 
> > >-Original Message-
> > >From: Glenn Nielsen [mailto:[EMAIL PROTECTED]]
> > >Sent: Wednesday, March 21, 2001 4:14 PM
> > >To: [EMAIL PROTECTED]
> > >Subject: Re: mod_webapp status?
> > >
> > >
> > >"Pier P. Fumagalli" wrote:
> > >>
> > >> jean-frederic clere <[EMAIL PROTECTED]> wrote:
> > >>
> > >> > "Eric L. Anderson" wrote:
> > >> >>
> > >> >> What is the current status of mod_webapp? I have tried
> > >building the connector
> > >> >> from cvs but the build fails with webapplib. The errors
> > >seem to indicate
> > >> >> there
> > >> >> are some missing source files.
> > >> >>
> > >> >> wa.c:69: `wa_connections' undeclared (first use in this function)
> > >> >> wa.c:69: (Each undeclared identifier is reported only once
> > >> >> wa.c:69: for each function it appears in.)
> > >> >> wa.c:72: `cb' undeclared (first use in this function)
> > >> >> wa.c:73: `wa_callbacks' undeclared (first use in this function)
> > >> >>
> > >> >> I can not find any trace of an actual definition of
> > >"wa_connections" in any
> > >> >> of the source files.
> > >> >
> > >> > ? It is in "webapplib/wa_connection.c"
> > >> >
> > >> >>
> > >> >> --
> > >> >> Eric L. Anderson
> > >> >> [EMAIL PROTECTED]
> > >> >
> > >> > I have also problems with mod_webapp.
> > >> >
> > >> > Pier has changed a lot of things, you will have to little.
> > >>
> > >> I'm rewriting it using APR... As we speak...
> > >>
> > >> Pier (under the snow in Dublin)
> > >>
> > >
> > >APR is for Apache 2.0, correct?  What about Apache 1.3?
> > >
> > >What _is_ the status of mod_webapp/WARP, this is a critical componenet
> > >for Tocmat 4.  Tomcat 4 is useless to me without an Apache connector.
> > >
> > >Regards,
> > >
> > >Glenn
> > >
> > >--
> > >Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> > >MOREnet System Programming   |  * if iz ina coment.  |
> > >Missouri Research and Education Network  |  */   |
> > >--
> > >
> 

RE: Bugzilla issues

[Ignacio J. Ortega]

> There are so many Tomcat 3/Jasper bugs and the component 
> itself assigned
> to Justyna Horward, it seems Justyna will not do much to help us with
> 3.X, if nobody complaints, if nobody complaints i will make somebody

Justy just confirmed me, that she want to make All Jasper versions
better.., not only 4.0.. This are really great news, but i continue
thinking it's better to spread resposabilities a s much a we can, and
bugzilla components are a great way to spread such resposabilities..

Thanks all good responses to my cal, this are really great news too !!!
many thanks .. i'm glad to learn and work with all of you..all


Saludos ,
Ignacio J. Ortega

Re: [PATCH] [Bug 1001] - available() method onServletInputStreamalways returns 0

[Mike Anderson]

Costin,

Thanks for the response.  I agree that available is supposed to return how many
bytes can be returned without a read() on the "primary".  The second diff file 
has patches that implement available this way for everything except the 
JNI connector.  My only concern with this (2nd) set of patches was that the
AJP13 connector would return how much was available in it's own buffer but 
that buffer was never reloaded unless a read was requested the exhausts the
buffer and still wanted more data.  The only way I could see to get around this
was to either have available return the total number of bytes that could be read
(bad because a read will most likely block) or implement refillBuffer as an
asynchronous method that would actually fill the buffer in the background based
on some signal from the main thread.  That type of implementation could also be 
used to clean up the JNI connector as well.  I just didn't want to introduce that
level of complexity this close to release ;-)  I'll wait to here from Marc and start
looking at the 3.3 code to what it will take there.

Mike

>>> [EMAIL PROTECTED] 03/21/01 03:23PM >>>
>Mike, 
>
>I'm not sure I understand ( not your mail - the "available" definition ).
>
>Isn't availabe supposed to return how many bytes can be returned without a
>read() on the "primary" source ( that would block ) ? 
>
>What you describe is slightly different - and I'm not sure it's a good
>idea. In any case, I would prefer the second choice - have the protocol
>return what it has in it's buffers ( if any ). 
>
>Of course, a big question is what is available :-) If the data has been
>read by Apache but not yet sent to tomcat - is it available ? Probably so
>( AFAIK this shouldn't happen - actual read from network is driven by a
>tomcat request and no data is buffered on apache ). But that would be a
>bit too complex even for 3.3 ( but may be implemented in a future ajp14 )
>
>I don't think this would have any significant impact on code stability -
>since you replace a method that returns 0 to something a bit more acurate,
>and I see no problem with adding a patch to 3.3 ( 3.2 is quite close to 
>a release, it's up to Marc to decide ). But I'm a bit concerned about the
>corectness of the result.
>
>
>Costin  
>
>
>
>
>On Wed, 21 Mar 2001, Mike Anderson wrote:
>
>> I noticed that this bug was marked RESOLVED/LATER and was wondering if there was 
>any way to get this into 3.2.2 since that is the version that is closest to being 
>released.  >I've already found 2 ways to fix this issue but am willing to abide by 
>the groups decision and concentrate on getting this into the 3.3 release instead.
>> The 2 ways to fix this are:
>> 
>> 1.  In BufferedServletInputStream, implement an available() method that returns 
>limit - bytesRead or 0 whichever is greater.  The limit class variable is set to the 
>value of the Content-Length header and bytesRead is the number of bytes read since 
>limit was set (see the attached diff1.txt).  This is the easy fix but doesn't address 
>the feature of available that says it will return the number of bytes that can be 
>read "without blocking".  Obviously, if there is a large amount of data, a read will 
>most likely block at some point depending on how much is asked for, however this 
>prevents a condition where one of the adapters returns 0 because a read hasn't 
>actually been requested from the webserver.
> 
> 2.  Update BufferedServletInputStream to call reqA.available and then update the 
>following files to provide this interface:
>   Request.java
>   RequestImpl.java
>   HttpRequestAdapter.java
>   Ajp12ConnectionHandler.java
>   Ajp13ConnectorRequest.java
>   JNIConnectionHandler.java
>   MsgConnector.java
>   TcpConnector.java
> Each of these classes would need to provide an appropriate available() method.  I've 
>also done the work on these files as well (see the attached diff2.txt) but noticed 
>that since some of the protocols (particularly AJP13) actually have to request a read 
>to fill their internal buffer, the adapter (i.e. Ajp13ConnectorRequest.java) will 
>return a 0 if doRead is called and it exactly empties the internal buffer.  Also the 
>JNIRequestAdapter (in JNIConnectionHandler.java) makes a native call back into the 
>webserver to do the reads and so available is implemented similar to #1 above; it 
>just returns the max of contentLength - bytesRead or 0.  This was because I'm not 
>sure of a way to imp
> 
> After testing both of these, implementation 1 is actually faster and more reliable.  
>Typically if someone is calling available and they get back a 0, they would block the 
>thread anyways and so it makes some sense to let it block on the read plus it gets 
>around the issue of an adapter requiring one of it's read methods to be called to 
>actually have something available.
> 
> Any response positive or negative would be appreciated so that I know where to focus 
>my energy (i.e. 3.2.2 or 3.3).
> 
> 
> 
> 

another bug in Jasper - incorrect File.separator

[Julien, Timothy]

Still in the endeavor of running Jasper in another container

When making calls in ParserController.getReader() to
ServletContext.getResourceAsStream() (through JspCompilationContext), the
String that is passed in is file.toString() (where file denotes the jsp to
be translated/compiled).  The problem with that call is that File.toString()
calls File.getPath(), which replaces '/' with File.separator - which on
Windows is '\'.  However, calls to ServletContext.getResourceAsStream() must
begin with '/', per the servlet 2.2 javadocs.  Hence, getResourceAsStream()
returns null.

I've included the fix:

in org.apache.jasper.compiler.ParserController:

private InputStreamReader getReader(File file, String encoding,
String absFileName)
throws FileNotFoundException, JasperException
{
InputStream in;
InputStreamReader reader;

  try {
if (ctxt == null) {
in = new FileInputStream(file);
reader = new InputStreamReader(in, encoding);
} else {
//String fileName = ctxt.getRealPath(file.toString());

   // TDJ
   // changed file.toString( ) ->
   // absFileName
   // ServletContext.getResourceAsStream( ) requires
   // url slashes ( '/' ), not platform specific slashes
in = ctxt.getResourceAsStream(absFileName);
if (in == null) {
throw new FileNotFoundException(absFileName);
}
reader = new InputStreamReader(in, encoding);
}
return reader;
   } catch (UnsupportedEncodingException ex) {
 throw new JasperException(
Constants.getString("jsp.error.unsupported.encoding",
new Object[]{encoding}));
 }
}

Tim Julien
HP middleware

RE: Bugzilla issues

[Larry Isaacs]

At the moment, I'm the default assignee for most other Tomcat3 stuff.
It means the I get the e-mail notification when a new bug is entered.
Unfortunately, I'm not finding much time to review them and re-assign
them if appropriate.  I think we need pretty much ignore who a bug
is assigned to and step in where ever you feel inclined.  I will *not*
be offended if someone fixes a bug assigned to me.

Cheers,
Larry

> -Original Message-
> From: Ignacio J. Ortega
> To: '[EMAIL PROTECTED]'
> Sent: 3/21/01 6:38 PM
> Subject: RE: Bugzilla issues
> 
> > There are so many Tomcat 3/Jasper bugs and the component 
> > itself assigned
> > to Justyna Horward, it seems Justyna will not do much to help us with
> > 3.X, if nobody complaints, if nobody complaints i will make somebody
> 
> Justy just confirmed me, that she want to make All Jasper versions
> better.., not only 4.0.. This are really great news, but i continue
> thinking it's better to spread resposabilities a s much a we can, and
> bugzilla components are a great way to spread such resposabilities..
> 
> Thanks all good responses to my cal, this are really great news too !!!
> many thanks .. i'm glad to learn and work with all of you..all
> 
> 
> Saludos ,
> Ignacio J. Ortega

RE: Bugzilla issues

[cmanolache]

On Thu, 22 Mar 2001, Ignacio J. Ortega wrote:

> better.., not only 4.0.. This are really great news, but i continue
> thinking it's better to spread resposabilities a s much a we can, and
> bugzilla components are a great way to spread such resposabilities..

A big +1 !

Henri and Dan are a perfect example of what happens when more than one
person is working on a component. 
I don't think the goal is to fix all the bugs and improve a piece of code,  
but improve ourself and learn from other people - and for that we need
more people to work with on each component. 

Right now tomcat(3.3) is in a decent state, at least for performance and
stability - I think jasper needs a bit more attention and maybe a bit of
refactoring. 

Costin


> 
> Thanks all good responses to my cal, this are really great news too !!!
> many thanks .. i'm glad to learn and work with all of you..all
> 
> 
> Saludos ,
> Ignacio J. Ortega
> 

cvs commit: jakarta-tomcat-4.0/webapps/examples/WEB-INF web.xml

[remm]

remm01/03/21 16:49:08

  Modified:webapps/examples/WEB-INF web.xml
  Log:
  - Don't enable the compression filter by default.
  
  Revision  ChangesPath
  1.11  +2 -0  jakarta-tomcat-4.0/webapps/examples/WEB-INF/web.xml
  
  Index: web.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/WEB-INF/web.xml,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- web.xml   2001/03/21 21:31:46 1.10
  +++ web.xml   2001/03/22 00:49:05 1.11
  @@ -52,11 +52,13 @@
/servlet/*
   
   
  +
   
  +-->
   
   

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

[remm]

remm01/03/21 16:51:20

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java
  Log:
  - Add possibility to make some servlet context attributes read only. Of course,
the object can still be mutated.
  - This functionality is NOT exposed to servlets (at least to servlets which are
outside the Catalina core).
  
  Revision  ChangesPath
  1.18  +29 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
  
  Index: ApplicationContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- ApplicationContext.java   2001/03/17 00:28:01 1.17
  +++ ApplicationContext.java   2001/03/22 00:51:17 1.18
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
 1.17 2001/03/17 00:28:01 craigmcc Exp $
  - * $Revision: 1.17 $
  - * $Date: 2001/03/17 00:28:01 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
 1.18 2001/03/22 00:51:17 remm Exp $
  + * $Revision: 1.18 $
  + * $Date: 2001/03/22 00:51:17 $
*
* 
*
  @@ -111,7 +111,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.17 $ $Date: 2001/03/17 00:28:01 $
  + * @version $Revision: 1.18 $ $Date: 2001/03/22 00:51:17 $
*/
   
   public final class ApplicationContext
  @@ -202,6 +202,12 @@
   
   
   /**
  + * List of read only attributes for this context.
  + */
  +private HashMap readOnlyAttributes = new HashMap();
  +
  +
  +/**
* The Context instance with which we are associated.
*/
   private StandardContext context = null;
  @@ -248,6 +254,19 @@
   }
   
   
  +/**
  + * Set an attribute as read only.
  + */
  +public void setAttributeReadOnly(String name) {
  +
  +synchronized (attributes) {
  +if (attributes.containsKey(name))
  +readOnlyAttributes.put(name, name);
  +}
  +
  +}
  +
  +
   // - ServletContext Methods
   
   
  @@ -710,6 +729,9 @@
   
// Remove the specified attribute
synchronized (attributes) {
  +// Check for read only attribute
  +if (readOnlyAttributes.containsKey(name))
  +return;
   found = attributes.containsKey(name);
   if (found) {
   value = attributes.get(name);
  @@ -761,6 +783,9 @@
   
// Add or replace the specified attribute
synchronized (attributes) {
  +// Check for read only attribute
  +if (readOnlyAttributes.containsKey(name))
  +return;
if (attributes.get(name) != null)
replaced = true;
attributes.put(name, value);
  
  
  

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

[remm]

remm01/03/21 16:53:35

  Modified:catalina/src/share/org/apache/catalina/loader
StandardLoader.java
  Log:
  - Make the two attributes Jasper uses read only.
  - That makes the classpath attribute immutable.
  - The class loader attribute will eventually be removed.
  
  Revision  ChangesPath
  1.21  +15 -5 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardLoader.java
  
  Index: StandardLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- StandardLoader.java   2001/02/21 06:03:43 1.20
  +++ StandardLoader.java   2001/03/22 00:53:31 1.21
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
 1.20 2001/02/21 06:03:43 remm Exp $
  - * $Revision: 1.20 $
  - * $Date: 2001/02/21 06:03:43 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
 1.21 2001/03/22 00:53:31 remm Exp $
  + * $Revision: 1.21 $
  + * $Date: 2001/03/22 00:53:31 $
*
* 
*
  @@ -94,6 +94,10 @@
   import org.apache.catalina.LifecycleListener;
   import org.apache.catalina.Loader;
   import org.apache.catalina.Logger;
  +// FIXME : Define a new "servlet context" interface to void directly referncing
  +// the ApplicationContext
  +import org.apache.catalina.core.ApplicationContext;
  +// End FIXME
   import org.apache.catalina.util.LifecycleSupport;
   import org.apache.catalina.util.StringManager;
   
  @@ -112,7 +116,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.20 $ $Date: 2001/02/21 06:03:43 $
  + * @version $Revision: 1.21 $ $Date: 2001/03/22 00:53:31 $
*/
   
   public final class StandardLoader
  @@ -856,6 +860,9 @@
   }
   
   servletContext.setAttribute(Globals.CLASS_PATH_ATTR, classpath);
  +if (servletContext instanceof ApplicationContext)
  +((ApplicationContext) servletContext).setAttributeReadOnly
  +(Globals.CLASS_PATH_ATTR);
   
   }
   
  @@ -913,7 +920,10 @@
if (servletContext == null)
return;
servletContext.setAttribute(Globals.CLASS_LOADER_ATTR,
  - getClassLoader());
  +getClassLoader());
  +if (servletContext instanceof ApplicationContext)
  +((ApplicationContext) servletContext).setAttributeReadOnly
  +(Globals.CLASS_LOADER_ATTR);
   
   }
   
  
  
  

jasper's -classpath

[Julien, Timothy]

How does Jasper construct its Classpath when compiling jsps?

>From what I see it is:

System class path + something from Tomcat + the directory containing the jsp
source.

Note that when running Jasper in another container, the 'something from
Tomcat' part is null - an init-parameter 'org.apache.cataline.jsp_classpath'
for JspServlet, I think, is (obviously) missing when running in another
container.

Question: Would Jasper be able to run out of a web-app, without hanving it
in the system classpath?  Could I stick all of Jaspers relevant jars in the
WEB-INF/lib directory and get it to work?  The behavior I am seeing says no.

I would think that the classpath for compilation should include the jars in
WEB-INF/lib directory.

Tim Julien
HP middleware

cvs commit: jakarta-tomcat-4.0/catalina/src/conf tld_12.dtd

[horwat]

horwat  01/03/21 17:26:53

  Modified:jasper/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java
   jasper/src/share/org/apache/jasper/resources
web-jsptaglib_1_2.dtd
   catalina/src/conf tld_12.dtd
  Log:
  Implementation of JSP 1.2 specification changes. These changes are
  a subset of spec bug 4401127.
  
  (1) Converting TLD into a useful end-user document
  
  Add the following optional elements:
  
  * ? at the end of 
  * ? at the end of 
  * ? at the end of 
  * ? at the end of 
  
  (2) Add comment to DTD for TLD indicating that a DOCTYPE is needed and
  what its value is.  No changes to the value.
  
  (3) Change the name space "claimed" in the TLD to be
  "http://java.sun.com/JSP/TagLibraryDescriptor"
  
  (4) Make jsp-version element (child of ) mandatory
  
  Revision  ChangesPath
  1.22  +14 -3 
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
  
  Index: TagLibraryInfoImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- TagLibraryInfoImpl.java   2001/03/21 00:08:52 1.21
  +++ TagLibraryInfoImpl.java   2001/03/22 01:26:44 1.22
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
 1.21 2001/03/21 00:08:52 remm Exp $
  - * $Revision: 1.21 $
  - * $Date: 2001/03/21 00:08:52 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
 1.22 2001/03/22 01:26:44 horwat Exp $
  + * $Revision: 1.22 $
  + * $Date: 2001/03/22 01:26:44 $
*
* The Apache Software License, Version 1.1
*
  @@ -364,6 +364,9 @@
   variableVector.addElement(createVariable(element));
   } else if ("attribute".equals(tname))
   attributeVector.addElement(createAttribute(element));
  +else if ("example".equals(tname) ||   // Ignored elements
  +  false)
  +;
   else {
   Constants.message("jsp.warning.unknown.element.in.tag", 
 new Object[] {tname},
  @@ -443,6 +446,9 @@
   rtexprvalue = JspUtil.booleanValue(s);
   } else if ("type".equals(tname))
   type = element.getBody();
  +else if ("description".equals(tname) ||// Ignored elements
  +  false ) 
  +   ;
   else {
   Constants.message("jsp.warning.unknown.element.in.attribute", 
 new Object[] {tname},
  @@ -488,6 +494,9 @@
scope = VariableInfo.AT_END;
}
}
  + }
  +else if ("description".equals(tname) ||// Ignored elements
  +  false ) {
   } else {
   Constants.message("jsp.warning.unknown.element.in.variable",
 new Object[] {tname},
  @@ -511,6 +520,8 @@
   else if ("init-param".equals(tname)) {
String[] initParam = createInitParam(element);
initParams.put(initParam[0], initParam[1]);
  +} else if ("description".equals(tname) ||// Ignored elements
  +  false ) {
   } else {
   Constants.message("jsp.warning.unknown.element.in.validator", //@@@ 
add in properties
 new Object[] {tname},
  
  
  
  1.3   +36 -6 
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources/web-jsptaglib_1_2.dtd
  
  Index: web-jsptaglib_1_2.dtd
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources/web-jsptaglib_1_2.dtd,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- web-jsptaglib_1_2.dtd 2000/10/29 05:10:35 1.2
  +++ web-jsptaglib_1_2.dtd 2001/03/22 01:26:49 1.3
  @@ -15,6 +15,17 @@
 "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN">
   
   
  +
  +
   
  -
   
   http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd"
  + "http://java.sun.com/JSP/TagLibraryDescriptor"
   >
   
   
   
  -
  +
   
   
   
   
   
  +   small-icon?, large-icon?, description?, variable*, attribute*,
  +   example?) >
   
   
  +
  +
  +
  +
   
   
  +declare?, scope?, description?) >
   
   
   
  @@ -361,9 +388,11 @@
 by a scriptlet expression (optional)
   
   - the type of the attributes value (optional)
  +
  +- an informal description o

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

[larryi]

larryi  01/03/21 17:44:15

  Modified:src/facade22/org/apache/tomcat/facade
Servlet22Interceptor.java
  Log:
  Now that the session facade is 1-1 associated with the real session, we
  can use that facade when calling valueUnbound() rather than using a
  temporary one.  This patch undoes the last patch since it is no longer
  needed.
  
  Revision  ChangesPath
  1.13  +4 -20 
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/Servlet22Interceptor.java
  
  Index: Servlet22Interceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/Servlet22Interceptor.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Servlet22Interceptor.java 2001/02/28 20:43:58 1.12
  +++ Servlet22Interceptor.java 2001/03/22 01:44:11 1.13
  @@ -173,15 +173,9 @@
newState==ServerSession.STATE_EXPIRED )   {

// generate "unbould" events when the session is suspended or
  - // expired :
  - 
  - // Session facades are managed by the request facades.
  - // So, the facade returned at this point by the method getFacade() 
  - // of ServerSession is not valid : it could refer to a session facade
  - // that is unused, or used by a request facade for another server session.
  - // That's why we have to manage our own facade.
  - HttpSessionFacade sessionFacade = new HttpSessionFacade();
  - 
  + // expired
  + HttpSession httpSess=(HttpSession)sess.getFacade();
  +
Vector removed=new Vector();
Enumeration e = sess.getAttributeNames();
// announce all values with listener that we'll remove them
  @@ -189,22 +183,12 @@
String key = (String) e.nextElement();
Object value = sess.getAttribute(key);
   
  - sessionFacade.setRealSession(sess);
  - 
if( value instanceof  HttpSessionBindingListener) {
((HttpSessionBindingListener) value).valueUnbound
  - (new HttpSessionBindingEvent(sessionFacade , key));
  + (new HttpSessionBindingEvent(httpSess , key));
removed.addElement( key );
}
  - 
  - // prevents a session crossover
  - sess.setFacade( null );
}
  - 
  - // helps garbage collector
  - sessionFacade.recycle();
  - sessionFacade = null;
  - 
// remove
e=removed.elements();
while( e.hasMoreElements() ) {
  
  
  

Re: mod_webapp status?

[Punky Tse]

- Original Message -
From: "GOMEZ Henri" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 22, 2001 6:21 AM
Subject: RE: mod_webapp status?


> >> I'm rewriting it using APR... As we speak...
> >>
> >> Pier (under the snow in Dublin)
> >>
> >
>
> APR is a great piece of code but it will restrict Tomcat
> to have only one front-end, Apache Web Server.
>

I think the advantage to use APR is that there is no need to worry about
portability across all platforms.  For example, file I/O, socket, threading
and some IPC calls.  We can still able to write NES filter, IIS filter and
Apache1.3/2.0 modules on top of it.

Punky

cvs commit: jakarta-tomcat-4.0/webapps/examples/WEB-INF web.xml

[remm]

remm01/03/21 18:34:50

  Modified:webapps/examples/WEB-INF web.xml
  Log:
  - Made a mistake when commenting out the compression filter. Sorry :(
  
  Revision  ChangesPath
  1.12  +1 -2  jakarta-tomcat-4.0/webapps/examples/WEB-INF/web.xml
  
  Index: web.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/WEB-INF/web.xml,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- web.xml   2001/03/22 00:49:05 1.11
  +++ web.xml   2001/03/22 02:34:45 1.12
  @@ -55,8 +55,7 @@
   
  +  /CompressionTest
   
   -->
   
  
  
  

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

[remm]

remm01/03/21 19:40:02

  Modified:jasper/src/share/org/apache/jasper/compiler JspCompiler.java
  Log:
  - Avoid generating NPEs when resource doesn't exist.
  
  Revision  ChangesPath
  1.5   +5 -2  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspCompiler.java
  
  Index: JspCompiler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspCompiler.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- JspCompiler.java  2001/03/21 00:08:50 1.4
  +++ JspCompiler.java  2001/03/22 03:40:02 1.5
  @@ -57,6 +57,7 @@
   
   import java.io.File;
   import java.io.FileNotFoundException;
  +import java.net.URL;
   
   import org.apache.jasper.JspCompilationContext;
   import org.apache.jasper.Constants;
  @@ -166,8 +167,10 @@
   long jspRealLastModified = 0;
   
   try {
  -jspRealLastModified = ctxt.getResource(jsp.getPath())
  -.openConnection().getLastModified();
  +URL jspUrl = ctxt.getResource(jsp.getPath());
  +if (jspUrl == null)
  +return true;
  +jspRealLastModified = jspUrl.openConnection().getLastModified();
   } catch (Exception e) {
   e.printStackTrace();
   return true;
  
  
  

[STATUS] Tomcat 3.2.2

[Marc Saegesser]

Well, it took longer than I had hoped, but we have finally managed to review
*all* open bug reports against Tomcat-3!  The only reports left in the NEW
state are those specifically opened against Tomcat 3.3.  All the others have
either been closed as FIXED, WORKSFORME or INVALID.  A big THANK YOU to
everyone who helped make this happen.

My plan is to use tomorrow, Thursday (3/22/01) for some final testing.  On
Friday morning (Central US time) I will tag and build Tomcat 3.2.2 beta 2.
This beta will last two weeks, during which time the only commits to the
tomcat_32 branch will be for fixing critical bugs identified during the beta
period.

At the end of the beta period I will call a vote for the release of Tomcat
3.2.2.

Marc Saegesser

Re: jasper's -classpath

[Mel Martinez]

--- "Julien, Timothy" <[EMAIL PROTECTED]> wrote:
> How does Jasper construct its Classpath when
> compiling jsps?
> 
> From what I see it is:
> 
> System class path + something from Tomcat + the
> directory containing the jsp
> source.
> 
> Note that when running Jasper in another container,
> the 'something from
> Tomcat' part is null - an init-parameter
> 'org.apache.cataline.jsp_classpath'
> for JspServlet, I think, is (obviously) missing when
> running in another
> container.
> 


When running in another container, the class path
visible to jasper JSP's is like so:

0 - Classpath (via system class loader)
1 - classes visible to JspServlet's class loader (i.e.
the servlet class loader for the container)
2 - classes visible to JasperLoader (the class loader
used to load Jsp servlets after they have been
compiled).

In general, you may or may not have control over 0
(depends on how the container starts up) and what is
available via (1) depends on how the container loads
servlets.  The control over (2) is a little shaky
currently.

The classpath available to JasperLoader for loading
classes is basically whatever directories, jar or zip
files have been added via the addJar() method. 
Unfortunately, as near as I can tell, this is not done
anywhere.

Now the classpath that is pulled out of the
JspServlet's init-params looks like it is _supposed_
to be added to JasperLoader, but if it is I can't find
where.  It IS appended to the classpath used by the
Compiler to compile the jsp's .java files into .class
files, but that doesn't help you load the classes and
run them.

Before I got involved with the tomcat project
directly, I solved this problem by extending a few
jasper classes to refactor it and fix this and a few
other problems specifically to address running Jasper
in a non-tomcat container (I need to run it in
WebLogic as well).  In my solution, I did two things.
(1) I outright added a system property to set a
classpath for the jsp loader.  (2) I calculate the
classpath for the JasperLoader using the above
property as well as the heretofore ignored init-param
and make sure to add it to the loader when I construct
the loader for the particular page (my implementation
uses a loader for each page to support dynamic
reloading).

So somewhere between the creation of the loader and
the  attempt to load the class, which currently
happens in JspServlet.doLoadJSP(), the classpath needs
to be added to the loader.

I say 'currently' because Costin is right when he says
that jasper could use some refactoring.  I'd like to
propose some wholesale refactoring of the class model
for the JspServlet and it's supporting classes to
better partition responsibilities.  I'll make a more
formal proposal along these lines shortly.

> Question: Would Jasper be able to run out of a
> web-app, without hanving it
> in the system classpath?  Could I stick all of
> Jaspers relevant jars in the
> WEB-INF/lib directory and get it to work?  The
> behavior I am seeing says no.
> 
> I would think that the classpath for compilation
> should include the jars in
> WEB-INF/lib directory.
> 

If the container properly implements the spec, then
JspServlet and thus the jsp servlets should be able to
'see' the WEB-INF/lib classes for LOADING purposes via
the servlet classloader.  However, that classpath is
not made available to the compiler for COMPILATION
currently.  The compiler sees the classpath of the
JasperLoader.getClassPath() call (which as I've said
above, is not necessarily set because that is
initialized via missing addJar() calls) catenated to
the init-param classpath.
  
So the result is that currently, you can only LOAD
classes that the parent servlet classloader can see
and you can only COMPILE classes visible in the
init-param classpath.  If you know how the container's
classloader behaves, and also manually setup the
init-param classpath, you can work around this
confusion.

However, this needs to be fixed.  I will try to take a
stab at first a short-term fix to get it working right
in the next couple of days and then as mentioned, I'd
like to propose some more wholesale changes.  Note - a
lot of these problems don't exist with the
JspInterceptor.  These problems seem to be solely with
the JspServlet as used separately from tomcat.

Cheers,

Dr. Mel Martinez


__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Re: bug in Jasper - bad lookups to Constants.getString()

[Mel Martinez]

--- [EMAIL PROTECTED] wrote:
> On Wed, 21 Mar 2001, Mel Martinez wrote:
> 
> > Would the following be an acceptable solution?
> > 
> > We change the
> > Constants.message(key,args,verbosityLevel) method
> > behavior so that if getString(key,args) throws
> > a missing resource exception that it logs using
> the
> > key itself as the log message. Note that this
> would
> > also require changing the getString() method to
> throw
> > the MissingResourceException instead of the Error
> > object that it currently throws.  
> 
> +1 ( please check the tomcat side is doing the
> same - we never had the problem but you never know )
> 
> Would StringManager be a better place for the fix ?
> 
> Costin


Yes.  After looking into this, it would seem that
there is no reason Jasper can't make use of
StringManager to handle getting it's resource strings
consistent with the way tomcat packages are doing so. 
This doesn't look too difficult to retro into Jasper.

However ...

StringManager's getString() currently deals with the
MissingResourceException by simply returning a String
consisting of a warning message about not being able
to find the particular key.  I don't think that is
correct behavior.  I think it should throw the
MissingResourceException or return null and that
calling code should deal with it.  Otherwise the
calling code really has no reason to suspect anything
is wrong (that the returned string is not what it
wanted).  If an exception were to be thrown and caught
(or a null is checked and found) then the calling code
wuld have the option to use the key to construct a
replacement String or whatever.  However, I am a bit
leary about changing code to throw an exception where
one has been incorrectly swallowed like this. 
Currently unsuspecting code may exist that relies
unknowingly on this swallowing of the exception by
blindly just using whatever string is returned.

Changing this may require a bit of testing to see all
the effects caused by missing resource strings.

Mel


__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Re: mod_webapp status?

[Craig R. McClanahan]

On Thu, 22 Mar 2001, Punky Tse wrote:

> - Original Message -
> From: "GOMEZ Henri" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, March 22, 2001 6:21 AM
> Subject: RE: mod_webapp status?
> 
> 
> > >> I'm rewriting it using APR... As we speak...
> > >>
> > >> Pier (under the snow in Dublin)
> > >>
> > >
> >
> > APR is a great piece of code but it will restrict Tomcat
> > to have only one front-end, Apache Web Server.
> >
> 
> I think the advantage to use APR is that there is no need to worry about
> portability across all platforms.  For example, file I/O, socket, threading
> and some IPC calls.  We can still able to write NES filter, IIS filter and
> Apache1.3/2.0 modules on top of it.
> 
> Punky
> 
> 
> 

Are you volunteering to help do that?  :-)  If so, that would be great.

Craig McClanahan

Re: Re:Réf. : RE: Proposal for Compression Filter example

[Amy Roh]

I have already committed the code to tomcat-4.0 CVS.  You can get it from
webapps\examples\web-inf\classes\compressionFilters\

Cheers,

Amy

> Hi Amy,
>
> I would really appreciate if you could mail me the source code for the
> compression filter that you are referring to in your mails to the tomcat
> dev mailing list. This is something that I've been wanting to do for a
long
> time. If I can look at your source code, I will get some good pointers on
> things I would like to extend upon.
>
> Thanks in advance.
>
> KM
>
> Khurram Mahmood
> Off: (408) 367-4443
>
>
>
>
>
> "Amy Roh"
>  ion.org> cc:
>  Subject: Re: Réf. : RE:
Proposal for Compression Filter example
> 03/21/01
> 10:31 AM
> Please
> respond to
> tomcat-dev
>
>
>
>
>
>
> Quoting "JULE, Nicolas - DSIA" <[EMAIL PROTECTED]>:
>
> >
> >
> >
> >  De :   Craig R. McClanahan@craigmcc le 20/03/2001 23:31
> >  Pour :
> tomcat-dev@[EMAIL PROTECTED]@SMTP@Hays Hub
> >  cc :
> >  Faxer à:
> >  Objet :RE: Proposal for Compression Filter example
> >
> >
> >
> >  On Tue, 20 Mar 2001, GOMEZ Henri wrote:
> >
> >  > >I created an example web application using Filter technology
> >  > >and would like to
> >  > >add to Tomcat 4 example webapps.  This example includes Data
> >  > >Compression Filter
> >  > >which compresses ServletResponse according to the threshold
> >  > >that can be set by
> >  > >users.  I think it'll be a good example usage of filters.
> >  > >
> >  > >What do you think?
> >  >
> >  > +1 (may be a module for 3.3 ?)
> >  >
> >
> >  | Anyone who wants to create a module for this kind of
> functionality
> > can, of
> >  | course, do so.  The advantage of impementing it as a Filter
is
> > that it
> >  | will be portable to any 2.3 servlet container.
> >
> >  Both are really interesting, but another Advantage for Filter
is
> > that it allow selective  compression (I hope it will !)
>
> Yes, it does.  It checks for compression support first then does the
> compression.
>
> Amy
>
> >  Systematic compression could break flows that are not
destinated
> to
> > Browsers, but other Applications
> >  using HTTP as a Tunnel, in backend of the HTTPServer.
> >
> >
> >  Nicolas
> >
> >  > I also recommand you to take a look at mod_gzip which
> >  > done that beautifully
> >  >
> >  > http://www.remotecommunications.com/apache/mod_gzip/
> >  >
> >
> >  Craig
> >
> >
> >
> >
> > **
> > Ce message électronique et tous les fichiers attachés qu'il contient
> > sont confidentiels et destinés exclusivement à l'usage de la personne
> > à laquelle ils sont adressés. Si vous avez reçu ce message par erreur,
> > merci de le retourner à son émetteur. Les idées et opinions présentées
> > dans ce messages sont celles de son auteur, et ne représentent pas
> > nécessairement celles du Groupe HAYS plc ou d'une quelconque de ses
> > filiales.
> > La publication, l'usage, la distribution, l'impression ou la copie non
> > autorisée de ce message et des attachements qu'il contient sont
> > strictement
> > interdits.
> >
> > Nous vous informons également que nous avons vérifié l'absence de virus
> > dans
> > ce message mais que, malgré ce contrôle, nous ne saurions être tenus
> > pour
> > responsables d'éventuels dégâts occasionnés par un virus non détecté.
> >
> > This e-mail and any attached files are confidential and intended
> > solely for the use of the individual to whom it is addressed. If you
> > have
> > received this email in error please send it back to the person that sent
> > it
> > to you. Any views or opinions presented are solely those of author and
> > do not necessarily represent those the HAYS plc group or any of its
> > subsidiary
> > companies. Unauthorized publication, use, dissemination, forwarding,
> > printing
> > or copying of this email and its associated attachments is strictly
> > prohibited.
> >
> > We also inform you that we have checked that this message does not
> > contain
> > any virus but we decline any responsability in case of any damage caused
> >
> > by an a non detected virus.
> >
> > **
> >
>
>
>
>
>
>

Re: Re:Réf. : RE: Proposal for Compression Filter example

[Amy Roh]

I have already committed the code to tomcat-4.0 CVS.  You can get it from
webapps\examples\web-inf\classes\compressionFilters\

Cheers,

Amy

> Hi Amy,
>
> I would really appreciate if you could mail me the source code for the
> compression filter that you are referring to in your mails to the tomcat
> dev mailing list. This is something that I've been wanting to do for a
long
> time. If I can look at your source code, I will get some good pointers on
> things I would like to extend upon.
>
> Thanks in advance.
>
> KM
>
> Khurram Mahmood
> Off: (408) 367-4443
>
>
>
>
>
> "Amy Roh"
>  ion.org> cc:
>  Subject: Re: Réf. : RE:
Proposal for Compression Filter example
> 03/21/01
> 10:31 AM
> Please
> respond to
> tomcat-dev
>
>
>
>
>
>
> Quoting "JULE, Nicolas - DSIA" <[EMAIL PROTECTED]>:
>
> >
> >
> >
> >  De :   Craig R. McClanahan@craigmcc le 20/03/2001 23:31
> >  Pour :
> tomcat-dev@[EMAIL PROTECTED]@SMTP@Hays Hub
> >  cc :
> >  Faxer à:
> >  Objet :RE: Proposal for Compression Filter example
> >
> >
> >
> >  On Tue, 20 Mar 2001, GOMEZ Henri wrote:
> >
> >  > >I created an example web application using Filter technology
> >  > >and would like to
> >  > >add to Tomcat 4 example webapps.  This example includes Data
> >  > >Compression Filter
> >  > >which compresses ServletResponse according to the threshold
> >  > >that can be set by
> >  > >users.  I think it'll be a good example usage of filters.
> >  > >
> >  > >What do you think?
> >  >
> >  > +1 (may be a module for 3.3 ?)
> >  >
> >
> >  | Anyone who wants to create a module for this kind of
> functionality
> > can, of
> >  | course, do so.  The advantage of impementing it as a Filter
is
> > that it
> >  | will be portable to any 2.3 servlet container.
> >
> >  Both are really interesting, but another Advantage for Filter
is
> > that it allow selective  compression (I hope it will !)
>
> Yes, it does.  It checks for compression support first then does the
> compression.
>
> Amy
>
> >  Systematic compression could break flows that are not
destinated
> to
> > Browsers, but other Applications
> >  using HTTP as a Tunnel, in backend of the HTTPServer.
> >
> >
> >  Nicolas
> >
> >  > I also recommand you to take a look at mod_gzip which
> >  > done that beautifully
> >  >
> >  > http://www.remotecommunications.com/apache/mod_gzip/
> >  >
> >
> >  Craig
> >
> >
> >
> >
> > **
> > Ce message électronique et tous les fichiers attachés qu'il contient
> > sont confidentiels et destinés exclusivement à l'usage de la personne
> > à laquelle ils sont adressés. Si vous avez reçu ce message par erreur,
> > merci de le retourner à son émetteur. Les idées et opinions présentées
> > dans ce messages sont celles de son auteur, et ne représentent pas
> > nécessairement celles du Groupe HAYS plc ou d'une quelconque de ses
> > filiales.
> > La publication, l'usage, la distribution, l'impression ou la copie non
> > autorisée de ce message et des attachements qu'il contient sont
> > strictement
> > interdits.
> >
> > Nous vous informons également que nous avons vérifié l'absence de virus
> > dans
> > ce message mais que, malgré ce contrôle, nous ne saurions être tenus
> > pour
> > responsables d'éventuels dégâts occasionnés par un virus non détecté.
> >
> > This e-mail and any attached files are confidential and intended
> > solely for the use of the individual to whom it is addressed. If you
> > have
> > received this email in error please send it back to the person that sent
> > it
> > to you. Any views or opinions presented are solely those of author and
> > do not necessarily represent those the HAYS plc group or any of its
> > subsidiary
> > companies. Unauthorized publication, use, dissemination, forwarding,
> > printing
> > or copying of this email and its associated attachments is strictly
> > prohibited.
> >
> > We also inform you that we have checked that this message does not
> > contain
> > any virus but we decline any responsability in case of any damage caused
> >
> > by an a non detected virus.
> >
> > **
> >
>
>
>
>
>
>

Re: Re:Réf. : RE: Proposal for Compression Filter example

[Amy Roh]

I have already committed the code to tomcat-4.0 CVS.  You can get it from
webapps\examples\web-inf\classes\compressionFilters\

Cheers,

Amy

>
> Hi Amy,
>
> I would really appreciate if you could mail me the source code for the
> compression filter that you are referring to in your mails to the tomcat
> dev mailing list. This is something that I've been wanting to do for a
long
> time. If I can look at your source code, I will get some good pointers on
> things I would like to extend upon.
>
> Thanks in advance.
>
> KM
>
> Khurram Mahmood
> Off: (408) 367-4443
>
>
>
>
>
> "Amy Roh"
>  ion.org> cc:
>  Subject: Re: Réf. : RE:
Proposal for Compression Filter example
> 03/21/01
> 10:31 AM
> Please
> respond to
> tomcat-dev
>
>
>
>
>
>
> Quoting "JULE, Nicolas - DSIA" <[EMAIL PROTECTED]>:
>
> >
> >
> >
> >  De :   Craig R. McClanahan@craigmcc le 20/03/2001 23:31
> >  Pour :
> tomcat-dev@[EMAIL PROTECTED]@SMTP@Hays Hub
> >  cc :
> >  Faxer à:
> >  Objet :RE: Proposal for Compression Filter example
> >
> >
> >
> >  On Tue, 20 Mar 2001, GOMEZ Henri wrote:
> >
> >  > >I created an example web application using Filter technology
> >  > >and would like to
> >  > >add to Tomcat 4 example webapps.  This example includes Data
> >  > >Compression Filter
> >  > >which compresses ServletResponse according to the threshold
> >  > >that can be set by
> >  > >users.  I think it'll be a good example usage of filters.
> >  > >
> >  > >What do you think?
> >  >
> >  > +1 (may be a module for 3.3 ?)
> >  >
> >
> >  | Anyone who wants to create a module for this kind of
> functionality
> > can, of
> >  | course, do so.  The advantage of impementing it as a Filter
is
> > that it
> >  | will be portable to any 2.3 servlet container.
> >
> >  Both are really interesting, but another Advantage for Filter
is
> > that it allow selective  compression (I hope it will !)
>
> Yes, it does.  It checks for compression support first then does the
> compression.
>
> Amy
>
> >  Systematic compression could break flows that are not
destinated
> to
> > Browsers, but other Applications
> >  using HTTP as a Tunnel, in backend of the HTTPServer.
> >
> >
> >  Nicolas
> >
> >  > I also recommand you to take a look at mod_gzip which
> >  > done that beautifully
> >  >
> >  > http://www.remotecommunications.com/apache/mod_gzip/
> >  >
> >
> >  Craig
> >
> >
> >
> >
> > **
> > Ce message électronique et tous les fichiers attachés qu'il contient
> > sont confidentiels et destinés exclusivement à l'usage de la personne
> > à laquelle ils sont adressés. Si vous avez reçu ce message par erreur,
> > merci de le retourner à son émetteur. Les idées et opinions présentées
> > dans ce messages sont celles de son auteur, et ne représentent pas
> > nécessairement celles du Groupe HAYS plc ou d'une quelconque de ses
> > filiales.
> > La publication, l'usage, la distribution, l'impression ou la copie non
> > autorisée de ce message et des attachements qu'il contient sont
> > strictement
> > interdits.
> >
> > Nous vous informons également que nous avons vérifié l'absence de virus
> > dans
> > ce message mais que, malgré ce contrôle, nous ne saurions être tenus
> > pour
> > responsables d'éventuels dégâts occasionnés par un virus non détecté.
> >
> > This e-mail and any attached files are confidential and intended
> > solely for the use of the individual to whom it is addressed. If you
> > have
> > received this email in error please send it back to the person that sent
> > it
> > to you. Any views or opinions presented are solely those of author and
> > do not necessarily represent those the HAYS plc group or any of its
> > subsidiary
> > companies. Unauthorized publication, use, dissemination, forwarding,
> > printing
> > or copying of this email and its associated attachments is strictly
> > prohibited.
> >
> > We also inform you that we have checked that this message does not
> > contain
> > any virus but we decline any responsability in case of any damage caused
> >
> > by an a non detected virus.
> >
> > **
> >
>
>
>
>
>
>

oops...sorry for duplicate emails...

[Amy Roh]

My mail is acting funny on me today.  My 
apologies

Re: bug in Jasper - bad lookups to Constants.getString()

[cmanolache]

On Wed, 21 Mar 2001, Mel Martinez wrote:

> StringManager's getString() currently deals with the
> MissingResourceException by simply returning a String
> consisting of a warning message about not being able
> to find the particular key.  I don't think that is
> correct behavior.  I think it should throw the
> MissingResourceException or return null and that
> calling code should deal with it.  Otherwise the

Ignoring exceptions is bad. Having to handle exceptions
for trivial cases is bad too.

My feeling is that this is not the biggest priority,
but you are right - StringManager and the whole resource
handling needs a refactoring. Go for it, if you want
to do it - I'll do whatever I can to help.

( I think thread pools or jasper or the admin are in a much
 bigger need for fixes and cleanup )

I am hoping the "commons" will ease our work - this is 
one of the things that are used in all jakarta projects,
and it would be a good thing to share it ( in which case
refactoring it and merging with the best out of what other 
projects are doing  is worth the effort ) 


Costin

Re: http 1.0 timeout patch

[Endre Stølsvik]

On Wed, 21 Mar 2001 [EMAIL PROTECTED] wrote:

| What about 33 sec. ? It matches the version :-)
|
| ( seriously - does the HTTP spec have any number ? If not, can we use
| whatever apache is using ? )
|
| In any case - 300s is better than no timeout - and if it's too much we can
| reduce it later ( and make it configurable anyway ).

Isn't there an issue with tomcat closing a connection before apache does?

At least it seems so to me. If you restart tomcat while the browser is
connected to it through apache-mod_jk, then that apache process will use
all available CPU right away.

I guess this is a bug of some sort, just wanted to mention it, especially
now since it seems like you'd want tomcat to close connections before
apache does.. Or whatever you're up to! ;)

-- 
Mvh,
Endre

RE: http 1.0 timeout patch

[GOMEZ Henri]

>What about 33 sec. ? It matches the version :-)
>
>( seriously - does the HTTP spec have any number ? If not, can we use
>whatever apache is using ? )
>
>In any case - 300s is better than no timeout - and if it's too 
>much we can
>reduce it later ( and make it configurable anyway ).   
>

300s is really huge number since in http 1.0 connector we read
input stream one byte at time.

With such timeout, you could let a connection open for more than
one hour just to read : GET / HTTP/1.0\r\n

So I'll commit the patch with 300s by default but I strongly recommand
to adapt this timeout to specific site configuration (intranet, internet)

Regards

RE: http 1.0 timeout patch

[GOMEZ Henri]

>Isn't there an issue with tomcat closing a connection before 
>apache does?

It's not related since we speak here of the native tomcat http connector.

>At least it seems so to me. If you restart tomcat while the browser is
>connected to it through apache-mod_jk, then that apache 
>process will use
>all available CPU right away.
>
>I guess this is a bug of some sort, just wanted to mention it, 
>especially
>now since it seems like you'd want tomcat to close connections before
>apache does.. Or whatever you're up to! ;)

The problem you describe is related to mod_jk and I'm working on a
patch (to be released very soon)

Tomcat SSL Socket factory -- more independent

[Darrel Drake]

Hi, I use Tomcat 3.2 with SSL and I ran into a problem when executing using
IBM's JSSE implementation. Namely, in the default configuration, the Sun
classes are referenced directly, so you CAN'T use IBM JSSE on the server
side in this case. I changed the source so that you can run either
implementation. Ideally ANY implementation of JSSE can be run on this
class, since only the javax.net and javax.net.ssl packages are referenced.
Also, I enhanced it to add session properties to the ServletRequest under
the names recommended in the JSSE 1.0.2 specification.

I'm aware that there's a new interceptor mechanism in v3.3m2, but I'm not
yet sure whether the same problems exist. It appears that the source tree
got re-arranged since 3.2 release and it's totally confusing to navigate
now. If this is still needed in 3.3 and someone would be nice enough to
commit it I'd appreciate it highly. If this change is useful to those who
use v3.2 please feel free to use it and give me feedback. The name on this
file is different so you can try it out and switch back if you want.

1. Compile the TomcatSSLSocketFactory.java to something that's on your
classpath
2. Change your server.xml line to read like this:

3. Set your JAVA_HOME to point to a JVM with either Sun or IBM JSSE
installed
4. Restart Tomcat
5. Run a test client (I attached one) using an https URL
6. Do 3-5 again with a JVM loaded with the other JSSE

Implementation notes: Initially I just copied the
"org.apache.tomcat.net.SSLSocketFactory" class into another file and
replaced all the "sun"s with "ibm"s, and it worked perfectly well. Then I
realized that you don't even have to call those proprietary classes; you
can simply set the Java environment variables inside the code, because the
first call to ServerSocketFactory.getDefault() will look for those values.
So instead of loading keystore files and constructing key- and
trust-managers, I just set those variables (System.setProperty
("xxx","yyy")) and let the default method do all that itself. It seems to
work totally fine under JDK 1.2 or 1.3 with either IBM or Sun JSSE
installed (4 test cases).

Darrell Drake*
IBM Japan, TRL
+81-46-215-4175
[EMAIL PROTECTED]
* - Notes ID has a misspelling of my name
(See attached file: TomcatSSLSocketFactory.java)(See attached file:
ReadURL.java)
 TomcatSSLSocketFactory.java
 ReadURL.java