About possible memory leak in Tomcat 5.x

[Andrievsky Dmitry]

Hello dev,

About a half a year ago I've found that my webapp works fine in
development environment, but leaks memory in production one.
I've searched through all the code, found a few minor errors, but it
didn't help.
(of course, tag pooling are disabled completely)

So then i've tried to use profiler, looking on alien classes.
(I've tried before too, but my attention was concentrated on my own classes)

And then i've found lots of
org.apache.jasper.runtime.PageContextImpl
from which there were a lot of references to the objects, that i've
treated as dead.


All PageContextImpl's lived at
org.apache.jasper.runtime.JspFactoryImpl.pool


There are property of org.apache.jasper.runtime.JspFactoryImpl, named
USE_POOL, which rules pool usage, but it is private,
and i've not found any way to set it to "false" from outside.
Initially it's "true".

So, i've set it to "false" directly in code,
rebuilt tomcat and replaced files ${CATALINA_HOME}/common/lib/jasper-*.jar
from production environment with fresh ones.

So, it seems that the problem is successfully solved.
As far as I can see there no more memory leakage.

I think it would be useful to allow users to set property of
org.apache.jasper.runtime.JspFactoryImpl.USE_POOL from config files or
in any other way, without rebuilding entire tomcat application.

P.S.
In fact, I think, it's not REAL memory leak - memory usage, may be,
will stop grow on some large value (2+ GB, when pool become full), but i have 
not such
amount of memory.
Now memory usage about 100-200 mb after full gc, depending on amount
of currently working users.

P.P.S What seems to me interesting.
Although before putting PageContextImpl into pool JspFactoryImpl calls
pc.release(), and inside the method all links must become null (or
not?..) and referenced objects must become available to gc, they are not.
May be it is the root of the problem?..

BTW disabling of pool solves the problem completely...


-- 
Best regards,
 Dmitry Andrievskymailto:[EMAIL PROTECTED]


















































































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

Re: About possible memory leak in Tomcat 5.x

[Tino Schwarze]

On Tue, Dec 20, 2005 at 12:39:50PM +0300, Andrievsky Dmitry wrote:

> P.P.S What seems to me interesting.  Although before putting
> PageContextImpl into pool JspFactoryImpl calls pc.release(), and
> inside the method all links must become null (or not?..) and
> referenced objects must become available to gc, they are not.  May be
> it is the root of the problem?..

I came across this too and it was caused by Servlets calling
JspFactory.getPageContext(...) and _not_ releasing the PageContext by
calling JspFactory.releasePageContext(...) - which is a real memory
leak (not caused by Tomcat but by the application!). Actually, the
BodyContent array inside PageContextImpl is not reset so the
BodyContents get reused - this might cost significant amounts of memory,
depending on the application.

We have been discussing this recently and it looks like there will be
solution which is useful for everyone: USE_POLL will be made
configurable and maybe big BodyContents will be reset on release().

Bye, Tino.


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

Re: Improving memory efficiency

[Remy Maucherat]

Costin Manolache wrote:

Assuming that most of the pages use 'huge' buffers - you're right.

However, if you have few pages that need large buffers - and most
don't - this will help.
And you would pay the price of System.arraycopy on the bad pages - i.e. normal
pages will be faster, and jsps that abuse the buffer will be even
slower than before. I think it's a good tradeoff, having bad
performance for pages that abuse the tag buffers is a given anyway :-)


As I understand it, these pages should have acceptable performance right 
now. Probably not great, but hopefully not too bad either. Feel free to 
build a test case that could be ab-ed :)


Rémy

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

DO NOT REPLY [Bug 37977] New: - adapt build/BUILDING.txt and build.xml for svn on windows

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=37977

   Summary: adapt build/BUILDING.txt and build.xml for svn on
windows
   Product: Tomcat 5
   Version: 5.5.9
  Platform: Other
   URL: http://tomcat.apache.org/tomcat-5.5-doc/build.xml
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Tried to rebuild tomcat according to BUILDING.txt 

<<[EMAIL PROTECTED]:~/<2>tomcat/mybuild> ant
Buildfile: build.xml

check.source:

get.source:

checkout:
 [echo] If the checkout fails, - todo -

