DO NOT REPLY [Bug 3774] - Error loading web.xml on root context when specified in server.xml file on Windows

[bugzilla]

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

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

Error loading web.xml on root context when specified in server.xml file on Windows

[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|4.0 Final   |4.0.4 Beta 1

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging

[White Knight]

But would it be a nice idea to use Log 4J through out tomcat?

comments..
 Jan Luehe <[EMAIL PROTECTED]> wrote:Jasper currently uses its own private logging 
facility implemented
in the org.apache.jasper.logging package. This is inconsistent with
the way the other Tomcat subsystems perform logging
(by leveraging the commons-logging package).

Proposal is to remove org.apache.jasper.logging, and replace calls
to it with calls to the commons-logging APIs.

Comments?


Jan


--
To unsubscribe, e-mail: 
For additional commands, e-mail: 



-
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging

[Jeanfrancois Arcand]

+1

-- Jeanfrancois

Jan Luehe wrote:


Jasper currently uses its own private logging facility implemented
in the org.apache.jasper.logging package. This is inconsistent with
the way the other Tomcat subsystems perform logging
(by leveraging the commons-logging package).

Proposal is to remove org.apache.jasper.logging, and replace calls
to it with calls to the commons-logging APIs.

Comments?


Jan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging

[White Knight]

+1
I strongly echo Jan Luehe.
 Jan Luehe <[EMAIL PROTECTED]> wrote:Jasper currently uses its own private logging 
facility implemented
in the org.apache.jasper.logging package. This is inconsistent with
the way the other Tomcat subsystems perform logging
(by leveraging the commons-logging package).

Proposal is to remove org.apache.jasper.logging, and replace calls
to it with calls to the commons-logging APIs.

Comments?


Jan


--
To unsubscribe, e-mail: 
For additional commands, e-mail: 



-
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging

[Glenn Nielsen]

Jan Luehe wrote:

Hans,



Jasper currently uses its own private logging facility implemented
in the org.apache.jasper.logging package. This is inconsistent with
the way the other Tomcat subsystems perform logging
(by leveraging the commons-logging package).

Proposal is to remove org.apache.jasper.logging, and replace calls
to it with calls to the commons-logging APIs.



+1


Comments?


+0. Do you suggest this for TC 5 only, or also for TC 4.1?



Mainly for TC 5, but if there is enough interest, I can apply
the changes to TC 4.1 as well.



Fine by me to port the switch to commons-logging to Jasper 2 for Tomcat 4.1. :-)

Glenn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 15851] - Parser generates a NullPointerException for invalid use case of jsp:attribute instead of a useful message.

[bugzilla]

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

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

Parser generates a NullPointerException for invalid use case of jsp:attribute instead 
of a useful message.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-22 01:49 ---
The test page



someattr


someattrvalue



is not a valid page.  The compiler's error message

jsp:attribute must be the subelement of a standard or custom action

is valid.  If the page is modified so that jsp:attribute is nested in a standard
action, such as


  

someattr


someattrvalue

  


then the compiler will generate the message

a jsp:attribute standard action cannot be nested within another
jsp:attribute standard action

as expected.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Why unpackWars=true default?

[mlh]

On Tue, Jan 21, 2003 at 09:14:29AM -0500, Shapira, Yoav wrote:
> >consider the ".war" file like an ".exe" or executable JAR file.
> 
> And I think this is where my interest comes from.  Your considerations
> are exactly the opposite of Costin's (I think it was Costin anyways),
> who considers the .war file a *deployment* format only, like an RPM or a
> Windows Installer file, not to be run as an executable.

I thought the raison d'etre of war's was acting like a single .exe.

Or at least the default -- just as you're not expected to unpack jars.

Matt

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

[Hans Bergsten]

[EMAIL PROTECTED] wrote:

costin  2003/01/21 15:24:51

  Modified:jasper2/src/share/org/apache/jasper JspC.java
  Log:
  Use the patch submited by Hans ( at least the part related to package ).
  
  I modified it so that if a package is specified, it is used as prefix.
  The second patch - I'm not sure what it does.

