DO NOT REPLY [Bug 22097] - build.xml dependency problem

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22097.
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=22097

build.xml dependency problem

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 06:43 ---
Use the main build script (from the jakarta-tomcat-5 repository).

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



DO NOT REPLY [Bug 22006] - Invalid SMAP line entries when running with mappedfile=true

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22006.
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=22006

Invalid SMAP line entries when running with mappedfile=true

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Keywords||PatchAvailable



--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 06:43 ---
There are two reasons the Actual LineInfo differs from the Expected LineInfo:

1) When a TemplateText node spans more than one line in the JSP, Jasper SMAPs 
it as if all of the node's output source was generated by the first line of 
the node's input source, and the other lines in the node's input source 
contributed nothing.

2) Jasper SMAPs each node independently of the others, and makes no attempt to 
consolidate the resulting line section.  I'm not sure consolidation is 
actually required by the spec, but it reduces the size of the class files, so 
it's a good thing to do.

I will attach a patch that fixes both of these.

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



DO NOT REPLY [Bug 22006] - Invalid SMAP line entries when running with mappedfile=true

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22006.
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=22006

Invalid SMAP line entries when running with mappedfile=true





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 06:44 ---
Created an attachment (id=7636)
Proposed patch

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



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

2003-08-04 Thread remm
remm2003/08/04 00:00:53

  Modified:docs index.html
   xdocsindex.xml
  Log:
  - Update for Tomcat 5.0.6 Alpha.
  
  Revision  ChangesPath
  1.44  +1 -1  jakarta-tomcat-site/docs/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/index.html,v
  retrieving revision 1.43
  retrieving revision 1.44
  diff -u -r1.43 -r1.44
  --- index.html31 Jul 2003 19:39:14 -  1.43
  +++ index.html4 Aug 2003 07:00:53 -   1.44
  @@ -169,7 +169,7 @@
   /td
   td bgcolor=#a0ddf0 colspan= rowspan= 
valign=top align=left
   font color=#00 size=-1 face=arial,helvetica,sanserif
  -5.0.5 Alpha
  +5.0.6 Alpha
   /font
   /td
   /tr
  
  
  
  1.36  +1 -1  jakarta-tomcat-site/xdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/xdocs/index.xml,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- index.xml 31 Jul 2003 19:39:14 -  1.35
  +++ index.xml 4 Aug 2003 07:00:53 -   1.36
  @@ -40,7 +40,7 @@
   
   tr
 td2.4/2.0/td
  -  td5.0.5 Alpha/td
  +  td5.0.6 Alpha/td
   /tr
   
   tr
  
  
  

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



Re: 4.1.27: manager reload of context fails to redeploy WEB-INF/lib and WEB-INF/classes

2003-08-04 Thread Remy Maucherat
David Rees wrote:
I just entered this bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096
I can reproduce it. Right now, I can't isolate the root cause.

Surprised it wasn't caught before the release.
I doubt this was introduced between 4.1.26 and 4.1.27, so there should 
have been plenty of time to catch it indeed.
One problem is that the reload mechanism is overly complex, so 
historically, there has been a significant amount of bugs in it. In 
5.0.x, all the custom logic is now replaced by stop + start (which is 
marginally slower, but is *a lot* simpler).

Remy



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


cvs commit: jakarta-tomcat-5 RELEASE-PLAN-5.0.txt

2003-08-04 Thread remm
remm2003/08/04 01:17:02

  Modified:.RELEASE-PLAN-5.0.txt
  Log:
  - Update target beta date.
  
  Revision  ChangesPath
  1.2   +4 -4  jakarta-tomcat-5/RELEASE-PLAN-5.0.txt
  
  Index: RELEASE-PLAN-5.0.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/RELEASE-PLAN-5.0.txt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- RELEASE-PLAN-5.0.txt  23 Jun 2003 13:53:37 -  1.1
  +++ RELEASE-PLAN-5.0.txt  4 Aug 2003 08:17:02 -   1.2
  @@ -37,10 +37,10 @@
   This Release Plan proposes the following prospective target dates 
   for stability:
   
  -  End of July, 2003
  -  -
  +  Middle of August, 2003
  +  --
   
  -Tomcat 5.0 should reach Beta status.
  +Tomcat 5.0 should reach Beta status by this date.
   
 Servlet 2.4 and JSP 2.0 Final Specification Releases (expected by 09/2003)
 
  
  
  

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



cvs commit: jakarta-tomcat-catalina/webapps/docs status.xml

2003-08-04 Thread remm
remm2003/08/04 01:31:24

  Modified:webapps/docs status.xml
  Log:
  - One item done :)
  
  Revision  ChangesPath
  1.5   +0 -4  jakarta-tomcat-catalina/webapps/docs/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/status.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- status.xml24 Jun 2003 21:04:56 -  1.4
  +++ status.xml4 Aug 2003 08:31:24 -   1.5
  @@ -63,10 +63,6 @@
   GUI for the deployer.
 /item
 item priority=Low owner=---
  -Stack size reduction (removal of valves to improve runtime 
  -performance and ease debugging).
  -  /item
  -  item priority=Low owner=---
   Java load balancer / cache (?) for use with Tomcat clustering, or
   with session affinity.
 /item
  
  
  

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



RE: tomcat-5.0.5 cannot access jar resources in WEB-INF/lib but o nly unzipped in WEB-INF/classes

2003-08-04 Thread Harmsen, Jan
Hi Remy,

sorry for not sending you a test case, there were some high priority
tasks coming in which had to be served first. As it looks now I will
be able to set up a test case within the next 2 days.

Best regards,

