DO NOT REPLY [Bug 36834] - Wrong message length in body chunks ?

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-09-28 06:35 ---
Request Body messages don't have a 'type' field in the AJP/1.3 protocol.

-- 
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 36834] - Wrong message length in body chunks ?

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
   ||com




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

TC v5.5.12 Breaks v5.5.9 Configuration

[Bob Bronson]

Hi all,

Pardon my post to the dev group. I already posted to the "User" list 
but received no useful response.


I've just tried to "upgrade" from TC v5.5.9 to v5.5.12 and it seems my 
(very simple) configuration is now broken.


The following configuration works beautifully under 5.5.9 -- no 
exceptions, no warnings, just utter perfection.


Here's a description of my configuration (BTW, CATALINA_HOME and 
JAvA_HOME are fine, I'm sure they're not causing the problem).


I have CATALINA_BASE set like this:
  C:\Projects\Configs\

Within this "Configs" directory I have two sub-directories: "conf" and 
"Engine_01" like this:


  C:\Projects\Configs\
  |
  +-conf\
  |  |
  |  +-server.xml
  |  +-web.xml
  |
  +-Engine01\
  |  |
  |  +-localhost\
  |  |  |
  |  |  +-ROOT.xml


Within the "conf" directory I have my "server.xml" and the default 
"web.xml" files. Here is the server.xml contents:



 
   
   
 
   
 



Notice I have named the engine, "Engine_01".

As you can see, in the "Engine_01" directory I have a subdirectory, 
"localhost", which contains a context fragment file named, "ROOT.xml". 
Here is the contents of ROOT.xml:


  


In my "server.xml" you'll notice I have my appBase property set to 
"..\Sites\Test 1". Here is the "Sites" directory structure:


  C:\Projects\Sites\
  |
  +-Test 1\
  |
  +-index.html
  +-WEB-INF\
  |
  +-web.xml
  +-classes\
  +-root\


It's all quite simple, I think. When I run under v5.5.9, this 
configuration works perfectly, as I said.


Using the EXACT SAME configuration, running under v5.5.12, I see this 
WARNING and EXCEPTION when I start TC:


WARNING: A docBase C:\Projects\Sites\Test 1\. inside the host appBase 
has been specified, and will be ignored
Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext 
resourcesStart

SEVERE: Error starting static Resources
java.lang.IllegalArgumentException: Document base 
C:\Projects\Configs\..\Sites\Test 1\ROOT does not exist or is not a 
readable directory
   at 
org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:140)
   at 
org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:3777)
   at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3948)
   at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
   at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
   at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
   at 
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:603)
   at 
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:535)
   at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470)
   at 
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1118)
   at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
   at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
   at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1020)
   at 
org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
   at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
   at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
   at 
org.apache.catalina.core.StandardService.start(StandardService.java:450)
   at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:680)
   at 
org.apache.catalina.startup.Catalina.start(Catalina.java:536)

   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown 
Source)

   at java.lang.reflect.Method.invoke(Unknown Source)
   at 
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)
   at 
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext start
SEVERE: Error in resourceStart()
Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext start
SEVERE: Error getConfigured
Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [] startup failed due to previous errors
Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext stop
INFO: Container 
org.apache.catalina.core.ContainerBase.[ENGINE_01].[localhost].[/] has 
not been started
Sep 26, 2005 8:37:23 PM org.apache.coyote.http11.Http11BaseProtocol 
start

INFO: Starting Coyote HTTP/1.1 on http-80
Sep 26, 2005 8:37:23 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 796 ms


So, you can see I have one WARNING and one EXCEPTION. Neither of these 
are present under v5.5.9. What's changed? Is 5.5.12 bro

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java

[jfarcand]

jfarcand2005/09/27 16:42:53

  Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
  Log:
  Port fix from SJSAS.
  
  Patch submitted by: Jan Luehe
  
  Revision  ChangesPath
  1.51  +16 -3 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
  
  Index: WebappClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
  retrieving revision 1.50
  retrieving revision 1.51
  diff -u -r1.50 -r1.51
  --- WebappClassLoader.java8 Sep 2005 15:00:54 -   1.50
  +++ WebappClassLoader.java27 Sep 2005 23:42:53 -  1.51
  @@ -1470,6 +1470,21 @@
*/
   public void stop() throws LifecycleException {
   
  +/*
  + * Clear the IntrospectionUtils cache.
  + *
  + * Implementation note:
  + * Any reference to IntrospectionUtils which may cause the static
  + * initalizer of that class to be invoked must occur prior to setting
  + * the started flag to FALSE, because the static initializer of
  + * IntrospectionUtils makes a call to
  + * org.apache.commons.logging.LogFactory.getLog(), which ultimately
  + * calls the loadClass() method of the thread context classloader,
  + * which is the same as this classloader, whose impl throws a
  + * ThreadDeath if the started flag has been set to FALSE.
  + */
  +IntrospectionUtils.clear();
  +
   started = false;
   
   int length = files.length;
  @@ -1515,8 +1530,6 @@
   org.apache.commons.logging.LogFactory.release(this);
   // Clear the classloader reference in the VM's bean introspector
   java.beans.Introspector.flushCaches();
  -// Clear the IntrospectionUtils cache
  -IntrospectionUtils.clear();
   
   }
   
  
  
  

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

