Re: Debugging Apache/mod_jk (worker) fault on AIX

[Tim Whittington]

We've seen broken mod_jk builds with xlc_r in our environments. cc_r builds 
seems to work fine though.
I haven't dug into what the issue is though.
 
tim
>>> On 6/03/2007 at 8:35 a.m., in message <[EMAIL PROTECTED]>, Eric Wertman 
>>> <[EMAIL PROTECTED]> wrote:
Actually I started with xlc_r and it wouldn't go.  Not mod_jk 
specifically, but apr or apache 2.2.4.  I stuck with cc_r for consistency.

William A. Rowe, Jr. wrote:
> Any reason you didn't choose xlc_r?  I'd suggest you retest with that
> compile.
> 
> Rainer Jung wrote:
>> Hi Eric,
>>
>> we won't close the issue immediately with "we don't support cc_r". This
>> will be our last option :)
>>
>> Rainer
>>
>> Eric Wertman wrote:
>>> Hi Rainer... I'll have to re-compile to get this info for you.  I'll
>>> make sure I can re-produce it and submit the details in a bugzilla.
>>>
>>> I think the first thing you'll notice, though, is that I'm using the
>>> IBM cc_r compiler and not gcc.
>>>
>>>
>>> Rainer Jung wrote:
 Eric reported very strange mod_jk behaviour using it with Apache
 2.0/worker on AIX.

 I start a new mail thread, because until now all the discussion is part
 of non-specific threads.

 Eric: could you please open a bugzilla (issues.apache.org), so that we
 can track the issue?

 Also: When you compile mod_jk for your apache with worker MPM, does the
 make output contain the flag -D_REENTRANT?

 If no, how does the begginning of the file HOME_OF_APACHE/bin/apr-config
 look like? Example:

 APR_MAJOR_VERSION="0"
 APR_DOTTED_VERSION="0.9.12"

 prefix="/var/tmp/install/apache2p"
 exec_prefix="/var/tmp/install/apache2p"
 bindir="${prefix}/bin"
 libdir="${prefix}/lib"
 datadir="/var/tmp/install/apache2p"
 installbuilddir="${prefix}/build"
 includedir="/var/tmp/install/apache2p/include"

 CC="gcc "
 CPP="gcc  -E"
 SHELL="/bin/sh"
 CPPFLAGS="-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE"
 CFLAGS="-O2 -g -Wall -pthread"
 LDFLAGS=""
 LIBS="-lrt -lm -lcrypt -lnsl  -lpthread -ldl"
 EXTRA_INCLUDES=""
 SHLIBPATH_VAR="LD_LIBRARY_PATH"
 APR_SOURCE_DIR="/non/existing/build/path/apache2/srclib/apr"
 APR_BUILD_DIR="/non/existing/build/path/apache2/srclib/apr"
 APR_SO_EXT="lo"
 APR_LIB_TARGET="-rpath \$(libdir) \$\$objects"
 APR_LIBNAME="apr-${APR_MAJOR_VERSION}"

 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] 

DO NOT REPLY [Bug 41770] New: - JkWorkerProperties broken in mod_jk 1.2.21

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

   Summary: JkWorkerProperties broken in mod_jk 1.2.21
   Product: Tomcat 5
   Version: Unknown
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


As of mod_jk 1.2.21 it is no longer possible to define workers via 
JkWorkerProperties directives.

Configurations that worked with previous versions now get "Error in reading 
worker properties". When the properties are moved to a separate file, there is 
no error.

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

