Re: questions on AJPv13 protocol, for a non-C,non-java container implementation
I'm working on implementing support for AJP/1.3 in IMHO (more info:
footnote [1]), to get a Lisp process to communicate with an Apache
server via mod_jk or mod_jk2
He he ;)
(Currently, IMHO can use its own copy of mod_webapp for this, at least
with Apache 1.3; the mod_webapp from Tomcat, with apache2, doesn't
seem to want to work with IMHO as it is, though, and so I found my way
around to mod_jk/mod_jk2.)
yes, mod_webapp is no more supported.
As a side note: The docs at
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13.html
[AJPv13.html]
have been very helpful for this.
Now, to the point: I have some questions, wanting to get the AJP/1.3
protocol-implemnetation right, in the Lisp code for it.
- in AJPv13.html, there's a mention of an 'integer' type
How wide is an integer expected to be in AJPv13 ?
2 bytes, MSB code (0x1234 will appears [0x12] [0x34]
- in that same doc [AJPv13.html], there's mention of a 'string' type,
used in some spots where there's no extra information to indicate
the length of the string (e.g.: in header-name/header-value pairs)
an int (2 bytes) containing len, then the string itself (à la Pascal)
including the final 0x00.
Should I assume that each not-otherwise-length-tagged string
(e.g.: a misc. header name) ends on a null byte?
- in regards to the the AJP13 extensions (esp. conenctor-mod_jk{2}
authentication) mentioned at
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13-extensions-proposal.html
...would anyone happen to know the 'status' on those extensions,
i.e. whether they're being used in mod_jk and/or mod_jk2?
- is there any official documentation about AJPv14? I've seen this
revision of the protocol mentioned, in some places.
Well Ajp14 or Ajp13++ has beean coded but hidden. It add features like
secure connections but I didn't check if it works in TC 4.1.x and 5.0.x ;)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP13 in TC 3.3.2-dev
Bill Barker a écrit : - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 1:42 AM Subject: AJP13 in TC 3.3.2-dev Did we still use in TC 3.3.2-dev the Ajp13 code in org.apache.tomcat.modules.server or the one in JTC ? I only ever use the j-t-c Coyote connectors personally. I don't recall that there has been an official decision, but I'd be +1 to deprecating o.a.t.m.server. +1 to depreciate or even better to remove it from TC 3.3.2 dev. Also I'd like to see Coyote/HTTP 1.1 connector used in TC 3.3.2 by default ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk does not detect a hung Tomcat
Henri Gomez said: This won't work with the pre-fork MPM, since each Apache child will have its own idea of the timing. The only way that it could tell that a Tomcat failed is to try the request and fail :). The idea needs to be flushed out some more. But we should be able to track enough data about how a worker is performing to make some simple Well the code is ready, native (jk), java (tc 3.3 + jtc) and I've updated documentations. Added PING/PONG support in ajp13, and make use of select() to determine if there is something to read. I attached a copy of jk_ajp_common.c for review but I'd like to commit the code before HEAD diverge. Since the new functionnalities are off by default it shouldn't hurt ;) You work fast, Henri. ;-) If you want, I can test it out tomorrow. If you can give me patches for Tomcat 4.1.27 and mod_jk, I'll see if I can get it compiled and run some quick tests. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk does not detect a hung Tomcat
Bill Barker a écrit : BTW, select() call is supported by WIN32 ? Strangely enough, it seems that select(int, fd_set *, fd_set *, fd_set *, const timeval *) is actually supported by MS. However, it seems that you need to use MS's weird error codes to handle errors. Ok I'll take a look in APR which is the definitive guide for OS portability. Which make me think that we should discuss one day of the use of APR in jk/jk2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23381] - Syntax error compiling mod_jk for apache 1.3.x on FreeBSD
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23381. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23381 Syntax error compiling mod_jk for apache 1.3.x on FreeBSD [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 07:23 --- No such code in current cvs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk does not detect a hung Tomcat
David Rees a écrit : Henri Gomez said: This won't work with the pre-fork MPM, since each Apache child will have its own idea of the timing. The only way that it could tell that a Tomcat failed is to try the request and fail :). The idea needs to be flushed out some more. But we should be able to track enough data about how a worker is performing to make some simple Well the code is ready, native (jk), java (tc 3.3 + jtc) and I've updated documentations. Added PING/PONG support in ajp13, and make use of select() to determine if there is something to read. I attached a copy of jk_ajp_common.c for review but I'd like to commit the code before HEAD diverge. Since the new functionnalities are off by default it shouldn't hurt ;) You work fast, Henri. ;-) The blocking read() need to be fixed for years :) If you want, I can test it out tomorrow. If you can give me patches for Tomcat 4.1.27 and mod_jk, I'll see if I can get it compiled and run some quick tests. If nobody object I'll commit it today, just wait jtc commiters to give a confirmation since jk 1.2.5 should be released before. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jk 1.2.5 release : Was: mod_jk does not detect a hung Tomcat
Did the jk 1.2.5 has been tagged so I could commit my modifications for PING/PONG in jtc ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: questions on AJPv13 protocol, for a non-C,non-java container implementation
wonderful! thanks -- sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19778] - utf-8-encoded source gets mangled in xml-mode
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19778.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19778
utf-8-encoded source gets mangled in xml-mode
--- Additional Comments From [EMAIL PROTECTED] 2003-09-25 07:39 ---
Yes. You are right!
But have some errors in your patch. You wrote:
--- JspDocumentParser.javaFri May 9 17:17:44 2003
+++ JspDocumentParser-original.javaWed Mar 19 10:20:58 2003
@@ -136,9 +136,9 @@
*/
public static Node.Nodes parse(ParserController pc,
String path,
- InputStream in,
+ InputStreamReader reader,
Node parent) throws JasperException {
-JspDocumentParser handler = new JspDocumentParser(pc, path, in);
+JspDocumentParser handler = new JspDocumentParser(pc, path, reader);
handler.current = parent;
Node.Nodes pageNodes = null;
but it mast be like this:
--- JspDocumentParser.javaFri May 9 17:17:44 2003
+++ JspDocumentParser-original.javaWed Mar 19 10:20:58 2003
@@ -136,9 +136,9 @@
*/
public static Node.Nodes parse(ParserController pc,
String path,
- InputStreamReader reader,
+ InputStream in,
Node parent) throws JasperException {
-JspDocumentParser handler = new JspDocumentParser(pc, path, reader);
+JspDocumentParser handler = new JspDocumentParser(pc, path, in);
handler.current = parent;
Node.Nodes pageNodes = null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23388] - Wrong assumtion on external XML-parser behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23388. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23388 Wrong assumtion on external XML-parser behavior [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 07:41 --- *** This bug has been marked as a duplicate of 19778 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19778] - utf-8-encoded source gets mangled in xml-mode
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19778 utf-8-encoded source gets mangled in xml-mode [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 07:41 --- *** Bug 23388 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk 1.2.5 release : Was: mod_jk does not detect a hung Tomcat
For me, doing a cvs log doesn't mention a 1.2.5 tag. - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 12:25 AM Subject: jk 1.2.5 release : Was: mod_jk does not detect a hung Tomcat Did the jk 1.2.5 has been tagged so I could commit my modifications for PING/PONG in jtc ? - 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]
questions on AJPv13 protocol, for a non-C,non-java container implementation
Hello,
I'm working on implementing support for AJP/1.3 in IMHO (see footnote
[1]), to get a Lisp process to communicate with an Apache server via
mod_jk or mod_jk2
(Currently, IMHO can use its own copy of mod_webapp for this, at least
with Apache 1.3; the mod_webapp from Tomcat, with apache2, doesn't
seem to want to work with IMHO as it is, though, and so I found my way
around to mod_jk/mod_jk2.)
As a side note: The docs at
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13.html
[AJPv13.html]
have been very helpful for this.
Now, to the point: I have some questions, wanting to get the AJP/1.3
protocol-implemnetation right, in the Lisp code for it.
- in AJPv13.html, there's a mention of an 'integer' type
How wide is an integer expected to be in AJPv13 ?
- in that same doc [AJPv13.html], there's mention of a 'string' type,
used in some spots where there's no extra information to indicate
the length of the string (e.g.: in header-name/header-value pairs)
Should I assume that each not-otherwise-length-tagged string
(e.g.: a misc. header name) ends on a null byte?
- in regards to the the AJP13 extensions (esp. conenctor-mod_jk{2}
authentication) mentioned at
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13-extensions-proposal.html
...would anyone happen to know the 'status' on those extensions,
i.e. whether they're being used in mod_jk and/or mod_jk2?
- is there any official documentation about AJPv14? I've seen this
revision of the protocol mentioned, in some places.
Thanks much! and good evening,
--
sean champ
Footnotes:
[1] IMHO is a Common Lisp web-application environment,
avaiable at http://alpha.onshored.com/lisp-software/#imho
It's free software.
More info, too: http://www.cliki.net/IMHO
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23406] New: - jsp:include shows partial output after the included file has been modified
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23406. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23406 jsp:include shows partial output after the included file has been modified Summary: jsp:include shows partial output after the included file has been modified Product: Tomcat 4 Version: 4.1.24 Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a very strange problem and it is almost unreproducable. If someone would like to help me isolate the issue I'd be much abliged. I'm willing to do the research work on it, but need a few hints where to look. The following happens: We have an index.jsp which jsp:includes a menu.jsp. The menu.jsp is a relatively large plain text file. The menu.jsp is generated every night at midnight to reflect the changes of the day. Some days when we come in, the menu only shows partially. Other days the whole menu is shown. When checking the generated java and class files everything seems to be in order. The index.jsp has a JspRuntimeLibrary.include where the jsp:include was and the menu.jsp, menu_jsp.java and menu_jsp.class(decompiled to check) all resemble the new state. The index.jsp shows itself entirely, however only a part of the included html is shown. If the menu.jsp is recreated manually everything works again. A sidenote to this bug is that it only seems to occur with larger includes (this example is 1300 lines). Other sites we've created use the same method of including and menu generation with smaller menus and they have no problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java
[EMAIL PROTECTED] wrote: luehe 2003/09/24 12:09:29 Modified:catalina/src/share/org/apache/catalina/startup CatalinaProperties.java Log: Added setProperty method. For example, this will allow the value for the noTldJars property to be determined and set dynamically. After a very frustrating private email exchange ... As I said previously: -1 for allowing configuration of a TLD exclusion list, because we're not out there to gain .01s on startup time, and a hardcoded list is good enough and will give us 99% of the benfit (which is already dubious IMO, but I don't mind about it overall). Also, (see below), the place where this is configured seems inappropriate. -1 for allowing dynaminc configuration of CatalinaProperties. cataina.properties is only meant to be able to configure the Bootstrap class of Tomcat, and shouldn't be a place to hack in things we want to hide. Please consider reverting the relevant patches. I think the best would be to completely remove the TLD exclusion list feature, as adding gratuitous complexity is bad. Thanks :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23373] - Servlet destroy() methods not being called at shutdown
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23373 Servlet destroy() methods not being called at shutdown --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 11:05 --- I couldn't reproduce the issue during testing with TC 5.0.12, and I couldn't find any issues affecting the shutdown code either. The only one is that apparently JDK 1.4 logging doesn't log reliably when called from a shutdown hook thread, for some reason. That made me think the proper shutdown didn't occur, but this isn't the case. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23406] - jsp:include shows partial output after the included file has been modified
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23406.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23406
jsp:include shows partial output after the included file has been modified
--- Additional Comments From [EMAIL PROTECTED] 2003-09-25 11:07 ---
[PURE SPECULATION]
You are seeing a race condition. While the file (menu.jsp) is being generated to
its destination - a request is made for it. During this sime time, a request is
made for the file. The file is read incompletely by the JSP compiler, and the
write happens quick enough that all of this occurs in the same second so the JSP
engine does not detect a file change.
I have seen this on tomcat404. You have 3 workarounds:
1) If its a plain text file, just call it menu.txt. This also saves some
overhead of a JSP.
2) Generate the file to a temporary area on the same disk. Then use a file copy
from/to local disk.
3) Tweak the jsp to force a compile error of itself if it is not complete. A
simple brace % { % at the top of the file then closing brace at the bottom
should work.
It would be nice for Jasper to store the file size and date to perform its
checks for situations such as this.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Protocol.java
remm2003/09/25 04:08:17
Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java
Log:
- Set the monitor thread as non daemon.
Revision ChangesPath
1.38 +1 -0
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
Index: Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- Http11Protocol.java 13 Sep 2003 17:30:50 - 1.37
+++ Http11Protocol.java 25 Sep 2003 11:08:17 - 1.38
@@ -200,6 +200,7 @@
tpOname=new ObjectName(domain + : + type=ThreadPool,name=http +
ep.getPort());
Registry.getRegistry().registerComponent(tp, tpOname, null );
tp.setName(http + ep.getPort());
+tp.setDaemon(false);
tp.addThreadPoolListener(new MXPoolListener(this, tp));
} catch (Exception e) {
log.error(Can't register threadpool );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
jserv status
Hi, I don't know if this is right place to ask but I have already asked in user list and I hadn't any answer. I have many jservs running and I need to know thier status. I want to know if there is any command line tool to query the port 8007 and get the status of the jservs processes. For example if they are frozen, lock up, etc. I would appreciate any help. Thanks in advance. Lucas -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jserv status
Lucas Alvarez a crit : Hi, I don't know if this is right place to ask but I have already asked in user list and I hadn't any answer. I have many jservs running and I need to know thier status. I want to know if there is any command line tool to query the port 8007 and get the status of the jservs processes. For example if they are frozen, lock up, etc. I would appreciate any help. Thanks in advance. Lucas JServ is deprecated and so you might consider switch to tomcat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
Glenn Nielsen a écrit : I have generated a test release source distribution for mod_jk 1.2.5, you can find it at: http://jakarta.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz Please build and test on as many OS/web servers as possible. I have already tested on Solaris7/8 Sparc. If there are no problems with this source release I will call for a release vote Friday 9/12 and release Monday 9/15 if the vote passes. Regards, Glenn Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans ServerLifecycleListener.java MBeanUtils.java
hgomez 2003/09/25 05:49:01
Modified:catalina/src/share/org/apache/catalina/mbeans
ServerLifecycleListener.java MBeanUtils.java
Log:
Make RMI/IIOP port configurable
Revision ChangesPath
1.11 +39 -13
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
Index: ServerLifecycleListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ServerLifecycleListener.java 19 Mar 2003 07:30:07 - 1.10
+++ ServerLifecycleListener.java 25 Sep 2003 12:49:01 - 1.11
@@ -152,15 +152,41 @@
/**
* MX4J adaptor name.
*/
-protected String adaptor = null;
+ protected String adaptor = null;
-public String getAdaptor() {
-return (this.adaptor);
-}
-
-public void setAdaptor(String adaptor) {
-this.adaptor = adaptor;
-}
+ public String getAdaptor() {
+ return (this.adaptor);
+ }
+
+ public void setAdaptor(String adaptor) {
+ this.adaptor = adaptor;
+ }
+
+ /**
+ * MX4J jrmp/iiop listen host
+ */
+ protected String adaptorHost = null;
+
+ public String getAdaptorHost() {
+ return (this.adaptorHost);
+ }
+
+ public void setAdaptorHost(String adaptorHost) {
+ this.adaptorHost = adaptorHost;
+ }
+
+ /**
+ * MX4J jrmp/iiop listen port
+ */
+ protected int adaptorPort = -1;
+
+ public int getAdaptorPort() {
+ return (this.adaptorPort);
+ }
+
+ public void setAdaptorPort(int adaptorPort) {
+ this.adaptorPort = adaptorPort;
+ }
// -- ContainerListener Methods
@@ -212,7 +238,7 @@
if (adaptor != null) {
try {
-MBeanUtils.createRMIAdaptor(adaptor);
+MBeanUtils.createRMIAdaptor(adaptor, adaptorHost,
adaptorPort);
} catch (Exception e) {
log.error(createAdaptor: Exception, e);
}
1.22 +19 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java
Index: MBeanUtils.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- MBeanUtils.java 2 Sep 2003 21:22:02 - 1.21
+++ MBeanUtils.java 25 Sep 2003 12:49:01 - 1.22
@@ -1711,7 +1711,7 @@
/**
* Create a RMI adapter [MX4J specific].
*/
-public static void createRMIAdaptor(String adaptorType)
+public static void createRMIAdaptor(String adaptorType, String host, int port)
throws Exception {
String namingProviderObjectName = null;
@@ -1724,6 +1724,9 @@
String contextFactory = null;
String providerUrl = null;
+ if ((host == null) || (host.trim().length() == 0))
+ host = localhost;
+
if (adaptorType.equals(jrmp)) {
namingProviderObjectName = Naming:type=rmiregistry;
namingProviderClassName = mx4j.tools.naming.NamingService;
@@ -1732,7 +1735,12 @@
adaptorMbeanClassName = mx4j.adaptor.rmi.jrmp.JRMPAdaptorMBean;
contextFactory =
com.sun.jndi.rmi.registry.RegistryContextFactory;
-providerUrl = rmi://localhost:1099;
+
+ if (port == -1)
+ port = 1099;
+
+providerUrl = rmi:// + host + : + Integer.toString(port);
+
} else if (adaptorType.equals(iiop)) {
namingProviderObjectName = Naming:type=tnameserv;
namingProviderClassName = mx4j.tools.naming.CosNamingService;
@@ -1741,7 +1749,11 @@
adaptorClassName = mx4j.adaptor.rmi.iiop.IIOPAdaptor;
adaptorMbeanClassName = mx4j.adaptor.rmi.iiop.IIOPAdaptorMBean;
contextFactory = com.sun.jndi.cosnaming.CNCtxFactory;
-providerUrl = iiop://localhost:900;
+
+ if (port == -1)
+ port = 900;
+
+providerUrl = iiop:// + host + : + Integer.toString(port);
} else {
throw new
Re: mod_jk 1.2.5 test release source distribution
Henri Gomez wrote: Glenn Nielsen a écrit : I have generated a test release source distribution for mod_jk 1.2.5, you can find it at: http://jakarta.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz Please build and test on as many OS/web servers as possible. I have already tested on Solaris7/8 Sparc. If there are no problems with this source release I will call for a release vote Friday 9/12 and release Monday 9/15 if the vote passes. Regards, Glenn Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] release mod_jk 1.2.5
The test results are in. No problems have been reported with the mod_jk 1.2.5 test release. ballot [ ] +1 release mod_jk 1.2.5 and I will help by building binaries for ___ [ ] +0 release mod_jk 1.2.5 [ ] -0 please don't release, reason __ [ ] -1 you can't release because of __ /ballot Voting closes saturday morning. If the vote is to release, I will release the source over the weekend. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk aphowto.xml quickhowto.xml workershowto.xml
glenn 2003/09/25 06:06:30 Modified:jk/native/common jk_version.h jk/xdocs/jk aphowto.xml quickhowto.xml workershowto.xml Log: Update revision prior to tag and release Revision ChangesPath 1.14 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_version.h Index: jk_version.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_version.h,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- jk_version.h 10 Jun 2003 14:05:43 - 1.13 +++ jk_version.h 25 Sep 2003 13:06:30 - 1.14 @@ -74,7 +74,7 @@ #define JK_VERBETA 0 #define JK_BETASTRING 1 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ -#define JK_VERISRELEASE 0 +#define JK_VERISRELEASE 1 /** END OF AREA TO MODIFY BEFORE RELEASING */ #define PACKAGE mod_jk/ 1.23 +11 -11jakarta-tomcat-connectors/jk/xdocs/jk/aphowto.xml Index: aphowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/aphowto.xml,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- aphowto.xml 25 Jul 2003 14:25:46 - 1.22 +++ aphowto.xml 25 Sep 2003 13:06:30 - 1.23 @@ -162,28 +162,28 @@ /p p -For example JK 1.2.4 can be found a href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/bin/; +For example JK 1.2.5 can be found a href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.5/bin/; here/a and contains the following: /p p table trthLocation/ththContents/th/tr - trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/bin/aix/;aix/a/tdtdSAVF including mod_jk for Apache 2.0 for iSeries V5R1/V5R2/td/tr - trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/bin/iseries/;iseries/a/tdtdSAVF including mod_jk for Apache 2.0 for iSeries V5R1/V5R2/td/tr - trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/bin/linux/;linux/a/tdtdmod_jk.so (Apache 1.3 standard API and EAPI and Apache 2.0) for some Linux Archs/td/tr - trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/bin/macosx/;macosx/a/tdtdContains the mod_jk.so for MacOS X/td/tr - trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/bin/netware/;netware/a/tdtdmod_jk.nlm and nsapi.nlm for Netware/td/tr - trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/bin/rpms/;rpms/a/tdtdContains the rpms (including sources and i386/ppc architectures)/td/tr - trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/bin/solaris6/;solaris6/a/tdtdContains the mod_jk.so for Solaris 6/td/tr - trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/bin/solaris8/;solaris8/a/tdtdContains the mod_jk.so for Solaris 8/td/tr - trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/bin/win32/;win32/a/tdtdContains the mod_jk.dll for Windows as well as other useful binaries./td/tr + trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.5/bin/aix/;aix/a/tdtdSAVF including mod_jk for Apache 2.0 for iSeries V5R1/V5R2/td/tr + trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.5/bin/iseries/;iseries/a/tdtdSAVF including mod_jk for Apache 2.0 for iSeries V5R1/V5R2/td/tr + trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.5/bin/linux/;linux/a/tdtdmod_jk.so (Apache 1.3 standard API and EAPI and Apache 2.0) for some Linux Archs/td/tr + trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.5/bin/macosx/;macosx/a/tdtdContains the mod_jk.so for MacOS X/td/tr + trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.5/bin/netware/;netware/a/tdtdmod_jk.nlm and nsapi.nlm for Netware/td/tr + trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.5/bin/rpms/;rpms/a/tdtdContains the rpms (including sources and i386/ppc architectures)/td/tr + trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.5/bin/solaris6/;solaris6/a/tdtdContains the mod_jk.so for Solaris 6/td/tr + trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.5/bin/solaris8/;solaris8/a/tdtdContains the mod_jk.so for Solaris 8/td/tr + trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.5/bin/win32/;win32/a/tdtdContains
cvs commit: jakarta-tomcat-connectors/jk HOWTO-RELEASE
glenn 2003/09/25 06:08:42 Modified:jk HOWTO-RELEASE Log: Update how to release Revision ChangesPath 1.7 +1 -1 jakarta-tomcat-connectors/jk/HOWTO-RELEASE Index: HOWTO-RELEASE === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/HOWTO-RELEASE,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- HOWTO-RELEASE 7 Sep 2003 03:32:19 - 1.6 +++ HOWTO-RELEASE 25 Sep 2003 13:08:42 - 1.7 @@ -74,7 +74,7 @@ Here is an example for mod_jk 1.2.5 -cvs tag -b JK_1.2.5 +cvs tag -b JK_1_2_5 Build the mod_jk 1.2 documentation -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_version.h
glenn 2003/09/25 06:11:21 Modified:jk/native/common jk_version.h Log: Bump version to 1.2.6-dev Revision ChangesPath 1.15 +4 -4 jakarta-tomcat-connectors/jk/native/common/jk_version.h Index: jk_version.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_version.h,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- jk_version.h 25 Sep 2003 13:06:30 - 1.14 +++ jk_version.h 25 Sep 2003 13:11:21 - 1.15 @@ -67,14 +67,14 @@ /** START OF AREA TO MODIFY BEFORE RELEASING */ #define JK_VERMAJOR 1 #define JK_VERMINOR 2 -#define JK_VERFIX 5 -#define JK_VERSTRING1.2.5 +#define JK_VERFIX 6 +#define JK_VERSTRING1.2.6 /* Beta number */ #define JK_VERBETA 0 #define JK_BETASTRING 1 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ -#define JK_VERISRELEASE 1 +#define JK_VERISRELEASE 0 /** END OF AREA TO MODIFY BEFORE RELEASING */ #define PACKAGE mod_jk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release mod_jk 1.2.5
[X] +1 release mod_jk 1.2.5 and I will help by building binaries for Linux - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20540] - Unable to compile the JSP files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20540. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20540 Unable to compile the JSP files --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 13:24 --- (Can't find anything in tomcat-users/google, trying here. Sorry if really wrong place. Thanks in advance.) I'm having the same problem with Tomcat 4.1.27, jdk 1.4.2 and Linux 2.4.20. I remember getting a error report when this happened show me the line number and other useful info in debugging the JSP. This is at debug level 5. Context path=/programa docBase=/path/programa debug=5/ FILE i'M USING FOR TESTING (other complex ones have the same behavior): html body This should show a error page %=jdfsafsd% /body /html The server send a HTTP header with 500 Internal Server error but nothing in the body (error report, etc). This is what I get in catalina.out: StandardContext[/programa]: Mapping contextPath='/programa' with requestURI='/programa/teste_de_erro.jsp' and relativeURI='/teste_de_erro.jsp' StandardContext[/programa]: Trying exact match StandardContext[/programa]: Trying prefix match StandardContext[/programa]: Trying extension match StandardContext[/programa]: Mapped to servlet 'jsp' with servlet path '/teste_de_erro.jsp' and path info 'null' and update=true Compile failed; see the compiler error output for details. at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842) at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:308) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:352) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:474) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2416) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1040) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1151) at java.lang.Thread.run(Thread.java:534) - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: [VOTE] release mod_jk 1.2.5
Glenn Nielsen wrote: The test results are in. No problems have been reported with the mod_jk 1.2.5 test release. ballot [X] +1 release mod_jk 1.2.5 and I will help by building binaries for Mac OS X/Solaris Sparc/FreeBSD 4.8, Apache 1.3/2.0 /ballot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: mod_jk does not detect a hung Tomcat]
Bill Barker wrote: - Original Message - From: Glenn Nielsen [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 12:28 PM Subject: Re: mod_jk does not detect a hung Tomcat Henri Gomez wrote: David Rees a écrit : Henri Gomez said: Henri Gomez a écrit : Nope since you don't have to just test at protocol level but also on higher level, for instance check the full chain, up to servlet handling. It's easy to simulate this behavior by sending a STOP signal to Tomcat. I've also attached a log from mod_jk showing the problem. I marked the point at which processing in mod_jk stopped until I sent a CONT signal to tomcat. Does mod_jk2 have this same problem? Is there any interest in fixing this? Does anyone have a workaround for this issue? Well, if you have a hung tomcat, you're probably allready in serious trouble. No, actually in my case I wasn't. I had two Tomcats running, as one was prone to locking up due to a JVM or application bug. With a 50-50 load distribution between two Tomcats, this left me with 1/2 of the requests getting stuck and clients waiting forever and tying up Apache processes. Eventually, a DOS will be the result if action is not taken in time. If mod_jk noticed it wasn't really alive, this wouldn't be an issue at all. Anyway, if we add stuff like time-out in ajp request, you could be stuck with long running servlets. Also jk read request in a blocking mode for performance and adding timeout here is not an option. Agreed that we wouldn't want a timeout normally to handle normal long running servlet processes, but if there was a PING/PONG added to the protocol there should be a timeout to prevent the above situation. When I worked on ajp13++ (ajp14) protocol, I added a more secure auth mecanism at connection time. Since there is a bidirectionnal communication, jk could detect that even if the connection is open, the remote didn't respond and so fall back to the next in cluster configuration. But on allready established connections, the problem persist. Or we should add a PING/PONG before sending any request to tomcat. It could be done as optional but I work on it only if many users make such requirements if many users ask for such feature ;) Well, you've got one so far. ;-) Adding a configurable option to have mod_jk verify (PING/PONG) that Tomcat is actually responding before using the connection would solve the problem and I can't imagine that it would add a lot of complexity to the code as well. If I wasn't so rusty with my C programming and had some spare time, I would offer to help code it up. ;-) In any case, I'll be more than happy to help test. Well, if you could find more users or at least one tomcat commiter (Glenn, Remy, Costin, JFC...) who need it, I'll add the necessary code in java and C areas ;) There may be a simple way to achieve what David is asking for without setting a request timeout or implementing a PING/PONG between mod_jk and Tomcat. What if each worker tracked the number of requests which were handled by the worker since the last successful completion of a request. i.e. add the following to a worker worker-last_completed // Time in seconds since last successfully completed request worker-requests_since_last_completed // Number of requests sent to worker since last successful completion. Then logic could be added to try and detect an instance of Tomcat which has failed. Perhaps even allow several additional worker properties to determine when mod_jk should consider the worker failed. This won't work with the pre-fork MPM, since each Apache child will have its own idea of the timing. The only way that it could tell that a Tomcat failed is to try the request and fail :). Argh, you are right, this goes back to the age old problem of not being able to write a global worker connection pool or shared memory with the current code. The only way to move forward would be to rewrite mod_jk 1.2 to use APR. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
Were there any changes since the test release, i.e. does the tagging reflect (minus release notes, etc) the test release? [I'm asking as I've built binaries for all platforms I need from the test release and would like to avoid rebuilding all of them] Glenn Nielsen wrote: Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Glenn - 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 1.2.5 test release source distribution
The test release at cvs.apache.org/~glenn is what will be released with no changes and does reflect the source which was tagged as mod_jk_1_2_5. So yes, you can use binaries built from that source as mod_jk 1.2.5 release binaries. Regards, Glenn Jess Holle wrote: Were there any changes since the test release, i.e. does the tagging reflect (minus release notes, etc) the test release? [I'm asking as I've built binaries for all platforms I need from the test release and would like to avoid rebuilding all of them] Glenn Nielsen wrote: Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Glenn - 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: [VOTE] release mod_jk 1.2.5
Glenn Nielsen wrote: The test results are in. No problems have been reported with the mod_jk 1.2.5 test release. ballot [ ] +1 release mod_jk 1.2.5 and I will help by building binaries for ___ [X] +0 release mod_jk 1.2.5 [ ] -0 please don't release, reason __ [ ] -1 you can't release because of __ /ballot Great work :) Unfortunately, there's nothing I can do to help :-( Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
Glenn Nielsen a écrit : The test release at cvs.apache.org/~glenn is what will be released with no changes and does reflect the source which was tagged as mod_jk_1_2_5. So yes, you can use binaries built from that source as mod_jk 1.2.5 release binaries. So I could commit my changes in 1.2.6-dev ? There is C and java ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release mod_jk 1.2.5
Here's my vote. Mike Anderson [EMAIL PROTECTED] 9/25/2003 6:59:10 AM The test results are in. No problems have been reported with the mod_jk 1.2.5 test release. ballot [ X] +1 release mod_jk 1.2.5 and I will help by building binaries for _NetWare Apache and Enterprise Server_ [ ] +0 release mod_jk 1.2.5 [ ] -0 please don't release, reason __ [ ] -1 you can't release because of __ /ballot Voting closes saturday morning. If the vote is to release, I will release the source over the weekend. Regards, Glenn - 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 1.2.5 test release source distribution
There is one minor change to jk_version.h so that the module reports that it is version 1.2.5 instead of 1.2.5-dev. If you already cheated and modified that locally, or you don't care what it reports, you should be fine. Mike Anderson [EMAIL PROTECTED] 9/25/2003 8:00:54 AM The test release at cvs.apache.org/~glenn is what will be released with no changes and does reflect the source which was tagged as mod_jk_1_2_5. So yes, you can use binaries built from that source as mod_jk 1.2.5 release binaries. Regards, Glenn Jess Holle wrote: Were there any changes since the test release, i.e. does the tagging reflect (minus release notes, etc) the test release? [I'm asking as I've built binaries for all platforms I need from the test release and would like to avoid rebuilding all of them] Glenn Nielsen wrote: Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Glenn - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
Actually from my reading of jk_version.h this change was already made in the test release. [And the version string shows up as 1.2.5 on Windows.] Mike Anderson wrote: There is one minor change to jk_version.h so that the module reports that it is version 1.2.5 instead of 1.2.5-dev. If you already cheated and modified that locally, or you don't care what it reports, you should be fine. Mike Anderson [EMAIL PROTECTED] 9/25/2003 8:00:54 AM The test release at cvs.apache.org/~glenn is what will be released with no changes and does reflect the source which was tagged as mod_jk_1_2_5. So yes, you can use binaries built from that source as mod_jk 1.2.5 release binaries. Regards, Glenn Jess Holle wrote: Were there any changes since the test release, i.e. does the tagging reflect (minus release notes, etc) the test release? [I'm asking as I've built binaries for all platforms I need from the test release and would like to avoid rebuilding all of them] Glenn Nielsen wrote: Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Glenn - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
Looks like Gleen was ahead of the game (as usual :-) and I was confused between what was in CVS and his tarball. Sorry for my misinformation. [EMAIL PROTECTED] 9/25/2003 8:38:51 AM Actually from my reading of jk_version.h this change was already made in the test release. [And the version string shows up as 1.2.5 on Windows.] Mike Anderson wrote: There is one minor change to jk_version.h so that the module reports that it is version 1.2.5 instead of 1.2.5-dev. If you already cheated and modified that locally, or you don't care what it reports, you should be fine. Mike Anderson [EMAIL PROTECTED] 9/25/2003 8:00:54 AM The test release at cvs.apache.org/~glenn is what will be released with no changes and does reflect the source which was tagged as mod_jk_1_2_5. So yes, you can use binaries built from that source as mod_jk 1.2.5 release binaries. Regards, Glenn Jess Holle wrote: Were there any changes since the test release, i.e. does the tagging reflect (minus release notes, etc) the test release? [I'm asking as I've built binaries for all platforms I need from the test release and would like to avoid rebuilding all of them] Glenn Nielsen wrote: Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Glenn - 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] - 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 1.2.5 test release source distribution
Glenn Nielsen a écrit : Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Ok, I start commit my stuff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
hgomez 2003/09/25 08:21:02 Modified:jk/xdocs/jk workershowto.xml Log: Update workers documentation with new hang detection parameters Revision ChangesPath 1.15 +33 -0 jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml Index: workershowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- workershowto.xml 25 Sep 2003 13:06:30 - 1.14 +++ workershowto.xml 25 Sep 2003 15:21:02 - 1.15 @@ -254,6 +254,39 @@ This property is very similar to bcache_timeout/b but works also in non-cache mode. /p +p +bconnect_timeout/b property told webserver to send a PING request on ajp13 connection after +connection is established. The parameter is the delay in milliseconds to wait for the PONG reply. +/p +p +This features has been added in bjk 1.2.6/b to avoid problem with hung tomcat's and require ajp13 +ping/pong support which has been implemented on Tomcat b3.3.2+, 4.1.28+ and 5.0.13+/b. +Disabled by default. +/p + +p +bprepost_timeout/b property told webserver to send a PING request on ajp13 connection before +forwarding to it a request. The parameter is the delay in milliseconds to wait for the PONG reply. +/p +p +This features has been added in bjk 1.2.6/b to avoid problem with hung tomcat's and require ajp13 +ping/pong support which has been implemented on bTomcat 3.3.2+, 4.1.28+ and 5.0.13+/b. +Disabled by default. +/p + +p +breply_timeout/b property told webserver to wait some time for reply to a forwarded request +before considering the remote tomcat is dead and eventually switch to another tomcat in a cluster +group. By default webserver will wait forever which could be an issue for you. +The parameter is the number of milliseconds to wait for reply, so adjust it carrefully if you +have long running servlets. +/p +p +This features has been added in bjk 1.2.6/b to avoid problem with hung tomcat's and works on all +servlet engines supporting ajp13. +Disabled by default. +/p + screen noteworker worker2 will talk to Tomcat listening on machine www2.x.com at port 8009 using 3.5 lb factor/note readworker.worker2.host=www2.x.com/read - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c
hgomez 2003/09/25 08:22:09
Modified:jk/native/common jk_ajp14_worker.h jk_worker.c
jk_ajp_common.h jk_ajp14_worker.c jk_ajp_common.c
jk_ajp13.h jk_ajp13.c jk_msg_buff.c
jk_worker_list.h jk_service.h jk_md5.c
jk_ajp13_worker.c jk_context.h jk_ajp14.h jk_util.h
jk_context.c jk_ajp14.c jk_util.c
jk/native/apache-2.0 mod_jk.c
jk/native/apache-1.3 mod_jk.c
Log:
New code to handle HANG tomcats.
Basically add PING/PONG in ajp protocol which will
require Tomcat 3.3.2, 4.1.28, 5.0.13
Revision ChangesPath
1.8 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.h
Index: jk_ajp14_worker.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.h,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- jk_ajp14_worker.h 21 Jun 2002 15:28:56 - 1.7
+++ jk_ajp14_worker.h 25 Sep 2003 15:22:07 - 1.8
@@ -57,7 +57,7 @@
/***
* Description: ajpv14 worker header file *
- * Author: Henri Gomez [EMAIL PROTECTED] *
+ * Author: Henri Gomez [EMAIL PROTECTED]*
* Version: $Revision$ *
***/
1.12 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_worker.c
Index: jk_worker.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_worker.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- jk_worker.c 4 Dec 2001 19:44:23 - 1.11
+++ jk_worker.c 25 Sep 2003 15:22:08 - 1.12
@@ -59,8 +59,8 @@
/***
* Description: Workers controller *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Author: Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision$ *
+ * Author: Henri Gomez [EMAIL PROTECTED]*
+ * Version: $Revision$ *
***/
#define _PLACE_WORKER_LIST_HERE
1.19 +13 -4 jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.h
Index: jk_ajp_common.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.h,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- jk_ajp_common.h 14 Mar 2003 13:36:35 - 1.18
+++ jk_ajp_common.h 25 Sep 2003 15:22:08 - 1.19
@@ -58,8 +58,8 @@
/***
* Description: common stuff for bi-directional protocol ajp13/ajp14. *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Author: Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision$ *
+ * Author: Henri Gomez [EMAIL PROTECTED]*
+ * Version: $Revision$ *
***/
#ifndef JK_AJP_COMMON_H
@@ -229,7 +229,9 @@
#define AJP_HEADER_SZ_LEN (2)
#define CHUNK_BUFFER_PAD (12)
#define AJP_DEF_CACHE_TIMEOUT (15)
-
+#define AJP_DEF_CONNECT_TIMEOUT (0)/* NO CONNECTION TIMEOUT = NO
PING/PONG */
+#define AJP_DEF_REPLY_TIMEOUT (0)/* NO REPLY TIMEOUT
*/
+#define AJP_DEF_PREPOST_TIMEOUT (0)/* NO PREPOST TIMEOUT = NO
PING/PONG*/
struct jk_res_data {
int status;
@@ -298,6 +300,13 @@
* Handle Cache Timeouts
*/
unsigned cache_timeout;
+
+ /*
+ * Handle Connection/Reply Timeouts
+ */
+ unsigned connect_timeout; /* connect ping/pong delay in ms (0 means
disabled) */
+ unsigned reply_timeout; /* reply timeout delay in ms (0 means disabled)
*/
+ unsigned prepost_timeout; /* before sending a request ping/pong timeout
delay
cvs commit: jakarta-tomcat-connectors/jk/xdocs/common AJPv13.xml
hgomez 2003/09/25 08:22:34 Modified:jk/xdocs/common AJPv13.xml Log: Update ajp13 documentation with PING/PONG Revision ChangesPath 1.5 +12 -1 jakarta-tomcat-connectors/jk/xdocs/common/AJPv13.xml Index: AJPv13.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/common/AJPv13.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- AJPv13.xml28 Nov 2002 08:52:48 - 1.4 +++ AJPv13.xml25 Sep 2003 15:22:34 - 1.5 @@ -252,6 +252,11 @@ tdShutdown/td tdThe web server asks the container to shut itself down./td /tr + tr +td8/td +tdPing/td +tdThe web server asks the container to respond quickly with a Pong./td + /tr /table /p @@ -284,6 +289,12 @@ td6/td tdGet Body Chunk/td tdGet further data from the request if it hasn't all been transferred +yet./td + /tr + tr +td8/td +tdPong Reply/td +tdThe reply to a PING request. yet./td /tr /table - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2 configure.in
hgomez 2003/09/25 08:23:24
Modified:jk/native2/common jk_uriEnv.c jk_md5.c jk_requtil.c
jk_registry.h jk_registry.c jk_workerEnv.c
jk_logger_file.c jk_worker_ajp13.c jk_env.c
jk_msg_ajp.c jk_handler_logon.c
jk/native2/include jk_service.h jk_env.h jk_endpoint.h
jk_objCache.h jk_requtil.h
jk/native2/server/apache2 jk_apache2.h mod_jk2.c
jk_service_apache2.c
jk/native2/server/apache13 mod_jk2.c
jk/native2/server/isapi jk_service_iis.c
jk/native2 configure.in
Log:
Update to use my correct email adress
Revision ChangesPath
1.50 +1 -1 jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c
Index: jk_uriEnv.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- jk_uriEnv.c 21 Apr 2003 08:20:35 - 1.49
+++ jk_uriEnv.c 25 Sep 2003 15:23:22 - 1.50
@@ -357,7 +357,7 @@
}
if( uriEnv-workerName == NULL ) {
/* The default worker */
-uriEnv-workerName=uriEnv-uriMap-workerEnv-defaultWorker-mbean-name;;
+uriEnv-workerName=uriEnv-uriMap-workerEnv-defaultWorker-mbean-name;
wname=uriEnv-workerName;
uriEnv-worker=uriEnv-uriMap-workerEnv-defaultWorker;
1.5 +2 -2 jakarta-tomcat-connectors/jk/native2/common/jk_md5.c
Index: jk_md5.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_md5.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- jk_md5.c 21 Feb 2002 11:11:15 - 1.4
+++ jk_md5.c 25 Sep 2003 15:23:22 - 1.5
@@ -102,7 +102,7 @@
/***
* Description: MD5 encoding wrapper *
- * Author: Henri Gomez [EMAIL PROTECTED] *
+ * Author: Henri Gomez [EMAIL PROTECTED]*
* Version: $Revision$ *
***/
1.29 +1 -1 jakarta-tomcat-connectors/jk/native2/common/jk_requtil.c
Index: jk_requtil.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_requtil.c,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- jk_requtil.c 4 Feb 2003 07:39:58 - 1.28
+++ jk_requtil.c 25 Sep 2003 15:23:22 - 1.29
@@ -59,7 +59,7 @@
* Utils for processing various request components
*
* Author: Gal Shachor [EMAIL PROTECTED]
- * Author: Henri Gomez [EMAIL PROTECTED]
+ * Author: Henri Gomez [EMAIL PROTECTED]
* Author: Costin Manolache
*/
1.20 +3 -3 jakarta-tomcat-connectors/jk/native2/common/jk_registry.h
Index: jk_registry.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_registry.h,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- jk_registry.h 4 Feb 2003 07:39:58 - 1.19
+++ jk_registry.h 25 Sep 2003 15:23:22 - 1.20
@@ -78,8 +78,8 @@
* static declarations for the factory methods and the registrerFactory() call.
*
* (based on jk_worker_list.h )
- * @author: Gal Shachor [EMAIL PROTECTED] *
- * @author: Henri Gomez [EMAIL PROTECTED] *
+ * @author: Gal Shachor [EMAIL PROTECTED]
+ * @author: Henri Gomez [EMAIL PROTECTED]
* @author: Costin Manolache
*
*/
1.30 +3 -3 jakarta-tomcat-connectors/jk/native2/common/jk_registry.c
Index: jk_registry.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_registry.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- jk_registry.c 4 Feb 2003 07:39:58 - 1.29
+++ jk_registry.c 25 Sep 2003 15:23:22 - 1.30
@@ -83,8 +83,8 @@
* static declarations for the factory methods and the registrerFactory() call.
*
* (based on jk_worker_list.h )
- * @author: Gal Shachor [EMAIL PROTECTED] *
- * @author: Henri Gomez [EMAIL
cvs commit: jakarta-tomcat-connectors/jk/support jk_ws.m4 jk_tchome.m4 jk_apr.m4 jk_apxs.m4 jk_apache_static.m4 jk_java.m4
hgomez 2003/09/25 08:23:56 Modified:jk/support jk_ws.m4 jk_tchome.m4 jk_apr.m4 jk_apxs.m4 jk_apache_static.m4 jk_java.m4 Log: Update to use my correct email adress Revision ChangesPath 1.2 +2 -2 jakarta-tomcat-connectors/jk/support/jk_ws.m4 Index: jk_ws.m4 === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_ws.m4,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jk_ws.m4 24 May 2002 07:05:07 - 1.1 +++ jk_ws.m4 25 Sep 2003 15:23:56 - 1.2 @@ -56,7 +56,7 @@ dnl = dnl -- -dnl Author Henri Gomez [EMAIL PROTECTED] +dnl Author Henri Gomez [EMAIL PROTECTED] dnl dnl Inspired by Pier works on webapp m4 macros :) dnl 1.2 +2 -2 jakarta-tomcat-connectors/jk/support/jk_tchome.m4 Index: jk_tchome.m4 === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_tchome.m4,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jk_tchome.m4 24 May 2002 07:05:07 - 1.1 +++ jk_tchome.m4 25 Sep 2003 15:23:56 - 1.2 @@ -56,7 +56,7 @@ dnl = dnl -- -dnl Author Henri Gomez [EMAIL PROTECTED] +dnl Author Henri Gomez [EMAIL PROTECTED] dnl dnl Inspired by Pier works on webapp m4 macros :) dnl 1.3 +2 -2 jakarta-tomcat-connectors/jk/support/jk_apr.m4 Index: jk_apr.m4 === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jk_apr.m4 5 Jun 2002 09:38:28 - 1.2 +++ jk_apr.m4 25 Sep 2003 15:23:56 - 1.3 @@ -56,7 +56,7 @@ dnl = dnl -- -dnl Author Henri Gomez [EMAIL PROTECTED] +dnl Author Henri Gomez [EMAIL PROTECTED] dnl dnl Inspired by Pier works on webapp m4 macros :) dnl 1.6 +2 -2 jakarta-tomcat-connectors/jk/support/jk_apxs.m4 Index: jk_apxs.m4 === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_apxs.m4,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- jk_apxs.m412 Sep 2002 10:33:45 - 1.5 +++ jk_apxs.m425 Sep 2003 15:23:56 - 1.6 @@ -56,7 +56,7 @@ dnl = dnl -- -dnl Author Henri Gomez [EMAIL PROTECTED] +dnl Author Henri Gomez [EMAIL PROTECTED] dnl dnl Inspired by Pier works on webapp m4 macros :) dnl 1.2 +2 -2 jakarta-tomcat-connectors/jk/support/jk_apache_static.m4 Index: jk_apache_static.m4 === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_apache_static.m4,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jk_apache_static.m4 24 May 2002 07:05:07 - 1.1 +++ jk_apache_static.m4 25 Sep 2003 15:23:56 - 1.2 @@ -56,7 +56,7 @@ dnl = dnl -- -dnl Author Henri Gomez [EMAIL PROTECTED] +dnl Author Henri Gomez [EMAIL PROTECTED] dnl dnl Inspired by Pier works on webapp m4 macros :) dnl 1.3 +2 -2 jakarta-tomcat-connectors/jk/support/jk_java.m4 Index: jk_java.m4 === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_java.m4,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jk_java.m44 Jun 2002 10:29:41 - 1.2 +++ jk_java.m425 Sep 2003 15:23:56 - 1.3 @@ -56,7 +56,7 @@ dnl = dnl -- -dnl Author Henri Gomez [EMAIL PROTECTED] +dnl Author Henri Gomez [EMAIL PROTECTED] dnl dnl Inspired by Pier works on webapp m4 macros :) dnl
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java
hgomez 2003/09/25 08:24:44 Modified:jk/java/org/apache/jk/common HandlerRequest.java MsgAjp.java JkMX.java jk/java/org/apache/jk/core WorkerEnv.java Msg.java MsgContext.java jk/java/org/apache/ajp Ajp13.java Ajp13Packet.java NegociationHandler.java RequestHandler.java jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java Log: Update ajp13 support in JTC to handle PING/PONG. Review is more than welcomed Revision ChangesPath 1.26 +20 -5 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java Index: HandlerRequest.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- HandlerRequest.java 17 May 2003 03:21:33 - 1.25 +++ HandlerRequest.java 25 Sep 2003 15:24:43 - 1.26 @@ -89,7 +89,7 @@ * - GET_BODY_CHUNK. Request a chunk of body data * - END_RESPONSE. Notify the end of a request processing. * - * @author Henri Gomez [EMAIL PROTECTED] + * @author Henri Gomez [EMAIL PROTECTED] * @author Dan Milstein [EMAIL PROTECTED] * @author Keith Wannamaker [EMAIL PROTECTED] * @author Costin Manolache @@ -103,14 +103,15 @@ // Prefix codes for message types from server to container public static final byte JK_AJP13_FORWARD_REQUEST = 2; - -public static final byte JK_AJP13_SHUTDOWN = 7; + public static final byte JK_AJP13_SHUTDOWN = 7; + public static final byte JK_AJP13_PING_REQUEST = 8; // Prefix codes for message types from container to server public static final byte JK_AJP13_SEND_BODY_CHUNK = 3; public static final byte JK_AJP13_SEND_HEADERS = 4; public static final byte JK_AJP13_END_RESPONSE = 5; -public static final byte JK_AJP13_GET_BODY_CHUNK= 6; + public static final byte JK_AJP13_GET_BODY_CHUNK= 6; + public static final byte JK_AJP13_PONG_REPLY= 9; // Integer codes for common response header strings public static final int SC_RESP_CONTENT_TYPE= 0xA001; @@ -227,10 +228,14 @@ JK_AJP13_FORWARD_REQUEST, this, null); // 2 -dispatch.registerMessageType( JK_AJP13_FORWARD_REQUEST, +dispatch.registerMessageType( JK_AJP13_SHUTDOWN, JK_AJP13_SHUTDOWN, this, null); // 7 + dispatch.registerMessageType( JK_AJP13_PING_REQUEST, + JK_AJP13_PING_REQUEST, + this, null); // 8 + // register outgoing messages handler dispatch.registerMessageType( JK_AJP13_SEND_BODY_CHUNK, // 3 JK_AJP13_SEND_BODY_CHUNK, @@ -411,6 +416,16 @@ System.exit(0); return OK; + + // We got a PING REQUEST, quickly respond with a PONG + case JK_AJP13_PING_REQUEST: + msg.reset(); + msg.appendByte(JK_AJP13_PONG_REPLY); + ep.setType( JkHandler.HANDLE_SEND_PACKET ); + ep.getSource().invoke( msg, ep ); + + return OK; + default: System.err.println(Unknown message + type ); msg.dump(Unknown message ); 1.15 +1 -1 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/MsgAjp.java Index: MsgAjp.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/MsgAjp.java,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- MsgAjp.java 18 Sep 2003 16:21:00 - 1.14 +++ MsgAjp.java 25 Sep 2003 15:24:43 - 1.15 @@ -73,7 +73,7 @@ * * @see Ajp14/Ajp13Packet * - * @author Henri Gomez [EMAIL PROTECTED] + * @author Henri Gomez [EMAIL PROTECTED] * @author Dan Milstein [EMAIL PROTECTED] * @author Keith Wannamaker [EMAIL PROTECTED] * @author Kevin Seguin 1.13 +41 -20jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java Index: JkMX.java === RCS file:
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
hgomez 2003/09/25 08:26:25
Modified:src/share/org/apache/tomcat/modules/server Ajp13.java
Log:
Update ajp13 support in TC 3.3.2 to handle PING/PONG.
Ok, this code will be deprecated but for now
Revision ChangesPath
1.34 +32 -2
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java
Index: Ajp13.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- Ajp13.java22 Sep 2003 09:18:37 - 1.33
+++ Ajp13.java25 Sep 2003 15:26:25 - 1.34
@@ -104,7 +104,8 @@
// Prefix codes for message types from server to container
public static final byte JK_AJP13_FORWARD_REQUEST = 2;
-public static final byte JK_AJP13_SHUTDOWN = 7;
+ public static final byte JK_AJP13_SHUTDOWN = 7;
+ public static final byte JK_AJP13_PING_REQUEST = 8;
// Error code for Ajp13
public static final int JK_AJP13_BAD_HEADER= -100;
@@ -118,7 +119,8 @@
public static final byte JK_AJP13_SEND_BODY_CHUNK = 3;
public static final byte JK_AJP13_SEND_HEADERS = 4;
public static final byte JK_AJP13_END_RESPONSE = 5;
-public static final byte JK_AJP13_GET_BODY_CHUNK= 6;
+ public static final byte JK_AJP13_GET_BODY_CHUNK= 6;
+ public static final byte JK_AJP13_PONG_REPLY = 9;
// Integer codes for common response header strings
public static final int SC_RESP_CONTENT_TYPE= 0xA001;
@@ -300,10 +302,38 @@
secret=hBuf.getString();
}
return -2;
+
+ case JK_AJP13_PING_REQUEST:
+ return sendPong();
}
+
return 200; // XXX This is actually an error condition
+
}
+ /**
+ * Send a PONG REPLY to web server to its PING request
+ *
+ * @param ch the Ajp13 channel
+ * @param outBuf the Ajp13Packet output packet to use
+ */
+ private int sendPong()
+ {
+ outBuf.reset();
+ outBuf.appendByte(JK_AJP13_PONG_REPLY);
+
+ try
+ {
+ send(outBuf);
+ }
+ catch (IOException ioe)
+ {
+ d(can't send pong reply);
+ }
+
+ return (999); // success but no need to process farther
+ }
+
/**
* Parse a FORWARD_REQUEST packet from the web server and store its
* properties in the passed-in request object.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
Henri Gomez a écrit : Glenn Nielsen a écrit : Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Ok, I start commit my stuff Commited. Thanks to review and comments ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java Ajp13Interceptor.java
hgomez 2003/09/25 08:33:06
Modified:src/share/org/apache/tomcat/modules/server Ajp13.java
Ajp13Interceptor.java
Log:
Update doc and Interceptor
Revision ChangesPath
1.35 +4 -2
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java
Index: Ajp13.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- Ajp13.java25 Sep 2003 15:26:25 - 1.34
+++ Ajp13.java25 Sep 2003 15:33:06 - 1.35
@@ -267,8 +267,10 @@
* @param req An empty (newly-recycled) request object.
*
* @return 200 in case of a successful read of a forwarded request, 500
- * if there were errors in the reading of the request, and -2 if the
- * server is asking the container to shut itself down.
+ * if there were errors in the reading of the request, 999 if request
+ * is a low level request which has been processed by low layer and
+ * -2 if the server is asking the container to shut itself down.
+ *
*/
public int receiveNextRequest(Request req) throws IOException
{
1.23 +11 -3
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java
Index: Ajp13Interceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- Ajp13Interceptor.java 22 Sep 2003 09:18:37 - 1.22
+++ Ajp13Interceptor.java 25 Sep 2003 15:33:06 - 1.23
@@ -336,6 +336,14 @@
}
}
+ // special case - low level AJP13 packet, like
+ // PING/PONG ...
+ if( status == 999 )
+ {
+ req.recycle();
+ continue;
+ }
+
// special case - invalid AJP13 packet, error
// decoding packet ...
// we drop the connection rigth now
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] release mod_jk 1.2.5
ballot [ x] +1 release mod_jk 1.2.5 and I will help by building binaries for: 2.0.47/1.3.28+EAPI/IIS (WIN32) [ ] +0 release mod_jk 1.2.5 [ ] -0 please don't release, reason __ [ ] -1 you can't release because of __ /ballot MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/common AJPv13.xml
I think there's a typo-o in here, looks like the text for the PONG REPLY will read as follows: The reply to a PING request. yet. The attached patch should fix it (Against rev 1.5) -Dave [EMAIL PROTECTED] said: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/common/AJPv13.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- AJPv13.xml 28 Nov 2002 08:52:48 - 1.4 +++ AJPv13.xml 25 Sep 2003 15:22:34 - 1.5 @@ -252,6 +252,11 @@ tdShutdown/td tdThe web server asks the container to shut itself down./td /tr + tr +td8/td +tdPing/td +tdThe web server asks the container to respond quickly with a Pong./td + /tr /table /p @@ -284,6 +289,12 @@ td6/td tdGet Body Chunk/td tdGet further data from the request if it hasn't all been transferred +yet./td + /tr + tr +td8/td +tdPong Reply/td +tdThe reply to a PING request. yet./td /tr /table - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22869] - under liveDeploy a webapp may throw an exception on restart. if some files are soft links
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22869. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22869 under liveDeploy a webapp may throw an exception on restart. if some files are soft links --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 15:58 --- I would like to add that I am experiencing this bug as well. In my case I do not have liveDeploy enabled and that in my case the app manager does not indicate any problem when a user stops and starts our web application. In our case our users receive internal server errors when attempting to access jsp files that rely on symbolic links to include external files. The exact message is: Exception report message Internal Server Error description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: /login.jsp(18,133) File /_vti_templates/topmenu.txt not found at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:94) at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:428) at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:170) at org.apache.jasper.compiler.Parser.processIncludeDirective(Parser.java:305) at org.apache.jasper.compiler.Parser.parseIncludeDirective(Parser.java:340) at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:378) at org.apache.jasper.compiler.Parser.parseElements(Parser.java:795) at org.apache.jasper.compiler.Parser.parse(Parser.java:122) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:199) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:153) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:227) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:369) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:473) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:190) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:432) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:356) at com.sears.intra.web.login.WebLoginFilter.deny(WebLoginFilter.java:129) at com.sears.intra.web.login.WebLoginFilter.doFilter(WebLoginFilter.java:86) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2408) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at
Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/common AJPv13.xml
David Rees said: I think there's a typo-o in here, looks like the text for the PONG REPLY will read as follows: The reply to a PING request. yet. The attached patch should fix it (Against rev 1.5) -Dave Doesn't look like my attachment made it. Here it is inline. -Dave --- AJPv13.xml Thu Sep 25 08:53:19 2003 +++ AJPv13.xml~ Thu Sep 25 08:52:26 2003 @@ -294,7 +294,8 @@ tr td8/td tdPong Reply/td -tdThe reply to a PING request./td +tdThe reply to a PING request. +yet./td /tr /table /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/common AJPv13.xml
hgomez 2003/09/25 09:03:07 Modified:jk/xdocs/common AJPv13.xml Log: Fix doc, Thanks David Revision ChangesPath 1.6 +3 -4 jakarta-tomcat-connectors/jk/xdocs/common/AJPv13.xml Index: AJPv13.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/common/AJPv13.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- AJPv13.xml25 Sep 2003 15:22:34 - 1.5 +++ AJPv13.xml25 Sep 2003 16:03:07 - 1.6 @@ -292,10 +292,9 @@ yet./td /tr tr -td8/td +td9/td tdPong Reply/td -tdThe reply to a PING request. -yet./td +tdThe reply to a PING request/td /tr /table /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
Henri Gomez wrote: Glenn Nielsen a écrit : The test release at cvs.apache.org/~glenn is what will be released with no changes and does reflect the source which was tagged as mod_jk_1_2_5. So yes, you can use binaries built from that source as mod_jk 1.2.5 release binaries. So I could commit my changes in 1.2.6-dev ? There is C and java ;-) You can commit your changes to HEAD. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
Glenn Nielsen a écrit : Henri Gomez wrote: Glenn Nielsen a écrit : The test release at cvs.apache.org/~glenn is what will be released with no changes and does reflect the source which was tagged as mod_jk_1_2_5. So yes, you can use binaries built from that source as mod_jk 1.2.5 release binaries. So I could commit my changes in 1.2.6-dev ? There is C and java ;-) You can commit your changes to HEAD. Done 15mn ago ;) See you tomorrow - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
Mike, I have built using the test release of mod_jk 1.2.5 and for me it does not have -dev. Looking at jk_version.h in the source release it is properly defined for a release. Glenn Mike Anderson wrote: There is one minor change to jk_version.h so that the module reports that it is version 1.2.5 instead of 1.2.5-dev. If you already cheated and modified that locally, or you don't care what it reports, you should be fine. Mike Anderson [EMAIL PROTECTED] 9/25/2003 8:00:54 AM The test release at cvs.apache.org/~glenn is what will be released with no changes and does reflect the source which was tagged as mod_jk_1_2_5. So yes, you can use binaries built from that source as mod_jk 1.2.5 release binaries. Regards, Glenn Jess Holle wrote: Were there any changes since the test release, i.e. does the tagging reflect (minus release notes, etc) the test release? [I'm asking as I've built binaries for all platforms I need from the test release and would like to avoid rebuilding all of them] Glenn Nielsen wrote: Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Glenn - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
I am making fewer mistakes with the releases since I wrote up the doc jk/HOW-TO-RELEASE. ;-) Mike Anderson wrote: Looks like Gleen was ahead of the game (as usual :-) and I was confused between what was in CVS and his tarball. Sorry for my misinformation. [EMAIL PROTECTED] 9/25/2003 8:38:51 AM Actually from my reading of jk_version.h this change was already made in the test release. [And the version string shows up as 1.2.5 on Windows.] Mike Anderson wrote: There is one minor change to jk_version.h so that the module reports that it is version 1.2.5 instead of 1.2.5-dev. If you already cheated and modified that locally, or you don't care what it reports, you should be fine. Mike Anderson [EMAIL PROTECTED] 9/25/2003 8:00:54 AM The test release at cvs.apache.org/~glenn is what will be released with no changes and does reflect the source which was tagged as mod_jk_1_2_5. So yes, you can use binaries built from that source as mod_jk 1.2.5 release binaries. Regards, Glenn Jess Holle wrote: Were there any changes since the test release, i.e. does the tagging reflect (minus release notes, etc) the test release? [I'm asking as I've built binaries for all platforms I need from the test release and would like to avoid rebuilding all of them] Glenn Nielsen wrote: Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Glenn - 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] - 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] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4091] - custom host with unpackWARs=true don't expand war automatically - work around fails log4j!
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4091. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4091 custom host with unpackWARs=true don't expand war automatically - work around fails log4j! [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 16:41 --- As per the documentation (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html) : --- The Document Base (also known as the Context Root) directory for this web application, or the pathname to the web application archive file (if this web application is being executed directly from the WAR file). You may specify an absolute pathname for this directory or WAR file, or a pathname that is relative to the appBase directory of the owning Host. --- When you deploy an application as a war and specify the docBase as a war file name (say tomcat-docs2 or tomcat-docs2.war [ are you supposed to include the extension]) in the server.xml or an [application-name].xml file, the application fails to start with the following exception: java.lang.IllegalArgumentException: Document base ..\webapps\tomcat-docs2.war does not exist or is not a readable directory. This appears to be fixed in the version 5 release (bug 4829). I am running 4.1.27 and although the bug was marked as resolved-fixed, it is still breaking. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using ThreadLocal with Tomcat4118 or greater
Hi, I'm developing a servlet framework and have run into a design snag because I don't know enough about how Tomcat handles threads. Long story short, I want a quick way for any class running in the framework to get access to the current request and response objects. I am tired of passing references to these objects from class to class. Another developer told me that I can use Threadlocal to create a singleton-like class that is unique to each request because every request runs in its own thread(big assumption that I am not too sure about). By taking this approach I can then quickly import my thread local class and have access to the request and response objects for the current request. Before I decide to implement this does anyone know if I would run into any snags on a high traffic site. Is it a guarantee that every request uses its own thread? I understand threads get pooled but as long as I initialize the threadlocal class on every request that would guarantee that each request is getting the right request and response objects. Can anyone see any instances when this would not work? Thanks, - dkrebs This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19778] - utf-8-encoded source gets mangled in xml-mode
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19778 utf-8-encoded source gets mangled in xml-mode --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 17:41 --- In JSP 2.0 the I18N approach was revisited and the encoding algorithm for XML syntax redefined. This part of Jasper in Tomcat 5 was rewritten. Can you guys verify if Tomcat 5 works correctly here? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CoyoteRequest assumption that breaks UTF-8 support
I am convinced that Tomcat 4.x has a very real bug when dealing with character encodings on login form submissions. (maybe elsewhere as well). To see what I am observing, watch the flow of code when doing a login from Tomcat's admin application. It sets the charset to UTF-8 in the tag %@ page language=java contentType=text/html;charset=UTF-8 import=java.util.* % at the top of the file. This correctly gets the browser into unicode mode, and (with all of the browsers I have tested - IE and NS 7 on windows, and Konqueror on SUSE Linux), they correctly encode your username / password in UTF-8. But, in CoyoteRequest, parseRequestParameters(), Tomcat tries to determine and set the encoding to be used and ends up setting it to be null. Why? It looks like in Request.getCharacterEncoding and subordinate methods, the header value, content-type is checked. On all of the browsers that I have checked if this value is set at all, it is simply set to application/x-www-form-urlencoded, without mention of UTF-8 or any other charset. The browser assumes that since you requested a certain charset in the first place, that you know how to deal with a parameter that is sent on encoded in that charset. Tomcat sees no mention of charsets, so it simply defaults to ISO-8859-1 (hardcoded constant) Is there a better way to tie the default value to whatever the JSP login form originally requested, or even, failing that, can we look up the system property, file.encoding, and require it to be passed in on startup. This is less than ideal though. Preferrably it would be something settable context-wide, not tomcat-wide. Where does this leave applications that wish to support extended characters in passwords and/or usernames, characters that may not be in the ISO-8859-1 range? Or am I missing the correct place to set this? Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java
Remy, sorry, but I don't see which part of our email exchange you found very frustrating. As I said, I'm open to suggestions, and if my patch is deemed useless, I'll revert it. No problem. I've done some measurements on my Ultra 60. TldConfig already calculates the tldScanTime for each context, so that's the number I'm using. Following are the tldScanTime numbers for a sequence of 10 startups with the standard contexts: - w/o optimization (static initializer in TldConfig commented out): Context name tldScanTime for 10 runs | Average --- /manager 417/452/431/438/408/468/434/418/423/450 | 433.90 /admin 1399/1310/1440/1385/1288/1347/1345/1340/1280/1317 |1345.10 /servlets-examples 210/198/206/235/192/182/189/188/166/195 | 196.10 [] 222/222/213/218/222/225/215/204/223/221 | 218.50 /jsp-examples 996/841/854/862/900/855/903/845/856/815 | 872.70 /tomcat-docs 155/176/168/184/175/294/164/185/194/183 | 187.80 Total=3254.10 - With optimization Context name tldScanTime for 10 runs | Average --- /manager 239/225/242/375/230/241/234/228/237/319 | 257.00 /admin 1225/1192/1242/1171/1320/1251/1248/1270/1253/1219 |1239.10 /servlets-examples 74/69/165/79/92/71/106/96/95/123 | 97.00 [] 129/109/136/186/241/194/111/103/96/142| 144.70 /jsp-examples 728/736/757/843/812/796/782/753/820/813 | 784.00 /tomcat-docs 77/60/127/191/102/101/61/96/88/85 | 98.80 Total=2620.60 This may not be significant, but if you increase the number of contexts and have additional JARs on your classpath of which you know they don't contain any TLDs, we're talking seconds, not ms. As I mentioned in my private email to you, it may not always be practical to rely on the list of noTldJars configured in catalina.properties if you bundle Tomcat with your own product. That's why I added the setProperty method on CatalinaProperties, in order to be able to override the value in catalina.properties. This allows the list of noTldJars to be determined more accurately at runtime. The code that is embedding Tomcat would call CatalinaProperties.setProperty() *before* starting Tomcat. I leave the judgement up to the community. Thanks, Jan Remy Maucherat wrote: [EMAIL PROTECTED] wrote: luehe 2003/09/24 12:09:29 Modified:catalina/src/share/org/apache/catalina/startup CatalinaProperties.java Log: Added setProperty method. For example, this will allow the value for the noTldJars property to be determined and set dynamically. After a very frustrating private email exchange ... As I said previously: -1 for allowing configuration of a TLD exclusion list, because we're not out there to gain .01s on startup time, and a hardcoded list is good enough and will give us 99% of the benfit (which is already dubious IMO, but I don't mind about it overall). Also, (see below), the place where this is configured seems inappropriate. -1 for allowing dynaminc configuration of CatalinaProperties. cataina.properties is only meant to be able to configure the Bootstrap class of Tomcat, and shouldn't be a place to hack in things we want to hide. Please consider reverting the relevant patches. I think the best would be to completely remove the TLD exclusion list feature, as adding gratuitous complexity is bad. Thanks :) Remy - 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: CoyoteRequest assumption that breaks UTF-8 support
This is not a bug. Read http://asg.web.cmu.edu/rfc/rfc2070.html#sec-5.
Use this code:
String result = req.getParameter(parm);
if (result == null)
return null;
try
{
return new String(result.getBytes(ISO-8859-1), UTF-8);
}
catch (UnsupportedEncodingException e)
{
return result;
}
Dave Oxley
[EMAIL PROTECTED]
-Original Message-
From: Jeff Tulley [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 6:40 PM
To: [EMAIL PROTECTED]
Subject: CoyoteRequest assumption that breaks UTF-8 support
I am convinced that Tomcat 4.x has a very real bug when dealing with
character encodings on login form submissions. (maybe elsewhere as
well).
To see what I am observing, watch the flow of code when doing a login
from Tomcat's admin application. It sets the charset to UTF-8 in the
tag
%@ page language=java contentType=text/html;charset=UTF-8
import=java.util.* % at the top of the file. This correctly gets
the browser into unicode mode, and (with all of the browsers I have
tested - IE and NS 7 on windows, and Konqueror on SUSE Linux), they
correctly encode your username / password in UTF-8.
But, in CoyoteRequest, parseRequestParameters(), Tomcat tries to
determine and set the encoding to be used and ends up setting it to be
null. Why? It looks like in Request.getCharacterEncoding and
subordinate methods, the header value, content-type is checked. On
all of the browsers that I have checked if this value is set at all, it
is simply set to application/x-www-form-urlencoded, without mention of
UTF-8 or any other charset. The browser assumes that since you
requested a certain charset in the first place, that you know how to
deal with a parameter that is sent on encoded in that charset.
Tomcat sees no mention of charsets, so it simply defaults to
ISO-8859-1 (hardcoded constant)
Is there a better way to tie the default value to whatever the JSP
login form originally requested, or even, failing that, can we look up
the system property, file.encoding, and require it to be passed in on
startup. This is less than ideal though. Preferrably it would be
something settable context-wide, not tomcat-wide.
Where does this leave applications that wish to support extended
characters in passwords and/or usernames, characters that may not be in
the ISO-8859-1 range?
Or am I missing the correct place to set this?
Jeff Tulley ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
DO NOT REPLY [Bug 23354] - HttpServletResponse.encodeURL() does not encode relative URLs beginning with ./ or ../
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23354. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23354 HttpServletResponse.encodeURL() does not encode relative URLs beginning with ./ or ../ [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 18:43 --- This works for me using the latest tomcat 4 source. I can't see any changes in CVS that could have changed behaviour since 4.1.27. I am therefore marking this bug as WORKSFORME. If you are still experiencing this problem, I will need some more information before I can investigate further. The most useful thing you could do is attached a simple war file that exhibits the invalid behaviour. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19145] - http to https redirect fails on non-standard ports
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19145. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19145 http to https redirect fails on non-standard ports [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 18:57 --- As the root cause of this is an IE bug (see also bug 13861) this will not be fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8752] - HTTPS redirect fails if using welcome-file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8752. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8752 HTTPS redirect fails if using welcome-file [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 18:59 --- As the root cause of this is an IE bug (see bugs 13861 and 19145) this will not be fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22869] - under liveDeploy a webapp may throw an exception on restart. if some files are soft links
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22869. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22869 under liveDeploy a webapp may throw an exception on restart. if some files are soft links --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 18:59 --- I built a standalone FileDirContext.class based on the original java file. In the release method I commented out the resetting of the allowLinking and caseSensitive attributes. I copied the created class files FileDirContext$FileResource.class, FileDirContext.class, and FileDirContext$FileResourceAttributes.class to the server/classes/org/apache/naming/resources directory and bounced the container. The problem still exists. Am I missing something? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8752] - HTTPS redirect fails if using welcome-file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8752. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8752 HTTPS redirect fails if using welcome-file --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 19:17 --- It's been years that this has been broken, so, I could be misremembering, but, I'd swear that this used to work. Why is this possible for Apache HTTP server and impossible for Tomcat? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java TldConfig.java
jfarcand2003/09/25 12:27:59
Modified:catalina/src/share/org/apache/catalina/startup
ContextConfig.java TldConfig.java
Log:
Follow a 101 Tranning course on how to use Xerces 2.3/2.5 and fix the schema
validation problem. The fix will only works for Xerces when schema are supported
(Crimson will still work).
Changes between 2.1/2.3 seems to have modified the way the parser is working. Those
private property will be added to the next release of jaxp.
Thanks to ramesh mandava at sun for is teaching lesson :-)
Revision ChangesPath
1.36 +23 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
Index: ContextConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- ContextConfig.java23 Sep 2003 21:37:00 - 1.35
+++ ContextConfig.java25 Sep 2003 19:27:59 - 1.36
@@ -300,7 +300,7 @@
if (context instanceof StandardContext) {
((StandardContext) context).setReplaceWelcomeFiles(true);
}
-webDigester.setUseContextClassLoader(true);
+webDigester.setUseContextClassLoader(false);
webDigester.push(context);
webDigester.parse(is);
} else {
@@ -497,12 +497,31 @@
webDigester = patchXerces(webDigester);
}
-url = ContextConfig.class.getResource(Constants.WebSchemaResourcePath_24);
+url = ContextConfig.class.
+getResource(Constants.WebSchemaResourcePath_24);
+
SchemaResolver webEntityResolver = new SchemaResolver(url.toString(),
webDigester);
if (validation) {
-webDigester.setSchema(url.toString());
+if (webDigester.getFactory().getClass()
+.getName().indexOf(xerces)!=-1) {
+try{
+webDigester.setFeature(
+http://apache.org/xml/features/validation/dynamic;,
+true);
+webDigester.setFeature(
+http://apache.org/xml/features/validation/schema;,
+true);
+} catch(ParserConfigurationException e){
+// log(contextConfig.registerLocalSchema, e);
+} catch(SAXNotRecognizedException e){
+// log(contextConfig.registerLocalSchema, e);
+} catch(SAXNotSupportedException e){
+// log(contextConfig.registerLocalSchema, e);
+}
+
+}
}
url = ContextConfig.class.getResource(Constants.WebDtdResourcePath_22);
1.29 +18 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java
Index: TldConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- TldConfig.java23 Sep 2003 21:37:00 - 1.28
+++ TldConfig.java25 Sep 2003 19:27:59 - 1.29
@@ -409,7 +409,24 @@
tldDigester);
if (xmlValidation) {
-tldDigester.setSchema(url.toString());
+if (tldDigester.getFactory().getClass()
+.getName().indexOf(xerces)!=-1) {
+try{
+tldDigester.setFeature(
+http://apache.org/xml/features/validation/dynamic;,
+true);
+tldDigester.setFeature(
+http://apache.org/xml/features/validation/schema;,
+true);
+} catch(ParserConfigurationException e){
+// log(contextConfig.registerLocalSchema, e);
+} catch(SAXNotRecognizedException e){
+// log(contextConfig.registerLocalSchema, e);
+} catch(SAXNotSupportedException e){
+// log(contextConfig.registerLocalSchema, e);
+}
+
+}
}
url = TldConfig.class.getResource(Constants.TldDtdResourcePath_11);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Please help (Custom authenticator realm problem)
Dear all, I wrote my own authenticator (extends FormAuthenticator) realm (extends JDBCRealm). What I need is to check one more field in the database besides password for authentication. Only minor modifications are made on the original codes so I think it should be fine. What I also did include changing the org/apache/catalina/startup/Authenticators.properties file to add the new authenticator; modifying the server.xml and web.xml accordingly. Furthermore, I added the entries for my authenticator and realm in the mbeans-descriptor.xml file. I expected everything to work perfectly but when I tried to access the secured area, I got the following error: HTTP Status 500 - Configuration error: Cannot perform access control without an authenticated principal - type Status report message Configuration error: Cannot perform access control without an authenticated principal description The server encountered an internal error (Configuration error: Cannot perform access control without an authenticated principal) that prevented it from fulfilling this request. This error was triggered instantly. I mean I even did not have a chance to see the login webpage. Now I have several questions: What is the flow of the authentication? Was my authenticator got executed at all? Any suggestions would be greatly appreciated. Charles - Do you Yahoo!? The New Yahoo! Shopping - with improved product search
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java
Jan Luehe wrote: Remy, sorry, but I don't see which part of our email exchange you found very frustrating. As I said, I'm open to suggestions, and if my patch is deemed useless, I'll revert it. No problem. [...] Sorry for not jumping in earlier in this discussion. When I implemented the shared tag libraries feature in LiteWebServer, I added scanning of JAR files in just /shared/lib. I do _not_ scan JAR files in common/lib and server/lib, because placing shared tag libraries there would be point-less; the container doesn't need access to them, only the applications do, which is what shared/lib is for. Maybe that cuts down the list enough so you don't have to mess with an exclusion list at all? Hans -- Hans Bergsten[EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com/ Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0 Details athttp://TheJSPBook.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CoyoteRequest assumption that breaks UTF-8 support
Yes, in MY application I will do that. Namely, I will decide on one
type of encoding to use and pull the arguments out in that encoding
using getBytes(encType). That is the correct way of doing it.
What I am talking about is Tomcat's built-in container-managed
security. When you specify a security constraint of form-based login,
and have a form that submits to j_security_check, and let Tomcat handle
the details using one of its many Realms.
This IS a bug, or at least a severe limit in functionality. As far as
I can tell, there is no way to handle UTF-8 usernames and passwords
doing container-managed security. Once again, unless I'm missing some
way to tell the browser to send on the content-type to j_security_check.
I have thoroughly investigated that, and think that I'm indeed not
missing anything.
Jeff Tulley ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
[EMAIL PROTECTED] 9/25/03 12:09:02 PM
This is not a bug. Read http://asg.web.cmu.edu/rfc/rfc2070.html#sec-5.
Use this code:
String result = req.getParameter(parm);
if (result == null)
return null;
try
{
return new String(result.getBytes(ISO-8859-1),
UTF-8);
}
catch (UnsupportedEncodingException e)
{
return result;
}
Dave Oxley
[EMAIL PROTECTED]
-Original Message-
From: Jeff Tulley [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 6:40 PM
To: [EMAIL PROTECTED]
Subject: CoyoteRequest assumption that breaks UTF-8 support
I am convinced that Tomcat 4.x has a very real bug when dealing with
character encodings on login form submissions. (maybe elsewhere as
well).
To see what I am observing, watch the flow of code when doing a
login
from Tomcat's admin application. It sets the charset to UTF-8 in
the
tag
%@ page language=java contentType=text/html;charset=UTF-8
import=java.util.* % at the top of the file. This correctly
gets
the browser into unicode mode, and (with all of the browsers I have
tested - IE and NS 7 on windows, and Konqueror on SUSE Linux), they
correctly encode your username / password in UTF-8.
But, in CoyoteRequest, parseRequestParameters(), Tomcat tries to
determine and set the encoding to be used and ends up setting it to
be
null. Why? It looks like in Request.getCharacterEncoding and
subordinate methods, the header value, content-type is checked.
On
all of the browsers that I have checked if this value is set at all,
it
is simply set to application/x-www-form-urlencoded, without mention
of
UTF-8 or any other charset. The browser assumes that since you
requested a certain charset in the first place, that you know how to
deal with a parameter that is sent on encoded in that charset.
Tomcat sees no mention of charsets, so it simply defaults to
ISO-8859-1 (hardcoded constant)
Is there a better way to tie the default value to whatever the JSP
login form originally requested, or even, failing that, can we look
up
the system property, file.encoding, and require it to be passed in
on
startup. This is less than ideal though. Preferrably it would be
something settable context-wide, not tomcat-wide.
Where does this leave applications that wish to support extended
characters in passwords and/or usernames, characters that may not be
in
the ISO-8859-1 range?
Or am I missing the correct place to set this?
Jeff Tulley ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a
proactive
anti-virus service working around the clock, around the globe,
visit:
http://www.star.net.uk
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23311] - Connections to tomcat left in CLOSE_WAIT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23311. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23311 Connections to tomcat left in CLOSE_WAIT --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 19:55 --- Tomcat has just hanged after 10 days. I've taken netstat threaddump in 2 steps: 1) at the time after hang... 2) ...then connect a browser and check again with netstat threaddump. Starting tomcat _(no -Xms/-Xmx options)_, a snippet from 'ps -efHl': java -Djava.awt.headless=true -Djava.endorsed.dirs=/usr/tomcat/common/endorsed - classpath /usr/java/j2sdk1.4.2/lib/tools.jar:/usr/tomcat/bin/bootstrap.jar - Dcatalina.base=/usr/tomcat -Dcatalina.home=/usr/tomcat -Dja BEFORE CONNECTING A CLIENT -- [EMAIL PROTECTED] root]# netstat -a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 *:1024 *:* LISTEN tcp0 0 mimmi.localdomain:1025 *:* LISTEN tcp0 0 mimmi.localdomain:8005 *:* LISTEN tcp0 0 *:8009 *:* LISTEN tcp0 0 *:netbios-ssn *:* LISTEN tcp0 0 *:sunrpc*:* LISTEN tcp0 0 *:http *:* LISTEN tcp0 0 *:x11 *:* LISTEN tcp0 0 *:ssh *:* LISTEN tcp0 0 *:ipp *:* LISTEN tcp0 0 10.0.0.6:ssh10.0.0.9:1115 ESTABLISHED tcp 298 0 10.0.0.6:http ses.grsc.k12.ar.u:57445 ESTABLISHED tcp0 0 10.0.0.6:http 11.80-203-235.nex:49333 ESTABLISHED tcp0 0 10.0.0.6:netbios-ssn10.0.0.9:1031 ESTABLISHED tcp1 0 mimmi.localdomain:1134 mimmi.localdomain:mysql CLOSE_WAIT tcp 380 0 10.0.0.6:http 11.80-203-235.nex:57746 ESTABLISHED udp0 0 *:1024 *:* udp0 0 10.0.0.6:netbios-ns *:* udp0 0 *:netbios-ns*:* udp0 0 10.0.0.6:netbios-dgm*:* udp0 0 *:netbios-dgm *:* udp0 0 mimmi.localdomain:1040 *:* udp0 0 *:918 *:* udp0 0 *:bootpc*:* udp0 0 *:sunrpc*:* udp0 0 *:631 *:* Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node Path unix 2 [ ACC ] STREAM LISTENING 2155 /dev/gpmctl unix 2 [ ACC ] STREAM LISTENING 2499 /tmp/.gdm_socket unix 9 [ ] DGRAM1638 /dev/log unix 2 [ ACC ] STREAM LISTENING 2348 /tmp/.font-unix/fs7100 unix 2 [ ACC ] STREAM LISTENING 2163 /tmp/.iroha_unix/IROHA unix 2 [ ACC ] STREAM LISTENING 2512 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2559 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2558 unix 3 [ ] STREAM CONNECTED 2554 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2553 unix 3 [ ] STREAM CONNECTED 2537 /tmp/.font-unix/fs7100 unix 3 [ ] STREAM CONNECTED 2536 unix 3 [ ] STREAM CONNECTED 2539 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2515 unix 2 [ ] DGRAM2435 unix 2 [ ] DGRAM2359 unix 2 [ ] DGRAM2188 unix 2 [ ] DGRAM2120 unix 2 [ ] DGRAM1859 unix 2 [ ] DGRAM1699 unix 2 [ ] DGRAM1649 Thread dump --- Full thread dump Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode): TP-Processor16 daemon prio=1 tid=0x08488560 nid=0x707 in Object.wait() [4f014000..4f014714] at java.lang.Object.wait(Native Method) - waiting on 0x45510990 (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Object.wait(Object.java:429) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:644) - locked 0x45510990 (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Thread.run(Thread.java:534) TP-Processor15 daemon prio=1 tid=0x084879a8 nid=0x707 in Object.wait()
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java
Hans, thanks for stepping in. sorry, but I don't see which part of our email exchange you found very frustrating. As I said, I'm open to suggestions, and if my patch is deemed useless, I'll revert it. No problem. [...] Sorry for not jumping in earlier in this discussion. When I implemented the shared tag libraries feature in LiteWebServer, I added scanning of JAR files in just /shared/lib. I do _not_ scan JAR files in common/lib and server/lib, because placing shared tag libraries there would be point-less; the container doesn't need access to them, only the applications do, which is what shared/lib is for. Maybe that cuts down the list enough so you don't have to mess with an exclusion list at all? good point. What about environments that embed Tomcat without following Tomcat's directory layout, and in which the classloader hierachy/depth is different from that in Tomcat? Jan Hans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15576] - IllegalArgumentException during adding a cookie
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15576. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15576 IllegalArgumentException during adding a cookie --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 20:42 --- As of today, running Tomcat 4.0.27, it's still broken. Using the cookie servlet test application in Tomcat, that it fails when either a comma or a semicolon is put into either the cookie name or cookie value. According to the sun documentation for the servlet class found at http://java.sun.com/products/servlet/2.1/api/javax.servlet.http.Cookie.html the characters comma, semicolon, and white space are not allowed in the name field. It also recommends that they not be used in the value field, but does not actually prohibit their use. Testing also showed that the white space characters are allowed in the name field, but will create problems when the cookie is later retrieved. Perhaps this should just be closed as that's how it works Harold - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java
Jan Luehe wrote: Hans, thanks for stepping in. sorry, but I don't see which part of our email exchange you found very frustrating. As I said, I'm open to suggestions, and if my patch is deemed useless, I'll revert it. No problem. [...] Sorry for not jumping in earlier in this discussion. When I implemented the shared tag libraries feature in LiteWebServer, I added scanning of JAR files in just /shared/lib. I do _not_ scan JAR files in common/lib and server/lib, because placing shared tag libraries there would be point-less; the container doesn't need access to them, only the applications do, which is what shared/lib is for. Maybe that cuts down the list enough so you don't have to mess with an exclusion list at all? good point. What about environments that embed Tomcat without following Tomcat's directory layout, and in which the classloader hierachy/depth is different from that in Tomcat? I don't give them that option (with regards to this) in LiteWebServer. The only place I look for shared libraries is $CATALINA_HOME/shared/lib. Is that really a severe limitation, you think? Hans -- Hans Bergsten[EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com/ Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0 Details athttp://TheJSPBook.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] jakarta-servletapi-5: Update to j2ee_1_4.xsd
Attached is a patch to update the J2EE 1.4 schema. jsr154/src/share/dtd/j2ee_1_4.xsd - clarify that fully-qualified-classType is a binary name --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. Index: jsr154/src/share/dtd/j2ee_1_4.xsd === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr154/src/share/dtd/j2ee_1_4.xsd,v retrieving revision 1.9 diff -u -r1.9 j2ee_1_4.xsd --- jsr154/src/share/dtd/j2ee_1_4.xsd 18 Aug 2003 17:41:20 - 1.9 +++ jsr154/src/share/dtd/j2ee_1_4.xsd 25 Sep 2003 21:42:48 - @@ -8,7 +8,7 @@ version=1.4 xsd:annotation xsd:documentation - @(#)j2ee_1_4.xsds1.42 03/08/01 + @(#)j2ee_1_4.xsds1.43 03/09/16 /xsd:documentation /xsd:annotation @@ -497,7 +497,11 @@ xsd:documentation The elements that use this type designate the name of a - Java class or interface. + Java class or interface. The name is in the form of a + binary name, as defined in the JLS. This is the form + of name used in Class.forName(). Tools that need the + canonical name (the name used in source code) will need + to convert this binary name to the canonical name. /xsd:documentation /xsd:annotation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23425] New: - Invalid scoping of variables exported from TEI classes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23425.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23425
Invalid scoping of variables exported from TEI classes
Summary: Invalid scoping of variables exported from TEI classes
Product: Tomcat 4
Version: 4.1.24
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I believe there is a scoping issue with Jasper with respect to variables
exported from TEI implementations. Specifically I am using the Struts define
tag, which exports a variable marked as VariableInfo.AT_END. Which according
to the Spec:
•AT_END, if the scripting variable is available after the end tag of the action
that defines it until the end of the scope.
However, in the scenario where the tag is used in 2 seperate scopes (within an
if/else) the variable is not redefined in the second scope. I believe that
according to spec the second scope should recieve a new declaration of the
exported var.
I have included only examples of the problem and can provide more detail if the
following does not sufficiently explain.
Example JSP -
%if (some boolean){%
struts:define id=varName ./
..
%}else{%
struts:define id=varName ./
..
%}%
JSP compilation will fail in this scenario as the Jasper output would look
something like:
if(same boolean value) {
/* bean:define */
org.apache.struts.taglib.bean.DefineTag _jspx_th_bean_define_0 = new
org.apache.struts.taglib.bean.DefineTag();
_jspx_th_bean_define_0.setPageContext(pageContext);
_jspx_th_bean_define_0.setParent(_jspx_parent tag);
_jspx_th_bean_define_0.setId(varName);
_jspx_th_bean_define_0.setName(...);
_jspx_th_bean_define_0.setProperty(...);
_jspx_th_bean_define_0.setType(java.lang.String);
int _jspx_eval_bean_define_0 = _jspx_th_bean_define_0.doStartTag();
if (_jspx_th_bean_define_0.doEndTag() ==
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;
java.lang.String propertyname = null;
propertyname = (java.lang.String) pageContext.findAttribute
(varName);
..
} else {
/* bean:define */
org.apache.struts.taglib.bean.DefineTag _jspx_th_bean_define_1 = new
org.apache.struts.taglib.bean.DefineTag();
_jspx_th_bean_define_1.setPageContext(pageContext);
_jspx_th_bean_define_1.setParent(_jspx_parent tag);
_jspx_th_bean_define_1.setId(varName);
_jspx_th_bean_define_1.setName(...);
_jspx_th_bean_define_1.setProperty(...);
_jspx_th_bean_define_1.setType(java.lang.String);
int _jspx_eval_bean_define_1 = _jspx_th_bean_define_1.doStartTag();
if (_jspx_th_bean_define_1.doEndTag() ==
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;
propertyname = (java.lang.String) pageContext.findAttribute
(varName); //compilation fails here//
...
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-servletapi-5/jsr154/src/share/dtd j2ee_1_4.xsd
kinman 2003/09/25 15:33:18 Modified:jsr154/src/share/dtd j2ee_1_4.xsd Log: Patch by Mark Roth: - update the J2EE 1.4 schema jsr154/src/share/dtd/j2ee_1_4.xsd to clarify that fully-qualified-classType is a binary name Revision ChangesPath 1.10 +6 -2 jakarta-servletapi-5/jsr154/src/share/dtd/j2ee_1_4.xsd Index: j2ee_1_4.xsd === RCS file: /home/cvs/jakarta-servletapi-5/jsr154/src/share/dtd/j2ee_1_4.xsd,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- j2ee_1_4.xsd 18 Aug 2003 17:41:20 - 1.9 +++ j2ee_1_4.xsd 25 Sep 2003 22:33:18 - 1.10 @@ -8,7 +8,7 @@ version=1.4 xsd:annotation xsd:documentation - @(#)j2ee_1_4.xsds 1.42 03/08/01 + @(#)j2ee_1_4.xsds 1.43 03/09/16 /xsd:documentation /xsd:annotation @@ -497,7 +497,11 @@ xsd:documentation The elements that use this type designate the name of a - Java class or interface. + Java class or interface. The name is in the form of a + binary name, as defined in the JLS. This is the form + of name used in Class.forName(). Tools that need the + canonical name (the name used in source code) will need + to convert this binary name to the canonical name. /xsd:documentation /xsd:annotation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java
Hans, good point. What about environments that embed Tomcat without following Tomcat's directory layout, and in which the classloader hierachy/depth is different from that in Tomcat? I don't give them that option (with regards to this) in LiteWebServer. The only place I look for shared libraries is $CATALINA_HOME/shared/lib. Is that really a severe limitation, you think? I think it depends on whether you anticipate (or support) LiteWebServer being bundled (as one or more libraries) into other products that use a different directory layout, with different locations for shared libs. If that's the case, limiting the location of shared libs to $CATALINA_HOME/shared/lib might be too restrictive. That's why Tomcat searches the webapp's classloader delegation chain for JARs, which ensures that it will find shared libs regardless of their location. Of course, by searching the classloader chain all the way up, we end up parsing too many JARs. I think it's impossible to know ahead of time where to stop in the chain, until you've actually traversed the entire chain. For example, an approach that walks the chain just two levels up won't work in environments where the classloaders 3 or 4 levels up in the chain are also responsible for loading shared libs. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23428] New: - servlet-mapping invoker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23428. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23428 servlet-mapping invoker Summary: servlet-mapping invoker Product: Tomcat 5 Version: 5.0.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello there, I noticed that uncommenting the servlet mapping servlet-mapping servlet-nameinvoker/servlet-name url-pattern/servlet/*/url-pattern /servlet-mapping which should be a security breach, makes Tomcat crash. This is the whole log i get. No erros on stderr.log though. If i'm being stupid you have my sinecere apologies. Thanks, George Sep 26, 2003 4:17:56 AM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on port 8080 Sep 26, 2003 4:17:56 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 6118 ms Sep 26, 2003 4:17:57 AM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Sep 26, 2003 4:17:57 AM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.0.12 Sep 26, 2003 4:17:58 AM org.apache.commons.digester.Digester endElement SEVERE: End event threw exception java.lang.reflect.InvocationTargetException 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.commons.beanutils.MethodUtils.invokeMethod (MethodUtils.java:252) at org.apache.commons.digester.CallMethodRule.end (CallMethodRule.java:505) at org.apache.commons.digester.Rule.end(Rule.java:276) at org.apache.commons.digester.Digester.endElement(Digester.java:1058) at org.apache.xerces.parsers.AbstractSAXParser.endElement (AbstractSAXParser.java:585) at org.apache.xerces.impl.XMLNamespaceBinder.endElement (XMLNamespaceBinder.java:647) at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement (XMLDTDValidator.java:1937) at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement (XMLDTDValidator.java:851) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement (XMLDocumentFragmentScannerImpl.java:1008) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher. dispatch(XMLDocumentFragmentScannerImpl.java:1469) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument (XMLDocumentFragmentScannerImpl.java:329) at org.apache.xerces.parsers.DTDConfiguration.parse (DTDConfiguration.java:525) at org.apache.xerces.parsers.DTDConfiguration.parse (DTDConfiguration.java:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse (AbstractSAXParser.java:1175) at org.apache.commons.digester.Digester.parse(Digester.java:1548) at org.apache.catalina.startup.ContextConfig.defaultConfig (ContextConfig.java:596) at org.apache.catalina.startup.ContextConfig.start (ContextConfig.java:728) at org.apache.catalina.startup.ContextConfig.lifecycleEvent (ContextConfig.java:257) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent (LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start (StandardContext.java:4073) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1125) at org.apache.catalina.core.StandardHost.start(StandardHost.java:792) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1125) at org.apache.catalina.core.StandardEngine.start (StandardEngine.java:502) at org.apache.catalina.core.StandardService.start (StandardService.java:519) at org.apache.catalina.core.StandardServer.start (StandardServer.java:2343) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) 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:295) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:392) Caused by: java.lang.IllegalArgumentException: Servlet mapping specifies an unknown servlet name invoker at
DO NOT REPLY [Bug 23428] - servlet-mapping invoker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23428. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23428 servlet-mapping invoker [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-09-26 01:25 --- There are 2 things to uncomment. The invoker declaration and its mapping. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23429] New: - isCompressable always false when charset is specified in Content-Type
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23429. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23429 isCompressable always false when charset is specified in Content-Type Summary: isCompressable always false when charset is specified in Content-Type Product: Tomcat 5 Version: 5.0.12 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] \org\apache\coyote\http11\Http11Processor.java return (inStringArray(compressableMimeTypes, response.getContentType())); - Problem: compression setting is ignored (isCompressable() == false) when a charset is specified in the Content-Type header. The check above for compressable mime types is an equals check. When the Content-Type contains a characterset, for example, by setting: response.setCharacterEncoding(UTF-8); The Content-Type header will *never* equal any of the given mime types because the Content-Type header will contain a charset field as well. Suggested remedy: Use startsWith instead of equals. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java
Jan Luehe wrote: Hans, good point. What about environments that embed Tomcat without following Tomcat's directory layout, and in which the classloader hierachy/depth is different from that in Tomcat? I don't give them that option (with regards to this) in LiteWebServer. The only place I look for shared libraries is $CATALINA_HOME/shared/lib. Is that really a severe limitation, you think? I think it depends on whether you anticipate (or support) LiteWebServer being bundled (as one or more libraries) into other products that use a different directory layout, with different locations for shared libs. If that's the case, limiting the location of shared libs to $CATALINA_HOME/shared/lib might be too restrictive. Your milage may wary, but no one embedding LiteWebServer (LWS) today has complained. I think sometimes too much flexibility is what makes a product hard to use. With LWS, I've stripped down Tomcat to the bare minimum and removed a lot of choices, and people seem to like how simple things get this way. That's why Tomcat searches the webapp's classloader delegation chain for JARs, which ensures that it will find shared libs regardless of their location. Of course, by searching the classloader chain all the way up, we end up parsing too many JARs. I think it's impossible to know ahead of time where to stop in the chain, until you've actually traversed the entire chain. For example, an approach that walks the chain just two levels up won't work in environments where the classloaders 3 or 4 levels up in the chain are also responsible for loading shared libs. Sure, if you can't restrict installation of shared tag libraries to a directory with a well-known name (off some configurable base, like CATALINA_HOME), you have no choice but to walk the chain. It's up to you to decide if it's worth it or not. I'm just piping in with an alternative that works fine for me and my users. Hans -- Hans Bergsten[EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com/ Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0 Details athttp://TheJSPBook.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers AccessLogInterceptor.java
billbarker2003/09/25 20:00:12
Modified:src/share/org/apache/tomcat/modules/loggers
AccessLogInterceptor.java
Log:
Log the content-length of the Response instead of the Request.
Reported By: Jens Schlatter [EMAIL PROTECTED]
Revision ChangesPath
1.10 +2 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers/AccessLogInterceptor.java
Index: AccessLogInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers/AccessLogInterceptor.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- AccessLogInterceptor.java 15 Jul 2003 06:03:18 - 1.9
+++ AccessLogInterceptor.java 26 Sep 2003 03:00:12 - 1.10
@@ -239,7 +239,8 @@
fw.write(request.protocol().toString().trim());
break;
case 'b':
- String cl = request.getHeader(Content-Length);
+ String cl = response.getMimeHeaders().
+getHeader(Content-Length);
if(cl != null) {
fw.write(cl);
} else {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt
billbarker2003/09/25 21:27:48 Modified:.RELEASE-NOTES-3.3.2.txt Log: Document change. Revision ChangesPath 1.20 +4 -1 jakarta-tomcat/RELEASE-NOTES-3.3.2.txt Index: RELEASE-NOTES-3.3.2.txt === RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.2.txt,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- RELEASE-NOTES-3.3.2.txt 14 Sep 2003 04:43:20 - 1.19 +++ RELEASE-NOTES-3.3.2.txt 26 Sep 2003 04:27:48 - 1.20 @@ -72,6 +72,9 @@ Updated DecodeInterceptor to treat URL paths containing null characters as unsafe. + Fix problem where the AccessLog was printing the content-length of the + Request instead of the Response. + Jasper: Bug No. Description - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat status
Hi, I want to know if there is any command line tool to get the status of tomcat. Thanks in advance. Lucas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23432] New: - org.apache.jasper.JasperException: Unable to compile class for JSP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23432. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23432 org.apache.jasper.JasperException: Unable to compile class for JSP Summary: org.apache.jasper.JasperException: Unable to compile class for JSP Product: Tomcat 4 Version: 4.1.27 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The page was displaying properly. Then I modified the class. Tomcat showed it relaoded successfully. After that when I hit the opage in which I have use this Bean it threw an exception that the package not found. I can mail you the Source code. I am using Tomcat 4.1.27 J2sdk1.4.2_01 Windows NT Workstation My application is running under another Host whos entries are. Host name=testaccess debug=0 appBase=D:\MyWorks\AutomaterFwdEngg\FwdEngg unpackWARs=true autoDeploy=true Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=testaccess. suffix=.txt timestamp=true/ Context path= docBase=D:\MyWorks\AutomaterFwdEngg\FwdEngg debug=0 reloadable=true / /Host HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: 3 in the jsp file: /bin/common.inc Generated servlet error: [javac] Compiling 1 source file D:\Apache\Tomcat4.1\temp\index_jsp.java:48: package com does not exist com.ConnectionBean dbConnect = null; ^ An error occurred at line: 3 in the jsp file: /bin/common.inc Generated servlet error: D:\Apache\Tomcat4.1\temp\index_jsp.java:50: package com does not exist dbConnect = (com.ConnectionBean) pageContext.getAttribute(dbConnect, PageContext.REQUEST_SCOPE); ^ An error occurred at line: 3 in the jsp file: /bin/common.inc Generated servlet error: D:\Apache\Tomcat4.1\temp\index_jsp.java:53: package com does not exist dbConnect = (com.ConnectionBean) java.beans.Beans.instantiate (this.getClass().getClassLoader(), com.ConnectionBean); ^ 3 errors at org.apache.jasper.compiler.DefaultErrorHandler.javacError (DefaultErrorHandler.java:130) at org.apache.jasper.compiler.ErrorDispatcher.javacError (ErrorDispatcher.java:293) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:353) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:370) at org.apache.jasper.JspCompilationContext.compile (JspCompilationContext.java:473) at org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:190) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke (StandardContext.java:2416) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke (ErrorDispatcherValve.java:171) at
DO NOT REPLY [Bug 23432] - org.apache.jasper.JasperException: Unable to compile class for JSP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23432. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23432 org.apache.jasper.JasperException: Unable to compile class for JSP --- Additional Comments From [EMAIL PROTECTED] 2003-09-26 06:02 --- Also after restarting the Tomcat the same page is displayed fine without any error. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT]: Tomcat Service Manager for Windows 1.0.0
http://www.daveoxley.co.uk/tcsm tcsm is a Service Manager for Tomcat that looks and works in a similar way to the MS SQL Server Service Manager. Enjoy. Dave. [EMAIL PROTECTED] This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk
