svn commit: r562025 - in /tomcat/connectors/trunk/jk/native: common/jk_version.h iis/installer/isapi-redirector-win32-msi.ism iis/isapi_redirect.rc

2007-08-02 Thread mturk
Author: mturk
Date: Wed Aug  1 23:10:29 2007
New Revision: 562025

URL: http://svn.apache.org/viewvc?view=revrev=562025
Log:
Increment version to 1.2.25-dev

Modified:
tomcat/connectors/trunk/jk/native/common/jk_version.h

tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism
tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc

Modified: tomcat/connectors/trunk/jk/native/common/jk_version.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_version.h?view=diffrev=562025r1=562024r2=562025
==
--- tomcat/connectors/trunk/jk/native/common/jk_version.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_version.h Wed Aug  1 23:10:29 
2007
@@ -26,14 +26,14 @@
 /** START OF AREA TO MODIFY BEFORE RELEASING */
 #define JK_VERMAJOR 1
 #define JK_VERMINOR 2
-#define JK_VERFIX   24
-#define JK_VERSTRING1.2.24
+#define JK_VERFIX   25
+#define JK_VERSTRING1.2.25
 
 /* Beta number */
 #define JK_VERBETA  0
 #define JK_BETASTRING   0
 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */
-#define JK_VERISRELEASE 1
+#define JK_VERISRELEASE 0
 #define JK_VERRC0
 #define JK_RCSTRING 0
 

Modified: 
tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism?view=diffrev=562025r1=562024r2=562025
==
--- 
tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism 
(original)
+++ 
tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism 
Wed Aug  1 23:10:29 2007
@@ -3409,7 +3409,7 @@
rowtdProductID/tdtdnone/tdtd//row
rowtdProductLanguage/tdtd1033/tdtd//row
rowtdProductName/tdtdTomcat Isapi 
Redirector/tdtd//row
-   rowtdProductVersion/tdtd1.2.24/tdtd//row
+   rowtdProductVersion/tdtd1.2.25/tdtd//row
rowtdProgressType0/tdtdinstall/tdtd//row
rowtdProgressType1/tdtdInstalling/tdtd//row
rowtdProgressType2/tdtdinstalled/tdtd//row

Modified: tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc?view=diffrev=562025r1=562024r2=562025
==
--- tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc (original)
+++ tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc Wed Aug  1 23:10:29 
2007
@@ -14,13 +14,13 @@
 specific language governing permissions and  \
 limitations under the License.
 
-#define JK_VERSION_STR  1.2.24
+#define JK_VERSION_STR  1.2.25
 #define JK_DLL_BASENAME isapi_redirect- JK_VERSION_STR
 
 
 1 VERSIONINFO
- FILEVERSION 1,2,24,0
- PRODUCTVERSION 1,2,24,0
+ FILEVERSION 1,2,25,0
+ PRODUCTVERSION 1,2,25,0
  FILEFLAGSMASK 0x3fL
 #if defined(_DEBUG)
  FILEFLAGS 0x01L



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



Serious regression in JK 1.2.24

2007-08-02 Thread Mladen Turk

Hi,

We have a problem with 1.2.24 that luckily is not security leak,
but it is security related.

The problem is that 401 from Tomcat without body
(a standard HTTP_UNAUTHORIZED) is treated as 401, meaning
that Apache is returning 401 page instead passing 401
to the client.

I already patched the SVN.
Can we roll 1.2.25?

Regards,
Mladen.

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



Re: Serious regression in JK 1.2.24

2007-08-02 Thread Rainer Jung

Hi,

OK with me. I've one outstanding patch related to fail on status. I 
think Ben short is testing today. I wrote mails about it to the user 
list and the patch is not committed yet. It's


http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch

(in short: fail on status has to be moved to a place a little earlier, 
because at the moment headers are set before fail on status. So if we do 
a retry and get different headers back, we produce an answer with an 
undefined mix of headers. In the users case we set Content-Length from 
the failure response, and the retry on another node succeeded with a 
chunked encoding ...)


Also there is one outstanding fix concerning nsapi on netware (which now 
has an unneeded dependency on shm).