BUILD FAILED
C:\Documents and Settings\RalfCHauser\My
Documents\psph\workspace\tomcat\mybuild\build.xml:87: The following error occur
red while executing this line:
C:\Documents and Settings\RalfCHauser\My
Documents\psph\workspace\tomcat\mybuild\build.xml:70: Execute failed: java.io.I
OException: CreateProcess: svn checkout
http://svn.apache.org/repos/asf//tomcat/current/tc5.5.x C:\Documents and Setting
s\RalfCHauser\My Documents\psph\workspace\tomcat\mybuild error=2

Total time: 0 seconds>>

1) I guess it would be good to update the BUILDING.txt to reflect the move from
CVS to SVN since it still mentions CVS.
2) I do not know a command-line svn client for windows since I use Tortoise as
per http://www.apache.org/dev/version-control.html#anon-svn

I did download the "subversion" package in cygwin and got a little bit further
<<[EMAIL PROTECTED]:~/<2>tomcat/mybuild> ant
Buildfile: build.xml

check.source:

get.source:

checkout:
 [echo] If the checkout fails, - todo -
 [exec] svn: Can't make directory
'Documents\psph\workspace\tomcat\mybuild/tc5.5.x': No such file or directory
 [exec] Result: 1

build:

BUILD FAILED
C:\Documents and Settings\RalfCHauser\My
Documents\psph\workspace\tomcat\mybuild\build.xml:48: Basedir C:\Documents and
Settings\RalfCHauser\My Documents\psph\workspace\tomcat\mybuild\build does not 
exist

Total time: 39 seconds
[EMAIL PROTECTED]:~/<2>tomcat/mybuild>
>>

So, it appears that either the build.xml should be made cygwin aware i.e.
3) a `cygpath -u ${basedir}` might help here or
4) 
 

could be changed to 

 


At least, with cygwin's command line "svn checkout
http://svn.apache.org/repos/asf/tomcat/current/tc5.5.x ." it worked nicely
afterwards

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 37977] - adapt build/BUILDING.txt and build.xml for svn on windows

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=37977





--- Additional Comments From [EMAIL PROTECTED]  2005-12-20 15:02 ---
If anything - I need to post this script on the site: (providing it still works)

http://marc.theaimsgroup.com/?l=tomcat-dev&m=11286855136&w=2




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 29108] - "chunked" transfer-encoding is not working

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29108


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2005-12-20 16:24 ---
On what version was this fixed?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 29108] - "chunked" transfer-encoding is not working

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29108


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-12-20 17:01 ---
(In reply to comment #3)
> On what version was this fixed?

If you're too stupid to look it up, why should I tell you?  Now go away and 
quit waisting people's time.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 29108] - "chunked" transfer-encoding is not working

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29108





--- Additional Comments From [EMAIL PROTECTED]  2005-12-20 17:24 ---
This community reserved the right to block users behaving improperly.
Please be respectful. Thanks.

This bug tracking system is the place to look into for getting the fixed 
release.
Closed bugs must contain a fixed release comment or attribute.

Not everyone has the knowledge to drill down hundred of files in CVS to look for
some unknown comment. Thanks you for your comprehension.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r358036 - in /tomcat/jasper/tc5.5.x/jasper2/src/share/org/apache/jasper/runtime: BodyContentImpl.java JspFactoryImpl.java

[remm]

Author: remm
Date: Tue Dec 20 09:02:33 2005
New Revision: 358036

URL: http://svn.apache.org/viewcvs?rev=358036&view=rev
Log:
- Add two system properties (as given the JSP API, there is no easy solution to
  retrieve configuration parameters elsewhere) to allow configuring Jasper
  memory management. Note that changing from the defaults may affect
  performance, depending on the application.

Modified:

tomcat/jasper/tc5.5.x/jasper2/src/share/org/apache/jasper/runtime/BodyContentImpl.java

tomcat/jasper/tc5.5.x/jasper2/src/share/org/apache/jasper/runtime/JspFactoryImpl.java

Modified: 
tomcat/jasper/tc5.5.x/jasper2/src/share/org/apache/jasper/runtime/BodyContentImpl.java
URL: 
http://svn.apache.org/viewcvs/tomcat/jasper/tc5.5.x/jasper2/src/share/org/apache/jasper/runtime/BodyContentImpl.java?rev=358036&r1=358035&r2=358036&view=diff
==
--- 
tomcat/jasper/tc5.5.x/jasper2/src/share/org/apache/jasper/runtime/BodyContentImpl.java
 (original)
+++ 
tomcat/jasper/tc5.5.x/jasper2/src/share/org/apache/jasper/runtime/BodyContentImpl.java
 Tue Dec 20 09:02:33 2005
@@ -40,6 +40,8 @@
 
 private static final String LINE_SEPARATOR = 
 System.getProperty("line.separator");
+private static final boolean LIMIT_BUFFER = 
+
Boolean.parseBoolean(System.getProperty("org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER",
 "false"));
 
 private char[] cb;
 private int nextChar;
@@ -468,6 +470,10 @@
 throw new IOException();
 } else {
 nextChar = 0;
+if (LIMIT_BUFFER && (cb.length > 
Constants.DEFAULT_TAG_BUFFER_SIZE)) {
+bufferSize = Constants.DEFAULT_TAG_BUFFER_SIZE;
+cb = new char[bufferSize];
+}
 }
 }
 

