Re: svn commit: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:

Author: fhanik
Date: Mon Nov 20 08:47:03 2006
New Revision: 477251

URL: http://svn.apache.org/viewvc?view=rev&rev=477251
Log:
TCK correction, depending on the sequence of the tests, the converter turns out 
to be null at certain times.
Added in a check to create the converter even when getting the output stream.


I have to veto this. It's using the output stream in that case, so why 
does it matter if the converter (= the character encoder) is null ?


Rémy

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

DO NOT REPLY [Bug 40877] - JK1 and IIS6: Problem with multithreading / shared memory

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





--- Additional Comments From [EMAIL PROTECTED]  2006-11-21 17:46 ---
Hi Bjoern Andersen,

The problem is very intermittent and we can't replicate it when we want to. It 
would happen may be once a day, not necessarily but most probably around the 
time when the application pool recycles itself. One website using JK stops 
working and no matter what we do (except IISRESET), it wouldn't come up 
throwing 404.2 and 404.3 errors.

I don't have any idea as when the patch would be released. I am more than 
willing to test it as soon as it is released. In the mean time while Mladen is 
doing the good work to release patch for JK 1.2.19 for win32, What I am 
thinking is to roll back to JK 1.2.15 since this bug is affecting our 
production environment. Do you know by any chance if the version JK 1.2.15 is 
more stable and doesn't have the shared memory bug. What version of JK would 
you suggest to roll back to?

-- 
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 41007] - Can't define customized 503 error page

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-11-20 13:48 ---
Bugzilla is not the forum to ask questions. Please post your question to the
Tomcat users mailing list.

-- 
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: r477127 - /tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh

[jfclere]

Author: jfclere
Date: Mon Nov 20 01:59:36 2006
New Revision: 477127

URL: http://svn.apache.org/viewvc?view=rev&rev=477127
Log:
Oops. The files should not be removed. Other for example make install will fail.

Modified:
tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh

Modified: tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh?view=diff&rev=477127&r1=477126&r2=477127
==
--- tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh (original)
+++ tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh Mon Nov 20 
01:59:36 2006
@@ -88,9 +88,4 @@
 mv $TARGETDIR/$DLNAME $TARGETDIR/$TARGET_NAME
 fi
 
-rm -f $TARGETDIR/$DSOARCHIVE_BASENAME
-rm -f $TARGETDIR/$DSOBASE.a
-rm -f $TARGETDIR/lib$DSOBASE.a
-rm -f $TARGETDIR/lib$TARGET_NAME
-
 exit 0



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

DO NOT REPLY [Bug 41008] New: - POST request ignores command line parameters

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

   Summary: POST request ignores command line parameters
   Product: Tomcat 5
   Version: 5.5.20
  Platform: PC
OS/Version: Windows Server 2003
Status: NEW
  Severity: normal
  Priority: P5
 Component: Servlets:CGI
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


example:


this code does invoke the test.exe without passing the test1 command line 
parameter

the example works in apache httpd and ms iis

fix:

CGIServlet.java

   if (!"GET".equals(req.getMethod()) && 
!"POST".equals(req.getMethod()) &&
!"HEAD".equals(req.getMethod()))
return;

-- 
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 41011] New: - duplicate class definition error when JSPs loaded from multiple threads

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

   Summary: duplicate class definition error when JSPs loaded from
multiple threads
   Product: Tomcat 5
   Version: 5.5.17
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


After switching to a client configuration where two JSP pages are loaded
simultaneously, I started getting LinkageErrors 10-20% of the time after
restarting Tomcat.  By passing -verbose:class to the JVM, I discovered that:

1. If the JSP classes and their dependencies are loaded one at a time,
everything is fine.

2. If the same classes are loaded concurrently in different threads, some of the
dependencies may be loaded twice.  In this case the -verbose:class output shows
a class loaded twice from the same location.

This tends to happen to me with the Struts Tiles classes, which are used by both
JSPs.  The first JSP starts loading its classes:

[Loaded org.apache.jsp.WEB_002dINF.include.xxx.pages.sidebar_jsp from
file:/xxx/catalina-base/work/Catalina/localhost/_/]
[Loaded org.apache.struts.taglib.tiles.PutTagParent from
file:/xxx/repository/struts/struts/1.2.9/struts-1.2.9.jar]
[Loaded org.apache.struts.taglib.tiles.PutListTagParent from
file:/xxx/repository/struts/struts/1.2.9/struts-1.2.9.jar]
...

The second JSP starts loading before the first finishes:

[Loaded org.apache.jsp.WEB_002dINF.include.xxx.pages.welcome_jsp from
file:/xxx/catalina-base/work/Catalina/localhost/_/]
[Loaded org.apache.struts.taglib.tiles.InsertTag$InsertHandler from
file:/xxx/repository/struts/struts/1.2.9/struts-1.2.9.jar]

One of the Tiles classes ends up being loaded twice:

[Loaded org.apache.struts.taglib.tiles.PutTag from
file:/xxx/repository/struts/struts/1.2.9/struts-1.2.9.jar]
[Loaded org.apache.struts.taglib.tiles.PutTag from
file:/xxx/repository/struts/struts/1.2.9/struts-1.2.9.jar]

The second JSP pages fails to render:

2006-11-21 11:32:49,617 [http-8080-Processor3] ERROR
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/].[jsp] -
Servlet.service() for servlet jsp threw exception
java.lang.LinkageError: duplicate class definition:
org/apache/struts/taglib/tiles/PutTag
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:880)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1319)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1198)
at 
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:127)
at 
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:65)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at
org.apache.jsp.WEB_002dINF.include.xxx.pages.welcome_jsp._jspx_meth_tiles_put_0(welcome_jsp.java:135)
at
org.apache.jsp.WEB_002dINF.include.xxx.pages.welcome_jsp._jspx_meth_tiles_insert_0(welcome_jsp.java:109)
at
org.apache.jsp.WEB_002dINF.include.xxx.pages.welcome_jsp._jspService(welcome_jsp.java:79)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at
org.apache.catalina.core.ApplicationDispatcher.doForwar

Re: [VOTE] Tomcat 6.0.2

[Filip Hanik - Dev Lists]

I'd prefer a 6.0.3, also due to a bug fix in the NIO connector (not 
picking up keystore password properly, or was this 6.0.1), but I'm not 
gonna hold back the 6.0.2 going beta by any means.


Filip

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

My alpha vote stands,
there are a few bug fixes I added to 6.0.2:
-output stream using the C2B converter


It is not a regression, the same code (and associated minor issue) 
exists in 5.5.


-ApplicationDispatcher.checkSameObjects wasn't checking the root of 
the request/response that were last serviced


This code is not used by default (it requires using the strict flag).


-DBCP wouldn't even build with jdk1.5


It works for me: I use JDK 1.5 without any problems, for whatever reason.

To me, beta is when you can build, and we have addressed most known 
defects, but the build issue is pretty big, a beta should build 
straight from SVN