We could review all changes since 1.2.24 (that's not much) and then skip 
the quality check phase, instead directly roll an oficial test/vote 
tarball. Would tomorrow be OK for that?


Regards,

Rainer

Mladen Turk wrote:

Hi,

We have a problem with 1.2.24 that luckily is not security leak,
but it is security related.

The problem is that 401 from Tomcat without body
(a standard HTTP_UNAUTHORIZED) is treated as 401, meaning
that Apache is returning 401 page instead passing 401
to the client.

I already patched the SVN.
Can we roll 1.2.25?

Regards,
Mladen.


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



DO NOT REPLY [Bug 43009] - Reported exception is not original cause of problem

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-02 01:52 ---
In the end, I think there isn't a bug here after all so this issue could be
safely ignored.

war.delete(); is called earlier as the first statement in the method, so if it
is going to throw a SecurityException, it will already have done so.

The actual problem I was investigating turned out to be elsewhere (will submit
that separately).

-- 
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: svn commit: r562022 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml

2007-08-02 Thread Rainer Jung

Hi Mladen,

I don't full yunderstand this fix. From your other mail i though it's a 
regression, but the code in this region is the same at least since 
1.2.18 (more than a year). So I have the impression, that this is not a 
regression. If so, I would prefer to not push 1.2.25 through with very 
high speed, i.e. 1.2.24 would still be pretty useful as an update.


Regards,

Rainer

[EMAIL PROTECTED] wrote:

Author: mturk
Date: Wed Aug  1 23:06:18 2007
New Revision: 562022

URL: http://svn.apache.org/viewvc?view=revrev=562022
Log:
Fix the 401 not passed to the client.

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?view=diffrev=562022r1=562021r2=562022
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Wed Aug  1 23:06:18 
2007
@@ -2159,7 +2159,8 @@
 if (rc  0) {
 /* If tomcat returned no body and the status is not OK,
let apache handle the error code */
-if (!r-sent_bodyct  r-status = HTTP_BAD_REQUEST) {
+if (!r-sent_bodyct  r-status = HTTP_BAD_REQUEST 
+ r-status != HTTP_UNAUTHORIZED) {
 jk_log(conf-log, JK_LOG_INFO, No body with status=%d
 for worker=%s,
r-status, worker_name);

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?view=diffrev=562022r1=562021r2=562022
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Wed Aug  1 23:06:18 
2007
@@ -2250,7 +2250,8 @@
 
 /* [EMAIL PROTECTED] : under i5/OS sent_bodyct is not set correctly */

 /*   check for header_only to see if there was a body */
-if (!r-sent_bodyct  r-status = HTTP_BAD_REQUEST) {
+if (!r-sent_bodyct  r-status = HTTP_BAD_REQUEST 
+ r-status != HTTP_UNAUTHORIZED) {
 jk_log(xconf-log, JK_LOG_INFO, No body with status=%d
 for worker=%s,
r-status, worker_name);

Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?view=diffrev=562022r1=562021r2=562022
==
--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Wed Aug  1 
23:06:18 2007
@@ -23,6 +23,16 @@
   new documentation project for JK was started.
   /p
 /section
+section name=Changes between 1.2.24 and 1.2.25
+  br /
+  subsection name=Native
+changelog
+  fix
+Pass the 401 as OK instead sending 401 for authentication. (mturk)
+  /fix
+/changelog
+  /subsection
+/section
 section name=Changes between 1.2.23 and 1.2.24
   br /
   subsection name=Native


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



DO NOT REPLY [Bug 43013] New: - No mention of limitation regarding deployment with multi-level context paths (e.g. /123/456)

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

   Summary: No mention of limitation regarding deployment with
multi-level context paths (e.g. /123/456)
   Product: Tomcat 5
   Version: 5.5.23
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If I understand correctly, the manager app doesn't support deployment with
multi-level context paths e.g. path=/123/456.

I couldn't see any mention of this limitation in the docs. Would be useful if it
was mentioned there.

Also, if trying to do this, the deployment fails but with no explanation. It
should be simple to add a test for multi-level paths and exit with an
appropriate error message, e.g.

Inserting after this block from org.apache.catalina.manager.ManagerServlet

// Validate the requested context path
if ((path == null) || path.length() == 0 || !path.startsWith(/)) {
writer.println(sm.getString(managerServlet.invalidPath, path));
return;
}

the following code at line 588:

if (path.lastIndexOf(/)  0) {
writer.println(sm.getString(managerServlet.unsupportedPath, 
path));
return;
}

Adding appropriate messages to properties files of course.


It would be even better if the manager could deploy apps using such a context
path but that would be an enhancement so I'll request that separately.

-- 
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: svn commit: r562022 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml

2007-08-02 Thread Mladen Turk

Rainer Jung wrote:

Hi Mladen,

I don't full yunderstand this fix. From your other mail i though it's a 
regression, but the code in this region is the same at least since 
1.2.18 (more than a year). So I have the impression, that this is not a 
regression.


You can try 1.2.23 (it works). 1.2.24 doesn't. With patch it works again.
I'm not sure if the patch is correct, because it might be that
request_rec-sent_bodyct flag is setup differently in 1.2.24

If so, I would prefer to not push 1.2.25 through with very 
high speed, i.e. 1.2.24 would still be pretty useful as an update.




But it doesn't work.
You can try 1.2.23 with Tomcat manager app. The browser displays login
window for username/password. 1.2.24 displays 401 page from Apache.

Regards,
Mladen

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



Re: svn commit: r562022 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml

2007-08-02 Thread Rainer Jung
OK, I'll go into it. I think I would propose a slightly different patch, 
but I'll investigate, why 23 and 24 are different.


The reason why I started to pose querstions is, that I found it a little 
strange to make an exception for exactly one status code.


My impression is: the code was supposed to let httpd produce the error 
page in case we got an error status without any content. But: for a 401 
we actually do get a body content from tomcat. So in fact something is 
wrong with sent_bodycnt. I'll investigate.


Regards,

Rainer

Mladen Turk wrote:

Rainer Jung wrote:

Hi Mladen,

I don't full yunderstand this fix. From your other mail i though it's 
a regression, but the code in this region is the same at least since 
1.2.18 (more than a year). So I have the impression, that this is not 
a regression.


You can try 1.2.23 (it works). 1.2.24 doesn't. With patch it works again.
I'm not sure if the patch is correct, because it might be that
request_rec-sent_bodyct flag is setup differently in 1.2.24

If so, I would prefer to not push 1.2.25 through with very high speed, 
i.e. 1.2.24 would still be pretty useful as an update.




But it doesn't work.
You can try 1.2.23 with Tomcat manager app. The browser displays login
window for username/password. 1.2.24 displays 401 page from Apache.

Regards,
Mladen


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



DO NOT REPLY [Bug 43014] New: - Enable manager to deploy apps with multi-level paths, e.g. /123/456

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

   Summary: Enable manager to deploy apps with multi-level paths,
e.g. /123/456
   Product: Tomcat 5
   Version: 5.5.23
  Platform: Other
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If I understand correctly, it can't do this at the moment,

ref:
http://www.nabble.com/Using-manager-to-deploy-with-path%3D%22-123-456-789%22-t4200949.html

Would be good if it could.

I'm thinking that an administrator would be able to define a location outside of
appBase where war's for such apps could be expanded, e.g.
catalina_base/outsideAppBase 

The manager on recognising such a contex-path could then expand the war there
(in a subdir according to the context-path specified, and create an appropriate
context xml file to go into catalina-base/conf/Engine/host/

Interested to hear what you think, and if you forsee any problems with this
approach.

-- 
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: svn commit: r562022 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml

2007-08-02 Thread Mladen Turk

Rainer Jung wrote:
OK, I'll go into it. I think I would propose a slightly different patch, 
but I'll investigate, why 23 and 24 are different.


The reason why I started to pose querstions is, that I found it a little 
strange to make an exception for exactly one status code.


My impression is: the code was supposed to let httpd produce the error 
page in case we got an error status without any content. But: for a 401 
we actually do get a body content from tomcat. So in fact something is 
wrong with sent_bodycnt. I'll investigate.




Probably it is. I personally don't like my patch either, cause it's
the kind of 'what other status might be bogus' thing.

Regards,
Mladen.

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



DO NOT REPLY [Bug 43013] - No mention of limitation regarding deployment with multi-level context paths (e.g. /123/456)

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-02 04:09 ---
*** Bug 43014 has been marked as a duplicate of this bug. ***

-- 
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: r562085 - /tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 04:57:29 2007
New Revision: 562085

URL: http://svn.apache.org/viewvc?view=revrev=562085
Log:
Partially undo r530674: Chanhing the AS400 ifdefs
also hit two ifndefs instead of only ifdefs.
As a consequence, we didn't flush any more.

Modified:
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?view=diffrev=562085r1=562084r2=562085
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Thu Aug  2 04:57:29 
2007
@@ -375,7 +375,7 @@
 
 static void JK_METHOD ws_flush(jk_ws_service_t *s)
 {
-#if defined(AS400)  !defined(AS400_UTF8)
+#ifndef AS400
 if (s  s-ws_private) {
 apache_private_data_t *p = s-ws_private;
 ap_rflush(p-r);
@@ -423,7 +423,7 @@
 }
 }
 if (p-r-header_only) {
-#if defined(AS400)  !defined(AS400_UTF8)
+#ifndef AS400
 ap_rflush(p-r);
 #endif
 return JK_TRUE;



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



Re: [VOTE] Release build 6.0.14

2007-08-02 Thread Remy Maucherat

Remy Maucherat wrote:

The candidates binaries are available here:
http://people.apache.org/~remm/tomcat-6/v6.0.14/

According to the release process, the 6.0.14 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[ ] Stable


Ok, so far this build seems stable. Any other votes ?

Rémy

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



Re: svn commit: r562022 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml

2007-08-02 Thread Rainer Jung
Update: The problem seems to be coming from a global change of AS400 
defines, which unintentionally also hit two ifndefs, which were 
transformed into ifdefs. As a result, we didn't flush any more, so small 
responses were not flushed before we came to the line checking 
sent_bodyct. That way the whole response got replaced by the apache 
error page.


Important: as far as I can see, this should not have introduced a 
problem with Apache 1.3. I didn't yet test, but if there is a problem 
with 401 for Apache 1.3, then there is also another cause we have to 
look for. I'll test but wanted to quickly give an information update.


And: In case we receive an empty body from Tomcat and an error status 
code (=400), we still throw away the response and let Apache generate a 
new one. More precisely this means, that we throw away all the headers. 
In the 401 case, this way we detected the original problem. I'm not 
sure, if we should really let Apache generate a new local error page 
including headers, if we get an http error code with empty body.


We could also just  pass the response with empty body back to the client.

In fact I was thinking earlier about giving people the chance to decide, 
if they want their error pages coming from apache or from Tomcat. This 
is too complex for a fast fix (as we can see from the 401 example), but 
I think some more thinking after fixing the actual issue would be good.


Regards,

Rainer

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



Re: Juli/Logging

2007-08-02 Thread Remy Maucherat

Rainer Jung wrote:
That's why it would be nice if someone took the burden of writing a 
better log formatter for j.u.l.


Got it.  Yea, that format is certainly grep unfriendly.

Looks like Harmony has a formatter we could copy from and fix to not 
add the new line.


http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java 


Yes, that could be a good starting point (although that implementation 
does not care about localization).


It might be better to use log4j code as a starting point as it already 
has the pattern processing code.


Rémy

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



svn commit: r562090 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 05:10:48 2007
New Revision: 562090

URL: http://svn.apache.org/viewvc?view=revrev=562090
Log:
Revert the quickfix r562022. It looks like we found the real problem
with r562085.

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?view=diffrev=562090r1=562089r2=562090
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Thu Aug  2 05:10:48 
2007
@@ -2159,8 +2159,7 @@
 if (rc  0) {
 /* If tomcat returned no body and the status is not OK,
let apache handle the error code */
-if (!r-sent_bodyct  r-status = HTTP_BAD_REQUEST 
- r-status != HTTP_UNAUTHORIZED) {
+if (!r-sent_bodyct  r-status = HTTP_BAD_REQUEST) {
 jk_log(conf-log, JK_LOG_INFO, No body with status=%d
 for worker=%s,
r-status, worker_name);

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?view=diffrev=562090r1=562089r2=562090
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Thu Aug  2 05:10:48 
2007
@@ -2250,8 +2250,7 @@
 
 /* [EMAIL PROTECTED] : under i5/OS sent_bodyct is not set correctly */
 /*   check for header_only to see if there was a body */
-if (!r-sent_bodyct  r-status = HTTP_BAD_REQUEST 
- r-status != HTTP_UNAUTHORIZED) {
+if (!r-sent_bodyct  r-status = HTTP_BAD_REQUEST) {
 jk_log(xconf-log, JK_LOG_INFO, No body with status=%d
 for worker=%s,
r-status, worker_name);



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



Re: svn commit: r562090 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c

2007-08-02 Thread Mladen Turk

[EMAIL PROTECTED] wrote:

Author: rjung
Date: Thu Aug  2 05:10:48 2007
New Revision: 562090

URL: http://svn.apache.org/viewvc?view=revrev=562090
Log:
Revert the quickfix r562022. It looks like we found the real problem
with r562085.



Perfect. The fix makes login working once again.

Regards,
Mladen

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



svn commit: r562109 - in /tomcat/site/trunk: docs/download-connectors.html xdocs/download-connectors.xml

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 06:43:54 2007
New Revision: 562109

URL: http://svn.apache.org/viewvc?view=revrev=562109
Log:
Withdraw JK 1.2.24 relase.
Revert download page to 1.2.23 and add a warning concerning the withdrawal.

Modified:
tomcat/site/trunk/docs/download-connectors.html
tomcat/site/trunk/xdocs/download-connectors.xml

Modified: tomcat/site/trunk/docs/download-connectors.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/download-connectors.html?view=diffrev=562109r1=562108r2=562109
==
--- tomcat/site/trunk/docs/download-connectors.html (original)
+++ tomcat/site/trunk/docs/download-connectors.html Thu Aug  2 06:43:54 2007
@@ -225,7 +225,7 @@
 li class=group
 div class=links
 span class=labelJK 1.2 (b
-a href=security-jk.htmlWARNING: Important vulnerabilities in previous 
versions/a
+a href=security-jk.htmlWARNING: Release 1.2.24 has been withdrawn./a
 /b) 
 /span
 /div
@@ -236,18 +236,18 @@
 /div
 ul
 li class=download
-a 
href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.tar.gzJK
 1.2.24 Source Release tar.gz/a (e.g. Unix, Linux, Mac OS)
+a 
href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.tar.gzJK
 1.2.23 Source Release tar.gz/a (e.g. Unix, Linux, Mac OS)
 ul class=attributes
 li
-span class=pgp[a 
href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.tar.gz.asc;pgp/a]/span
+span class=pgp[a 
href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.tar.gz.asc;pgp/a]/span
 /li
 /ul
 /li
 li class=download
-a 
href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.zipJK
 1.2.24 Source Release zip/a (e.g. Windows)
+a 
href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.zipJK
 1.2.23 Source Release zip/a (e.g. Windows)
 ul class=attributes
 li
-span class=pgp[a 
href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.zip.asc;pgp/a]/span
+span class=pgp[a 
href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.zip.asc;pgp/a]/span
 /li
 /ul
 /li

Modified: tomcat/site/trunk/xdocs/download-connectors.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/download-connectors.xml?view=diffrev=562109r1=562108r2=562109
==
--- tomcat/site/trunk/xdocs/download-connectors.xml (original)
+++ tomcat/site/trunk/xdocs/download-connectors.xml Thu Aug  2 06:43:54 2007
@@ -26,17 +26,17 @@
 /div
 ul class=downloads
 li class=group
-div class=linksspan class=labelJK 1.2 (ba 
href=security-jk.htmlWARNING: Important vulnerabilities in previous 
versions/a/b) 
+div class=linksspan class=labelJK 1.2 (ba 
href=security-jk.htmlWARNING: Release 1.2.24 has been withdrawn./a/b) 
 /span/div
 ulli class=group
 div class=linksspan class=labelSource (please choose the 
correct format for your platform)/span/div
-ulli class=downloada 
href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.tar.gzJK
 1.2.24 Source Release tar.gz/a (e.g. Unix, Linux, Mac OS)
-ul class=attributeslispan class=pgp[a 
href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.tar.gz.asc;pgp/a]/span
+ulli class=downloada 
href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.tar.gzJK
 1.2.23 Source Release tar.gz/a (e.g. Unix, Linux, Mac OS)
+ul class=attributeslispan class=pgp[a 
href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.tar.gz.asc;pgp/a]/span
 /li
 /ul
 /li
-li class=downloada 
href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.zipJK
 1.2.24 Source Release zip/a (e.g. Windows)
-ul class=attributeslispan class=pgp[a 
href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.zip.asc;pgp/a]/span
+li class=downloada 
href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.zipJK
 1.2.23 Source Release zip/a (e.g. Windows)
+ul class=attributeslispan class=pgp[a 
href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.zip.asc;pgp/a]/span
 /li
 /ul
 /li



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

Re: mod_jk 1.2.24 withdrawal?

2007-08-02 Thread Mladen Turk

I agree. Remove 1.2.24 and include all the patches.
Let's roll that ASAP.

Regards,
Mladen.



Rainer Jung wrote:
I think the problem with JK 1.2.24 is big enough to release soon. I 
would also suggest to officially withdraw 1.2.24 from the download and 
web site (with a comment indicating the problem) so that people will not 
run into more complex problems related to the missing flush. Although 
we've got no indication, that there will be a security problem, the 
missing flushing can lead to undefined behaviour.


Users needed to wait for a post 1.2.23 update for 2.5 months, so 1-2 
more weeks will be OK.


Additionally the question is: should we include other fixes or strictly 
only 1.2.24 + this fix. If we remove 1.2.24 I think the other fixes 
listed below will be safe. I would propose to include them and run 
through the usual Quality check + release cycle, we've done a couple of 
times for JK.


r560736 (fuankg): additional defines in jk_globalh. if __GNUC__ is 
defined for WIN32 or Netware. This should enable gcc builds on these 
platforms. Looks like very low risk, because until now we don't support 
building with gcc on these platforms, so the change looks like it can't 
break anything.


r560739 (fuankg): Change in Netware Makefile for Apache 1.3. I think 
Günter knows best, if this should be released.


r560823 (rjung): changed pid_t print format detection for Solaris. 
Tested with gcc and cc for 32 Bit and 64 Bit build on Solaris Sparc. Not 
tested for Solaris x86, but until now I think we do not actively support 
this.


r560831 (rjung): Fix nsapi crash with debug log during startup. Very 
local change, low risk.


r562085 (rjung): Fix 401 problem. That's the one we definitely need.

Outstanding changes:

fail on status
--

http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch

Improve nsapi shut down
---

Index: netscape/jk_nsapi_plugin.c
===
--- netscape/jk_nsapi_plugin.c  (revision 562051)
+++ netscape/jk_nsapi_plugin.c  (working copy)
@@ -320,14 +320,15 @@
 uri_worker_map_free(uw_map, logger);
 }

+if (init_map) {
+jk_map_free(init_map);
+}
+
+jk_shm_close();
 wc_close(logger);
 if (logger) {
 jk_close_file_logger(logger);
 }
-
-if (init_map) {
-jk_map_free(init_map);
-}
 }


Improve nsapi returning correctly when errors occur
---

Index: netscape/jk_nsapi_plugin.c
===
--- netscape/jk_nsapi_plugin.c  (revision 562051)
+++ netscape/jk_nsapi_plugin.c  (working copy)
@@ -382,10 +382,14 @@
 }
 else {
 if ((result == JK_CLIENT_ERROR)  (is_error == 
JK_HTTP_OK)) {

+rc = REQ_EXIT;
+protocol_status(sn, rq, is_error, NULL);
 jk_log(logger, JK_LOG_INFO,
service() failed because client aborted 
connection);

 }
 else {
+rc = REQ_ABORTED;
+protocol_status(sn, rq, is_error, NULL);
 jk_log(logger, JK_LOG_ERROR,
service() failed with http error %d, 
is_error);

 }


nsapi and shm
--

For Netware nsapi now has a build dependency on shm although it doesn't 
use it. More generally, we need to check which way we should use shm for 
nsapi on which platform. I think the nsapi and general platforms 
considerations should not be done before 1.2.25, but everything else 
looks OK to me.


Regards,

Rainer

Mladen Turk wrote:

[EMAIL PROTECTED] wrote:

Author: rjung
Date: Thu Aug  2 05:10:48 2007
New Revision: 562090

URL: http://svn.apache.org/viewvc?view=revrev=562090
Log:
Revert the quickfix r562022. It looks like we found the real problem
with r562085.



Perfect. The fix makes login working once again.

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]



mod_jk 1.2.24 withdrawal?

2007-08-02 Thread Rainer Jung
I think the problem with JK 1.2.24 is big enough to release soon. I 
would also suggest to officially withdraw 1.2.24 from the download and 
web site (with a comment indicating the problem) so that people will not 
run into more complex problems related to the missing flush. Although 
we've got no indication, that there will be a security problem, the 
missing flushing can lead to undefined behaviour.


Users needed to wait for a post 1.2.23 update for 2.5 months, so 1-2 
more weeks will be OK.


Additionally the question is: should we include other fixes or strictly 
only 1.2.24 + this fix. If we remove 1.2.24 I think the other fixes 
listed below will be safe. I would propose to include them and run 
through the usual Quality check + release cycle, we've done a couple of 
times for JK.


r560736 (fuankg): additional defines in jk_globalh. if __GNUC__ is 
defined for WIN32 or Netware. This should enable gcc builds on these 
platforms. Looks like very low risk, because until now we don't support 
building with gcc on these platforms, so the change looks like it can't 
break anything.


r560739 (fuankg): Change in Netware Makefile for Apache 1.3. I think 
Günter knows best, if this should be released.


r560823 (rjung): changed pid_t print format detection for Solaris. 
Tested with gcc and cc for 32 Bit and 64 Bit build on Solaris Sparc. Not 
tested for Solaris x86, but until now I think we do not actively support 
this.


r560831 (rjung): Fix nsapi crash with debug log during startup. Very 
local change, low risk.


r562085 (rjung): Fix 401 problem. That's the one we definitely need.

Outstanding changes:

fail on status
--

http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch

Improve nsapi shut down
---

Index: netscape/jk_nsapi_plugin.c
===
--- netscape/jk_nsapi_plugin.c  (revision 562051)
+++ netscape/jk_nsapi_plugin.c  (working copy)
@@ -320,14 +320,15 @@
 uri_worker_map_free(uw_map, logger);
 }

+if (init_map) {
+jk_map_free(init_map);
+}
+
+jk_shm_close();
 wc_close(logger);
 if (logger) {
 jk_close_file_logger(logger);
 }
-
-if (init_map) {
-jk_map_free(init_map);
-}
 }


Improve nsapi returning correctly when errors occur
---

Index: netscape/jk_nsapi_plugin.c
===
--- netscape/jk_nsapi_plugin.c  (revision 562051)
+++ netscape/jk_nsapi_plugin.c  (working copy)
@@ -382,10 +382,14 @@
 }
 else {
 if ((result == JK_CLIENT_ERROR)  (is_error == 
JK_HTTP_OK)) {

+rc = REQ_EXIT;
+protocol_status(sn, rq, is_error, NULL);
 jk_log(logger, JK_LOG_INFO,
service() failed because client 
aborted connection);

 }
 else {
+rc = REQ_ABORTED;
+protocol_status(sn, rq, is_error, NULL);
 jk_log(logger, JK_LOG_ERROR,
service() failed with http error %d, 
is_error);

 }


nsapi and shm
--

For Netware nsapi now has a build dependency on shm although it doesn't 
use it. More generally, we need to check which way we should use shm for 
nsapi on which platform. I think the nsapi and general platforms 
considerations should not be done before 1.2.25, but everything else 
looks OK to me.


Regards,

Rainer

Mladen Turk wrote:

[EMAIL PROTECTED] wrote:

Author: rjung
Date: Thu Aug  2 05:10:48 2007
New Revision: 562090

URL: http://svn.apache.org/viewvc?view=revrev=562090
Log:
Revert the quickfix r562022. It looks like we found the real problem
with r562085.



Perfect. The fix makes login working once again.

Regards,
Mladen


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



Re: mod_jk 1.2.24 withdrawal?

2007-08-02 Thread Rainer Jung

I withdrew the release from the server:

- removed 1.2.24 source and binaries from www.apache.org/dist/...
- put back 1.2.23 source and binaries from archive
- reverted the download page and added a warning
- added a withdrawal note to the index and news page in the live online 
docs.


It will take the usual time to sync to www.a.o/tomcat.a.o and the mirrors.

I'm going to send a note to the users and dev list.

Regards,

Rainer

Mladen Turk wrote:

I agree. Remove 1.2.24 and include all the patches.
Let's roll that ASAP.

Regards,
Mladen.


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



[ANN] Withdrawal of Apache Tomcat JK 1.2.24 Web Server Connectors

2007-08-02 Thread Rainer Jung
The Apache Tomcat team needs to withdraw release 1.2.24 of the Apache 
Tomcat Connectors.


The release contains a bug that prevents the correct flushing of parts 
of responses from the web server to the client. This might result in 
unpredicted communication behaviour. We therefore have removed the 
source and binary distributions from the origin server.


A fix for the problem has already been committed. We expect release of 
version 1.2.25 in sometime next week.


We apologise for any inconvenience,

-- The Apache Tomcat Team





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



svn commit: r562127 - /tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 07:39:04 2007
New Revision: 562127

URL: http://svn.apache.org/viewvc?view=revrev=562127
Log:
Allow missing shm_file attribute for nsapi plugin
on WIN32 and Netware platforms.

Modified:
tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c

Modified: tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c?view=diffrev=562127r1=562126r2=562127
==
--- tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c (original)
+++ tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c Thu Aug  2 
07:39:04 2007
@@ -231,6 +231,7 @@
 char *log_level_str = pblock_findval(JK_LOG_LEVEL_TAG, pb);
 char *log_file = pblock_findval(JK_LOG_FILE_TAG, pb);
 char *shm_file = pblock_findval(JK_SHM_FILE_TAG, pb);
+char *shm_file_safe = ;
 char *reject_unsafe = pblock_findval(REJECT_UNSAFE_TAG, pb);
 
 int rc = REQ_ABORTED;
@@ -249,11 +250,16 @@
 return rc;
 }
 
-if (!shm_file) {
+if (shm_file) {
+shm_file_safe = shm_file;
+}
+#if !defined(WIN32)  !defined(NETWARE)
+else {
 fprintf(stderr,
 Missing attribute %s in magnus.conf (jk_init) - aborting!\n, 
JK_SHM_FILE_TAG);
 return rc;
 }
+#endif
 
 fprintf(stderr,
 In jk_init.\n   Worker file = %s.\n   Log level = %s.\n   Log 
File = %s\n   SHM File = %s\n,



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



svn commit: r562129 - /tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 07:43:08 2007
New Revision: 562129

URL: http://svn.apache.org/viewvc?view=revrev=562129
Log:
Add correct plugin return when service ends with an error.

Modified:
tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c

Modified: tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c?view=diffrev=562129r1=562128r2=562129
==
--- tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c (original)
+++ tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c Thu Aug  2 
07:43:08 2007
@@ -387,11 +387,14 @@
service() returned OK);
 }
 else {
+protocol_status(sn, rq, is_error, NULL);
 if ((result == JK_CLIENT_ERROR)  (is_error == 
JK_HTTP_OK)) {
+rc = REQ_EXIT;
 jk_log(logger, JK_LOG_INFO,
service() failed because client aborted 
connection);
 }
 else {
+rc = REQ_ABORTED;
 jk_log(logger, JK_LOG_ERROR,
service() failed with http error %d, 
is_error);
 }



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



svn commit: r562131 - /tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 07:47:00 2007
New Revision: 562131

URL: http://svn.apache.org/viewvc?view=revrev=562131
Log:
Move fail on status a little down the protocol
stack, so that we haven't yet returned the headers.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c

Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c?view=diffrev=562131r1=562130r2=562131
==
--- tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Thu Aug  2 
07:47:00 2007
@@ -1423,6 +1423,18 @@
 return (JK_TRUE);
 }
 
+
+static int is_http_status_fail(ajp_worker_t *w, int status)
+{
+unsigned int i;
+for (i = 0; i  w-http_status_fail_num; i++) {
+if (w-http_status_fail[i] == status)
+return 1;
+}
+return 0;
+}
+
+
 /*
  * What to do with incoming data (dispatcher)
  */
@@ -1445,13 +1457,17 @@
 JK_TRACE_EXIT(l);
 return JK_AJP13_ERROR;
 }
+r-http_response_status = res.status;
+if (is_http_status_fail(ae-worker, res.status)) {
+JK_TRACE_EXIT(l);
+return JK_STATUS_ERROR;
+}
 r-start_response(r, res.status, res.msg,
   (const char *const *)res.header_names,
   (const char *const *)res.header_values,
   res.num_headers);
 if (r-flush  r-flush_header)
 r-flush(r);
-r-http_response_status = res.status;
 }
 return JK_AJP13_SEND_HEADERS;
 
@@ -1564,17 +1580,6 @@
 return JK_AJP13_NO_RESPONSE;
 }
 
-static int is_http_status_fail(ajp_worker_t *w, int status)
-{
-unsigned int i;
-for (i = 0; i  w-http_status_fail_num; i++) {
-if (w-http_status_fail[i] == status)
-return 1;
-}
-return 0;
-}
-
-
 /*
  * get replies from Tomcat via Ajp13/Ajp14
  * We will know only at read time if the remote host closed
@@ -1733,11 +1738,11 @@
 return JK_TRUE;
 }
 else if (JK_AJP13_SEND_HEADERS == rc) {
-if (is_http_status_fail(p-worker, s-http_response_status)) {
-JK_TRACE_EXIT(l);
-return JK_STATUS_ERROR;
-}
 headeratclient = JK_TRUE;
+}
+else if (JK_STATUS_ERROR == rc) {
+JK_TRACE_EXIT(l);
+return JK_STATUS_ERROR;
 }
 else if (JK_AJP13_HAS_RESPONSE == rc) {
 /*



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



svn commit: r562130 - /tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 07:45:24 2007
New Revision: 562130

URL: http://svn.apache.org/viewvc?view=revrev=562130
Log:
Fix shm shutdown behaviour of nsapi plugin.

Modified:
tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c

Modified: tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c?view=diffrev=562130r1=562129r2=562130
==
--- tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c (original)
+++ tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c Thu Aug  2 
07:45:24 2007
@@ -326,13 +326,14 @@
 uri_worker_map_free(uw_map, logger);
 }
 
+if (init_map) {
+jk_map_free(init_map);
+}
+
+jk_shm_close();
 wc_close(logger);
 if (logger) {
 jk_close_file_logger(logger);
-}
-
-if (init_map) {
-jk_map_free(init_map);
 }
 }
 



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



Re: Juli/Logging

2007-08-02 Thread Costin Manolache
I think something is missing - DirectJDKLog is looking for a
JdkLoggerFormatter that would do
the trick. I may have forgot to add it, I have it on my machine ( I hate too
the default format ).
There's also a config override allowing default properties to be loaded from
a different location.

Costin

On 8/2/07, Remy Maucherat [EMAIL PROTECTED] wrote:

 Rainer Jung wrote:
  That's why it would be nice if someone took the burden of writing a
  better log formatter for j.u.l.
 
  Got it.  Yea, that format is certainly grep unfriendly.
 
  Looks like Harmony has a formatter we could copy from and fix to not
  add the new line.
 
 
 http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java
 
  Yes, that could be a good starting point (although that implementation
  does not care about localization).

 It might be better to use log4j code as a starting point as it already
 has the pattern processing code.

 Rémy

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




Re: Juli/Logging

2007-08-02 Thread Remy Maucherat

Costin Manolache wrote:

I think something is missing - DirectJDKLog is looking for a
JdkLoggerFormatter that would do
the trick. I may have forgot to add it, I have it on my machine ( I hate too
the default format ).
There's also a config override allowing default properties to be loaded from
a different location.


I don't think I removed those two classes, so feel free to add them. You 
don't need to hardcode configuration, the LogManager that replaces the 
default one supports a lot of stuff.


Rémy

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



svn commit: r562174 - in /tomcat/connectors/trunk/jk/native/common: jk_status.c jk_uri_worker_map.c

2007-08-02 Thread jim
Author: jim
Date: Thu Aug  2 09:28:29 2007
New Revision: 562174

URL: http://svn.apache.org/viewvc?view=revrev=562174
Log:
These are local functions; ensure we don't clobber
things and handle compiler warnings about prototypes.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_status.c
tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

Modified: tomcat/connectors/trunk/jk/native/common/jk_status.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_status.c?view=diffrev=562174r1=562173r2=562174
==
--- tomcat/connectors/trunk/jk/native/common/jk_status.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_status.c Thu Aug  2 09:28:29 
2007
@@ -733,7 +733,7 @@
 return def;
 }
 
-const char *status_cmd_text(int cmd)
+static const char *status_cmd_text(int cmd)
 {
 return cmd_type[cmd];
 }
@@ -759,7 +759,7 @@
 return JK_STATUS_CMD_UNKNOWN;
 }
 
-const char *status_mime_text(int mime)
+static const char *status_mime_text(int mime)
 {
 return mime_type[mime];
 }

Modified: tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c?view=diffrev=562174r1=562173r2=562174
==
--- tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c Thu Aug  2 
09:28:29 2007
@@ -276,7 +276,7 @@
  * Delete all entries of a given source type
  */
 
-int uri_worker_map_clear(jk_uri_worker_map_t *uw_map,
+static int uri_worker_map_clear(jk_uri_worker_map_t *uw_map,
  unsigned int source_type, jk_logger_t *l)
 {
 uri_worker_record_t *uwr = NULL;



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



svn commit: r562175 - /tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 09:30:45 2007
New Revision: 562175

URL: http://svn.apache.org/viewvc?view=revrev=562175
Log:
Add usual info log message containing version during nsapi startup.

Modified:
tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c

Modified: tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c?view=diffrev=562175r1=562174r2=562175
==
--- tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c (original)
+++ tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c Thu Aug  2 
09:30:45 2007
@@ -297,6 +297,8 @@
 if (init_on_other_thread_is_done  init_on_other_thread_is_ok) {
 magnus_atrestart(jk_term, NULL);
 rc = REQ_PROCEED;
+jk_log(logger, JK_LOG_INFO, nsapi_redirector/%s initialized,
+   JK_VERSTRING);
 }
 
 /*if(wc_open(init_map, NULL, logger)) {



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



svn commit: r562182 - in /tomcat/connectors/trunk/jk/native/netscape: Makefile.linux Makefile.solaris

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 09:54:20 2007
New Revision: 562182

URL: http://svn.apache.org/viewvc?view=revrev=562182
Log:
Improve nsapi Makefiles a bit:
- remove unnecessary differences between Solaris and Linux
- Use CC and CFLAGS
Next step will be configure based generation of the makefile.
Not in this release, because automake doesn't really support
Sun Studio compiler well (KPIC has been obsoleted by -xcode).

Modified:
tomcat/connectors/trunk/jk/native/netscape/Makefile.linux
tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris

Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.linux
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.linux?view=diffrev=562182r1=562181r2=562182
==
--- tomcat/connectors/trunk/jk/native/netscape/Makefile.linux (original)
+++ tomcat/connectors/trunk/jk/native/netscape/Makefile.linux Thu Aug  2 
09:54:20 2007
@@ -1,13 +1,17 @@
 # Defines for example NSAPI programs running under Linux
 
-#gcc
+# gcc
 # If you get relocation errors, try:
 #   1. compiling with Sun's cc
 #   2. statically linking with libgcc
 #   3. Adjusting LD_LIBRARY_PATH to grab libgcc_s
-CC_CMD=gcc -fpic -DNET_SSL -DLinux -DLINUX -D_REENTRANT -DXP_UNIX
+CC=gcc
+# For 64 Bit builds, add -m64 to CFLAGS
+CFLAGS=-fPIC
+LD_SHAREDCMD=$(CC) -shared -lthread
 
-LD_SHAREDCMD=gcc -shared
+CC_CMD=$(CC) $(CFLAGS) -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \
+   -DMCC_HTTPD -DSPAPI20
 
 OS_TYPE=linux
 INCLUDEDIR=$(SUITSPOT_HOME)/include
@@ -28,7 +32,7 @@
 all: nsapi_redirector.so 
 
 
-nsapi_redirector.so: $(PLUGIN_OBJ) $(JK_OBJS)
+nsapi_redirector.so: $(JK_OBJS) $(PLUGIN_OBJ)
$(LD_SHAREDCMD) $(JK_OBJS) $(PLUGIN_OBJ) -o nsapi_redirector.so 
$(EXTRA_LDDEFINES)
 
 clean:

Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris?view=diffrev=562182r1=562181r2=562182
==
--- tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris (original)
+++ tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris Thu Aug  2 
09:54:20 2007
@@ -1,20 +1,25 @@
 # Defines for example NSAPI programs running under SOLARIS
 
-#gcc
+# Choose between the settings for gcc or Sun Studio compiler
+
+# gcc
 # If you get relocation errors, try:
 #   1. compiling with Sun's cc
 #   2. statically linking with libgcc
 #   3. Adjusting LD_LIBRARY_PATH to grab libgcc_s
-CC_CMD=gcc -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \
-   -DMCC_HTTPD -DSPAPI20 \
-   -fPIC
-
-#SunStudio cc compiler
-#CC_CMD=cc -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \
-#  -DMCC_HTTPD -DSPAPI20 \
-#  -xcode=pic32
+CC=gcc
+# For 64 Bit builds, add -m64 to CFLAGS
+CFLAGS=-fPIC
+LD_SHAREDCMD=$(CC) -shared -lthread
+
+# Sun Studio cc compiler
+#CC=cc
+# For 64 Bit builds, add -xtarget=generic64 to CFLAGS and #LD_SHAREDCMD
+#CFLAGS=-xcode=pic32
+#LD_SHAREDCMD=$(CC) -G -lthread
 
-LD_SHAREDCMD=ld -G -fPIC
+CC_CMD=$(CC) $(CFLAGS) -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \
+   -DMCC_HTTPD -DSPAPI20
 
 all:
 
@@ -44,4 +49,4 @@
rm -f *.o nsapi_redirector.so $(JK_OBJS)
 
 %.o : %.c
-   $(CC_CMD) $(INCLUDE_FLAGS) -c $ 
+   $(CC_CMD) $(INCLUDE_FLAGS) -c $



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



svn commit: r562184 - /tomcat/connectors/trunk/jk/native/netscape/Makefile.linux

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 10:09:15 2007
New Revision: 562184

URL: http://svn.apache.org/viewvc?view=revrev=562184
Log:
Fix linux Makefile error for nsapi from previous commit.

Modified:
tomcat/connectors/trunk/jk/native/netscape/Makefile.linux

Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.linux
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.linux?view=diffrev=562184r1=562183r2=562184
==
--- tomcat/connectors/trunk/jk/native/netscape/Makefile.linux (original)
+++ tomcat/connectors/trunk/jk/native/netscape/Makefile.linux Thu Aug  2 
10:09:15 2007
@@ -7,7 +7,7 @@
 #   3. Adjusting LD_LIBRARY_PATH to grab libgcc_s
 CC=gcc
 # For 64 Bit builds, add -m64 to CFLAGS
-CFLAGS=-fPIC
+CFLAGS=-fPIC
 LD_SHAREDCMD=$(CC) -shared -lthread
 
 CC_CMD=$(CC) $(CFLAGS) -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \



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



svn commit: r562186 - /tomcat/connectors/trunk/jk/xdocs/reference/workers.xml

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 10:20:07 2007
New Revision: 562186

URL: http://svn.apache.org/viewvc?view=revrev=562186
Log:
Clarify fail_on-Status behaviour in docs.

Modified:
tomcat/connectors/trunk/jk/xdocs/reference/workers.xml

Modified: tomcat/connectors/trunk/jk/xdocs/reference/workers.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/reference/workers.xml?view=diffrev=562186r1=562185r2=562186
==
--- tomcat/connectors/trunk/jk/xdocs/reference/workers.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/reference/workers.xml Thu Aug  2 10:20:07 
2007
@@ -686,9 +686,16 @@
 
 directive name=fail_on_status workers=AJP,SUB default=0 
required=false
 Set this value to the HTTP status code that will cause a worker to fail
-if returned from Servlet contatiner. Use this directive to deal with
+if returned from Servlet container. Use this directive to deal with
 cases when the servlet container can temporary return non-200 responses
 for a short amount of time, e.g during redeployment.
+p
+The error page, headers and status codes of the original response will not be 
send back
+to the client. Instead the request will result in a 503 response.
+If the worker is a member of a load balancer, the member will
+be put into an error state. Request failover and worker recovery will be 
handled
+with the usual load balancer procedures.
+/p
 p
 This feature has been added in bjk 1.2.20/b.
 /p



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



Re: Juli/Logging

2007-08-02 Thread Rainer Jung

Hi Costin (and Remy),

I had a quick look at the JdkLoggerFormatter (found in an old revision 
of the sandbox, it's not there any more):


this formatter uses a *very* compact format. E.g. the timestamp is just 
the milliseconds and the log level is abbreviated with a single 
character. Although technically very useful, I doubt that most admins 
will like it at first sight, so it might not be a good default 
replacement for the JDK simple formatter. Still searching ...


Regards,

Rainer

Costin Manolache wrote:

I think something is missing - DirectJDKLog is looking for a
JdkLoggerFormatter that would do
the trick. I may have forgot to add it, I have it on my machine ( I hate too
the default format ).
There's also a config override allowing default properties to be loaded from
a different location.

Costin

On 8/2/07, Remy Maucherat [EMAIL PROTECTED] wrote:

Rainer Jung wrote:

That's why it would be nice if someone took the burden of writing a
better log formatter for j.u.l.

Got it.  Yea, that format is certainly grep unfriendly.

Looks like Harmony has a formatter we could copy from and fix to not
add the new line.



http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java

Yes, that could be a good starting point (although that implementation
does not care about localization).

It might be better to use log4j code as a starting point as it already
has the pattern processing code.

Rémy


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



svn commit: r562187 - /tomcat/tc6.0.x/trunk/java/org/apache/juli/JdkLoggerFormatter.java

2007-08-02 Thread costin
Author: costin
Date: Thu Aug  2 10:25:21 2007
New Revision: 562187

URL: http://svn.apache.org/viewvc?view=revrev=562187
Log:
Add a simple one-line formatter. 


Added:
tomcat/tc6.0.x/trunk/java/org/apache/juli/JdkLoggerFormatter.java
  - copied, changed from r415842, 
tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerFormatter.java

Copied: tomcat/tc6.0.x/trunk/java/org/apache/juli/JdkLoggerFormatter.java (from 
r415842, tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerFormatter.java)
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/juli/JdkLoggerFormatter.java?view=diffrev=562187p1=tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerFormatter.javar1=415842p2=tomcat/tc6.0.x/trunk/java/org/apache/juli/JdkLoggerFormatter.javar2=562187
==
--- tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerFormatter.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/juli/JdkLoggerFormatter.java Thu Aug  
2 10:25:21 2007
@@ -15,7 +15,7 @@
  * limitations under the License.
  */ 
 
-package org.apache.tomcat.util.log;
+package org.apache.juli;
 
 import java.util.logging.Formatter;
 import java.util.logging.LogRecord;



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



svn commit: r562190 - /tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 10:32:56 2007
New Revision: 562190

URL: http://svn.apache.org/viewvc?view=revrev=562190
Log:
Update changelog for JK.

Modified:
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml

Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?view=diffrev=562190r1=562189r2=562190
==
--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Thu Aug  2 
10:32:56 2007
@@ -27,8 +27,44 @@
   br /
   subsection name=Native
 changelog
+  update
+NSAPI: Add initialization startup message containing JK version. 
(rjung)
+  /update
   fix
-Pass the 401 as OK instead sending 401 for authentication. (mturk)
+General: Declare static functions as static. (jim)
+  /fix
+  update
+Documentation: Clarify fail_on_status behaviour. (rjung)
+  /update
+  fix
+General: Do fail_on_status before returning the response headers. 
(rjung)
+  /fix
+  update
+NSAPI: Fix shm shutdown behaviour. (rjung)
+  /update
+  update
+NSAPI: Set return status even if request ended with an error. (rjung)
+  /update
+  update
+NSAPI: Allow using without shm_file on WIN32 and Netware. (rjung)
+  /update
+  fix
+NSAPI: Fix Crash of nsapi for log level debug and unset refect_unsafe. 
(rjung)
+  /fix
+  update
+NSAPI: Improve Solaris and Linux Makefiles for nsapi build. (rjung)
+  /update
+  fix
+Build: Improve pid_t type detection during configure on Solaris. 
(rjung)
+  /fix
+  update
+Build: Experimental build support for gcc on WIN32 and Netware. 
(fuankg)
+  /update
+  update
+Build: Makefile optimizations for Apache httpd 1.3/Netware . (fuankg)
+  /update
+  fix
+General: Fix missing flush bug introduced in 1.2.24. (rjung)
   /fix
 /changelog
   /subsection



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



svn commit: r562201 - in /tomcat/connectors/trunk/jk/native/netscape: Makefile.linux Makefile.solaris

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 10:54:15 2007
New Revision: 562201

URL: http://svn.apache.org/viewvc?view=revrev=562201
Log:
Fix comments about 64Bit building nsapi plugin in Makefiles.

Modified:
tomcat/connectors/trunk/jk/native/netscape/Makefile.linux
tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris

Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.linux
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.linux?view=diffrev=562201r1=562200r2=562201
==
--- tomcat/connectors/trunk/jk/native/netscape/Makefile.linux (original)
+++ tomcat/connectors/trunk/jk/native/netscape/Makefile.linux Thu Aug  2 
10:54:15 2007
@@ -6,7 +6,7 @@
 #   2. statically linking with libgcc
 #   3. Adjusting LD_LIBRARY_PATH to grab libgcc_s
 CC=gcc
-# For 64 Bit builds, add -m64 to CFLAGS
+# For 64 Bit builds, add -m64 to CFLAGS and LD_SHAREDCMD
 CFLAGS=-fPIC
 LD_SHAREDCMD=$(CC) -shared -lthread
 

Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris?view=diffrev=562201r1=562200r2=562201
==
--- tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris (original)
+++ tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris Thu Aug  2 
10:54:15 2007
@@ -8,13 +8,13 @@
 #   2. statically linking with libgcc
 #   3. Adjusting LD_LIBRARY_PATH to grab libgcc_s
 CC=gcc
-# For 64 Bit builds, add -m64 to CFLAGS
+# For 64 Bit builds, add -m64 to CFLAGS and LD_SHAREDCMD
 CFLAGS=-fPIC
 LD_SHAREDCMD=$(CC) -shared -lthread
 
 # Sun Studio cc compiler
 #CC=cc
-# For 64 Bit builds, add -xtarget=generic64 to CFLAGS and #LD_SHAREDCMD
+# For 64 Bit builds, add -xtarget=generic64 to CFLAGS and LD_SHAREDCMD
 #CFLAGS=-xcode=pic32
 #LD_SHAREDCMD=$(CC) -G -lthread
 



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



svn commit: r562198 - in /tomcat/connectors/trunk/jk: native/iis/jk_isapi_plugin.c xdocs/miscellaneous/changelog.xml

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 10:44:25 2007
New Revision: 562198

URL: http://svn.apache.org/viewvc?view=revrev=562198
Log:
Fix shm shutdown behaviour for IIS.

Modified:
tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml

Modified: tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c?view=diffrev=562198r1=562197r2=562198
==
--- tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c (original)
+++ tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c Thu Aug  2 10:44:25 
2007
@@ -1604,6 +1604,7 @@
 }
 jk_map_free(rregexp_map);
 }
+jk_shm_close();
 wc_close(logger);
 if (logger) {
 jk_close_file_logger(logger);

Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?view=diffrev=562198r1=562197r2=562198
==
--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Thu Aug  2 
10:44:25 2007
@@ -28,6 +28,9 @@
   subsection name=Native
 changelog
   update
+IIS: Fix shm shutdown behaviour. (rjung)
+  /update
+  update
 General: fail_on_status used in a load balancer can optionally
 do fail over without putting the failed worker in error state. (rjung)
   /update



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



Re: Juli/Logging

2007-08-02 Thread Costin Manolache
Can be changed to include a better date format.

I used this to look at execution times and start time - so millis was quite
nice. Also more
efficient to generate.

Costin

On 8/2/07, Rainer Jung [EMAIL PROTECTED] wrote:

 Hi Costin (and Remy),

 I had a quick look at the JdkLoggerFormatter (found in an old revision
 of the sandbox, it's not there any more):

 this formatter uses a *very* compact format. E.g. the timestamp is just
 the milliseconds and the log level is abbreviated with a single
 character. Although technically very useful, I doubt that most admins
 will like it at first sight, so it might not be a good default
 replacement for the JDK simple formatter. Still searching ...

 Regards,

 Rainer

 Costin Manolache wrote:
  I think something is missing - DirectJDKLog is looking for a
  JdkLoggerFormatter that would do
  the trick. I may have forgot to add it, I have it on my machine ( I hate
 too
  the default format ).
  There's also a config override allowing default properties to be loaded
 from
  a different location.
 
  Costin
 
  On 8/2/07, Remy Maucherat [EMAIL PROTECTED] wrote:
  Rainer Jung wrote:
  That's why it would be nice if someone took the burden of writing a
  better log formatter for j.u.l.
  Got it.  Yea, that format is certainly grep unfriendly.
 
  Looks like Harmony has a formatter we could copy from and fix to not
  add the new line.
 
 
 
 http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java
  Yes, that could be a good starting point (although that implementation
  does not care about localization).
  It might be better to use log4j code as a starting point as it already
  has the pattern processing code.
 
  Rémy

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




DO NOT REPLY [Bug 29936] - XML parser loading problems by container

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-02 11:08 ---
Eddy, which particular sourceforge webapp did you use to test this?

-- 
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 43002] - NIO connector performance issue in 6.0.13

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-02 11:43 ---
Created an attachment (id=20581)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20581action=view)
JSP That renerates a variable response buffer with configurable sleep delays


-- 
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 43002] - NIO connector performance issue in 6.0.13

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-02 11:44 ---
Created an attachment (id=20582)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20582action=view)
Grinder config file for load test


-- 
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 43002] - NIO connector performance issue in 6.0.13

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-02 11:46 ---
Created an attachment (id=20583)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20583action=view)
Grinder/JPython script that calls response generator JSP for 