DO NOT REPLY [Bug 36834] New: - Wrong message length in body chunks ?

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

   Summary: Wrong message length in body chunks ?
   Product: Tomcat 5
   Version: Unknown
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


jk_ajp13.h uses (line 43): AJP13_MAX_SEND_BODY_SZ = DEF_BUFFER_SZ - 6

but the start of the message is

2 header bytes
2 bytes for the message length
1 byte for the message type
2 bytes for the chunk length.

= a total of 7 bytes.  

The buffer usable space should be DEF_BUFFER_SZ - 7, if I'm not wrong

-- 
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: Please verify this is correct: Need multiple virtual directories for isapi_redirector

[Yoav Shapira]

Hi,
Please use tomcat-user@jakarta.apache.org for user support issues.  The
tomcat-dev list is for discussion regarding Tomcat's own internal development. 
Thank you,

Yoav

--- David Thielen <[EMAIL PROTECTED]> wrote:

> Note: I looked and looked and couldn't find this documented.
> 
> Hi;
> 
> I want to make sure this is correct:
> 
> If you want to run Tomcat against multiple websites, not just the default
> website, this is what I have had to do.
> 
> This is on Windows 2003/IIS 6.0.
> 
> I removed isapi_redirector.dll from the default web site ISAPI Filters and
> put it in the parent "Web Sites" ISAPI Filter properties.
> 
> I added a jakarta virtual directory for each website (and I have a lot.).
> 
> Now it appears to work.
> 
> ??? - thanks - dave
> 
> 
> 
> -
> 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]

What is correct for workers.properties.minimal

[David Thielen]

Hi;

 

I'm running Tomcat 5.5 on Windows 2003/IIS 6.0 using isapi_redirect

 

The isapi_redirect.exe installer creates a worker.properties.minimal of:

  worker.list=wlb,jkstatus

  worker.ajp13w.type=ajp13

  worker.ajp13w.host=localhost

  worker.ajp13w.port=8009

  worker.wlb.type=lb

  worker.wlb.balance_workers=ajp13w

  worker.jkstatus.type=status

 

While the docs show one of:

  worker.list=ajp13w

  worker.ajp13w.type=ajp13

  worker.ajp13w.host=localhost

  worker.ajp13w.port=8009

 

First, what use is the load balancing if I have just one server running one
instance of Tomcat? Does it load balance within that one instance?

 

Second, what is jkstatus for?

 

Thanks - dave

 

 

David Thielen

303-499-2544

www.windwardreports.com

 

Please verify this is correct: Need multiple virtual directories for isapi_redirector

[David Thielen]

Note: I looked and looked and couldn't find this documented.

Hi;

I want to make sure this is correct:

If you want to run Tomcat against multiple websites, not just the default
website, this is what I have had to do.

This is on Windows 2003/IIS 6.0.

I removed isapi_redirector.dll from the default web site ISAPI Filters and
put it in the parent "Web Sites" ISAPI Filter properties.

I added a jakarta virtual directory for each website (and I have a lot.).

Now it appears to work.

??? - thanks - dave



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

Re: isapi_redirect expert?

[Tim Whittington]

If it's undocumented behaviour or it's a clear gap in the documentation 
(i.e a doc bug) then it might be appropriate here.

Otherwise, send them through to me and I'll see if I can help.

tim

David Thielen wrote:


Hi;



I understand it is a big no-no to ask user questions on this list. But I
have three questions about isapi_redirect that no one on the user list seems
to know the answer to.



If I can post them here and I get an answer, I would be happy to write up
the solution for posting on the tomcat site as I know others are hitting
these same questions.



??? - Thanks - dave



David Thielen

303-499-2544

www.windwardreports.com




 

isapi_redirect expert?

[David Thielen]

Hi;

 

I understand it is a big no-no to ask user questions on this list. But I
have three questions about isapi_redirect that no one on the user list seems
to know the answer to.

 

If I can post them here and I get an answer, I would be happy to write up
the solution for posting on the tomcat site as I know others are hitting
these same questions.

 

??? - Thanks - dave

 

David Thielen

303-499-2544

www.windwardreports.com

 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardHostValve.java

[jfarcand]

jfarcand2005/09/27 12:20:54

  Modified:catalina/src/share/org/apache/catalina/core