You mean the o.a.j.compiler.TagLibraryInfoImpl.java patch, right?
As I mentioned briefly in my last comment for the bug, it fixes a
problem with TLDs packaged in JAR files. Without this patch, you get
an NPE for this case (the problem described by bug #13212).

The code the patch removes is admittedly a mystery to me (why is a
leading slash only removed if a URLClassLoader is used? Isn't this
always the case?) and I don't remember why it failed for TLDs in
JAR files (maybe path is null?). In all my tests, however, this patch
fixes #13212 and has not caused any side-effects.

Hans


  Revision  ChangesPath
  1.23  +4 -4  jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
  
  Index: JspC.java
  ===
  RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- JspC.java	21 Jan 2003 22:49:53 -	1.22
  +++ JspC.java	21 Jan 2003 23:24:50 -	1.23
  @@ -548,7 +548,7 @@
   targetClassName = null;
   }
   if (targetPackage != null) {
  -clctxt.setServletPackageName( targetPackage + "." +
  +clctxt.setServletPackageName( targetPackage +
   toPackageName(jspUri));
   } else {
   clctxt.setServletPackageName( toPackageName(jspUri));
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[luehe]

luehe   2003/01/21 15:45:19

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  Modified code generated for  to be well-formed.
  
  Example:
  
  Previous format of generated code:
  



  

  
  Unable to start plugin.
  

  
  New format of generated code:
  



  
  Unable to start plugin.
  


  
  Revision  ChangesPath
  1.151 +9 -7  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.150
  retrieving revision 1.151
  diff -u -r1.150 -r1.151
  --- Generator.java17 Jan 2003 01:21:16 -  1.150
  +++ Generator.java21 Jan 2003 23:45:18 -  1.151
  @@ -1447,13 +1447,11 @@
if (n.getBody() != null)
n.getBody().visit(new ParamVisitor(false)); 
   
  - out.printil("out.write(" + quote(">") + ");");
  + out.printil("out.write(" + quote("/>") + ");");
out.printil("out.write(\"\\n\");");
   
out.printil("out.write(" + quote("") + ");");
out.printil("out.write(\"\\n\");");
  - out.printil("out.write(" + quote("") + ");");
  - out.printil("out.write(\"\\n\");");
   
/*
 * Fallback
  @@ -1463,8 +1461,12 @@
out.printil("out.write(\"\\n\");");
}
   
  - out.printil("out.write(" + quote("") + ");");
  + out.printil("out.write(" + quote("") + ");");
  + out.printil("out.write(\"\\n\");");
  +
  + out.printil("out.write(" + quote("") + ");");
out.printil("out.write(\"\\n\");");
  +
out.printil("out.write(" + quote("") + ");");
out.printil("out.write(\"\\n\");");
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Tomcat 5 target JDK1.4?

[Sean Reilly]

This might start a bit of a flame-fest here, and if so I appologize, but I feel that 
this is a valid point.
A lot of people have been critizing V. Cekvenich for his suggestion, and one of the 
common reasons given was:

>Those who have systems in production and have spent alot of time developing
>applications which are hosted on those systems can't do a major upgrade like
>JVM 1.3 -> JVM 1.4 at the drop of a hat.

This particular version of the argument was posted by Glenn, and I believe he's 
correct in stating this.
However, if you can't do a major upgrade like JVM 1.3 -> JVM 1.4 at the drop of a hat, 
why would you consider
a major upgrade like Tomcat 4.X -> Tomcat 5 at the drop of a hat?

The many other arguments against requiring 1.4 notwithstanding (and I'm not attempting 
to refute _any_ of them here), it would seem to me that testing a major version change 
of Tomcat + a JVM  change wouldn't incur much more overhead than testing a major 
version change of Tomcat alone.  Does anyone have any 
comments/opinions/counterarguments? Or should I just shut my trap and concentrate on 
the other reasons requiring J2SE 1.4 is a bad idea ;-)

Sean Reilly
Software Architect, Point2 Technologies, Inc.
(306) 955-1855
[EMAIL PROTECTED]


> -Original Message-
> From: V. Cekvenich [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 21, 2003 5:04 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Tomcat 5 target JDK1.4?
> 
> 
> iSeris has JDK 1.4 download from IBM, that is my point. (BEA, 
> and Apple 
> have it as well so we have multi source).
> 
> Today when you download Tomcat 4 you have the 1.4 LE edition 
> just loook 
> at the site
> Also downloading a jar, ex: http://jdbc.postgresql.org/download.html 
> have 1.4 required.
> Today!
> 
> TC5 is ways of.
> And I think everyone can agree that JDK1.4 is more stable than 1.3.
> 
> .V
> 
> Henri Gomez wrote:
> > V. Cekvenich wrote:
> > 
> >> For TC 4 OK, but TC5 will have tested 4 vendors JVM 1.4.
> >>
> >> Most people run JDK 1.4 now.
> > 
> > 
> > There is at least one person which didn't run JDK 1.4,
> > me, since the JDK 1.4 is not available on my iSeries.
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Precompiled jsps

[Costin Manolache]

Finally - the precompilation for /admin works, just use 

  ant build-admin-precompile

The jsp-examples should be precompiled too ( unless they're
intended to show how slow jsp can be on the first request).

After more looking at the code - I think it is a bit too
complicated to add the JMX to jasper ( at least for my 
current free time ). However it works perfectly fine with the
precompiled jsps - and IMO any decent production server should
precompile the jsps ( and get JMX as yet another benefit of 
doing so )

Costin




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-5 build.xml

[costin]

costin  2003/01/21 15:25:56

  Modified:.build.xml
  Log:
  Update to match gump dir naming.
  
  Revision  ChangesPath
  1.67  +1 -1  jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.66
  retrieving revision 1.67
  diff -u -r1.66 -r1.67
  --- build.xml 21 Jan 2003 00:26:09 -  1.66
  +++ build.xml 21 Jan 2003 23:25:56 -  1.67
  @@ -22,7 +22,7 @@
 
 
 
  -  
  +  
   
 
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

looking for a recent isapi_redirector2.dll

[Andris Spruds]

Hello,

Has anyone recently compiled isapi_redirector2.dll (aka IIS JK2 connector)?
It seems that the binary version available at Tomcat Connectors site is
quite old and does not include the recent upload-corrupter bugfix
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15278). It would be cool
if someone who has recently compiled it could send it (or post an URL) as it
can be a nightmare for unexpierenced C user (that's me!) to compile the IIS
connector from source!

Thanks,
-Andris Spruds





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/webapps/admin/WEB-INF web.xml

[costin]

costin  2003/01/21 15:25:29

  Modified:webapps/admin/WEB-INF web.xml
  Log:
  Add a small XML comment - it'll be replaced with the generated web.xml
  fragment.
  
  Revision  ChangesPath
  1.6   +2 -0  jakarta-tomcat-catalina/webapps/admin/WEB-INF/web.xml
  
  Index: web.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/web.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- web.xml   20 Nov 2002 00:14:07 -  1.5
  +++ web.xml   21 Jan 2003 23:25:28 -  1.6
  @@ -90,6 +90,8 @@
   2
 
   
  +   
  +
 
 
   action
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

[costin]

costin  2003/01/21 15:24:51

  Modified:jasper2/src/share/org/apache/jasper JspC.java
  Log:
  Use the patch submited by Hans ( at least the part related to package ).
  
  I modified it so that if a package is specified, it is used as prefix.
  The second patch - I'm not sure what it does.
  
  Revision  ChangesPath
  1.23  +4 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
  
  Index: JspC.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- JspC.java 21 Jan 2003 22:49:53 -  1.22
  +++ JspC.java 21 Jan 2003 23:24:50 -  1.23
  @@ -548,7 +548,7 @@
   targetClassName = null;
   }
   if (targetPackage != null) {
  -clctxt.setServletPackageName( targetPackage + "." +
  +clctxt.setServletPackageName( targetPackage +
   toPackageName(jspUri));
   } else {
   clctxt.setServletPackageName( toPackageName(jspUri));
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt

[amyroh]

amyroh  2003/01/21 15:19:56

  Modified:.RELEASE-NOTES-4.1.txt
  Log:
  Tomcat 4 admin webapp is now accessible and passes section 508.
  
  Revision  ChangesPath
  1.51  +4 -1  jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
  
  Index: RELEASE-NOTES-4.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
  retrieving revision 1.50
  retrieving revision 1.51
  diff -u -r1.50 -r1.51
  --- RELEASE-NOTES-4.1.txt 17 Jan 2003 10:09:29 -  1.50
  +++ RELEASE-NOTES-4.1.txt 21 Jan 2003 23:19:56 -  1.51
  @@ -62,6 +62,9 @@
   [4.1.19] Documentation:
Added printer friendly versions of the documents.
   
  +[4.1.19] Administration Webapp:
  + Complete the accessibility requirements to pass section 508.
  +
   -
   Catalina New Features:
   -
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/webapps/admin/defaultcontext defaultcontext.jsp

[amyroh]

amyroh  2003/01/21 15:16:37

  Modified:webapps/admin/defaultcontext defaultcontext.jsp
  Log:
  Complete the accessibility requirement for section 508.
  
  Revision  ChangesPath
  1.3   +27 -27
jakarta-tomcat-4.0/webapps/admin/defaultcontext/defaultcontext.jsp
  
  Index: defaultcontext.jsp
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/defaultcontext/defaultcontext.jsp,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- defaultcontext.jsp19 Sep 2002 22:56:05 -  1.2
  +++ defaultcontext.jsp21 Jan 2003 23:16:37 -  1.3
  @@ -37,9 +37,9 @@
 
  
 
  -  
  -
  -  
  +  
  +
  +  
 
- 

 
  @@ -68,10 +68,10 @@
   
   
   
  -
  +
   :
   
  -
  +


  @@ -79,10 +79,10 @@
   
   
   
  -
  +
   :
   
  -
  +


  @@ -90,10 +90,10 @@
   
   
   
  -  
  +  
   :
   
  -
  +


  @@ -101,10 +101,10 @@
   
   
   
  -  
  +  
   :
   
  -
  +


  @@ -112,10 +112,10 @@
   
   
   
  -  
  +  
   :
   
  -
  +


  @@ -147,17 +147,17 @@
   
   
   
  -
  +
   :
   
  -
  +
   
   
   
  -  
  +  
   :
   
  -   
  +   


  @@ -165,10 +165,10 @@
   
   
   
  -  
  +  
   :
   
  -
  +


  @@ -198,17 +198,17 @@
   
   
   
  -
  +
   :
   
  -
  +
   
   
   
  -
  +
   :
   
  -   
  +   


  @@ -216,17 +216,17 @@
   
   
   
  -   
  +   
   :
   
  -   
  +   
   
   
   
  -   
  +   
   :
   
  -   
  +   
   
   
  
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 5 target JDK1.4?

[V. Cekvenich]

iSeris has JDK 1.4 download from IBM, that is my point. (BEA, and Apple 
have it as well so we have multi source).

Today when you download Tomcat 4 you have the 1.4 LE edition just loook 
at the site
Also downloading a jar, ex: http://jdbc.postgresql.org/download.html 
have 1.4 required.
Today!

TC5 is ways of.
And I think everyone can agree that JDK1.4 is more stable than 1.3.

.V

Henri Gomez wrote:
V. Cekvenich wrote:


For TC 4 OK, but TC5 will have tested 4 vendors JVM 1.4.

Most people run JDK 1.4 now.



There is at least one person which didn't run JDK 1.4,
me, since the JDK 1.4 is not available on my iSeries.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

[costin]

costin  2003/01/21 14:49:53

  Modified:jasper2/src/share/org/apache/jasper JspC.java
  Log:
  Use Hans version of the patch.
  
  Revision  ChangesPath
  1.22  +118 -67   
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
  
  Index: JspC.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- JspC.java 21 Jan 2003 19:44:42 -  1.21
  +++ JspC.java 21 Jan 2003 22:49:53 -  1.22
  @@ -4,10 +4,10 @@
* $Date$
*
* 
  - * 
  + *
* The Apache Software License, Version 1.1
*
  - * Copyright (c) 1999 The Apache Software Foundation.  All rights 
  + * Copyright (c) 1999 The Apache Software Foundation.  All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
  @@ -15,7 +15,7 @@
* are met:
*
* 1. Redistributions of source code must retain the above copyright
  - *notice, this list of conditions and the following disclaimer. 
  + *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
  @@ -23,15 +23,15 @@
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
  - *any, must include the following acknowlegement:  
  - *   "This product includes software developed by the 
  + *any, must include the following acknowlegement:
  + *   "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
  - *from this software without prior written permission. For written 
  + *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"
  @@ -57,7 +57,7 @@
* information on the Apache Software Foundation, please see
* .
*
  - */ 
  + */
   
   package org.apache.jasper;
   
  @@ -78,7 +78,7 @@
   import org.apache.jasper.compiler.TagPluginManager;
   
   /**
  - * Shell for the jspc compiler.  Handles all options associated with the 
  + * Shell for the jspc compiler.  Handles all options associated with the
* command line and creates compilation contexts which it then compiles
* according to the specified options.
*
  @@ -99,11 +99,11 @@
   

   
  -
  -

*
  @@ -113,9 +113,9 @@
*/
   public class JspC implements Options {
   
  -public static final String DEFAULT_IE_CLASS_ID = 
  +public static final String DEFAULT_IE_CLASS_ID =
   "clsid:8AD9C840-044E-11D1-B3E9-00805F499D93";
  -
  +
   public static final String SWITCH_VERBOSE = "-v";
   public static final String SWITCH_QUIET = "-q";
   public static final String SWITCH_OUTPUT_DIR = "-d";
  @@ -148,8 +148,8 @@
   
   // future direction
   //public static final String SWITCH_XML_OUTPUT = "-xml";
  -  
  -
  +
  +
   boolean largeFile = false;
   boolean mappedFile = false;
   
  @@ -160,7 +160,7 @@
   String ieClassId = DEFAULT_IE_CLASS_ID;
   
   String targetPackage;
  -
  +
   String targetClassName;
   
   String uriBase;
  @@ -174,11 +174,11 @@
   
   boolean compile=false;
   String compiler=null;
  -
  +
   boolean dirset;
  -
  +
   boolean classDebugInfo=true;
  -
  +
   Vector extensions;
   
   Vector pages = new Vector();
  @@ -193,7 +193,7 @@
   static PrintStream log;
   
   JspCServletContext context;
  -
  +
   /**
* Cache for the TLD locations
*/
  @@ -209,7 +209,7 @@
   // isn't this why we are running jspc?
   return true;
   }
  -
  +
   public boolean getLargeFile() {
   return largeFile;
   }
  @@ -233,7 +233,7 @@
   public Object getProtectionDomain() {
return 

Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging

[Amy Roh]

Jasper currently uses its own private logging facility implemented
in the org.apache.jasper.logging package. This is inconsistent with
the way the other Tomcat subsystems perform logging
(by leveraging the commons-logging package).

Proposal is to remove org.apache.jasper.logging, and replace calls
to it with calls to the commons-logging APIs.

Comments?


+1

Amy




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging

[Jan Luehe]

Hans,

> > Jasper currently uses its own private logging facility implemented
> > in the org.apache.jasper.logging package. This is inconsistent with
> > the way the other Tomcat subsystems perform logging
> > (by leveraging the commons-logging package).
> > 
> > Proposal is to remove org.apache.jasper.logging, and replace calls
> > to it with calls to the commons-logging APIs.
> > 
> > Comments?
> 
> +0. Do you suggest this for TC 5 only, or also for TC 4.1?

Mainly for TC 5, but if there is enough interest, I can apply
the changes to TC 4.1 as well.

Jan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging

[Costin Manolache]

Jan Luehe wrote:

> Jasper currently uses its own private logging facility implemented
> in the org.apache.jasper.logging package. This is inconsistent with
> the way the other Tomcat subsystems perform logging
> (by leveraging the commons-logging package).
> 
> Proposal is to remove org.apache.jasper.logging, and replace calls
> to it with calls to the commons-logging APIs.
> 
> Comments?

Finally...

Thanks

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging

[Hans Bergsten]

Jan Luehe wrote:

Jasper currently uses its own private logging facility implemented
in the org.apache.jasper.logging package. This is inconsistent with
the way the other Tomcat subsystems perform logging
(by leveraging the commons-logging package).

Proposal is to remove org.apache.jasper.logging, and replace calls
to it with calls to the commons-logging APIs.

Comments?


+0. Do you suggest this for TC 5 only, or also for TC 4.1?

Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

[Hans Bergsten]

Costin Manolache wrote:

Sorry, I didn't see the patch - I was precompiling the admin and
hit the problem.

BTW - why don't you fix it yourself - you are committer AFAIK :-) ?


There's a simple reason: it's been so long since I was actively involved
in the development that I (a) want to lurk a bit before I start
making commits, and (b) I've lost my password/key/procedures and
haven't had the time to figure it all out again ;-)

I _will_ start committing again, but I hope you can have some patience
and apply a few patches I submit in the bug database database until
then.

Hans


Hans Bergsten wrote:



[EMAIL PROTECTED] wrote:


costin  2003/01/21 11:44:42

 Modified:jasper2/src/share/org/apache/jasper JspC.java
 Log:
 Support for packages in precompiled servlets - otherwise all go to the
 same package and we get conflicts.


Thanks for finally fixing this, but please use the patch I submitted for
BugID 14302 instead, since it handles special characters in the path
as well. The TagLibraryInfoImpl patch (same BugID) is also required to
support TLDs located in JAR files.

Hans



 Revision  ChangesPath
 1.21  +8 -5 
 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
 
 Index: JspC.java
 ===
 RCS file:
 


/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v


 retrieving revision 1.20 retrieving revision 1.21
 diff -u -r1.20 -r1.21
 --- JspC.java  31 Dec 2002 14:01:17 -  1.20
 +++ JspC.java  21 Jan 2003 19:44:42 -  1.21
 @@ -547,7 +547,10 @@
  targetClassName = null;
  }
  if (targetPackage != null) {
 -clctxt.setServletPackageName(targetPackage);
 +int baseLen=jspUri.lastIndexOf("/");
 +if( baseLen <0 ) baseLen=0;
 +String packageSubs= jspUri.substring(0,
 baseLen).replace( '/', '.' );
 +clctxt.setServletPackageName( targetPackage + "." +
 packageSubs);
  }
  
  setupContext(clctxt);
 @@ -593,7 +596,7 @@
  } else if (dieLevel != NO_DIE_LEVEL) {
  dieOnExit = true;
  }
 -throw new JasperException( e );
 +throw new JasperException( "Error compiling " + file, e );
  }
  }
  
 
 
 