-- 
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 43002] - NIO connector performance issue in 6.0.13

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-02 11:53 ---
I've added a simple JSP page to help work the issue.  

The Grinder load test scripts are now separate attachments.

The JSP page is pretty simplistic and I had to push the server hard.   It 
appears that the Content-Length header does not match the response buffer size.

During one of the test runs I got the following exeception in the system logs, 
although it seemed to be an isolated occurance.

===
2007-08-01 17:09:20,364 [http-8080-exec-9] ERROR 
org.apache.catalina.connector.CoyoteAdapter - An exception or error occurred in 
the container during the request processing
java.nio.BufferOverflowException
at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:311)
at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:290)
at sun.nio.ch.IOUtil.write(IOUtil.java:70)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:111)
at org.apache.tomcat.util.net.NioBlockingSelector.write
(NioBlockingSelector.java:57)
at org.apache.tomcat.util.net.NioSelectorPool.write
(NioSelectorPool.java:135)
at org.apache.tomcat.util.net.NioSelectorPool.write
(NioSelectorPool.java:130)
at org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket
(InternalNioOutputBuffer.java:433)
at org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer
(InternalNioOutputBuffer.java:761)
at org.apache.coyote.http11.InternalNioOutputBuffer.endRequest
(InternalNioOutputBuffer.java:398)
at org.apache.coyote.http11.Http11NioProcessor.action
(Http11NioProcessor.java:1089)
at org.apache.coyote.Response.action(Response.java:183)
at org.apache.coyote.Response.finish(Response.java:305)
at org.apache.catalina.connector.OutputBuffer.close
(OutputBuffer.java:276)
at org.apache.catalina.connector.Response.finishResponse
(Response.java:486)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:285)
at org.apache.coyote.http11.Http11NioProcessor.process
(Http11NioProcessor.java:896)
at 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process
(Http11NioProtocol.java:705)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run
(NioEndpoint.java:2049)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask
(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
2007-08-01 17:09:56,255 [http-8080-exec-11] ERROR 
org.apache.catalina.connector.CoyoteAdapter - An exception or error occurred in 
the container during the request processing
java.nio.BufferOverflowException
at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:311)
at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:290)
at sun.nio.ch.IOUtil.write(IOUtil.java:70)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:111)
at org.apache.tomcat.util.net.NioBlockingSelector.write
(NioBlockingSelector.java:57)
at org.apache.tomcat.util.net.NioSelectorPool.write
(NioSelectorPool.java:135)
at org.apache.tomcat.util.net.NioSelectorPool.write
(NioSelectorPool.java:130)
at org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket
(InternalNioOutputBuffer.java:433)
at org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer
(InternalNioOutputBuffer.java:761)
at org.apache.coyote.http11.InternalNioOutputBuffer.endRequest
(InternalNioOutputBuffer.java:398)
at org.apache.coyote.http11.Http11NioProcessor.action
(Http11NioProcessor.java:1089)
at org.apache.coyote.Response.action(Response.java:183)
at org.apache.coyote.Response.finish(Response.java:305)
at org.apache.catalina.connector.OutputBuffer.close
(OutputBuffer.java:276)
at org.apache.catalina.connector.Response.finishResponse
(Response.java:486)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:285)
at org.apache.coyote.http11.Http11NioProcessor.process
(Http11NioProcessor.java:896)
at 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process
(Http11NioProtocol.java:705)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run
(NioEndpoint.java:2049)
at 

