DO NOT REPLY [Bug 23691] New: - Incorrect custom tag SMAPping

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://nagoya.apache.org/bugzilla/show_bu

tomcat status

Hi all, I'm looking for a command for query the Tomcat port. I want to determine if the Tomcat processes are frozen or locked up. It would be nice to find a method for probing port 8007 to test if the java servlet container and servlets are still operating correctly. I would appreciate any help

[PATCH] jakarta-servletapi-5: XML schema fix

Attached is a patch to the TLD schema to remove a superfluous definition for the xml prefix. jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd - Removed superfluous xml namespace --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. Index: jsr152/src/share/dtd/web-jsp

DO NOT REPLY [Bug 23267] - Manger remove of context deployed as defult webapp gets NPE

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://nagoya.apache.org/bugzilla/show_bu

Re: [5] IndexOutOfBoundsException from CharChunk

> Date: Wed, 08 Oct 2003 21:22:07 +0200 > From: Remy Maucherat <[EMAIL PROTECTED]> > Subject: Re: [5] IndexOutOfBoundsException from CharChunk > To: Tomcat Developers List <[EMAIL PROTECTED]> > > Kin-Man Chung wrote: > > > I am getting a sporadic IndexOutOfBoundsException and it seems to come fr

Re: [5] IndexOutOfBoundsException from CharChunk

Kin-Man Chung wrote: I am getting a sporadic IndexOutOfBoundsException and it seems to come from org.apache.tomcat.util.buf.CharChunk.flushBuffer. The trace is Servlet.service() for servlet jsp threw exception java.lang.IndexOutOfBoundsException at sun.nio.cs.StreamEncoder.write(StreamEnc

[5] IndexOutOfBoundsException from CharChunk

I am getting a sporadic IndexOutOfBoundsException and it seems to come from org.apache.tomcat.util.buf.CharChunk.flushBuffer. The trace is Servlet.service() for servlet jsp threw exception java.lang.IndexOutOfBoundsException at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:132)

DO NOT REPLY [Bug 19005] - Add "setIsPoolingEnabled()" method to org.apache.jasper.JspC

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://nagoya.apache.org/bugzilla/show_bu

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspCompilationContext.java

kinman 2003/10/08 10:39:15 Modified:jasper2/src/share/org/apache/jasper JspCompilationContext.java Log: - Serialize directory creating to avoid a potential race condition. Revision ChangesPath 1.43 +21 -19 jakarta-tomcat-jasper/jasper2/sr

DO NOT REPLY [Bug 23675] New: - Ajp13Connector contains code that works only on JDK1.3+

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://nagoya.apache.org/bugzilla/show_bu

RE: Order of parameters

The best idea so far! Another time when the HttpServletRequestWrapper is gonna help out. Martin > -Original Message- > From: Chad Johnson [mailto:[EMAIL PROTECTED] > Sent: woensdag 8 oktober 2003 16:43 > To: Tomcat Developers List > Subject: RE: Order of parameters > > > Heh, well ofco

Re: [5] Unable to initialize TldLocationsCache: zip file closed

I was testing on 1.3. (Just an old 1.3) I meant to say I should attempt to upgrade to a newer 1.3 JVM. I think I can have a test box with 1.4 late next week if I sweet talk the right people. For this particular config, I haven't tried running tomcat 4.1 on it. It might be interesting to try. S

Re: [5] Unable to initialize TldLocationsCache: zip file closed

Tim Funk wrote: No luck. I have had trouble in the past with HP JVMs and this is an old JVM. No errors are output when the webapp is loaded. Just when the first JSP tries to get compiled. As a sanity check, I removed the precompile mappings for the JSP examples and most examples worked fine. B

RE: Order of parameters

Heh, well ofcourse this could also be implemented as a servlet filter! Overriding these methods of the request object: -getParameter -getParameterMap -getParameterNames -getParameterValues Chad Johnson -Original Message- From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED] Sent: Wedn

RE: Order of parameters

Just add a number to the name of your form fields, and parse them in the servlet e.g. 01_name 02_address A more elegant solution (requires more coding) would be to name your fields like -Original Message- > From: Martin van Dijken [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 08. Ok

RE: Order of parameters

On Wed, 8 Oct 2003, Chad Johnson wrote: > A solution that could work: > Directly get the query string with "request.getQueryString()" parse > the results yourself and store the results in the order found. Come on - you folks are java guys - wrap something around it :-0 Dw --

Re: Order of parameters

The problem lies in the servlet spec. It does not dictate that request.getParameterNames() returns the parameter list in any specific order. A feature request to the spec working group is your best bet. If your using GET - you always have access to the query string and a "simple regex" can retu

RE: Order of parameters

IMO: -Across the board browsers are not obligated to behave like this -Any servlet that depended on this behavior would be locked into TC A solution that could work: Directly get the query string with "request.getQueryString()" parse the results yourself and store the results in the order f

RE: Order of parameters

> The solution is to pass a fields list as an additional > paramter, and use > that field list to drive the ordering of your form. That is of course possible, but requires more code in the form, which is in my opinion totally unnecessary. ASP, and I think PHP as well, have this as one of their m

RE: Order of parameters

The solution is to pass a fields list as an additional paramter, and use that field list to drive the ordering of your form. -Original Message- From: Martin van Dijken [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 4:16 AM To: Tomcat Developers List Subject: RE: Order of para

Re: [Fwd: Re: /www/www.apache.org/dyn/mirrors/mirrors.cgi]

From: "jean-frederic clere" <[EMAIL PROTECTED]> > Tetsuya Kitahata wrote: > > On Tue, 07 Oct 2003 13:49:39 +0200 > > Remy Maucherat <[EMAIL PROTECTED]> wrote: > > > > > >>There is no guarantee that the binaries d/led are not corrupted on your > >>random mirror, or haven't been tampered with, or if

Re: [Fwd: Re: /www/www.apache.org/dyn/mirrors/mirrors.cgi]

Tetsuya Kitahata wrote: On Tue, 07 Oct 2003 13:49:39 +0200 Remy Maucherat <[EMAIL PROTECTED]> wrote: There is no guarantee that the binaries d/led are not corrupted on your random mirror, or haven't been tampered with, or if the mirror is available at all. This is for the build process, so mir

Re: [5] Unable to initialize TldLocationsCache: zip file closed

No luck. I have had trouble in the past with HP JVMs and this is an old JVM. No errors are output when the webapp is loaded. Just when the first JSP tries to get compiled. As a sanity check, I removed the precompile mappings for the JSP examples and most examples worked fine. But then one of th

RE: Order of parameters

> MOST browsers; certainly not all. 100% true > If you are requiring order it may makes the most sense to NOT > trust the wire - but do the ordering yourself on entry as described. Well, the reason I'm proposing this is I'm modifying a form handler which simply mails all fields encountered to

Re: Order of parameters

On Wed, 8 Oct 2003, Martin van Dijken wrote: > I've been trying to create an automated form handler. This form handler > could be a lot more effective if the request parameters were in the > order they were put on the form. Now most browsers send this information MOST browsers; certainly not al

Order of parameters

I've been trying to create an automated form handler. This form handler could be a lot more effective if the request parameters were in the order they were put on the form. Now most browsers send this information over HTTP in the order they were found in the form. However, because the parameters

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3 CoyoteInterceptor2.java

hgomez 2003/10/08 01:48:32 Modified:coyote/src/java/org/apache/coyote/tomcat3 CoyoteInterceptor2.java Log: Comment gzip/http 1.1 tuning for Coyote 2 (now it's using HEAD) Revision ChangesPath 1.17 +16 -1 jakarta-tomcat-connectors/coyote/