Modified: 
tomcat/jasper/tc5.5.x/jasper2/src/share/org/apache/jasper/runtime/JspFactoryImpl.java
URL: 
http://svn.apache.org/viewcvs/tomcat/jasper/tc5.5.x/jasper2/src/share/org/apache/jasper/runtime/JspFactoryImpl.java?rev=358036&r1=358035&r2=358036&view=diff
==
--- 
tomcat/jasper/tc5.5.x/jasper2/src/share/org/apache/jasper/runtime/JspFactoryImpl.java
 (original)
+++ 
tomcat/jasper/tc5.5.x/jasper2/src/share/org/apache/jasper/runtime/JspFactoryImpl.java
 Tue Dec 20 09:02:33 2005
@@ -40,9 +40,10 @@
 private Log log = LogFactory.getLog(JspFactoryImpl.class);
 
 private static final String SPEC_VERSION = "2.0";
-private static final boolean USE_POOL = true;
+private static final boolean USE_POOL = 
+
Boolean.parseBoolean(System.getProperty("org.apache.jasper.runtime.JspFactoryImpl.USE_POOL",
 "true"));
 
-private SimplePool pool = new SimplePool( 100 );
+private SimplePool pool = new SimplePool(100);
 
 public PageContext getPageContext(Servlet servlet,
  ServletRequest request,
@@ -51,7 +52,6 @@
   boolean needsSession,
  int bufferSize,
   boolean autoflush) {
-
if( System.getSecurityManager() != null ) {
PrivilegedGetPageContext dp = new PrivilegedGetPageContext(
(JspFactoryImpl)this, servlet, request, response, errorPageURL,



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

Re: svn commit: r358036 - in /tomcat/jasper/tc5.5.x/jasper2/src/share/org/apache/jasper/runtime: BodyContentImpl.java JspFactoryImpl.java

[Tino Schwarze]

Hi there,

On Tue, Dec 20, 2005 at 05:02:37PM -, [EMAIL PROTECTED] wrote:
> Author: remm
> Date: Tue Dec 20 09:02:33 2005
> New Revision: 358036
> 
> URL: http://svn.apache.org/viewcvs?rev=358036&view=rev
> Log:
> - Add two system properties (as given the JSP API, there is no easy solution 
> to
>   retrieve configuration parameters elsewhere) to allow configuring Jasper
>   memory management. Note that changing from the defaults may affect
>   performance, depending on the application.

[...]
> +private static final boolean LIMIT_BUFFER = 
> +
> Boolean.parseBoolean(System.getProperty("org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER",
>  "false"));
[...]
> +if (LIMIT_BUFFER && (cb.length > 
> Constants.DEFAULT_TAG_BUFFER_SIZE)) {
> +bufferSize = Constants.DEFAULT_TAG_BUFFER_SIZE;
> +cb = new char[bufferSize];
[...]
> +private static final boolean USE_POOL = 
> +
> Boolean.parseBoolean(System.getProperty("org.apache.jasper.runtime.JspFactoryImpl.USE_POOL",
>  "true"));

Thanks a lot! This gives people nice adjusting screws.

Bye, Tino.


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

May Chun Chew/FEA/PEC is out of the office.

[May Chun Chew]

I will be out of the office starting  12/21/2005 and will not return until
12/27/2005.

I will respond to your message when I return. For urgent matters, pls
contact SP Lim at [EMAIL PROTECTED] or 63629384.


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

Tomcat 6 plans (JSP 2.1)

[Remy Maucherat]

Hi,

Besides adding support for Servlet 2.5 which does not seem too 
overwhelming, most of the specification work is on support of JSP 2.1. I 
am happy to report that Jacob Hookom is willing to contribute code to 
add the necessary JSP support in Tomcat (he has done such an 
implementation already, and owns the copyright on that code). To host 
the code, a new branch is going to be needed for Jasper (as well as a 
new folder in servletapi).


For testing the implementation, Jacob is going to need access to the JSP 
2.1 TCK (I suppose he'll need to be a committer to do that, but it 
should be ok by then).


Comments ?

Rémy

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

Re: Tomcat 6 plans (JSP 2.1)

[Costin Manolache]

+1

Costin


On 12/20/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Besides adding support for Servlet 2.5 which does not seem too
> overwhelming, most of the specification work is on support of JSP 2.1. I
> am happy to report that Jacob Hookom is willing to contribute code to
> add the necessary JSP support in Tomcat (he has done such an
> implementation already, and owns the copyright on that code). To host
> the code, a new branch is going to be needed for Jasper (as well as a
> new folder in servletapi).
>
> For testing the implementation, Jacob is going to need access to the JSP
> 2.1 TCK (I suppose he'll need to be a committer to do that, but it
> should be ok by then).
>
> Comments ?
>
> Rémy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

RE: Tomcat 6 plans (JSP 2.1)

[Bill Barker]

 

> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, December 20, 2005 12:32 PM
> To: dev@tomcat.apache.org
> Subject: Tomcat 6 plans (JSP 2.1)
> 
> Hi,
> 
> Besides adding support for Servlet 2.5 which does not seem too 
> overwhelming, most of the specification work is on support of 
> JSP 2.1. I 
> am happy to report that Jacob Hookom is willing to contribute code to 
> add the necessary JSP support in Tomcat (he has done such an 
> implementation already, and owns the copyright on that code). To host 
> the code, a new branch is going to be needed for Jasper (as well as a 
> new folder in servletapi).
> 

Does this mean that we'll be hosting EL?  IMHO, resurrecting commons-el to
bring it up to JSP 2.1 was always going to be the hardest part of TC 6.  

I agree that the changes for Servlet 2.5 aren't that bad, but we might as
well branch Container while we are at it.

> For testing the implementation, Jacob is going to need access 
> to the JSP 
> 2.1 TCK (I suppose he'll need to be a committer to do that, but it 
> should be ok by then).
> 

We'll have to get access to the TCK ourselves first ;-).  

> Comments ?
> 
> Rémy
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


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

Re: Tomcat 6 plans (JSP 2.1)

[Keith Wannamaker]

There was some talk of merging the modules in 6, is there any objection 
to that?


Keith


Bill Barker wrote:

I agree that the changes for Servlet 2.5 aren't that bad, but we might as
well branch Container while we are at it.


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

Re: TC 5.5.12 WARNING: A docBase XXX inside the host appBase has been specified, and will be ignored

[Jason Novotny]

Yoav Shapira wrote:


Hi,
Slight juxtaposition of your message:

 


   This certainly seems a lot more limited than the way it worked in TC
5.0. I wonder if I need to file this as a bug or a feature enhancement.
If you have any ideas, I'd love to hear them.
   



 


second step that I don't want to do since some of the  web app code
internally uses a hardcoded gridsphere web app name).
   



Idea: Don't hard-code the app name, use ServletContext.getContextName
as needed instead.

 

   Great idea-- where can I find this method 
ServletContext.getContextName? It appears non-existent. There is a 
method ServletContext.getServletContextName() but that returns the 
description as defined in the web.xml and there is a 
ServletConfig.getServletName() but that returns the servlet name, I need 
a method that will give me the web application name programatically. 
Previously I've used getServletPath("") and parse out the last file 
separation character but it seems kind of hackish.



Suggestion: Don't file this as a bug or feature enhancement, it's not
likely to change, as many of us see this as an improvement in
enforcement and convention over 5.0.

 

   Hmm, can you tell me where this convention is defined anywhere? This 
is not just a problem for my portal but a few others out there that have 
presented instructions that no longer work. If say three portal projects 
including Pluto and Jetspeed claim this is a problem can it be 
considered a bug?


   Thanks, Jason


Yoav

On 12/19/05, Jason Novotny <[EMAIL PROTECTED]> wrote:
 


Hi Yoav,

   I tried the context without the Logger element and unfortunately it
still does not work. Based on some other responses I received it seems
there are only two options to modify the context of my webapp from
http://localhost:8080/gridsphere to http://localhost:8080/portal:

1) copy "gridsphere.xml" containing my context fragment to "portal.xml"
AND rename the webapplication from "gridsphere" to "portal". (It's the

2) Create a context like this:



where the web application is then moved outside of the Tomcat webapps/
directory. I don't want to do this either since for the same reasons as
1, I reference some files using the hardcoded gridsphere web app directory.


   Thanks for your time, Jason



Yoav Shapira wrote:

   


Hi,



 



 



   


Loggers are gone and invalid in 5.5.  A similar context.xml fragment
without the Logger sub-element works fine for me in 5.5.12.

Yoav

--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com

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




 

   




--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com

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


 




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

Re: TC 5.5.12 WARNING: A docBase XXX inside the host appBase has been specified, and will be ignored

[Yoav Shapira]

Hi,

> PS: Question to the developers: I'd like to have a  without
> appBase (only 1 app and outside) - is this supported?

AFAIK, no: a Host must have an appBase, explicitly or implicitly.

Yoav

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

Re: TC 5.5.12 WARNING: A docBase XXX inside the host appBase has been specified, and will be ignored

[Yoav Shapira]

Hi,

> Great idea-- where can I find this method
> ServletContext.getContextName? It appears non-existent. There is a
> method ServletContext.getServletContextName()

That's the method I meant, but I'd forgotten it returns the
description and not the name.  getServletPath("") is a hack as you
noted, and also will return null if running the app from a packaged
WAR, so it's not a good idea anyways.

Why is the app name hard-coded?  Can you get around the hard-coding
with ServletContext.getResource-type calls, which run off the docBase
by default?

> Hmm, can you tell me where this convention is defined anywhere? This
> is not just a problem for my portal but a few others out there that have
> presented instructions that no longer work.

It wouldn't be a bad idea to update the instructions for 5.5, e.g. by
taking out the Logger element, if it is present.

> If say three portal projects including Pluto and Jetspeed claim this is a 
> problem can it be
> considered a bug?

If they explain their desired functionality exactly, we can certainly
discuss it further.  I still wouldn't call it a bug because it's
functioning as designed for 5.5 (as noted previously, this is slightly
different from 5.0).

--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com

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

Re: Tomcat 6 plans (JSP 2.1)

[Yoav Shapira]

Hi,
Replying to three messages n one: see inline.

> Besides adding support for Servlet 2.5 which does not seem too
> overwhelming, most of the specification work is on support of JSP 2.1.

My observation as well.

> am happy to report that Jacob Hookom is willing to contribute code to
> add the necessary JSP support in Tomcat (he has done such an
> implementation already, and owns the copyright on that code).

Excellent, glad to hear it.

> For testing the implementation, Jacob is going to need access to the JSP
> 2.1 TCK (I suppose he'll need to be a committer to do that, but it
> should be ok by then).

I have access to the Servlet and JSP TCKs (current versions 2.4 and
2.0 respectively, but once the 2.5 and 2.1 are available, those as
well), and can help in this regard.

> Comments ?

Let's get cracking after 5.5.15.

Bill Barker said:
> We'll have to get access to the TCK ourselves first ;-).

"We" loosely defined as current Tomcat committers, already do.  You
need to send Geir Magnusson <[EMAIL PROTECTED]> (in his capacity as the
Apache JCP coordinator) an email saying you want access to the TCKs
relevant to Tomcat, and he'll set you up.

Keith Wannamaker said:
>There was some talk of merging the modules in 6, is there any
objection to that?

No objection, I don't think, but uncertainty as to which modules to
combine and into what SVN structure.

Yoav

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

Re: TC 5.5.12 WARNING: A docBase XXX inside the host appBase has been specified, and will be ignored

[Remy Maucherat]

Jason Novotny wrote:
   Hmm, can you tell me where this convention is defined anywhere? This 
is not just a problem for my portal but a few others out there that have 
presented instructions that no longer work. If say three portal projects 
including Pluto and Jetspeed claim this is a problem can it be 
considered a bug?


If you don't like it, you'll have to use a different container.

Rémy

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

RE: Tomcat 6 plans (JSP 2.1)

[jacob]

The EL implementation that I would be rolling in was one I wrote for the
JSP-EG/WebTier alignment and was licensed within Sun's Glassfish server
and used within Sun's Facelets technology for JavaServer Faces.  It's a
complete depart from commons-el in implementation and optimized for
expression serialization and some of the new EL-API concerns.

-- Jacob

Bill Barker <[EMAIL PROTECTED]> wrote on 12/20/2005, 09:51:18 PM:
>  
> 
> > -Original Message-
> > From: Remy Maucherat [mailto:[EMAIL PROTECTED] 
> > Sent: Tuesday, December 20, 2005 12:32 PM
> > To: dev@tomcat.apache.org
> > Subject: Tomcat 6 plans (JSP 2.1)
> > 
> > Hi,
> > 
> > Besides adding support for Servlet 2.5 which does not seem too 
> > overwhelming, most of the specification work is on support of 
> > JSP 2.1. I 
> > am happy to report that Jacob Hookom is willing to contribute code to 
> > add the necessary JSP support in Tomcat (he has done such an 
> > implementation already, and owns the copyright on that code). To host 
> > the code, a new branch is going to be needed for Jasper (as well as a 
> > new folder in servletapi).
> > 
> 
> Does this mean that we'll be hosting EL?  IMHO, resurrecting commons-el to
> bring it up to JSP 2.1 was always going to be the hardest part of TC 6.  
> 
> I agree that the changes for Servlet 2.5 aren't that bad, but we might as
> well branch Container while we are at it.
> 
> > For testing the implementation, Jacob is going to need access 
> > to the JSP 
> > 2.1 TCK (I suppose he'll need to be a committer to do that, but it 
> > should be ok by then).
> > 
> 
> We'll have to get access to the TCK ourselves first ;-).  
> 
> > Comments ?
> > 
> > Rémy
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> > 
> 
> 
> 
> 
> This message is intended only for the use of the person(s) listed above as 
> the intended recipient(s), and may contain information that is PRIVILEGED and 
> CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, 
> or distribute this message or any attachment. If you received this 
> communication in error, please notify us immediately by e-mail and then 
> delete all copies of this message and any attachments.
> 
> 
> 
> In addition you should be aware that ordinary (unencrypted) e-mail sent 
> through the Internet is not secure. Do not send confidential or sensitive 
> information, such as social security numbers, account numbers, personal 
> identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

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

Re: TC 5.5.12 WARNING: A docBase XXX inside the host appBase has been specified, and will be ignored

[Remy Maucherat]

Yoav Shapira wrote:

If they explain their desired functionality exactly, we can certainly
discuss it further.  I still wouldn't call it a bug because it's
functioning as designed for 5.5 (as noted previously, this is slightly
different from 5.0).


The point was to remove redundant information to make the deployer 
reasonably robust. People can develop a new deployer (and associated 
manager webapp) with more capabilities if they want to, but I am -1 for 
touching the behavior of the current one in this area, since it will 
cause it to revert to broken 5.0.x behavior.


Rémy

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

RE: TC 5.5.12 WARNING: A docBase XXX inside the host appBase has been specified, and will be ignored

[Rasmus - Camp Online]

Does anyone know how to unsbubscribe from this list? I have sent 20 mails to  
[EMAIL PROTECTED], but nothing helps!



-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED] 
Sent: 20. december 2005 22:41
To: Tomcat Developers List
Subject: Re: TC 5.5.12 WARNING: A docBase XXX inside the host appBase has been 
specified, and will be ignored

Yoav Shapira wrote:
> If they explain their desired functionality exactly, we can certainly 
> discuss it further.  I still wouldn't call it a bug because it's 
> functioning as designed for 5.5 (as noted previously, this is slightly 
> different from 5.0).

The point was to remove redundant information to make the deployer reasonably 
robust. People can develop a new deployer (and associated manager webapp) with 
more capabilities if they want to, but I am -1 for touching the behavior of the 
current one in this area, since it will cause it to revert to broken 5.0.x 
behavior.

Rémy

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


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

DO NOT REPLY [Bug 29108] - "chunked" transfer-encoding is not working

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29108





--- Additional Comments From [EMAIL PROTECTED]  2005-12-20 23:52 ---
(In reply to comment #5)
> This bug tracking system is the place to look into for getting the fixed 
> release.
No it isn't. The change log is the definitive source for matching bug fixes
against releases.

> Closed bugs must contain a fixed release comment or attribute.
Whilst committers do endeavour to do this when they commit a fix, there is no
policy within the Tomcat project that states that this must occur.

> Not everyone has the knowledge to drill down hundred of files in CVS to look 
> for
> some unknown comment. Thanks you for your comprehension.
It is not necessary to use the source repository (which, for the record, is now
in SVN rather than CVS). Again, look at the change log. (Hint: look at the log
for 5.0.x rather than 5.5.x as this bug was fixed quite some time ago).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 21440] - whose target performs a 'forward' does not behave as expected

[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://issues.apache.org/bugzilla/show_bug.cgi?id=21440


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-12-21 00:11 ---
I have just taken a closer look at the remaining issues and the behaviour seen
is as expected. The use of newlines and "***2***" etc in the test jsps was
causing output to be written after the response had been committed. With all the
superfluous output removed, the test cases behaved as expected. Specifically:
- for 4.1.x and 5.5.x console messages are displayed with ForwardServlet
- for 4.1.x and 5.5.x the IlegalStateException is thrown for test case 2

The exceptions Jan referred to in comment #3 no longer appear.

The additional warnings in 5.5.x are just that. The response has been committed
so trying to flush the buffer on the release of the PageContext fails. This is
expected.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Tomcat 6 plans (JSP 2.1)

[Tim Funk]

+0

(+1 - if I can realign my day job duties to free up time to help more :( )

-Tim

Remy Maucherat wrote:

Hi,

Besides adding support for Servlet 2.5 which does not seem too 
overwhelming, most of the specification work is on support of JSP 2.1. I 
am happy to report that Jacob Hookom is willing to contribute code to 
add the necessary JSP support in Tomcat (he has done such an 
implementation already, and owns the copyright on that code). To host 
the code, a new branch is going to be needed for Jasper (as well as a 
new folder in servletapi).


For testing the implementation, Jacob is going to need access to the JSP 
2.1 TCK (I suppose he'll need to be a committer to do that, but it 
should be ok by then).


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

DO NOT REPLY [Bug 37984] New: - JNDIRealm.java not able to handle MD5 password

[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://issues.apache.org/bugzilla/show_bug.cgi?id=37984

   Summary: JNDIRealm.java not able to handle MD5 password
   Product: Tomcat 5
   Version: 5.5.12
  Platform: Other
OS/Version: other
Status: NEW
  Keywords: PatchAvailable
  Severity: normal
  Priority: P3
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I'm using JNDIRealm to authenticate to OpenLDAP 2.2.28.  Within OpenLDAP I've
configured the userPassword attribute for each user to contain the MD5 digest,
and each is prefixed with the string "{MD5}".  I am not an LDAP expert by any
means but I believe this prefix is a standard convention.  Anyway assuming this
is a convention then JNDIRealm needs to strip off the "{MD5}" portion much like
it does with "{SHA1}".  See attached patch which accomplishes this and I
verified it works in my environment.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 37984] - JNDIRealm.java not able to handle MD5 password

[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://issues.apache.org/bugzilla/show_bug.cgi?id=37984





--- Additional Comments From [EMAIL PROTECTED]  2005-12-21 05:52 ---
Created an attachment (id=17249)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17249&action=view)
Handle password digests that are prefixed with "{MD5}".


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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