--
To unsubscribe, e-mail:  
 For additional
commands, e-mail: 






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PROPOSAL] Replace Jasper's logging facility with commons-logging

[Jan Luehe]

Jasper currently uses its own private logging facility implemented
in the org.apache.jasper.logging package. This is inconsistent with
the way the other Tomcat subsystems perform logging
(by leveraging the commons-logging package).

Proposal is to remove org.apache.jasper.logging, and replace calls
to it with calls to the commons-logging APIs.

Comments?


Jan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16234] - Click on the context node in administration webapps generates an error

[bugzilla]

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

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

Click on the context node in administration webapps generates an error





--- Additional Comments From [EMAIL PROTECTED]  2003-01-21 21:35 ---
I've redownloaded a version of tomcat 4.1.19 and replaced the
$TOMCAT_HOME/server of my installation with the one contained in the archive,
and it solved my problem...

It was certainly an installation problem...

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16234] - Click on the context node in administration webapps generates an error

[bugzilla]

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

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

Click on the context node in administration webapps generates an error

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2003-01-21 21:21 ---
Cannot reproduce.  Can anyone reproduce the error?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

[Costin Manolache]

Sorry, I didn't see the patch - I was precompiling the admin and
hit the problem.

BTW - why don't you fix it yourself - you are committer AFAIK :-) ?

Costin

Hans Bergsten wrote:

> [EMAIL PROTECTED] wrote:
>> costin  2003/01/21 11:44:42
>> 
>>   Modified:jasper2/src/share/org/apache/jasper JspC.java
>>   Log:
>>   Support for packages in precompiled servlets - otherwise all go to the
>>   same package and we get conflicts.
> 
> Thanks for finally fixing this, but please use the patch I submitted for
> BugID 14302 instead, since it handles special characters in the path
> as well. The TagLibraryInfoImpl patch (same BugID) is also required to
> support TLDs located in JAR files.
> 
> Hans
> 
>>   Revision  ChangesPath
>>   1.21  +8 -5 
>>   jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
>>   
>>   Index: JspC.java
>>   ===
>>   RCS file:
>>   
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
>>   retrieving revision 1.20 retrieving revision 1.21
>>   diff -u -r1.20 -r1.21
>>   --- JspC.java  31 Dec 2002 14:01:17 -  1.20
>>   +++ JspC.java  21 Jan 2003 19:44:42 -  1.21
>>   @@ -547,7 +547,10 @@
>>targetClassName = null;
>>}
>>if (targetPackage != null) {
>>   -clctxt.setServletPackageName(targetPackage);
>>   +int baseLen=jspUri.lastIndexOf("/");
>>   +if( baseLen <0 ) baseLen=0;
>>   +String packageSubs= jspUri.substring(0,
>>   baseLen).replace( '/', '.' );
>>   +clctxt.setServletPackageName( targetPackage + "." +
>>   packageSubs);
>>}
>>
>>setupContext(clctxt);
>>   @@ -593,7 +596,7 @@
>>} else if (dieLevel != NO_DIE_LEVEL) {
>>dieOnExit = true;
>>}
>>   -throw new JasperException( e );
>>   +throw new JasperException( "Error compiling " + file, e );
>>}
>>}
>>
>>   
>>   
>>   
>> 
>> --
>> To unsubscribe, e-mail:  
>>  For additional
>> commands, e-mail: 
>> 
> 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16308] New: - Session.invalidate() does not release sessions

[bugzilla]

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

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

Session.invalidate() does not release sessions

   Summary: Session.invalidate() does not release sessions
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi

I have web application in which I have a logout page where I call 
session.invalidate().  This does not seem to work and session count just keeps 
rising as more users access the application and even if they logout the count 
does not go down.  The session count does go down after session timeout time is 
reached.  But still tomcat never releases memory though, it just keeps growing 
and ultimately crash with out of memory error.

I monitored this uing tomcats manager application's manager/list call

The problem here is 
1.  Tomcat does not release sessions that are invalidated.
2.  Tomcat does not release memory after the sessions that are released after 
session timeouts.
3.  Tomcat persists the sessions from previous run too.

Please help

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12196] - request.getRemoteUser() returns null for AJP request with remote username

[bugzilla]

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

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

request.getRemoteUser() returns null for AJP request with remote username





--- Additional Comments From [EMAIL PROTECTED]  2003-01-21 20:26 ---
I'm a bit confused about tomcatAuthentication="false".  It existed as an option 
in the Coyote connector at least up to version 4.1.12.  Remy says the 
workaround is to put tomcatAuthentication="false" in the jk2.properties.  
However, Dan Dexter has reported that this doesn't work and I am using mod_jk, 
not jk2.  How do I make getRemoteUser() to work with mod_jk and the latest 
versions of Tomcat using the Coyote connector?