StandardHostValve.java
  Log:
  Minor fix. Use the the class instead of the String.
  
  Revision  ChangesPath
  1.27  +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostValve.java
  
  Index: StandardHostValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostValve.java,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- StandardHostValve.java25 Aug 2005 12:32:30 -  1.26
  +++ StandardHostValve.java27 Sep 2005 19:20:54 -  1.27
  @@ -309,7 +309,7 @@
   return (null);
   Class clazz = exception.getClass();
   String name = clazz.getName();
  -while (!"java.lang.Object".equals(clazz)) {
  +while (!Object.class.equals(clazz)) {
   ErrorPage errorPage = context.findErrorPage(name);
   if (errorPage != null)
   return (errorPage);
  
  
  

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

Re: Problems Parsing Request Paramers

[Rick Knowles]

Yoav Shapira wrote:


Hi,
Could it be the referer URL is too long, causing the query string to be ignored
or dropped?  There's a limit (2048 characters, I think?) on GET requests in
some browsers.  But actually, you're seeing this on the server, so I'm not
sure.  Can you try testing with less parameters or an otherwise shorter query
string?



I've seen this sort of thing too, but I thought it was 255 chars. From
RFC2616 section 3.2.1:

"Note: Servers ought to be cautious about depending on URI lengths above
255 bytes, because some older client or proxy implementations might not
properly support these lengths. "

Not quite set in stone, but a good general hint to avoid long URLs.

Rick

--
Servlet v2.4 container in a single 155KB jar file ? Try Winstone 
(http://winstone.sourceforge.net/)



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

RE: Problems Parsing Request Paramers

[Jeremy Nix]

The original referer variable was a little over 1K chars, so I don't
believe that I'm pushing that limit quite yet.  As for recreating...I
cannot.  I wish I could.  In order for me to cut down the # of
parameters, I'd have to modify the workflow process which could
potentially aggitate our users.  I will try this locally, but I'm almost
certain that my testing will be futile since I've yet to recreate the
scenario.  Any other ideas?  

I did speak with someone over the phone today who contacted me regarding
this post.  It seems as though they have experienced the same problem
with Tomcat 4 and 5.  He seemed to believe it was related to load.  I
know that our website typically operates at roughly 80 users at a time.
At our peak, 200 users.  So, I'm not so sure it is related to load, but
I'm going to do some further investigating in our test environment with
a load tester to see if I can recreate the problem.

___
Jeremy Nix
Senior Application Developer
Southwest Financial Services, LTD.
(513) 621-6699 x1158
www.sfsltd.com



-Original Message-
From: Yoav Shapira [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 27, 2005 2:06 PM
To: Tomcat Developers List
Subject: Re: Problems Parsing Request Paramers


Hi,
Could it be the referer URL is too long, causing the query string to be
ignored or dropped?  There's a limit (2048 characters, I think?) on GET
requests in some browsers.  But actually, you're seeing this on the
server, so I'm not sure.  Can you try testing with less parameters or an
otherwise shorter query string?

Yoav

--- Jeremy Nix <[EMAIL PROTECTED]> wrote:

> First off, I apologize for the cross-post.  I posted this same message
> in the User's mailing list with no replies.   So, my hope is that one
of
> you developers may have some insight into the problem that I'm having.
> 
> Certain users of my website are having issues with respect to 
> submitting a form on a page.  Not all users are experiencing this 
> problem, and I've yet to replicate it myself so it makes the situation

> even more complex. I have an icking suspicion that its related to the 
> user's browser, but I've tested on the same browser version/subversion

> without a glitch. Here's the scenario:
> 1) User goes to page.
> 2) User fills out form.
> 3) User clicks submit.
> 4) JSP page then performs sanity checks against submitted data.  In 
> the event of a failure on the sanity checks, page is redirected back 
> to previous page.
> 
> Simple enough.  Well, users are filling out the form and clicking 
> submit with valid infromation, yet when I parse the parameters out of 
> the request, I'm finding none of the form values from the previous 
> page.  I then decided to investigate further and log out all request 
> information in the event that these sanity checks fail.  The following