Two questions about SemaphoreValve support for filtering (bug # 41679)

[Scott Marlow]

For Bug # 41679, I attached the current code changes that I am using to 
apply SemaphoreValve to different parts of my application based on url 
filtering or header field value.  Certain "resource expensive" parts of 
the application are allowed a smaller number of users to access 
concurrently than other parts of the application.  I think that this 
will be useful to other applications as well.


I have two questions about finishing the patch that is attached to bug 
41679.


1.  I currently detect if a request has already been throttled by 
testing if an attribute named "_SemaphoreValve_throttled_" is in the 
request.  If not, evaluate if the SemaphoreValve should be applied.  If 
yes, add an attribute named "_SemaphoreValve_throttled_" to the request 
so that we don't apply further SemaphoreValve instances to the request.  
Is this technique of injecting a magic attribute in the request too 
intrusive?  Another option would be to change all Valves to not expect a 
certain concrete implementation of Request so that we could use a 
RequestWrapper instead that implements a SemaphoreValveMarkerInterface 
to signal that a request has already been throttled.


2.  It might be useful to have a common Valve subclass that helps with 
the url filter matching.  Should I work on that as part of this bug?  Or 
is it better to keep this change simple and isolated to the 
SemaphoreValve?  The filtering support could be refactored later to a 
common subclass.


I assume that if several SemaphoreValve instances are specified in 
conf/server.xml, that they are executed in the order that they appear.  
This appears to be the behavior in Tomcat 5.x + 5.5.x.  Is this a valid 
assumption to add to the doc?


Thanks,

Scott  Marlow
www.vestmark.com


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

Re: Two questions about SemaphoreValve support for filtering (bug # 41679)

[Remy Maucherat]

Scott Marlow wrote:
For Bug # 41679, I attached the current code changes that I am using to 
apply SemaphoreValve to different parts of my application based on url 
filtering or header field value.  Certain "resource expensive" parts of 
the application are allowed a smaller number of users to access 
concurrently than other parts of the application.  I think that this 
will be useful to other applications as well.


Sounds cool to me.

I have two questions about finishing the patch that is attached to bug 
41679.


1.  I currently detect if a request has already been throttled by 
testing if an attribute named "_SemaphoreValve_throttled_" is in the 
request.  If not, evaluate if the SemaphoreValve should be applied.  If 
yes, add an attribute named "_SemaphoreValve_throttled_" to the request 
so that we don't apply further SemaphoreValve instances to the request.  
Is this technique of injecting a magic attribute in the request too 
intrusive?  Another option would be to change all Valves to not expect a 
certain concrete implementation of Request so that we could use a 
RequestWrapper instead that implements a SemaphoreValveMarkerInterface 
to signal that a request has already been throttled.


I don't see how a request going through a Valve can be "already 
throttled", as requests are supposed to go through a valve only once. 
Can you give an example ? (maybe multiple valves in a row like what is 
suggested below ?) Valves only accept the concrete Request class, no 
wrapping allowed.


Marker attributes are already being used elsewhere, so it's ok.

2.  It might be useful to have a common Valve subclass that helps with 
the url filter matching.  Should I work on that as part of this bug?  Or 
is it better to keep this change simple and isolated to the 
SemaphoreValve?  The filtering support could be refactored later to a 
common subclass.


Yes, I think such a common valve is the way to go, similar to the 
RequestFilterValve.


I assume that if several SemaphoreValve instances are specified in 
conf/server.xml, that they are executed in the order that they appear.  
This appears to be the behavior in Tomcat 5.x + 5.5.x.  Is this a valid 
assumption to add to the doc?


Yes.

Rémy


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

Re: [VOTE] Release build 5.5.23 - Take 2

[Jim Jagielski]

On Mar 5, 2007, at 11:29 AM, Filip Hanik - Dev Lists wrote:

Due to a recent screw up, my binaries didn't match the tag in SVN.  
This has been corrected.
A new build has been run from the tag, the TCK tests have all been  
run and passed.


Candidate binaries are available here:
http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.23-2/

According to the (slightly) updated release process, the 5.5.23 tag  
is:

[ ] Broken
[ ] Alpha
[ ] Beta
[X] Stable



Stable

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

DO NOT REPLY [Bug 41770] - JkWorkerProperties broken in mod_jk 1.2.21

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





--- Additional Comments From [EMAIL PROTECTED]  2007-03-06 07:10 ---
I have a running config which uses workers.properties and JkWorkerProperty.

Could you please attach a test case, i.e. a small example configuration with
which we can reproduce the problem.

-- 
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: Two questions about SemaphoreValve support for filtering (bug # 41679)

[Scott Marlow]

I don't see how a request going through a Valve can be "already 
throttled", as requests are supposed to go through a valve only once. 
Can you give an example ? (maybe multiple valves in a row like what is 
suggested below ?) Valves only accept the concrete Request class, no 
wrapping allowed.


Yes, multiple valves in a row is what I am suggesting.  One example 
could be:



   


 
 fairness="true"
 concurrency="0"
 
filter=".*\.gif,.*\.js,.*\.jpg,.*\.htm,.*\.html,.*\.txt,.*\.vm,.*\.css,.*\.cur" 
/>



   
   
   /> 

I didn't want a single request to consume Semaphore permits from more 
than one SemaphoreValve.


Thanks,
Scott

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

Re: Two questions about SemaphoreValve support for filtering (bug # 41679)

[Remy Maucherat]

Scott Marlow wrote:
I didn't want a single request to consume Semaphore permits from more 
than one SemaphoreValve.


I'm not sure about that, since for example the last valve could be more 
restrictive than the first one, etc. It seems more logical to me to 
consume one permit from each valve since I understand the SemaphoreValve 
in terms of restricting something (most likely there should be an option 
for this on the valve, however, so a SemaphoreValve relaxing concurrency 
constraints could be configured as in your example).


Rémy

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

DO NOT REPLY [Bug 41770] - JkWorkerProperties broken in mod_jk 1.2.21

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2007-03-06 07:33 ---
You are correct.
If there is no define JkWorkersFile mo_jk on Windows shuts
down the httpd.
If there is a JkWorkersFile directive (even pointing to an empty file)
then everything works as expected. Not sure if you reported that exactly.


-- 
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 41770] - JkWorkerProperties broken in mod_jk 1.2.21

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





--- Additional Comments From [EMAIL PROTECTED]  2007-03-06 08:00 ---
Aha, it's the same on the other platforms. We check for return form
jk_map_read_properties() and this returns JK_FALSE, if the file name is NULL.

So either we return JK_TRUE in case the file nae is NULL and the given map is
non empty, or we need to use a multi value return code, which distinguishes
several kinds of anomalies.

Since IIS and Netscape have no JkWorkerProperty statement, a NULL file name
really is an error for them. But maybe (it seems so) we already check for
non-NULL filenames during config parsing of IIS and netscape?


-- 
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: Two questions about SemaphoreValve support for filtering (bug # 41679)

[Scott Marlow]

Remy Maucherat wrote:

Scott Marlow wrote:
I didn't want a single request to consume Semaphore permits from more 
than one SemaphoreValve.


I'm not sure about that, since for example the last valve could be 
more restrictive than the first one, etc. It seems more logical to me 
to consume one permit from each valve since I understand the 
SemaphoreValve in terms of restricting something (most likely there 
should be an option for this on the valve, however, so a 
SemaphoreValve relaxing concurrency constraints could be configured as 
in your example).


Good point, I updated the bug report to reflect the requirement to have 
an option for this.  I think both modes will be useful for different cases.


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

DO NOT REPLY [Bug 41772] New: - Brand new HttpServletResponse is already committed.

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

   Summary: Brand new HttpServletResponse is already committed.
   Product: Tomcat 5
   Version: 5.0.30
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I'm running on Suse 9.3 (I think) with tomcat 5.0.30 running under Java
1.5.0_07-b03.  I'm front-ending with Apache 2.2.0 using mod_jk set up to hit an
AJP 1.3 connector.  As far as I can tell, everything is configured correctly.

About 20% of the time, when I hit my application without handing in a session
ID, I get an "IllegalStateException: Cannot create a session after the response
has been committed".  The problem is at its worst when I hit my application
using a client OTHER than a web browser.  I have tried putting a ServletFilter
in front of my application to verify that 1) the session truly cannot be
created, and 2) that the response is actually committed before my code touches
it.  It appears my application is being handed an already commited
HttpServletResponse.

I have 3 separate applications running in the same tomcat instance.

1) a webservice powered first by Axis, and now by XFire.  This bug showed up
using both of these libraries.
2) a straight up servlet / JSP webapp powered by struts.
3) a struts-powered app used exclusively for dynamic image generation.