Jake

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

[Hans Bergsten]

[EMAIL PROTECTED] wrote:

costin  2003/01/21 11:44:42

  Modified:jasper2/src/share/org/apache/jasper JspC.java
  Log:
  Support for packages in precompiled servlets - otherwise all go to the
  same package and we get conflicts.


Thanks for finally fixing this, but please use the patch I submitted for
BugID 14302 instead, since it handles special characters in the path
as well. The TagLibraryInfoImpl patch (same BugID) is also required to
support TLDs located in JAR files.

Hans


  Revision  ChangesPath
  1.21  +8 -5  jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
  
  Index: JspC.java
  ===
  RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- JspC.java	31 Dec 2002 14:01:17 -	1.20
  +++ JspC.java	21 Jan 2003 19:44:42 -	1.21
  @@ -547,7 +547,10 @@
   targetClassName = null;
   }
   if (targetPackage != null) {
  -clctxt.setServletPackageName(targetPackage);
  +int baseLen=jspUri.lastIndexOf("/");
  +if( baseLen <0 ) baseLen=0;
  +String packageSubs= jspUri.substring(0, baseLen).replace( '/', '.' );
  +clctxt.setServletPackageName( targetPackage + "." + packageSubs);
   }
   
   setupContext(clctxt);
  @@ -593,7 +596,7 @@
   } else if (dieLevel != NO_DIE_LEVEL) {
   dieOnExit = true;
   }
  -throw new JasperException( e );
  +throw new JasperException( "Error compiling " + file, e );
   }
   }
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Making PureTLS work

[Eric Rescorla]

Remy Maucherat <[EMAIL PROTECTED]> writes:
> Eric Rescorla wrote:
> >>If PureTLS isn't compatible with IBM JVM, then fine, but I can't see
> >>its usefulness.
> > It shouldn't be incompatible. What's going on here is a provider
> > conflict.
> 
> > You need to ensure that Cryptix is ahead of whatever IBM provider you
> > ahve installed.
> 
> That is possible, I didn't think of setting Cryptix as endorsed. I did
> try it with PureTLS, though.
PureTLS needs Cryptix.

> I had similar problem with JSSE and the IBM VM.
Java crypto support could be a lot better.

-Ekr


-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

[costin]

costin  2003/01/21 11:44:42

  Modified:jasper2/src/share/org/apache/jasper JspC.java
  Log:
  Support for packages in precompiled servlets - otherwise all go to the
  same package and we get conflicts.
  
  Revision  ChangesPath
  1.21  +8 -5  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
  
  Index: JspC.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- JspC.java 31 Dec 2002 14:01:17 -  1.20
  +++ JspC.java 21 Jan 2003 19:44:42 -  1.21
  @@ -547,7 +547,10 @@
   targetClassName = null;
   }
   if (targetPackage != null) {
  -clctxt.setServletPackageName(targetPackage);
  +int baseLen=jspUri.lastIndexOf("/");
  +if( baseLen <0 ) baseLen=0;
  +String packageSubs= jspUri.substring(0, baseLen).replace( '/', '.' 
);
  +clctxt.setServletPackageName( targetPackage + "." + packageSubs);
   }
   
   setupContext(clctxt);
  @@ -593,7 +596,7 @@
   } else if (dieLevel != NO_DIE_LEVEL) {
   dieOnExit = true;
   }
  -throw new JasperException( e );
  +throw new JasperException( "Error compiling " + file, e );
   }
   }
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Making PureTLS work

[Remy Maucherat]

Eric Rescorla wrote:

Remy Maucherat <[EMAIL PROTECTED]> writes:



Hi,

I was wondering if people among the happy few who got PureTLS (0.9b3)
running with Tomcat 4.1 or 5.0 post some kind of small HOWTO.


I'm running Linux (RH 7.3, with IBM 1.4.0 or Sun 1.4.1).

I read on the PureTLS website (err, sorry webpage) that it supported
OpenSSL certs. So I should be able to reuse the certs I generated for
mod_ssl ?


Yes.



If PureTLS isn't compatible with IBM JVM, then fine, but I can't see
its usefulness.


It shouldn't be incompatible. What's going on here is a provider conflict.
You need to ensure that Cryptix is ahead of whatever IBM provider you
ahve installed.


That is possible, I didn't think of setting Cryptix as endorsed. I did 
try it with PureTLS, though.

I had similar problem with JSSE and the IBM VM.

As for the error with Sun VM, I don't know what to do
(there doesn't seem to be any docs at all anywhere) ...


Hmmm The Sun error looks to me like a standard password
conflict. Are you sure you have the right password?


Mm, I'll check. Since I couldn't find what type of certificate it 
needed, I decided to try first with the ones included with the PureTLS 
distribution.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jasper, JMX and JSR77

[Glenn Nielsen]

I have looked at JSR 77, but not in depth.

I am all for instrumenting Tomcat using JMX where it makes sense.

And will help when/if I have time.

Glenn

Costin Manolache wrote:

JSR77 defines a certain model - in particular a WebModule must
include an attribute "servlets[]" that lists all the servlets
in the webapp, and it also requires on JMX mbean per servlet.
( tomcat uses that to provide all kind of performance and 
statistical info ).

The problem is - JSPs are not visible, since Jasper creates them
internally. One solution is to turn JspServletWrapper into
an interface, with a GenericServletWrapper impl ( the current code )
and a mechanism to create container-specific wrappers. 
A TomcatServletWrapper can hook JSP servlets into JMX and
it may also provide future tomcat-specific optimizations ( like
bypassing JspServlet - by registering the ServletWrapper directly 
into the mapper ).

Questions:
- do we want to do that ( there is some extra complexity and some
work ) ? Does anyone care about JSR77 support in tomcat ?

- where should TomcatServletWrapper live - jasper can have an optional
dependency on catalina, or catalina can have an optional dependency on
jasper.

- should we extend JMX support to other jasper components - to report
things like compilation times, tag pool usage, tag usage, etc ?

- anyone willing to help, or I'm alone  :-) ?


Costin 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


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


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jasper, JMX and JSR77

[Hans Bergsten]

Costin Manolache wrote:

JSR77 defines a certain model - in particular a WebModule must
include an attribute "servlets[]" that lists all the servlets
in the webapp, and it also requires on JMX mbean per servlet.
( tomcat uses that to provide all kind of performance and 
statistical info ).

The problem is - JSPs are not visible, since Jasper creates them
internally. One solution is to turn JspServletWrapper into
an interface, with a GenericServletWrapper impl ( the current code )
and a mechanism to create container-specific wrappers. 
A TomcatServletWrapper can hook JSP servlets into JMX and
it may also provide future tomcat-specific optimizations ( like
bypassing JspServlet - by registering the ServletWrapper directly 
into the mapper ).

Questions:

Just some answers from the floor:


- do we want to do that ( there is some extra complexity and some
work ) ? Does anyone care about JSR77 support in tomcat ?


I think JMX and JSR77 is interesting, even though I admit I haven't
read up on it yet, so yes. But I suggest that major changes like
this are restricted to TC 5, and that we keep TC 4.1 possible to use
without any JMX dependencies (which is possible with TC 4.1.18).

I've just released a slimmed down and modularized version of TC 4.1.18
plus a module management web app, distributed under the name
LiteWebServer. One of the main points with this distribution is that
it's _small_, so I strip off all JARs (and even individual classes) that
are not needed for the base functionality (some of it can be added
through add-on modules to enable specific features). I've managed to
exclude all JMX and MBeans stuff so far, and I hope I can continue to
do so as long as it's based on the TC 4.1 tree.


- where should TomcatServletWrapper live - jasper can have an optional
dependency on catalina, or catalina can have an optional dependency on
jasper.


It would make most sense to me to make Catalina have an optional
dependency on Jasper for this; it's only when you use Jasper with
Catalina that you get the JMX support, but Jasper can be used without
it in other containers.


- should we extend JMX support to other jasper components - to report
things like compilation times, tag pool usage, tag usage, etc ?


Sounds cool :-) As long as it doesn't add too much overhead.


- anyone willing to help, or I'm alone  :-) ?


I'm +0 for TC 5. Eventually, I hope to find time to help out with TC 5,
but for now I need to focus on TC 4.1.

Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Making PureTLS work

[Eric Rescorla]

Remy Maucherat <[EMAIL PROTECTED]> writes:

> Hi,
> 
> I was wondering if people among the happy few who got PureTLS (0.9b3)
> running with Tomcat 4.1 or 5.0 post some kind of small HOWTO.
> 
> 
> I'm running Linux (RH 7.3, with IBM 1.4.0 or Sun 1.4.1).
> 
> I read on the PureTLS website (err, sorry webpage) that it supported
> OpenSSL certs. So I should be able to reuse the certs I generated for
> mod_ssl ?
Yes.

> If PureTLS isn't compatible with IBM JVM, then fine, but I can't see
> its usefulness.
It shouldn't be incompatible. What's going on here is a provider conflict.
You need to ensure that Cryptix is ahead of whatever IBM provider you
ahve installed.