Re: svn commit: r562194 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp13.h native/common/jk_ajp_common.c native/common/jk_lb_worker.c xdocs/miscellaneous/changelog.xml xdocs/reference/workers.

2007-08-02 Thread Jim Jagielski


On Aug 2, 2007, at 1:42 PM, [EMAIL PROTECTED] wrote:

== 


--- tomcat/connectors/trunk/jk/native/common/jk_ajp13.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp13.h Thu Aug  2  
10:42:23 2007

@@ -45,7 +45,8 @@
 #define JK_CLIENT_RD_ERROR  (-6)
 #define JK_CLIENT_WR_ERROR  (-7)
 #define JK_STATUS_ERROR (-8)
-#define JK_REPLY_TIMEOUT(-9)
+#define JK_STATUS_FATAL_ERROR   (-9)
+#define JK_REPLY_TIMEOUT(-10)



I'm curious... One reason to use C #defines is to abstract
out the macro and their values. So why, when adding
entries to we force JK_REPLY_TIMEOUT to always be
the lowest value? It shouldn't matter what the
real values are, right? This is especially true if we
ever want to leak these out externally :)


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



svn commit: r562242 - in /tomcat/connectors/trunk/jk/native/netscape: Makefile.linux Makefile.solaris

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 13:27:03 2007
New Revision: 562242