As all three issues are minor, I have to disagree with this. I suppose 
if you look for long enough, you'll find some issues, but this is not 
going to be adequate testing, while it will delay real testing.


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: [Proposal] Change in behaviour of uriworkermap.properties

[Jean-frederic Clere]

On Tue, 2006-11-21 at 06:52 +0100, Mladen Turk wrote:
> Rainer Jung wrote:
> > 
> > E.g. if one empties the uriworkermap.properties, reloading it does not
> > change the internal mount list. Temporarily adding and later removing an
> > entry will not remove the entry.
> 
> That's the entire point.
> Once new entry is added it will be there for the server lifetime.
> Of course it can be disabled with minus prefix.
> 
> If one adds the mount point and then deletes it, other child
> processes might not pick that up, but that's not how they
> suppose to work. "Deletion" *must* be done only by prefixing
> the mount points with minus.
> I'm not even sure why I allow to have the new mounts at
> the first place.
> 
> > One could live with that (after we
> > improve the docs).
> > 
> 
> Sure. The entire idea of reloading a uriworkermap.properties
> was to temporary disable some pre-existing mount.
> 
> Anything else should be handled via graceful restart.
> BTW, this was added only to help the IIS that doesn't have
> the graceful restart concept.
> 
> 
> I don't like the idea of splitting the static and dynamic
> mount points.
> The proper way to go would be to add the second shared memory
> (database like) that would contain the mount points with
> options to manage that via jkstatus. Anything else IMHO is
> useless, because it can be done via simple restart, if one
> needs to add/remove the whole bunch of new mounts in frequent
> way.

Yep. Static configuration is just a dynamic configuration that never
changes. The right way to go is to have the configuration in shared
memory the complex stuff is how to update it.
I am trying to get something similar to work on mod_proxy and I need an
external process to update the shared memory.

Cheers

Jean-Frederic

> 
> 
> Regards,
> Mladen.
> 
> -
> 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: [VOTE] Tomcat 6.0.2

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

My alpha vote stands,
there are a few bug fixes I added to 6.0.2:
-output stream using the C2B converter


It is not a regression, the same code (and associated minor issue) 
exists in 5.5.


-ApplicationDispatcher.checkSameObjects wasn't checking the root of the 
request/response that were last serviced


This code is not used by default (it requires using the strict flag).


-DBCP wouldn't even build with jdk1.5


It works for me: I use JDK 1.5 without any problems, for whatever reason.

To me, beta is when you can build, and we have addressed most known 
defects, but the build issue is pretty big, a beta should build straight 
from SVN


As all three issues are minor, I have to disagree with this. I suppose 
if you look for long enough, you'll find some issues, but this is not 
going to be adequate testing, while it will delay real testing.


Rémy

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

Re: [VOTE] Tomcat 6.0.2

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
I'd prefer a 6.0.3, also due to a bug fix in the NIO connector (not 
picking up keystore password properly, or was this 6.0.1), but I'm not 
gonna hold back the 6.0.2 going beta by any means.


Ok, but releasing a 6.0.3 as a beta would take about 10 more days, and 
the benefit would not be that great. Actually, we can do a 6.0.3 release 
quite soon, even if 6.0.2 is released as a beta.


Rémy

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

Re: [Proposal] Change in behaviour of uriworkermap.properties

[Rainer Jung]

Jean-frederic Clere schrieb:
> On Tue, 2006-11-21 at 06:52 +0100, Mladen Turk wrote:
>> Rainer Jung wrote:
>>> E.g. if one empties the uriworkermap.properties, reloading it does not
>>> change the internal mount list. Temporarily adding and later removing an
>>> entry will not remove the entry.
>> That's the entire point.

But this is not what a user expects from a change in a list.

>> Once new entry is added it will be there for the server lifetime.
>> Of course it can be disabled with minus prefix.
>>
>> If one adds the mount point and then deletes it, other child
>> processes might not pick that up, but that's not how they
>> suppose to work. "Deletion" *must* be done only by prefixing
>> the mount points with minus.
>> I'm not even sure why I allow to have the new mounts at
>> the first place.

OK, but you did. And my proposal comes in, because I want to fix this
behaviour exactly becauswe of the case, are adding and deleting rules.

>>
>>> One could live with that (after we
>>> improve the docs).
>>>
>> Sure. The entire idea of reloading a uriworkermap.properties
>> was to temporary disable some pre-existing mount.

I understand, but it can be used in a much more powerful way.
It's an external file with an easy syntax, so external monitor and
manage scripts can easily manipulate it's contents.

>>
>> Anything else should be handled via graceful restart.
>> BTW, this was added only to help the IIS that doesn't have
>> the graceful restart concept.

Graceful restarts can produce hanging processes under heavy load. You'll
notice slots in state "G" or "L" in the server-status.

>> I don't like the idea of splitting the static and dynamic
>> mount points.
>> The proper way to go would be to add the second shared memory
>> (database like) that would contain the mount points with
>> options to manage that via jkstatus. Anything else IMHO is
>> useless, because it can be done via simple restart, if one
>> needs to add/remove the whole bunch of new mounts in frequent
>> way.
> 
> Yep. Static configuration is just a dynamic configuration that never
> changes. The right way to go is to have the configuration in shared
> memory the complex stuff is how to update it.
> I am trying to get something similar to work on mod_proxy and I need an
> external process to update the shared memory.

That using shared memory to share the mapping rules and the changes is
what I wrote too. And I will investigate this further. My suggestion is
to make the current behaviour of uriworkermap.properties reloading
easier to understand for the users. This is something I can easily do
for the next release. Handling the rules via shared memory would
definitely have to wait at least for one more release.

> 
> Cheers
> 
> Jean-Frederic
> 
>>
>> Regards,
>> Mladen.
>>

Regards,

Rainer

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

Re: findAncestorWithClass in a tag, used in a tag-file

[Michiel Meeuwissen]

Michiel Meeuwissen wrote:
> Hello.
> 
> I notice that in tomcat 5.5.20, in contradiction to tomcat 5.5.17, the
> findAncestorWithClass method of a Tag now also looks outside the tag-file,
> if the tag is used in a tag-file. So, if you use a tag implemented by a
> tag-file inside some tag, and inside the file of the tag-file you use a tag
> which uses 'findAncestorByClass' it can now see the tag in which the tag of
> the tag-file was used.
> 
> Since this breaks the functionality of tag-library I'm maintaining I was
> wondering if this was an intentional change, and whether the current
> behaviour or the previous one was correct. It's not clear to me from at
> least the javadoc of Tag.

The difference is also clear from the generated .java code for such a
tag-file.

5.5.20:
   _jspx_th_mm_import_0.setParent(new 
javax.servlet.jsp.tagext.TagAdapter((javax.servlet.jsp.tagext.SimpleTag) this 
));
5.5.17:
  _jspx_th_mm_import_0.setParent(null);

Does anybody know which class does generate this code? I may want to look
in the history of that, for a clue why it was actually changed.