In the case of app 1, I ended up hacking XFire to not call
response.setBufferSize(), which kept it from triggering an
"IllegalStateException: response has already been committed."  I don't have any
remaining stack traces, as I did this fix several months ago and dumped them,
thinking this was the end of the issue.

In app #2 everything seems to work fine except occasionally on my login page,
where I get this problem occasionally when I hand in no SESSIONID or an expired
one.  A page refresh usually takes care of it.

In app #3, I'm generating images to be included in a dynamically generated PDF.
 I make a bunch of calls to this app in rapid succession (12-15 images per PDF)
and invariably, anywhere between 1 and 5 of them returns a content length of 0.
 I checked the logs and found this stack trace:

(NOTE: that stray line in my SessionFilter class is:
((HttpServletRequest)request).getSession(true);  If you need the whole content
of that filter, I can send it to you, but that's all it does at the moment.)

java.lang.IllegalStateException: Cannot create a session after the response has
been committed
at
org.apache.coyote.tomcat5.CoyoteRequest.doGetSession(CoyoteRequest.java:2270)
at
org.apache.coyote.tomcat5.CoyoteRequest.getSession(CoyoteRequest.java:2116)
at
org.apache.coyote.tomcat5.CoyoteRequestFacade.getSession(CoyoteRequestFacade.java:528)
at com.mycompany.util.SessionFilter.doFilter(SessionFilter.java:37)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at 
org.apache.coyote.tomcat5.CoyoteAdapter.serv

DO NOT REPLY [Bug 41772] - Brand new HttpServletResponse is already committed.

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





--- Additional Comments From [EMAIL PROTECTED]  2007-03-06 09:32 ---
Created an attachment (id=19672)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19672&action=view)
My test case - used to reproduce my problem.