URL: http://svn.apache.org/viewvc?view=revrev=562242
Log:
Another round of Makefile changes for nsapi (Linux/Solaris).

Modified:
tomcat/connectors/trunk/jk/native/netscape/Makefile.linux
tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris

Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.linux
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.linux?view=diffrev=562242r1=562241r2=562242
==
--- tomcat/connectors/trunk/jk/native/netscape/Makefile.linux (original)
+++ tomcat/connectors/trunk/jk/native/netscape/Makefile.linux Thu Aug  2 
13:27:03 2007
@@ -6,12 +6,14 @@
 #   2. statically linking with libgcc
 #   3. Adjusting LD_LIBRARY_PATH to grab libgcc_s
 CC=gcc
-# For 64 Bit builds, add -m64 to CFLAGS and LD_SHAREDCMD
-CFLAGS=-fPIC
-LD_SHAREDCMD=$(CC) -shared -lthread
+# For 64 Bit builds, add -m64 to EXTRA_CFLAGS
+EXTRA_CFLAGS=-fPIC -pthread
+LDFLAGS=-shared
 
-CC_CMD=$(CC) $(CFLAGS) -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \
-   -DMCC_HTTPD -DSPAPI20
+CC_CMD=$(CC) $(CFLAGS) $(EXTRA_CFLAGS) \
+   -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20
+
+LD_SHAREDCMD=$(CC) $(LDFLAGS) $(CFLAGS) $(EXTRA_CFLAGS)
 
 OS_TYPE=linux
 INCLUDEDIR=$(SUITSPOT_HOME)/include

Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris?view=diffrev=562242r1=562241r2=562242
==
--- tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris (original)
+++ tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris Thu Aug  2 
13:27:03 2007
@@ -8,18 +8,20 @@
 #   2. statically linking with libgcc
 #   3. Adjusting LD_LIBRARY_PATH to grab libgcc_s
 CC=gcc