Anyhow, the current opinion seems to be that the parent of a tag in a
tag-file is the tag which is implemented by this tag-file. Correct?


Michiel


-- 
Michiel Meeuwissen  mihxil'
Peperbus 107 MediaPark H'sum  []()
+31 (0)35 6772979 nl_NL eo_XX en_US

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

Re: findAncestorWithClass in a tag, used in a tag-file

[Michiel Meeuwissen]

Michiel Meeuwissen wrote:
> Michiel Meeuwissen wrote:
> > Hello.
> > 
> > I notice that in tomcat 5.5.20, in contradiction to tomcat 5.5.17, the
> > findAncestorWithClass method of a Tag now also looks outside the tag-file,
> > if the tag is used in a tag-file. So, if you use a tag implemented by a
> > tag-file inside some tag, and inside the file of the tag-file you use a tag
> > which uses 'findAncestorByClass' it can now see the tag in which the tag of
> > the tag-file was used.
> > 
> > Since this breaks the functionality of tag-library I'm maintaining I was
> > wondering if this was an intentional change, and whether the current
> > behaviour or the previous one was correct. It's not clear to me from at
> > least the javadoc of Tag.
> 
> The difference is also clear from the generated .java code for such a
> tag-file.
> 
> 5.5.20:
>_jspx_th_mm_import_0.setParent(new 
> javax.servlet.jsp.tagext.TagAdapter((javax.servlet.jsp.tagext.SimpleTag) this 
> ));
> 5.5.17:
>   _jspx_th_mm_import_0.setParent(null);
> 
> Does anybody know which class does generate this code? I may want to look
> in the history of that, for a clue why it was actually changed.
> 
> Anyhow, the current opinion seems to be that the parent of a tag in a
> tag-file is the tag which is implemented by this tag-file. Correct?


Ah,  it is bug 31804. Hmm.

Michiel


-- 
Michiel Meeuwissen  mihxil'
Peperbus 107 MediaPark H'sum  []()
+31 (0)35 6772979 nl_NL eo_XX en_US

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

findAncestorWithClass in a tag, used in a tag-file

[Michiel Meeuwissen]

Hello.

I notice that in tomcat 5.5.20, in contradiction to tomcat 5.5.17, the
findAncestorWithClass method of a Tag now also looks outside the tag-file,
if the tag is used in a tag-file. So, if you use a tag implemented by a
tag-file inside some tag, and inside the file of the tag-file you use a tag
which uses 'findAncestorByClass' it can now see the tag in which the tag of
the tag-file was used.

Since this breaks the functionality of tag-library I'm maintaining I was
wondering if this was an intentional change, and whether the current
behaviour or the previous one was correct. It's not clear to me from at
least the javadoc of Tag.

Michiel



-- 
Michiel Meeuwissen  mihxil'
Peperbus 107 MediaPark H'sum  []()
+31 (0)35 6772979 nl_NL eo_XX en_US

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

Re: svn commit: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

[Filip Hanik - Dev Lists]

I figured :). I'll revert and hunt down the root cause. My guess is that 
if the response was used with output stream first, then recycled and 
then used again, somehow the conv ends up being null and causes a NPE in 
the write method.


Filip

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: fhanik
Date: Mon Nov 20 08:47:03 2006
New Revision: 477251

URL: http://svn.apache.org/viewvc?view=rev&rev=477251
Log:
TCK correction, depending on the sequence of the tests, the converter 
turns out to be null at certain times.
Added in a check to create the converter even when getting the output 
stream.


I have to veto this. It's using the output stream in that case, so why 
does it matter if the converter (= the character encoder) is null ?


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 40997] - JkMountFile directive fails to update after the uri mapping file is modified

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-11-21 02:52 ---
So I assume you are deleting the "!" in freont of the /bug maps to enable or
disable access to the /bug context.

The correct way is to use a minus sign "-" instead of an exclamation mark "!".

-XXX says: define a rule XXX and disable it (don't use it).
!XXX says: after you did the matching and you found a worker, go through all the
"!" rules, and if one of those matches for the same target worker, don't use the
original match, don't forward to tomcat

file change semantics without restart are: entries learnt from earlier versions
do not get deleted. The only way of manipulating old entries is adding or
removing a minus sign. Then they get disabled, or a previous disabled state is
turned into enable again.

You did:

!XXX: never use a mapping XXX. 1 rule loaded.

Change to XXX: use a mapping XXX, a second rule loaded. Now you have a rule XXX
that might match a request, but the check for exclusions afterwards still finds
the !XXX and negated the forward.

I suggest:

-XXX: Define a map XXX but disable it.

Change to XXX: Remove the disabling of XXX, ie. enable it.

If you want to be more secure, so that other rules will not be able to
accidentily map to /bug, you can also do:

!XXX
-XXX

and enable the context by changing to:

-!XXX
XXX

I'm closing this now. In case you don't understand, please proceed via the users
list. In case you are pretty sure, that there is still a bug, reopen with your
arguments. 

-- 
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 41007] - Can't define customized 503 error page

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





--- Additional Comments From [EMAIL PROTECTED]  2006-11-20 14:40 ---
I didn't find any question mark in my sentences, did you?

On the mailing list they say, it's hardcoded. It's surely no bug - but where can
I put feature requests then?

-- 
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: [Proposal] Change in behaviour of uriworkermap.properties

[Rainer Jung]

Henri Gomez schrieb:
> Why not just extends current jkstatus ?

Mapping rules are kept process local. They are only shared, because the
first process generates them and afterwards all other processes inherit
them during fork.