> is what I logged out:
> --
> --
> -
> Attributes:
>   "javax.servlet.request.cipher_suite" = ["SSL_RSA_WITH_RC4_128_MD5"]
>   "javax.servlet.request.key_size" = ["128"]
>   "javax.servlet.request.ssl_session" =
> ["433162398579970fee9289baa9ac832b8558dcc409382f62cb67a3499b80"]
> Parameters:
> Cookies:
>  "JSESSIONID" = [FCB31837FFBD2C0D9F986C42B698BADE]
>  "contact_value" = [ABC]
>  "duplicate_type" = [None]
>  "duplicate_time" = []
>  "mortgage" = []
>  "lender_id_label" = []
>  "title_alternative" = []
>  "can_place_orders" = [Y]
>  "flood_default" = [126]
>  "can_cancel_lol" = [N]
>  "contact_label" = []
>  "lender_id_value" = [ABC]
>  "census" = []
>  "loan_no_label" = []
>  "delivery_method" = [Online]
>  "apprasail" = []
>  "delivery_address" = []
>  "title" = []
> Headers:
>   "accept" = ["image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/msword,
> application/vnd.ms-powerpoint, application/x-shockwave-flash, */*"]
>   "referer" =
>
["https://WEBSITE_URL/CreateOrder.jsp?applicant2HomePhone=&streetName=Ma
> in+St&applicant2WorkPhone=&applicantOtherPhone=&ownerEstimate=&applica
> in+nt
> 2WorkPhone2=&revisionOf=&applicantWorkPhoneExtension=&unitType=&preFix
> Di
>
r=E&applicant2OtherPhoneAreaCode=&applicantOtherPhone2=&applicantMname=L
>
&skipstep=none&zip4=&applicant2HomePhoneAreaCode=&applicant2OtherPhone=&
>
applicantLname=Doe&streetNum=&applicantHomePhoneAreaCode=&zip=40845&pass
>
code=Home&orderHeaderGeneralNotes=&applicantHomePhone2=&propertyLoanNumb
>
er=&productTitle=&applicantFname=John&applicant2WorkPhoneExtension=&appl
>
icant2WorkPhoneAreaCode=&applicant2Mname=J&unitNumber=&applicantWorkPhon
>
eAreaCode=&postFixDir=&productAppraisal=&propertyParcelNumber=&applicant
>
WorkPhone2=&applicantOtherPhoneAreaCode=&city=Hulen&applicantHomePhone=&
>
applicantWorkPhone=&applicant2Lname=Jane&applicant2OtherPhone2=&applican
>
t2HomePhone2=&streetType=&state=KY&contactId=10&productMortgagePrep=&pro
> ductFlood=Yes&applicant2Fname=Doe"]
>   "accept-language" = ["en-us"]
>

Re: Problems Parsing Request Paramers

[Yoav Shapira]

Hi,
Could it be the referer URL is too long, causing the query string to be ignored
or dropped?  There's a limit (2048 characters, I think?) on GET requests in
some browsers.  But actually, you're seeing this on the server, so I'm not
sure.  Can you try testing with less parameters or an otherwise shorter query
string?

Yoav

--- Jeremy Nix <[EMAIL PROTECTED]> wrote:

> First off, I apologize for the cross-post.  I posted this same message
> in the User's mailing list with no replies.   So, my hope is that one of
> you developers may have some insight into the problem that I'm having.
> 
> Certain users of my website are having issues with respect to submitting
> a form on a page.  Not all users are experiencing this problem, and I've
> yet to replicate it myself so it makes the situation even more complex.
> I have an icking suspicion that its related to the user's browser, but
> I've tested on the same browser version/subversion without a glitch.
> Here's the scenario:
> 1) User goes to page.
> 2) User fills out form.
> 3) User clicks submit.
> 4) JSP page then performs sanity checks against submitted data.  In the
> event of a failure on the sanity checks, page is redirected back to
> previous page.
> 
> Simple enough.  Well, users are filling out the form and clicking submit
> with valid infromation, yet when I parse the parameters out of the
> request, I'm finding none of the form values from the previous page.  I
> then decided to investigate further and log out all request information
> in the event that these sanity checks fail.  The following is what I
> logged out:
> 
> -
> Attributes:
>   "javax.servlet.request.cipher_suite" = ["SSL_RSA_WITH_RC4_128_MD5"]
>   "javax.servlet.request.key_size" = ["128"]
>   "javax.servlet.request.ssl_session" =
> ["433162398579970fee9289baa9ac832b8558dcc409382f62cb67a3499b80"]
> Parameters:
> Cookies:
>  "JSESSIONID" = [FCB31837FFBD2C0D9F986C42B698BADE]
>  "contact_value" = [ABC]
>  "duplicate_type" = [None]
>  "duplicate_time" = []
>  "mortgage" = []
>  "lender_id_label" = []
>  "title_alternative" = []
>  "can_place_orders" = [Y]
>  "flood_default" = [126]
>  "can_cancel_lol" = [N]
>  "contact_label" = []
>  "lender_id_value" = [ABC]
>  "census" = []
>  "loan_no_label" = []
>  "delivery_method" = [Online]
>  "apprasail" = []
>  "delivery_address" = []
>  "title" = []
> Headers:
>   "accept" = ["image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/msword,
> application/vnd.ms-powerpoint, application/x-shockwave-flash, */*"]
>   "referer" =
> ["https://WEBSITE_URL/CreateOrder.jsp?applicant2HomePhone=&streetName=Ma
> in+St&applicant2WorkPhone=&applicantOtherPhone=&ownerEstimate=&applicant
> 2WorkPhone2=&revisionOf=&applicantWorkPhoneExtension=&unitType=&preFixDi
> r=E&applicant2OtherPhoneAreaCode=&applicantOtherPhone2=&applicantMname=L
> &skipstep=none&zip4=&applicant2HomePhoneAreaCode=&applicant2OtherPhone=&
> applicantLname=Doe&streetNum=&applicantHomePhoneAreaCode=&zip=40845&pass
> code=Home&orderHeaderGeneralNotes=&applicantHomePhone2=&propertyLoanNumb
> er=&productTitle=&applicantFname=John&applicant2WorkPhoneExtension=&appl
> icant2WorkPhoneAreaCode=&applicant2Mname=J&unitNumber=&applicantWorkPhon
> eAreaCode=&postFixDir=&productAppraisal=&propertyParcelNumber=&applicant
> WorkPhone2=&applicantOtherPhoneAreaCode=&city=Hulen&applicantHomePhone=&
> applicantWorkPhone=&applicant2Lname=Jane&applicant2OtherPhone2=&applican
> t2HomePhone2=&streetType=&state=KY&contactId=10&productMortgagePrep=&pro
> ductFlood=Yes&applicant2Fname=Doe"]
>   "accept-language" = ["en-us"]
>   "content-type" = ["application/x-www-form-urlencoded"]
>   "accept-encoding" = ["gzip, deflate"]
>   "user-agent" = ["Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
> .NET CLR 1.1.4322)"]
>   "host" = ["WEBSITE_DOMAIN"]
>   "connection" = ["Keep-Alive"]
>   "cache-control" = ["no-cache"]
>   "cookie" = ["JSESSIONID=FCB31837FFBD2C0D9F986C42B698BADE;
> contact_value=ABC; duplicate_type=None; duplicate_time=; mortgage=;
> lender_id_label=; title_alternative=; can_place_orders=Y;
> flood_default=126; can_cancel_lol=N; contact_label=;
> lender_id_value=ABC; census=; can_view_insurance_tracking=N;
> loan_no_label=; delivery_method=Online; apprasail=; delivery_address=;
> title="]
>   "content-length" = ["0"]
> 
> -
> There are many interesting things about this request.  First, the
> content-length is 0.  Not sure how this could happen...error in
> browser??  Second, and the most intriguing...Notice the "referer" entry.
> The referer entry actually contains all relevant information that I
> needed in order to process this request, yet if you look at what
> parameters I was actually able to parse off this request you will
> see...NONE.
> 
> I'm stumped.

Problems Parsing Request Paramers

[Jeremy Nix]

First off, I apologize for the cross-post.  I posted this same message
in the User's mailing list with no replies.   So, my hope is that one of
you developers may have some insight into the problem that I'm having.

Certain users of my website are having issues with respect to submitting
a form on a page.  Not all users are experiencing this problem, and I've
yet to replicate it myself so it makes the situation even more complex.
I have an icking suspicion that its related to the user's browser, but
I've tested on the same browser version/subversion without a glitch.
Here's the scenario:
1) User goes to page.
2) User fills out form.
3) User clicks submit.
4) JSP page then performs sanity checks against submitted data.  In the
event of a failure on the sanity checks, page is redirected back to
previous page.