-# For 64 Bit builds, add -m64 to CFLAGS and LD_SHAREDCMD
-CFLAGS=-fPIC
-LD_SHAREDCMD=$(CC) -shared -lthread
+# For 64 Bit builds, add -m64 to EXTRA_CFLAGS
+EXTRA_CFLAGS=-fPIC -pthread
+LDFLAGS=-shared
 
 # Sun Studio cc compiler
 #CC=cc
-# For 64 Bit builds, add -xtarget=generic64 to CFLAGS and LD_SHAREDCMD
-#CFLAGS=-xcode=pic32
-#LD_SHAREDCMD=$(CC) -G -lthread
+# For 64 Bit builds, add -xtarget=generic64 to EXTRA_CFLAGS
+#EXTRA_CFLAGS=-xcode=pic32 -mt
+#LDFLAGS=-G
 
-CC_CMD=$(CC) $(CFLAGS) -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \
-   -DMCC_HTTPD -DSPAPI20
+CC_CMD=$(CC) $(CFLAGS) $(EXTRA_CFLAGS) \
+   -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20
+
+LD_SHAREDCMD=$(CC) $(LDFLAGS) $(CFLAGS) $(EXTRA_CFLAGS)
 
 all:
 



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



Re: Juli/Logging

2007-08-02 Thread Remy Maucherat