> As for the error with Sun VM, I don't know what to do
> (there doesn't seem to be any docs at all anywhere) ...
Hmmm The Sun error looks to me like a standard password
conflict. Are you sure you have the right password?

-Ekr


-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

strange messages in tomcat 4.1.18

[Raiden]

Hello,

I apologize for posting this question to this group, but I have been
unable to get an answer in the tomcat-user group.  My catalina.out logs
are full of the following messages:

Jan 21, 2003 10:31:41 AM org.apache.jk.common.ChannelSocket
processConnection
INFO: server has been restarted or reset this connection
Jan 21, 2003 10:31:42 AM org.apache.jk.common.ChannelSocket
processConnection
INFO: server has been restarted or reset this connection
Jan 21, 2003 10:31:43 AM org.apache.jk.common.ChannelSocket
processConnection
INFO: server has been restarted or reset this connection
Jan 21, 2003 10:31:45 AM org.apache.jk.common.ChannelSocket
processConnection
INFO: server has been restarted or reset this connection
Jan 21, 2003 10:31:47 AM org.apache.jk.common.ChannelSocket
processConnection
INFO: server has been restarted or reset this connection

Assuming these are non-harmful messages (are they?), is there a way to
turn them off, so that they're not flooding my logs?  They appear to
happen everytime an apache/mod_jk/mod_jk2 worker creates a connection to
Tomcat.

Thanks,
Raiden



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Jasper, JMX and JSR77

[Costin Manolache]

JSR77 defines a certain model - in particular a WebModule must
include an attribute "servlets[]" that lists all the servlets
in the webapp, and it also requires on JMX mbean per servlet.
( tomcat uses that to provide all kind of performance and 
statistical info ).

The problem is - JSPs are not visible, since Jasper creates them
internally. One solution is to turn JspServletWrapper into
an interface, with a GenericServletWrapper impl ( the current code )
and a mechanism to create container-specific wrappers. 
A TomcatServletWrapper can hook JSP servlets into JMX and
it may also provide future tomcat-specific optimizations ( like
bypassing JspServlet - by registering the ServletWrapper directly 
into the mapper ).

Questions:
- do we want to do that ( there is some extra complexity and some
work ) ? Does anyone care about JSR77 support in tomcat ?

- where should TomcatServletWrapper live - jasper can have an optional
dependency on catalina, or catalina can have an optional dependency on
jasper.

- should we extend JMX support to other jasper components - to report
things like compilation times, tag pool usage, tag usage, etc ?

- anyone willing to help, or I'm alone  :-) ?


Costin 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Tomcat 5 target JDK1.4?

[Costin Manolache]

Martin Algesten wrote:

>> I use vi for at least 14 years, but for java dev I turned to
>> eclipse last year, and it's hard to reswicth to vi ;)
> 
> Wow! I tried to use Borland J something or another a long time ago and
> got to frustrated that I didn't have control over what I was doing...
> what are the advantages?

Very fast navigation if you work with hundreds of classes.
Code completion that works ( and is context sensitive, displays
param info as you type, etc ). Refactoring ( rename or move something and 
it'll find all usages and replace them ). Find who uses or implements 
something. 

I only used vi 12 years, and emacs for about 7 - but I don't think
I can turn back.
( eclipse looks nice, but it needs real key customization. Netbeans
is even nicer - but too slow for my laptop )

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Tomcat 5 target JDK1.4?

[Martin Algesten]

> I use vi for at least 14 years, but for java dev I turned to 
> eclipse last year, and it's hard to reswicth to vi ;)

Wow! I tried to use Borland J something or another a long time ago and
got to frustrated that I didn't have control over what I was doing...
what are the advantages?

Martin

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 5 target JDK1.4?

[Henri Gomez]

Costin Manolache wrote:

I use Idea. I should start learning vi :-) 

( well, I do use emacs and vi a lot - but not for java, so I
may still have a chance ... )

I use vi for at least 14 years, but for java dev I turned to
eclipse last year, and it's hard to reswicth to vi ;)





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: DO NOT REPLY [Bug 3597] - Tomcat shutting down takes "ages"

[Jindong Li]

 -Original Message-
From:   [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
Sent:   Tuesday, January 21, 2003 11:00 AM
To: [EMAIL PROTECTED]
Subject:DO NOT REPLY [Bug 6007]  -  JSP-servlet cache is not deleted

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

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





--- Additional Comments From [EMAIL PROTECTED]  2003-01-21 15:59
---
I think we're experiencing something very similar to what's happened here,
only to a lesser extend.

We're using SUN's JVM (build 1.3.1_01) on W2K, what happened when we were
trying out Tomcat 4.0.5 / 4.0.6/ 4.1.x is that when shutting down Tomcat,
there would be a delay of around 30 to 40 secs.

We've always used Tomcat 4.0.1 and don't have this delay issue when shutting
down.

We've since installed JDK1.4.1 and the delay when shutting down TC
405/406/41x no longer exists.

I wonder if this relates to the same thread.interrupt() bug possibily exists
in SUN's JDK131?

Anybody else has had similar experience?

The dillema of running JDK141 is that it has some other bugs that prevent
our application from working properly.

Any comments would be greatly appreciated.

Jindong.
--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 5 target JDK1.4?

[Costin Manolache]

I use Idea. I should start learning vi :-) 

( well, I do use emacs and vi a lot - but not for java, so I
may still have a chance ... )

Costin

Glenn Nielsen wrote:

> This is off topic, but I do the same.
> 
> Glenn
> 
> Shapira, Yoav wrote:
>> Howdy,
>> 
>> 
>>>The first thing I ask programmers I hire is "How do you prefer to
>>>program? What is your environment like?" ... If the answer is along the
>>>lines of "vi", "emacs", "notepad", "zsh", "bash", "windows command
>>>line", then I feel much relieved...
>> 
>> 
>> Wow, that's kind of amazing -- I use the exact same question and like
>> the same answers ;)
>> 
>> Yoav Shapira
>> Millennium ChemInformatics
>> 
>> --
>> To unsubscribe, e-mail:  
>>  For additional
>> commands, e-mail: > 
> 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 5 target JDK1.4?

[Henri Gomez]

V. Cekvenich wrote:



Glenn Nielsen wrote:


V. Cekvenich wrote:


For TC 4 OK, but TC5 will have tested 4 vendors JVM 1.4.

Most people run JDK 1.4 now.



Perhaps you do, but where is the data to support your claim above that
most people run JDK 1.4?



Going around to clients site. What are you running..


Those who have systems in production and have spent alot of time 
developing
applications which are hosted on those systems can't do a major 
upgrade like
JVM 1.3 -> JVM 1.4 at the drop of a hat.


Drop of the hat == when is TC5 due?

Anyway, no one is arguing my side that we must have progress.
JRockit, a popular VM is JDK 1.4. And IBM has a download that supports 
AS400 on 1.4, and Apple is coming out.
In Java, the whole point is you can go switch out a VM, at a drop of a hat.
I mean, JDK 1.5 is coming out.

iSeries got support for 1.4 ?

I just discovered it but I didn't see how to get it on my V5R2
and there is not a major announce of it on iseries site.

BTW, why should we make JDK 1.4 mandatory ?





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 5 target JDK1.4?

[Henri Gomez]

V. Cekvenich wrote:

For TC 4 OK, but TC5 will have tested 4 vendors JVM 1.4.

Most people run JDK 1.4 now.


There is at least one person which didn't run JDK 1.4,
me, since the JDK 1.4 is not available on my iSeries.





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16299] New: - admin page gives a HTTP 500 error

[bugzilla]

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

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

admin page gives a HTTP 500 error

   Summary: admin page gives a HTTP 500 error
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have tried this with j2sdk1.4.0 and j2sdk1.4.1.
I have installed Tomcat 4.1.18

Tomcat starts up fine. When i try to go to the Admin page
127.0.0.1:8080/admin,

I get HTTP 500:
type Exception report

message description 
The server encountered an internal error () that prevented it from fulfilling 
this request.

exception 

org.apache.jasper.JasperException: Unable to compile class for JSP

An error occurred at line: 6 in the jsp file: /header.jsp

Generated servlet error:
[javac] Compiling 1 source file

C:\Program Files\Apache Group\Tomcat 4.1
\work\Standalone\localhost\admin\login_jsp.java:11: cannot access 
java.lang.Object



An error occurred at line: 6 in the jsp file: /header.jsp

Generated servlet error:
bad class file: C:\j2sdk1.4.0\jre\lib\rt.jar(java/lang/Object.class)
class file has wrong version 48.0, should be 47.0
Please remove or make sure it appears in the correct subdirectory of the 
classpath.
  private static java.util.Vector _jspx_includes;
 ^
1 error


at org.apache.jasper.compiler.DefaultErrorHandler.javacError
(DefaultErrorHandler.java:130)
at org.apache.jasper.compiler.ErrorDispatcher.javacError
(ErrorDispatcher.java:293)
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:340)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:352)
at org.apache.jasper.JspCompilationContext.compile
(JspCompilationContext.java:474)
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:184)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:260)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke
(AuthenticatorBase.java:550)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:172)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.

Re: Tomcat 5 target JDK1.4?

[Glenn Nielsen]

This is off topic, but I do the same.

Glenn

Shapira, Yoav wrote:

Howdy,