Simple enough.  Well, users are filling out the form and clicking submit
with valid infromation, yet when I parse the parameters out of the
request, I'm finding none of the form values from the previous page.  I
then decided to investigate further and log out all request information
in the event that these sanity checks fail.  The following is what I
logged out:

-
Attributes:
  "javax.servlet.request.cipher_suite" = ["SSL_RSA_WITH_RC4_128_MD5"]
  "javax.servlet.request.key_size" = ["128"]
  "javax.servlet.request.ssl_session" =
["433162398579970fee9289baa9ac832b8558dcc409382f62cb67a3499b80"]
Parameters:
Cookies:
 "JSESSIONID" = [FCB31837FFBD2C0D9F986C42B698BADE]
 "contact_value" = [ABC]
 "duplicate_type" = [None]
 "duplicate_time" = []
 "mortgage" = []
 "lender_id_label" = []
 "title_alternative" = []
 "can_place_orders" = [Y]
 "flood_default" = [126]
 "can_cancel_lol" = [N]
 "contact_label" = []
 "lender_id_value" = [ABC]
 "census" = []
 "loan_no_label" = []
 "delivery_method" = [Online]
 "apprasail" = []
 "delivery_address" = []
 "title" = []
Headers:
  "accept" = ["image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword,
application/vnd.ms-powerpoint, application/x-shockwave-flash, */*"]
  "referer" =
["https://WEBSITE_URL/CreateOrder.jsp?applicant2HomePhone=&streetName=Ma
in+St&applicant2WorkPhone=&applicantOtherPhone=&ownerEstimate=&applicant
2WorkPhone2=&revisionOf=&applicantWorkPhoneExtension=&unitType=&preFixDi
r=E&applicant2OtherPhoneAreaCode=&applicantOtherPhone2=&applicantMname=L
&skipstep=none&zip4=&applicant2HomePhoneAreaCode=&applicant2OtherPhone=&
applicantLname=Doe&streetNum=&applicantHomePhoneAreaCode=&zip=40845&pass
code=Home&orderHeaderGeneralNotes=&applicantHomePhone2=&propertyLoanNumb
er=&productTitle=&applicantFname=John&applicant2WorkPhoneExtension=&appl
icant2WorkPhoneAreaCode=&applicant2Mname=J&unitNumber=&applicantWorkPhon
eAreaCode=&postFixDir=&productAppraisal=&propertyParcelNumber=&applicant
WorkPhone2=&applicantOtherPhoneAreaCode=&city=Hulen&applicantHomePhone=&
applicantWorkPhone=&applicant2Lname=Jane&applicant2OtherPhone2=&applican
t2HomePhone2=&streetType=&state=KY&contactId=10&productMortgagePrep=&pro
ductFlood=Yes&applicant2Fname=Doe"]
  "accept-language" = ["en-us"]
  "content-type" = ["application/x-www-form-urlencoded"]
  "accept-encoding" = ["gzip, deflate"]
  "user-agent" = ["Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
.NET CLR 1.1.4322)"]
  "host" = ["WEBSITE_DOMAIN"]
  "connection" = ["Keep-Alive"]
  "cache-control" = ["no-cache"]
  "cookie" = ["JSESSIONID=FCB31837FFBD2C0D9F986C42B698BADE;
contact_value=ABC; duplicate_type=None; duplicate_time=; mortgage=;
lender_id_label=; title_alternative=; can_place_orders=Y;
flood_default=126; can_cancel_lol=N; contact_label=;
lender_id_value=ABC; census=; can_view_insurance_tracking=N;
loan_no_label=; delivery_method=Online; apprasail=; delivery_address=;
title="]
  "content-length" = ["0"]

-
There are many interesting things about this request.  First, the
content-length is 0.  Not sure how this could happen...error in
browser??  Second, and the most intriguing...Notice the "referer" entry.
The referer entry actually contains all relevant information that I
needed in order to process this request, yet if you look at what
parameters I was actually able to parse off this request you will
see...NONE.

I'm stumped.  Anybody else seen this before?

Environment:
JDK 1.4.2_08
Tomcat 5.5.9

___
Jeremy Nix
Senior Application Developer
Southwest Financial Services, LTD.
(513) 621-6699 x1158
www.sfsltd.com

Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.

[Remy Gendron]

Hi all,

Here's the situation as it stands today and what can be done to solve
it. I'll try to keep this short.

Running configuration:

*   Running on Linux Red-Hat Ent 3
*   1 X F5 load balancer and hardware SSL box.
*   5 X Apache 1.3.33/mod_jk 1.2.14
*   6 X JBoss 4.0.0/Tomcat 5.0.28 using the AJP13 connector. 
*   Oracle 9i


Our production environment hosts a number of applications, each with
different load and usage patterns. Our problem comes from the fact that
it is difficult to find a web farm configuration that will satisfy every
application. For reasons I will not explain here, we cannot have a
dedicated web farm for each application.

This is what we think is happening in our production environment based
on tests ran in UAT (User Acceptance Tests) and literature from the
Apache and Tomcat products. This is all pretty new to us so if someone
can provide hard facts, you are more than welcome.

1.  The 1.3 generation of Apache web servers will spawn a child
process to handle an HTTP request. Only one HTTP request at a time can
be processed by that child. 
2.  As the load increases on the web server, additional child
processes will be spawned to concurrently serve the requests. There is a
default limit to how many child processes can be forked. That limit
defaults to 256 but has been changed in production to 16384. This is the
MaxClients directive. It seems that production really needs the 16384
value instead of the 256 default. With 256, our web servers were
rejecting connections and could not support the load generated by all of
our clients.
3.  To prevent latency, Apache will maintain a maximum of 100 spare
child processes alive. Spare means that they are not serving requests.
Once reached, that number of spare servers does not seem to decrease.
This is the number we see in our tests in UAT where 201 threads remain
active in Tomcat. This is the 100 spare children connections * 2 web
server plus accept() thread. 
4.  If a request needs to be forwarded to Tomcat/JBoss (dynamic
pages), the child process mod_jk module will instantiate a socket
connection to the ajp13 connector in Tomcat. 
5.  Tomcat will accept the connection and create a thread to serve
it. Connections will be accepted up to a concurrent maximum of 1200.
This upper value has been set by us. 
6.  Tomcat will reject connections when the maximum is reached.
JBoss 4.0.0 has a known issue where the server will die when the maximum
is reached. This has been fixed in 4.0.2. 
7.  A connection could potentially be recycled in mod_jk
(recycle_timeout) if no activity occurs thru the connection. However,
any requests to Tomcat from any user session-bound to that Tomcat
instance could go thru the connection, thus keeping it active. Recycling
does not seem to occur. We use a recycle_timeout value of 300.
8.  The fact that the production web servers can potentially serve
up to 16384 concurrent requests make it possible for a web server to
instantiate an almost infinite number of connections to Tomcat and nuke
it. 
9.  Tomcat can then become overloaded with connections. If a valid
HTTP request comes thru Apache and is routed to a child process that has
not yet made a connection to Tomcat, the connection could be impossible
if Tomcat has already accepted its 1200 limit. 
10. In that case, mod_jk could potentially fail over to another
Tomcat. The user would however loose his session.
11. The recycle_timeout and  cache_size options are of no use to us
because too many web server children are created to serve the company
load. Thus, many different routes can be taken by requests targeted to
our application, keeping all the connection alive.
12. We tried really small recycle_timeout values (e.g. 20) with no
effect. A netstat reveals that connections remain ESTABLISHED. 
13. The maxRequestsPerChild setting is set to 0 in PROD. It means
that Apache child processes will never die, unless you reach the
maxSpareServers value. Thus, at least 100 connections per web server
will always remain actively connected to Tomcat. A > 0 value would at
least guarantee that a child process would eventually die, freeing
Tomcat connections and releasing back leaked memory to the OS. 

It's hard to see a path out of this one. One solution would be to reduce
the MaxClients Apache config back to 256. This would mean that a single
instance of Tomcat would not be hit by more than 256 * 5 = 1280 (5 is
the web farm size) connections. Our current jvm settings (heap + thread
stack sizes) would allow us to do it. We would also need to bump our
current 1200 limit a bit higher. However, this solution if not
compatible with other applications which have really high loads.

Second option would be to patch mod_jk so that connections are dropped
as soon as the response has been received from Tomcat. Drawbacks include
preventing us from upgrading to new releases (unless we re-apply the
modifications), introduce the ri

DO NOT REPLY [Bug 36827] - Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.

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





--- Additional Comments From [EMAIL PROTECTED]  2005-09-27 16:59 ---
Please witch over to tomcat-user for discussion. This is not a bug.

First hints from my side: reduce to equal number of apache and tomcat instances,
configure F5 with rule that sends URLs with session cookie or jsessionid in URL
to the "correct" apache. Furthermore configure mod_jk, such that each apache
sends requests without sessions to it's preferred tomcat partner.

That way almost all apache processes will connect to only one tomcat.

If you still need 16K apache processes per instance you are in trouble (maybe
upgrade to apache 2), if you manage to handle the workload with 1K apache
processes, 1K Threads in Tomcat should be 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 36827] New: - Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.

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

   Summary: Need an option to severe socket connections between
mod_jk and ajp connector after request/response cycle.
   Product: Tomcat 5
   Version: 5.0.28
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Here’s the situation as it stands today and what can be done to solve it. I’ll 
try to keep this short.

Running configuration:

•   Running on Linux Red-Hat Ent 3
•   1 X F5 load balancer and hardware SSL box.
•   5 X Apache 1.3.33/mod_jk 1.2.14
•   6 X JBoss 4.0.0/Tomcat 5.0.28 using the AJP13 connector. 
•   Oracle 9i

Our production environment hosts a number of applications, each with different 
load and usage patterns. Our problem comes from the fact that it is difficult 
to find a web farm configuration that will satisfy every application. For 
reasons I will not explain here, we cannot have a dedicated web farm for each 
application.

This is what we think is happening in our production environment based on 
tests ran in UAT (User Acceptance Tests) and literature from the Apache and 
Tomcat products. This is all pretty new to us so if someone can provide hard 
facts, you are more than welcome.

1.  The 1.3 generation of Apache web servers will spawn a child process to 
handle an HTTP request. Only one HTTP request at a time can be processed by 
that child. 
2.  As the load increases on the web server, additional child processes 
will be spawned to concurrently serve the requests. There is a default limit 
to how many child processes can be forked. That limit defaults to 256 but has 
been changed in production to 16384. This is the MaxClients directive. It 
seems that production really needs the 16384 value instead of the 256 default. 
With 256, our web servers were rejecting connections and could not support the 
load generated by all of our clients.
3.  To prevent latency, Apache will maintain a maximum of 100 spare child 
processes alive. Spare means that they are not serving requests. Once reached, 
that number of spare servers does not seem to decrease. This is the number we 
see in our tests in UAT where 201 threads remain active in Tomcat. This is the 
100 spare children connections * 2 web server plus accept() thread. 
4.  If a request needs to be forwarded to Tomcat/JBoss (dynamic pages), 
the child process mod_jk module will instantiate a socket connection to the 
ajp13 connector in Tomcat. 
5.  Tomcat will accept the connection and create a thread to serve it. 
Connections will be accepted up to a concurrent maximum of 1200. This upper 
value has been set by us. 
6.  Tomcat will reject connections when the maximum is reached. JBoss 
4.0.0 has a known issue where the server will die when the maximum is reached. 
This has been fixed in 4.0.2. 
7.  A connection could potentially be recycled in mod_jk (recycle_timeout) 
if no activity occurs thru the connection. However, any requests to Tomcat 
from any user session-bound to that Tomcat instance could go thru the 
connection, thus keeping it active. Recycling does not seem to occur. We use a 
recycle_timeout value of 300.
8.  The fact that the production web servers can potentially serve up to 
16384 concurrent requests make it possible for a web server to instantiate an 
almost infinite number of connections to Tomcat and nuke it. 
9.  Tomcat can then become overloaded with connections. If a valid HTTP 
request comes thru Apache and is routed to a child process that has not yet 
made a connection to Tomcat, the connection could be impossible if Tomcat has 
already accepted its 1200 limit. 
10. In that case, mod_jk could potentially fail over to another Tomcat. 
The user would however loose his session.
11. The recycle_timeout and  cache_size options are of no use to us 
because too many web server children are created to serve the company load. 
Thus, many different routes can be taken by requests targeted to our 
application, keeping all the connection alive.
12. We tried really small recycle_timeout values (e.g. 20) with no effect. 
A netstat reveals that connections remain ESTABLISHED. 
13. The maxRequestsPerChild setting is set to 0 in PROD. It means that 
Apache child processes will never die, unless you reach the maxSpareServers 
value. Thus, at least 100 connections per web server will always remain 
actively connected to Tomcat. A > 0 value would at least guarantee that a 
child process would eventually die, freeing 

DO NOT REPLY [Bug 36814] - Parameter for POST encoding

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





--- Additional Comments From [EMAIL PROTECTED]  2005-09-27 15:45 ---
I also have the filter mapping like this:

 
Set Character Encoding
action
  

but it does not work.

In the config file in the  I have this valve included:



In the comment it says, that all request accesses are logged. Maybe this one
sets the character encoding already to the wrong value? I mean not directly the
valve but Tomcat when the request is accessed.




-- 
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 36814] - Parameter for POST encoding

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





--- Additional Comments From [EMAIL PROTECTED]  2005-09-27 15:25 ---
don't forget to add a filter mapping, this is ours, you may need a URL pattern 
match.


requestCharacterEncodingFilter
springFrontController




-- 
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 36814] - Parameter for POST encoding

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





--- Additional Comments From [EMAIL PROTECTED]  2005-09-27 15:21 ---
Maybe I am too silly to do it, but for my test case it does not work setting the
encoding with a filter. I did this:

in the web.xml as the first filter in the list:

 
Set Character Encoding
package.SetCharacterEncodingFilter

  encoding
  UTF-8

  

This is the filter which is packaged as example with Tomcat.

If I do now a post with UTF-8 characters all submitted UTF-8 characters are
corrupted. 

What am I doing wrong?


There is also a problem with valves. If you read a parameter from the request
inside a valve then the character encoding is automatically set to the default
(spec) value which is ISO-8859-1. Later you can not change this in a filter 
anymore.

(If I use my patch instead, everything is fine, no matter where I try to read
parameters from the request.)

With regards,
Udo

-- 
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 36814] - Parameter for POST encoding

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





--- Additional Comments From [EMAIL PROTECTED]  2005-09-27 13:32 ---
it always comes down to what the servlet specification says a container 
implementation should do, what developers expect container implementations to 
do and how they should behave, and what developers often get confused about.

character encoding seems to be one of those things that many developers are 
getting confused about, and this issue in particular seems to come about quite 
often. i suppose as far as a developer is concerned whatever data they send to 
the server should be maintained in that way. so if arabic is sent via a post 
running on tomcat, is it acceptable for the developer to have to understand 
that tomcat runs in a charset that is not universal and to have to seek a 
filter or write their own filter to change this?

personally, i believe encoding falls into the same kind of category as other 
configuration elements like databases, jndi environment vars.

imo the container should help out the developer with this type of 
functionality, if not by configuration, then by providing default configurable 
filters across web applications. 

just my opinion.

-- 
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: JK 1.2.15 Release plan?

[Rainer Jung]

I encourage you for voting 1.2.15 as stable.

Mladen Turk wrote:

> Anyhow, I would like that we vote this (1.2.15) version as stable,
> because it's a bug-fix release over the 1.2.14 stable.


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

DO NOT REPLY [Bug 36823] - Ant task Description file catalina.tasks shouldn't have JspC

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-09-27 10:08 ---
This will not be addressed.

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