cvs commit: jakarta-tomcat-connectors/jk/xdocs style.xsl.in

[hgomez]

hgomez  2002/09/27 23:06:37

  Modified:jk/xdocs style.xsl.in
  Added:   jk/xdocs/images mod_jk.jpg
  Removed: jk/xdocs/images mod_jk.jpeg
  Log:
  Change from .jpeg to .jpg to avoid problem with misconfigured CVS
  clients which broke the .jpeg in at least TC 4.1.12 release tarball
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-connectors/jk/xdocs/images/mod_jk.jpg
  
<>
  
  
  1.14  +1 -1  jakarta-tomcat-connectors/jk/xdocs/style.xsl.in
  
  Index: style.xsl.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/style.xsl.in,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- style.xsl.in  26 Sep 2002 12:50:49 -  1.13
  +++ style.xsl.in  28 Sep 2002 06:06:37 -  1.14
  @@ -102,7 +102,7 @@
   
 
 
  -
  +
 
   
 
  
  
  

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

fault-tolerance

[Kirill Koulechov]

Hi,

i think i have a rather simple questions for the developers of tomcat. Let
me give short explanation.

I am working on a research topic, which is generic fault detection and
tolerance for software architectures. i've picked apache as a sample of
c/c++ program and tomcat as a java program. don't get me wrong: i did it
because i beleave that these programs are well known, and developed
professionaly, since i need fault statistics that are not obscured by simply
omitting basic rules of software development.

i studied the bug database for tomcat4 versions 4.0.x Final, with the
assumption that these have been (fairly) stable versions. i omitted NEW and
UNCONFIRMED bugs, as well as INVALID, WONTFIX, DUPLICATE, WORKSFORME.
besides that, i ignored some IMHO rare plattforms like BeOS, OS/2, Netware,
OS/400 and included only critical, major and normal bugs.

i did that in the hope to get representative statistics about common
software faults in a big, professionaly developed software product. if i did
something wrong, please correct me. at the end i got 163 bugs.

now the important stuff.