The first thing I ask programmers I hire is "How do you prefer to
program? What is your environment like?" ... If the answer is along the
lines of "vi", "emacs", "notepad", "zsh", "bash", "windows command
line", then I feel much relieved...



Wow, that's kind of amazing -- I use the exact same question and like
the same answers ;)

Yoav Shapira
Millennium ChemInformatics

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 
For additional commands, e-mail: 

DO NOT REPLY [Bug 6007] - JSP-servlet cache is not deleted

[bugzilla]

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

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

JSP-servlet cache is not deleted





--- Additional Comments From [EMAIL PROTECTED]  2003-01-21 15:59 ---
I just read this bug, and it seems that there is a simple solution. The notion
of doing checksums is calculationally intensive, and therefore unacceptable, but
you don't need a check sum. All you need is the date on the JSP file. Store it
in a file called foo.class.jspdate and compare that date to the one on the JSP..
if it differs + or - recompile. One might even be able to add this information
directly into the generated .java (and thus .class) file as a constant int where
it can be checked without another file access.

If the extra file access solution needs to be turned off for production make
this check only happen if tomcat is started with soemthing like a -devel flag or
somesuch.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] bug 14436 - "RequestDispatcher Drops Query String"

[John Downing]

This is regarding (alleged) bug 14436 - "RequestDispatcher Drops Query
String"

Noticed 14436 in the Bug Database. We had two situations that were almost
identical. One where the resource path to dispatch to (a servlet) had its
own query string .. the JSP page that the servlet then forwarded to was
unable to see the query string from the original, dispatching request. 

And one where a dynamically included JSP page was not able to see request
parameters from the page it was included in (unless they were explicitly
passed in using jsp:param).

The following patch fixed both situations, so am including it in case it's
useful for anyone else. 

Whether or not it fixes 14436, or is the behavior required by the spec, is
something I haven't had time to look into. As is how far this works with
nested dispatches .. the existing code stores separate references to
appRequest, outerRequest etc .. not sure if  a proper fix will need to store
appQueryString, outerQueryString, etc, rather than just concatenating them
together ?

Anyway, hope it helps :)

Cheers,
John

PS - this is the first time I've sent in a patch (or indeed contributed to
the list) so if I'm doing anything wrong please let me know. I gotta learn
(!)


Index: ApplicationDispatcher.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/co
re/ApplicationDispatcher.java,v
retrieving revision 1.30
diff -u -r1.30 ApplicationDispatcher.java
--- ApplicationDispatcher.java  9 Jun 2002 05:45:04 -   1.30
+++ ApplicationDispatcher.java  19 Jan 2003 12:16:53 -
@@ -811,7 +811,23 @@
 this.outerResponse = response;
 this.including = including;
 
+// Workaround for (alleged) bug 14436 - the resource we're
dispatching to doesn't
+// otherwise see the query string of the request we're dispatching
from ..
+if (request instanceof HttpServletRequest) {
+String requestQueryString =
((HttpServletRequest)request).getQueryString();
+
+if (requestQueryString != null) {
+if (this.queryString == null || this.queryString.length()
== 0) {
+this.queryString = requestQueryString;
+}
+else {
+this.queryString += "&" + requestQueryString;
+}
+}
+}
 }