I've attached the test case I used to reproduce my bug.  I have changed the URL
to edit out the host, application, and struts action mapping.  However, all
other parts of the file are as-is.

-- 
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 41770] - JkWorkerProperties broken in mod_jk 1.2.21

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
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 41770] - JkWorkerProperties broken in mod_jk 1.2.21

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





--- Additional Comments From [EMAIL PROTECTED]  2007-03-06 10:00 ---
As a temporary workaround for those of you on UNIX, you may try adding:

  JkWorkersFile /dev/null

...in addition to your JkWorkerProperty directives (which still seem to apply).

Best regards,
Björn

-- 
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 41770] - JkWorkerProperties broken in mod_jk 1.2.21

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





--- Additional Comments From [EMAIL PROTECTED]  2007-03-06 10:35 ---
Not sure if it's related, but worker..local_worker will also now toss an
error where it wouldn't in 1.2.20.  Removing the local_worker directive fixed
the error, but was surprising in a point release to say the least.

-- 
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 41773] New: - DefaultServlet doesn't set correct content type

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

   Summary: DefaultServlet doesn't set correct content type
   Product: Tomcat 5
   Version: 5.5.20
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
 BugsThisDependsOn: 31201


This is a continuation of bug #31201. The fileEncoding parameter on the
DefaultServlet doesn't go far enough. 
The case I have is this:
I have a webapp that serves some static html files directly to end user. They
are encoded in shift_jis. With the current implementation the response header
says the charset is iso-8859-1 for my jvm. So now I can see the correct
characters in the result page but only if I explicitly tell the browser to show
the page in shift_jis.

I believe the DefaultServlet also needs to pass along the fileEncoding parameter
as the charset in the response content type.

I added the following line to the Default Servlet and it now returns a sensible
content type header for any static html  or text files in my web application.

Compare:
(<)\apache-tomcat-5.5.20-src\container\catalina\src\share\org\apache\catalina\servlets\DefaultServlet.java