Costin Manolache wrote:

Can be changed to include a better date format.

I used this to look at execution times and start time - so millis was quite
nice. Also more
efficient to generate.


Ideally, it would use a pattern property to configure it, like:
logger_prefix.org.apache.juli.PatternFormatter.pattern

Rémy

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



svn commit: r562250 - in /tomcat/connectors/trunk/jk/xdocs: miscellaneous/changelog.xml webserver_howto/nes.xml

2007-08-02 Thread rjung
Author: rjung
Date: Thu Aug  2 13:44:23 2007
New Revision: 562250

URL: http://svn.apache.org/viewvc?view=revrev=562250
Log:
Improve nsapi build description for Unix.

Modified:
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
tomcat/connectors/trunk/jk/xdocs/webserver_howto/nes.xml

Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?view=diffrev=562250r1=562249r2=562250
==
--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Thu Aug  2 
13:44:23 2007
@@ -35,6 +35,9 @@
 do fail over without putting the failed worker in error state. (rjung)
   /update
   update
+NSAPI: Improve build description for Unix. (rjung)
+  /update
+  update
 NSAPI: Add initialization startup message containing JK version. 
(rjung)
   /update
   fix

Modified: tomcat/connectors/trunk/jk/xdocs/webserver_howto/nes.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/webserver_howto/nes.xml?view=diffrev=562250r1=562249r2=562250
==
--- tomcat/connectors/trunk/jk/xdocs/webserver_howto/nes.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/webserver_howto/nes.xml Thu Aug  2 
13:44:23 2007
@@ -463,7 +463,7 @@
 /section
 section name=Building NSAPI so plugin redirector for Unix
 p
-The redirector requires either gcc or the native Solaris cc compiler.
+The redirector requires either gcc (Linux) or gcc or the Sun cc compiler 
(Solaris).
 
 The steps that you need to take are:
 ul
@@ -477,7 +477,15 @@
 Change directory to the nsapi netscape directory (./netstape).
 /li
 li
-Edit bMakefile.solaris/b and update the SUITSPOT_HOME and JAVE_HOME path 
to reflect your own Netscape server installation.
+Set environment variables JAVA_HOME resp. SUITSPOT_HOME to the location of 
your Java installation
+resp. Netscape server installation. Depending on the web server version, you 
must add the subdirectory
+quot;pluginsquot; to SUITSPOT_HOME.
+The variable is correct, if the file $SUITSPOT_HOME/include/nsapi.h exists.
+/li
+li
+Edit bMakefile.solaris/b resp. bMakefile.linux/b and update the 
variables according to your needs.
+In the Solaris Makefile, you need to switch the commented lines in order to 
use the Sun compiler cc
+instead of GNU gcc.
 /li
 li
 Make the source with gmake.
@@ -490,7 +498,11 @@
 typedos./configure --enable-netscape/typedos
 notedosChange directory to the nsapi netscape directory/notedos
 typedoscd netscape/typedos
-notedosEdit Makefile.solaris/notedos
+notedosSet JAVA_HOME (ksh example)/notedos
+typedosexport JAVA_HOME=/path/to/my/java/typedos
+notedosSet SUITSPOT_HOME (ksh example)/notedos
+typedosexport SUITSPOT_HOME=/path/to/my/netscape/server/typedos
+notedosEdit the Makefile/notedos
 typedosvi Makefile.solaris/typedos
 notedosMake the source with gmake/notedos
 typedosgmake -f Makefile.solaris/typedos



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



Re: svn commit: r562194 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp13.h native/common/jk_ajp_common.c native/common/jk_lb_worker.c xdocs/miscellaneous/changelog.xml xdocs/reference/workers

2007-08-02 Thread Rainer Jung
And in fact it doesn't matter. I found it more logical, to have 
JK_STATUS_ERROR and JK_STATUS_FATAL_ERROR closer together (for those 
reading the code). The constants are not used outside JK, so there is no 
compatibility problem.


It looks like your are closely following todays JK changes. I really 
appreciate that! Unless you find problems, I just now commited my last 
change (hopefully) for 1.2.25.


Regards,

Rainer

Jim Jagielski wrote:


On Aug 2, 2007, at 1:42 PM, [EMAIL PROTECTED] wrote:

== 


--- tomcat/connectors/trunk/jk/native/common/jk_ajp13.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp13.h Thu Aug  2 
10:42:23 2007

@@ -45,7 +45,8 @@
 #define JK_CLIENT_RD_ERROR  (-6)
 #define JK_CLIENT_WR_ERROR  (-7)
 #define JK_STATUS_ERROR (-8)
-#define JK_REPLY_TIMEOUT(-9)
+#define JK_STATUS_FATAL_ERROR   (-9)
+#define JK_REPLY_TIMEOUT(-10)



I'm curious... One reason to use C #defines is to abstract
out the macro and their values. So why, when adding
entries to we force JK_REPLY_TIMEOUT to always be
the lowest value? It shouldn't matter what the
real values are, right? This is especially true if we
ever want to leak these out externally :)


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



DO NOT REPLY [Bug 43003] - Separate dependent component download and build targets

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-02 16:51 ---
Created an attachment (id=20586)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20586action=view)
Servlet response generator


