DO NOT REPLY [Bug 39003] - Tomcat 5.5.15 with APR 1.2.2 corrupts sent images

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 08:04 ---
Use 5.5.16 with tcnative 1.1.2.

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

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

DO NOT REPLY [Bug 37167] - make error: libtool: install: you must specify a destination

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 08:35 ---
Fixed in the SVN. See:
http://cvs.apache.org/viewcvs.cgi?rev=326453&view=rev



-- 
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: r386569 - /tomcat/connectors/trunk/jk/xdocs/changelog.xml

[mturk]

Author: mturk
Date: Fri Mar 17 00:36:51 2006
New Revision: 386569

URL: http://svn.apache.org/viewcvs?rev=386569&view=rev
Log:
Document #37167 -- Allow building with BSD-ish like make, that does not 
understand '$<' expansion.

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

Modified: tomcat/connectors/trunk/jk/xdocs/changelog.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/jk/xdocs/changelog.xml?rev=386569&r1=386568&r2=386569&view=diff
==
--- tomcat/connectors/trunk/jk/xdocs/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/changelog.xml Fri Mar 17 00:36:51 2006
@@ -47,6 +47,9 @@
   This fixes hot-standby workers in error state. (mturk)
   
   
+  37167: Allow building with BSD-ish like make. (mturk)
+  
+  
   ISAPI plugin (isapi_redirect.dll) did not provide correct request data
   for IIS
  to include in the IIS log. (markt)



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

DO NOT REPLY [Bug 37322] - format bug: sprintf() twice on top of each other

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 08:46 ---
Like you said:

The good news is that it currently cannot be easily misused, because
the function involved is so far only used with the format string
"Memory Error" -- not a single "%" therein.
However it's just sitting there, waiting to be put to other uses.

So, we'll be paranoid if someone puts "%" instead "Memory error"

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

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

DO NOT REPLY [Bug 37246] - Election method T weirdness under constant heavy load

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 09:09 ---
Fixed in the SVN.
The problem was caused because locking was improper.
Anyhow for prefork the solution is to add
worker.loadbalancer.lock=P
See:
http://cvs.apache.org/viewcvs.cgi?rev=386277&view=rev

-- 
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 36155] - tomcat chooses wrong host if using mod_jk

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WORKSFORME




--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 09:25 ---
I was not able to reproduce the problem.
With your test files and mod_jk from SVN it works OK.

-- 
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 39003] - Tomcat 5.5.15 with APR 1.2.2 corrupts sent images

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 09:29 ---
(In reply to comment #1)
> Is this with AJP or HTTP protocol.
> If it's AJP connector the this is already fixed with 5.5.16
> See:
> http://cvs.apache.org/viewcvs.cgi?rev=381505&view=rev

It is NOT with the AJP connector, but with the HTTP connector. Is it then also
fixed with 5.5.16 and APR 1.1.2?

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

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

svn commit: r386592 - in /tomcat/connectors/trunk/jk: native/common/jk_util.c xdocs/changelog.xml

[mturk]

Author: mturk
Date: Fri Mar 17 01:35:16 2006
New Revision: 386592

URL: http://svn.apache.org/viewcvs?rev=386592&view=rev
Log:
Fix #37332 -- potential misuse of buffer length with snprintf functions.

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

Modified: tomcat/connectors/trunk/jk/native/common/jk_util.c
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/jk/native/common/jk_util.c?rev=386592&r1=386591&r2=386592&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_util.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_util.c Fri Mar 17 01:35:16 2006
@@ -315,8 +315,8 @@
 used += sprintf(&buf[used], "[%04d:%04d] ", getpid(),
 jk_gettid());
 #else
-used += snprintf(&buf[used], HUGE_BUFFER_SIZE, "[%04d:%04d] ",
- getpid(), jk_gettid());
+used += snprintf(&buf[used], HUGE_BUFFER_SIZE - used,
+ "[%04d:%04d] ", getpid(), jk_gettid());
 #endif
 if (used < 0) {
 return 0;
@@ -338,8 +338,8 @@
 used += sprintf(&buf[used], "%s (%d): ", f, line);
 #else
 if (line)
-used += snprintf(&buf[used], HUGE_BUFFER_SIZE, "%s (%d): ",
- f, line);
+used += snprintf(&buf[used], HUGE_BUFFER_SIZE - used,
+ "%s (%d): ", f, line);
 #endif
 if (used < 0) {
 return 0;   /* [V] not sure what to return... */

Modified: tomcat/connectors/trunk/jk/xdocs/changelog.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/jk/xdocs/changelog.xml?rev=386592&r1=386591&r2=386592&view=diff
==
--- tomcat/connectors/trunk/jk/xdocs/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/changelog.xml Fri Mar 17 01:35:16 2006
@@ -26,6 +26,10 @@
   
 
   
+  37332: Fix potential misuse of buffer length with
+  snprintf functions. (mturk)
+  
+  
   38859: Protect mod_jk against buggy or malicious
   AJP servers in the backend. Patch provided by Ruediger Pluem. (mturk)
   



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

DO NOT REPLY [Bug 37332] - bounded buffer bug: incorrect use of [v]snprintf()

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 09:36 ---
Fixed in the SVN.
Although 8K buffer is long enough for any log line we might have.

-- 
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 37850] - Core dumps on Solaris under concurrent load.

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME




--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 09:41 ---
I have never observed such behavior.
There was bug with Solaris dealing with the shared memory that
was causing core dump, but never something like that.

The interesting is that it fails in strformat, so try adjusting the
JkLogStampFormat.

-- 
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 39003] - Tomcat 5.5.15 with APR 1.2.2 corrupts sent images

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 09:45 ---
(In reply to comment #2)
> Use 5.5.16 with tcnative 1.1.2.

Only tcnative 1.1.2 is needed, actually.

-- 
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 39003] - Tomcat 5.5.15 with APR 1.2.2 corrupts sent images

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 09:46 ---
No idea.
Try it, and give some test case.
It for sure works for me.

-- 
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 37498] - [PATCH] NPE in org.apache.catalina.core.ContainerBase.removeChild

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX




-- 
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 39003] - Tomcat 5.5.15 with APR 1.2.2 corrupts sent images

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 10:00 ---
(In reply to comment #5)
> No idea.

You should: it's the incomplete write bug that you did fix youself.

-- 
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 39011] New: - image size limit

[bugzilla]

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

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

   Summary: image size limit
   Product: Tomcat 5
   Version: 5.5.4
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: major
  Priority: P2
 Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I use tomcat 5.5.4 with struts framework,the jsp cant show img with more than 
(n)kb size . If i try a direct  access with:
http://localhost:8080/myspace/imgDir/moreThanN_kb.gif  i recive this error:

java.lang.NoSuchMethodError: 
org.apache.naming.resources.ResourceAttributes.getCanonicalPath()
Ljava/lang/String


http://localhost:8080/myspace/imgDir/lessThanN_kb.gif i see the picture in my 
browser

-- 
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 39003] - Tomcat 5.5.15 with APR 1.2.2 corrupts sent images

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 10:08 ---
(In reply to comment #3)
Are your sure that your apr, tcnative is really compile right? I have seen last 
week an installation
with wrong CFLAGS with same strange report. (Compiled without -g -O2)  Make 
sure that your compile 
env is clean!



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

[Mladen Turk]

Jim Jagielski wrote:

I'm thinking... the behavior we want is that non-Windows
OSs want the APR_SO_REUSEADDR before the bind; Windows
wants it after. So checking for (OS.IS_UNIX) at
one point (for the former) and then (OS.IS_WIN32 || OS.IS_WIN64)
(for the later) is misleading, and doesn't match what
we do elsewhere. So why not make the former test

!(OS.IS_WIN32 || OS.IS_WIN64)

instead? This should also fix the MacOS bug as well.



Now that flags are correctly initialized, there is no need
for that. MacOS will be reported as 'IS_UNIX'.
Of course we can add IS_MACOS once when Peter finishes
MacOS system info, but it will still be reported as IS_UNIX
beside IS_MACOS, just like IS_LINUX or IS_SOLARIS.

We can change the later test for
(OS.IS_WIN32 || OS.IS_WIN64) to !OS.IS_UNIX
but it wouldn't change anything functional.


Regards,
Mladen.

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

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

[Peter Rossbach]

The current os.c patch works well at mac os x. and currently the IS_UNIX
flag is enough.

But my research for more mac os x system info is hard. Help is needed...

Thanks
peter



Am 17.03.2006 um 11:10 schrieb Mladen Turk:


Jim Jagielski wrote:

I'm thinking... the behavior we want is that non-Windows
OSs want the APR_SO_REUSEADDR before the bind; Windows
wants it after. So checking for (OS.IS_UNIX) at
one point (for the former) and then (OS.IS_WIN32 || OS.IS_WIN64)
(for the later) is misleading, and doesn't match what
we do elsewhere. So why not make the former test
!(OS.IS_WIN32 || OS.IS_WIN64)
instead? This should also fix the MacOS bug as well.


Now that flags are correctly initialized, there is no need
for that. MacOS will be reported as 'IS_UNIX'.
Of course we can add IS_MACOS once when Peter finishes
MacOS system info, but it will still be reported as IS_UNIX
beside IS_MACOS, just like IS_LINUX or IS_SOLARIS.

We can change the later test for
(OS.IS_WIN32 || OS.IS_WIN64) to !OS.IS_UNIX
but it wouldn't change anything functional.


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]

svn commit: r386604 - in /tomcat/connectors/trunk/jk: native/common/jk_shm.c xdocs/changelog.xml

[mturk]

Author: mturk
Date: Fri Mar 17 02:39:10 2006
New Revision: 386604

URL: http://svn.apache.org/viewcvs?rev=386604&view=rev
Log:
Fix #37469. Shared memory was closed for forked childs,
thus causing close an munmap twice for the same file id.

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

Modified: tomcat/connectors/trunk/jk/native/common/jk_shm.c
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/jk/native/common/jk_shm.c?rev=386604&r1=386603&r2=386604&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_shm.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_shm.c Fri Mar 17 02:39:10 2006
@@ -253,7 +253,10 @@
 return 0;
 }
 jk_shmem.filename = fname;
-jk_shmem.attached = attached;
+if (attached)
+jk_shmem.attached = (int)getpid();
+else
+jk_shmem.attached = 0;
 
 jk_shmem.size = JK_SHM_ALIGN(sizeof(jk_shm_header_t) + sz);
 