To make the rules manageable via jkstatus (everyone wants that, me too;
it's a much bigger task) we need to do two things:

- use shared memory at least to exchange information about changes to
maping rules, so that the process that handles the jkstatus request is
able to distribute the changes.

- also we need to think about virtual hosts: mapping rules are per
virtual host. At the moment, if you call jkstatus, you will only see the
rules defined for the virtual host, which you called with jkstatus. If
you want to have a central administration point, jkstatus must go
through all vhosts starting from the main server to produce the list,
and if you change something it might need to change it in a vhost that's
different from the vhost, the request runs in.

This is no argument, that it is very hard to make these changes. It's
simply not in scope for the next release, which should get ready in very
few days, because we had a couple of nice bug fixes since 1.2.19.

Regards,

Rainer

> 
> 2006/11/21, Rainer Jung <[EMAIL PROTECTED]>:
>> Jean-frederic Clere schrieb:
>> > On Tue, 2006-11-21 at 06:52 +0100, Mladen Turk wrote:
>> >> Rainer Jung wrote:
>> >>> E.g. if one empties the uriworkermap.properties, reloading it does
>> not
>> >>> change the internal mount list. Temporarily adding and later
>> removing an
>> >>> entry will not remove the entry.
>> >> That's the entire point.
>>
>> But this is not what a user expects from a change in a list.
>>
>> >> Once new entry is added it will be there for the server lifetime.
>> >> Of course it can be disabled with minus prefix.
>> >>
>> >> If one adds the mount point and then deletes it, other child
>> >> processes might not pick that up, but that's not how they
>> >> suppose to work. "Deletion" *must* be done only by prefixing
>> >> the mount points with minus.
>> >> I'm not even sure why I allow to have the new mounts at
>> >> the first place.
>>
>> OK, but you did. And my proposal comes in, because I want to fix this
>> behaviour exactly becauswe of the case, are adding and deleting rules.
>>
>> >>
>> >>> One could live with that (after we
>> >>> improve the docs).
>> >>>
>> >> Sure. The entire idea of reloading a uriworkermap.properties
>> >> was to temporary disable some pre-existing mount.
>>
>> I understand, but it can be used in a much more powerful way.
>> It's an external file with an easy syntax, so external monitor and
>> manage scripts can easily manipulate it's contents.
>>
>> >>
>> >> Anything else should be handled via graceful restart.
>> >> BTW, this was added only to help the IIS that doesn't have
>> >> the graceful restart concept.
>>
>> Graceful restarts can produce hanging processes under heavy load. You'll
>> notice slots in state "G" or "L" in the server-status.
>>
>> >> I don't like the idea of splitting the static and dynamic
>> >> mount points.
>> >> The proper way to go would be to add the second shared memory
>> >> (database like) that would contain the mount points with
>> >> options to manage that via jkstatus. Anything else IMHO is
>> >> useless, because it can be done via simple restart, if one
>> >> needs to add/remove the whole bunch of new mounts in frequent
>> >> way.
>> >
>> > Yep. Static configuration is just a dynamic configuration that never
>> > changes. The right way to go is to have the configuration in shared
>> > memory the complex stuff is how to update it.
>> > I am trying to get something similar to work on mod_proxy and I need an
>> > external process to update the shared memory.
>>
>> That using shared memory to share the mapping rules and the changes is
>> what I wrote too. And I will investigate this further. My suggestion is
>> to make the current behaviour of uriworkermap.properties reloading
>> easier to understand for the users. This is something I can easily do
>> for the next release. Handling the rules via shared memory would
>> definitely have to wait at least for one more release.
>>
>> >
>> > Cheers
>> >
>> > Jean-Frederic
>> >
>> >>
>> >> Regards,
>> >> Mladen.
>> >>
>>
>> Regards,
>>
>> Rainer
>>
>> -
>> 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]

-
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  11/22/2006 and will not return until
11/23/2006.



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

Re: [Proposal] Change in behaviour of uriworkermap.properties

[Henri Gomez]

JkMount shouldn't be affected by any automatic reloading to preserve
compatibility.

The new mounts via uriworkermap.properties chould be considered
transient, ie they could follow the file change but did the 60s isn't
too long is some circumstance ?

I think it will be better to make the Routing administration via some
basic HTML pages where the admin click the 'action' button and know
when the new rules are applied.



2006/11/20, Rainer Jung <[EMAIL PROTECTED]>:

Hello,

I would like to change the detailed behaviour of uriworkermap.properties
(JkMountFile) in mod_jk in a non-compatible way. The reason is a problem
I found with the momentary implementation plus the impression, that the
actual behaviour in detail is a little strange.

I'm interested in opinions about that.

1) Old situation

Entries in uriworkermap.properties are read during startup. They are
added to mount defined by other means (JkMount and mount attribute in
worker.properties and JkWorkerProperty).

When the file has been changed and some time went by (60 seconds after
reading it last) the next request will trigger a new read of the file.

Now only entries, that did not exist before, are being added to the
internal mount list. To "remove" an entry from the internal list, one
needs to add a minus sign in front of an existing entry.

E.g. if one empties the uriworkermap.properties, reloading it does not
change the internal mount list. Temporarily adding and later removing an
entry will not remove the entry. One could live with that (after we
improve the docs).

2) Problem

During runtime this means, that the actual mount list consists of a
continuous overlay of multiple versions of uriworkermap.properties.
Unfortunately each web server process does this on it's own, it's not
shared data. Now if a process doesn't get any requests, it will not
detect a changed version of the file and may miss the reading=adding of
entries. Other processes might get requests and do the reloading. If the
files is being changed again and later on all of the processes get
requests, the internal mount list of the various processes will begin to
differ. As a result the correct forwarding of requests will depend on
the process that handles the request, which is out of control of the
user/admin etc.

3) Proposed new situation

I would like to distinguish the mounts loaded from
uriworkermap.properties (=dynamic) internally from other mounts, like
JkMount, mount attribute in workers.properties and via JkWorkerProperty
(=static). If the uriworkermap.properties file changes, the process will
delete all dynamic mounts and completely reload them from the file.

That way each process does have a consistent internal state, reflecting
the state of the config files, at least whenever the 60 seconds have passed.

It would be nice to use the shared memory segment as an intermediate to
handle the reloading. But as long as all actions in the processes are
only triggered by requests, in the old model this would only help, if we
also exchange the maps via the shared memory. This change would be much
more delicate. So I would prefer an easier change by simply marking the
map entries internally.

The important thing is: afer the change the feature would behave
differently, but I must confess: every user I met first expected the
behaviour I suggest here. Everyone thought the old behaviour is exotic.

Comments?

Rainer

-
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 41007] - Can't define customized 503 error page

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





--- Additional Comments From [EMAIL PROTECTED]  2006-11-20 15:00 ---
I assumed there was an implied question "How do I set a global 503 error page?".

The reply to your post on the users list points you towards how to customise
this to use your own page.

-- 
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]

Getting StandardServer's NamingContext?

[Daniel Santos]

Is there a better way to get StandardServer's NamingContext than this?  I'm
writing a custom realm and I need some puggable resources (I'm using
GlobalNamingResources to configure these, it's the cleanest way I could come
up with)

// code is from a RealmBase-derived class start() method

Container c;
for(c = this.container; c.getParent() != null; c = c.getParent());

if(!(c instanceof Service)) {
throw new SomeException("Can't find my Service, that's wierd.");
}

Service service = (Service)c;
StandardServer server = (StandardServer)service.getServer();
for(LifecycleListener ll : server.findLifecycleListeners()) {
if(ll instanceof NamingContextListener) {
rootNamingContext = ((NamingContextListener)ll).getNamingContext();
}
}

Thanks,
Daniel

-- 
View this message in context: 
http://www.nabble.com/Getting-StandardServer%27s-NamingContext--tf2679812.html#a7474313
Sent from the Tomcat - Dev mailing list archive at Nabble.com.


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

DO NOT REPLY [Bug 41007] - Can't define customized 503 error page

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|major   |enhancement
 Status|RESOLVED|REOPENED
  Component|Unknown |Catalina
 OS/Version|other   |All
   Platform|Other   |All
 Resolution|INVALID |
Version|5.0.16  |5.5.20




--- Additional Comments From [EMAIL PROTECTED]  2006-11-20 15:14 ---
To register this an enhancement request, I have re-opened this issue and set the
severity to enhancement. I also set a few other attributes.

