RE: cvs commit: jakarta-servletapi-5/jsr152/examples/tagplugin choose.html choose.jsp foreach.html foreach.jsp howto.html if.html if.jsp notes.html
1.1 jakarta-servletapi-5/jsr152/examples/tagplugin/howto.html Index: howto.html === html head titleTag Plugin Implementation/title h2How to write tag plugins/h2 p To write a plugin, you'll need to download the source for Tomcat 5. There are two steps: ol li Implement the plugin class.p/ This class, which implements ttorg.apache.jasper.compiler.tagplugin.Plugin/tt I guess org.apache.jasper.compiler.tagplugin.TagPlugin is correct. Ias = Lee, Changshin (Korean name) Ias (International name) Company Web Site: http://www.tmax.co.kr Personal Web Site: http://www.iasandcb.pe.kr - JSR 201, 204, 222 and 224 EG member Apache Axis (JAX-RPC and SAAJ) and JaxMe (JAXB) committer RD Center Tmax Soft, Inc. = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
NormW wrote:
Good morning All.
The default 'worker', which is hard-wired into Mod_Jk2, is 'lb:lb', and
is, for most users I believe, a wrong guess at best, since the majority of
users are probably not using mod_jk2 in load-balancing mode. The 'guess'
means that mod_jk2 creates uri objects assigned to either a load-balancer
that doesn't exist , a load-balancer that is not hooked into anything or a
load-balancer that is not even wanted. For example, the following uri's
are created automatically:
:-)
I agree that lb is a missleading name, as is the whole worker concept.
The real intent is for lb to represent one tomcat cluster ( of one or
many servers ), and for routing to be directed to different clusters
instead of individual machines.
Even if you have a single tomcat - I think it is still better to make the
mapping based on the tomcat instance, and not on the various protocols used
to connect.
The overhead of having lb is very small, and IMO it's well worth it given
the simplification in code and the extra features.
I also think the right direction is to decouple the worker ( as a
particular protcol to connect to a tomcat instance ) from the notion of
routing requests to a particular instance or cluster, which may use multipe
protocols and workers.
nameurigroup context
* null null null
*// lb:lb /
There is no means to determine the existence of the 'lb:lb' worker, but
suffice to say, my setup doesn't want or need it anyway. (As an aside,
perhaps this might be an extension to /jkstatus/ ?)
I think the code created the lb:lb automatically unless one is defined
exeplicitely. The goal was to have each tomcat instance ( or cluster )
associated with an lb, with a reasonable default to minimize trivial
configuration.
Then each lb would have one or multiple protocols pointing at different
tomcat instances.
A more valid approach would be to identify, via the workers2.properties
file, which worker of those configured is to be considered the 'default'.
It would also become the 'default' worker/group for [uri] sections not
having a worker/group entry when created, and a variation of the JkUriSet
parameter could also allow use of the 'default' worker, for example:
JkUriSet worker default
The existing code makes allowance for a defaultWorker property in the
[workerEnv] section of memory, and I would like to submit the attached
[patch
as a step in such an arrangement. If this option isn't used within the
workers2.properties file, then the module reverts to current operation.
The parameter proposed would look as follows and retain the current
default for wEnv-defaultWorker:
I'm not very comfortable with this ( I'm close to -1, but if other people
think it's a good idea I can change it to -0).
It kinds of moves us backwards, to the mess of protocols and load balancers.
I'm ok with any renaming or clarification or defaults - as long as we keep
or increase the current separation between protocols ( i.e. ajp-like
workers ) and clusters/instances - or however you want to call the
lb-like workers.
All mapping should be made between URIs and lb ( clusters/instances ), and
each lb can have multiple protocols ( ajp ) associated. It would be great
if we just create a separate interface to make it clear that those are
distinct.
Costin
[workerEnv]
defaultWorker=workerName
For your consideration and comment,
Norm
--- jk_workerEnv.c.orig Fri Sep 26 07:00:51 2003
+++ jk_workerEnv.c Thu Feb 5 18:36:39 2004
@@ -93,6 +93,8 @@
wEnv-ssl_enable = JK_TRUE;
} else if( strcmp( name, timing )==0 ) {
wEnv-timing= atoi( value );
+} else if( strcmp( name, defaultWorker )==0 ) {
+wEnv-defaultWorker = value ;
} else if( strcmp( name, httpsIndicator )==0 ) {
wEnv-https_indicator = value;
} else if( strcmp( name, certsIndicator )==0 ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX remote and JDK 1.5
Remy Maucherat wrote: Hi, It looks like the new JDK has an easy way to add a connector (and even SNMP) to a VM, without the need for explicit support in the application, using system properties (on the command line) like: - com.sun.management.config.file - com.sun.management.snmp.port - com.sun.management.jmxremote.port I expect other vendors will provide a similar feature :) As a result, there's no need to reinvent the wheel inside Tomcat, and I'm shelving my plans to add a listener to instantiate JMX remote (no need to add complexity), and will unbundle JMX remote (only the JMX RI core will be bundled); instead, I'll add a little chapter about JMX in the docs :) What does it mean ? I saw the 1.5 jmx stuff, but as usual this only works with 1.5 while most people will keep using 1.3 or 1.4 for few years. I hope we're not falling into the forced upgrade trap :-) I agree that tomcat should't reinvent the wheel - but provide some mechanism for 1.4, maybe similar ( or identical ) with what 1.5 provides. This would also allow people with 1.3 or 1.4 to enjoy JMX now. Costin With this JDK, JMX remote powered clients are going to become a standard almost instantly, since the only requirement is that the server is instrumented though JMX. So good job to the J2SE team, this doesn't seem beta (although they didn't test JBoss, it doesn't work right now, as a side effect of bundling JMX :-( ). On the performance side, my (client) VM seems as fast as JDK 1.4.2, but does seem to use a little bit less memory. So unless it turns out to be really unstable (it does seem better than almost all the other Sun JDKs I've tried, so far), final 1.5.0 should be really successful when it's released. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX remote and JDK 1.5
[EMAIL PROTECTED] wrote: Remy Maucherat wrote: What does it mean ? I saw the 1.5 jmx stuff, but as usual this only works with 1.5 while most people will keep using 1.3 or 1.4 for few years. I hope we're not falling into the forced upgrade trap :-) I agree in general. However, I've played with the beta, and it basically feels like 1.4.3, with the added language features. I didn't test the stability in production, of course, but it looks good so far. I do not think we'll end up in a situation like with Java 1.4 when: - coders didn't want to use the new APIs since they weren't stable and tested (NIO) - people didn't want to upgrade as the JVM itself wasn't stable I agree that tomcat should't reinvent the wheel - but provide some mechanism for 1.4, maybe similar ( or identical ) with what 1.5 provides. This would also allow people with 1.3 or 1.4 to enjoy JMX now. I'm talking about JMX remote here. AFAIK, no clients support it right now. JDK 1.5 will make it a standard in a hurry, given that you don't have to configure or add anything in the application itself. Given that there's already support for the other JMX remoting connectors in Tomcat, I don't see the need to add something which will only become used once JDK 1.5 is out. Now, if someone feels like adding it, I won't complain, but I won't do it myself ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/support jk_apxs.m4
hgomez 2004/02/06 00:37:08
Modified:jk/support jk_apxs.m4
Log:
Get APR/APR_UTILS include path
Revision ChangesPath
1.11 +3 -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.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- jk_apxs.m45 Feb 2004 17:13:54 - 1.10
+++ jk_apxs.m46 Feb 2004 08:37:08 - 1.11
@@ -139,7 +139,8 @@
HAS_APR=-DHAS_APR
APXS$1_CFLAGS=`${APXS$1} -q CFLAGS` `${APXS$1} -q EXTRA_CFLAGS`
APXS$1_CPPFLAGS=`${APXS$1} -q EXTRA_CPPFLAGS`
- APR_INCDIR=`${APXS$1} -q APR_INCLUDE`
+ APR_INCDIR=`${APXS$1} -q APR_INCLUDEDIR`
+ APR_UTIL_INCDIR=`${APXS$1} -q APU_INCLUDEDIR`
LIBTOOL=`${APXS$1} -q LIBTOOL`
fi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c
hgomez 2004/02/06 00:37:46
Modified:jk/native/common jk_ajp_common.c
Log:
More info to track the potential problem in POST recovery
Revision ChangesPath
1.46 +16 -9 jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
Index: jk_ajp_common.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- jk_ajp_common.c 25 Jan 2004 23:51:41 - 1.45
+++ jk_ajp_common.c 6 Feb 2004 08:37:46 - 1.46
@@ -1007,6 +1007,7 @@
ajp_operation_t *op)
{
int err = 0;
+ int postlen;
/* Up to now, we can recover */
op-recoverable = JK_TRUE;
@@ -1074,18 +1075,23 @@
ae-left_bytes_to_send, jk_b_get_len(op-reply) - AJP_HEADER_LEN);
/*
- * POST recovery job is done here.
- * It's not very fine to have posted data in reply but that's the only easy
- * way to do that for now. Sharing the reply is really a bad solution but
- * it will works for POST DATA less than 8k.
+ * POST recovery job is done here and will work when data to
+ * POST are less than 8k, since it's the maximum size of op-post buffer.
* We send here the first part of data which was sent previously to the
* remote Tomcat
*/
-if (jk_b_get_len(op-post) AJP_HEADER_LEN) {
+
+/* Did we have something to resend (ie the op-post has been feeded previously */
+
+postlen = jk_b_get_len(op-post);
+if (postlen AJP_HEADER_LEN) {
if(!ajp_connection_tcp_send_message(ae, op-post, l)) {
-jk_log(l, JK_LOG_ERROR, Error resending request body\n);
+jk_log(l, JK_LOG_ERROR, Error resending request body (%d)\n, postlen);
return JK_FALSE;
}
+else
+ jk_log(l, JK_LOG_DEBUG, Resent the request body (%d)\n, postlen);
+
}
else {
/* We never sent any POST data and we check if we have to send at
@@ -1096,7 +1102,7 @@
/* || s-is_chunked - this can't be done here. The original protocol
sends the first chunk of post data ( based on Content-Length ),
and that's what the java side expects.
-Sending this data for chunked would break other ajp13 serers.
+Sending this data for chunked would break other ajp13 servers.
Note that chunking will continue to work - using the normal read.
*/
@@ -1185,6 +1191,7 @@
jk_log(l, JK_LOG_INFO,
ERROR reading POST data from client.
Connection aborted or network problems\n);
+
return JK_CLIENT_ERROR;
}
break;
@@ -1439,7 +1446,7 @@
p-worker-name, errno);
} else {
-jk_log(l, JK_LOG_ERROR, In jk_endpoint_t::service, NULL parameters\n);
+jk_log(l, JK_LOG_ERROR, ajp: end of service with error\n);
}
return JK_FALSE;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c
hgomez 2004/02/06 00:37:59
Modified:jk/native/common jk_lb_worker.c
Log:
Comment end of LB service
Revision ChangesPath
1.15 +3 -3 jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
Index: jk_lb_worker.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- jk_lb_worker.c5 Nov 2003 09:15:39 - 1.14
+++ jk_lb_worker.c6 Feb 2004 08:37:59 - 1.15
@@ -372,7 +372,7 @@
* another worker... Lets try to do that.
*/
jk_log(l, JK_LOG_DEBUG,
-In jk_endpoint_t::service, recoverable error... will try
to recover on other host\n);
+lb: recoverable error... will try to recover on other
host\n);
} else {
/* NULL record, no more workers left ... */
jk_log(l, JK_LOG_ERROR,
@@ -384,7 +384,7 @@
}
jk_log(l, JK_LOG_ERROR,
- In jk_endpoint_t::service: NULL Parameters\n);
+ lb: end of service with error\n);
return JK_FALSE;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/support jk_apxs.m4
hgomez 2004/02/06 00:53:52
Modified:jk/support jk_apxs.m4
Log:
Fix build for include in APR/APR_UTILS
Revision ChangesPath
1.12 +3 -3 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.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- jk_apxs.m46 Feb 2004 08:37:08 - 1.11
+++ jk_apxs.m46 Feb 2004 08:53:52 - 1.12
@@ -139,8 +139,8 @@
HAS_APR=-DHAS_APR
APXS$1_CFLAGS=`${APXS$1} -q CFLAGS` `${APXS$1} -q EXTRA_CFLAGS`
APXS$1_CPPFLAGS=`${APXS$1} -q EXTRA_CPPFLAGS`
- APR_INCDIR=`${APXS$1} -q APR_INCLUDEDIR`
- APR_UTIL_INCDIR=`${APXS$1} -q APU_INCLUDEDIR`
+ APR_INCDIR=-I`${APXS$1} -q APR_INCLUDEDIR`
+ APR_UTIL_INCDIR=-I`${APXS$1} -q APU_INCLUDEDIR`
LIBTOOL=`${APXS$1} -q LIBTOOL`
fi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 Makefile.in
jfclere 2004/02/06 01:10:40
Modified:jk/native2/server/apache2 Makefile.in
Log:
Remove the cp because it is already in the MOD_INSTALL.
Revision ChangesPath
1.16 +2 -2 jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile.in,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- Makefile.in 5 Feb 2004 17:40:22 - 1.15
+++ Makefile.in 6 Feb 2004 09:10:40 - 1.16
@@ -97,9 +97,9 @@
all: prepare ${BUILD_DIR}/mod_jk2.so ${BUILD_DIR}/libjkjni.so
${BUILD_DIR}/mod_jk2.so: ${BUILD_DIR}/mod_jk2.la
- $(MOD_INSTALL) cp $^ `pwd`/${BUILD_DIR}
+ $(MOD_INSTALL) $^ `pwd`/${BUILD_DIR}
${BUILD_DIR}/libjkjni.so: ${BUILD_DIR}/libjkjni.la
- $(MOD_INSTALL) cp $^ `pwd`/${BUILD_DIR}
+ $(MOD_INSTALL) $^ `pwd`/${BUILD_DIR}
${BUILD_DIR}/libjkjni.la: ${JNI_LO_FILES} ${COMMON_LO_FILES}
$(MOD_LINK) -o $@ $(JK_LDFLAGS) $^
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: failover-problem and session mixup: jakarta-tomcat-connectors/mod_jk: jk_ajp_common.c
Alexander Schwartz a écrit : Hello Henri, hello mod_jk-Developers, Am Di, den 27.01.2004 schrieb Henri Gomez um 18:00: we are currently experiencing some problems with mod_jk with loadbalancing: (A) when a post-request fails while receiving data from tomcat, the loadbalancer tries to send the request to the other tomcat, but forgets the post body content (i.e. login and password submitted by the user). The size of the body content is only a few bytes ( 100), so it's not the known problem with bodies longer than 8k. (B) it seems that sometimes after a POST-failover body data from an old request is sent to the other tomcat when the first connection failed. This leads to a session mix-up user mix-up! Could you try with the latest code from CVS, since your patch seems to be for an older version ? From what I see in the code the datas in op-post are sent to the new tomcat so I don't see where can be the problem. I'd like to see test case and dumps. In fact we may have to rewrite the ajp_service(): 1) Init Buffers request, post, reply. 2) Feed request buffer and if needed post buffer. 3) Iterate here : 4) Try to send request and if needed post datas to a tomcat. 5) Swith to another tomcat and retry. A problem in such case is that if there is many POST datas we'll have a HUGE POST buffer and that datas won't be send to tomcat immediatly. So a consensus should be found here : - Make the web-server buffering the request/post, and then send to tomcat's. - Keep the current behaviour, where jk feed the data to tomcat as soon as he get them. I also wonder why the tomcat failed since using the prepost_timeout ping/pong could help you there. Questions : - Did Tomcat failed while handling the request or was allready broken before ? - Did you clients used chunked transfert ? - You say that sometimes after a POST-failover body data from an old request is sent to the other tomcat when the first connection failed. Do you means that the other tomcat get POST DATA which was never sent by the browser in this request ? Strange since the op-post is reset each time we service a new request. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: failover-problem and session mixup: jakarta-tomcat-connectors/mod_jk: jk_ajp_common.c
Alexander Schwartz a écrit : I'd really like to use mod_jk open source software in our production environment, but I need to make sure it's strong enough for production. I need some advice on the two issues (as far as I can see there has been no commit on CVS and/or discussion results) * do you think the POST-recovery caused the session mix-up? * does our patch successfully eliminate the problem by disabling POST-recovery? I'd like to see this recovery fixed instead of removing it. but I need something working now :( -- thefore I asked if my code is a working, although i know it is not perfect seen with your eyes. The idea is to use buffers to store request datas (headers/datas). OK, understood. What's the exact problem. You send request (headers / datas) to tomcat1. This one fail when sending reply or didn't reply at all ? I don't know when the session mix up happens, and I was unable to reproduce it. But I was to reproduce the following: (a) mod_jk sends the request and data to tomcat1. Tomcat1 closes the connection. mod_jk tries to recover and sends the request with no data to the second tomcat. Sending no data is definitely wrong. I also argue that this is dangerous as a transaction may be triggered twice by sending the request a second time. Could you send a complete mod_jk.log in DEBUG mode ? Use netcat (nc -l -p 8080) to simulate a tomcat1 on port 8080 receiving the headers. Press ^C to simulate the failure of tomcat1. Use a real tomcat2 for failover. netcat should handle AJP13, not HTTP, so it should be 8009. (b) mod_jk sends the request and data to tomcat1. mod_jk receives header and data from tomcat, but the response is not yet complete. tomcat1 closes the connection. mod_jk tries to recover and sends the request with no data to the second tomcat. The output of the second tomcat is appended to the output of the first tomcat. This is definitely wrong. Strange, also I need a complete mod_jk.log for study. I used the attached filter to set up a test case for this. Use two tomcats, and shut down the first tomcat when it is processing its request. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 release plan
[EMAIL PROTECTED] a écrit : -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Subject: jk2 2.0.4 release plan Comments welcome I can throw some tests at the build given some notice if that is any help. Thanks for picking this up. Thanks, we're working with JFC to clean the build :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2 buildconf.sh README.txt
jfclere 2004/02/06 01:43:06 Modified:jk/native2 buildconf.sh README.txt Log: Remove the automake cache. And adjust README to the buildconf.sh location. Revision ChangesPath 1.8 +3 -0 jakarta-tomcat-connectors/jk/native2/buildconf.sh Index: buildconf.sh === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/buildconf.sh,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- buildconf.sh 28 May 2002 07:52:27 - 1.7 +++ buildconf.sh 6 Feb 2004 09:43:06 - 1.8 @@ -1,5 +1,8 @@ #!/bin/sh +echo rm autom4te.cache +rm -rf autom4te.cache + echo libtoolize --force --automake --copy libtoolize --force --automake --copy echo aclocal 1.5 +1 -1 jakarta-tomcat-connectors/jk/native2/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/README.txt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- README.txt16 Sep 2003 07:38:51 - 1.4 +++ README.txt6 Feb 2004 09:43:06 - 1.5 @@ -51,7 +51,7 @@ When the APR sources are in place, we need to create the configure scripts. It is done by running the command: -./support/buildconf.sh +./buildconf.sh WARNING: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25851] - jk2 errors in apache2 error log
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=25851. 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=25851 jk2 errors in apache2 error log [EMAIL PROTECTED] changed: What|Removed |Added Component|Connector:AJP |Native:JK - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25733] - Apache-Tomcat connector problem
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=25733. 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=25733 Apache-Tomcat connector problem [EMAIL PROTECTED] changed: What|Removed |Added Component|Connector:AJP |Native:JK - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26711] New: - jsp being forwarded to overwrites content-type header
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=26711. 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=26711 jsp being forwarded to overwrites content-type header Summary: jsp being forwarded to overwrites content-type header Product: Tomcat 4 Version: 4.1.0 Platform: Other OS/Version: Windows 9x Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I set the content-type of the response (to text/html; charset=utf-8 if it matters) in a servlet and then forward the processing to a jsp file. However, it seems to have no effect at all. It works if I set the content-type in the jsp (using something like % @ page ...%. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26715] New: - Sessions that have been persisted during a server restart never time out.
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=26715. 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=26715 Sessions that have been persisted during a server restart never time out. Summary: Sessions that have been persisted during a server restart never time out. Product: Tomcat 5 Version: 5.0.18 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This can easily be reproduced. 1. create a session via request.getSession(true). 2. restart the server so the session will be persisted and loaded again. 3. wait until the session has timed out according to the value specified in web.xml. 4. the session can still be accessed by the client and stays accessible if not explicitly invalidated by a call to session.invalidate(). Looking at the codebase I think the reason for this is the accessCount field in StandardSession being in an inconsistent state after sessions have been reloaded from file. The attached patch solves it for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26715] - Sessions that have been persisted during a server restart never time out.
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=26715. 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=26715 Sessions that have been persisted during a server restart never time out. --- Additional Comments From [EMAIL PROTECTED] 2004-02-06 11:32 --- Created an attachment (id=10249) see description - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session StandardManager.java
remm2004/02/06 03:45:58
Modified:catalina/src/share/org/apache/catalina/session
StandardManager.java
Log:
- Call endAccess after reading a session from storage so that the session
properly timeouts.
- Bug 26715, submitted by Jochen Strunk.
Revision ChangesPath
1.20 +5 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardManager.java
Index: StandardManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardManager.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- StandardManager.java 26 Jan 2004 19:47:47 - 1.19
+++ StandardManager.java 6 Feb 2004 11:45:58 - 1.20
@@ -464,6 +464,7 @@
session.setManager(this);
sessions.put(session.getId(), session);
session.activate();
+session.endAccess();
}
} catch (ClassNotFoundException e) {
log.error(sm.getString(standardManager.loading.cnfe, e), e);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session PersistentManagerBase.java
remm2004/02/06 03:51:13 Modified:catalina/src/share/org/apache/catalina/session PersistentManagerBase.java Log: - Similar fix for the persistent manager. - Call endAccess after reading a session from storage so that the session properly timeouts. Revision ChangesPath 1.17 +5 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java Index: PersistentManagerBase.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- PersistentManagerBase.java26 Jan 2004 19:47:47 - 1.16 +++ PersistentManagerBase.java6 Feb 2004 11:51:13 - 1.17 @@ -874,6 +874,7 @@ ((StandardSession)session).tellNew(); add(session); ((StandardSession)session).activate(); +session.endAccess(); return (session); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26715] - Sessions that have been persisted during a server restart never time out.
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=26715. 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=26715 Sessions that have been persisted during a server restart never time out. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-06 11:51 --- Fixed. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26711] - jsp being forwarded to overwrites content-type header
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=26711. 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=26711 jsp being forwarded to overwrites content-type header [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-06 11:55 --- That is because the response is reset when you do a forward() and the JSP sets the content type and character encoding. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] uri runtime info - avoid nameless entries
Hi all, no comments yet to this?? Guenter. in mod_jk2, if invoked by the /jkstatus page, jk2_worker_status_displayRuntimeType() displays always a nameless / useless first line below the uri runtime info; I'm asking me what entry that vould be, and if it is the right way to suppress displaying it, or dig for what it is? can perhaps someone enlighten me? == --- jk_worker_status.c.origTue Feb 03 00:21:34 2004 +++ jk_worker_status.c Wed Feb 04 22:03:24 2004 @@ -282,6 +282,10 @@ if( mbean==NULL || mbean-getAttributeInfo==NULL ) continue; +/* Don't display nameless */ +if( mbean-localName == NULL || (strlen(mbean-localName) == 0) ) +continue; + if( mbean-getAttribute == NULL ) continue; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/support jk_apr.m4
jfclere 2004/02/06 04:14:53
Modified:jk/native2/server/apache13 Makefile.in
jk/support jk_apr.m4
Log:
Arrange the libtool name. Use *.la instead guessed names.
Revision ChangesPath
1.10 +6 -4 jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.in
Index: Makefile.in
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.in,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- Makefile.in 5 Feb 2004 17:40:22 - 1.9
+++ Makefile.in 6 Feb 2004 12:14:53 - 1.10
@@ -9,7 +9,6 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@/apr-config --libs`
ifdef JAVA_HOME
JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS} @HAVE_JNI@
@@ -79,10 +78,13 @@
# -- Targets
-all: prepare ${BUILD_DIR}/mod_jk2.so
+all: prepare ${BUILD_DIR}/mod_jk2.so
-${BUILD_DIR}/mod_jk2.so: ${COMMON_LO_FILES} ${A_LO_FILES}
- ${MOD_LINK} -o $@ $^ @APR_LDFLAGS@ ${APR_LIBS}
+${BUILD_DIR}/mod_jk2.so: ${BUILD_DIR}/mod_jk2.la
+ $(MOD_INSTALL) $^ `pwd`/${BUILD_DIR}
+
+${BUILD_DIR}/mod_jk2.la: ${COMMON_LO_FILES} ${A_LO_FILES}
+ ${MOD_LINK} -o $@ $^ @APR_LDFLAGS@
${COMMON_C_FILES} ${A_C_FILES}: ${H_FILES}
1.9 +5 -5 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.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- jk_apr.m4 10 Nov 2003 11:05:33 - 1.8
+++ jk_apr.m4 6 Feb 2004 12:14:53 - 1.9
@@ -138,7 +138,7 @@
AC_MSG_ERROR(apr configure failed with ${tempret})
fi
JK_APR_LIBNAME(apr_libname,${APR_DIR})
-APR_LDFLAGS=${APR_DIR}/.libs/${apr_libname}
+APR_LDFLAGS=${APR_DIR}/${apr_libname}
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
@@ -204,7 +204,7 @@
AC_MSG_ERROR(apr-util configure failed with ${tempret})
fi
JK_APR_UTIL_LIBNAME(apr_util_libname,${APR_UTIL_DIR})
-APR_LDFLAGS=${APR_LDFLAGS} ${APR_UTIL_DIR}/.libs/${apr_util_libname}
+APR_LDFLAGS=${APR_LDFLAGS} ${APR_UTIL_DIR}/${apr_util_libname}
APR_UTIL_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
@@ -326,7 +326,7 @@
if ${TEST} -z ${jk_apr_get_tempval} ; then
AC_MSG_ERROR([$2/apr-config --link-libtool failed])
fi
-jk_apr_get_tempval=`basename ${jk_apr_get_tempval} | sed 's/\.la/\.a/g'`
+jk_apr_get_tempval=`basename ${jk_apr_get_tempval}`
$1=${jk_apr_get_tempval}
AC_MSG_RESULT([${jk_apr_get_tempval}])
unset jk_apr_get_tempval
@@ -350,7 +350,7 @@
if ${TEST} -z ${jk_apu_get_tempval} ; then
AC_MSG_ERROR([$2/apu-config --link-libtool failed])
fi
-jk_apu_get_tempval=`basename ${jk_apu_get_tempval} | sed 's/\.la/\.a/g'`
+jk_apu_get_tempval=`basename ${jk_apu_get_tempval}`
$1=${jk_apu_get_tempval}
AC_MSG_RESULT([${jk_apu_get_tempval}])
unset jk_apu_get_tempval
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache13 Makefile.in
jfclere 2004/02/06 06:07:18
Modified:jk/native2/server/apache13 Makefile.in
Log:
Add the libraries apr needs. Otherwise unresolved with using mod_jk2.so.
Revision ChangesPath
1.11 +1 -1 jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.in
Index: Makefile.in
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.in,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Makefile.in 6 Feb 2004 12:14:53 - 1.10
+++ Makefile.in 6 Feb 2004 14:07:18 - 1.11
@@ -84,7 +84,7 @@
$(MOD_INSTALL) $^ `pwd`/${BUILD_DIR}
${BUILD_DIR}/mod_jk2.la: ${COMMON_LO_FILES} ${A_LO_FILES}
- ${MOD_LINK} -o $@ $^ @APR_LDFLAGS@
+ ${MOD_LINK} -o $@ $^ @APR_LDFLAGS@ [EMAIL PROTECTED]@/apr-config --libs`
${COMMON_C_FILES} ${A_C_FILES}: ${H_FILES}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native configure.in
hgomez 2004/02/06 06:09:34
Modified:jk/native configure.in
Log:
apxs -q installbuildir allready provide the 'build' dir
Revision ChangesPath
1.28 +2 -2 jakarta-tomcat-connectors/jk/native/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/configure.in,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- configure.in 21 Jan 2004 15:50:39 - 1.27
+++ configure.in 6 Feb 2004 14:09:34 - 1.28
@@ -103,7 +103,7 @@
APRINCLUDEDIR=-I`$APXS -q APR_INCLUDEDIR`
APXSCFLAGS=`${APXS} -q CFLAGS` `${APXS} -q EXTRA_CFLAGS`
-DHAVE_APR ${APRINCLUDEDIR}
APXSCPPFLAGS=`${APXS} -q EXTRA_CPPFLAGS`
-APACHE_CONFIG_VARS=`${APXS} -q
installbuilddir`/build/config_vars.mk
+APACHE_CONFIG_VARS=`${APXS} -q installbuilddir`/config_vars.mk
LIBTOOL=`$APXS -q LIBTOOL`
fi
AC_MSG_RESULT([building connector for \$WEBSERVER\])
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native configure.in
hgomez 2004/02/06 06:12:59
Modified:jk/native configure.in
Log:
The real install build dir which is where live the build datas
Revision ChangesPath
1.29 +2 -2 jakarta-tomcat-connectors/jk/native/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/configure.in,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- configure.in 6 Feb 2004 14:09:34 - 1.28
+++ configure.in 6 Feb 2004 14:12:59 - 1.29
@@ -103,7 +103,7 @@
APRINCLUDEDIR=-I`$APXS -q APR_INCLUDEDIR`
APXSCFLAGS=`${APXS} -q CFLAGS` `${APXS} -q EXTRA_CFLAGS`
-DHAVE_APR ${APRINCLUDEDIR}
APXSCPPFLAGS=`${APXS} -q EXTRA_CPPFLAGS`
-APACHE_CONFIG_VARS=`${APXS} -q installbuilddir`/config_vars.mk
+APACHE_CONFIG_VARS=`${APXS} -q exp_installbuilddir`/config_vars.mk
LIBTOOL=`$APXS -q LIBTOOL`
fi
AC_MSG_RESULT([building connector for \$WEBSERVER\])
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs/config context.xml
yoavs 2004/02/06 06:26:10 Modified:webapps/docs/config context.xml Log: Corrected typo. Revision ChangesPath 1.9 +3 -1 jakarta-tomcat-catalina/webapps/docs/config/context.xml Index: context.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/context.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- context.xml 5 Feb 2004 23:17:21 - 1.8 +++ context.xml 6 Feb 2004 14:26:10 - 1.9 @@ -53,7 +53,9 @@ reconfiguration of the web application, since the main codeconf/server.xml/code file cannot be reloaded without restarting Tomcat. bPlease note that for tomcat 5.x, unlike tomcat 4.x, it is NOT - recommended to place lt;Contextgt; elements directory in the server.xml file./b + recommended to place lt;Contextgt; elements directly in the server.xml file./b + Instead, put them in the META-INF/context.xml directory of your WAR file or + the conf directory as described above. /p pIn addition to explicitly specified Context elements, there are - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_status.c
hgomez 2004/02/06 06:51:25
Modified:jk/native2/common jk_worker_status.c
Log:
Avoid display nameless beans.
Provided by Gunter Knauf
Revision ChangesPath
1.47 +3 -0 jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c
Index: jk_worker_status.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- jk_worker_status.c2 Feb 2004 18:21:08 - 1.46
+++ jk_worker_status.c6 Feb 2004 14:51:25 - 1.47
@@ -288,6 +288,9 @@
if( strncmp( type, mbean-type, typeLen ) != 0 )
continue;
+if( mbean-localName == NULL || (strlen(mbean-localName) == 0) )
+continue;
+
if( needHeader ) {
s-jkprintf(env, s, H3%s runtime info/H3\n, JK_CHECK_NULL(type) );
s-jkprintf(env, s, p%s information, using getAttribute() /p\n,
JK_CHECK_NULL(type) );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] uri runtime info - avoid nameless entries
Günter Knauf a écrit : Hi all, no comments yet to this?? Guenter. in mod_jk2, if invoked by the /jkstatus page, jk2_worker_status_displayRuntimeType() displays always a nameless / useless first line below the uri runtime info; I'm asking me what entry that vould be, and if it is the right way to suppress displaying it, or dig for what it is? can perhaps someone enlighten me? == --- jk_worker_status.c.origTue Feb 03 00:21:34 2004 +++ jk_worker_status.c Wed Feb 04 22:03:24 2004 @@ -282,6 +282,10 @@ if( mbean==NULL || mbean-getAttributeInfo==NULL ) continue; +/* Don't display nameless */ +if( mbean-localName == NULL || (strlen(mbean-localName) == 0) ) +continue; + if( mbean-getAttribute == NULL ) continue; Make sense, commited, thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0.19] New tag next week ?
Howdy, 5.0.18 has been good, so there's no big rush. But there are bug fixes and doc updates, which are always good to get out ;) So I'm neutral on the date, I think next week is fine. Yoav Shapira Millennium ChemInformatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Friday, February 06, 2004 10:03 AM To: Tomcat Developers List Subject: [5.0.19] New tag next week ? Hi, I think I'll tag a new build next week, picking up the bugfixes. Any comments on this ? Or should we wait more ? The remaining issues are for the most part with either: - JK (with a release planned for the same date - 02/13 -, this should be covered :) ) - the admin webapp Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.19] New tag next week ?
I think next week is a good date. There is a pretty significant change in the clustering configuration, it is more modular and can be easier extendable now. Also some good bug fixes in there. Next week, definitely not later :) Filip - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, February 06, 2004 7:04 AM Subject: RE: [5.0.19] New tag next week ? Howdy, 5.0.18 has been good, so there's no big rush. But there are bug fixes and doc updates, which are always good to get out ;) So I'm neutral on the date, I think next week is fine. Yoav Shapira Millennium ChemInformatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Friday, February 06, 2004 10:03 AM To: Tomcat Developers List Subject: [5.0.19] New tag next week ? Hi, I think I'll tag a new build next week, picking up the bugfixes. Any comments on this ? Or should we wait more ? The remaining issues are for the most part with either: - JK (with a release planned for the same date - 02/13 -, this should be covered :) ) - the admin webapp Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: [5.0.19] New tag next week ?
Shapira, Yoav wrote: Howdy, 5.0.18 has been good, so there's no big rush. But there are bug fixes and doc updates, which are always good to get out ;) So I'm neutral on the date, I think next week is fine. There are a number of significant fixes having been made since 5.0.18. Indeed there were few regressions or similar, so this is good. My list of significant stuff includes: - Bugs 26611, 26492, 26373, 26432, 26010, 26341, 26628, 26487. - Jan's fix on RequestGroupInfo. - The rather visible home.c syntax error in commons-deamon. - Fixed connector shutdown. - Allow configuring how much memory the HTTP connector uses. By default, it's a lot less than before. There's one related fix I'll need to do (dynamically resizing the buffer used for the HTTP response header), but it'll wait until after the tag. - Plenty of session access optimization and invalidation fixes. Testing of HEAD is encouraged to fix issues before the end of next week :) (please don't come up with your issues five minutes after I've finished uploading and signing the build, I won't be pleased) I'll try to do some polish and testing of my own before the tag. Incl for example testing JNI with my (truted) IIS 5 install. The last time I did was one year ago, and I've seen classpath induced complaints about this on tomcat-user. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session DeltaManager.java DeltaSession.java
fhanik 2004/02/06 08:15:32
Modified:modules/cluster/src/share/org/apache/catalina/cluster/session
DeltaManager.java DeltaSession.java
Log:
Fix for bug 26715, a replicated session will never expire if the primary server
crashes.
This will fix that.
Revision ChangesPath
1.14 +9 -4
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
Index: DeltaManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- DeltaManager.java 5 Feb 2004 23:01:29 - 1.13
+++ DeltaManager.java 6 Feb 2004 16:15:32 - 1.14
@@ -484,7 +484,12 @@
session.setManager(this);
session.setValid(true);
session.setPrimarySession(false);
+//in case the nodes in the cluster are out of
+//time synch, this will make sure that we have the
+//correct timestamp, isValid returns true, cause accessCount=1
session.access();
+//make sure that the session gets ready to expire if needed
+session.setAccessCount(0);
sessions.put(session.getId(), session);
}
} catch (ClassNotFoundException e) {
1.15 +12 -4
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java
Index: DeltaSession.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- DeltaSession.java 6 Feb 2004 02:09:38 - 1.14
+++ DeltaSession.java 6 Feb 2004 16:15:32 - 1.15
@@ -1685,6 +1685,14 @@
protected void setLastTimeReplicated(long lastTimeReplicated) {
this.lastTimeReplicated = lastTimeReplicated;
}
+
+protected void setAccessCount(int accessCount) {
+ this.accessCount = accessCount;
+}
+
+protected int getAccessCount() {
+ return accessCount;
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
BIG PROBLEM // LINUX TOMCAT SSL
Hello, I have post this message two week ago. I don't have any response about it. It's very very important. Have you see it ? If you want more information, tell me. Please answer me for tell me you are going to see the problem. Thanks. -Message d'origine- De : Bouchia Nazha [mailto:[EMAIL PROTECTED] Envoyé : mercredi 14 janvier 2004 12:19 À : 'Tomcat Users List' Objet : BIG PROBLEM // LINUX TOMCAT SSL Hello, I have encountered a problem using tomcat, linux and ssl. This is my configuration: OS: Redhat7.2 Tomcat: 4.0 Jdk: 1.3.1_07 I have a servlet that does a post https connexion with a certificat client and server. When I execute 200 (or more) this servlet, we can see that the memory increase. After 200 calls consecutive, the memory has increased of 20M and doesn't decrease. After 1000 calls, the server doesn't have enough memory and tomcat crash. I have upgrated the jdk toV1.4.1 and tomcat to V5.0, and have the same problem. I have add tomcat option like -Xmx without succes. When I do this test with Windows2000, the memory increase but decrease after. It seem to be link with linux. Any help will be welcome. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.576 / Virus Database: 365 - Release Date: 30/01/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BIG PROBLEM // LINUX TOMCAT SSL
Read the solution of your problem here: http://jakarta.apache.org/site/mail.html In bref, all you need to do is * Respect the mailing list type * There are generally two types of lists. * The User lists where you can send questions and comments about configuration, setup, usage and other user types of questions. * The Developer lists where you can send questions and comments about the actual software source code and general development types of questions. -- Jeanfrancois Bouchia Nazha wrote: Hello, I have post this message two week ago. I don't have any response about it. It's very very important. Have you see it ? If you want more information, tell me. Please answer me for tell me you are going to see the problem. Thanks. -Message d'origine- De : Bouchia Nazha [mailto:[EMAIL PROTECTED] Envoyé : mercredi 14 janvier 2004 12:19 À : 'Tomcat Users List' Objet : BIG PROBLEM // LINUX TOMCAT SSL Hello, I have encountered a problem using tomcat, linux and ssl. This is my configuration: OS: Redhat7.2 Tomcat: 4.0 Jdk: 1.3.1_07 I have a servlet that does a post https connexion with a certificat client and server. When I execute 200 (or more) this servlet, we can see that the memory increase. After 200 calls consecutive, the memory has increased of 20M and doesn't decrease. After 1000 calls, the server doesn't have enough memory and tomcat crash. I have upgrated the jdk toV1.4.1 and tomcat to V5.0, and have the same problem. I have add tomcat option like -Xmx without succes. When I do this test with Windows2000, the memory increase but decrease after. It seem to be link with linux. Any help will be welcome. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.576 / Virus Database: 365 - Release Date: 30/01/2004 - 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: [5.0.19] New tag next week ?
Remy Maucherat wrote: Shapira, Yoav wrote: Howdy, 5.0.18 has been good, so there's no big rush. But there are bug fixes and doc updates, which are always good to get out ;) So I'm neutral on the date, I think next week is fine. There are a number of significant fixes having been made since 5.0.18. Indeed there were few regressions or similar, so this is good. My list of significant stuff includes: - Bugs 26611, 26492, 26373, 26432, 26010, 26341, 26628, 26487. - Jan's fix on RequestGroupInfo. - The rather visible home.c syntax error in commons-deamon. - Fixed connector shutdown. - Allow configuring how much memory the HTTP connector uses. By default, it's a lot less than before. There's one related fix I'll need to do (dynamically resizing the buffer used for the HTTP response header), but it'll wait until after the tag. - Plenty of session access optimization and invalidation fixes. Testing of HEAD is encouraged to fix issues before the end of next week :) (please don't come up with your issues five minutes after I've finished uploading and signing the build, I won't be pleased) I'll try to do some polish and testing of my own before the tag. Incl for example testing JNI with my (truted) IIS 5 install. The last time I did was one year ago, and I've seen classpath induced complaints about this on tomcat-user. +1. I will spin the tcks again to double check we don't regress. -- Jeanfrancois Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26363] - JSP Compiler does not recognize unbalanced Struts tag
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=26363. 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=26363 JSP Compiler does not recognize unbalanced Struts tag [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.19] New tag next week ?
Remy Maucherat wrote: Shapira, Yoav wrote: Howdy, 5.0.18 has been good, so there's no big rush. But there are bug fixes and doc updates, which are always good to get out ;) So I'm neutral on the date, I think next week is fine. There are a number of significant fixes having been made since 5.0.18. Indeed there were few regressions or similar, so this is good. My list of significant stuff includes: - Bugs 26611, 26492, 26373, 26432, 26010, 26341, 26628, 26487. - Jan's fix on RequestGroupInfo. - The rather visible home.c syntax error in commons-deamon. - Fixed connector shutdown. - Allow configuring how much memory the HTTP connector uses. By default, it's a lot less than before. There's one related fix I'll need to do (dynamically resizing the buffer used for the HTTP response header), but it'll wait until after the tag. - Plenty of session access optimization and invalidation fixes. Testing of HEAD is encouraged to fix issues before the end of next week :) (please don't come up with your issues five minutes after I've finished uploading and signing the build, I won't be pleased) I'll try to do some polish and testing of my own before the tag. Incl for example testing JNI with my (truted) IIS 5 install. The last time I did was one year ago, and I've seen classpath induced complaints about this on tomcat-user. +1. I will spin the tcks again to double check we don't regress. -- Jeanfrancois Rémy - 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]
[PATCH] net build ant script documentation
One must set the 'base.path' property to an *absolute* directory name for the net build script to function properly. Using a relative path will cause the script to fail. This patch seeks to add a simple warning to the user on this page. The file location may be wrong. http://jakarta.apache.org/tomcat/tomcat-5.0-doc/building.html -- Josh Rehman citysearch.com 213.739.3559 Index: BUILDING.txt === RCS file: /home/cvspublic/jakarta-tomcat-5/BUILDING.txt,v retrieving revision 1.32 diff -u -r1.32 BUILDING.txt --- BUILDING.txt8 Sep 2003 10:12:00 - 1.32 +++ BUILDING.txt6 Feb 2004 05:49:43 - @@ -85,7 +85,7 @@ # - Default Base Path for Dependent Packages - # Replace this path with the directory path where dependencies binaries -# should be downloaded +# should be downloaded. THIS MUST BE AN ABSOLUTE PATHNAME! base.path=/usr/share/java @@ -107,4 +107,4 @@ In addition, ant build-depends will build packages that tomcat depends on ( commons-logging for now ), to ease fixes -and debuging in those packages. \ No newline at end of file +and debuging in those packages. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session DeltaManager.java DeltaRequest.java DeltaSession.java
fhanik 2004/02/06 09:30:13
Modified:modules/cluster/src/share/org/apache/catalina/cluster/session
DeltaManager.java DeltaRequest.java
DeltaSession.java
Log:
Implemented access logic on the delta request, fixed double expiration on the session
Revision ChangesPath
1.15 +8 -7
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
Index: DeltaManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- DeltaManager.java 6 Feb 2004 16:15:32 - 1.14
+++ DeltaManager.java 6 Feb 2004 17:30:13 - 1.15
@@ -949,7 +949,6 @@
* Invalidate all sessions that have expired.
*/
public void processExpires() {
-
long timeNow = System.currentTimeMillis();
Session sessions[] = findSessions();
@@ -958,7 +957,6 @@
if (!session.isValid()) {
try {
expiredSessions++;
-session.expire();
} catch (Throwable t) {
log.error(sm.getString
(standardManager.expireException), t);
@@ -967,17 +965,20 @@
}
long timeEnd = System.currentTimeMillis();
processingTime += ( timeEnd - timeNow );
-
}
+
public boolean getStateTransferred() {
return stateTransferred;
}
+
public void setStateTransferred(boolean stateTransferred) {
this.stateTransferred = stateTransferred;
}
+
public CatalinaCluster getCluster() {
return cluster;
}
+
public void setCluster(CatalinaCluster cluster) {
this.cluster = cluster;
}
1.6 +5 -3
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaRequest.java
Index: DeltaRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaRequest.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- DeltaRequest.java 5 Feb 2004 21:08:02 - 1.5
+++ DeltaRequest.java 6 Feb 2004 17:30:13 - 1.6
@@ -161,6 +161,7 @@
public void execute(DeltaSession session) {
if ( !this.sessionId.equals( session.getId() ) )
throw new java.lang.IllegalArgumentException(Session id mismatch, not
executing the delta request);
+session.access();
for ( int i=0; iactions.size(); i++ ) {
AttributeInfo info = (AttributeInfo)actions.get(i);
switch ( info.getType() ) {
@@ -191,6 +192,7 @@
default : throw new java.lang.IllegalArgumentException(Invalid
attribute info type=+info);
}//switch
}//for
+session.endAccess();
}
public void reset() {
1.16 +5 -6
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java
Index: DeltaSession.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- DeltaSession.java 6 Feb 2004 16:15:32 - 1.15
+++ DeltaSession.java 6 Feb 2004 17:30:13 - 1.16
@@ -661,7 +661,7 @@
//the primary session has probably crashed, and no other
//requests are coming in. that is why we do this. otherwise
//we would have a memory leak
-expire(true);
+expire(true,false);
}
}
@@ -745,7 +745,6 @@
// Mark this session as being expired if needed
if (expiring)
return;
-
String expiredId = getId();
synchronized (this) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5598] - (JSP Problem) RequestDispatcher doesn't include HTML output in place
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=5598. 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=5598 (JSP Problem) RequestDispatcher doesn't include HTML output in place [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-06 17:30 --- Closing based on Kin-Man's last comments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-servletapi-5/jsr152/examples/tagplugin howto.html
kinman 2004/02/06 10:28:38 Modified:jsr152/examples/tagplugin howto.html Log: Fix typo. Revision ChangesPath 1.2 +2 -2 jakarta-servletapi-5/jsr152/examples/tagplugin/howto.html Index: howto.html === RCS file: /home/cvs/jakarta-servletapi-5/jsr152/examples/tagplugin/howto.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- howto.html5 Feb 2004 18:09:04 - 1.1 +++ howto.html6 Feb 2004 18:28:38 - 1.2 @@ -9,10 +9,10 @@ li Implement the plugin class.p/ This class, which implements -ttorg.apache.jasper.compiler.tagplugin.Plugin/tt +ttorg.apache.jasper.compiler.tagplugin.TagPlugin/tt instructs Jasper what Java codes to generate in place of the tag handler calls. -See Javadoc for ttorg.apache.jasper.compiler.tagplugin.Plugin/tt +See Javadoc for ttorg.apache.jasper.compiler.tagplugin.TagPlugin/tt for details. /li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] uri runtime info - avoid nameless entries
Good morning All. The fact that the row (without even a 'name' value) appears in the URI runtime table in /jkstatus suggests that it must be an object (bean?) of type 'uri' because that is a requirement of the loop. Hence something is permitting the creation of an unitialised uri object [zero perhaps, since it is the first element in the table] and all this change will do is mask it from display in /jkstatus. Of course once the cause of the problem is determined then this patch will not have a detrimental effect. Norm Hi all, no comments yet to this?? Guenter. in mod_jk2, if invoked by the /jkstatus page, jk2_worker_status_displayRuntimeType() displays always a nameless / useless first line below the uri runtime info; I'm asking me what entry that vould be, and if it is the right way to suppress displaying it, or dig for what it is? can perhaps someone enlighten me? == --- jk_worker_status.c.origTue Feb 03 00:21:34 2004 +++ jk_worker_status.c Wed Feb 04 22:03:24 2004 @@ -282,6 +282,10 @@ if( mbean==NULL || mbean-getAttributeInfo==NULL ) continue; +/* Don't display nameless */ +if( mbean-localName == NULL || (strlen(mbean-localName) == 0) ) +continue; + if( mbean-getAttribute == NULL ) continue; - 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]
cvs commit: jakarta-tomcat-connectors/jk/native2 configure.in
jfclere 2004/02/06 14:37:17 Modified:jk/native2 configure.in Log: Add the missing parameter to JK_WS_DIR. Revision ChangesPath 1.16 +10 -6 jakarta-tomcat-connectors/jk/native2/configure.in Index: configure.in === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/configure.in,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- configure.in 5 Feb 2004 17:04:33 - 1.15 +++ configure.in 6 Feb 2004 22:37:17 - 1.16 @@ -123,19 +123,22 @@ JK_APXS([2], [location of apxs for Apache 2.0]) dnl APACHE13 settings -JK_WS_DIR([apache13], [src/include/httpd.h]) +AC_MSG_RESULT([Checking for apache13...]) +JK_WS_DIR([apache13], [APACHE], [src/include/httpd.h]) JK_WS_INCDIR([apache13], [httpd.h]) JK_WS_LIBDIR([apache13]) dnl APACHE2 settings -JK_WS_DIR([apache2], [include/httpd.h]) +AC_MSG_RESULT([Checking for apache20...]) +JK_WS_DIR([apache2], [APACHE2], [include/httpd.h]) JK_WS_INCDIR([apache2], [httpd.h]) JK_WS_LIBDIR([apache2]) dnl IIS settings -JK_WS_DIR([iis], [.]) +AC_MSG_RESULT([Checking for iis...]) +JK_WS_DIR([iis], [IIS], [.]) JK_WS_INCDIR([iis], [.]) JK_WS_LIBDIR([iis]) @@ -148,7 +151,8 @@ dnl iPlanet settings -JK_WS_DIR([iplanet], [.]) +AC_MSG_RESULT([Checking for iPlanet...]) +JK_WS_DIR([iplanet], [IPLANET], [.]) JK_WS_INCDIR([iplanet], [.]) JK_WS_LIBDIR([iplanet]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/support jk_ws.m4
jfclere 2004/02/06 15:26:30
Modified:jk/native2 configure.in
jk/support jk_ws.m4
Log:
WEBSERVER was missing when using --with-server.
Prevent test $APACHE${n}-CC with CC when $APACHE${n}-CC is empty.
Revision ChangesPath
1.17 +8 -8 jakarta-tomcat-connectors/jk/native2/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/configure.in,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- configure.in 6 Feb 2004 22:37:17 - 1.16
+++ configure.in 6 Feb 2004 23:26:29 - 1.17
@@ -124,21 +124,21 @@
dnl APACHE13 settings
AC_MSG_RESULT([Checking for apache13...])
-JK_WS_DIR([apache13], [APACHE], [src/include/httpd.h])
+JK_WS_DIR([apache13], [APACHE], [src/include/httpd.h], [server/apache13])
JK_WS_INCDIR([apache13], [httpd.h])
JK_WS_LIBDIR([apache13])
dnl APACHE2 settings
AC_MSG_RESULT([Checking for apache20...])
-JK_WS_DIR([apache2], [APACHE2], [include/httpd.h])
+JK_WS_DIR([apache2], [APACHE2], [include/httpd.h], [server/apache2])
JK_WS_INCDIR([apache2], [httpd.h])
JK_WS_LIBDIR([apache2])
dnl IIS settings
AC_MSG_RESULT([Checking for iis...])
-JK_WS_DIR([iis], [IIS], [.])
+JK_WS_DIR([iis], [IIS], [.], [server/isapi])
JK_WS_INCDIR([iis], [.])
JK_WS_LIBDIR([iis])
@@ -152,7 +152,7 @@
dnl iPlanet settings
AC_MSG_RESULT([Checking for iPlanet...])
-JK_WS_DIR([iplanet], [IPLANET], [.])
+JK_WS_DIR([iplanet], [IPLANET], [.], [server/aolserver])
JK_WS_INCDIR([iplanet], [.])
JK_WS_LIBDIR([iplanet])
@@ -216,7 +216,7 @@
AC_MSG_ERROR([Apache 1.3 requires apr to built from source, use
--with-apr and --with-apr-util])
fi
dnl make sure compiler matchs apxs
-if ${TEST} $APACHE_CC != $CC; then
+if ${TEST} -n $APACHE_CC -a $APACHE_CC != $CC; then
AC_MSG_RESULT([error])
AC_MSG_RESULT([compiler discovered by configure: ${CC}])
AC_MSG_RESULT([compiler used by apache: ${APACHE_CC}])
@@ -232,7 +232,7 @@
AC_MSG_ERROR([Use apr that comes with Apache 2, remove --with-apr])
fi
dnl make sure compiler matchs apxs
-if ${TEST} $APACHE2_CC != $CC; then
+if ${TEST} -n $APACHE2_CC -a $APACHE2_CC != $CC; then
AC_MSG_RESULT([error])
AC_MSG_RESULT([compiler discovered by configure: ${CC}])
AC_MSG_RESULT([compiler used by apache: ${APACHE2_CC}])
1.4 +3 -1 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.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- jk_ws.m4 5 Nov 2003 09:14:28 - 1.3
+++ jk_ws.m4 6 Feb 2004 23:26:29 - 1.4
@@ -69,6 +69,7 @@
dnl $1 = Webserver name
dnl $2 = Webserver vars prefix name
dnl $3 = File which should be present
+dnl $4 = Server specific source directory
dnl --
AC_DEFUN(
[JK_WS_DIR],
@@ -103,6 +104,7 @@
$2_INCDIR=${tempval}/include
$2_LDFLAGS=
$2_LIBDIR=
+ WEBSERVERS=${WEBSERVERS} $4
AC_MSG_RESULT($1_DIR)
fi
;;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Configurable session id length
Is there any interest in making the session id length configurable?
If so, please consider my patch (attached).
Thanks,
Jan
Index: Manager.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Manager.java,v
retrieving revision 1.6
diff -u -r1.6 Manager.java
--- Manager.java13 Jan 2004 01:39:36 - 1.6
+++ Manager.java7 Feb 2004 02:19:31 -
@@ -164,6 +164,24 @@
public void setMaxInactiveInterval(int interval);
+/**
+ * Gets the session id length (in bytes) of Sessions created by
+ * this Manager.
+ *
+ * @return The session id length
+ */
+public int getSessionIdLength();
+
+
+/**
+ * Sets the session id length (in bytes) for Sessions created by this
+ * Manager.
+ *
+ * @param sessionIdLength The session id length
+ */
+public void setSessionIdLength(int idLength);
+
+
// - Public Methods
Index: session/ManagerBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
retrieving revision 1.24
diff -u -r1.24 ManagerBase.java
--- session/ManagerBase.java26 Jan 2004 20:19:11 - 1.24
+++ session/ManagerBase.java7 Feb 2004 02:19:31 -
@@ -119,13 +119,6 @@
/**
- * The number of random bytes to include when generating a
- * session identifier.
- */
-protected static final int SESSION_ID_BYTES = 16;
-
-
-/**
* The message digest algorithm to be used when generating session
* identifiers. This must be an algorithm supported by the
* codejava.security.MessageDigest/code class on your platform.
@@ -187,6 +180,12 @@
/**
+ * The session id length of Sessions created by this Manager.
+ */
+protected int sessionIdLength = 16;
+
+
+/**
* The descriptive name of this Manager implementation (for logging).
*/
protected static String name = ManagerBase;
@@ -488,6 +487,36 @@
/**
+ * Gets the session id length (in bytes) of Sessions created by
+ * this Manager.
+ *
+ * @return The session id length
+ */
+public int getSessionIdLength() {
+
+return (this.sessionIdLength);
+
+}
+
+
+/**
+ * Sets the session id length (in bytes) for Sessions created by this
+ * Manager.
+ *
+ * @param sessionIdLength The session id length
+ */
+public void setSessionIdLength(int idLength) {
+
+int oldSessionIdLength = this.sessionIdLength;
+this.sessionIdLength = idLength;
+support.firePropertyChange(sessionIdLength,
+ new Integer(oldSessionIdLength),
+ new Integer(this.sessionIdLength));
+
+}
+
+
+/**
* Return the descriptive short name of this Manager implementation.
*/
public String getName() {
@@ -496,8 +525,9 @@
}
-/** Use /dev/random-type special device. This is new code, but may reduce the
- * big delay in generating the random.
+/**
+ * Use /dev/random-type special device. This is new code, but may reduce
+ * the big delay in generating the random.
*
* You must specify a path to a random generator file. Use /dev/urandom
* for linux ( or similar ) systems. Use /dev/random for maximum security
@@ -828,23 +858,30 @@
* Generate and return a new session identifier.
*/
protected synchronized String generateSessionId() {
-byte bytes[] = new byte[SESSION_ID_BYTES];
-getRandomBytes( bytes );
-bytes = getDigest().digest(bytes);
+
+byte random[] = new byte[16];
// Render the result as a String of hexadecimal digits
StringBuffer result = new StringBuffer();
-for (int i = 0; i bytes.length; i++) {
-byte b1 = (byte) ((bytes[i] 0xf0) 4);
-byte b2 = (byte) (bytes[i] 0x0f);
-if (b1 10)
-result.append((char) ('0' + b1));
-else
-result.append((char) ('A' + (b1 - 10)));
-if (b2 10)
-result.append((char) ('0' + b2));
-else
-result.append((char) ('A' + (b2 - 10)));
+int resultLenBytes = 0;
+while (resultLenBytes this.sessionIdLength) {
+getRandomBytes(random);
+random = getDigest().digest(random);
+for (int j = 0;
+j random.length resultLenBytes this.sessionIdLength;
+j++) {
+byte b1 = (byte) ((random[j] 0xf0) 4);
+byte b2 = (byte) (random[j] 0x0f);
+if (b1 10)
+result.append((char) ('0' + b1));
+else
+
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
billbarker2004/02/06 21:24:08
Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java
Log:
Fix stupid off-by-one bug.
Before, a url-pattern of /s/* would match /simon/rant.html
Reported by: Yann Cebron [EMAIL PROTECTED]
Revision ChangesPath
1.28 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java
Index: RealmBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- RealmBase.java26 Jan 2004 20:19:11 - 1.27
+++ RealmBase.java7 Feb 2004 05:24:08 - 1.28
@@ -511,7 +511,7 @@
matched = true;
length = pattern.length();
} else if(pattern.regionMatches(0,uri,0,
-pattern.length()-2)) {
+pattern.length()-1)) {
matched = true;
length = pattern.length();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
billbarker2004/02/06 21:54:32
Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java
Log:
Went back and re-read the spec.
A url-pattern of /protected/* must match a request for /protected. Hence a special
case for this one.
Revision ChangesPath
1.29 +8 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java
Index: RealmBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- RealmBase.java7 Feb 2004 05:24:08 - 1.28
+++ RealmBase.java7 Feb 2004 05:54:32 - 1.29
@@ -511,7 +511,10 @@
matched = true;
length = pattern.length();
} else if(pattern.regionMatches(0,uri,0,
-pattern.length()-1)) {
+pattern.length()-1) ||
+ (pattern.length()-2 == uri.length()
+ pattern.regionMatches(0,uri,0,
+pattern.length()-2))) {
matched = true;
length = pattern.length();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