@@ -361,6 +364,16 @@
 {
 int rc;
 if (jk_shmem.hdr) {
+if (jk_shmem.hdr.attached) {
+int p = (int)getpid();
+if (p != jk_shmem.hdr.attached) {
+/* In case this is a forked child
+ * do not close the shared memory.
+ * It will be closed by the parent.
+ */
+ return;
+}
+}
 if (jk_shmem.fd_lock >= 0) {
 close(jk_shmem.fd_lock);
 }

Modified: tomcat/connectors/trunk/jk/xdocs/changelog.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/jk/xdocs/changelog.xml?rev=386604&r1=386603&r2=386604&view=diff
==
--- tomcat/connectors/trunk/jk/xdocs/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/changelog.xml Fri Mar 17 02:39:10 2006
@@ -26,6 +26,10 @@
   
 
   
+  37469: Fix shared memory close for forked childs.
+  The shared memory will be closed by the parent process. (mturk)
+  
+  
   37332: Fix potential misuse of buffer length with
   snprintf functions. (mturk)
   



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

DO NOT REPLY [Bug 37469] - mod_jk doesn�t scale well with hundreds of sites - interferes with CGI handling

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 10:40 ---
Fixed in the SVN. See:
http://svn.apache.org/viewcvs?rev=386604&view=rev

-- 
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: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/ParserController.java

[Jean-frederic Clere]

Bill Barker wrote:




 


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 16, 2006 3:55 AM

To: tomcat-dev@jakarta.apache.org
Subject: svn commit: r386315 - 
/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa

rserController.java

Author: jfclere
Date: Thu Mar 16 03:54:29 2006
New Revision: 386315

URL: http://svn.apache.org/viewcvs?rev=386315&view=rev
Log:
If the encoding is not specified use the detected one.

   



-1.
If it gets to this point, the detected encoding is *wrong* (e.g.  in JSP syntax).


Why wrong?
+++
Connected to localhost.
Escape character is '^]'.
GET /try1.jsp

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
+++

 


I don't have access to an EBCDIC machine to know what the problem is, but
this isn't the fix.  Possibly a better way to guess the encoding of the
Reader?
 

Thinking to it  the patch is not prefect but the old code is worse we 
have a piece of code that detects correctly the  source encoding and 
detroy it...


In doParse() in ParserController.java the following happends
parse() is called with pageEnc = sourceEnc
jspConfigPageEnc = null
isDefaultPageEncoding = false.
But the line before the jspReader uses the sourceEnc to create the 
InputStreamReader so the content of the file is translated to utf-8 when 
reading it.
In validator.java the charset will be set to the detected encoding... In 
the example above iso-8859.2. Bad for me that will be OSD_EBCDIC_DF04_1.


Cheers

Jean-Frederic






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

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


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


 




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

DO NOT REPLY [Bug 37147] - IIS 6.0, isapi_redirect.dll 1.2.14, does not log page redirects

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 11:24 ---
I do not understand this bug report.
I can clealy get the
[debug] jk_isapi_plugin.c (831): Virtual Host redirection of 
/localhost/gohere.html

in the log file.


-- 
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 36169] - [PATCH] Enable chunked encoding for IIS JK connector

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|major   |enhancement




--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 11:26 ---
This is enhancement request, not bug report.
I'll test your patch but not sure how to test it.

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

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

mod_jk [STATUS]

[Mladen Turk]

Hi all,

There is quite large list of fixed bugs for mod_jk
from the 1.2.15:

#37469: Fix shared memory close for forked childs.
#37332: Fix potential misuse of buffer length with snprintf.
#38859: Protect mod_jk against buggy or malicious AJP servers.
#38889: Use worker map sorting depending on the path elements.
#36138: Added Busyness lb method.
#none:  Fix loadbalancer for burst load.
#38806: Reclycle worker even if it is disabled.
#37167: Allow building with BSD-ish like make.
#none:  Fix ISAPI plugin log.


Is this worth tagging and releasing 1.2.16?

Regards,
Mladen.

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

Re: mod_jk [STATUS]

[Peter Rossbach]

+1 for that,

I can made my tests at weekend.

Regards
Peter



Am 17.03.2006 um 12:37 schrieb Mladen Turk:


Hi all,

There is quite large list of fixed bugs for mod_jk
from the 1.2.15:

#37469: Fix shared memory close for forked childs.
#37332: Fix potential misuse of buffer length with snprintf.
#38859: Protect mod_jk against buggy or malicious AJP servers.
#38889: Use worker map sorting depending on the path elements.
#36138: Added Busyness lb method.
#none:  Fix loadbalancer for burst load.
#38806: Reclycle worker even if it is disabled.
#37167: Allow building with BSD-ish like make.
#none:  Fix ISAPI plugin log.


Is this worth tagging and releasing 1.2.16?

Regards,
Mladen.

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





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

Re: mod_jk [STATUS]

[Henri Gomez]

+1

2006/3/17, Peter Rossbach <[EMAIL PROTECTED]>:
> +1 for that,
>
> I can made my tests at weekend.
>
> Regards
> Peter
>
>
>
> Am 17.03.2006 um 12:37 schrieb Mladen Turk:
>
> > Hi all,
> >
> > There is quite large list of fixed bugs for mod_jk
> > from the 1.2.15:
> >
> > #37469: Fix shared memory close for forked childs.
> > #37332: Fix potential misuse of buffer length with snprintf.
> > #38859: Protect mod_jk against buggy or malicious AJP servers.
> > #38889: Use worker map sorting depending on the path elements.
> > #36138: Added Busyness lb method.
> > #none:  Fix loadbalancer for burst load.
> > #38806: Reclycle worker even if it is disabled.
> > #37167: Allow building with BSD-ish like make.
> > #none:  Fix ISAPI plugin log.
> >
> >
> > Is this worth tagging and releasing 1.2.16?
> >
> > 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]
>
>

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

Re: mod_jk [STATUS]

[Yoav Shapira]

+1.

On 3/17/06, Henri Gomez <[EMAIL PROTECTED]> wrote:
> +1
>
> 2006/3/17, Peter Rossbach <[EMAIL PROTECTED]>:
> > +1 for that,
> >
> > I can made my tests at weekend.
> >
> > Regards
> > Peter
> >
> >
> >
> > Am 17.03.2006 um 12:37 schrieb Mladen Turk:
> >
> > > Hi all,
> > >
> > > There is quite large list of fixed bugs for mod_jk
> > > from the 1.2.15:
> > >
> > > #37469: Fix shared memory close for forked childs.
> > > #37332: Fix potential misuse of buffer length with snprintf.
> > > #38859: Protect mod_jk against buggy or malicious AJP servers.
> > > #38889: Use worker map sorting depending on the path elements.
> > > #36138: Added Busyness lb method.
> > > #none:  Fix loadbalancer for burst load.
> > > #38806: Reclycle worker even if it is disabled.
> > > #37167: Allow building with BSD-ish like make.
> > > #none:  Fix ISAPI plugin log.
> > >
> > >
> > > Is this worth tagging and releasing 1.2.16?
> > >
> > > 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]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com

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

Re: mod_jk [STATUS]

[Peter Rossbach]

Hey Malden,

I have found one compile error:


/bin/sh /Users/peter/server/apache2.0.55w/build/libtool --silent -- 
mode=compile gcc -I/Users/peter/server/apache2.0.55w/include -g -O2 - 
g -O2 -DHAVE_APR  -I/Users/peter/develop/apache/httpd-2.0.55/srclib/ 
apr/include -I/Users/peter/develop/apache/httpd-2.0.55/srclib/apr- 
util/include -g -O2 -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp- 
precomp -I /System/Library/Frameworks/JavaVM.framework/Versions/1.5/ 
Home/include -I /System/Library/Frameworks/JavaVM.framework/Versions/ 
1.5/Home/include/ -c jk_shm.c -o jk_shm.lo

jk_shm.c: In function 'jk_shm_close':
jk_shm.c:367: error: request for member 'attached' in something not a  
structure or union
jk_shm.c:369: error: request for member 'attached' in something not a  
structure or union

make[1]: *** [jk_shm.lo] Error 1
make: *** [all-recursive] Error 1

Can be that we must use
jk_shmem.attached instead jk_shmem.hdr.attached ?


other thing is that gcc 4.0.1 report this warning

/JavaVM.framework/Versions/1.5/Home/include/ -c jk_ajp12_worker.c -o  
jk_ajp12_worker.lo
/bin/sh /Users/peter/server/apache2.0.55w/build/libtool --silent -- 
mode=compile gcc -I/Users/peter/server/apache2.0.55w/include -g -O2 - 
g -O2 -DHAVE_APR  -I/Users/peter/develop/apache/httpd-2.0.55/srclib/ 
apr/include -I/Users/peter/develop/apache/httpd-2.0.55/srclib/apr- 
util/include -g -O2 -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp- 
precomp -I /System/Library/Frameworks/JavaVM.framework/Versions/1.5/ 
Home/include -I /System/Library/Frameworks/JavaVM.framework/Versions/ 
1.5/Home/include/ -c jk_connect.c -o jk_connect.lo

jk_connect.c: In function 'nb_connect':
jk_connect.c:198: warning: pointer targets in passing argument 5 of  
'getsockopt' differ in signedness


Can I set rclen to unsigned ?
L181 jk_connect.c
   unsigned int rclen = sizeof(rc);

regards
Peter


Am 17.03.2006 um 12:37 schrieb Mladen Turk:


Hi all,

There is quite large list of fixed bugs for mod_jk
from the 1.2.15:

#37469: Fix shared memory close for forked childs.
#37332: Fix potential misuse of buffer length with snprintf.
#38859: Protect mod_jk against buggy or malicious AJP servers.
#38889: Use worker map sorting depending on the path elements.
#36138: Added Busyness lb method.
#none:  Fix loadbalancer for burst load.
#38806: Reclycle worker even if it is disabled.
#37167: Allow building with BSD-ish like make.
#none:  Fix ISAPI plugin log.


Is this worth tagging and releasing 1.2.16?

Regards,
Mladen.

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

svn commit: r386627 - /tomcat/connectors/trunk/jk/native/common/jk_shm.c

[pero]

Author: pero
Date: Fri Mar 17 04:34:53 2006
New Revision: 386627

URL: http://svn.apache.org/viewcvs?rev=386627&view=rev
Log:
Fix small type usage typo!

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