Why is it like this? The current approach works and no one has felt the need to
change it.

Obviously, enhancement requests with patches that implement them are more likely
to make it into the codebase.

-- 
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: r477737 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java

[fhanik]

Author: fhanik
Date: Tue Nov 21 08:35:19 2006
New Revision: 477737

URL: http://svn.apache.org/viewvc?view=rev&rev=477737
Log:
Fix the logic of the checkSameObjects method.
The method did not take into account that the lastServiceRequest/Response could 
be wrapped themselves.


Modified:

tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java?view=diff&rev=477737&r1=477736&r2=477737
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java 
Tue Nov 21 08:35:19 2006
@@ -969,10 +969,8 @@
 }
 
 private void checkSameObjects() throws ServletException {
-ServletRequest originalRequest =
-ApplicationFilterChain.getLastServicedRequest();
-ServletResponse originalResponse =
-ApplicationFilterChain.getLastServicedResponse();
+ServletRequest originalRequest = 
ApplicationFilterChain.getLastServicedRequest();
+ServletResponse originalResponse = 
ApplicationFilterChain.getLastServicedResponse();
 
 // Some forwards, eg from valves will not set original values 
 if (originalRequest == null || originalResponse == null) {
@@ -982,41 +980,47 @@
 boolean same = false;
 ServletRequest dispatchedRequest = appRequest;
 
+//find the bottom most request, the one that was passed into the 
service method
+while ( originalRequest instanceof ServletRequestWrapper && 
((ServletRequestWrapper) originalRequest).getRequest()!=null ) {
+originalRequest = ((ServletRequestWrapper) 
originalRequest).getRequest();
+}
+//compare with the dispatched request
 while (!same) {
 if (originalRequest.equals(dispatchedRequest)) {
 same = true;
 }
 if (!same && dispatchedRequest instanceof ServletRequestWrapper) {
-dispatchedRequest =
-((ServletRequestWrapper) dispatchedRequest).getRequest();
+dispatchedRequest = ((ServletRequestWrapper) 
dispatchedRequest).getRequest();
 } else {
 break;
 }
 }
 if (!same) {
-throw new ServletException(sm.getString(
-"applicationDispatcher.specViolation.request"));
+throw new 
ServletException(sm.getString("applicationDispatcher.specViolation.request"));
 }
 
 same = false;
 ServletResponse dispatchedResponse = appResponse;
 
+//find the bottom most response, the one that was passed into the 
service method
+while ( originalResponse instanceof ServletResponseWrapper && 
((ServletResponseWrapper) originalResponse).getResponse()!=null ) {
+originalResponse = ((ServletResponseWrapper) 
originalResponse).getResponse();
+}
+//compare with the dispatched response
 while (!same) {
 if (originalResponse.equals(dispatchedResponse)) {
 same = true;
 }
 
 if (!same && dispatchedResponse instanceof ServletResponseWrapper) 
{
-dispatchedResponse =
-((ServletResponseWrapper) 
dispatchedResponse).getResponse();
+dispatchedResponse = ((ServletResponseWrapper) 
dispatchedResponse).getResponse();
 } else {
 break;
 }
 }
 
 if (!same) {
-throw new ServletException(sm.getString(
-"applicationDispatcher.specViolation.response"));
+throw new 
ServletException(sm.getString("applicationDispatcher.specViolation.response"));
 }
 }
 }



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

Re: [Proposal] Change in behaviour of uriworkermap.properties

[Jean-frederic Clere]

On Tue, 2006-11-21 at 11:58 +0100, Rainer Jung wrote:
> Henri Gomez schrieb:
> > Why not just extends current jkstatus ?
> 
> Mapping rules are kept process local. They are only shared, because the
> first process generates them and afterwards all other processes inherit
> them during fork.
> 
> To make the rules manageable via jkstatus (everyone wants that, me too;
> it's a much bigger task) we need to do two things:
> 
> - use shared memory at least to exchange information about changes to
> maping rules, so that the process that handles the jkstatus request is
> able to distribute the changes.
> 
> - also we need to think about virtual hosts: mapping rules are per
> virtual host. At the moment, if you call jkstatus, you will only see the
> rules defined for the virtual host, which you called with jkstatus. If
> you want to have a central administration point, jkstatus must go
> through all vhosts starting from the main server to produce the list,
> and if you change something it might need to change it in a vhost that's
> different from the vhost, the request runs in.
> 
> This is no argument, that it is very hard to make these changes. It's
> simply not in scope for the next release, which should get ready in very
> few days, because we had a couple of nice bug fixes since 1.2.19.

May be that is time to make a new branch: 1.3 for example ;-)

Cheers

Jean-Frederic

> 
> Regards,
> 
> Rainer
> 
> > 
> > 2006/11/21, Rainer Jung <[EMAIL PROTECTED]>:
> >> Jean-frederic Clere schrieb:
> >> > On Tue, 2006-11-21 at 06:52 +0100, Mladen Turk wrote:
> >> >> Rainer Jung wrote:
> >> >>> E.g. if one empties the uriworkermap.properties, reloading it does
> >> not
> >> >>> change the internal mount list. Temporarily adding and later
> >> removing an
> >> >>> entry will not remove the entry.
> >> >> That's the entire point.
> >>
> >> But this is not what a user expects from a change in a list.
> >>
> >> >> Once new entry is added it will be there for the server lifetime.
> >> >> Of course it can be disabled with minus prefix.
> >> >>
> >> >> If one adds the mount point and then deletes it, other child
> >> >> processes might not pick that up, but that's not how they
> >> >> suppose to work. "Deletion" *must* be done only by prefixing
> >> >> the mount points with minus.
> >> >> I'm not even sure why I allow to have the new mounts at
> >> >> the first place.
> >>
> >> OK, but you did. And my proposal comes in, because I want to fix this
> >> behaviour exactly becauswe of the case, are adding and deleting rules.
> >>
> >> >>
> >> >>> One could live with that (after we
> >> >>> improve the docs).
> >> >>>
> >> >> Sure. The entire idea of reloading a uriworkermap.properties
> >> >> was to temporary disable some pre-existing mount.
> >>
> >> I understand, but it can be used in a much more powerful way.
> >> It's an external file with an easy syntax, so external monitor and
> >> manage scripts can easily manipulate it's contents.
> >>
> >> >>
> >> >> Anything else should be handled via graceful restart.
> >> >> BTW, this was added only to help the IIS that doesn't have
> >> >> the graceful restart concept.
> >>
> >> Graceful restarts can produce hanging processes under heavy load. You'll
> >> notice slots in state "G" or "L" in the server-status.
> >>
> >> >> I don't like the idea of splitting the static and dynamic
> >> >> mount points.
> >> >> The proper way to go would be to add the second shared memory
> >> >> (database like) that would contain the mount points with
> >> >> options to manage that via jkstatus. Anything else IMHO is
> >> >> useless, because it can be done via simple restart, if one
> >> >> needs to add/remove the whole bunch of new mounts in frequent
> >> >> way.
> >> >
> >> > Yep. Static configuration is just a dynamic configuration that never
> >> > changes. The right way to go is to have the configuration in shared
> >> > memory the complex stuff is how to update it.
> >> > I am trying to get something similar to work on mod_proxy and I need an
> >> > external process to update the shared memory.
> >>
> >> That using shared memory to share the mapping rules and the changes is
> >> what I wrote too. And I will investigate this further. My suggestion is
> >> to make the current behaviour of uriworkermap.properties reloading
> >> easier to understand for the users. This is something I can easily do
> >> for the next release. Handling the rules via shared memory would
> >> definitely have to wait at least for one more release.
> >>
> >> >
> >> > Cheers
> >> >
> >> > Jean-Frederic
> >> >
> >> >>
> >> >> Regards,
> >> >> Mladen.
> >> >>
> >>
> >> Regards,
> >>
> >> Rainer
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional com