738d738
< if(contentType.toLowerCase().indexOf("charset") == -1 &&
fileEncoding != null) contentType += ";charset="+fileEncoding; 

It would be great if this could be applied to the official tomcat distribution.
Thanks

-- 
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 31201] - Encoding bug when using action

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

OtherBugsDependingO||41773
  nThis||




-- 
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 41772] - HttpServletResponse is already committed.

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |minor
Summary|Brand new   |HttpServletResponse is
   |HttpServletResponse is  |already committed.
   |already committed.  |




--- Additional Comments From [EMAIL PROTECTED]  2007-03-06 12:43 ---
So, sheepishly I admit that this is an application error, but I believe there's
still a weakness to be patched up.  

It relates back to the Java2D stuff I'm using.  After the following two lines:

ImageOutputStream 
out=ImageIO.createImageOutputStream(response.getOutputStream());
ImageIO.write(image,"png",out);
response.getOutputStream().flush();

I never closed ImageOutputStream.  Obviously an application error.  However, in
the catalina logs, I found this stack trace:

2007-03-05 07:00:01,167 [Finalizer] ERROR org.apache.jk.server.JkCoyoteHandler -
Error in action code
java.net.SocketException: Socket closed
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:506)
at 
org.apache.jk.server.JkCoyoteHandler.appendHead(JkCoyoteHandler.java:401)
at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:416)
at org.apache.coyote.Response.action(Response.java:182)
at org.apache.coyote.Response.sendHeaders(Response.java:374)
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:322)
at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:298)
at
org.apache.coyote.tomcat5.CoyoteOutputStream.flush(CoyoteOutputStream.java:85)
at
javax.imageio.stream.FileCacheImageOutputStream.close(FileCacheImageOutputStream.java:194)
at
javax.imageio.stream.ImageInputStreamImpl.finalize(ImageInputStreamImpl.java:850)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)


During GC, that ImageOutputStream is trying to flush the response output stream.
 It seems like Tomcat recycles HttpServletResponse objects.  If this finalizer
is executed AFTER the Response object it references is recycled, the resulting
'flush()' would cause that Response object to become committed.  When a new
request then comes in to be handled by a thread with a now broken Response
object . . . well, there's where my error comes from.

I also believe this bug report relates directly to bug #37516.  Note that in the
example code provided in that bug, he ALSO does not close his image output
stream.  My apologies for duplicating a previous bug.

While I understand this is my application's bug, it seems that recycling
Response objects should be a bit more safe than it currently is.

-- 
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 41775] New: - Classes are not loaded from ${catalina.base}/lib

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

   Summary: Classes are not loaded from ${catalina.base}/lib
   Product: Tomcat 6
   Version: unspecified
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: normal
  Priority: P3
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


If $CATALINA_BASE is defined it is supposed to affect the locations used for
several things, including changing the location of the lib directory which
defines the contents of the common class loader. However, although the locations
of conf, work, and webapps are changed by CATALINA_BASE, the lib directory does
not appear to be relocated.

The RUNNING.txt states explicitly that shared class loading is affected by
"catalina.base", but the remaining docs are less clear.

Is this a bug in behavior, or is it an error in 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 41772] - HttpServletResponse is already committed.

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2007-03-06 13:51 ---
This has been reported many times, and will not be patched, since enabling the
security manager fixes it.

-- 
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 41773] - DefaultServlet doesn't set correct content type

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2007-03-06 14:01 ---
You can easily use your own extended servlet. I believe the current one provides
the necessary features encoding wise.

-- 
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 41775] - Classes are not loaded from ${catalina.base}/lib

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-03-06 14:04 ---
You can read about CL in the documentation, and you can customize the
classloading tree using catalina.properties.

-- 
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 41770] - JkWorkerProperties broken in mod_jk 1.2.21

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