-- 
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 43002] - NIO connector performance issue in 6.0.13

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-02 16:48 ---
Update.I wrote a simple response generator servlet and re-ran the tests.   
Now performance on 6.0.13 is significantly *FASTER*.  However, I'm seeing a 
fair number of HTTPClient errors from Grinder as well as consistent buffer 
overflow exceptions.  This leads me to believe that the bottleneck has now 
shifted to the application code.

I've attached the test servlet.   Here are the stack traces:

===
Java exception whilst invoking test runner
File /apps/grinder-3.0/projects/TeaBenchmark/smallest-servlet-
400rps.py, line 40, in __call__
Caused by: java.io.IOException: HTTPClient.ParseException: Didn't find valid 
chunk length: 
at HTTPClient.StreamDemultiplexor.read(StreamDemultiplexor.java:372)
at HTTPClient.RespInputStream.read(RespInputStream.java:155)
at HTTPClient.HTTPResponse.readResponseData(HTTPResponse.java:1011)
at HTTPClient.HTTPResponse.getData(HTTPResponse.java:515)
at net.grinder.plugin.http.HTTPRequest$AbstractRequest.getHTTPResponse
(HTTPRequest.java:888)
at net.grinder.plugin.http.HTTPRequest.GET(HTTPRequest.java:385)
at net.grinder.plugin.http.HTTPRequest.GET(HTTPRequest.java:360)
at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)


TOMCAT LOG STACK TRACE FOLLOWS:

2007-08-02 15:44:04,453 [http-8080-exec-17] ERROR 
org.apache.catalina.connector.CoyoteAdapter - An exception or error occurred in 
the container during the request processing
java.nio.BufferOverflowException
at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:311)
at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:290)
at sun.nio.ch.IOUtil.write(IOUtil.java:70)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:111)
at org.apache.tomcat.util.net.NioBlockingSelector.write
(NioBlockingSelector.java:57)
at org.apache.tomcat.util.net.NioSelectorPool.write
(NioSelectorPool.java:135)
at org.apache.tomcat.util.net.NioSelectorPool.write
(NioSelectorPool.java:130)
at org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket
(InternalNioOutputBuffer.java:433)
at org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer
(InternalNioOutputBuffer.java:761)
at org.apache.coyote.http11.InternalNioOutputBuffer.endRequest
(InternalNioOutputBuffer.java:398)
at org.apache.coyote.http11.Http11NioProcessor.action
(Http11NioProcessor.java:1089)
at org.apache.coyote.Response.action(Response.java:183)
at org.apache.coyote.Response.finish(Response.java:305)
at org.apache.catalina.connector.OutputBuffer.close
(OutputBuffer.java:276)
at org.apache.catalina.connector.Response.finishResponse
(Response.java:486)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:285)
at org.apache.coyote.http11.Http11NioProcessor.process
(Http11NioProcessor.java:896)
at 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process
(Http11NioProtocol.java:705)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run
(NioEndpoint.java:2049)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask
(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
2007-08-02 15:45:24,687 [http-8080-exec-11] ERROR 
org.apache.catalina.connector.CoyoteAdapter - An exception or error occurred in 
the container during the request processing
java.nio.BufferOverflowException
at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:311)
at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:290)
at sun.nio.ch.IOUtil.write(IOUtil.java:70)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:111)
at org.apache.tomcat.util.net.NioBlockingSelector.write
(NioBlockingSelector.java:57)
at org.apache.tomcat.util.net.NioSelectorPool.write
(NioSelectorPool.java:135)
at 

DO NOT REPLY [Bug 43019] New: - valid absolute request uris + mod_jk 1.2.23 return 400 Invalid URI

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

   Summary: valid absolute request uris + mod_jk 1.2.23 return 400
Invalid URI
   Product: Tomcat 6
   Version: 6.0.13
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Problem noticed after upgrading to 1.2.23 to pick up the fix for
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1860

mod_jk now by default uses  JkOptions +ForwardURICompatUnparsed

Problem seen with Tomcat 5.0.28 through 6.0.13 and other versions are likely
affected.

The problem:

Some HTTP clients send requests like:

POST http://host/abs_path HTTP/1.1
Host:host

When Tomcat is fronted by mod_jk 1.2.23, requests like now produce 400 Invalid
URI responses.

After more testing, we found:

(1) client - (apache + mod_jk) - tomcat: produces 400 Invalid URI response
(2) client - (apache + mod_jk) - (tomcat + apr): produces 200 OK response
(3) client - tomcat: produces 200 OK response

Stepping through case (1) with a debugger, request was rejected at this point:

package org.apache.catalina.connector;

public class CoyoteAdapter {
public static boolean normalize(MessageBytes uriMB) {
...

// The URL must start with '/'
if (b[start] != (byte) '/') {
return false;
}

The byte buffer contained the full http://host/abs_path request uri.

Comparing the differences between org.apache.coyote.ajp.AjpAprProcessor (case 2,
works OK) and org.apache.jk.common.HandlerRequest (case 1, broken), we noticed
that AjpAprProcessor converts http://host/abs_path to /abs_path in the
STAGE_PREPARE phase but HandlerRequest does not.

To fix, we just copied the code from AjpAprProcessor to HandlerRequest
essentially unchanged:

package org.apache.jk.common;

public class HandlerRequest {
...

private int decodeRequest( Msg msg, MsgContext ep, MessageBytes tmpMB )
throws IOException{
...

decodeHeaders( ep, msg, req, tmpMB );

decodeAttributes( ep, msg, req, tmpMB );

rp.setStage(Constants.STAGE_PREPARE);

// start yahoo! modified:
// note this code was taken from AjpProcessor.prepare() - other code
// from that method should also be considered for inclusion here

// Check for a full URI (including protocol://host:port/)
ByteChunk uriBC = req.requestURI().getByteChunk();
if (uriBC.startsWithIgnoreCase(http, 0)) {

int pos = uriBC.indexOf(://, 0, 3, 4);
int uriBCStart = uriBC.getStart();
int slashPos = -1;
if (pos != -1) {
byte[] uriB = uriBC.getBytes();
slashPos = uriBC.indexOf('/', pos + 3);
if (slashPos == -1) {
slashPos = uriBC.getLength();
// Set URI as /
req.requestURI().setBytes
(uriB, uriBCStart + pos + 1, 1);
} else {
req.requestURI().setBytes
(uriB, uriBCStart + slashPos,
 uriBC.getLength() - slashPos);
}
MessageBytes hostMB = req.getMimeHeaders().setValue(host);
hostMB.setBytes(uriB, uriBCStart + pos + 3,
slashPos - pos - 3);
}

}

// end yahoo! modified

MessageBytes valueMB = req.getMimeHeaders().getValue(host);
parseHost(valueMB, req);
// set cookies on request now that we have all headers
req.getCookies().setHeaders(req.getMimeHeaders());
 
...

-- 
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: Juli/Logging

2007-08-02 Thread Len Popp
On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote:
 My personal opinion: java.util.logging very much lacks a good formatter.
 The default 2 line formatting of messages, splitting timestamps and
 message in separate lines, is not really useful in production. Many ad
 hoc log analysis practices work on a line oriented basis.

How would exception stack traces be handled? That's an important
consideration because a stack trace is the first thing people ask for
when someone has a problem. :-)
I like the idea of one line per entry, but stack traces don't seem to
fit into that format. If you collapse a stack trace onto one line,
it's a lot harder to read. If you keep the multi-line format for stack
traces, you keep the same problem with log analysis practices that
work on a line oriented basis.
-- 
Len

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



Re: Juli/Logging

2007-08-02 Thread Costin Manolache
On 8/2/07, Len Popp [EMAIL PROTECTED] wrote:

 On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote:
  My personal opinion: java.util.logging very much lacks a good formatter.
  The default 2 line formatting of messages, splitting timestamps and
  message in separate lines, is not really useful in production. Many ad
  hoc log analysis practices work on a line oriented basis.

 How would exception stack traces be handled? That's an important
 consideration because a stack trace is the first thing people ask for
 when someone has a problem. :-)
 I like the idea of one line per entry, but stack traces don't seem to
 fit into that format. If you collapse a stack trace onto one line,
 it's a lot harder to read. If you keep the multi-line format for stack
 traces, you keep the same problem with log analysis practices that
 work on a line oriented basis.


It's not only log tools who dislike the 2-line format - also humans.

For a tool -  detecting the stack trace  is not that hard, it's a simple
pattern.

But maybe a compact binary format would be more interesting for tools, and
could be converted to different layouts for people.

Costin


--
 Len

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




Re: Juli/Logging

2007-08-02 Thread Len Popp
On 8/3/07, Costin Manolache [EMAIL PROTECTED] wrote:
 On 8/2/07, Len Popp [EMAIL PROTECTED] wrote:
 
  On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote:
   My personal opinion: java.util.logging very much lacks a good formatter.
   The default 2 line formatting of messages, splitting timestamps and
   message in separate lines, is not really useful in production. Many ad
   hoc log analysis practices work on a line oriented basis.
 
  How would exception stack traces be handled? That's an important
  consideration because a stack trace is the first thing people ask for
  when someone has a problem. :-)
  I like the idea of one line per entry, but stack traces don't seem to
  fit into that format. If you collapse a stack trace onto one line,
  it's a lot harder to read. If you keep the multi-line format for stack
  traces, you keep the same problem with log analysis practices that
  work on a line oriented basis.


 It's not only log tools who dislike the 2-line format - also humans.

 For a tool -  detecting the stack trace  is not that hard, it's a simple
 pattern.

 But maybe a compact binary format would be more interesting for tools, and
 could be converted to different layouts for people.

 Costin

Oh, I'm one of the humans who prefers one line per entry - at least
for short entries. I'm not against changing the log format. I'm just
not sure if you can put a stack trace on one line and keep it
readable.

I wouldn't like to have a binary file format that I need a special
program to read, or that is incompatible with standard tools like
grep, tail, etc.
-- 
Len

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