Re: svn commit: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
I figured :). I'll revert and hunt down the root cause. My guess is that 
if the response was used with output stream first, then recycled and 
then used again, somehow the conv ends up being null and causes a NPE in 
the write method.


Ok, and what does the stack trace look like exactly ?

Rémy

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

Re: suggestion about new loadbalancing method of mod_jk

[Rainer Jung]

Takayuki Kaneko schrieb:
> Thank you for pointing out!
> I'll try this setting next time. Actually, I patched mod_jk to output
> the every worker's lb_value on every requests. In my analysis, it was
> the following situation.
> (Of cause the numbers of lb_value aren't real.)
> 
> * before test
>  tomcat1 lb_value=0, tomcat2 lb_value=0
> * run test and concentrated login requests, but they were distributed
> evenly
>  tomcat1 lb_value=50, tomcat2 lb_value=50
> * made difference **1

OK, what do you mean by "made difference **1"? What did the test do
during that time? Is it clear, why the difference happened, like huge
differences in requests per session?

>  tomcat1 lb_value=300, tomcat2 lb_value=200
> * concentrated login requests and all clients were distributed to tomcat2
>  tomcat1 lb_value=300, tomcat2 lb_value=300
> * made bigger difference
>  tomcat1 lb_value=300, tomcat2 lb_value=800
> * repeat **1 with swapping tomcat1 and tomcat2

Depending on the answer to the question above: in most real live
applications users don't send hundreds of requests per session and per
minute. So a couple of busy sessions might send a few dozens of requests
more in a minute. mod_jk divides the lb_value once a minute by 2 so that
differences that happened in the past get more and more unimportant.

If you do a synthetic test and hammer one session very fast, and then
soon after you make a lot of logins, the in fact the session
distribution will be uneven.

> ---
> I had another idea, the offset value should be shared among the apache
> processes with Busyness method. What do you think?

The offset is used to increase the chance of every worker getting some
request, so that you can detect failures even if the load is not very
high. The most observed case is when users do simple tests by sending a
couple of requests and then try to understand the load balancer
decision. But: this case is somehow artificial and not really relevant
for load balancing. Load balancing without load is not supposed to work
great.

With the busyness method, the low load situations happen more frequent,
especially since people might use it for apps, where it is not that
adequate. For usual apps with busyness, nearly all the time you will
have all lb_values equal to zero (and few equals 1 where a request is
running). In my opinion busyness is best, if parallelity is your
limiting ressource, like e.g. long running downloads. But again: if the
parallelity is very low, ie. low load, then you shouldn't really care
about evenly distributed requests. If you choose busyness, your metric
is parallelity and not accumulated requests. There is no mix.

The algorithm would be more perfect, if we would share the offset. But
there is a performance penalty for the shared offset. At the moment we
keep more data shared, than necessary. It is really necessary for the
lb_value, but lots of the others could be copied out of the shared
memory, because they only change via reconfiguration (jkstatus et.). I
think we will have more local copies in the future and in my opinion the
benefit of a shred offset is not enough to justify the likely
performance penalty.

> 
> Regards,
> 
> -Takayuki


Regards,

Rainer

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

svn commit: r477406 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/connector/ webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ webapps/admin/WEB-INF/classes/org/apache/we

[markt]

Author: markt
Date: Mon Nov 20 15:34:22 2006
New Revision: 477406

URL: http://svn.apache.org/viewvc?view=rev&rev=477406
Log:
Fix bug 40999. Add trust store configuration to admin webapp.
Also clean up code in o.a.webapp.admin.connector

Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/mbeans-descriptors.xml

tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources.properties

tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/AddConnectorAction.java

tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/ConnectorForm.java

tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/DeleteConnectorAction.java

tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/DeleteConnectorsAction.java

tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/EditConnectorAction.java

tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/SaveConnectorAction.java
tomcat/container/tc5.5.x/webapps/admin/connector/connector.jsp
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/mbeans-descriptors.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/mbeans-descriptors.xml?view=diff&rev=477406&r1=477405&r2=477406
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/mbeans-descriptors.xml
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/mbeans-descriptors.xml
 Mon Nov 20 15:34:22 2006
@@ -171,6 +171,18 @@
description="The thread priority for processors"
   type="int"/>
 
+
+
+
+
+
+
 

Modified: 
tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources.properties
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources.properties?view=diff&rev=477406&r1=477405&r2=477406
==
--- 
tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources.properties
 (original)
+++ 
tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources.properties
 Mon Nov 20 15:34:22 2006
@@ -142,6 +142,9 @@
 connector.keystore.filename=Keystore Filename
 connector.keystore.password=Keystore Password
 connector.keystore.type=Keystore Type
+connector.truststore.filename=Trust Store Filename
+connector.truststore.password=Trust Store Password
+connector.truststore.type=Trust Store Type
 connector.sslProtocol=SSL Protocol
 connector.keyPass.warning=Please use keytool to generate certificate.
 connector.secure=Secure

Modified: 
tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/AddConnectorAction.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/AddConnectorAction.java?view=diff&rev=477406&r1=477405&r2=477406
==
--- 
tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/AddConnectorAction.java
 (original)
+++ 
tomcat/container/tc5.5.x/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/AddConnectorAction.java
 Mon Nov 20 15:34:22 2006
@@ -19,18 +19,15 @@
 
 import java.io.IOException;
 import java.net.URLEncoder;
-import java.util.Locale;
 import java.util.ArrayList;
 import javax.servlet.ServletException;
 import javax.servlet.http.HttpServletRequest;
 import javax.servlet.http.HttpServletResponse;
 import javax.servlet.http.HttpSession;
 import org.apache.struts.action.Action;
-import org.apache.struts.action.ActionErrors;
 import org.apache.struts.action.ActionForm;
 import org.apache.struts.action.ActionForward;
 import org.apache.struts.action.ActionMapping;
-import org.apache.struts.util.MessageResources;
 import org.apache.webapp.admin.TomcatTreeBuilder;
 import org.apache.webapp.admin.LabelValueBean;
 import org.apache.webapp.admin.Lists;
@@ -120,6 +117,9 @@
 connectorFm.setKeyStoreFileName("");
 connectorFm.setKeyStorePassword("");
 connectorFm.setKeyStoreType("JKS");
+connectorFm.setTrustStoreFileName("");
+connectorFm.setTrustStorePassword("");
+connectorFm.setTrustStoreType("JKS");
 connectorFm.setSslProtocol("TLS");

 // supported only by Coyote connectors

Modified: 
tomcat/container/tc5.5.x/webapps/ad

Re: svn commit: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

ok, here is what I found,


CoyoteOutputStream.java
   public void print(String s)
   throws IOException {
   ob.write(s);
   }


I see. It's a mistake: this should be converted using the fixed default 
encoding (it works most of the time, but if somehow the app has set the 
encoding anyway, it might do funny things). Don't know what the best 
method would be, as there are some options, like using the superclass 
print(String).


Rémy

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

svn commit: r477409 - in /tomcat/tc6.0.x/trunk: java/org/apache/catalina/connector/mbeans-descriptors.xml webapps/docs/changelog.xml

[markt]

Author: markt
Date: Mon Nov 20 15:37:43 2006
New Revision: 477409

URL: http://svn.apache.org/viewvc?view=rev&rev=477409
Log:
Port relevant parts of fix for bug 40999.

Modified:

tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/mbeans-descriptors.xml
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/mbeans-descriptors.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/mbeans-descriptors.xml?view=diff&rev=477409&r1=477408&r2=477409
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/mbeans-descriptors.xml 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/mbeans-descriptors.xml 
Mon Nov 20 15:37:43 2006
@@ -171,6 +171,18 @@
description="The thread priority for processors"
   type="int"/>
 
+
+
+
+
+
+
 

Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?view=diff&rev=477409&r1=477408&r2=477409
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Mon Nov 20 15:37:43 2006
@@ -49,6 +49,9 @@
 40860: Log exceptions and other problems during parameter
 processing. (markt)
   
+  
+Enable JMX for trust store attributes for SSL connector. (markt)
+  
 

 



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

Re: [Proposal] Change in behaviour of uriworkermap.properties

[Mladen Turk]

Rainer Jung wrote:



If you think you can do that in a simple way, then fine.
But if it would require a lots of changes, then I think
we should go with the more powerful solution as part
of 1.3 branch, by using shared memory, web interface, etc.

I just don't think that this is so important if you
still cannot manage it via jkstatus.


Yes, it is simple.


OK then. Knock yourself out :)