Jan

 -Original Message-
 From: Remy Maucherat [mailto:[EMAIL PROTECTED]
 Sent: Saturday, August 02, 2003 7:47 PM
 To: Tomcat Developers List
 Subject: Re: tomcat-5.0.5 cannot access jar resources in 
 WEB-INF/lib but
 o nly unzipped in WEB-INF/classes
 
 
 Harmsen, Jan wrote:
 Please provide a test case along with infomation on your 
 environment.
  
  okay, tomorrow I'll provide a test case + description,
 
 Any update on this ? This is obviously a big problem if the issue is 
 valid, so I'd really appreciate your help.
 
 Thanks,
 Remy
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


How to config the sever.xml and web.xml about tomcat-4.1.27?

2003-08-04 Thread 50332696
Hello!,
   I want to ask about the configuration of tomcat-4.1.27. I want to get some 
infomation about thw whole set up. Thank you for your help!


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



[VOTE] Tomcat 5.0 release plan

2003-08-04 Thread Remy Maucherat
I have updated the dates mentioned in the release plan (given that 
Tomcat 5 can't go to beta before the end of last month ;-) ). It now 
calls for a beta before the 15th of August, which means either Tomcat 
5.0.6 or 5.0.7 would have to be declared beta to fit the schedule 
(assuming the one release per week keeps on, plus one week test/vote to 
decide on the build stability). Of course, the release plan would be 
affected by last minute changes or delays in the Servlet and JSP 
specifications.

I consider the current 5.0.6 build to be feature complete, so I believe 
this schedule is realistic. I volunteer to continue being the release 
manager for this Tomcat branch.

This release plan vote if a maority vote. Please send any comments on 
the release plan ASAP if some modifications are required.

ballot
[ ] +1 I approve this release plan, and I will help
[ ] +0 I approve this release plan
[ ] -0 I disagree with the release plan
[ ] -1 I am against this release plan
/ballot
comments
/comments
Remy

$Id: RELEASE-PLAN-5.0.txt,v 1.2 2003/08/04 08:17:02 remm Exp $

  Release Plan for Apache Tomcat 5.0
  ==


Introduction:


This document is a release plan for the final release of Apache Tomcat 5.0.

The goal of the Apache Tomcat 5.0 final release is to provide a stable
container that supports 100% of the mandatory requirements of the Servlet 2.4
and JSP 2.0 specifications, as well as to improve and add many useful 
additional features on top of the existing Apache Tomcat 4.1.x releases.

Apache Tomcat 5.0 includes the following major new features over 
Apache Tomcat 4.1:

* Performance optimizations and reduced garbage collection
* Refactored application deployer, with an optional standalone deployer 
  allowing validation and compilation of a web application before putting 
  it in production
* Complete server monitoring using JMX and the manager web application
* Scalability and reliability enhancements
* Improved Taglibs handling, including advanced pooling and tag plugins
* Improved platform integration, with native Windows and Unix wrappers
* Embedding of Tomcat using JMX
* Expanded documentation

Apache Tomcat 5.0 will use the build numbering and release process first used 
in the Apache HTTPd 2.0.x project.
Milestone builds, numbered 5.0.x, will be released as needed and will 
recieve a stability rating after a one week testing period. The rating can be
either: Alpha, Beta, or Stable.

This Release Plan proposes the following prospective target dates 
for stability:

  Middle of August, 2003
  --

Tomcat 5.0 should reach Beta status by this date.

  Servlet 2.4 and JSP 2.0 Final Specification Releases (expected by 09/2003)
  

At least another Beta rated release should be made simultaneous to the release
of the specification.

  Two to four weeks after Final Specification Releases
  

Best effort should be made for Tomcat 5.0 to reach Stable status as soon as
possible after the specification releases. However, it should be pointed out 
that wide testing cannot occur before the specifications are released, so
a Stable release should only be made after a period of time.

In order to complete a first Stable release, all outstanding Bugzilla bug 
reports against Tomcat 5.0 above NORMAL severity need to be fixed or deferred 
for later releases.

This Release Plan proposes the following classification of current outstanding
bug reports in the bug tracking system, sorted by component and their ID
numbers in our bug tracking system at:

http://nagoya.apache.org/bugzilla/

Please review the bug reports, and their severity accordingly. 


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

DO NOT REPLY [Bug 22090] - EL evaluation should cache parse results

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22090.
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=22090

EL evaluation should cache parse results





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 09:24 ---
Evidence (threaddumps) supports that the problem is not the parsing performance
per se, but the allocation of three (8k+16k+16k) buffers per parser invocation:

SimpleCharStream.java:
#245:buffer = new char[buffersize];
#246:bufline = new int[buffersize];
#247:bufcolumn = new int[buffersize];

tcpConnection-8001-14 daemon prio=1 tid=0x4e102df8 nid=0x33ca waiting for
monitor entry [bbdfe000..bbdff908]
at
org.apache.commons.el.parser.SimpleCharStream.init(SimpleCharStream.java:245)
at
org.apache.commons.el.parser.SimpleCharStream.init(SimpleCharStream.java:253)
at org.apache.commons.el.parser.ELParser.init(ELParser.java:1721)

This is kind of a commons/el problem, not a jasper one. I will try to patch el
to use smaller buffers (which expression is 4k???). If that improves matters, I
might close this report although I still consider it valid.

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



DO NOT REPLY [Bug 22090] - EL evaluation should cache parse results

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22090.
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=22090

EL evaluation should cache parse results





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 09:35 ---
Good findings.

I think those buffers should be owned by another component (Jasper's
PageContextImpl IMO), and passed to commons-el), to allow reuse and avoid the
allocation. This could be optional (commons-el would allocate buffers if none
are passed): a new constructor would simply need to be added.

Buffers bigger than 1K take a significant amount of time to allocate (and making
them too small might impact functionality), so even 4K would be too big IMO.

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



DO NOT REPLY [Bug 22103] New: - JspC.execute do not close files

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22103.
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=22103

JspC.execute do not close files

   Summary: JspC.execute do not close files
   Product: Tomcat 5
   Version: 5.0.6
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When there is an error in the JSP file, and the JSP compiler is invoked from an 
ANT script via JspC.execute(), the opened files are not closed.

What seems to happen is that the java output files is created and opened, the 
error in the JSP is detected and an exception is trigered without closing the 
opened files.

That raise problems when the ANT script is called from an IDE (like eclipse) 
that does'nt use a separate JVM to execute it.  In that case, the created empty 
file can not be deleted without closing the IDE.

Is it possible to add a finally clause somewhere to always close all opened 
files, even in case of errors ?

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



DO NOT REPLY [Bug 22090] - EL evaluation should cache parse results

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22090.
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=22090

EL evaluation should cache parse results





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 10:53 ---
Some measurements:

1. no el cache, parser default buffers: 40 req/s, 1.8m/s
2. no el cache, small parser buffers: 90req/s, 3.7m/s
3. el cache: 200req/s, 8m/s
4. non-synchronized el-cache (simulates parsed expression trees stored per
tagfile instance): 210req/s, 8.5m/s

linux dual proc, 100mbit ethernet, j2sdk 1.4.2, resin 2.1.9, jasper 5.0.6
page data completely in memory, ~70 simple el evaluations, 40k html

still voting for option 3 or 4.
last post on this subject.

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



ERROR: Apache Tomcat/5.0.5 - Not sure which build

2003-08-04 Thread James Urie
Error in package org.apache.jasper.runtime.BodyContentImpl class.

Method:

   /**
* Write a single character.
*/
   public void write(int c) throws IOException {
   if (writer != null) {
   writer.write(c);
   } else {
   ensureOpen();
   if (nextChar = bufferSize) {
   reAllocBuff (0);
   }
   cb[nextChar++] = (char) c;
   }
   }
Comment:

If the developer has more than 512 character being fed to this method an 
array-out-of-bounds
will occur.  reAllocBuff should not be zero.

Cheers,

James

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


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

2003-08-04 Thread remm
remm2003/08/04 05:26:33

  Modified:jasper2/src/share/org/apache/jasper/runtime
PageContextImpl.java
  Log:
  - Enable expression cache, submitted by Matthias Ernst. Bug 22090.
  
  Revision  ChangesPath
  1.51  +4 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java
  
  Index: PageContextImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
  retrieving revision 1.50
  retrieving revision 1.51
  diff -u -r1.50 -r1.51
  --- PageContextImpl.java  11 Jul 2003 01:29:14 -  1.50
  +++ PageContextImpl.java  4 Aug 2003 12:26:33 -   1.51
  @@ -121,7 +121,7 @@
   
   // The expression evaluator, for evaluating EL expressions.
   private static ExpressionEvaluatorImpl elExprEval
  - = new ExpressionEvaluatorImpl(true);
  + = new ExpressionEvaluatorImpl(false);
   
   // The variable resolver, for evaluating EL expressions.
   private VariableResolverImpl variableResolver;
  
  
  

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



DO NOT REPLY [Bug 22090] - EL evaluation should cache parse results

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22090.
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=22090

EL evaluation should cache parse results

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 12:30 ---
Well, I thought your second post meant that the benefit of using caching was
offset by some buffer allocation. Looking at the code, the allocation doesn't
seem to happen with the cache, so there's no problem.
Your patch seems good, sorry for the misunderstanding.

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



DO NOT REPLY [Bug 22103] - JspC.execute do not close files

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22103.
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=22103

JspC.execute do not close files





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 12:43 ---
Since you seem to have looked into the problem in detail, could you submit a
small patch ?
Otherwise, can you give more details on where the leak come from ?

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



RE: [VOTE] Tomcat 5.0 release plan

2003-08-04 Thread Shapira, Yoav




Yoav Shapira
Millennium ChemInformatics


-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 5:17 AM
To: Tomcat Developers List
Subject: [VOTE] Tomcat 5.0 release plan

ballot
[X] +1 I approve this release plan, and I will help
[ ] +0 I approve this release plan
[ ] -0 I disagree with the release plan
[ ] -1 I am against this release plan
/ballot

comments

I will try to put out commons-modeler 1.1 final in the next couple of
days, so we can updated that dependency.

/comments

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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



DO NOT REPLY [Bug 22103] - JspC.execute do not close files

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22103.
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=22103

JspC.execute do not close files





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 13:12 ---
Oups, sorry I can not send you a patch.  But I have look in the source, and I 
think that if you update the org.apache.jasper.compiler.Compiler.compile
(boolean) method by insterting

if (ctx.getWriter()!=null)
{
   ctx.getWriter().close();
   ctx.setWriter(null);
}

in the finally clause.

BTW, how can I give you patch if I don't have a CVS client?

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



DO NOT REPLY [Bug 4893] - Tomcat dies with following error..

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4893.
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=4893

Tomcat dies with following error..





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 13:46 ---
 for me also the same problem occur. i think in ur application you are using 
the resultset and preparedstatements. so make sure that all the resultset and 
preparedstatments closed like

 if(psmt!=null){
psmt.close();
psmt=null;
 }
 if(rs!=null){
rs.close();
rs=null;
  }

 i hope this will solved this problem

bye
shafeek

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



Re: [VOTE] Tomcat 5.0 release plan

2003-08-04 Thread Costin Manolache
Remy Maucherat wrote:

 I have updated the dates mentioned in the release plan (given that
 Tomcat 5 can't go to beta before the end of last month ;-) ). It now
 calls for a beta before the 15th of August, which means either Tomcat
 5.0.6 or 5.0.7 would have to be declared beta to fit the schedule
 (assuming the one release per week keeps on, plus one week test/vote to
 decide on the build stability). Of course, the release plan would be
 affected by last minute changes or delays in the Servlet and JSP
 specifications.
 
 I consider the current 5.0.6 build to be feature complete, so I believe
 this schedule is realistic. I volunteer to continue being the release
 manager for this Tomcat branch.
 
 This release plan vote if a maority vote. Please send any comments on
 the release plan ASAP if some modifications are required.
 
 ballot
 [ ] +1 I approve this release plan, and I will help
 [X] +0 I approve this release plan
 [ ] -0 I disagree with the release plan
 [ ] -1 I am against this release plan
 /ballot

For the next few months I can't help too much - really sorry, but my work
schedule is crazy. 

Costin


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



Re: [VOTE] Tomcat 5.0 release plan

2003-08-04 Thread Tim Funk
Remy Maucherat wrote:
ballot
[X] +1 I approve this release plan, and I will help
[ ] +0 I approve this release plan
[ ] -0 I disagree with the release plan
[ ] -1 I am against this release plan
/ballot
comments
I will be without a computer (therefore not checking email) next week aug 10-17.
/comments
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


DO NOT REPLY [Bug 22108] New: - WebDAV not working with default servlet mapping

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22108.
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=22108

WebDAV not working with default  servlet mapping

   Summary: WebDAV not working with default  servlet mapping
   Product: Tomcat 5
   Version: 5.0.6
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Servlets:WebDAV
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The servlet mapping as specified in the deployment descriptor for the webdav 
application (taken from TC 4.1.27) doesn't work. I had to change

servlet-mapping
servlet-namewebdav/servlet-name
url-pattern//url-pattern
/servlet-mapping

to

servlet-mapping
servlet-namewebdav/servlet-name
url-pattern/*/url-pattern
/servlet-mapping

to make things work. This doesn't seem to be compliant with SVR 11.2 of the 
current servlet specification.

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



DO NOT REPLY [Bug 22096] - reload through manager webapp fails to redeploy classes/jars

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096.
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=22096

reload through manager webapp fails to redeploy classes/jars





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 14:39 ---
I confirm I have that exact problem, both on 4.1.26 that I installed last
Friday, and on 4.1.27 that I installed today.
Previous version was 4.1.24, which was working fine.
Configuration was left the same.

I'm not sure about it, but I was surprised to see that in the exception report:
C:\TEMP\index_jsp.java:99: cannot resolve symbol


I though Tomcat put all its temporary stuff in the work/directort.
I couldn't find any temporary JSP dating from 4.1.24 in TEMP.

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



DO NOT REPLY [Bug 22110] New: - URL encoded space characters (%20) get lost

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22110.
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=22110

URL encoded space characters (%20) get lost

   Summary: URL encoded space characters (%20) get lost
   Product: Tomcat 4
   Version: 4.1.24
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We encountered that %20-characters (encoded spaces) in URI-Parameters are 
omitted by Tomcat. 
an URI containing 
...PARAM=This%20is%20a%20hashed%20message
results in 
PARAM=Thisisahashedmessage 

which is -in the context of a hash- fatal

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



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

2003-08-04 Thread remm
remm2003/08/04 08:09:41

  Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
  Log:
  - Release servlet writer after compilation (bug 22103).
  - Submitted by Gilles Scokart.
  
  Revision  ChangesPath
  1.67  +4 -0  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
  
  Index: Compiler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
  retrieving revision 1.66
  retrieving revision 1.67
  diff -u -r1.66 -r1.67
  --- Compiler.java 28 Jul 2003 18:47:30 -  1.66
  +++ Compiler.java 4 Aug 2003 15:09:41 -   1.67
  @@ -469,6 +469,10 @@
   project = null;
   pageInfo = null;
   pageNodes = null;
  +if (ctxt.getWriter() != null) {
  +ctxt.getWriter().close();
  +ctxt.setWriter(null);
  +}
   }
   }
   
  
  
  

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



DO NOT REPLY [Bug 22103] - JspC.execute do not close files

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22103.
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=22103

JspC.execute do not close files

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 15:12 ---
Ok, the proposed change seems reasonable to me. Thanks. I assume you have
verified it fixes your problem.

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



DO NOT REPLY [Bug 22103] - JspC.execute do not close files

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22103.
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=22103

JspC.execute do not close files





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 15:22 ---
Unfortunately, no.  I didn't have all the environment (and/or the time) I need 
to recompile and test the fix.  But as you said, it seems reasonable.

Thanks.

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



cvs commit: jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager StatusManagerServlet.java

2003-08-04 Thread remm
remm2003/08/04 08:33:08

  Modified:webapps/manager/WEB-INF/classes/org/apache/catalina/manager
StatusManagerServlet.java
  Log:
  - Also display wrapper mappings.
  
  Revision  ChangesPath
  1.9   +17 -4 
jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/StatusManagerServlet.java
  
  Index: StatusManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/StatusManagerServlet.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- StatusManagerServlet.java 30 Jul 2003 18:43:01 -  1.8
  +++ StatusManagerServlet.java 4 Aug 2003 15:33:08 -   1.9
  @@ -607,8 +607,21 @@
   
   String servletName = objectName.getKeyProperty(name);
   
  +String[] mappings = (String[]) 
  +mBeanServer.invoke(objectName, findMappings, null, null);
  +
   writer.print(h2);
   writer.print(servletName);
  +if ((mappings != null)  (mappings.length  0)) {
  +writer.print( [ );
  +for (int i = 0; i  mappings.length; i++) {
  +writer.print(mappings[i]);
  +if (i  mappings.length - 1) {
  +writer.print( , );
  +}
  +}
  +writer.print( ] );
  +}
   writer.print(/h2);
   
   writer.print(p);
  
  
  

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



DO NOT REPLY [Bug 22108] - WebDAV not working with default servlet mapping

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22108.
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=22108

WebDAV not working with default  servlet mapping

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 16:15 ---
I tried mapping the WebDAV servlet as the default servlet of a context, and it
works. There's an impact from the updated welcome files processing though (it
now matches the spec requirements, but is lower level and more intrusive), so
you have to put an empty list for that.
If there's a bug with the WebDAV servlet, you should look into it, as there's no
real maintainer for it anymore.
BTW, /* is a perfectly valid mapping (it has priority over a lot of other
mappings, which makes it especially well suited IMO for WebDAV).

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



DO NOT REPLY [Bug 22111] New: - Alternative location for autoDeploy context snipped

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22111.
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=22111

Alternative location for autoDeploy context snipped

   Summary: Alternative location for autoDeploy context snipped
   Product: Tomcat 4
   Version: 4.1.24
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Request for enhancement: When using autoDeploy with a app.war file
tomcat currently looks for a file app.xml or context.xml that can
contain the Context / snipped for this application.

Alternatively one should also be able to place this file in
the META-INF directory of the .war file.

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



DO NOT REPLY [Bug 22112] New: - Cannot autoDeploy .war file to root context

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22112.
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=22112

Cannot autoDeploy .war file to root context

   Summary: Cannot autoDeploy .war file to root context
   Product: Tomcat 4
   Version: 4.1.24
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Tomcat does not correctly autoDeploy a .war file to the root context, when the
option unpackWars is selected.

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



DO NOT REPLY [Bug 22113] New: - Improvable Exception Message Cannot create resource instance

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22113.
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=22113

Improvable Exception Message Cannot create resource instance

   Summary: Improvable Exception Message Cannot create resource
instance
   Product: Tomcat 4
   Version: 4.1.24
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I didn't know which module this belongs to - sorry.

When org.apache.naming.factory.ResourceFactory fails to instanciate an
object by e.g. Class.forName().getInstance a NamingException   
(Cannot create resource instance) is issued.

Request for enhancement: Do not ignore the exception thrown by getInstance().
Instead use NamingException.setRootCause() to pass the information. This 
will avoid many headaches. (Oh yes, like mine). If e.g. a DataSource cannot be 
created because of a JDBC driver issue this would be obvious then.

[...]
try {
factory = (ObjectFactory) 
Class.forName(javaxSqlDataSourceFactoryClassName)
.newInstance();
} catch(Throwable t) {
/* NEW */  NamingException nx = new NamingException(t.getMessage());
/* NEW */  nx.setRootCause(t);
/* NEW */  throw nx;
}

[...] 2 more repetitions.

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



DO NOT REPLY [Bug 22114] New: - mod_jk2: wrong load balancing group assigned

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22114.
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=22114

mod_jk2: wrong load balancing group assigned

   Summary: mod_jk2: wrong load balancing group assigned
   Product: Tomcat 4
   Version: 4.1.24
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have created a load balancing group in workers2.properties. When I assign 
this group to a virtual host in httpd.conf and then inspect /jkstatus I can see 
that the group is correctly assigned to that virtual host. However mod_jk2 has 
automatically created two additional URIs vhost/ and vhost/* with the 
default group lb:lb assigned instead of lb:mygroup.

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



DO NOT REPLY [Bug 22096] - reload through manager webapp fails to redeploy classes/jars

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096.
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=22096

reload through manager webapp fails to redeploy classes/jars





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 17:27 ---
I don't know yet when this bug was introduced, and will look into the issue.

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



Re: 4.1.27: manager reload of context fails to redeploy WEB-INF/lib and WEB-INF/classes

2003-08-04 Thread David Rees
Remy Maucherat wrote:
David Rees wrote:
I just entered this bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096
I can reproduce it. Right now, I can't isolate the root cause.

Surprised it wasn't caught before the release.
I doubt this was introduced between 4.1.26 and 4.1.27, so there should 
have been plenty of time to catch it indeed.
One problem is that the reload mechanism is overly complex, so 
historically, there has been a significant amount of bugs in it. In 
5.0.x, all the custom logic is now replaced by stop + start (which is 
marginally slower, but is *a lot* simpler).
Not being familiar with the workings of the manager app, but if it's a 
lot easier implement a simple stop/start the context when reloading, why 
not do so in 4.1.x like TC 5?

I doubt anyone will notice a tiny performance hit when doing reloads, 
especially since it's broken anyway.  ;-)

Wish I had time to dig into Tomcat internals.

-Dave

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


Re: 4.1.27: manager reload of context fails to redeploy WEB-INF/lib and WEB-INF/classes

2003-08-04 Thread Remy Maucherat
David Rees wrote:
Remy Maucherat wrote:

David Rees wrote:

I just entered this bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096
I can reproduce it. Right now, I can't isolate the root cause.

Surprised it wasn't caught before the release.
I doubt this was introduced between 4.1.26 and 4.1.27, so there should 
have been plenty of time to catch it indeed.
One problem is that the reload mechanism is overly complex, so 
historically, there has been a significant amount of bugs in it. In 
5.0.x, all the custom logic is now replaced by stop + start (which is 
marginally slower, but is *a lot* simpler).
Not being familiar with the workings of the manager app, but if it's a 
lot easier implement a simple stop/start the context when reloading, why 
not do so in 4.1.x like TC 5?
Well, it significantly changes the semantics of reload, and as a result 
could break things. That's why it's not a good idea IMO to port that.

I doubt anyone will notice a tiny performance hit when doing reloads, 
especially since it's broken anyway.  ;-)

Wish I had time to dig into Tomcat internals.
Remy



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


[OT] New job

2003-08-04 Thread Remy Maucherat
This is OT, sorry.

I've accepted a position of Consultant at the JBoss Group, where I will 
help maintain the JBoss / Tomcat integration (which has become 
especially important since their decision to use Tomcat as their default 
servlet container in the upcoming JBoss releases), spend a significant 
amount of time working on Tomcat (as before), and provide commercial 
support / consulting / training on Tomcat.

So the cool part is that my Tomcat work is funded again :)

Remy



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


RE: [OT] New job

2003-08-04 Thread Shapira, Yoav

Howdy,
Cool - congrats and good luck ;)

Yoav Shapira
Millennium ChemInformatics


-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 2:40 PM
To: Tomcat Developers List
Subject: [OT] New job

This is OT, sorry.

I've accepted a position of Consultant at the JBoss Group, where I will
help maintain the JBoss / Tomcat integration (which has become
especially important since their decision to use Tomcat as their
default
servlet container in the upcoming JBoss releases), spend a significant
amount of time working on Tomcat (as before), and provide commercial
support / consulting / training on Tomcat.

So the cool part is that my Tomcat work is funded again :)

Remy



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




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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



cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup HostConfig.java

2003-08-04 Thread remm
remm2003/08/04 12:02:30

  Modified:catalina/src/share/org/apache/catalina/startup
HostConfig.java
  Log:
  - Allow putting a /META-INF/context.xml inside any WAR file deployed
by the HostConfig.
  
  Revision  ChangesPath
  1.21  +74 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java
  
  Index: HostConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- HostConfig.java   26 Jul 2003 14:24:52 -  1.20
  +++ HostConfig.java   4 Aug 2003 19:02:30 -   1.21
  @@ -436,6 +436,10 @@
*/
   protected File configBase() {
   
  +if (configBase != null) {
  +return configBase;
  +}
  +
   File file = new File(System.getProperty(catalina.base), conf);
   Container parent = host.getParent();
   if ((parent != null)  (parent instanceof Engine)) {
  @@ -562,6 +566,72 @@
   contextPath = ;
   if (host.findChild(contextPath) != null)
   continue;
  +
  +// Checking for a nested /META-INF/context.xml
  +JarFile jar = null;
  +JarEntry entry = null;
  +InputStream istream = null;
  +BufferedOutputStream ostream = null;
  +File xml = new File
  +(configBase, files[i].substring
  + (0, files[i].lastIndexOf(.)) + .xml);
  +if (!xml.exists()) {
  +try {
  +jar = new JarFile(dir);
  +entry = jar.getJarEntry(META-INF/context.xml);
  +if (entry != null) {
  +istream = jar.getInputStream(entry);
  +ostream =
  +new BufferedOutputStream
  +(new FileOutputStream(xml), 1024);
  +byte buffer[] = new byte[1024];
  +while (true) {
  +int n = istream.read(buffer);
  +if (n  0) {
  +break;
  +}
  +ostream.write(buffer, 0, n);
  +}
  +ostream.flush();
  +ostream.close();
  +ostream = null;
  +istream.close();
  +istream = null;
  +entry = null;
  +jar.close();
  +jar = null;
  +deployDescriptors(configBase(), configBase.list());
  +return;
  +}
  +} catch (Exception e) {
  +// Ignore and continue
  +if (ostream != null) {
  +try {
  +ostream.close();
  +} catch (Throwable t) {
  +;
  +}
  +ostream = null;
  +}
  +if (istream != null) {
  +try {
  +istream.close();
  +} catch (Throwable t) {
  +;
  +}
  +istream = null;
  +}
  +entry = null;
  +if (jar != null) {
  +try {
  +jar.close();
  +} catch (Throwable t) {
  +;
  +}
  +jar = null;
  +}
  +}
  +}
   
   if (isUnpackWARs()) {
   
  
  
  

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



DO NOT REPLY [Bug 21206] - Tomcat 5 - Jetspeed JSP Portlets do not display

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21206.
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=21206

Tomcat 5 - Jetspeed JSP Portlets do not display





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 19:24 ---
Some progress: Jasper does get invoked in both scenarios through an include
(with or without a server restart).
However, in the first case, the processed JSP is:
/portal/media-type/html/user/turbine/page/default.psml/media-type/html (bad)
In the second case, it is: /WEB-INF/templates/jsp/portlets/html/hello.jsp (good)
I added a Thread.dumpStack in JspServlet.service, and the stack trace is
identical, so I don't understand how it could come from a RD dispatcher bug
(which according to the stack trace is the only possible culprit).

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



DO NOT REPLY [Bug 22111] - Alternative location for autoDeploy context snipped

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22111.
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=22111

Alternative location for autoDeploy context snipped

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 19:34 ---
This is useful, and adds consistency, so I have added the feature in Tomcat 5.

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



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

2003-08-04 Thread remm
remm2003/08/04 13:14:36

  Modified:jasper2/src/share/org/apache/jasper/servlet JspServlet.java
  Log:
  - Fix including a JSP, where Jasper would do weird things whenever the
outer request had a non null pathInfo. now, it will use the included servlet
path correctly.
  - This fixes bug 21206 (issue with Jetspeed).
  
  Revision  ChangesPath
  1.29  +10 -11
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java
  
  Index: JspServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- JspServlet.java   22 Jul 2003 21:04:46 -  1.28
  +++ JspServlet.java   4 Aug 2003 20:14:36 -   1.29
  @@ -202,18 +202,17 @@
   
   if (includeUri == null) {
jspUri = request.getServletPath();
  +// When jsp-property-group/url-matching is used, and when the 
  +// jsp is not defined with servlet-name, the url
  +// as to be passed as it is to the JSP container (since 
  +// Catalina doesn't know anything about the requested JSP 
  +if (request.getPathInfo() != null) {
  +jspUri = request.getServletPath() + request.getPathInfo();
  +}
   } else {
   jspUri = includeUri;
   }
   
  -// When jsp-property-group/url-matching is used, and when the 
  -// jsp is not defined with servlet-name, the url
  -// as to be passed as it is to the JSP container (since Catalina
  -// doesn't know anything about the requested JSP 
  -if(request.getPathInfo() != null){
  -jspUri = request.getServletPath() + request.getPathInfo();
  -}
  -
   String jspFile = (String) request.getAttribute(Constants.JSP_FILE);
   if (jspFile != null) {
   jspUri = jspFile;
  
  
  

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



DO NOT REPLY [Bug 21206] - Tomcat 5 - Jetspeed JSP Portlets do not display

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21206.
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=21206

Tomcat 5 - Jetspeed JSP Portlets do not display

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Blocker |Major
 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 20:22 ---
The bug turned out to be a dumb bug in Jasper (after spending one more hour
debugging the RD ...). This will be fixed in 5.0.7 (or in the next nightly;
applying the patch is trivial if you're using the CVS code).
Easy workaround: After editing, you need to click on the home link on the
left, or access your portal through a URI which doesn't have a pathInfo. I'm
downgrading the severity of the bug.

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



DO NOT REPLY [Bug 14184] - HttpSession object has confusing behaviour (HttpSession.isNew() )

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14184.
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=14184

HttpSession object has confusing behaviour (HttpSession.isNew() )





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 20:36 ---
FWIW, I believe I'm seeing this same bug.  I can call request.getSession() in
one servlet, call request.getSession() later in another servlet, and have the
second session's isNew() method return true.  The session ID's are the same when
this happens, and I do have cookies enabled.

This is with Tomcat 4.1.24

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



DO NOT REPLY [Bug 22118] New: - Manager webapp not reloading context

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22118.
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=22118

Manager webapp not reloading context

   Summary: Manager webapp not reloading context
   Product: Tomcat 4
   Version: 4.1.24
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm using the manager web app (either the HTML version, or the regular manager)
to reload a context afer changes to classes.  reloadable is set to true for 
this context in server.xml.
When I call reload on the changed web app, the manager hangs indefinitely.  
All other manager functions work, and reload works for all unchanged web 
apps.  There doesn't seem to be any errors in the logs, and I can reload the 
context by stopping and starting Tomcat (but this is obviously non-optimal for 
a production box!)

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



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

2003-08-04 Thread luehe
luehe   2003/08/04 15:55:45

  Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
Validator.java PageInfo.java
  Log:
  Have 'isELIgnored' page directive attribute take precendence over JSP
  config el-ignored. This is according to the spec.
  
  Revision  ChangesPath
  1.68  +10 -11
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
  
  Index: Compiler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
  retrieving revision 1.67
  retrieving revision 1.68
  diff -u -r1.67 -r1.68
  --- Compiler.java 4 Aug 2003 15:09:41 -   1.67
  +++ Compiler.java 4 Aug 2003 22:55:44 -   1.68
  @@ -209,17 +209,16 @@
JspConfig.JspProperty jspProperty =
jspConfig.findJspProperty(ctxt.getJspFile());
   
  - // If the current uri is matched by a pattern specified in
  - // a jsp-property-group in web.xml, initialize pageInfo with
  - // those properties.
  - if (jspProperty.isELIgnored() != null) {
  - pageInfo.setELIgnoredSpecified(true);
  - }
  - pageInfo.setELIgnored(JspUtil.booleanValue(jspProperty.isELIgnored()));
  - 
pageInfo.setScriptingInvalid(JspUtil.booleanValue(jspProperty.isScriptingInvalid()));
  - if (jspProperty.getIncludePrelude() != null) {
  - pageInfo.setIncludePrelude(jspProperty.getIncludePrelude());
  - }
  +/*
  + * If the current uri is matched by a pattern specified in
  + * a jsp-property-group in web.xml, initialize pageInfo with
  + * those properties.
  + */
  +pageInfo.setELIgnored(JspUtil.booleanValue(jspProperty.isELIgnored()));
  +
pageInfo.setScriptingInvalid(JspUtil.booleanValue(jspProperty.isScriptingInvalid()));
  +if (jspProperty.getIncludePrelude() != null) {
  +pageInfo.setIncludePrelude(jspProperty.getIncludePrelude());
  +}
if (jspProperty.getIncludeCoda() != null) {
pageInfo.setIncludeCoda(jspProperty.getIncludeCoda());
}
  
  
  
  1.112 +5 -11 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
  
  Index: Validator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
  retrieving revision 1.111
  retrieving revision 1.112
  diff -u -r1.111 -r1.112
  --- Validator.java23 Jul 2003 20:37:24 -  1.111
  +++ Validator.java4 Aug 2003 22:55:44 -   1.112
  @@ -196,10 +196,7 @@
}
} else if (isELIgnored.equals(attr)) {
if (pageInfo.getIsELIgnored() == null) {
  - if (!pageInfo.isELIgnoredSpecified()) {
  - // If specified in jsp-config, use it
  - pageInfo.setIsELIgnored(value, n, err, true);
  - } 
  +pageInfo.setIsELIgnored(value, n, err, true);
} else if (!pageInfo.getIsELIgnored().equals(value)) {
err.jspError(n, jsp.error.page.conflict.iselignored,
 pageInfo.getIsELIgnored(), value);
  @@ -268,10 +265,7 @@
}
} else if (isELIgnored.equals(attr)) {
if (pageInfo.getIsELIgnored() == null) {
  - if (!pageInfo.isELIgnoredSpecified()) {
  - // If specified in jsp-config, use it
  - pageInfo.setIsELIgnored(value, n, err, false);
  - } 
  +pageInfo.setIsELIgnored(value, n, err, false);
} else if (!pageInfo.getIsELIgnored().equals(value)) {
err.jspError(n, jsp.error.tag.conflict.iselignored,
 pageInfo.getIsELIgnored(), value);
  
  
  
  1.36  +3 -12 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java
  
  Index: PageInfo.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- PageInfo.java 1 Aug 2003 17:10:10 -   1.35
  +++ PageInfo.java 4 Aug 2003 22:55:44 -   1.36
  @@ -104,7 +104,6 @@
   private boolean scriptingInvalid = false;
   private String isELIgnoredValue;
   private boolean isELIgnored = false;
  -private boolean elIgnoredSpecified = false;
   private String omitXmlDecl = null;
   
   private boolean isJspPrefixHijacked;
  @@ -194,14 +193,6 @@
   
   public boolean 

RE: [VOTE] Tomcat 5.0 release plan

2003-08-04 Thread Larry Isaacs


 -Original Message-
 From: Remy Maucherat [mailto:[EMAIL PROTECTED] 
 Sent: Monday, August 04, 2003 5:17 AM
 To: Tomcat Developers List
 Subject: [VOTE] Tomcat 5.0 release plan
 
 
 I have updated the dates mentioned in the release plan (given that 
 Tomcat 5 can't go to beta before the end of last month ;-) ). It now 
 calls for a beta before the 15th of August, which means either Tomcat 
 5.0.6 or 5.0.7 would have to be declared beta to fit the schedule 
 (assuming the one release per week keeps on, plus one week 
 test/vote to 
 decide on the build stability). Of course, the release plan would be 
 affected by last minute changes or delays in the Servlet and JSP 
 specifications.
 
 I consider the current 5.0.6 build to be feature complete, so 
 I believe 
 this schedule is realistic. I volunteer to continue being the release 
 manager for this Tomcat branch.
 
 This release plan vote if a maority vote. Please send any comments on 
 the release plan ASAP if some modifications are required.
 
 ballot
 [?] +1 I approve this release plan, and I will help [if possible]
 [X] +0 I approve this release plan
 [ ] -0 I disagree with the release plan
 [ ] -1 I am against this release plan
 /ballot

As my work project nears completion, my heavy load should lighten in
about a month.  However, I'm afraid to look behind me for fear of
discovering that something new gaining on me.  I'll try to help
as time permits.

Larry

 
 comments
 /comments
 
 Remy
 
 

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



cvs commit: jakarta-tomcat build.xml

2003-08-04 Thread larryi
larryi  2003/08/04 16:30:45

  Modified:.build.xml
  Log:
  Update to copy commons-logging-api.jar since JTC-util HEAD no longer
  copies it.
  
  Revision  ChangesPath
  1.196 +4 -1  jakarta-tomcat/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/build.xml,v
  retrieving revision 1.195
  retrieving revision 1.196
  diff -u -r1.195 -r1.196
  --- build.xml 7 Apr 2003 00:48:11 -   1.195
  +++ build.xml 4 Aug 2003 23:30:44 -   1.196
  @@ -456,12 +456,15 @@
   /jar
   
   !-- Add jakarta-tomcat-connectors utils --
  -!-- Includes the tomcat-utils.jar and common-logging.jar --
   copy todir=${tomcat.build}/lib/common
 fileset dir=${jtc.util.build}/lib
   include name=*.jar/
 /fileset
   /copy
  +
  +!-- Copy commons-logging-api.jar since tomcat-util depends on it --
  +copy todir=${tomcat.build}/lib/common
  +  file=${commons-logging.jar}/
   
   !-- All tomcat3 specific utils --
   jar jarfile=${tomcat.build}/lib/container/container_util.jar 
  
  
  

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



DO NOT REPLY [Bug 11678] - JNDIRealm times out/prompts for password with BASIC authentication

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11678.
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=11678

JNDIRealm times out/prompts for password with BASIC authentication





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 23:57 ---
It looks as if code is in JNDIRealm.java to deal with this issue as of about 
Tomcat 4.1.19 or so.  (JNDIRealm 1.11).  But, there was a NullPointerException 
causing that code not to work, at least against certain LDAP Servers.  (See bug 
# 19864).  Hopefully that (and therefore this) will be fixed very soon.

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



DO NOT REPLY [Bug 19864] - JNDIRealm NullPointerException / CommunicationException when Context Closed

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19864.
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=19864

JNDIRealm NullPointerException / CommunicationException when Context Closed





--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 23:59 ---
If it is:
if (e.toString().indexOf(closed)  0)
throw(e);

That should take care of the problem of the error being Connection closed as 
well.

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



DO NOT REPLY [Bug 22082] - Variable substiturion not working for server.xml

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22082.
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=22082

Variable substiturion not working for server.xml

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-05 00:51 ---
Tomcat 3.3 and Tomcat 4.x differ significantly, not only architecturally, but in
XML parser used to parse server.xml.  Tomcat 3.3 uses an internal
implementation, which supports substitution.  Tomcat 4.x uses commons-
digester, which currently does not support substitution.

You are welcome to file a feature request for this on commons-digester.

Marking as INVALID since a lot of Tomcat 3.3's documentation doesn't apply at 
all to Tomcat 4.

For now, maybe you can generate customized server.xmls from a single source XML 
using some technology, for example Ant's copy task (with filtering) or xslt 
task.

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



cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm JNDIRealm.java

2003-08-04 Thread funkman
funkman 2003/08/04 17:54:26

  Modified:catalina/src/share/org/apache/catalina/realm JNDIRealm.java
  Log:
  Fix bugs:
  18698 - Exception message in JNDI realm is not Socket closed on different ldap 
implementations
  11678 - JNDIRealm times out/prompts for password with BASIC authentication
  19864 - JNDIRealm NullPointerException / CommunicationException when Context Closed
  
  20518 - JNDIRealm not retrying primary LDAP server after failed attempt against 
alternate server
Thanks to Bradley M. Handy bhandy aT users dot sf (another dot) net for 20518
  
  For the first 3 bugs:
  When CommunicationException is thrown, check that message is not null.
  When CommunicationException is thrown close the connection if
  - Message is null
  - Message contains closed (was Socket closed)
  
  For the last bug:
  Put connectionAttempt = 0 in a finally block
  
  Other thanks to David DeWolf (david at daviddewolf com) and
  Jeff Tulley (jtulley at novell com)
  
  Committing to 4.1 first since this has a better chance of being tested there first.
  
  My text editor strips trailing white space (for seemingly unchanged lines)
  In reality, about 4 lines of code really changed.
  
  Revision  ChangesPath
  1.12  +103 -95   
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
  
  Index: JNDIRealm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- JNDIRealm.java11 Jan 2003 01:47:13 -  1.11
  +++ JNDIRealm.java5 Aug 2003 00:54:26 -   1.12
  @@ -107,7 +107,7 @@
* substituting the presented username into a pattern configured by the
* codeuserPattern/code property./li
*
  - * liAlternatively, if the codeuserPattern/code property is not 
  + * liAlternatively, if the codeuserPattern/code property is not
* specified, a unique element can be located by searching the directory
* context. In this case:
* ul
  @@ -122,7 +122,7 @@
* requests a search of only the current level./li
*/ul
* /li
  - * 
  + *
* liThe user may be authenticated by binding to the directory with the
*  username and password presented. This method is used when the
*  codeuserPassword/code property is not specified./li
  @@ -244,19 +244,20 @@
   
   
   /**
  - * The protocol that will be used in the communication with the directory 
server.
  + * The protocol that will be used in the communication with the
  + * directory server.
*/
   protected String protocol = null;
   
   
   /**
  - * How should we handle referrals?  Microsoft Active Directory can't handle 
  - * the default case, so an application authenticating against AD must 
  + * How should we handle referrals?  Microsoft Active Directory can't handle
  + * the default case, so an application authenticating against AD must
* set referrals to follow.
*/
   protected String referrals = null;
  -
  -
  +
  +
   /**
* The base element for user searches.
*/
  @@ -292,7 +293,7 @@
   /**
* The message format used to form the distinguished name of a
* user, with {0} marking the spot where the specified username
  - * goes.  
  + * goes.
*/
   protected String userPattern = null;
   
  @@ -342,11 +343,11 @@
*/
   protected boolean roleSubtree = false;
   
  -/** 
  +/**
* An alternate URL, to which, we should connect if connectionURL fails.
*/
  -protected String alternateURL;  
  -
  +protected String alternateURL;
  +
   /**
* The number of connection attempts.  If greater than zero we use the
* alternate url.
  @@ -357,24 +358,24 @@
   
   /**
* Return the type of authentication to use.
  - */  
  + */
   public String getAuthentication() {
   
   return authentication;
  -
  +
   }
  - 
  +
   /**
* Set the type of authentication to use.
*
* @param authentication The authentication
*/
   public void setAuthentication(String authentication) {
  -
  +
   this.authentication = authentication;
  -
  +
   }
  -  
  +
   /**
* Return the connection username for this Realm.
*/
  @@ -467,20 +468,20 @@
* Return the protocol to be used.
*/
   public String getProtocol() {
  - 
  +
   return protocol;
  - 
  +
   }
  -
  +
   /**
* Set the protocol for this Realm.
*
* @param protocol The new protocol.
*/
   public void setProtocol(String protocol) {
  - 
  +
   this.protocol = protocol;
  -
  +
   }
   
   
  @@ -493,13 

DO NOT REPLY [Bug 11678] - JNDIRealm times out/prompts for password with BASIC authentication

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11678.
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=11678

JNDIRealm times out/prompts for password with BASIC authentication

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-05 00:58 ---
Patched in HEAD of 4.1. Please test and so I may port to 5.

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



DO NOT REPLY [Bug 19864] - JNDIRealm NullPointerException / CommunicationException when Context Closed

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19864.
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=19864

JNDIRealm NullPointerException / CommunicationException when Context Closed

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-05 00:59 ---
Patched in HEAD of 4.1. Please test and so I may port to 5.

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



DO NOT REPLY [Bug 11678] - JNDIRealm times out/prompts for password with BASIC authentication

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11678.
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=11678

JNDIRealm times out/prompts for password with BASIC authentication

This bug depends on bug 19864, which changed state:

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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



DO NOT REPLY [Bug 18698] - Exception message in JNDI realm is not Socket closed on different ldap implementations

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18698.
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=18698

Exception message in JNDI realm is not Socket closed on different ldap 
implementations

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-05 01:02 ---
Patched in HEAD of 4.1. Please test and so I may port to 5.

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



Tomcat shutdown port and security

2003-08-04 Thread NAIK,ROSHAN (HP-Cupertino,ex1)

Given that _anybody_ on the local machine could simply telnet to the 
port and issue a SHUTDOWN command. Isnt the current shutdown mechanism in 
Tomcat 4 a security issue ? 

-- Roshan 

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



[ANN] Tomcat 5.0.6 Alpha released

2003-08-04 Thread Remy Maucherat
Tomcat 5.0.6 Alpha is now available for testing.

Please refer to the changelog included in the release for the list of 
changes.

Downloads:
http://jakarta.apache.org/site/binindex.cgi
Remy



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


Tomcat apache2, SSL and extremely bad performance.

2003-08-04 Thread henrik . bentel
Thought I'd try here too:

SETUP:
linux 7.3, apache 2.0.45, tomcat4.1.24, mod_jk2, latest and greatest
openssl.
apache conf: 2 virtualhosts (one secure), pluss default host. No mod_jk2
configuration except LoadModule jk2_module modules/mod_jk2.so
workers2 conf: 1 socket channel, 2 workers (worker=ajp13:localhost:8009)
server.xml: 1 Coyote connector used(basically just uncommented default
definition).
Apache handles certificate, servlet webapp does secure/unsecure
redirection. One connector handles both secure and unsecure comm.

PROBLEM: Responsetimes of up to 12-15 seconds with only 10 concurrent test
threads(jmeter) for very simple content.
webserver error log has plenty of:
[Mon Aug 04 21:50:21 2003] [error] jk2_init() Can't find child 25954 in
scoreboard
[Mon Aug 04 21:50:21 2003] [error] mod_jk child init 1 -2
[Mon Aug 04 21:50:25 2003] [error] jk2_init() Can't find child 25959 in
scoreboard
[Mon Aug 04 21:50:25 2003] [error] mod_jk child init 1 -2
.
.


The requests doesn't even have to be for tomcat. Even if I only retrive
static content (such as an image) over https(using jmeter again) I get
these errors. And same bad performance?!?! 10 seconds to retrieve an image
with only 10 concurrent accesses? Pluss the mod_jk errors. Which is weird
considering tomcat shouldn't even be involved??

Hope someone can shed some light on this or has seen something similar
before.

Henrik Bentel



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



DO NOT REPLY [Bug 21168] - Incorrect paths in generated SMAP file entries

2003-08-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21168.
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=21168

Incorrect paths in generated SMAP file entries





--- Additional Comments From [EMAIL PROTECTED]  2003-08-05 01:17 ---
Applied patch with slight modification:

Instead of (as suggested in the patch):

  private static String unqualify(String path) {
File f = new File(path);
return f.getName();
  }

the impl now does this:

  private static String unqualify(String path) {
return path.substring(path.lastIndexOf(File.separator) + 1);
  }

which avoids generation of a File object.

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