Modified: tomcat/connectors/trunk/jk/native/common/jk_shm.c
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/jk/native/common/jk_shm.c?rev=386627&r1=386626&r2=386627&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_shm.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_shm.c Fri Mar 17 04:34:53 2006
@@ -364,9 +364,9 @@
 {
 int rc;
 if (jk_shmem.hdr) {
-if (jk_shmem.hdr.attached) {
+if (jk_shmem.attached) {
 int p = (int)getpid();
-if (p != jk_shmem.hdr.attached) {
+if (p != jk_shmem.attached) {
 /* In case this is a forked child
  * do not close the shared memory.
  * It will be closed by the parent.



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

svn commit: r386629 - /tomcat/connectors/trunk/jk/native/common/jk_connect.c

[pero]

Author: pero
Date: Fri Mar 17 04:36:04 2006
New Revision: 386629

URL: http://svn.apache.org/viewcvs?rev=386629&view=rev
Log:
Fix gcc 4.0.1 compiler warning at mac os x!

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

Modified: tomcat/connectors/trunk/jk/native/common/jk_connect.c
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/jk/native/common/jk_connect.c?rev=386629&r1=386628&r2=386629&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_connect.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_connect.c Fri Mar 17 04:36:04 
2006
@@ -177,7 +177,7 @@
&& (timeout > 0)) {
 fd_set wfdset;
 struct timeval tv;
-int rclen = sizeof(rc);
+unsigned int rclen = sizeof(rc);
 
 FD_ZERO(&wfdset);
 FD_SET(sock, &wfdset);



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

Re: svn commit: r386629 - /tomcat/connectors/trunk/jk/native/common/jk_connect.c

[Mladen Turk]

[EMAIL PROTECTED] wrote:

Fix gcc 4.0.1 compiler warning at mac os x!



Man, your are really serious with macosx.
Now, since it runs on Intel, I should try
one for myself :)

Cheers,
Mladen.

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

Re: svn commit: r386629 - /tomcat/connectors/trunk/jk/native/common/jk_connect.c

[Peter Rossbach]

Hi,

I wait for second MacBook generation and then  Cool design, and a  
very hot computer...
Some people have make last days the first Windows XP up and running  
and Suse linux works nicely...


;-)
Peter


Am 17.03.2006 um 13:43 schrieb Mladen Turk:


[EMAIL PROTECTED] wrote:

Fix gcc 4.0.1 compiler warning at mac os x!



Man, your are really serious with macosx.
Now, since it runs on Intel, I should try
one for myself :)

Cheers,
Mladen.

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





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

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

[Mladen Turk]

Peter Rossbach wrote:

The current os.c patch works well at mac os x. and currently the IS_UNIX
flag is enough.

But my research for more mac os x system info is hard. Help is needed...



Rainer made initial implementation for linux and solaris,
so he might have some ideas. Although this is pretty platform
specific, because it involves lot's of syscalls.
Anyhow, it's not operationally critical so, any time is
a good time :)

Regards,
Mladen.

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

Re: mod_jk [STATUS]

[Mladen Turk]

Peter Rossbach wrote:

Hey Malden,

I have found one compile error:

Can be that we must use
jk_shmem.attached instead jk_shmem.hdr.attached ?



Right, a stupid copy/paste error from the testing
linux box to a windows one I'm using for commits.

However, I saw you already commit a patch.

Thanks,
Mladen.

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

DO NOT REPLY [Bug 39013] New: - Incorrect use of docBase from XML Context file deployment

[bugzilla]

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

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

   Summary: Incorrect use of docBase from XML Context file
deployment
   Product: Tomcat 5
   Version: 5.5.16
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: minor
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I created a folder called "webapps-war" within the Tomcat installation directory
(CATALINA_HOME). The host's default appBase is "webapps" in this directory.

What I wanted to do is use the XML Context file deployment method, i.e. put my
xml file into conf/catalina/localhost (in my case) and specify the docBase to
look for the war in ${catalina.home}/webapps-war/myapp.

But just because the name starts with "webapps", it misinterprets the docBase
setting and I get in tomcat.log:
"A docBase C:\tomcat-5.5.16\webapps-war\myapp inside the host appBase has been
specified, and will be ignored"
and then my deployment fails.

On the other hand, if I name my folder "somethingelse" instead of "webapps-war",
it works like a charm.

So not a big problem (trivial workaround) but would be nicer if the rule was
perfectly implemented. And that would have saved me hours trying to figure out
what was wrong in my deployment!...

If my investigation is correct, the problem can be traced back to
org.apache.catalina.startup.HostConfig and below is my suggested change against
the download from SVN done today (17 March). I'm not an expert on the catalina
source, so it would need another pair of eyes and some testing before you can
say this is the resolution of this problem. The proposed solution is simply to
make sure the string comparaisons includes a trailing "/" after the default 
appBase.

Questions on the suggested resolution:
I'm not sure in particular if you can use "/" as the directory separator for all
platform of if you'd need to use something like
System.getProperty("file.separator")?
Would there be other places where this applies?
Is there a compelling reason why this can't be done like that?

DIFF FILE against $Revision: 386336 $ $Date: 2006-03-16 14:13:00 + (Thu, 16
Mar 2006) $
Compare:
(<)D:\work-bak\tomcat\container\catalina\src\share\org\apache\catalina\startup\HostConfig.java
(45038 bytes)
   with:
(>)D:\work-bak\tomcat\container\catalina\src\share\org\apache\catalina\startup\HostConfig.java.changed
(44596 bytes)

592c592
< if
(!docBase.getCanonicalPath().startsWith(appBase().getAbsolutePath())) {
---
> if
(!docBase.getCanonicalPath().startsWith(appBase().getAbsolutePath() + "/")) {
995,996c995,996
< if
((current.getAbsolutePath().startsWith(appBase().getAbsolutePath()))
< ||
(current.getAbsolutePath().startsWith(configBase().getAbsolutePath( {
---
> if
((current.getAbsolutePath().startsWith(appBase().getAbsolutePath() + "/"))
> ||
(current.getAbsolutePath().startsWith(configBase().getAbsolutePath() + "/"))) {
1035,1036c1035,1036
< if
((current.getAbsolutePath().startsWith(appBase().getAbsolutePath()))
< ||
(current.getAbsolutePath().startsWith(configBase().getAbsolutePath( {
---
> if
((current.getAbsolutePath().startsWith(appBase().getAbsolutePath() + "/"))
> ||
(current.getAbsolutePath().startsWith(configBase().getAbsolutePath() + "/"))) {
1052,1053c1052,1053
< if
((current.getAbsolutePath().startsWith(appBase().getAbsolutePath()))
< ||
((current.getAbsolutePath().startsWith(configBase().getAbsolutePath())
---
> if
((current.getAbsolutePath().startsWith(appBase().getAbsolutePath() + "/"))
> ||
((current.getAbsolutePath().startsWith(configBase().getAbsolutePath() + "/")

-- 
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: mod_jk [STATUS]

[Remy Maucherat]

Mladen Turk wrote:

Hi all,

There is quite large list of fixed bugs for mod_jk
from the 1.2.15:

#37469: Fix shared memory close for forked childs.
#37332: Fix potential misuse of buffer length with snprintf.
#38859: Protect mod_jk against buggy or malicious AJP servers.
#38889: Use worker map sorting depending on the path elements.
#36138: Added Busyness lb method.
#none:  Fix loadbalancer for burst load.
#38806: Reclycle worker even if it is disabled.
#37167: Allow building with BSD-ish like make.
#none:  Fix ISAPI plugin log.


Is this worth tagging and releasing 1.2.16?


+1, but make sure you test it (I see lots of last minute fixes).

Rémy


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

Re: mod_jk [STATUS]

[Mladen Turk]

Remy Maucherat wrote:


+1, but make sure you test it (I see lots of last minute fixes).



Well, I hope I won't be the only one doing testing.
I'll create a private .tar.gz so everyone interested
(beside myself) could build and test it, before
official vote and release.
This is for those lazy to use the SVN :)

Regards,
Mladen.



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

Re: mod_jk [STATUS]

[Peter Rossbach]

+1

Can you please create a windows binaries?

I start testing at weekend and I hope Rainer can also do testing at  
solaris.


Thanks
peter



Am 17.03.2006 um 14:27 schrieb Mladen Turk:


Remy Maucherat wrote:

+1, but make sure you test it (I see lots of last minute fixes).



Well, I hope I won't be the only one doing testing.
I'll create a private .tar.gz so everyone interested
(beside myself) could build and test it, before
official vote and release.
This is for those lazy to use the SVN :)

Regards,
Mladen.



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





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

Re: mod_jk [STATUS]

[Mladen Turk]

Peter Rossbach wrote:

+1

Can you please create a windows binaries?



Sure. Already have them :)


I start testing at weekend and I hope Rainer can also do testing at 
solaris.




I'll put that somewhere in the people.apache.org.
I'll let you know, when I upload the bins.


--
Mladen.

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

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

[Jim Jagielski]

On Mar 17, 2006, at 5:10 AM, Mladen Turk wrote:


Jim Jagielski wrote:

I'm thinking... the behavior we want is that non-Windows
OSs want the APR_SO_REUSEADDR before the bind; Windows
wants it after. So checking for (OS.IS_UNIX) at
one point (for the former) and then (OS.IS_WIN32 || OS.IS_WIN64)
(for the later) is misleading, and doesn't match what
we do elsewhere. So why not make the former test
!(OS.IS_WIN32 || OS.IS_WIN64)
instead? This should also fix the MacOS bug as well.


Now that flags are correctly initialized, there is no need
for that. MacOS will be reported as 'IS_UNIX'.
Of course we can add IS_MACOS once when Peter finishes
MacOS system info, but it will still be reported as IS_UNIX
beside IS_MACOS, just like IS_LINUX or IS_SOLARIS.



Oh. I had thought that someone said that MaxOS did NOT
report itself as IS_UNIX (which would itself be a bug).
If that is no longer the case, then the MacOS side-benefit
is moot. 


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

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

[Jim Jagielski]

On Mar 17, 2006, at 5:27 AM, Peter Rossbach wrote:

The current os.c patch works well at mac os x. and currently the  
IS_UNIX

flag is enough.

But my research for more mac os x system info is hard. Help is  
needed...




ping me offline about OSX/Darwin.

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

Re: mod_jk [STATUS]

[Jim Jagielski]

+1 for current trunk.

On Mar 17, 2006, at 7:55 AM, Mladen Turk wrote:


Peter Rossbach wrote:

Hey Malden,
I have found one compile error:
Can be that we must use
jk_shmem.attached instead jk_shmem.hdr.attached ?



Right, a stupid copy/paste error from the testing
linux box to a windows one I'm using for commits.

However, I saw you already commit a patch.

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

svn commit: r386668 - in /tomcat/container/tc5.5.x/modules/groupcom: ./ src/share/org/apache/catalina/tribes/tcp/bio/ src/share/org/apache/catalina/tribes/tipis/

[fhanik]

Author: fhanik
Date: Fri Mar 17 08:35:32 2006
New Revision: 386668

URL: http://svn.apache.org/viewcvs?rev=386668&view=rev
Log:
Added new todo items,
Added a replicated hash map, all-to-all replication
Simplified BioSender, writeData isn't needed if it is a 2 line method

Added:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/ReplicatedMap.java
Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/bio/BioSender.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/LazyReplicatedMap.java
tomcat/container/tc5.5.x/modules/groupcom/to-do.txt

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/bio/BioSender.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/bio/BioSender.java?rev=386668&r1=386667&r2=386668&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/bio/BioSender.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/bio/BioSender.java
 Fri Mar 17 08:35:32 2006
@@ -267,22 +267,12 @@
 keepalive();
 if ( reconnect ) closeSocket();
 if (!isConnected()) openSocket();
-writeData(data);
-}
-
-/**
- * Sent real cluster Message to socket stream
- * FIXME send compress
- * @param data
- * @throws IOException
- * @since 5.5.10
- */
-protected  void writeData(byte[] data) throws IOException { 
 soOut.write(data);
 soOut.flush();
 if (getWaitForAck()) waitForAck();
-}
 
+}
+
 /**
  * Wait for Acknowledgement from other server
  * FIXME Please, not wait only for three charcters, better control that 
the wait ack message is correct.

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/LazyReplicatedMap.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/LazyReplicatedMap.java?rev=386668&r1=386667&r2=386668&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/LazyReplicatedMap.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/LazyReplicatedMap.java
 Fri Mar 17 08:35:32 2006
@@ -15,19 +15,11 @@
  */
 package org.apache.catalina.tribes.tipis;
 
-import java.io.Externalizable;
-import java.io.IOException;
-import java.io.ObjectInput;
-import java.io.ObjectOutput;
-import java.io.ObjectOutputStream;
 import java.io.Serializable;
-import java.io.UnsupportedEncodingException;
 import java.util.ArrayList;
-import java.util.Arrays;
 import java.util.Collection;
 import java.util.Collections;
 import java.util.Iterator;
-import java.util.LinkedHashMap;
 import java.util.LinkedHashSet;
 import java.util.Map;
 import java.util.Set;
@@ -37,9 +29,6 @@
 import org.apache.catalina.tribes.ChannelListener;
 import org.apache.catalina.tribes.Member;
 import org.apache.catalina.tribes.MembershipListener;
-import org.apache.catalina.tribes.io.DirectByteArrayOutputStream;
-import org.apache.catalina.tribes.io.XByteBuffer;
-import org.apache.catalina.tribes.mcast.MemberImpl;
 
 /**
  * A smart implementation of a stateful replicated map. uses primary/secondary 
backup strategy. 

Added: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/ReplicatedMap.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/ReplicatedMap.java?rev=386668&view=auto
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/ReplicatedMap.java
 (added)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/ReplicatedMap.java
 Fri Mar 17 08:35:32 2006
@@ -0,0 +1,281 @@
+/*
+ * Copyright 1999,2004-2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.catalina.tribes.tipis;
+
+import java.io.Serializable;
+import java.util.Ar

DO NOT REPLY [Bug 39021] New: - Support authentication only access

[bugzilla]

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

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

   Summary: Support authentication only access
   Product: Tomcat 5
   Version: 5.5.16
  Platform: Other
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The recent changes in the handling of the * have broken 
a 
long standing ability to specify authentication only access. Although not 
explicitly supported by the servlet spec(and I think it should be), this is a 
useful feature that users ask for. It can be achieved in various vendor 
specific 
ways via tomcat customizations, but I would like to see inherent support for 
it. 
The simplest approach would be a Realm attribute like 
authenticationOnlyAllRolesMode=true allowing for an authenticated user access 
regardless of the role(s) they have been granted.

-- 
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: r386674 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSender.java

[fhanik]

Author: fhanik
Date: Fri Mar 17 09:07:47 2006
New Revision: 386674

URL: http://svn.apache.org/viewcvs?rev=386674&view=rev
Log:
setting default value for retry attempts

Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSender.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSender.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSender.java?rev=386674&r1=386673&r2=386674&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSender.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSender.java
 Fri Mar 17 09:07:47 2006
@@ -49,7 +49,7 @@
 private Member destination;
 private InetAddress address;
 private int port;
-private int maxRetryAttempts;
+private int maxRetryAttempts = 0;//zero resends
 private int attempt;
 public AbstractSender() {
 



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

svn commit: r386672 - in /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp: ./ bio/ nio/

[fhanik]

Author: fhanik
Date: Fri Mar 17 09:06:52 2006
New Revision: 386672

URL: http://svn.apache.org/viewcvs?rev=386672&view=rev
Log:
Removed the resend flag and added in a configurable retry attempt flag that 
lets you control resends more


Added:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSender.java
  - copied, changed from r386373, 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSocketSender.java
Removed:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSocketSender.java
Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/bio/BioSender.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/bio/MultipointBioSender.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/nio/NioSender.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/nio/ParallelNioSender.java

Copied: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSender.java
 (from r386373, 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSocketSender.java)
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSender.java?p2=tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSender.java&p1=tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSocketSender.java&r1=386373&r2=386672&rev=386672&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSocketSender.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AbstractSender.java
 Fri Mar 17 09:06:52 2006
@@ -34,7 +34,7 @@
  * @author not attributable
  * @version 1.0
  */
-public abstract class AbstractSocketSender implements DataSender {
+public abstract class AbstractSender implements DataSender {
 
 private boolean connected = false;
 private boolean waitForAck = false;
@@ -50,17 +50,18 @@
 private InetAddress address;
 private int port;
 private int maxRetryAttempts;
-public AbstractSocketSender() {
+private int attempt;
+public AbstractSender() {
 
 }
 
-public AbstractSocketSender(Member destination) throws 
UnknownHostException {
+public AbstractSender(Member destination) throws UnknownHostException {
 this.destination = destination;
 this.address = InetAddress.getByAddress(destination.getHost());
 this.port = destination.getPort();
 }
 
-public AbstractSocketSender(Member destination, int rxBufSize, int 
txBufSize) throws UnknownHostException {
+public AbstractSender(Member destination, int rxBufSize, int txBufSize) 
throws UnknownHostException {
 this(destination);
 this.rxBufSize = rxBufSize;
 this.txBufSize = txBufSize;
@@ -161,6 +162,9 @@
 return this.directBuffer;
 }
 
+public int getAttempt() {
+return attempt;
+}
 
 public void setKeepAliveCount(int keepAliveCount) {
 this.keepAliveCount = keepAliveCount;
@@ -196,5 +200,9 @@
 
 public void setMaxRetryAttempts(int maxRetryAttempts) {
 this.maxRetryAttempts = maxRetryAttempts;
+}
+
+public void setAttempt(int attempt) {
+this.attempt = attempt;
 }
 }

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java?rev=386672&r1=386671&r2=386672&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java
 Fri Mar 17 09:06:52 2006
@@ -30,7 +30,7 @@
  * @author not attributable
  * @version 1.0
  */
-public abstract class PooledSender extends AbstractSocketSender implements 
MultiPointSender {
+public abstract class PooledSender extends AbstractSender implements 
MultiPointSender {
 
 private SenderQueue queue = null;
 private int poolSize = 25;

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/bio/BioSender.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/bio/BioSender.java?

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

[Mladen Turk]

Jim Jagielski wrote:



Oh. I had thought that someone said that MaxOS did NOT
report itself as IS_UNIX (which would itself be a bug).
If that is no longer the case, then the MacOS side-benefit
is moot.


Right, and with the latest patch to the OS.java there is
no more 'Address already in use ...' error.

I've send the new tomcat-apr.jar to Stephan Faust,
and he confirmed that the error has gone.
(see Tomcat users list)

Perhaps one reason more for 5.5.17

Regards,
Mladen.


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

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

[Yoav Shapira]

Alright, I'll cut out 5.5.17.  When is the earliest time that's good
for you, i.e. you (everyone who's been discussing the native issues)
feel comfortable me cutting a release from trunk?

Yoav

On 3/17/06, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Jim Jagielski wrote:
> >
> >
> > Oh. I had thought that someone said that MaxOS did NOT
> > report itself as IS_UNIX (which would itself be a bug).
> > If that is no longer the case, then the MacOS side-benefit
> > is moot.
>
> Right, and with the latest patch to the OS.java there is
> no more 'Address already in use ...' error.
>
> I've send the new tomcat-apr.jar to Stephan Faust,
> and he confirmed that the error has gone.
> (see Tomcat users list)
>
> Perhaps one reason more for 5.5.17
>
> Regards,
> Mladen.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com

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

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

[Remy Maucherat]

Yoav Shapira wrote:

Alright, I'll cut out 5.5.17.  When is the earliest time that's good
for you, i.e. you (everyone who's been discussing the native issues)
feel comfortable me cutting a release from trunk?


-0. These are quite minor issues: definitely no reason to do a new release.

About the rebinding issues, this is quite funny, I remember asking for 
explanations to Mladen and Jim (who did apply a patch for it in the 
native code, as far as I can remember, but it's not in tcnative 1.1.2), 
and was ignored.


Rémy


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

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

[Mladen Turk]

Remy Maucherat wrote:
About the rebinding issues, this is quite funny, I remember asking for 
explanations to Mladen and Jim (who did apply a patch for it in the 
native code, as far as I can remember, but it's not in tcnative 1.1.2), 
and was ignored.


The problem was in OS.java, not in native.
OS.IS_UNIX was always false due to faulty initialization of fields,
so the reuseaddr was never called.

--
Mladen.



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

RE: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/ParserController.java

[Bill Barker]

 

> -Original Message-
> From: Jean-frederic Clere [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 17, 2006 4:13 AM
> To: Tomcat Developers List
> Subject: Re: svn commit: r386315 - 
> /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
> rserController.java
> 
> Bill Barker wrote:
> 
> > 
> >
> >  
> >
> >>-Original Message-
> >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> >>Sent: Thursday, March 16, 2006 3:55 AM
> >>To: tomcat-dev@jakarta.apache.org
> >>Subject: svn commit: r386315 - 
> >>/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
> >>rserController.java
> >>
> >>Author: jfclere
> >>Date: Thu Mar 16 03:54:29 2006
> >>New Revision: 386315
> >>
> >>URL: http://svn.apache.org/viewcvs?rev=386315&view=rev
> >>Log:
> >>If the encoding is not specified use the detected one.
> >>
> >>
> >>
> >
> >-1.
> >If it gets to this point, the detected encoding is *wrong* 
> (e.g.  >version="1.0" encoding="iso-8859-2" ?> in JSP syntax).
> >
> Why wrong?

Because the right encoding is the one specified in the <[EMAIL PROTECTED]
pageEncoding="utf8"%>.

> +++
> Connected to localhost.
> Escape character is '^]'.
> GET /try1.jsp
> 
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> +++
> 

This is about pageEncoding, so I don't see the relevance.

> >  
> >
> >I don't have access to an EBCDIC machine to know what the 
> problem is, but
> >this isn't the fix.  Possibly a better way to guess the 
> encoding of the
> >Reader?
> >  
> >
> Thinking to it  the patch is not prefect but the old code is worse we 
> have a piece of code that detects correctly the  source encoding and 
> detroy it...
> 

However, the old code adheres to the JSP spec, whereas your patch breaks the
JSP spec (Appendix D).  That automatically makes the old code better than
your patch.

> In doParse() in ParserController.java the following happends
> parse() is called with pageEnc = sourceEnc
> jspConfigPageEnc = null
> isDefaultPageEncoding = false.
> But the line before the jspReader uses the sourceEnc to create the 
> InputStreamReader so the content of the file is translated to 
> utf-8 when 
> reading it.
> In validator.java the charset will be set to the detected 
> encoding... In 
> the example above iso-8859.2. Bad for me that will be 
> OSD_EBCDIC_DF04_1.
> 

The only issue is why Jasper can't recognize your <[EMAIL PROTECTED]
pageEncoding="OSD_EBCDIC_DF04_1" %> statement.  That's the part that I can't
figure out (and your patch is masking :).

> Cheers
> 
> Jean-Frederic
> 
> > 
> >
> >
> >
> >This message is intended only for the use of the person(s) 
> listed above as the intended recipient(s), and may contain 
> information that is PRIVILEGED and CONFIDENTIAL.  If you are 
> not an intended recipient, you may not read, copy, or 
> distribute this message or any attachment. If you received 
> this communication in error, please notify us immediately by 
> e-mail and then delete all copies of this message and any attachments.
> >
> >In addition you should be aware that ordinary (unencrypted) 
> e-mail sent through the Internet is not secure. Do not send 
> confidential or sensitive information, such as social 
> security numbers, account numbers, personal identification 
> numbers and passwords, to us via ordinary (unencrypted) e-mail.
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >  
> >
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 



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

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


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

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

[Jim Jagielski]

On Mar 17, 2006, at 12:38 PM, Remy Maucherat wrote:


Yoav Shapira wrote:

Alright, I'll cut out 5.5.17.  When is the earliest time that's good
for you, i.e. you (everyone who's been discussing the native issues)
feel comfortable me cutting a release from trunk?


-0. These are quite minor issues: definitely no reason to do a new  
release.


About the rebinding issues, this is quite funny, I remember asking  
for explanations to Mladen and Jim (who did apply a patch for it in  
the native code, as far as I can remember, but it's not in tcnative  
1.1.2), and was ignored.




Different issue. The recent issue had to do with init's and re-inits
of OS data fields.

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

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

[Bill Barker]

 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Yoav Shapira
> Sent: Friday, March 17, 2006 9:16 AM
> To: Tomcat Developers List
> Subject: Re: http://issues.apache.org/bugzilla/show_bug.cgi?id=38984
> 
> Alright, I'll cut out 5.5.17.  When is the earliest time that's good
> for you, i.e. you (everyone who's been discussing the native issues)
> feel comfortable me cutting a release from trunk?
> 

We would need to resolve (i.e. revert :) JFC's Jasper patch before a
release.  The current Jasper in trunk is badly broken, so I'd have to vote
-1 on any release that contains the patch.



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

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


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

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

[Yoav Shapira]

Hi,

> > Alright, I'll cut out 5.5.17.  When is the earliest time that's good
> > for you, i.e. you (everyone who's been discussing the native issues)
> > feel comfortable me cutting a release from trunk?
> >
>
> We would need to resolve (i.e. revert :) JFC's Jasper patch before a
> release.  The current Jasper in trunk is badly broken, so I'd have to vote
> -1 on any release that contains the patch.

Yeah, I was thinking that might be the case.  That's why I asked if
trunk is in a decent state ;)  I'm not going to cut a release before
we arrive at some sort of consensus...

Yoav

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

Re: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/ParserController.java

[Costin Manolache]

In his example ( where both XML and JSP declare encodings ) - which one
would win ?

IMO the XML encoding should win i.e. if the file uses xml syntax and starts
with
, then jsp pageEncoding should
be ignored.
If a jsp is written using the XML syntax - it is supposed to follow the XML
rules - there is no
exception in the XML spec for jsps specifying their different syntax for
encoding.

For non-XML jsps - I think respecting pageEncoding is a must, the jsp reader
must scan the
file to find the pageEncoding string - which is not trivial ( there is a
reason why XML requires the
encoding to be the first thing in the file, at the top, I would't bet on
jasper implementing it correctly :-)

Costin

On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote:
>
>
>
> > -Original Message-
> > From: Jean-frederic Clere [mailto:[EMAIL PROTECTED]
> > Sent: Friday, March 17, 2006 4:13 AM
> > To: Tomcat Developers List
> > Subject: Re: svn commit: r386315 -
> > /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
> > rserController.java
> >
> > Bill Barker wrote:
> >
> > >
> > >
> > >
> > >
> > >>-Original Message-
> > >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > >>Sent: Thursday, March 16, 2006 3:55 AM
> > >>To: tomcat-dev@jakarta.apache.org
> > >>Subject: svn commit: r386315 -
> > >>/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
> > >>rserController.java
> > >>
> > >>Author: jfclere
> > >>Date: Thu Mar 16 03:54:29 2006
> > >>New Revision: 386315
> > >>
> > >>URL: http://svn.apache.org/viewcvs?rev=386315&view=rev
> > >>Log:
> > >>If the encoding is not specified use the detected one.
> > >>
> > >>
> > >>
> > >
> > >-1.
> > >If it gets to this point, the detected encoding is *wrong*
> > (e.g.  > >version="1.0" encoding="iso-8859-2" ?> in JSP syntax).
> > >
> > Why wrong?
>
> Because the right encoding is the one specified in the <[EMAIL PROTECTED]
> pageEncoding="utf8"%>.
>
> > +++
> > Connected to localhost.
> > Escape character is '^]'.
> > GET /try1.jsp
> > 
> >  >"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> > +++
> >
>
> This is about pageEncoding, so I don't see the relevance.
>
> > >
> > >
> > >I don't have access to an EBCDIC machine to know what the
> > problem is, but
> > >this isn't the fix.  Possibly a better way to guess the
> > encoding of the
> > >Reader?
> > >
> > >
> > Thinking to it  the patch is not prefect but the old code is worse we
> > have a piece of code that detects correctly the  source encoding and
> > detroy it...
> >
>
> However, the old code adheres to the JSP spec, whereas your patch breaks
> the
> JSP spec (Appendix D).  That automatically makes the old code better than
> your patch.
>
> > In doParse() in ParserController.java the following happends
> > parse() is called with pageEnc = sourceEnc
> > jspConfigPageEnc = null
> > isDefaultPageEncoding = false.
> > But the line before the jspReader uses the sourceEnc to create the
> > InputStreamReader so the content of the file is translated to
> > utf-8 when
> > reading it.
> > In validator.java the charset will be set to the detected
> > encoding... In
> > the example above iso-8859.2. Bad for me that will be
> > OSD_EBCDIC_DF04_1.
> >
>
> The only issue is why Jasper can't recognize your <[EMAIL PROTECTED]
> pageEncoding="OSD_EBCDIC_DF04_1" %> statement.  That's the part that I
> can't
> figure out (and your patch is masking :).
>
> > Cheers
> >
> > Jean-Frederic
> >
> > >
> > >
> > >
> > >
> > >This message is intended only for the use of the person(s)
> > listed above as the intended recipient(s), and may contain
> > information that is PRIVILEGED and CONFIDENTIAL.  If you are
> > not an intended recipient, you may not read, copy, or
> > distribute this message or any attachment. If you received
> > this communication in error, please notify us immediately by
> > e-mail and then delete all copies of this message and any attachments.
> > >
> > >In addition you should be aware that ordinary (unencrypted)
> > e-mail sent through the Internet is not secure. Do not send
> > confidential or sensitive information, such as social
> > security numbers, account numbers, personal identification
> > numbers and passwords, to us via ordinary (unencrypted) e-mail.
> > >
> > >
> > >-
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
>
> This message is intended only for the use of the person(s) listed above as
> the intended recipient(s), and may contain information that is PRIVILEGED
> and CONFIDENTIAL.  If you are not an intended recipient, you may not read,
> copy, or distribute this message or any attachment. If you received this
> communication in error

DO NOT REPLY [Bug 37850] - Core dumps on Solaris under concurrent load.

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-17 20:21 ---
Hi Jorge, Hi Mladen,

are you sure, that the stack is from the right thread?

If so, man page of Solaris 9 says localtime is not MT safe:

 The return values for  ctime(),  localtime(),  and  gmtime()
 point  to  static  data whose content is overwritten by each
 call.
...
 The asctime(), ctime(), gmtime(), and localtime()  functions
 are unsafe in multithread applications.  The asctime_r() and
 gmtime_r()   functions   are   MT-Safe.Thectime_r(),
 localtime_r(),  and  tzset()  functions  are MT-Safe in mul-
 tithread applications, as long as no  user-defined  function
 directly  modifies one of the following variables: timezone,
 altzone, daylight, and tzname.  These four variables are not
 MT-Safe to access. They are modified by the tzset() function
 in an MT-Safe manner.   The   mktime(),  localtime_r(),  and
 ctime_r() functions call tzset().

-- 
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: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/ParserController.java

[Bill Barker]

 

> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 17, 2006 11:57 AM
> To: Tomcat Developers List
> Subject: Re: svn commit: r386315 - 
> /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
> rserController.java
> 
> In his example ( where both XML and JSP declare encodings ) - 
> which one
> would win ?

The patch only affects pages in JSP syntax, so the  is just
another piece of template text :).

> 
> IMO the XML encoding should win i.e. if the file uses xml 
> syntax and starts
> with
> , then jsp 
> pageEncoding should
> be ignored.
> If a jsp is written using the XML syntax - it is supposed to 
> follow the XML
> rules - there is no
> exception in the XML spec for jsps specifying their different 
> syntax for
> encoding.
> 

The JSP expert group agrees with you:).  In XML syntax, the XML encoding
should win out over .

> For non-XML jsps - I think respecting pageEncoding is a must, 
> the jsp reader
> must scan the
> file to find the pageEncoding string - which is not trivial ( 
> there is a
> reason why XML requires the
> encoding to be the first thing in the file, at the top, I 
> would't bet on
> jasper implementing it correctly :-)
> 

In JSP syntax, the spec (Appendix D) says that pageEncoding should win (at
least when there is no matching  in web.xml :).  What the
patch breaks is that with it Jasper won't even look for the pageEncoding
most of the time.

Jasper looks like it does a pretty good job of guessing to set up the Reader
that scans for the pageEncoding directive.  And JFC seems to agree, since
the patch is to use the guessed encoding rather than the one that was
specified :).

> Costin
> 
> On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Jean-frederic Clere [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, March 17, 2006 4:13 AM
> > > To: Tomcat Developers List
> > > Subject: Re: svn commit: r386315 -
> > > /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
> > > rserController.java
> > >
> > > Bill Barker wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > >>-Original Message-
> > > >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > >>Sent: Thursday, March 16, 2006 3:55 AM
> > > >>To: tomcat-dev@jakarta.apache.org
> > > >>Subject: svn commit: r386315 -
> > > >>/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
> > > >>rserController.java
> > > >>
> > > >>Author: jfclere
> > > >>Date: Thu Mar 16 03:54:29 2006
> > > >>New Revision: 386315
> > > >>
> > > >>URL: http://svn.apache.org/viewcvs?rev=386315&view=rev
> > > >>Log:
> > > >>If the encoding is not specified use the detected one.
> > > >>
> > > >>
> > > >>
> > > >
> > > >-1.
> > > >If it gets to this point, the detected encoding is *wrong*
> > > (e.g.  > > >version="1.0" encoding="iso-8859-2" ?> in JSP syntax).
> > > >
> > > Why wrong?
> >
> > Because the right encoding is the one specified in the <[EMAIL PROTECTED]
> > pageEncoding="utf8"%>.
> >
> > > +++
> > > Connected to localhost.
> > > Escape character is '^]'.
> > > GET /try1.jsp
> > > 
> > >  > >"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> > > +++
> > >
> >
> > This is about pageEncoding, so I don't see the relevance.
> >
> > > >
> > > >
> > > >I don't have access to an EBCDIC machine to know what the
> > > problem is, but
> > > >this isn't the fix.  Possibly a better way to guess the
> > > encoding of the
> > > >Reader?
> > > >
> > > >
> > > Thinking to it  the patch is not prefect but the old code 
> is worse we
> > > have a piece of code that detects correctly the  source 
> encoding and
> > > detroy it...
> > >
> >
> > However, the old code adheres to the JSP spec, whereas your 
> patch breaks
> > the
> > JSP spec (Appendix D).  That automatically makes the old 
> code better than
> > your patch.
> >
> > > In doParse() in ParserController.java the following happends
> > > parse() is called with pageEnc = sourceEnc
> > > jspConfigPageEnc = null
> > > isDefaultPageEncoding = false.
> > > But the line before the jspReader uses the sourceEnc to create the
> > > InputStreamReader so the content of the file is translated to
> > > utf-8 when
> > > reading it.
> > > In validator.java the charset will be set to the detected
> > > encoding... In
> > > the example above iso-8859.2. Bad for me that will be
> > > OSD_EBCDIC_DF04_1.
> > >
> >
> > The only issue is why Jasper can't recognize your <[EMAIL PROTECTED]
> > pageEncoding="OSD_EBCDIC_DF04_1" %> statement.  That's the 
> part that I
> > can't
> > figure out (and your patch is masking :).
> >
> > > Cheers
> > >
> > > Jean-Frederic
> > >
> > > >
> > > >
> > > >
> > > >
> > > >This message is intended only for the use of the person(s)
> > > listed above as the intended recipient(s), and may contain
> > > information that is PRIVILEGED and CONFIDENTIAL.  If you are
> > > not an intended recipient, you may not read, copy, or
> > > distribute this message or an

Re: mod_jk [STATUS]

[Chris Lamprecht]

Mladen,
Thanks for applying the busyness patch (and the other fixes)!  Once
1.2.16 is tagged, I'll try to test it on our setup.  We're still
running our lb-busyness-patched version with 1.2.14.
-chris

On 3/17/06, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> There is quite large list of fixed bugs for mod_jk
> from the 1.2.15:
>
> #37469: Fix shared memory close for forked childs.
> #37332: Fix potential misuse of buffer length with snprintf.
> #38859: Protect mod_jk against buggy or malicious AJP servers.
> #38889: Use worker map sorting depending on the path elements.
> #36138: Added Busyness lb method.
> #none:  Fix loadbalancer for burst load.
> #38806: Reclycle worker even if it is disabled.
> #37167: Allow building with BSD-ish like make.
> #none:  Fix ISAPI plugin log.
>
>
> Is this worth tagging and releasing 1.2.16?
>
> Regards,
> Mladen.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: mod_jk [STATUS]

[William A. Rowe, Jr.]

Chris Lamprecht wrote:

Mladen,
Thanks for applying the busyness patch (and the other fixes)!  Once
1.2.16 is tagged, I'll try to test it on our setup.  We're still
running our lb-busyness-patched version with 1.2.14.


If there's any hope of waiting a day or few, I'd like to ensure this can
be configured and built to both 2.0 and 2.2 on windows and unix.  At one
point I thought I had started the effort, but had invested no energy at
that time on the unix build.

Bill

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

Re: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/ParserController.java

[Costin Manolache]

Sorry, I forgot there are 2 meanings of  'xml syntax' :-), I was thinking if
the output
is an xml file - with encoding in declaration, but in regular jsp. (well,
the patch is not dealing
with jspx anyway )
I was referring to the fact that  is treated as
template text,
and pageEncoding (or web.xml ) takes precedence.
In jsp-xml ( jspx ) it seems we report an error if the web.xml encoding
doesn't match the
 encoding. I can't see many use cases for having an explicit encoding
in the
xml header, and yet the file read with a different encoding.


Costin


On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote:
>
>
>
> > -Original Message-
> > From: Costin Manolache [mailto:[EMAIL PROTECTED]
> > Sent: Friday, March 17, 2006 11:57 AM
> > To: Tomcat Developers List
> > Subject: Re: svn commit: r386315 -
> > /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
> > rserController.java
> >
> > In his example ( where both XML and JSP declare encodings ) -
> > which one
> > would win ?
>
> The patch only affects pages in JSP syntax, so the  is just
> another piece of template text :).
>
> >
> > IMO the XML encoding should win i.e. if the file uses xml
> > syntax and starts
> > with
> > , then jsp
> > pageEncoding should
> > be ignored.
> > If a jsp is written using the XML syntax - it is supposed to
> > follow the XML
> > rules - there is no
> > exception in the XML spec for jsps specifying their different
> > syntax for
> > encoding.
> >
>
> The JSP expert group agrees with you:).  In XML syntax, the XML encoding
> should win out over .
>
> > For non-XML jsps - I think respecting pageEncoding is a must,
> > the jsp reader
> > must scan the
> > file to find the pageEncoding string - which is not trivial (
> > there is a
> > reason why XML requires the
> > encoding to be the first thing in the file, at the top, I
> > would't bet on
> > jasper implementing it correctly :-)
> >
>
> In JSP syntax, the spec (Appendix D) says that pageEncoding should win (at
> least when there is no matching  in web.xml :).  What the
> patch breaks is that with it Jasper won't even look for the pageEncoding
> most of the time.
>
> Jasper looks like it does a pretty good job of guessing to set up the
> Reader
> that scans for the pageEncoding directive.  And JFC seems to agree, since
> the patch is to use the guessed encoding rather than the one that was
> specified :).
>
> > Costin
> >
> > On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Jean-frederic Clere [mailto:[EMAIL PROTECTED]
> > > > Sent: Friday, March 17, 2006 4:13 AM
> > > > To: Tomcat Developers List
> > > > Subject: Re: svn commit: r386315 -
> > > > /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
> > > > rserController.java
> > > >
> > > > Bill Barker wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >>-Original Message-
> > > > >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > > >>Sent: Thursday, March 16, 2006 3:55 AM
> > > > >>To: tomcat-dev@jakarta.apache.org
> > > > >>Subject: svn commit: r386315 -
> > > > >>/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
> > > > >>rserController.java
> > > > >>
> > > > >>Author: jfclere
> > > > >>Date: Thu Mar 16 03:54:29 2006
> > > > >>New Revision: 386315
> > > > >>
> > > > >>URL: http://svn.apache.org/viewcvs?rev=386315&view=rev
> > > > >>Log:
> > > > >>If the encoding is not specified use the detected one.
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >-1.
> > > > >If it gets to this point, the detected encoding is *wrong*
> > > > (e.g.  > > > >version="1.0" encoding="iso-8859-2" ?> in JSP syntax).
> > > > >
> > > > Why wrong?
> > >
> > > Because the right encoding is the one specified in the <[EMAIL PROTECTED]
> > > pageEncoding="utf8"%>.
> > >
> > > > +++
> > > > Connected to localhost.
> > > > Escape character is '^]'.
> > > > GET /try1.jsp
> > > > 
> > > >  > > >"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> > > > +++
> > > >
> > >
> > > This is about pageEncoding, so I don't see the relevance.
> > >
> > > > >
> > > > >
> > > > >I don't have access to an EBCDIC machine to know what the
> > > > problem is, but
> > > > >this isn't the fix.  Possibly a better way to guess the
> > > > encoding of the
> > > > >Reader?
> > > > >
> > > > >
> > > > Thinking to it  the patch is not prefect but the old code
> > is worse we
> > > > have a piece of code that detects correctly the  source
> > encoding and
> > > > detroy it...
> > > >
> > >
> > > However, the old code adheres to the JSP spec, whereas your
> > patch breaks
> > > the
> > > JSP spec (Appendix D).  That automatically makes the old
> > code better than
> > > your patch.
> > >
> > > > In doParse() in ParserController.java the following happends
> > > > parse() is called with pageEnc = sourceEnc
> > > > jspConfigPageEnc = null
> > > > isDefaultPageEncoding = false.
> > > > But the line before the jspReader uses the sourceEnc to cr

svn commit: r386733 - /tomcat/container/tc5.5.x/modules/groupcom/to-do.txt

[fhanik]

Author: fhanik
Date: Fri Mar 17 13:53:41 2006
New Revision: 386733

URL: http://svn.apache.org/viewcvs?rev=386733&view=rev
Log:
added todo stuff

Modified:
tomcat/container/tc5.5.x/modules/groupcom/to-do.txt

Modified: tomcat/container/tc5.5.x/modules/groupcom/to-do.txt
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/to-do.txt?rev=386733&r1=386732&r2=386733&view=diff
==
--- tomcat/container/tc5.5.x/modules/groupcom/to-do.txt (original)
+++ tomcat/container/tc5.5.x/modules/groupcom/to-do.txt Fri Mar 17 13:53:41 2006
@@ -3,7 +3,26 @@
 
 Documentation:
 ===
+ Why is tribes unique compared to JGroups/Appia
+ 1. Uses NIO and TCP for guaranteed delivery and the ability to join large 
groups
+ 2. Guarantees messages the following way
+a) TCP messaging
+b) ACK messages from the receiver
+c) ACK after processing
+
+ 3. Same (single) channel can handle all types of guarantees (a,b,c) at the 
same time
+and both process synchronous and asynchronous messaging.
+This is key to support different requirements for messaging through 
+the same channel to save system resources.
 
+ 4. For async messaging, errors are reported through an error handler, callback
+ 
+ 5. Ability to send on multiple streams at the same time, in parallel, to 
improve performance
+ 
+ 6. Future version will have WAN membership and replication
+
+
+ 
 
 Code Tasks:
 ===



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

svn commit: r386737 - /tomcat/container/tc5.5.x/modules/groupcom/to-do.txt

[fhanik]

Author: fhanik
Date: Fri Mar 17 13:59:14 2006
New Revision: 386737

URL: http://svn.apache.org/viewcvs?rev=386737&view=rev
Log:
added completed task

Modified:
tomcat/container/tc5.5.x/modules/groupcom/to-do.txt

Modified: tomcat/container/tc5.5.x/modules/groupcom/to-do.txt
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/to-do.txt?rev=386737&r1=386736&r2=386737&view=diff
==
--- tomcat/container/tc5.5.x/modules/groupcom/to-do.txt (original)
+++ tomcat/container/tc5.5.x/modules/groupcom/to-do.txt Fri Mar 17 13:59:14 2006
@@ -27,8 +27,7 @@
 Code Tasks:
 ===
 
-22. sendAck and synchronized should not have to be a XML config,
-it can be configured on a per packet basis using ClusterData.getOptions()
+23. TotalOrderInterceptor
 
 21. Implement a WAN membership layer, using a WANMbrInterceptor and a 
 WAN Router/Forwarder (Tipi on top of a ManagedChannel)
@@ -125,4 +124,8 @@
 names and the locations.
 It can replicate every X seconds, or on dirty flags by the objects stored,
 or a request to scan for dirty flags, or a request with the objects.
-Notes: the map has been completed
\ No newline at end of file
+Notes: the map has been completed
+
+22. sendAck and synchronized should not have to be a XML config,
+it can be configured on a per packet basis using ClusterData.getOptions()
+Notes: see Channel.SEND_OPT_ variables
\ No newline at end of file



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

Anne-Sophie Brichard/EUZ/ChubbMail is out of the office.

[abrichard]

I will be out of the office starting  17/03/2006 and will not return until
18/03/2007.

En cas d'urgence, merci de bien vouloir contacter Sandra Boutboul
([EMAIL PROTECTED]) au 01 70 36 65 90

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

svn commit: r386742 - /tomcat/site/trunk/docs/doap_Tomcat.rdf

[yoavs]

Author: yoavs
Date: Fri Mar 17 14:30:47 2006
New Revision: 386742

URL: http://svn.apache.org/viewcvs?rev=386742&view=rev
Log:
Updated DOAP.

Modified:
tomcat/site/trunk/docs/doap_Tomcat.rdf

Modified: tomcat/site/trunk/docs/doap_Tomcat.rdf
URL: 
http://svn.apache.org/viewcvs/tomcat/site/trunk/docs/doap_Tomcat.rdf?rev=386742&r1=386741&r2=386742&view=diff
==
--- tomcat/site/trunk/docs/doap_Tomcat.rdf (original)
+++ tomcat/site/trunk/docs/doap_Tomcat.rdf Fri Mar 17 14:30:47 2006
@@ -20,8 +20,13 @@
 http://tomcat.apache.org/lists.html"; />
 http://tomcat.apache.org"; />
 java
-http://projects.apache.org/category/servletcontainerJavaServerPagesJSP";
 />
+http://projects.apache.org/category/servletContainer"; />
 
+  
+5.5.16
+2006-03-05
+5.5.16
+  
   
 5.5.15
 2006-01-23



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

svn commit: r386744 - /tomcat/site/trunk/docs/doap_Tomcat.rdf

[yoavs]

Author: yoavs
Date: Fri Mar 17 14:36:31 2006
New Revision: 386744

URL: http://svn.apache.org/viewcvs?rev=386744&view=rev
Log:
Further DOAP stuff.

Modified:
tomcat/site/trunk/docs/doap_Tomcat.rdf

Modified: tomcat/site/trunk/docs/doap_Tomcat.rdf
URL: 
http://svn.apache.org/viewcvs/tomcat/site/trunk/docs/doap_Tomcat.rdf?rev=386744&r1=386743&r2=386744&view=diff
==
--- tomcat/site/trunk/docs/doap_Tomcat.rdf (original)
+++ tomcat/site/trunk/docs/doap_Tomcat.rdf Fri Mar 17 14:36:31 2006
@@ -19,11 +19,11 @@
 http://issues.apache.org/bugzilla"; />
 http://tomcat.apache.org/lists.html"; />
 http://tomcat.apache.org"; />
-java
-http://projects.apache.org/category/servletContainer"; />
+Java
+http://projects.apache.org/category/network-server"; />
 
   
-5.5.16
+Latest Stable Release
 2006-03-05
 5.5.16
   
@@ -39,6 +39,18 @@
 http://svn.apache.org/repos/asf/tomcat/"/>
   
 
+
+  Java Servlets
+  JCP
+  JSR 154
+  http://www.jcp.org/en/jsr/detail?id=154"/>
+
+
+  Java Server Pages
+  JCP
+  JSR 152
+  http://www.jcp.org/en/jsr/detail?id=152"/>
+
   
 
 



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

svn commit: r386748 - /tomcat/site/trunk/docs/doap_Tomcat.rdf

[yoavs]

Author: yoavs
Date: Fri Mar 17 14:49:06 2006
New Revision: 386748

URL: http://svn.apache.org/viewcvs?rev=386748&view=rev
Log:
Yet one more DOAP addition

Modified:
tomcat/site/trunk/docs/doap_Tomcat.rdf

Modified: tomcat/site/trunk/docs/doap_Tomcat.rdf
URL: 
http://svn.apache.org/viewcvs/tomcat/site/trunk/docs/doap_Tomcat.rdf?rev=386748&r1=386747&r2=386748&view=diff
==
--- tomcat/site/trunk/docs/doap_Tomcat.rdf (original)
+++ tomcat/site/trunk/docs/doap_Tomcat.rdf Fri Mar 17 14:49:06 2006
@@ -21,6 +21,12 @@
 http://tomcat.apache.org"; />
 Java
 http://projects.apache.org/category/network-server"; />
+
+  
+Tomcat PMC
+  mailto:dev@tomcat.apache.org"/>
+  
+
 
   
 Latest Stable Release



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

svn commit: r386754 - /tomcat/site/trunk/docs/doap_Tomcat.rdf

[yoavs]

Author: yoavs
Date: Fri Mar 17 15:02:11 2006
New Revision: 386754

URL: http://svn.apache.org/viewcvs?rev=386754&view=rev
Log:
Corrected and added missing namespace.

Modified:
tomcat/site/trunk/docs/doap_Tomcat.rdf

Modified: tomcat/site/trunk/docs/doap_Tomcat.rdf
URL: 
http://svn.apache.org/viewcvs/tomcat/site/trunk/docs/doap_Tomcat.rdf?rev=386754&r1=386753&r2=386754&view=diff
==
--- tomcat/site/trunk/docs/doap_Tomcat.rdf (original)
+++ tomcat/site/trunk/docs/doap_Tomcat.rdf Fri Mar 17 15:02:11 2006
@@ -3,7 +3,8 @@
 http://usefulinc.com/ns/doap#"; 
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; 
- xmlns:asfext="http:projects.apache.org/ns/asfext#">
+ xmlns:asfext="http://projects.apache.org/ns/asfext#";
+ xmlns:foaf="http://xmlsns.com/foaf/0.1/";>
   http://tomcat.apache.org/";>
 2006-01-27
 http://usefulinc.com/doap/licenses/asl20"; />



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

Re: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/ParserController.java

[Jean-frederic Clere]

Costin Manolache wrote:


Sorry, I forgot there are 2 meanings of  'xml syntax' :-), I was thinking if
the output
is an xml file - with encoding in declaration, but in regular jsp. (well,
the patch is not dealing
with jspx anyway )
I was referring to the fact that  is treated as
template text,
and pageEncoding (or web.xml ) takes precedence.
In jsp-xml ( jspx ) it seems we report an error if the web.xml encoding
doesn't match the
 encoding. I can't see many use cases for having an explicit encoding
in the
xml header, and yet the file read with a different encoding.
 


In my case the xml header is:
 (In EBCDIC...)
Reading the file with ISO-8859-1 encoding only gives garbages.

But the patch prevents reading the  <@page pageEncoding="bla" %> so it 
is bad.


The old code should be improved to allow to use the sourceEnc when the 
pageEncoding is not specified and ISO-8859-1 if none are specified.


Cheers

Jean-Frederic



Costin


On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote:
 



   


-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED]
Sent: Friday, March 17, 2006 11:57 AM
To: Tomcat Developers List
Subject: Re: svn commit: r386315 -
/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
rserController.java

In his example ( where both XML and JSP declare encodings ) -
which one
would win ?
 


The patch only affects pages in JSP syntax, so the  is just
another piece of template text :).

   


IMO the XML encoding should win i.e. if the file uses xml
syntax and starts
with
, then jsp
pageEncoding should
be ignored.
If a jsp is written using the XML syntax - it is supposed to
follow the XML
rules - there is no
exception in the XML spec for jsps specifying their different
syntax for
encoding.

 


The JSP expert group agrees with you:).  In XML syntax, the XML encoding
should win out over .

   


For non-XML jsps - I think respecting pageEncoding is a must,
the jsp reader
must scan the
file to find the pageEncoding string - which is not trivial (
there is a
reason why XML requires the
encoding to be the first thing in the file, at the top, I
would't bet on
jasper implementing it correctly :-)

 


In JSP syntax, the spec (Appendix D) says that pageEncoding should win (at
least when there is no matching  in web.xml :).  What the
patch breaks is that with it Jasper won't even look for the pageEncoding
most of the time.

Jasper looks like it does a pretty good job of guessing to set up the
Reader
that scans for the pageEncoding directive.  And JFC seems to agree, since
the patch is to use the guessed encoding rather than the one that was
specified :).

   


Costin

On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote:
 



   


-Original Message-
From: Jean-frederic Clere [mailto:[EMAIL PROTECTED]
Sent: Friday, March 17, 2006 4:13 AM
To: Tomcat Developers List
Subject: Re: svn commit: r386315 -
/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
rserController.java

Bill Barker wrote:

 




   


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 16, 2006 3:55 AM
To: tomcat-dev@jakarta.apache.org
Subject: svn commit: r386315 -
/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
rserController.java

Author: jfclere
Date: Thu Mar 16 03:54:29 2006
New Revision: 386315

URL: http://svn.apache.org/viewcvs?rev=386315&view=rev
Log:
If the encoding is not specified use the detected one.



 


-1.
If it gets to this point, the detected encoding is *wrong*
   


(e.g.  


version="1.0" encoding="iso-8859-2" ?> in JSP syntax).

   


Why wrong?
 


Because the right encoding is the one specified in the <[EMAIL PROTECTED]
pageEncoding="utf8"%>.

   


+++
Connected to localhost.
Escape character is '^]'.
GET /try1.jsp

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
+++

 


This is about pageEncoding, so I don't see the relevance.

   


I don't have access to an EBCDIC machine to know what the
   


problem is, but
 


this isn't the fix.  Possibly a better way to guess the
   


encoding of the
 


Reader?


   


Thinking to it  the patch is not prefect but the old code
 


is worse we
 


have a piece of code that detects correctly the  source
 


encoding and
 


detroy it...

 


However, the old code adheres to the JSP spec, whereas your
   


patch breaks
 


the
JSP spec (Appendix D).  That automatically makes the old
   


code better than
 


your patch.

   


In doParse() in ParserController.java the following happends
parse() is called with pageEnc = sourceEnc
jspConfigPageEnc = null
isDefaultPageEncoding = false.
But the line before the jspReader uses the sourceEnc to create the
InputStreamReader so the content of the file is translated to
utf-8 when
reading it.
In validator.java the charset will be 

Re: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/ParserController.java

[Jean-frederic Clere]

Costin Manolache wrote:


Sorry, I forgot there are 2 meanings of  'xml syntax' :-), I was thinking if
the output
is an xml file - with encoding in declaration, but in regular jsp. (well,
the patch is not dealing
with jspx anyway )
I was referring to the fact that  is treated as
template text,
and pageEncoding (or web.xml ) takes precedence.
In jsp-xml ( jspx ) it seems we report an error if the web.xml encoding
doesn't match the
 encoding. I can't see many use cases for having an explicit encoding
in the
xml header, and yet the file read with a different encoding.
 

The spec (JavaServer Pages 2.1 Specification (Proposed Final Draft 2) 
page 3-113 says:

+++
The page character encoding of documents in XML syntax is now always 
detected

in the XML specification. The pageEncoding attribute and/or page-encoding
configuration element may be given, but must not disagree with the
XML prolog.
+++
What should we do if the disagreement happends?



Costin


On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote:
 



   


-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED]
Sent: Friday, March 17, 2006 11:57 AM
To: Tomcat Developers List
Subject: Re: svn commit: r386315 -
/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
rserController.java

In his example ( where both XML and JSP declare encodings ) -
which one
would win ?
 


The patch only affects pages in JSP syntax, so the  is just
another piece of template text :).

   


IMO the XML encoding should win i.e. if the file uses xml
syntax and starts
with
, then jsp
pageEncoding should
be ignored.
If a jsp is written using the XML syntax - it is supposed to
follow the XML
rules - there is no
exception in the XML spec for jsps specifying their different
syntax for
encoding.

 


The JSP expert group agrees with you:).  In XML syntax, the XML encoding
should win out over .

   


For non-XML jsps - I think respecting pageEncoding is a must,
the jsp reader
must scan the
file to find the pageEncoding string - which is not trivial (
there is a
reason why XML requires the
encoding to be the first thing in the file, at the top, I
would't bet on
jasper implementing it correctly :-)

 


In JSP syntax, the spec (Appendix D) says that pageEncoding should win (at
least when there is no matching  in web.xml :).  What the
patch breaks is that with it Jasper won't even look for the pageEncoding
most of the time.

Jasper looks like it does a pretty good job of guessing to set up the
Reader
that scans for the pageEncoding directive.  And JFC seems to agree, since
the patch is to use the guessed encoding rather than the one that was
specified :).

   


Costin

On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote:
 



   


-Original Message-
From: Jean-frederic Clere [mailto:[EMAIL PROTECTED]
Sent: Friday, March 17, 2006 4:13 AM
To: Tomcat Developers List
Subject: Re: svn commit: r386315 -
/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
rserController.java

Bill Barker wrote:

 




   


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 16, 2006 3:55 AM
To: tomcat-dev@jakarta.apache.org
Subject: svn commit: r386315 -
/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
rserController.java

Author: jfclere
Date: Thu Mar 16 03:54:29 2006
New Revision: 386315

URL: http://svn.apache.org/viewcvs?rev=386315&view=rev
Log:
If the encoding is not specified use the detected one.



 


-1.
If it gets to this point, the detected encoding is *wrong*
   


(e.g.  


version="1.0" encoding="iso-8859-2" ?> in JSP syntax).

   


Why wrong?
 


Because the right encoding is the one specified in the <[EMAIL PROTECTED]
pageEncoding="utf8"%>.

   


+++
Connected to localhost.
Escape character is '^]'.
GET /try1.jsp

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
+++

 


This is about pageEncoding, so I don't see the relevance.

   


I don't have access to an EBCDIC machine to know what the
   


problem is, but
 


this isn't the fix.  Possibly a better way to guess the
   


encoding of the
 


Reader?


   


Thinking to it  the patch is not prefect but the old code
 


is worse we
 


have a piece of code that detects correctly the  source
 


encoding and
 


detroy it...

 


However, the old code adheres to the JSP spec, whereas your
   


patch breaks
 


the
JSP spec (Appendix D).  That automatically makes the old
   


code better than
 


your patch.

   


In doParse() in ParserController.java the following happends
parse() is called with pageEnc = sourceEnc
jspConfigPageEnc = null
isDefaultPageEncoding = false.
But the line before the jspReader uses the sourceEnc to create the
InputStreamReader so the content of the file is translated to
utf-8 when
reading it.
In validator.java

Re: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/ParserController.java

[Costin Manolache]

On 3/17/06, Jean-frederic Clere <[EMAIL PROTECTED]> wrote:
>
> Costin Manolache wrote:
>
> >Sorry, I forgot there are 2 meanings of  'xml syntax' :-), I was thinking
> if
> >the output
> >is an xml file - with encoding in declaration, but in regular jsp. (well,
> >the patch is not dealing
> >with jspx anyway )
> >I was referring to the fact that  is treated
> as
> >template text,
> >and pageEncoding (or web.xml ) takes precedence.
> >In jsp-xml ( jspx ) it seems we report an error if the web.xml encoding
> >doesn't match the
> > encoding. I can't see many use cases for having an explicit
> encoding
> >in the
> >xml header, and yet the file read with a different encoding.
> >
> >
> In my case the xml header is:
>  (In EBCDIC...)
> Reading the file with ISO-8859-1 encoding only gives garbages.
>
> But the patch prevents reading the  <@page pageEncoding="bla" %> so it
> is bad.



Yes, the patch is bad - but what would be a good patch ?

- if pageEncoding is not specified but document starts with  - use xml encoding
- if pageEncoding is specified and so is  - report an error
( like jspx does ) or
a warning or choose the xml encoding
- leave current behavior - use default 8859-1 or pageEncoding only.

 is probably more used and supported ( i.e. more 'standard'
:-) that jsp pageEncoding.
The jsp spec is clear that last option should be used - but having 2
conflicting encodings is a source of problems,
and if we can't follow the 'higher' standard, we can at least warn.

Well - not a big deal, but encodings tends to be a headache area for many
people, in particular
when different parts of the system have different 'standards' and defaults
plus autodetections ( on browser,  http, html,
xml, or jsp ).

Costin


The old code should be improved to allow to use the sourceEnc when the
> pageEncoding is not specified and ISO-8859-1 if none are specified.






Cheers
>
> Jean-Frederic
>
> >
> >Costin
> >
> >
> >On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote:
> >
> >
> >>
> >>
> >>
> >>>-Original Message-
> >>>From: Costin Manolache [mailto:[EMAIL PROTECTED]
> >>>Sent: Friday, March 17, 2006 11:57 AM
> >>>To: Tomcat Developers List
> >>>Subject: Re: svn commit: r386315 -
> >>>/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
> >>>rserController.java
> >>>
> >>>In his example ( where both XML and JSP declare encodings ) -
> >>>which one
> >>>would win ?
> >>>
> >>>
> >>The patch only affects pages in JSP syntax, so the  is just
> >>another piece of template text :).
> >>
> >>
> >>
> >>>IMO the XML encoding should win i.e. if the file uses xml
> >>>syntax and starts
> >>>with
> >>>, then jsp
> >>>pageEncoding should
> >>>be ignored.
> >>>If a jsp is written using the XML syntax - it is supposed to
> >>>follow the XML
> >>>rules - there is no
> >>>exception in the XML spec for jsps specifying their different
> >>>syntax for
> >>>encoding.
> >>>
> >>>
> >>>
> >>The JSP expert group agrees with you:).  In XML syntax, the XML encoding
> >>should win out over .
> >>
> >>
> >>
> >>>For non-XML jsps - I think respecting pageEncoding is a must,
> >>>the jsp reader
> >>>must scan the
> >>>file to find the pageEncoding string - which is not trivial (
> >>>there is a
> >>>reason why XML requires the
> >>>encoding to be the first thing in the file, at the top, I
> >>>would't bet on
> >>>jasper implementing it correctly :-)
> >>>
> >>>
> >>>
> >>In JSP syntax, the spec (Appendix D) says that pageEncoding should win
> (at
> >>least when there is no matching  in web.xml :).  What
> the
> >>patch breaks is that with it Jasper won't even look for the pageEncoding
> >>most of the time.
> >>
> >>Jasper looks like it does a pretty good job of guessing to set up the
> >>Reader
> >>that scans for the pageEncoding directive.  And JFC seems to agree,
> since
> >>the patch is to use the guessed encoding rather than the one that was
> >>specified :).
> >>
> >>
> >>
> >>>Costin
> >>>
> >>>On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> 
> 
> 
> >-Original Message-
> >From: Jean-frederic Clere [mailto:[EMAIL PROTECTED]
> >Sent: Friday, March 17, 2006 4:13 AM
> >To: Tomcat Developers List
> >Subject: Re: svn commit: r386315 -
> >/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
> >rserController.java
> >
> >Bill Barker wrote:
> >
> >
> >
> >>
> >>
> >>
> >>
> >>>-Original Message-
> >>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> >>>Sent: Thursday, March 16, 2006 3:55 AM
> >>>To: tomcat-dev@jakarta.apache.org
> >>>Subject: svn commit: r386315 -
> >>>/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa
> >>>rserController.java
> >>>
> >>>Author: jfclere
> >>>Date: Thu Mar 16 03:54:29 2006
> >>>New Revision: 386315
> >>>
> >>>URL: http://svn.apache.org/viewcvs?rev=386315&view=rev
> >>>Log:
> >>>If the encoding is not specified use the

svn commit: r386806 - /tomcat/container/tc5.5.x/modules/groupcom/to-do.txt

[fhanik]

Author: fhanik
Date: Fri Mar 17 20:19:18 2006
New Revision: 386806

URL: http://svn.apache.org/viewcvs?rev=386806&view=rev
Log:
added total order interceptor to the list

Modified:
tomcat/container/tc5.5.x/modules/groupcom/to-do.txt

Modified: tomcat/container/tc5.5.x/modules/groupcom/to-do.txt
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/to-do.txt?rev=386806&r1=386805&r2=386806&view=diff
==
--- tomcat/container/tc5.5.x/modules/groupcom/to-do.txt (original)
+++ tomcat/container/tc5.5.x/modules/groupcom/to-do.txt Fri Mar 17 20:19:18 2006
@@ -27,7 +27,12 @@
 Code Tasks:
 ===
 
-23. TotalOrderInterceptor
+23. TotalOrderInterceptor - fairly straight forward implementation
+This interceptor would depend on the fact that there is some sort of 
+membership coordinator, see task 9.
+Once there is a coordinator in the group, the total order protocol is the 
same 
+as the OrderInterceptor, except that it gets its message number from 
+the coordinator, prior to sending it out.
 
 21. Implement a WAN membership layer, using a WANMbrInterceptor and a 
 WAN Router/Forwarder (Tipi on top of a ManagedChannel)



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

svn commit: r386814 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

[fhanik]

Author: fhanik
Date: Fri Mar 17 22:33:10 2006
New Revision: 386814

URL: http://svn.apache.org/viewcvs?rev=386814&view=rev
Log:
format fix

Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java?rev=386814&r1=386813&r2=386814&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 Fri Mar 17 22:33:10 2006
@@ -121,8 +121,7 @@
 //unique context is more efficient if it is stored as bytes
 this.mapContextName = mapContextName.getBytes(chset);
 } catch (UnsupportedEncodingException x) {
-log.warn("Unable to encode mapContextName[" + mapContextName + "] 
using getBytes(" + chset +
- ") using default getBytes()", x);
+log.warn("Unable to encode mapContextName[" + mapContextName + "] 
using getBytes(" + chset +") using default getBytes()", x);
 this.mapContextName = mapContextName.getBytes();
 }
 



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

svn commit: r386815 - in /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis: AbstractReplicatedMap.java LazyReplicatedMap.java ReplicatedMap.java

[fhanik]

Author: fhanik
Date: Fri Mar 17 22:37:07 2006
New Revision: 386815

URL: http://svn.apache.org/viewcvs?rev=386815&view=rev
Log:
send options is configurable on the abstract map

Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/LazyReplicatedMap.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/ReplicatedMap.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java?rev=386815&r1=386814&r2=386815&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 Fri Mar 17 22:37:07 2006
@@ -65,6 +65,8 @@
 private transient boolean stateTransferred = false;
 private transient Object stateMutex = new Object();
 private transient ArrayList mapMembers = new ArrayList();
+
+private transient int channelSendOptions = Channel.SEND_OPTIONS_DEFAULT;
 
 
//--
 //  CONSTRUCTORS
@@ -78,10 +80,15 @@
  * @param initialCapacity int - the size of this map, see HashMap
  * @param loadFactor float - load factor, see HashMap
  */
-public AbstractReplicatedMap(Channel channel, long timeout, String 
mapContextName, int initialCapacity,
- float loadFactor) {
+public AbstractReplicatedMap(Channel channel, 
+ long timeout, 
+ String mapContextName, 
+ int initialCapacity,
+ float loadFactor,
+ int channelSendOptions) {
 super(initialCapacity, loadFactor);
-init(channel, mapContextName, timeout);
+init(channel, mapContextName, timeout, channelSendOptions);
+
 }
 
 /**
@@ -91,9 +98,13 @@
  * @param mapContextName String - unique name for this map, to allow 
multiple maps per channel
  * @param initialCapacity int - the size of this map, see HashMap
  */
-public AbstractReplicatedMap(Channel channel, long timeout, String 
mapContextName, int initialCapacity) {
+public AbstractReplicatedMap(Channel channel, 
+ long timeout, 
+ String mapContextName, 
+ int initialCapacity,
+ int channelSendOptions) {
 super(initialCapacity);
-init(channel, mapContextName, timeout);
+init(channel, mapContextName, timeout, channelSendOptions);
 }
 
 /**
@@ -102,18 +113,21 @@
  * @param timeout long - timeout for RPC messags
  * @param mapContextName String - unique name for this map, to allow 
multiple maps per channel
  */
-public AbstractReplicatedMap(Channel channel, long timeout, String 
mapContextName) {
+public AbstractReplicatedMap(Channel channel, 
+ long timeout, 
+ String mapContextName,
+ int channelSendOptions) {
 super();
-init(channel, mapContextName, timeout);
+init(channel, mapContextName, timeout, channelSendOptions);
 }
 
 protected Member[] wrap(Member m) {
 return new Member[] {m};
 }
 
-private void init(Channel channel, String mapContextName, long timeout) {
+private void init(Channel channel, String mapContextName, long timeout, 
int channelSendOptions) {
 final String chset = "ISO-8859-1";
-
+this.channelSendOptions = channelSendOptions;
 this.channel = channel;
 this.rpcTimeout = timeout;
 
@@ -134,7 +148,7 @@
 //send out a map membership message, only wait for the first reply
 MapMessage msg = new MapMessage(this.mapContextName, 
MapMessage.MSG_START,
 false, null, null, null, 
wrap(channel.getLocalMember(false)));
-Response[] resp = rpcChannel.send(channel.getMembers(), msg, 
rpcChannel.FIRST_REPLY, Channel.SEND_OPTIONS_DEFAULT, timeout);
+Response[] resp = rpcChannel.send(channel.getMembers(), msg, 
rpcChannel.FIRST_REPLY, channelSendOptions, timeout);
 for (int i = 0; i < resp.length; i++) {
 messageReceived(resp[i].getMessage(), resp[i].getSource());
 }
@@ -254,7 +268,7 @@
 

svn commit: r386819 - in /tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse: JSSE13SocketFactory.java JSSE14SocketFactory.java JSSESocketFactory.java

[billbarker]

Author: billbarker
Date: Fri Mar 17 23:26:00 2006
New Revision: 386819

URL: http://svn.apache.org/viewcvs?rev=386819&view=rev
Log:
Restoring ability to configure non-default ciphers

Modified:

tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java

tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java

tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java

Modified: 
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java?rev=386819&r1=386818&r2=386819&view=diff
==
--- 
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java
 (original)
+++ 
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java
 Fri Mar 17 23:26:00 2006
@@ -126,7 +126,7 @@
 // Determine which cipher suites to enable
 String requestedCiphers = (String)attributes.get("ciphers");
 enabledCiphers = getEnabledCiphers(requestedCiphers,
- sslProxy.getDefaultCipherSuites());
+ sslProxy.getSupportedCipherSuites());
 
 } catch(Exception e) {
 if( e instanceof IOException )

Modified: 
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java?rev=386819&r1=386818&r2=386819&view=diff
==
--- 
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java
 (original)
+++ 
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java
 Fri Mar 17 23:26:00 2006
@@ -117,7 +117,7 @@
 // Determine which cipher suites to enable
 String requestedCiphers = (String)attributes.get("ciphers");
 enabledCiphers = getEnabledCiphers(requestedCiphers,
-   
sslProxy.getDefaultCipherSuites());
+   
sslProxy.getSupportedCipherSuites());
 
 } catch(Exception e) {
 if( e instanceof IOException )

Modified: 
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java?rev=386819&r1=386818&r2=386819&view=diff
==
--- 
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
 (original)
+++ 
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
 Fri Mar 17 23:26:00 2006
@@ -188,7 +188,7 @@
 vec.copyInto(enabledCiphers);
 }
 } else {
-enabledCiphers = supportedCiphers;
+enabledCiphers = sslProxy.getDefaultCipherSuites();
 }
 
 return enabledCiphers;



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