Regards,
Mladen.

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

Re: [VOTE] Tomcat 6.0.2

[Filip Hanik - Dev Lists]

My alpha vote stands,
there are a few bug fixes I added to 6.0.2:
-output stream using the C2B converter
-ApplicationDispatcher.checkSameObjects wasn't checking the root of the 
request/response that were last serviced

-DBCP wouldn't even build with jdk1.5

To me, beta is when you can build, and we have addressed most known 
defects, but the build issue is pretty big, a beta should build straight 
from SVN

Filip

Remy Maucherat wrote:

Remy Maucherat wrote:

Hi,

Tomcat 6.0.1 has been available for over a week. Tomcat 6.0.2 updates 
a few packaging glitches, as well as two dependencies (JDT and the 
native library).


6.0.2 is:
[ ] Alpha
[ ] Beta


Ok, so far, it's 3 votes for "beta", and 1 for "alpha". Any other votes ?

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: svn commit: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

[Filip Hanik - Dev Lists]

ok, here is what I found,


CoyoteOutputStream.java
   public void print(String s)
   throws IOException {
   ob.write(s);
   }

This calls OutputBuffer.java
   public void write(String s)
   throws IOException {

   if (suspended)
   return;

   if (s == null)
   s = "null";
   conv.convert(s);
   conv.flushBuffer();

   }

and hence the NPE

Filip


Filip Hanik - Dev Lists wrote:
I figured :). I'll revert and hunt down the root cause. My guess is 
that if the response was used with output stream first, then recycled 
and then used again, somehow the conv ends up being null and causes a 
NPE in the write method.


Filip

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: fhanik
Date: Mon Nov 20 08:47:03 2006
New Revision: 477251

URL: http://svn.apache.org/viewvc?view=rev&rev=477251
Log:
TCK correction, depending on the sequence of the tests, the 
converter turns out to be null at certain times.
Added in a check to create the converter even when getting the 
output stream.


I have to veto this. It's using the output stream in that case, so 
why does it matter if the converter (= the character encoder) is null ?


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]






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

Re: [VOTE] Tomcat 6.0.2

[Tim Funk]

Its time for beta. More folks will kick the tires.

-Tim

Remy Maucherat wrote:

Hi,
6.0.2 is:
[ ] Alpha
[X] Beta



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

Re: Initial Feedback on Tomcat 6.0.2 build system

[Markus Schönhaber]

William L. Thomson Jr. wrote:

> Now for my problem. I got most of the way through compile then ran into
> this.
>
> BUILD FAILED
> /usr/portage/tmp/portage/www-servers/tomcat-6.0.2/work/apache-tomcat-6.0.2-
>src/build.xml:388: Warning: Could not find file
> /usr/portage/tmp/portage/www-servers/tomcat-6.0.2/temp/tomcat-native-1.1.7/
>tomcat-native.tar.gz to copy.
>
> I am a bit confused. Now granted we are not running the download targets
> for a variety of reasons. But the native sources seem to be inside of
> Tomcat. Why does it need a tar.gz as well as the sources? Shouldn't it
> build that out of the sources. Or is that being shipped on it's own or
> etc. Excuse me if I am totally in left field on this.

The tar.gz contains the sources. More below.

> My plan for the native stuff on Gentoo is to have a USE flag, more than
> likely jni, control if the native connector is built or not. Maybe
> optional openssl or require that since it seems most of the point to the
> native accelerator.
>
> However I am not getting what the native stuff has to do with building
> the java parts?

AFAICT - nothing. But beware: I'm not a Tomcat developer. Hopefully one of the 
Devs chimes in if the following is not correct.
The source archive for the native connector (tomcat-native.tar.gz) is handled 
by Tomcat's build process in a similar way as the binary dependencies - for 
example the Eclipse compiler, Xerces, the different Jakarta Commons packages 
etc. - i. e. it is pulled by the "download" target of the main build.xml and 
is saved to a subdir in ${base.path}. For the build of the Tomcat Java 
sources the contents of tomcat-native.tar.gz are not needed but the whole 
archive is copied to the binary distribution. That way, users of the binary 
distribution get the source for the native connector automatically and can 
build the connector without the need to fetch the sources separately. This 
build is independent of Tomcat itself. What's needed is the APR (and 
OpenSSL).
To me it seems reasonable to make the native connector a standalone Gentoo 
package on which the Tomcat package depends if it has corresponding USE-flag 
("jni" as you say) set.

Regards
  mks

BTW: if there's something I can do to help - for example testing - feel free 
to contact me.

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