after examining some of them, i noticed some amount of bugs (i.e. bugs
#4930, #4047) causing unchecked exceptions, which strike all the way through
the stack, ending in org.apache.catalina.connector.http.HttpProcessor.run()
and then in java.lang.Thread.run(). in my understanding, this stops the
affected thread and all functionality that was done by
org.apache.catalina.connector.http.HttpProcessor.run() is unavailable now.
what is tomcats reaction to this? does the program crash/freeze/hang
whatever, or do these exceptions not affect the runime behaviour? or is only
the active servlet affected? besides that, i wondered what are the effects
of the bugs 3817, 4542, 5201, since the provided stack doesn't go up to
java.lang.Thread.run().


thank you very much in advance,

i really appreciate your answers because it doesnt help you developing
tomcat in the first place, but just think that you are helping to research
ways to prevent software from crashing at all!

Kirill Koulechov


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

Re: DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails

[Glenn Nielsen]

I know that jikes on unix has support for the -encoding arg.
I built it from source on Solaris.

When I did the build jikes there were dependences for libs (dll)
which supported unicode and internationalizaiton.  Without these
the version of jikes built did not support encodeing.

I don't know where you would get a windows version with support for -encoding.

Regards,

Glenn

Sean Reilly wrote:
> Just out of curiosity, where would you obtain such a version?
> 
> I tried jikes 1.16 (win32) from IBM.
> AFAIK this is the current version of jikes, and also the first version that supports 
>assertions (-source 1.4).
> It doesn't list the -encoding option.  Is -encoding a standard option for jikes?
> 
> Sean Reilly
> Programmer, Point2 Technologies, Inc.
> (306) 955-1855
> [EMAIL PROTECTED]
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 27, 2002 4:33 PM
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails
> 
> (snip)
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13084
> 
> jsp compilation with jikes fails
> 
> [EMAIL PROTECTED] changed:
> 
>What|Removed |Added
> 
>  Status|NEW |RESOLVED
>  Resolution||INVALID
> 
> 
> 
> --- Additional Comments From [EMAIL PROTECTED]  2002-09-27 22:33 ---
> You need a version of jikes with support for encoding.
> 
> If you execute the jikes compiler from a shell with -help and don't
> see the option "-encoding" then jikes isn't built with support for
> encoding.
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail:  




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

DO NOT REPLY [Bug 13107] New: - Wrong handling of <% // some comment %>

[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=13107

Wrong handling of <% // some comment %>

   Summary: Wrong handling of <% // some comment %>
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


After upgrading from 4.0.4 (cute version number for a webserver anyway :) I 
faced a compilation problem with the following code:

<% // some comment %>...

The source generated looks like:

 // some comment  if (_jspx_meth_own_mytag_2(pageContext))

which is wrong. As said before, this worked in 4.0.4.
Rewriting the comment to /* some comment */ works, too.

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

DO NOT REPLY [Bug 13058] - Dynamic Attributes do not take in RT expressions

[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=13058

Dynamic Attributes do not take in RT expressions

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

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

[kinman]

kinman  2002/09/27 17:46:28

  Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
  Log:
  - Fix 13058: Dynamic attributes specified in  body do not
take RT expressions.
  
  Revision  ChangesPath
  1.32  +8 -5  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- Parser.java   12 Sep 2002 21:57:00 -  1.31
  +++ Parser.java   28 Sep 2002 00:46:28 -  1.32
  @@ -1715,8 +1715,8 @@
   private String getAttributeBodyType(Node n, String name) {
   
if (n instanceof Node.CustomTag) {
  - TagAttributeInfo[] tldAttrs =
  - ((Node.CustomTag)n).getTagInfo().getAttributes();
  + TagInfo tagInfo = ((Node.CustomTag)n).getTagInfo();
  + TagAttributeInfo[] tldAttrs = tagInfo.getAttributes();
for (int i=0; imailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

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

[glenn]

glenn   2002/09/27 17:35:03

  Modified:xdocsbugreport.xml
  Log:
  Add info on how to report a security bug
  
  Revision  ChangesPath
  1.3   +5 -0  jakarta-tomcat-site/xdocs/bugreport.xml
  
  Index: bugreport.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/xdocs/bugreport.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- bugreport.xml 11 Apr 2002 01:47:29 -  1.2
  +++ bugreport.xml 28 Sep 2002 00:35:03 -  1.3
  @@ -15,6 +15,11 @@
   who assist on a day to day basis resolving bug reports do this for a
   wide variety of reasons, and almost all of them do this on their own time.
   
  +If you have a verified security bug to report please do not post it
  +to email lists or submit a bug report.  Security bugs should be reported
  +privately by email to mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED].
  +
  +
   Many bugs reported end up not being a bug in the Tomcat code, but are
   due to misconfiguration, problems caused by installed applications, the
   operating system, etc.
  
  
  

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

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

[glenn]

glenn   2002/09/27 17:24:31

  Modified:webapps/tomcat-docs jasper-howto.xml
  Log:
  Update docs for jikes
  
  Revision  ChangesPath
  1.3   +3 -1  jakarta-tomcat-4.0/webapps/tomcat-docs/jasper-howto.xml
  
  Index: jasper-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/jasper-howto.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- jasper-howto.xml  13 Sep 2002 11:51:30 -  1.2
  +++ jasper-howto.xml  28 Sep 2002 00:24:31 -  1.3
  @@ -166,7 +166,9 @@
   http://oss.software.ibm.com/developerworks/opensource/jikes/";>
   Jikes to compile JSP pages:
   
  -Download and install jikes.
  +Download and install jikes. jikes must support the -encoding option.
  +Execute jikes -help to verify that it was built with support
  +for -encoding.
   Set the init parameter compiler to jikes.
   Define the property -Dbuild.compiler.emacs=true when starting
   Tomcat by adding it to your CATALINA_OPTS environment variable.
  
  
  

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

DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace

[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=9931

Base64 decoder chokes on a whitespace

[EMAIL PROTECTED] changed:

   What|Removed |Added

URL||http://cvs.apache.org/viewcv
   ||s/xml-
   ||rpc/src/test/org/apache/xmlr
   ||pc/Base64Test.java?rev=1&con
   ||tent-type=text/vnd.viewcvs-
   ||markup



--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 23:43 ---
Hmm.  I just wrote a very simple test case for the Base64 implementation which
Jon nabbed from Tomcat (I found the attached one a bit too abstract to follow
easily).  I was unable to reproduce the failure, even by appending whitespace to
the end of the line (you can try it out yourself with `ant test`):



Vjekoslav, can you tell me what the correct method of handling whitespace in
base64-encoded data is?  The closest thing that I found to a RFC on that is
 -- it recommends
stripping trailing whitespace.  Is this what Apache's implementation should be
doing?  Or should it collapse all lines of base64-encoded data together, then
decode that?

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

Tired...

[Pier Fumagalli]

Since I'm tired of you lot, I'm going to say goodbye and retire in lala-land
... Have fun and try not to hit
bugtrack too often! :-)

Pier


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

Re: Cannot Build WebApp on Solaris 2.8

[Pier Fumagalli]

On 27/9/02 0:22, "Jay Ebert" <[EMAIL PROTECTED]> wrote:

> I followed the "Building the WebApp module" exactly and cannot build the
> webapp module for Solaris 2.8 using gcc 2.95. After a successful
> ./configure ... , I get the following errors on the make:

Use mod_jk


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

RE: DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails

[Sean Reilly]

Just out of curiosity, where would you obtain such a version?

I tried jikes 1.16 (win32) from IBM.
AFAIK this is the current version of jikes, and also the first version that supports 
assertions (-source 1.4).
It doesn't list the -encoding option.  Is -encoding a standard option for jikes?

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


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 27, 2002 4:33 PM
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails

(snip)

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

jsp compilation with jikes fails

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 22:33 ---
You need a version of jikes with support for encoding.

If you execute the jikes compiler from a shell with -help and don't
see the option "-encoding" then jikes isn't built with support for
encoding.


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

DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails

[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=13084

jsp compilation with jikes fails

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails

[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=13084

jsp compilation with jikes fails

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 22:33 ---
You need a version of jikes with support for encoding.

If you execute the jikes compiler from a shell with -help and don't
see the option "-encoding" then jikes isn't built with support for
encoding.

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

[patch] JNDIRealm and SSL

[Fredrik Westermarck]

Hi!

I have added the possibility to use SSL with the JNDIRealm in the file 
JNDIRealm.java.diff.

This patch allows two more parameters to be set for the JNDIRealm. If they are 
not explicitly set the JNDIRealm will behave in the same way as before.

I tried to document the changes (or additions) for the configuration in the 
realm.xml.diff.

O, as a bonus I did remove some unused imports and a fixed a typo in the 
javadoc in JNDRealm.

Regards,
Fredrik Westermarck


JNDIRealm.java.diff
Description: Binary data


realm.xml.diff
Description: Binary data

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

DO NOT REPLY [Bug 13068] - Use of validationQuery parameter by BasicDataSourceFactory implementation

[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=13068

Use of validationQuery parameter by BasicDataSourceFactory implementation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

DO NOT REPLY [Bug 13068] - Use of validationQuery parameter by BasicDataSourceFactory implementation

[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=13068

Use of validationQuery parameter by BasicDataSourceFactory implementation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 22:25 ---
The validationQuery is used by the PoolableConectionFactory.validateObject()
method in the code from CVS for the DBCP 1.0 release.

Make sure you have the 1.0 release.

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

DO NOT REPLY [Bug 13052] - SecurityManager + req.getParameter() = "ParameterMap" class loading NoClassDefFoundError exception

[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=13052

SecurityManager + req.getParameter() = "ParameterMap" class loading 
NoClassDefFoundError exception

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

DO NOT REPLY [Bug 13052] - SecurityManager + req.getParameter() = "ParameterMap" class loading NoClassDefFoundError exception

[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=13052

SecurityManager + req.getParameter() = "ParameterMap" class loading 
NoClassDefFoundError exception

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 22:19 ---
As I stated in the other bugzilla report, there is nothing in
org.apache.catalina.util.* that is security sensitive.

Fix your policy so that the correct defineClassInPackage Runitme permission is 
granted.

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

DO NOT REPLY [Bug 13000] - tag file handler generation with complex attributes

[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=13000

tag file handler generation with complex attributes

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Major   |Critical

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

Ping: sources for jsp2el.jar !

[Costin Manolache]

It seems Justyna was the last person to access the file, and Remy 
was the first.

If anyone knows where are the sources for that jar - please let me know. 
( or just check them in ).


-- 
Costin



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

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

[luehe]

luehe   2002/09/27 13:18:32

  Modified:jasper2/src/share/org/apache/jasper/compiler
TagFileProcessor.java TagLibraryInfoImpl.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties messages_ja.properties
  Log:
  Let parse exception from packaged tag files propagate up
  
  Revision  ChangesPath
  1.28  +4 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java
  
  Index: TagFileProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- TagFileProcessor.java 12 Sep 2002 20:48:17 -  1.27
  +++ TagFileProcessor.java 27 Sep 2002 20:18:31 -  1.28
  @@ -193,13 +193,13 @@
   // type is fixed to "JspFragment" and a translation error
   // must occur if specified.
   if (type != null) {
  -err.jspError("jsp.error.fragmentwithtype");
  +err.jspError(n, "jsp.error.fragmentwithtype");
   }
   // rtexprvalue is fixed to "true" and a translation error
   // must occur if specified.
   rtexprvalue = true;
   if( rtexprvalueString != null ) {
  -err.jspError("jsp.error.frgmentwithrtexprvalue" );
  +err.jspError(n, "jsp.error.frgmentwithrtexprvalue" );
   }
   } else {
   if (type == null)
  
  
  
  1.15  +4 -7  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
  
  Index: TagLibraryInfoImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- TagLibraryInfoImpl.java   28 Aug 2002 23:00:19 -  1.14
  +++ TagLibraryInfoImpl.java   27 Sep 2002 20:18:32 -  1.15
  @@ -226,10 +226,6 @@
// it to release the cached entry, so
// there's no way to redeploy from the same JAR file.  Wierd.
} catch (Exception ex) {
  - Constants.message(
  -"jsp.error.taglib.jarFileException",
  - new Object[] {url.toString(), ex.getMessage()},
  - Logger.ERROR);
if (stream != null) {
try {
stream.close();
  @@ -240,6 +236,7 @@
jarFile.close();
} catch (Throwable t) {}
}
  + throw new JasperException(ex);
}
}
   }
  
  
  
  1.43  +1 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
  
  Index: messages.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
  retrieving revision 1.42
  retrieving revision 1.43
  diff -u -r1.42 -r1.43
  --- messages.properties   24 Sep 2002 21:24:58 -  1.42
  +++ messages.properties   27 Sep 2002 20:18:32 -  1.43
  @@ -253,7 +253,6 @@
   #jspx.error.templateDataNotInJspCdata=Validation Error: Element <{0}> cannot 
have template data. Template data must be encapsulated within a  
element. [JSP1.2 PFD section 5.1.9]\nTemplate data in error: {1}
   jspx.error.templateDataNotInJspCdata=Validation Error: Element <{0}> cannot 
have template data. Template data must be encapsulated within a  
element. [JSP1.2 PFD section 5.1.9]\nTemplate data in error: {1}
   #Error while processing taglib jar file {0}: {1}
  -jsp.error.taglib.jarFileException=
   jsp.error.taglib.reserved.prefix=The taglib prefix {0} is reserved
   jsp.error.invalid.javaEncoding=Invalid java encodings. Tried {0} and then {1}. Both 
failed.
   jsp.error.needAlternateJavaEncoding=Default java encoding {0} is invalid on your 
java platform. An alternate can be specified via the 'javaEncoding' parameter of 
JspServlet.
  
  
  
  1.14  +1 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_ja.properties
  
  Index: messages_ja.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_ja.properties,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- messages_ja.properties24 Sep 2002 21:24:58 -  1.13
  +++ messages_ja.properties27 Sep 2002 20:18:32 -

DO NOT REPLY [Bug 13097] New: - org.apache.catalina.startup.Embedded.createConnector sets incorrect address

[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=13097

org.apache.catalina.startup.Embedded.createConnector sets incorrect address

   Summary: org.apache.catalina.startup.Embedded.createConnector
sets incorrect address
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


For applications which embed Tomcat using the Embedded class, the
createConnector which worked previously (I last used it with Tomcat 4.0.1) now
results in the following error: "IntrospectionUtils: Unable to resolve host
name:localhost/127.0.0.1".  
Upon examination of the code in Embedded, I find that the String value it is
passing on the setProperty("address"...) method is incorrect.  It is using an
implied toString method of an InetAddress object where it should be using the
getHostName method.

Eventually, an IntrospectionUtils setProperty for the underlying
org.apache.coyote.http11.Http11Protocol object tries to reconstruct an
InetAddress object using the value as a hostname.  In the above example,
"localhost/127.0.0.1" is not a valid hostname, though "localhost" is.

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

DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid  in servlet mapping

[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=13014

OS/390/USS - Invalid   in servlet mapping





--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 19:25 ---
I replaced the XML parser with xercesImpl.jar from Xerces-Java 2.1.0.
The problem remains.

I installed v331 of tomcat today and it works after with the following files
in EBCDIC :
conf/tomcat.policy
conf/jserv/tomcat.conf
conf/jserv/tomcat.property

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

[PATCH] 4.1.12 catalina.sh for cygwin

[Peter Romianowski]

After 2 days of messing around with TC 4.1.12 on cygwin, I realized
that the catalina.sh is broken. It does not convert the $CATALINE_TMPDIR
environment-variable to a cygwin-path. This lead to these
javax.servlet.ServletException: Exception processing JAR at resource
path /WEB-INF/lib/
exception, which lead me into the complete wrong direction :-)

Here's a patch for that (against the 4.1.12 RELEASE)

--- catalina_orig.sh2002-09-23 11:23:00.0 +0200
+++ catalina.sh 2002-09-27 20:38:36.0 +0200
@@ -101,6 +101,7 @@
   CATALINA_HOME=`cygpath --path --windows "$CATALINA_HOME"`
   CATALINA_BASE=`cygpath --path --windows "$CATALINA_BASE"`
   CLASSPATH=`cygpath --path --windows "$CLASSPATH"`
+  CATALINA_TMPDIR=`cygpath --path --windows "$CATALINA_TMPDIR"`
   JSSE_HOME=`cygpath --path --windows "$JSSE_HOME"`
 fi

I hope I did it the right way.

Peter


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

DO NOT REPLY [Bug 12978] - Tomcat doesn't pick up error pages.

[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=12978

Tomcat doesn't pick up error pages.





--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 18:47 ---
Created an attachment (id=3272)
o.a.c.v.ErrorDispatcherValve even newer.. one of those days

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

DO NOT REPLY [Bug 12978] - Tomcat doesn't pick up error pages.

[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=12978

Tomcat doesn't pick up error pages.





--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 18:44 ---
The second patch conforms to the spec.. the first still did things backwords..


The web application may have declared error pages using the exception-type
element. In this case the container matches the exception type by comparing the
exception thrown with the list of error-page definitions that use the 
exceptiontype element. A match results in the container returning the resource 
indicated in the location entry. The closest match in the class heirarchy wins.

If no error-page declaration containing an exception-type fits using the
class-heirarchy match, and the exception thrown is a ServletException or
subclass thereof, the container extracts the wrapped exception, as defined by 
the ServletException.getRootCause method. A second pass is made over the error
page declarations, again attempting the match against the error page 
declarations, but using the wrapped exception instead.


as you can see it needs to check for the ServletException first, and if a page 
is not found for them then it needs to check the root cause..

or atleast that is how I read it..

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

DO NOT REPLY [Bug 12978] - Tomcat doesn't pick up error pages.

[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=12978

Tomcat doesn't pick up error pages.





--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 18:42 ---
Created an attachment (id=3271)
o.a.c.v.ErrorDispatcherValve newer patch

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

Re: cvs and 4.1

[Amy Roh]

micael wrote:

> Amy, I am using jCVS.  When I export and want to specify a tag, how is that
> done?  I am asking for later.  Do I do something in the arguments text box?

I don't use jCVS so I don't know how.  There should usually an option when you do
checkout to specify a tag.  You should refer to jCVS documentation.

Amy

>
>
> At 01:52 PM 9/26/2002 -0700, you wrote:
> >micael wrote:
> >
> > > If I cvs to tomcat-4.0, am I going to get the latest of 4.1?
> >
> >Yes.  If you checkout jakarta-tomcat-4.0 with no tag specified, you'll get the
> >latest HEAD of 4.1.
> >
> > > If not, how
> > > do I pick the branches off tomcat-4.0?
> >
> >You can use different tags to get certain releases of tomcat from cvs.  For
> >example, you'd use TOMCAT_4_1_12 tag to get the recent 4.1.12 release.
> >
> >Amy
> >
> > >
> > >
> > > Micael
> > >
> > > ---
> > >
> > > This electronic mail  transmission and any accompanying documents contain
> > > information belonging to the sender which may be confidential and legally
> > > privileged.  This information is intended only for the use of the
> > > individual or entity to whom this electronic mail transmission was sent as
> > > indicated above. If you are not the intended recipient, any dislosure,
> > > copying, distribution, or action taken in reliance on the contents of the
> > > information contained in this transmission is strictly prohibited.  If you
> > > have received this transmission in error, please delete the
> > message.  Thank you
> > >
> > > --
> > > To unsubscribe,
> > e-mail:   
> > > For additional commands, e-mail:
> > 
> >
> >
> >--
> >To unsubscribe, e-mail:   
> >For additional commands, e-mail: 
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 


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

DO NOT REPLY [Bug 12978] - Tomcat doesn't pick up error pages.

[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=12978

Tomcat doesn't pick up error pages.





--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 18:33 ---
This patch should fix your problems.

the valve was never handling ServletException when looking for errorpages.

see SRV.9.9.2

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

JK2 2.0.0 Released as Beta

[Mladen Turk]

This is the first Beta relese of JK2

The JK2 should be considered initial-release quality code.  
It has not been subjected to the same stresses on its stability and 
security that the mod_jk releases have enjoyed, so there is a greater 
possibility of undiscovered vulnerabilities to stability or security.


The newest JK2 is a rewrite of JK . The native part has been completly
restructured and the configuration has been simplified a lot.
Even if it works with Apache 1.3, JK2 has been developed with Apache 2.0
in mind,
and thus is better suited for multi-threaded servers like IIS,
NES/iPlanet.

JK2 has a better separation between protocol and physical layer.
As such JK2 support fast unix-socket, and could be extended to support
others communications
channels. Better it's suited for JNI and JDK 1.4 fast IO APIs

You can find the sources and binaries at

http://cvs.apache.org/~mturk/jk2

MT.


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

DO NOT REPLY [Bug 12978] - Tomcat doesn't pick up error pages.

[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=12978

Tomcat doesn't pick up error pages.





--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 18:30 ---
Created an attachment (id=3270)
o.a.c.v.ErrorDispatcherValve patch

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

DO NOT REPLY [Bug 13094] - Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable).

[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=13094

Compliance Issue - NPE not thrown if a null reference is passed to 
PageContext.handlePageException(Exception) or 
PageContext.handlePageException(Throwable).





--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 18:25 ---
*** Bug 13093 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 13093] - Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable).

[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=13093

Compliance Issue - NPE not thrown if a null reference is passed to 
PageContext.handlePageException(Exception) or 
PageContext.handlePageException(Throwable).

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 18:25 ---


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

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

DO NOT REPLY [Bug 13094] New: - Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable).

[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=13094

Compliance Issue - NPE not thrown if a null reference is passed to 
PageContext.handlePageException(Exception) or 
PageContext.handlePageException(Throwable).

   Summary: Compliance Issue - NPE not thrown if a null reference is
passed to PageContext.handlePageException(Exception) or
PageContext.handlePageException(Throwable).
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Javadocs for PageContext.handlePageException(Exception) and 
PageContext.handlePageException(Throwable) clearly state that
a NullPointerException is to be thrown if a null reference is passed
to these methods.

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

DO NOT REPLY [Bug 13093] New: - Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable).

[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=13093

Compliance Issue - NPE not thrown if a null reference is passed to 
PageContext.handlePageException(Exception) or 
PageContext.handlePageException(Throwable).

   Summary: Compliance Issue - NPE not thrown if a null reference is
passed to PageContext.handlePageException(Exception) or
PageContext.handlePageException(Throwable).
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Javadocs for PageContext.handlePageException(Exception) and 
PageContext.handlePageException(Throwable) clearly state that
a NullPointerException is to be thrown if a null reference is passed
to these methods.

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

Could we improve on the connector (mod_jk) for ajp13?

[Han Ming Ong]

Hi tomcat developers,

I have had the chance to play with Tomcat 3 (TC3) and 4 (TC4) 
recently. I discovered a performance bottleneck that is quite small and 
should be non-obvious in a WAN. Nonetheless, I would like to raise this 
up and see if you folks have talked about this before (I only saw a 
couple of postings about this on the dev archive). If it is indeed 
something that can be improved, I can volunteer a patch.

Summary: We have a very simple JSP app that is deployed on TC3, 
integrating with Apache, using either ajp12 or ajp13 protocol. When 
used with ajp13, we realized that the classic interaction between Nagle 
algorithm (on the TC3 side) and delayed ack (on the Apache side) 
results in 200ms delay per request-response loop on the Mac OS X 
platform.

Detailed description:

1. The connector that we used is mod_jk, which is capable of ajp12 or 
ajp13.

2. When we use ajp12, the entire request-response loop takes about 1ms 
on a LAN. Using tcpdump on the traffic shows no obvious slow down. This 
is good.

3. Using the same hardware/software setup but just switching to the 
ajp13 protocol, each request-response is about 200ms. Mac OS X  10.2 
(darwin), by default, turns on Nagle and set the delayed ack to be 
200ms. So, intuitively, we know that it's probably due to that.

4. Indeed, analyzing the protocol at 
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13.html 
and the tcp dump confirms this. Experimentally, if I either turn off 
Nagle on the TC3 side or turn off delayed ack on the Apache, then 
performance is as good as ajp12.

5. So there are 2 potentially simple fix:
a. We could turn off delayed ack on the Apache side but on darwin, 
there is no such socket level option. Hence, it will affect the entire 
machine.
b. Turn off Nagle on the TC3 side, for ajp13. Analysis of the protocol 
shows that ajp13 first sends Headers (small load) back to Apache, 
followed by Body Chunk (big load) and then an End Response (small 
load). And for some reason, the Body Chunk is divided into chunks of 
1032. I'll have to read the codes to understand why so.

Conclusion: before I spend more effort into a solution , I would like 
to know if you developers has already a solution (but has not been 
committed since I didn't see it in TC4 yet) so that I don't duplicate 
effort. Is this something worth pursuing?

Thanks much!!

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi isapi.dsp

[mturk]

mturk   2002/09/27 10:59:53

  Modified:jk/native2/server/isapi isapi.dsp
  Log:
  Fix the DLL Stactic MT Debug bild
  
  Revision  ChangesPath
  1.20  +1 -1  jakarta-tomcat-connectors/jk/native2/server/isapi/isapi.dsp
  
  Index: isapi.dsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/isapi.dsp,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- isapi.dsp 25 Sep 2002 07:37:54 -  1.19
  +++ isapi.dsp 27 Sep 2002 17:59:53 -  1.20
  @@ -99,7 +99,7 @@
   # PROP Ignore_Export_Lib 0
   # PROP Target_Dir ""
   # ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I "..\..\include" /I 
"$(JAVA_HOME)\include" /I "$(JAVA_HOME)\include\win32" /I "$(APACHE2_HOME)\include" /I 
"$(APACHE2_HOME)\os\win32" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D 
"_USRDLL" /D "ISAPI_EXPORTS" /D "HAVE_JNI" /D "HAS_APR" /FR /YX /FD /GZ /c
  -# ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I "..\..\include" /I 
"$(JAVA_HOME)\include" /I "$(JAVA_HOME)\include\win32" /I "$(APACHE2_HOME)\include" /I 
"$(APACHE2_HOME)\os\win32" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D 
"_USRDLL" /D "ISAPI_EXPORTS" /D "HAVE_JNI" /D "HAS_APR" /D "APR_DECLARE_STATIC" /D 
"APU_DECLARE_STATIC" /FR /YX /FD /GZ /c
  +# ADD CPP /nologo /MDd /W3 /Gm /GX /ZI /Od /I "..\..\include" /I 
"$(JAVA_HOME)\include" /I "$(JAVA_HOME)\include\win32" /I "$(APACHE2_HOME)\include" /I 
"$(APACHE2_HOME)\os\win32" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D 
"_USRDLL" /D "ISAPI_EXPORTS" /D "HAVE_JNI" /D "HAS_APR" /D "APR_DECLARE_STATIC" /D 
"APU_DECLARE_STATIC" /FR /YX /FD /GZ /c
   # ADD BASE MTL /nologo /D "_DEBUG" /mktyplib203 /win32
   # ADD MTL /nologo /D "_DEBUG" /mktyplib203 /win32
   # ADD BASE RSC /l 0x409 /d "_DEBUG"
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache13 jk_service_apache13.c

[mturk]

mturk   2002/09/27 10:49:01

  Modified:jk/native2/server/apache13 jk_service_apache13.c
  Log:
  Fix the compile warning.
  
  Revision  ChangesPath
  1.8   +1 -1  
jakarta-tomcat-connectors/jk/native2/server/apache13/jk_service_apache13.c
  
  Index: jk_service_apache13.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/jk_service_apache13.c,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- jk_service_apache13.c 20 Jun 2002 16:16:00 -  1.7
  +++ jk_service_apache13.c 27 Sep 2002 17:49:01 -  1.8
  @@ -207,7 +207,7 @@
   #endif
   
   static int JK_METHOD jk2_service_apache13_write(jk_env_t *env, jk_ws_service_t *s,
  -const void *b, int len)
  +const void *b, unsigned int len)
   {
   int rc;
   
  
  
  

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

DO NOT REPLY [Bug 13089] New: - Coyote sources are missing from the source zip for Tomcat 4.1.12

[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=13089

Coyote sources are missing from the source zip for Tomcat 4.1.12

   Summary: Coyote sources are missing from the source zip for
Tomcat 4.1.12
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The summary says it all.

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

DO NOT REPLY [Bug 13085] New: - Compliance issue. HttpServletResponse.sendError(int, String) doesn't behave per the specification.

[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=13085

Compliance issue.  HttpServletResponse.sendError(int, String) doesn't behave per the 
specification.

   Summary: Compliance issue.  HttpServletResponse.sendError(int,
String) doesn't behave per the specification.
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Calling HttpServletResponse.sendError(int, String) causes the string message to
be used as the HTTP reason-phrase in the status line.

According to the 2.4 spec, the String argument should be present in the response
body:



Sends an error response to the client using the specified status clearing the
buffer. The server defaults to creating the response to look like an
HTML-formatted server error page containing the specified message, setting the
content type to "text/html", leaving cookies and other headers unmodified. If an
error-page declaration has been made for the web application corresponding to
the status code passed in, it will be served back in preference to the suggested
msg parameter.



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

Re: [ANNOUNCEMENT]: JK 1.2.0 is now available

[Henri Gomez]

Henri Gomez wrote:
> Marx, Mitchell E (Mitch), ALCNS wrote:
> 
>> Where is Solaris 8, Apache 1.3?
> 
> 
> to be released, but contributions are welcomed ;-)

Just uploaded by JF Clere.




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

DO NOT REPLY [Bug 13084] New: - jsp compilation with jikes fails

[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=13084

jsp compilation with jikes fails

   Summary: jsp compilation with jikes fails
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
   URL: http://www.morgenstern.net/
OS/Version: Windows XP
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I've configured tomcat to use jikes (ver. 1.16 = latest) with 

jsp
org.apache.jasper.servlet.JspServlet

logVerbosityLevel
WARNING


compiler
jikes

3

as suggested in the docs.

When I run a webapp and try to compile a jsp I get the following error:
org.apache.jasper.JasperException: Unable to compile class for JSP

An error occurred at line: -1 in the jsp file: null

Generated servlet error:
[javac] Compiling 1 source file
[javac] use: jikes [options] [@files] file.java...
[javac] For more help, try -help or -version.
[javac] Error: The option "-encoding" is unsupported in this build.



at
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:120)
at 
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:293)
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:313)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:324)
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:289)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:432)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:356)
at de.uni_tuebingen.prometheus.vl.VlController.doPost(VlController.java:56)
at de.uni_tuebingen.prometheus.vl.VlController.doGet(VlController.java:64)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
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.invokeNext(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.invokeNext(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.StandardContext.invoke(StandardContext.java:2396)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(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.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java

DO NOT REPLY [Bug 11891] - JspC does not work for webapps

[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=11891

JspC does not work for webapps





--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 15:40 ---
Hi,

I analyzed the problem with jspc and jsp pages in a directory structure.

These are the problems based on the Tomcat 4.1.12 version:

1. the directory structure is copied to place the generated Java files into it. 
But there's a problem with the package names. What are you doing if there's a 
directory or sub-directory with a not legal Java package name, e.g. 'static' or 
'public' etc. so that e.g. a directory name would be /static/public/infopages. 
This should be converted into e.g. '_static/_public/_infopages'.

2. The generated Java file has always the same package (the first line in the 
Java source file). That's by default org.apache.jsp. It should be the converted 
directory structure to a legal package name: for the example above it should be: 
'package _static._public._infopages;'

3. Probably there are also restrictions for a Java class name. Probably some 
characters are not allowd in the class name but are legal for jsp names. These 
should be escaped.

4. The servlet mappings file generator should use all the above used techniques 
to generate a correct mapping. For the above example it should be (with the page 
Test.jsp):


  _static__public__infopages_Test_jsp
  _static._public._infopages.Test_jsp



 _static__public__infopages_Test_jsp
 /static/public/infopages/Test.jsp


I hope these comments are useful for a correct implementation of the JspC for 
larger web applications with a rich directory structure and jsp names.

With Regards,
Udo Walker

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

Status of tomcat (up/down)

[Eugene Gluzberg]

I am running multiple tomcat instances on one server (user TOMCAT_BASE
setup). I need to know whether a particular tomcat instance is up or
down for monitoring purposes.

The tomcats I am running only have the shutdown port and ajp13 port bound.

Is a socket connection without a command to the shutdown port enough? Is
there any way to connect to the ajp13 port and do a dummy request? Is
there a java api for client side ajp13 to help with this?

Any help would be appreciated,

Eugene




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

Re: [ANNOUNCEMENT]: JK 1.2.0 is now available

[Henri Gomez]

Marx, Mitchell E (Mitch), ALCNS wrote:
> Where is Solaris 8, Apache 1.3?

to be released, but contributions are welcomed ;-)



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

Re: [ANNOUNCEMENT]: JK 1.2.0 is now available

[jean-frederic clere]

Marx, Mitchell E (Mitch), ALCNS wrote:
> Where is Solaris 8, Apache 1.3?

In preparation...

> 
> Mitchell Evan Marx[EMAIL PROTECTED]
> AT&T IP Network Configuration & Provisioning Development
> 
> 
> -Original Message-
> From: Henri Gomez [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 27, 2002 11:03 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: [ANNOUNCEMENT]: JK 1.2.0 is now available
> 
> 
> Hi all,
> 
> The Jakarta-Tomcat-Connector team is pleased to announce the 
> availability of JK 1.2.0.
> 
> JK, also known as mod_jk, is a Tomcat / WebServers plug-in that handles 
> the communication between Tomcat and webservers.
> 
> Currently Apache 1.3.x and 2.0.x, IIS, Netscape/iPlanet are supported.
> 
> binaries and source versions of the release are available and can be 
> downloaded from :
> 
> http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1
> .2.0/
> 
> Binaries allready available are :
> 
> - Linux i386 (Apache 1.3/2.0.42)
> - Solaris 8 (Apache 1.3/2.0.39/2.0.42)
> - Win32 (IIS/Apache 1.3/2.0.42)
> 
> MacOS X, AIX, iSeries binaries to be released shortly (I hope)
> 
> Feel free to contact us to provide binaries for your own operating
> system.
> 
> Enjoy!
> 
> 
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 




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

WebApp module for Apache 1.3

[Jay Ebert]

I'm unable to build the WebApp module for Apache 1.3 on Solaris 2.8.
Where can I get the answer for this (?) :

 

build/ltconfig: build/ltconfig: cannot open

configure: error: libtool configure failed

APR configure: checking for minix/config.h... no

APR configure: checking whether system uses EBCDIC... no

APR configure: performing libtool configuration...

APR configure: checking for non-GNU ld... /usr/ccs/bin/ld

APR configure: checking if the linker (/usr/ccs/bin/ld) is GNU ld...
no

APR configure: checking for BSD-compatible nm... /usr/ccs/bin/nm -p

  Execution of ./configure --enable-static --disable-shared
--disable-threads returned 1

configure: error: APR configure script terminated with error code 1

 

 

 

Cannot Build WebApp on Solaris 2.8

[Jay Ebert]

I followed the "Building the WebApp module" exactly and cannot build the
webapp module for Solaris 2.8 using gcc 2.95. After a successful
./configure ... , I get the following errors on the make:

 

wcarweb1:/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40 #
make

 

make[1]: Entering directory "lib"

make[1]: Invoking "make  build"

/opt/sfw/bin//gcc -g -O2-DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS
-D_REENTRANT
-I/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/includ
e -I/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/include
-c "wa_main.c" -o "wa_main.o"

In file included from
/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/
apr_general.h:61,

 from
/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/include/wa.h
:77,

 from wa_main.c:59:

/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/
apr.h:198: #error Can not determine the proper size for apr_int64_t

/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/
apr.h:253: #error Can not determine the proper size for ssize_t

/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/
apr.h:256: #error Can not determine the proper size for size_t

/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/
apr.h:265: #error Can not determine the proper size for apr_int64_t

*** Error code 1

make: Fatal error: Command failed for target `wa_main.o'

Current working directory
/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/lib

*** Error code 1

make: Fatal error: Command failed for target `template'

Current working directory
/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40

*** Error code 1

make: Fatal error: Command failed for target `lib-build'

Problem running Jakarta-tomcat

[kothapally subbaraju]

Hi,

I have installed Jakarta-tomcat 4.0.5 and
J2sdk1.4.0-02.
When i started Jakarta-tomcat first it was giving the
error that port no:8080 is already in use.

later i changed the port no: to 1977, then it is
giving : Error creating server
socket(java.net.BindException), Address already in
use.

How to solve this error

i am waiting for your reply

thanking you

kvs raju
([EMAIL PROTECTED])

__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

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

RE: [ANNOUNCEMENT]: JK 1.2.0 is now available

[Marx, Mitchell E (Mitch), ALCNS]

Where is Solaris 8, Apache 1.3?

Mitchell Evan Marx[EMAIL PROTECTED]
AT&T IP Network Configuration & Provisioning Development


-Original Message-
From: Henri Gomez [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 27, 2002 11:03 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: [ANNOUNCEMENT]: JK 1.2.0 is now available


Hi all,

The Jakarta-Tomcat-Connector team is pleased to announce the 
availability of JK 1.2.0.

JK, also known as mod_jk, is a Tomcat / WebServers plug-in that handles 
the communication between Tomcat and webservers.

Currently Apache 1.3.x and 2.0.x, IIS, Netscape/iPlanet are supported.

binaries and source versions of the release are available and can be 
downloaded from :

http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1
.2.0/

Binaries allready available are :

- Linux i386 (Apache 1.3/2.0.42)
- Solaris 8 (Apache 1.3/2.0.39/2.0.42)
- Win32 (IIS/Apache 1.3/2.0.42)

MacOS X, AIX, iSeries binaries to be released shortly (I hope)

Feel free to contact us to provide binaries for your own operating
system.

Enjoy!


--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

DO NOT REPLY [Bug 13081] - ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes

[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=13081

ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes





--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 15:12 ---
Remy,

Thanks for the response.  I understand what you are getting at.  Unfortunately,
although we would like to go strictly tags based, some of the platforms that we
are trying to run on don't do tags very well... The extra generated code in the
JSP servlets absolutely kills performance.  Until we can remove support for that
platform, we are stuck with a mix of Java scriplets and tags in some cases. 
That is our reality.  

I can take a look at using Jasper1 with 4.1.12, but unfortunately Jasper2 does
some nice new code generation that would further help our performance in the
cases that we do tags.  We would like to be able to take advantage of that.

As for the spec, you can certainly argue this one either way.  I agree that
clarification is probably necessary.  I would also say that I believe as long as
Java scriptlets are allowed in the pages by spec, that the page generation
should not be allowed to do anything that would break because of that.

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

[ANNOUNCEMENT]: JK 1.2.0 is now available

[Henri Gomez]

Hi all,

The Jakarta-Tomcat-Connector team is pleased to announce the 
availability of JK 1.2.0.

JK, also known as mod_jk, is a Tomcat / WebServers plug-in that handles 
the communication between Tomcat and webservers.

Currently Apache 1.3.x and 2.0.x, IIS, Netscape/iPlanet are supported.

binaries and source versions of the release are available and can be 
downloaded from :

http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/

Binaries allready available are :

- Linux i386 (Apache 1.3/2.0.42)
- Solaris 8 (Apache 1.3/2.0.39/2.0.42)
- Win32 (IIS/Apache 1.3/2.0.42)

MacOS X, AIX, iSeries binaries to be released shortly (I hope)

Feel free to contact us to provide binaries for your own operating
system.

Enjoy!


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

DO NOT REPLY [Bug 13081] - ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes

[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=13081

ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Blocker |Major



--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 14:57 ---
Quite frankly, this is more likely to get fixed by fixing the spec rather than
fixing Tomcat. Of course, the spec / Jasper gurus have the final word.
Anyway, if I were you, I'd plan to either stick with Jasper 1 (I would use TC
4.1.12 + Jasper 1, as detailed in the 4.1.12 release notes, to get more
reliability and performance) or fix my code (I think refactoring to get good
code can't hurt in the long run).

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

DO NOT REPLY [Bug 13081] New: - ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes

[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=13081

ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes

   Summary: ScriptingVariableVisitor#setScriptingVars does not
account for scriptlet scopes
   Product: Tomcat 4
   Version: 4.1.12
  Platform: All
OS/Version: All
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The code in ScriptingVariableVisitor#setScriptingVars is attempting to fix a
long-standing problem whereby tags within other tags cannot declare scripting
variables twice (due to the same Java scope) and yet tags that are scoped within
different parent tags *must* redeclare the variable.  This is handled by the
following snippet of code:

Integer currentRange = (Integer) scriptVars.get(varName);
if (currentRange == null
|| ownRange.compareTo(currentRange) > 0) {
scriptVars.put(varName, ownRange);
vec.add(varInfos[i]);
}

The problem with this code is that it ignores the fact that java scriptlets may
have defined explicit code blocks, limiting the visibility of a scripting
variable more than this particular piece of code can ever realize.  Because of
the need to handle this situation, all of our tags take an optional attribute
"declareVariables" and have for many years.  The above snippet of code breaks
valid JSP's that have worked for us on the 4.0.x series of Tomcat.  Despite the
fact that it is not considered good "form" to use significant Java code in
JSP's, it is certainly allowed.  We have legacy applications that we cannot
change for various reasons.

Understanding that there is a real problem to be solved here (which we solved a
different way), I'm wondering if I can suggest solving this dilemma by
introducing a new servlet initialization parameter to control whether the above
check is done or not.  The default value could be true so that the check above
can continue to be done, but allowing us to override the configuration in
web.xml to turn this check off.

At this point, we have to drop back to the 4.0.x series of Tomcat to avoid this
problem.  We would very much like to use the new, better performing 4.1.x
series, but will have to wait until a reasonable solution can be found to this
problem.

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

DO NOT REPLY [Bug 13080] - when response.sendRedirect is executed it takes lot of time to execute and gives exception

[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=13080

when response.sendRedirect is executed it takes lot of time to execute and gives 
exception

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX
Summary|when response.sendRedirect  |when response.sendRedirect
   |is executed it takes lot of |is executed it takes lot of
   |time to execute and gives   |time to execute and gives
   |exception   |exception



--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 14:38 ---
First, it is impolite to write in caps. Second, this is a known issue with the
old HTTP/1.1 connector and JDK 1.4. Either upgrade to Tomcat 4.1.x or use JDK 1.3.

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

DO NOT REPLY [Bug 13080] New: - when response.sendRedirect is executed it takes lot of time to execute and gives exception

[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=13080

when response.sendRedirect is executed it takes lot of time to execute and gives 
exception 

   Summary: when response.sendRedirect is executed it takes lot of
time to execute and gives exception
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


when response.sendRedirect is executed it takes lot of time to execute, BUT IT 
GETS ME TO THE REQUIRED PAGE AND I GET AN EXCEPTION IN CATALINA LOGS. Exception 
is

java.lang.IllegalStateException: Current state = FLUSHED, new state = CODING_END
at java.nio.charset.CharsetEncoder.throwIllegalStateException
(CharsetEncoder.java:933)
at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529)
at sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar
(StreamEncoder.java:356)
at sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413)
at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158)
at java.io.OutputStreamWriter.close(OutputStreamWriter.java:222)
at java.io.PrintWriter.close(PrintWriter.java:137)
at org.apache.catalina.connector.ResponseBase.finishResponse
(ResponseBase.java:482)
at org.apache.catalina.connector.HttpResponseBase.finishResponse
(HttpResponseBase.java:237)
at org.apache.catalina.connector.http.HttpResponseImpl.finishResponse
(HttpResponseImpl.java:287)
at org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:1054)
at org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1125)
at java.lang.Thread.run(Thread.java:536)

and the the code that is executed in servlet is 


public void doGet(HttpServletRequest mRequest, HttpServletResponse res)
throws ServletException, IOException
{

res.sendRedirect(res.encodeURL   
(".."+fSpr+".."+fSpr+"servlet"+fSpr+"LoginServlet"));

}
so i m not sending any data back to the client
Please help me asap. Thanx in advance.
Girish

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

Tagging JK2_2_0_0

[Mladen Turk]

The JK will get tagged as JK2_2_0_0 today on 18:00 GMT.

The sources will be on the
http://cvs.apache.org/~mturk/jk2/v2.0.0/src

Regards,

MT.



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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache13 mod_jk2.c

[mturk]

mturk   2002/09/27 06:18:26

  Modified:jk/native2/server/apache13 mod_jk2.c
  Log:
  Fix the compile warnings.
  
  Revision  ChangesPath
  1.22  +2 -3  jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c
  
  Index: mod_jk2.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- mod_jk2.c 25 Sep 2002 08:11:10 -  1.21
  +++ mod_jk2.c 27 Sep 2002 13:18:26 -  1.22
  @@ -197,7 +197,7 @@
   
   /* Local initialization.
*/
  -workerEnv->_private = s;
  +workerEnv->_private = (void *)s;
   
   /* serverRoot via ap_server_root_relative()
*/
  @@ -316,7 +316,6 @@
*/
   static int jk2_handler(request_rec *r)
   {   
  -const char   *worker_name;
   jk_logger_t  *l=NULL;
   int  rc;
   jk_worker_t *worker=NULL;
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_service_apache2.c

[mturk]

mturk   2002/09/27 06:14:09

  Modified:jk/native2/server/apache2 jk_service_apache2.c
  Log:
  Fix the compile warning unsigned -> int
  
  Revision  ChangesPath
  1.29  +3 -3  
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c
  
  Index: jk_service_apache2.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- jk_service_apache2.c  14 Jul 2002 13:37:28 -  1.28
  +++ jk_service_apache2.c  27 Sep 2002 13:14:09 -  1.29
  @@ -230,7 +230,7 @@
   #endif
   
   static int JK_METHOD jk2_service_apache2_write(jk_env_t *env, jk_ws_service_t *s,
  -   const void *b, int len)
  +   const void *b, unsigned int len)
   {
   size_t r = 0;
   long ll=len;
  @@ -315,7 +315,7 @@
   static long jk2_get_content_length(jk_env_t *env, request_rec *r)
   {
   if(r->clength > 0) {
  -return r->clength;
  +return (long)(r->clength);
   } else {
   char *lenp = (char *)apr_table_get(r->headers_in, "Content-Length");
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_logger_file.c

[mturk]

mturk   2002/09/27 06:08:17

  Modified:jk/native2/common jk_logger_file.c
  Log:
  Fix the reported level as INFO not ERROR.
  
  Revision  ChangesPath
  1.34  +2 -2  jakarta-tomcat-connectors/jk/native2/common/jk_logger_file.c
  
  Index: jk_logger_file.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_logger_file.c,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- jk_logger_file.c  24 Sep 2002 22:37:13 -  1.33
  +++ jk_logger_file.c  27 Sep 2002 13:08:17 -  1.34
  @@ -213,7 +213,7 @@
   } else if( strcmp( name, "level" )==0 ) {
   _this->level = jk2_logger_file_parseLogLevel(env, value);
   if( _this->level == 0 ) {
  -_this->jkLog( env, _this, JK_LOG_ERROR,
  +_this->jkLog( env, _this, JK_LOG_INFO,
 "Level %s %d \n", value, _this->level );
   }
   }
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_status.c jk_shm.c jk_channel_apr_socket.c

[mturk]

mturk   2002/09/27 06:07:28

  Modified:jk/native2/common jk_worker_status.c jk_shm.c
jk_channel_apr_socket.c
  Log:
  Fix the compiler warnings about 64->32 bits.
  
  Revision  ChangesPath
  1.31  +2 -2  jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c
  
  Index: jk_worker_status.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- jk_worker_status.c8 Jul 2002 13:32:49 -   1.30
  +++ jk_worker_status.c27 Sep 2002 13:07:28 -  1.31
  @@ -114,9 +114,9 @@
   s->jkprintf(env, s, "%ld\n",
   (long)(stat->endTime - stat->startTime) );
   
  -totalTime += stat->totalTime;
  +totalTime += (long)stat->totalTime;
   if( maxTime < stat->maxTime )
  -maxTime=stat->maxTime;
  +maxTime = (long)stat->maxTime;
   }
   #endif
   s->jkprintf(env, s, "\n");
  
  
  
  1.30  +2 -2  jakarta-tomcat-connectors/jk/native2/common/jk_shm.c
  
  Index: jk_shm.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_shm.c,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- jk_shm.c  24 Sep 2002 22:41:48 -  1.29
  +++ jk_shm.c  27 Sep 2002 13:07:28 -  1.30
  @@ -162,7 +162,7 @@
   
   if( finfo.size < shm->size ) {
   char bytes[1024];
  -apr_size_t toWrite=shm->size-finfo.size;
  +apr_size_t toWrite = (apr_size_t)(shm->size-finfo.size);
   apr_off_t off=0;
   
   memset( bytes, 0, 1024 );
  @@ -190,7 +190,7 @@
   /* Now mmap it
*/
   rc=apr_mmap_create( &aprMmap,  file, (apr_off_t)0,
  -finfo.size, APR_MMAP_READ | APR_MMAP_WRITE,
  +(apr_size_t)finfo.size, APR_MMAP_READ | APR_MMAP_WRITE,
   globalShmPool );
   if( rc!=JK_OK ) {
   char error[256];
  
  
  
  1.25  +1 -1  
jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c
  
  Index: jk_channel_apr_socket.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- jk_channel_apr_socket.c   8 Jul 2002 13:42:03 -   1.24
  +++ jk_channel_apr_socket.c   27 Sep 2002 13:07:28 -  1.25
  @@ -218,7 +218,7 @@
   
   apr_socket_t *sock=endpoint->channelData;
   apr_status_t ret;
  -apr_int32_t timeout = socketInfo->timeout * APR_USEC_PER_SEC;
  +apr_int32_t timeout = (apr_int32_t)(socketInfo->timeout * APR_USEC_PER_SEC);
   char msg[128];
   
   if (apr_socket_create(&sock, remote_sa->family, SOCK_STREAM,
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/conf workers2.properties

[mturk]

mturk   2002/09/27 06:05:11

  Modified:jk/conf  workers2.properties
  Log:
  tomcat-jni is inside TOMCAT_HOME/bin not /lib
  
  Revision  ChangesPath
  1.17  +2 -2  jakarta-tomcat-connectors/jk/conf/workers2.properties
  
  Index: workers2.properties
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/conf/workers2.properties,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- workers2.properties   19 Sep 2002 06:28:24 -  1.16
  +++ workers2.properties   27 Sep 2002 13:05:11 -  1.17
  @@ -68,7 +68,7 @@
   [vm:]
   info=Parameters used to load a JVM in the server process
   #JVM=C:\jdk\jre\bin\hotspot\jvm.dll
  
-OPT=-Djava.class.path=${TOMCAT_HOME}/lib/tomcat-jni.jar;${TOMCAT_HOME}/server/lib/commons-logging.jar
  
+OPT=-Djava.class.path=${TOMCAT_HOME}/bin/tomcat-jni.jar;${TOMCAT_HOME}/server/lib/commons-logging.jar
   OPT=-Dtomcat.home=${TOMCAT_HOME}
   OPT=-Dcatalina.home=${TOMCAT_HOME}
   OPT=-Xmx128M
  @@ -122,6 +122,6 @@
   info=Map the whole webapp
   
   [uri:/examples/servlet/HelloW]
  -info=Exampel with debug enabled.
  +info=Example with debug enabled.
   debug=10
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk2_install.vbs

[mturk]

mturk   2002/09/27 06:01:49

  Removed: jk/native2/server/isapi jk2_install.vbs
  Log:
  The admin script is doing lot of harms to the IIS.
  I've even has to reinstall the IIS on one of my servers.
  So until I figure out something that doesn't behave that badly...

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

DO NOT REPLY [Bug 13071] - Class Loading does not work properly

[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=13071

Class Loading does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 13:02 ---
You cannot override the shared XML parser, as this causes severe classloading
issues. It is likely the ability to override shared components will be
completely refactored in Tomcat 5.0.x.

However, I just noticed I bundled Xerces 2.0.2, although I meant to bundle 2.1.0
(as defined in build.properties.sample). This will be fixed in Tomcat 4.1.13.
Sorry for the trouble :-(

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

DO NOT REPLY [Bug 13072] - Resources leak leading to memory starvation

[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=13072

Resources leak leading to memory starvation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 12:53 ---
I read all your posts on tomcat-user already. This is not a bug, please do not
reopen this.

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

DO NOT REPLY [Bug 13072] New: - Resources leak leading to memory starvation

[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=13072

Resources leak leading to memory starvation

   Summary: Resources leak leading to memory starvation
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This is what I do to reproduce the problem.
It is very easy.

- Clean install of redhat 7.2 or 
Suse 7.1 (same results for both platforms)
- Clean installation of tomcat 4.1.12
- Clean 
installation if JDK 1.4.1 (the same happens with 1.4.0.2 or 1.3.1)
- What I am doing is 
http://localhost:8080/  and keep refreshing that with F5
- I am NOT testing my own servlet. I am 
NOT doing anything else !!!

I monitor memory usage using top and sorting the results by 
memory. I am looking at the SIZE column.
What I get is an EVER INCREASING memory usage. Something 
like
30212
30220
31016
31040
31576

-
I did try the various suggestions and as far 
as I can tell it is not a pure  memory issue but it probably is a resource issue, 
maybe a file not closed 
or a socket ...

Please do not dismiss it as the usual Garbage collect issue, if you keep 
refreshing the page the memory used will increase.

Thanks

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

DO NOT REPLY [Bug 13071] New: - Class Loading does not work properly

[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=13071

Class Loading does not work properly

   Summary: Class Loading does not work properly
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In my application I am using different version of xercesImpl.jar then the one located 
in 
$CATALINA_HOME/common/endorsed (mine is 2.1.0).  

The version provided with Tomcat has a 
nasty bug in it: org.apache.xerces.util.DOMErrorHandlerWrapper was being 
non-serializable 
was not declared as transient in one of Document Implementation classes thus causing 
NonSerializableException during serialization of a class implementting Serializable 
interface (org.apache.xerces.dom.NodeImpl).

This bug is fixed in Xerces-2.1.0 and since I 
have it in my WEB-INF/lib directory, according to 
http://jakarta.apache.org/tomcat/tomcat-
4.1-doc/class-loader-howto.html, I should expect that this version will be used by my 
application, rather then the 'endorsed' one.  

However, the fact I am having the exception 
indicates that the 'endorsed' version is used.  As a workarond I have replaced 
'endorsed' 
versions of xercesImp.jar and xmlParserAPIs.jar with v. 2.1.0 and they worked fine.

Still, 
I guess, classloading order should be fixed.

My JDK version is 1.3.1_04 and J2SDKEE version 
is 1.3.1

Regards, Vadim.

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

Re: Tomcat 4.1.12: access log corrupted

[David Shanahan]

FYI 

> [EMAIL PROTECTED] wrote:
>> Well, i rechecked all twice, i't a new fresh install.
>> The only old thing is the app context, that is not embedded into server.xml
>> but as a standalone file.
>> I still had a doubt about the jk module that was compiled for 4.1.10, but i
>> downloaded 4.1.12 connectors and recompiled them.
>> I tested both jk and jk2 with ajp3 connector with same results.
>> Also the application was recompiled against 4.1.12.
>> If nobody has any other hint, i'll open a bug.
> 
> According to my testing, this doesn't happen with Tomcat standalone on
> 8080 (or you'll have to explain how to get the problems).
> 
> Since the requestURI buffer isn't used much in Tomcat, it is possible
> that Coyote JK2 mutates it, creating the incorrect logs.

I have a filter that calls request.getRequestURI() after the request has
been processed by the destination servlet. (The filter roughly measures
servlet processing times).

When I changed from using mod_jk to mod_jk2, request.getRequestURI() started
returning part of the content of the response instead of the URI.
Moving the call to request.getRequestURI() before the call to
chain.doFilter() fixed the problem.

This didn't happen with mod_jk or the http connector.

> Of course, if you use Apache + Tomcat, maybe you should use the native
> access logger instead (it should be much faster).
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 

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

DO NOT REPLY [Bug 13069] New: - mod_webapp inits all webapps for each virtualHost

[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=13069

mod_webapp inits all webapps for each virtualHost

   Summary: mod_webapp inits all webapps for each virtualHost
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Webapp
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


It looks like the mod_webb when it is used together with Apache virtualHost 
directives, cause all webapps in tomcat/webapps dir to init once for every 
virtualHost, even if only one webapp is deployed for that specific virtualHost..

Tested Config on Solaris and Linux with Jdk 1.3.1_02:
Apache 1.3.23
Tomcat 4.0.3 and 4.1.12

Server.xml







  
  



... 






...





  

httpd.conf

ServerName webapp1.xxx.yyy
DocumentRoot "/home/www/webapp1"

Options FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all

WebAppConnection conn1 warp 192.168.10.10:8008
WebAppDeploy webapp1 conn1 /



ServerName webapp2.xxx.yyy
DocumentRoot "/home/www/webapp2"

Options FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all

WebAppConnection conn2 warp 192.168.10.10:8008
WebAppDeploy webapp2 conn2 /


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

Re: Tomcat 4.1.12: access log corrupted

[Tim Funk]

Some of actually use both logs(apache and tomcat) for varios reasons. 
The tomcat logs allow us to look at how well load balancing is working 
across all our tomcat instances.

If bug patch 12145 were examined - tomcat logging would be much richer 
allowing Request & Session Attributes, Cookies, and Input Headers to 
also be logged per request.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12145

Remy Maucherat wrote:
> [EMAIL PROTECTED] wrote:
> 
>> Well, i rechecked all twice, i't a new fresh install.
>> The only old thing is the app context, that is not embedded into 
>> server.xml
>> but as a standalone file.
>> I still had a doubt about the jk module that was compiled for 4.1.10, 
>> but i
>> downloaded 4.1.12 connectors and recompiled them.
>> I tested both jk and jk2 with ajp3 connector with same results.
>> Also the application was recompiled against 4.1.12.
>> If nobody has any other hint, i'll open a bug.
> 
> 
> According to my testing, this doesn't happen with Tomcat standalone on 
> 8080 (or you'll have to explain how to get the problems).
> 
> Since the requestURI buffer isn't used much in Tomcat, it is possible 
> that Coyote JK2 mutates it, creating the incorrect logs.
> Of course, if you use Apache + Tomcat, maybe you should use the native 
> access logger instead (it should be much faster).
> 
> Remy


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

DO NOT REPLY [Bug 12985] - jsp load-on-startup behavior not correct

[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=12985

jsp load-on-startup behavior not correct

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 10:51 ---
There is still a bug where the jspInit() method gets called twice.

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

DO NOT REPLY [Bug 13068] New: - Use of validationQuery parameter by BasicDataSourceFactory implementation

[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=13068

Use of validationQuery parameter by BasicDataSourceFactory implementation

   Summary: Use of validationQuery parameter by
BasicDataSourceFactory implementation
   Product: Tomcat 4
   Version: 4.1.8
  Platform: All
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When specifying a JNDI connection pool resource a parameter exists
"validationQuery" that is documented to "validate a connection before returning
it to the client".

Use of this does not appear to be implmented.

I have looked into the code of:
org.apache.commons.dbcp.BasicDataSourceFactory
BasicDataSource
PoolableConnectionFactory
PoolingDataSource

and cannot find any sql statment/execution that would use the SQL specified in 
the validationQuery parameter.

If I am wrong then sorry for waisting your time - but would it be possible to 
tell me where to find further documentation on this - or on how to refresh a 
pool of connections that have become invalidated by a loss in socket connection 
to the database.

Rob

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

DO NOT REPLY [Bug 13067] - When webapp is restarted the finalize method of application scope classes is not called consistently

[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=13067

When webapp is restarted the finalize method of application scope classes is not 
called consistently

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-09-27 10:27 ---
This is, of course, unspecified behavior (Tomcat does not attempt to control
when the garbage collector is run). The container provides other lifecycle
mechanisms either proprietary or through the standard servlet API (valves,
listeners).
Read the docs or post on tomcat-user for more details.

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

DO NOT REPLY [Bug 13067] New: - When webapp is restarted the finalize method of application scope classes is not called consistently

[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=13067

When webapp is restarted the finalize method of application scope classes is not 
called consistently

   Summary: When webapp is restarted the finalize method of
application scope classes is not called consistently
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am using oracle database connection pooling and have a login connection pool 
that is managed by an application scope class. The finalize method of this 
class is coded to terminate the login connection pool.

I would have expected the finalize method to be called when the webapp restarts 
but.

The finalize of the method is however not called consistently - if I use the 
manager app to do a restart on the webapp the finalize method is called maybe 1 
in 3 times. Clearly I need a method of running this everytime.

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

Re: Tomcat 4.1.12: access log corrupted

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
> Well, i rechecked all twice, i't a new fresh install.
> The only old thing is the app context, that is not embedded into server.xml
> but as a standalone file.
> I still had a doubt about the jk module that was compiled for 4.1.10, but i
> downloaded 4.1.12 connectors and recompiled them.
> I tested both jk and jk2 with ajp3 connector with same results.
> Also the application was recompiled against 4.1.12.
> If nobody has any other hint, i'll open a bug.

According to my testing, this doesn't happen with Tomcat standalone on 
8080 (or you'll have to explain how to get the problems).

Since the requestURI buffer isn't used much in Tomcat, it is possible 
that Coyote JK2 mutates it, creating the incorrect logs.
Of course, if you use Apache + Tomcat, maybe you should use the native 
access logger instead (it should be much faster).

Remy


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

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapijk2_install.vbs

[Henri Gomez]

Henri Gomez wrote:
> [EMAIL PROTECTED] wrote:
> 
>> mturk   2002/09/26 11:45:55
>>
> 
> Very interesting stuff...
> 
> I didn't expect to see VBS one days in an Apache CVS ;)
> But in JTC we found more exotic stuff like iSeries CL sources...

Read, didn't expected 



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

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapijk2_install.vbs

[Henri Gomez]

[EMAIL PROTECTED] wrote:
> mturk   2002/09/26 11:45:55
> 

Very interesting stuff...

I didn't expect to see VBS one days in an Apache CVS ;)
But in JTC we found more exotic stuff like iSeries CL sources...





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