--- Additional Comments From [EMAIL PROTECTED]  2007-03-06 15:18 ---
When we introduced the new check for valid attributes, we carefully included all
old obsolete attributes to not break old configs. Unfortunately if one goes back
until mod_jk 1.2.6, there are two attributes that got completely removed between
1.2.8 and 1.2.9: local_worker and local_worker_only. These two slipped our
attention. So if you still have them in your configuration, the validity check
for the config will detect an unknown attribute and the web server will not 
start.

We should have added those two to our deprecation list long ago, then the web
server would start but log a notice, that these two properties are deprecated.

As a workaround please remove these two attributes from your configuration. They
don't work since 1.2.9 in early 2005. You can use the distance attribute to
express proximity relations.

We will add local_worker and local_worker_only to our list of deprecated
attributes in the next release, so that other users upgrading from very old
versions will still be able to start their servers, but might need to optimize
their configurations with respect to all attributes logged as deprecated during
startup.

Thanks for reporting this and sorry for the inconvenience.

And: yes, I think we are not far from starting a new major release. We tried to
improve over a lot of dot releases and the functional break was not intentional.


-- 
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: r515355 - in /tomcat/connectors/trunk/jk: native/common/jk_util.c xdocs/miscellaneous/changelog.xml

[rjung]

Author: rjung
Date: Tue Mar  6 15:25:38 2007
New Revision: 515355

URL: http://svn.apache.org/viewvc?view=rev&rev=515355
Log:
Add local_worker and friends to the list of deprecated and the list of supported
attributes.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_util.c
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml

Modified: tomcat/connectors/trunk/jk/native/common/jk_util.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_util.c?view=diff&rev=515355&r1=515354&r2=515355
==
--- tomcat/connectors/trunk/jk/native/common/jk_util.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_util.c Tue Mar  6 15:25:38 2007
@@ -65,6 +65,8 @@
 #define BALANCE_WORKERS ("balance_workers")
 #define STICKY_SESSION  ("sticky_session")
 #define STICKY_SESSION_FORCE("sticky_session_force")
+#define LOCAL_WORKER_DEPRECATED ("local_worker")
+#define LOCAL_WORKER_ONLY_DEPRECATED ("local_worker_only")
 #define JVM_ROUTE_OF_WORKER_DEPRECATED ("jvm_route")
 #define ROUTE_OF_WORKER ("route")
 #define DOMAIN_OF_WORKER("domain")
@@ -165,6 +167,8 @@
 LOAD_FACTOR_OF_WORKER,
 STICKY_SESSION,
 STICKY_SESSION_FORCE,
+LOCAL_WORKER_DEPRECATED,
+LOCAL_WORKER_ONLY_DEPRECATED,
 JVM_ROUTE_OF_WORKER_DEPRECATED,
 ROUTE_OF_WORKER,
 DOMAIN_OF_WORKER,
@@ -206,6 +210,8 @@
 RECYCLE_TIMEOUT_DEPRECATED,
 BALANCED_WORKERS_DEPRECATED,
 JVM_ROUTE_OF_WORKER_DEPRECATED,
+LOCAL_WORKER_DEPRECATED,
+LOCAL_WORKER_ONLY_DEPRECATED,
 IS_WORKER_DISABLED_DEPRECATED,
 IS_WORKER_STOPPED_DEPRECATED,
 NULL
@@ -246,6 +252,8 @@
 BALANCE_WORKERS,
 STICKY_SESSION,
 STICKY_SESSION_FORCE,
+LOCAL_WORKER_DEPRECATED,
+LOCAL_WORKER_ONLY_DEPRECATED,
 JVM_ROUTE_OF_WORKER_DEPRECATED,
 ROUTE_OF_WORKER,
 DOMAIN_OF_WORKER,

Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?view=diff&rev=515355&r1=515354&r2=515355
==
--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Tue Mar  6 
15:25:38 2007
@@ -22,6 +22,18 @@
   new documentation project for JK was started.
   
 
+
+  
+  
+
+  
+41770: Fix the second part of the bug: local_worker and 
local_worker_only
+is missing from the list of deprecated attributes (and not supported 
either), so prevents
+the web server from startup. (rjung)
+  
+
+  
+
 
   
   



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