Re: [Proposal] Change in behaviour of uriworkermap.properties

[Mladen Turk]

Rainer Jung wrote:

E.g. if one empties the uriworkermap.properties, reloading it does not
change the internal mount list. Temporarily adding and later removing an
entry will not remove the entry.

That's the entire point.


But this is not what a user expects from a change in a list.


I know, but like said, the current implementation
relies only on disabling existing rules with '-'.


Sure. The entire idea of reloading a uriworkermap.properties
was to temporary disable some pre-existing mount.


I understand, but it can be used in a much more powerful way.
It's an external file with an easy syntax, so external monitor and
manage scripts can easily manipulate it's contents.



If you think you can do that in a simple way, then fine.
But if it would require a lots of changes, then I think
we should go with the more powerful solution as part
of 1.3 branch, by using shared memory, web interface, etc.

I just don't think that this is so important if you
still cannot manage it via jkstatus.

Regards,
Mladen.

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

DO NOT REPLY [Bug 41007] New: - Can't define customized 503 error page

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

   Summary: Can't define customized 503 error page
   Product: Tomcat 5
   Version: 5.0.16
  Platform: Other
OS/Version: other
Status: NEW
  Severity: major
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi.

I didn't find any way to customize a global 503 error page. Sure, that can't be
on  webapps level because when it's stopped it can't be reached. So it should
give a way to customize that default tomcat error page at least for 503 errors.

I've searched the web and mailing lists on this issue and no one got it solved.
Someone said it's hardcoded in
org.apache.catalina.valves.ErrorReportValve.report(). If that is the case, that
would be really bad.

-- 
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 40002] - JULI Should Use Context ClassLoader for Formatter

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2006-11-20 03:52 ---
>From my reading of the docs, it should be possible for a webapp to specify a
custom formatter for its own logging, but I've been unable to make this
work...and neither java.util.logging.XMLFormatter (too verbose) nor
java.util.logging.SimpleFormatter meets the needs of my application. 

(SimpleFormatter is especially pointless since about half of every log record is
spent telling me that the log message was issued from the point at which Tomcat
does logging for webapps, which of course never changes.) 

I appreciate that the new logging scheme is extremely useful and flexible for
people working on Tomcat itself, but the reason there _is_ a container is to run
the contained applications. If,  by design, webapp devs can't set a custom
formatter with JULI and WEB_INF/classes/logging.properties, that should be
documented. If we can, it would be nice if we could figure out how to do that
from reading the the docs.   

-- 
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 40997] - JkMountFile directive fails to update after the uri mapping file is modified

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





--- Additional Comments From [EMAIL PROTECTED]  2006-11-20 12:20 ---
Hi Gilberto,

you need to give a little info to make your tes understandable for me:

- the uriworkermap.properties before the chagne
- the same after the change
- the URL(s) with which you are testing before and after and the results of the
requests (expected/actual)
- the timestamp of the change and of the test requests

Some of that I can guess from the log, but unfortunately not all :(


-- 
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: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

[fhanik]

Author: fhanik
Date: Mon Nov 20 08:47:03 2006
New Revision: 477251

URL: http://svn.apache.org/viewvc?view=rev&rev=477251
Log:
TCK correction, depending on the sequence of the tests, the converter turns out 
to be null at certain times.
Added in a check to create the converter even when getting the output stream.


Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java?view=diff&rev=477251&r1=477250&r2=477251
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java Mon 
Nov 20 08:47:03 2006
@@ -574,6 +574,7 @@
 (sm.getString("coyoteResponse.getOutputStream.ise"));
 
 usingOutputStream = true;
+outputBuffer.checkConverter();
 if (outputStream == null) {
 outputStream = new CoyoteOutputStream(outputBuffer);
 }



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

Re: svn commit: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

[Filip Hanik - Dev Lists]

I don't see anything wrong with my fix, as it is clear that the 
outputstream is using the converter


java.lang.Exception: conv is null
   at 
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:471)
   at 
org.apache.catalina.connector.CoyoteOutputStream.print(CoyoteOutputStream.java:113)
   at 
javax.servlet.ServletOutputStream.println(ServletOutputStream.java:242)
   at 
com.sun.ts.tests.servlet.common.util.ServletTestUtil.printResult(ServletTestUtil.java:320)
   at 
com.sun.ts.tests.servlet.api.common.response.ResponseTests.flushBufferTest(ResponseTests.java:126)

   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
com.sun.ts.tests.servlet.api.common.response.ResponseTestServlet.service(ResponseTestServlet.java:43)
   at 
com.sun.ts.tests.servlet.api.javax_servlet.servletresponsewrapper.TestServlet.service(TestServlet.java:36)
   at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
   at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
   at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
   at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
   at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
   at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
   at 
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:888)
   at 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:624)
   at 
org.apache.tomcat.util.net.NioEndpoint$Worker.run(NioEndpoint.java:1467)

   at java.lang.Thread.run(Thread.java:595)

Same test with the JIO connector
java.lang.Exception: conv is null
   at 
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:471)
   at 
org.apache.catalina.connector.CoyoteOutputStream.print(CoyoteOutputStream.java:113)
   at 
javax.servlet.ServletOutputStream.println(ServletOutputStream.java:242)
   at 
com.sun.ts.tests.servlet.common.util.ServletTestUtil.printResult(ServletTestUtil.java:320)
   at 
com.sun.ts.tests.servlet.api.common.response.ResponseTests.flushBufferTest(ResponseTests.java:126)

   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
com.sun.ts.tests.servlet.api.common.response.ResponseTestServlet.service(ResponseTestServlet.java:43)
   at 
com.sun.ts.tests.servlet.api.javax_servlet.servletresponsewrapper.TestServlet.service(TestServlet.java:36)
   at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
   at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
   at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
   at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
   at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
   at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
   at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:818)
   at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624)
   at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)

   at java.lang.Thread.run(Thread.java:595)



Filip

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
I figured :). I'll revert and hunt down the root cause. My guess is 
that if the response was used with output stream first, then recycled 
and then used again, somehow the conv ends up being null and causes a 
NPE in the write method.


Ok, and what does the stack trace look like exactly ?

Rémy

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

Re: svn commit: r477369 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteOutputStream.java

[Filip Hanik - Dev Lists]

:)




[EMAIL PROTECTED] wrote:

Author: remm
Date: Mon Nov 20 14:31:37 2006
New Revision: 477369

URL: http://svn.apache.org/viewvc?view=rev&rev=477369
Log:
- I suppose I can remove the method then.

Modified:

tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteOutputStream.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteOutputStream.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteOutputStream.java?view=diff&rev=477369&r1=477368&r2=477369
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteOutputStream.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteOutputStream.java 
Mon Nov 20 14:31:37 2006
@@ -105,14 +105,5 @@
 }
 
 
-//  ServletOutputStream Methods

-
-
-public void print(String s)
-throws IOException {
-super.print(s);
-}
-
-
 }
 




-
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]