+
 
 
 /**

>Hello,
>
>I'm using TC 4.1.12 on Win 2k. I'm using the TC Coyote Connector.
>
>I've checked the Servlet v2.3 spec and the behavior I'm seeing in TC seems
to 
>go against the spec. In general, the problem is that the original query
string 
>is not properly aggregated when a servlet is invoked using a
RequestDispatcher 
>where and the target servlet has its own query string. Here's an example:
>
>I have a servlet called "servletA". Let's say "servletA" is invoked from a 
>browser with this URL:
>
>
>
>Within "servletA" we create a RequestDispatcher for "servletB" and then
forward 
>to "servletB" like this:
>
>RequestDispatcher rd = request.getRequestDispatcher("servletB");
>rd.forward(request, response);
>
>In "servletB", a call to "request.getQueryString()" returns the string
"x=1". 
>In other words, "servletB" is able to "see" the query string used to 
>invoke "servletA". Okay, so far, so good.
>
>Now, here's the problem: If "servletA" appends a query string to "servletB"

>when creating the RequestDispatcher like this:
>
>RequestDispatcher rd = request.getRequestDispatcher("servletB?z=1");
>
>"servletB" will only see the query string, "z=1", it will *no longer* see 
>the "x=1" query string.
>
>What I *expect* to see in "servletB" is a query string "x=1&z=1" -- i.e., 
>*both* query strings.
>
>Let me quote from SRV.8.1.1 (Servlet 2.3): "Parameters specified in the
query 
>string used to create the RequestDispatcher take precedence over other 
>parameters of the same name passed to the included servlet."
>
>In my example, the parameter names are *not* the same ("x" and "z") so the
"z" 
>parameter should not take precedence over "x". Also, the quote above refers
to 
>the "included servlet". I believe this generically refers to forwarded
servlets 
>as well. The example in the spec just happens to be using include() rather
than 
>forward().
>
>Finally, I would like to mention what happens if you use the 
>RequestDispatcher.include() method rather than forward(). Using my example 
>above, if you change forward() to include(), "servletB" will only see the
"x=1" 
>query string. It will *never* see the "z=1".
>
>One last quote from the servlet spec (SRV.8.4.1): "The request dispatching 
>mechanism is responsible for aggregating query string parameters when 
>forwarding or including responses."
>
>So, can you confirm that this is a bug?
>
>Thanks very much...






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16297] New: - PureTLS failing to initialize

[bugzilla]

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

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

PureTLS failing to initialize

   Summary: PureTLS failing to initialize
   Product: Tomcat 4
   Version: 4.1.19
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm running Linux (RH 7.3, with IBM 1.4.0 or Sun 1.4.1) with PureTLS 0.9b3.

I read on the PureTLS website (err, sorry webpage) that it supported OpenSSL
certs. So I should be able to reuse the certs I generated for mod_ssl ?
Anyway, that's for later. In order to avoid making mistakes, I reused the .pem
files I found in the distribution.
After tweaking my server.xml to point at the right files (of course, I had to
read the sources to know how to do it), I got the following exceptions:

- with IBM JDK:
Caused by: java.lang.InternalError: java.security.NoSuchAlgorithmException:
class configured for Cipher: com.ibm.crypto.
provider.DESedeCipher is not a subclass of xjava.security.Cipher
at COM.claymoresystems.crypto.PEMData.readPEMObject(Unknown Source)
at
COM.claymoresystems.crypto.EAYEncryptedPrivateKey.createPrivateKey(Unknown Source)
at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown Source)
at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown Source)
at
org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(PureTLSSocketFactory.java:165)
at
org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.createSocket(PureTLSSocketFactory.java:104)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:275)

- with Sun JDK:
java.io.IOException: PKCS#5: Invalid number of padding bytes
at
org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(PureTLSSocketFactory.java:175)
at
org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.createSocket(PureTLSSocketFactory.java:104)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:275)
at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:150)

The connector configuration is:

  


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Making PureTLS work

[Martin Algesten]

This list is for development of the Tomcat please forward to tomcat-user
etc etc ;)

Martin (sorry, couldn't stop myself)


> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]] 
> Sent: 21 January 2003 15:04
> To: Tomcat Developers List
> Subject: Making PureTLS work
> 
> 
> Hi,
> 
> I was wondering if people among the happy few who got PureTLS (0.9b3) 
> running with Tomcat 4.1 or 5.0 post some kind of small HOWTO.
> 
> I'm running Linux (RH 7.3, with IBM 1.4.0 or Sun 1.4.1).
> 
> I read on the PureTLS website (err, sorry webpage) that it supported 
> OpenSSL certs. So I should be able to reuse the certs I generated for 
> mod_ssl ?
> Anyway, that's for later. In order to avoid making mistakes, I reused 
> the .pem files I found in the distribution.
> After tweaking my server.xml to point at the right files (of 
> course, I 
> had to read the sources to know how to do it), I got the following 
> exceptions:
> 
> - with IBM JDK:
> Caused by: java.lang.InternalError: 
> java.security.NoSuchAlgorithmException: class configured for Cipher: 
> com.ibm.crypto.
> provider.DESedeCipher is not a subclass of xjava.security.Cipher
>  at 
> COM.claymoresystems.crypto.PEMData.readPEMObject(Unknown Source)
>  at 
> COM.claymoresystems.crypto.EAYEncryptedPrivateKey.createPrivat
> eKey(Unknown 
> Source)
>  at 
> COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown 
> Source)
>  at 
> COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown 
> Source)
>  at 
> org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(P
> ureTLSSocketFactory.java:165)
>  at 
> org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.create
> Socket(PureTLSSocketFactory.java:104)
>  at 
> org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTc
> pEndpoint.java:275)
> 
> - with Sun JDK:
> java.io.IOException: PKCS#5: Invalid number of padding bytes
>  at 
> org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(P
> ureTLSSocketFactory.java:175)
>  at 
> org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.create
> Socket(PureTLSSocketFactory.java:104)
>  at 
> org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTc
> pEndpoint.java:275)
>  at 
> org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:150)
> 
> If PureTLS isn't compatible with IBM JVM, then fine, but I 
> can't see its 
> usefulness. As for the error with Sun VM, I don't know what 
> to do (there 
> doesn't seem to be any docs at all anywhere) ...
> 
> Any ideas ?
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Making PureTLS work

[Remy Maucherat]

Hi,

I was wondering if people among the happy few who got PureTLS (0.9b3) 
running with Tomcat 4.1 or 5.0 post some kind of small HOWTO.

I'm running Linux (RH 7.3, with IBM 1.4.0 or Sun 1.4.1).

I read on the PureTLS website (err, sorry webpage) that it supported 
OpenSSL certs. So I should be able to reuse the certs I generated for 
mod_ssl ?
Anyway, that's for later. In order to avoid making mistakes, I reused 
the .pem files I found in the distribution.
After tweaking my server.xml to point at the right files (of course, I 
had to read the sources to know how to do it), I got the following 
exceptions:

- with IBM JDK:
Caused by: java.lang.InternalError: 
java.security.NoSuchAlgorithmException: class configured for Cipher: 
com.ibm.crypto.
provider.DESedeCipher is not a subclass of xjava.security.Cipher
at COM.claymoresystems.crypto.PEMData.readPEMObject(Unknown Source)
at 
COM.claymoresystems.crypto.EAYEncryptedPrivateKey.createPrivateKey(Unknown 
Source)
at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown 
Source)
at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown 
Source)
at 
org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(PureTLSSocketFactory.java:165)
at 
org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.createSocket(PureTLSSocketFactory.java:104)
at 
org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:275)

- with Sun JDK:
java.io.IOException: PKCS#5: Invalid number of padding bytes
at 
org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(PureTLSSocketFactory.java:175)
at 
org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.createSocket(PureTLSSocketFactory.java:104)
at 
org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:275)
at 
org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:150)

If PureTLS isn't compatible with IBM JVM, then fine, but I can't see its 
usefulness. As for the error with Sun VM, I don't know what to do (there 
doesn't seem to be any docs at all anywhere) ...

Any ideas ?

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tag Pooling ( was: Re: DO NOT REPLY [Bug 16001] - Tag.release()not invoked

[Glenn Nielsen]

Costin Manolache wrote:

Taking Glenn's post out of thread:


Glenn Nielsen wrote:



Per JSP Page (current)
--

The current tag pool manages one or more pools of tags on a per JSP
page basis. With a synchronized method call for each get/reuse pair
for a TagHandler used in the page. That page could have as many current
requests as Processor threads.  The TagHandlerPool's for the JSP page
could grow to the point where they have as many TagHandler elements
as needed to handle the maximum number of concurrent requests (Threads).



If we're going to keep the current around - we should at least increase
the limit. 




Per JSP Page Thread Local
-

Switching this to ThreadLocal would remove all need for synchronized
access for the TagHandlerPool get/reuse but significantly increase the
memory usage. You end up with a TagHandlerPool for each thread, for each
JSP page.

Both of these could require enoubh memory to hold the number of TagHandler
classes = Number of Threads * Number of JSP pages * Number of unique
TagHandlers needed per JSP



A mechanism to clean up unused pools could help reduce this ( similar with 
ThreadPool ). ( maybe combined with some JMX to give insight into how many 
pools and tags are in used - quite usefull ).

This is the classical "memory versus time" - a choice that users should make
for themself, depending on the application they run. A production site with 
a lot of memory and very high traffic on few pages may choose the speed.



There are two other options based on managing a global tag pool rather
than
a per JSP page tag pool.  If you have many JSP pages with custom tags
there
will be common tags/attributes used across all of them.  Why not be able
to reuse these TagHandler's across all the JSP pages instead of on a per
JSP page basis. This could significantly reduce the number of instances of
TagHandler's
which have to be pooled, and the memory the consume.  Consider the JSTL
c:if tag and how many times it could get used across 20 different JSP
pages.



If this is still thread local - I'm +0 ( i.e. I won't implement it, but
I think it's a great idea ).

That would make it ( threads * maxTag ), where maxTag is the maximum number
of one tag in any page. 

It shouldn't be hard - you'll need to pass the context and keep the
ThreadLocal in the context.

Of course - keep in mind that you need one pool for each tag+attribute_set
( another wise requirement..)



Global


Let me rename this:

Context Global
--



--

TagHandlerPool's which are global and pool all unique TagHandler classes
for all JSP pages. In this case you would require one synchronized call at
the start of the JSP page to populate its local pool with reusable
TagHandler's from the global pool. Then on JSP page exit return the
TagHandler's from its local pool to the global. Requires two synchronized
method calls per JSP page execution, but mimimizes the memory footprint of
pooled tags.



If by global you mean cross-context - I don't think it would work ( 
versioning, security, etc ).


No, Global means global within a single webapp but pools tags for all
JSP pages within a context.  There are too many problems trying to pool
cross-context due to each context having its own WebappClassLoader.





Global Thread Local


Let me rename this:

Context Global Thread Local
---


---

TagHandlerPool's which are global within a thread and pool all unique
TagHandler classes for all JSP pages which execute within the thread. No
synchronized methods
would be required for this design.  This would have a smaller memory
footprint than the Per JSP Page (current) and Per Jsp Page Thread Local
tag pools, but use more memory than the Global tag pool.



Again - if by global you mean per context, +1. Per server is too dangerous
( a thread can hold on the reference for a tag and access it when it is 
in used in a different context ).



Yes, Global means global within a single webapp but pools tags for all
JSP pages within the context.  There are too many problems trying to pool
cross-context due to each context having its own WebappClassLoader.




Of the four designs above I think the Global Thread Local design may be
the best. It removes the need for synchronized get/reuse and has a smaller
memory footprint than the Per JSP Page tag pool design.



+1 for Context Thread Local ( eventually combined with some expiration
strategy ).



Was that a +1 to the renamed Context Global Thread Local?

Glenn



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Why unpackWars=true default?

[Shapira, Yoav]

Howdy,

>always apply).  All custom data in our apps is either stored in the
>user.home directory, the preferences API, JNDI, or whatever.  We tend
to
>consider the ".war" file like an ".exe" or executable JAR file.

And I think this is where my interest comes from.  Your considerations
are exactly the opposite of Costin's (I think it was Costin anyways),
who considers the .war file a *deployment* format only, like an RPM or a
Windows Installer file, not to be run as an executable.

I think a lot of users are confused on this point.  That's not tomcat's
fault by any means.  I think tomcat goes above and beyond the spec with
its support for packed/unpacked wars, XML app descriptors, and the whole
automatic app deployment feature.  

Personally, I think of a .war as a deployment format.  I think what the
server does with it (e.g. unpack, copy into a database in Oracle iAS,
etc.) is an implementation detail that users shouldn't know about.

Thanks everyone for answering my original question.  It was very
interesting to read responses from the developers.
  
Yoav Shapira
Millennium ChemInformatics

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16294] New: - Configurable URL Decoding.

[bugzilla]

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

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

Configurable URL Decoding.

   Summary: Configurable URL Decoding.
   Product: Tomcat 4
   Version: Unknown
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Currently URLs are decoded with a hard coded UTF8 encoding.
(Apparently this value is also hardcoded in several classes.)
This is per se a bad thing.

Additionally, there are valid reasons for wanting to use other
encodings. (Cf. http://issues.apache.org/bugzilla/show_bug.cgi?id=15810).

Correspondingly, catalina would profit from having a centrally
configurable URL decoding.

(Of course similar points apply to other cases of encoding and hard coded
values in general.)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Tomcat 5 target JDK1.4?

[Shapira, Yoav]

Howdy,

>The first thing I ask programmers I hire is "How do you prefer to
>program? What is your environment like?" ... If the answer is along the
>lines of "vi", "emacs", "notepad", "zsh", "bash", "windows command
>line", then I feel much relieved...

Wow, that's kind of amazing -- I use the exact same question and like
the same answers ;)

Yoav Shapira
Millennium ChemInformatics

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Why unpackWars=true default?

[Chris Brown]

> Would it be better to remove unpackWARs from tomcat5 since there isn't
> that much of a concern for backwards compatibilty on major releases?
>
> -Tim

It should always be at least an option to deploy WAR files without unpacking
them.

Systematically unpacking WARs would cause problems: the unpacked version is
always used in preference to the packed version by Tomcat, so if
unpackWARs="true", then overwriting the original ".war" file has no effect
(because of the preference for using the directory if it exists), making
upgrade deployment of webapps very problematic, leading to lots of support
calls for us ("I replaced the WAR file, but nothing happens!").

It seems like a bad idea in many cases (obviously not all) to allow
modifications within the webapp itself on production deployments (small
sites and development releases of webapps are examples where this wouldn't
always apply).  All custom data in our apps is either stored in the
user.home directory, the preferences API, JNDI, or whatever.  We tend to
consider the ".war" file like an ".exe" or executable JAR file.

- Chris



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16290] New: - Unresolved entities in included JSP file

[bugzilla]

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

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

Unresolved entities in included JSP file

   Summary: Unresolved entities in included JSP file
   Product: Tomcat 4
   Version: 4.1.18
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hello,

I have a probleme with JSP pages written in XML. The entities defined in a DTD
for a JSP page (i.e index.jsp) doesn't apply to pages included from this jsp
(i.e menu.jsp).

Nothing in JSP specification 1.2 explain how to handle this case AFAIK, but in
xml, i think that the DTd must apply to all the node of the document, including
the nodes added during the construction of the page by inclusion.

Sample test case


File test_include.jsp :


]>
 
http://java.sun.com/JSP/Page";
 version="1.2">
 
  
 
 
 
 
File test_included.jsp :
  
 
When i access to test_include.jsp :
 
XML Parsing Error: undefined entity
Location: http://localhost:8080/test_include.jsp
Line Number 1, Column 17:
  
^

I have the same error with a jsp:include markup.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Jk connector and security roles (was: DO NOT REPLY [Bug 16253] - Security roles in web.xml do not work with IIS)

[Ari Suutari]

Hi,

>
> Security roles in web.xml do not work with IIS

Btw, I guess that it is impossible to use roles
when one has apache as front end also.

> --- Additional Comments From [EMAIL PROTECTED]  2003-01-20 15:18 ---
> The idea was to use NT UserGroups as Roles, but never reached to
> conclusion, that is to read that Info gathered from Native-NT at Java Land
> ( they are transmited to tomcat over the wire but tomcat doenst get them
> from the AJP13 packet), and use them as roles...

I already wrote a Jk2Realm, which was supposed to check that
if request role is one of the groups transmitted from native side
(the groups are in
 HttpServletRequest.getAttribute("org.apache.tomcat.jk.roles"))
but then I noticed that servlet request is not available in Realm.hasRole.

So, maybe the right approach would be to add role information
into CoyotePrincipal and just check against that in my Jk2Realm ?

Also, to make my Jk2Realm to work I had to modify mbeans-descriptors.xml
under catalina - which didn't feel right because the Jk2Realm 
kind of belongs to jakarta-connectors, doesn't it ?

I'm willing to make this work but as you can see, I need some
ideas how to proceeed.

Ari Suutari / Syncron Tech Oy
Lappeenranta, Finland



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release()not invoked]

[Remy Maucherat]

Costin Manolache wrote:

Hans Bergsten wrote:



Costin Manolache wrote:


[...]
In an ideal world, all "core" tags would be recyclable and garbage-free -
that may allow them to run at comparable speed with a hard-coded page.


I think it's more important to implement "open coding" of JSTL, i.e.
generate if and for statement instead of using  and 
tag handlers. That would really make a difference for all apps that
use JSTL, while the potential gains from tag handler reuse depend on
a lot of factors that varies between applications and the runtime
environment.



+1 - "open coding" is far better ( for performance ). Is the API/model
for portable open coding defined and stable ? That would be by far the 
biggest improvement in JSP performance.

Kin-Man told me it wasn't done yet (he mentioned the curent methods 
should stay, though), unfortunately. From what he said, he needed to 
write more tag plugins to see if he was able to implement JSTL tags with 
the current API.
I agree it's definitely a good way to get around the problems with tags 
without adding too much complexity. In the end, I decided to talk about 
it a bit in a chapter of my book.
What's really funny is that you can get rid of the tag handler, and 
write only the tag plugin. That's of course, if you don't care about 
portability, and you have the tag plugin able to handle all forms of you 
tag.

But for people who use regular tag handlers - I think we need to fix
the tag pool, and a fixed tag pool will improve the performance 
significantly. And if regular tags are used, for whatever reason, 
recycling should be taken into account - if people care a bit
about performance.

+1.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Tomcat 5 target JDK1.4?

[Martin Algesten]

> In Java, the whole point is you can go switch out a VM, at a 
> drop of a hat.
> I mean, JDK 1.5 is coming out.

That's just moronic and plain wrong and if you truly believe that I'm
feeling sorry for you. If you'd had any experience running live servers
you'd know that changing API's _always_ have consequences. I'm worried
about even changing trivial things like upgrading minor versions of XML
parsers. To change the VM I rely on is a serious undertaking and
certainly not done at a drop of a hat.

> But if I am the only one asking, maybe I am drunk. The thing is go to 
> your IDE (IDEj) and flag target 1.4, do you see all the 
> import changes?

IDE? Flag target 1.4? That says it then.

The first thing I ask programmers I hire is "How do you prefer to
program? What is your environment like?" ... If the answer is along the
lines of "vi", "emacs", "notepad", "zsh", "bash", "windows command
line", then I feel much relieved...

Martin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

AW: Tag Pooling ( was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Torsten Fohrer]

on option, can it be minimize the synchronized calls, as a example.

1. Removing synchronized methods in TagPool
2. Adding a synchronize block on top of the jspService method, that get all
needed tag instances
3. normal using the instances
4. Adding a synchronize block in finally block to put back the tag instances

this can simply extended to support tagpool per unique tag/attribute
combination in the same context.


Torsten Fohrer

> -Ursprüngliche Nachricht-
> Von: Costin Manolache [mailto:[EMAIL PROTECTED]]
> Gesendet: Dienstag, 21. Januar 2003 01:08
> An: [EMAIL PROTECTED]
> Betreff: Tag Pooling ( was: Re: DO NOT REPLY [Bug 16001] - 
> Tag.release()
> not invoked
> 
> 
> Taking Glenn's post out of thread:
> 
> 
> Glenn Nielsen wrote:
> 
> > Per JSP Page (current)
> > --
> > 
> > The current tag pool manages one or more pools of tags on a per JSP
> > page basis. With a synchronized method call for each get/reuse pair
> > for a TagHandler used in the page. That page could have as 
> many current
> > requests as Processor threads.  The TagHandlerPool's for 
> the JSP page
> > could grow to the point where they have as many TagHandler elements
> > as needed to handle the maximum number of concurrent 
> requests (Threads).
> 
> If we're going to keep the current around - we should at 
> least increase
> the limit. 
> 
> 
> 
> > Per JSP Page Thread Local
> > -
> > 
> > Switching this to ThreadLocal would remove all need for synchronized
> > access for the TagHandlerPool get/reuse but significantly 
> increase the
> > memory usage. You end up with a TagHandlerPool for each 
> thread, for each
> > JSP page.
> > 
> > Both of these could require enoubh memory to hold the 
> number of TagHandler
> > classes = Number of Threads * Number of JSP pages * Number of unique
> > TagHandlers needed per JSP
> 
> A mechanism to clean up unused pools could help reduce this ( 
> similar with 
> ThreadPool ). ( maybe combined with some JMX to give insight 
> into how many 
> pools and tags are in used - quite usefull ).
> 
> This is the classical "memory versus time" - a choice that 
> users should make
> for themself, depending on the application they run. A 
> production site with 
> a lot of memory and very high traffic on few pages may choose 
> the speed.
> 
> 
> > There are two other options based on managing a global tag 
> pool rather
> > than
> > a per JSP page tag pool.  If you have many JSP pages with 
> custom tags
> > there
> > will be common tags/attributes used across all of them.  
> Why not be able
> > to reuse these TagHandler's across all the JSP pages 
> instead of on a per
> > JSP page basis. This could significantly reduce the number 
> of instances of
> > TagHandler's
> > which have to be pooled, and the memory the consume.  
> Consider the JSTL
> > c:if tag and how many times it could get used across 20 
> different JSP
> > pages.
> 
> If this is still thread local - I'm +0 ( i.e. I won't 
> implement it, but
> I think it's a great idea ).
> 
> That would make it ( threads * maxTag ), where maxTag is the 
> maximum number
> of one tag in any page. 
> 
> It shouldn't be hard - you'll need to pass the context and keep the
> ThreadLocal in the context.
> 
> Of course - keep in mind that you need one pool for each 
> tag+attribute_set
> ( another wise requirement..)
> 
> 
> > Global
> > --
> > 
> > TagHandlerPool's which are global and pool all unique 
> TagHandler classes
> > for all JSP pages. In this case you would require one 
> synchronized call at
> > the start of the JSP page to populate its local pool with reusable
> > TagHandler's from the global pool. Then on JSP page exit return the
> > TagHandler's from its local pool to the global. Requires 
> two synchronized
> > method calls per JSP page execution, but mimimizes the 
> memory footprint of
> > pooled tags.
> 
> If by global you mean cross-context - I don't think it would work ( 
> versioning, security, etc ).
> 
> 
> > 
> > Global Thread Local
> > ---
> > 
> > TagHandlerPool's which are global within a thread and pool 
> all unique
> > TagHandler classes for all JSP pages which execute within 
> the thread. No
> > synchronized methods
> > would be required for this design.  This would have a smaller memory
> > footprint than the Per JSP Page (current) and Per Jsp Page 
> Thread Local
> > tag pools, but use more memory than the Global tag pool.
> 
> Again - if by global you mean per context, +1. Per server is 
> too dangerous
> ( a thread can hold on the reference for a tag and access it 
> when it is 
> in used in a different context ).
> 
> 
> > Of the four designs above I think the Global Thread Local 
> design may be
> > the best. It removes the need for synchronized get/reuse 
> and has a smaller
> > memory footprint than the Per JSP Page tag pool design.
> 
> +1 for Context Thread Local ( eventually combined with some expiration
> strategy ).
> 
> 
> Costin
> 
> 
>