DO NOT REPLY [Bug 31594] - Change server.xml default Connector address to localhost + AJP docs tweak
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31594. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31594 Change server.xml default Connector address to localhost + AJP docs tweak [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 06:08 --- Although we have a quite secure default configuration, this would not be acceptable, and would cause a lot of user complaints. Sorry if this causes you to not use Tomcat, but this will not happen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31590] - Problem deploying a WAR with a META-INF/context.xml file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31590 Problem deploying a WAR with a META-INF/context.xml file --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 06:57 --- Hi Remy, ok. I'm attaching it. This war deploys fine with Tomcat 5.0.25, 5.0.28 and 5.0.29. To deploy it, I'm simply dropping it in [tomcathome]/webapps/ and then I start Tomcat. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31590] - Problem deploying a WAR with a META-INF/context.xml file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31590 Problem deploying a WAR with a META-INF/context.xml file --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 06:58 --- Created an attachment (id=12993) war containing a META-INF/context.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31592] - storage format of digested realm passwords depends on default charset
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31592. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31592 storage format of digested realm passwords depends on default charset --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 06:59 --- Yes, you are right, I mean Tomcat 5 and read the 5.5 doc but the Tomcat 3 source. However, now I also checked the 5.5 source, and the code - so the problem - is the same. The same fix could be equally useful for Tomcat 5 too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31590] - Problem deploying a WAR with a META-INF/context.xml file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31590 Problem deploying a WAR with a META-INF/context.xml file --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 06:59 --- Note that the file is named: tomcat-context.war. It seems bugzilla has renamed my attachment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31590] - Problem deploying a WAR with a META-INF/context.xml file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31590 Problem deploying a WAR with a META-INF/context.xml file [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 07:12 --- Ok, it's simple. To avoid having duplicate information about the same thing, the path value is aquired from the .war name (= the deployment name). So other places where a path attribute would have been specified are now ignored (I was considering printing out a message of some sort). Similarly, the docBase attribute is only used if referring to a docBase outside of the host's appBase (which is webapps here), so you also don't need it. The exception where the path attribute is used is when you define the Context in server.xml. In this case, however, the docBase should not be in the host appBase unless it matches the path name (otherwise - double deployment). So, sorry, it's INVALID since I did it on purpose. Note: In 5.0.x, I think the path manipulation you did might have led to your webapp being deployed twice (you might want to check with the manager or something like it). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c
mturk 2004/10/08 00:19:34
Modified:jk/native/common jk_uri_worker_map.c
Log:
Untabify the source.
Revision ChangesPath
1.22 +58 -59jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c
Index: jk_uri_worker_map.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- jk_uri_worker_map.c 24 Feb 2004 08:45:46 - 1.21
+++ jk_uri_worker_map.c 8 Oct 2004 07:19:34 - 1.22
@@ -90,8 +90,7 @@
* .suffix/, or .suffix .
*/
static int check_security_fraud(jk_uri_worker_map_t *uw_map,
-const char *uri,
-jk_logger_t *l)
+const char *uri)
{
unsigned i;
@@ -153,10 +152,10 @@
uri_worker_map_close(*uw_map, l);
free(*uw_map);
*uw_map = NULL;
- return JK_TRUE;
+return JK_TRUE;
}
else
- jk_log(l, JK_LOG_ERROR,
+jk_log(l, JK_LOG_ERROR,
In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters\n);
return JK_FALSE;
@@ -257,30 +256,30 @@
uwr-match_type = MATCH_TYPE_SUFFIX;
jk_log(l, JK_LOG_DEBUG,
Into jk_uri_worker_map_t::uri_worker_map_open,
-suffix rule %s.%s=%s was added\n,
+ suffix rule %s.%s=%s was added\n,
uri, asterisk + 3, worker);
- } else if ('\0' != asterisk[2]) {
- /* general suffix rule */
- asterisk[1] = '\0';
- uwr-worker_name = worker;
- uwr-context = uri;
- uwr-suffix = asterisk + 2;
- uwr-match_type = MATCH_TYPE_GENERAL_SUFFIX;
- jk_log(l, JK_LOG_DEBUG,
-Into jk_uri_worker_map_t::uri_worker_map_open,
-general suffix rule %s*%s=%s was added\n,
-uri, asterisk + 2, worker);
- } else {
- /* context based */
- asterisk[1] = '\0';
- uwr-worker_name = worker;
- uwr-context = uri;
- uwr-suffix = NULL;
- uwr-match_type = MATCH_TYPE_CONTEXT;
- jk_log(l, JK_LOG_DEBUG,
-Into jk_uri_worker_map_t::uri_worker_map_open,
-match rule %s=%s was added\n,
-uri, worker);
+} else if ('\0' != asterisk[2]) {
+/* general suffix rule */
+asterisk[1] = '\0';
+uwr-worker_name = worker;
+uwr-context = uri;
+uwr-suffix = asterisk + 2;
+uwr-match_type = MATCH_TYPE_GENERAL_SUFFIX;
+jk_log(l, JK_LOG_DEBUG,
+ Into jk_uri_worker_map_t::uri_worker_map_open,
+ general suffix rule %s*%s=%s was added\n,
+ uri, asterisk + 2, worker);
+} else {
+/* context based */
+asterisk[1] = '\0';
+uwr-worker_name = worker;
+uwr-context = uri;
+uwr-suffix = NULL;
+uwr-match_type = MATCH_TYPE_CONTEXT;
+jk_log(l, JK_LOG_DEBUG,
+ Into jk_uri_worker_map_t::uri_worker_map_open,
+ match rule %s=%s was added\n,
+ uri, worker);
}
} else {
/* Something like : JkMount /servlets/exampl* ajp13 */
@@ -389,7 +388,7 @@
const char *str_minus_one=str-1;
const char *s=str+strlen(str);
while(s!=str_minus_one ch!=*s) {
- --s;
+--s;
}
return (s-str);
}
@@ -403,7 +402,7 @@
if(uw_map) {
jk_close_pool(uw_map-p);
jk_close_pool(uw_map-tp);
- return JK_TRUE;
+return JK_TRUE;
}
jk_log(l, JK_LOG_ERROR,
@@ -469,38 +468,38 @@
uwr-ctxt_len)) {
if(MATCH_TYPE_EXACT == uwr-match_type) {
if(strlen(uri) == uwr-ctxt_len) {
- jk_log(l,
-JK_LOG_DEBUG,
-jk_uri_worker_map_t::map_uri_to_worker,
-Found an exact match %s - %s\n,
-uwr-worker_name,
-uwr-context );
+jk_log(l,
+ JK_LOG_DEBUG,
+ jk_uri_worker_map_t::map_uri_to_worker,
+ Found an exact match %s - %s\n,
+ uwr-worker_name,
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_util.c
mturk 2004/10/08 00:20:33
Modified:jk/native/common jk_util.c
Log:
Untabify the source and use size_t for strlens.
Revision ChangesPath
1.29 +26 -26jakarta-tomcat-connectors/jk/native/common/jk_util.c
Index: jk_util.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- jk_util.c 13 Jul 2004 13:58:10 - 1.28
+++ jk_util.c 8 Oct 2004 07:20:33 - 1.29
@@ -33,7 +33,7 @@
#define MX_OF_WORKER(mx)
#define MS_OF_WORKER(ms)
#define CP_OF_WORKER(class_path)
-#define BRIDGE_OF_WORKER (bridge)
+#define BRIDGE_OF_WORKER(bridge)
#define JVM_OF_WORKER (jvm_lib)
#define LIBPATH_OF_WORKER (ld_path)
#define CMD_LINE_OF_WORKER (cmd_line)
@@ -45,9 +45,9 @@
#define CACHE_OF_WORKER (cachesize)
#define CACHE_TIMEOUT_OF_WORKER (cache_timeout)
#define RECOVERY_OPTS_OF_WORKER (recovery_options)
-#define CONNECT_TIMEOUT_OF_WORKER(connect_timeout)
-#define PREPOST_TIMEOUT_OF_WORKER(prepost_timeout)
-#define REPLY_TIMEOUT_OF_WORKER (reply_timeout)
+#define CONNECT_TIMEOUT_OF_WORKER (connect_timeout)
+#define PREPOST_TIMEOUT_OF_WORKER (prepost_timeout)
+#define REPLY_TIMEOUT_OF_WORKER (reply_timeout)
#define SOCKET_TIMEOUT_OF_WORKER(socket_timeout)
#define SOCKET_KEEPALIVE_OF_WORKER (socket_keepalive)
#define LOAD_FACTOR_OF_WORKER (lbfactor)
@@ -62,13 +62,13 @@
#define DEFAULT_WORKER JK_AJP12_WORKER_NAME
#define WORKER_LIST_PROPERTY_NAME (worker.list)
#define DEFAULT_LB_FACTOR (1.0)
-#define LOG_FORMAT (log_format)
+#define LOG_FORMAT (log_format)
-#define TOMCAT32_BRIDGE_NAME (tomcat32)
-#define TOMCAT33_BRIDGE_NAME (tomcat33)
-#define TOMCAT40_BRIDGE_NAME (tomcat40)
-#define TOMCAT41_BRIDGE_NAME (tomcat41)
-#define TOMCAT50_BRIDGE_NAME (tomcat5)
+#define TOMCAT32_BRIDGE_NAME(tomcat32)
+#define TOMCAT33_BRIDGE_NAME(tomcat33)
+#define TOMCAT40_BRIDGE_NAME(tomcat40)
+#define TOMCAT41_BRIDGE_NAME(tomcat41)
+#define TOMCAT50_BRIDGE_NAME(tomcat5)
#define HUGE_BUFFER_SIZE (8*1024)
#define LOG_LINE_SIZE(1024)
@@ -141,7 +141,7 @@
if( l
(l-level = level || level == JK_LOG_REQUEST_LEVEL)
l-logger_private what) {
-unsigned sz = strlen(what);
+size_t sz = strlen(what);
if(sz) {
file_logger_t *p = l-logger_private;
fwrite(what, 1, sz, p-logfile);
@@ -241,7 +241,7 @@
#endif
char *f = (char *)(file + strlen(file) - 1);
va_list args;
-int used = 0;
+size_t used = 0;
while(f != file '\\' != *f '/' != *f) {
f--;
@@ -685,25 +685,25 @@
unsigned *bt)
{
char buf[1024];
- char *type;
-
+char *type;
+
if(m bt wname) {
sprintf(buf, %s.%s.%s, PREFIX_OF_WORKER, wname, BRIDGE_OF_WORKER);
type = map_get_string(m, buf, NULL);
if(type) {
- if (! strcasecmp(type, TOMCAT32_BRIDGE_NAME))
- *bt = TC32_BRIDGE_TYPE;
- else if (! strcasecmp(type, TOMCAT33_BRIDGE_NAME))
- *bt = TC33_BRIDGE_TYPE;
- else if (! strcasecmp(type, TOMCAT40_BRIDGE_NAME))
- *bt = TC40_BRIDGE_TYPE;
- else if (! strcasecmp(type, TOMCAT41_BRIDGE_NAME))
- *bt = TC41_BRIDGE_TYPE;
- else if (! strcasecmp(type, TOMCAT50_BRIDGE_NAME))
- *bt = TC50_BRIDGE_TYPE;
-
+if (! strcasecmp(type, TOMCAT32_BRIDGE_NAME))
+*bt = TC32_BRIDGE_TYPE;
+else if (! strcasecmp(type, TOMCAT33_BRIDGE_NAME))
+*bt = TC33_BRIDGE_TYPE;
+else if (! strcasecmp(type, TOMCAT40_BRIDGE_NAME))
+*bt = TC40_BRIDGE_TYPE;
+else if (! strcasecmp(type, TOMCAT41_BRIDGE_NAME))
+*bt = TC41_BRIDGE_TYPE;
+else if (! strcasecmp(type, TOMCAT50_BRIDGE_NAME))
+*bt = TC50_BRIDGE_TYPE;
+
return JK_TRUE;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_md5.c
mturk 2004/10/08 00:22:58
Modified:jk/native/common jk_md5.c
Log:
Untabify the source code
Revision ChangesPath
1.10 +119 -135 jakarta-tomcat-connectors/jk/native/common/jk_md5.c
Index: jk_md5.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_md5.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- jk_md5.c 24 Feb 2004 08:45:48 - 1.9
+++ jk_md5.c 8 Oct 2004 07:22:58 - 1.10
@@ -119,10 +119,10 @@
#define S44 21
static void MD5Transform(JK_UINT4 state[4], const unsigned char block[64]);
-static void Encode(unsigned char *output, const JK_UINT4 *input, unsigned int len);
-static void Decode(JK_UINT4 *output, const unsigned char *input, unsigned int len);
+static void Encode(unsigned char *output, const JK_UINT4 *input, size_t len);
+static void Decode(JK_UINT4 *output, const unsigned char *input, size_t len);
static void jk_MD5Init(JK_MD5_CTX *context);
-static void jk_MD5Update(JK_MD5_CTX *context, const unsigned char *input, unsigned
int inputLen);
+static void jk_MD5Update(JK_MD5_CTX *context, const unsigned char *input, size_t
inputLen);
/*static void jk_MD5Final(unsigned char digest[JK_MD5_DIGESTSIZE], JK_MD5_CTX
*context);*/
static unsigned char PADDING[64] =
@@ -184,17 +184,17 @@
context.
*/
static void jk_MD5Update(JK_MD5_CTX *context, const unsigned char *input,
- unsigned int inputLen)
+ size_t inputLen)
{
-unsigned int i, idx, partLen;
+size_t i, idx, partLen;
/* Compute number of bytes mod 64 */
-idx = (unsigned int) ((context-count[0] 3) 0x3F);
+idx = (size_t) ((context-count[0] 3) 0x3F);
/* Update number of bits */
if ((context-count[0] += ((JK_UINT4) inputLen 3))
- ((JK_UINT4) inputLen 3)) {
- context-count[1]++;
+ ((JK_UINT4) inputLen 3)) {
+context-count[1]++;
}
context-count[1] += (JK_UINT4) inputLen 29;
@@ -203,36 +203,36 @@
/* Transform as many times as possible. */
#ifndef CHARSET_EBCDIC
if (inputLen = partLen) {
- memcpy(context-buffer[idx], input, partLen);
- MD5Transform(context-state, context-buffer);
+memcpy(context-buffer[idx], input, partLen);
+MD5Transform(context-state, context-buffer);
- for (i = partLen; i + 63 inputLen; i += 64) {
- MD5Transform(context-state, input[i]);
- }
+for (i = partLen; i + 63 inputLen; i += 64) {
+MD5Transform(context-state, input[i]);
+}
- idx = 0;
+idx = 0;
}
else {
- i = 0;
+i = 0;
}
/* Buffer remaining input */
memcpy(context-buffer[idx], input[i], inputLen - i);
#else /*CHARSET_EBCDIC*/
if (inputLen = partLen) {
- ebcdic2ascii(context-buffer[idx], input, partLen);
- MD5Transform(context-state, context-buffer);
+ebcdic2ascii(context-buffer[idx], input, partLen);
+MD5Transform(context-state, context-buffer);
- for (i = partLen; i + 63 inputLen; i += 64) {
- unsigned char inp_tmp[64];
- ebcdic2ascii(inp_tmp, input[i], 64);
- MD5Transform(context-state, inp_tmp);
- }
+for (i = partLen; i + 63 inputLen; i += 64) {
+unsigned char inp_tmp[64];
+ebcdic2ascii(inp_tmp, input[i], 64);
+MD5Transform(context-state, inp_tmp);
+}
- idx = 0;
+idx = 0;
}
else {
- i = 0;
+i = 0;
}
/* Buffer remaining input */
@@ -246,7 +246,7 @@
void JK_METHOD jk_MD5Final(unsigned char digest[16], JK_MD5_CTX *context)
{
unsigned char bits[8];
-unsigned int idx, padLen;
+size_t idx, padLen;
/* Save number of bits */
@@ -268,7 +268,7 @@
#endif /*CHARSET_EBCDIC*/
/* Pad out to 56 mod 64. */
-idx = (unsigned int) ((context-count[0] 3) 0x3f);
+idx = (size_t) ((context-count[0] 3) 0x3f);
padLen = (idx 56) ? (56 - idx) : (120 - idx);
jk_MD5Update(context, (const unsigned char *)PADDING, padLen);
@@ -290,76 +290,76 @@
Decode(x, block, 64);
/* Round 1 */
-FF(a, b, c, d, x[0], S11, 0xd76aa478); /* 1 */
-FF(d, a, b, c, x[1], S12, 0xe8c7b756); /* 2 */
-FF(c, d, a, b, x[2], S13, 0x242070db); /* 3 */
-FF(b, c, d, a, x[3], S14, 0xc1bdceee); /* 4 */
-FF(a, b, c, d, x[4], S11, 0xf57c0faf); /* 5 */
-FF(d, a, b, c, x[5], S12, 0x4787c62a); /* 6 */
-FF(c, d, a, b, x[6], S13, 0xa8304613); /* 7 */
-FF(b, c, d, a, x[7], S14, 0xfd469501); /* 8 */
-FF(a, b, c, d, x[8], S11, 0x698098d8); /* 9 */
-FF(d, a, b, c, x[9], S12, 0x8b44f7af); /* 10 */
-FF(c, d, a, b, x[10], S13, 0x5bb1); /*
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_md5.h
mturk 2004/10/08 00:23:51
Modified:jk/native/common jk_md5.h
Log:
Int is not 32 bits on all platforms.
Revision ChangesPath
1.3 +12 -4 jakarta-tomcat-connectors/jk/native/common/jk_md5.h
Index: jk_md5.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_md5.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- jk_md5.h 24 Feb 2004 08:45:48 - 1.2
+++ jk_md5.h 8 Oct 2004 07:23:51 - 1.3
@@ -56,13 +56,21 @@
#define JK_MD5_DIGESTSIZE 16
/* JK_UINT4 defines a four byte word */
+#if HAVE_APR
+typedef apr_uint32_t JK_UINT4;
+#else
+#ifdef WIN32
+typedef DWORD JK_UINT4;
+#else
typedef unsigned int JK_UINT4;
+#endif
+#endif /* HAVE_APR */
/* MD5 context. */
typedef struct {
-JK_UINT4 state[4]; /* state (ABCD) */
-JK_UINT4 count[2]; /* number of bits, modulo 2^64 (lsb first) */
-unsigned char buffer[64];/* input buffer */
+JK_UINT4 state[4]; /* state (ABCD) */
+JK_UINT4 count[2]; /* number of bits, modulo 2^64 (lsb first) */
+unsigned char buffer[64]; /* input buffer */
} JK_MD5_CTX;
/*
@@ -80,4 +88,4 @@
}
#endif
-#endif /* !JK_APACHE_MD5_H */
+#endif /* !JK_APACHE_MD5_H */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp14_worker.c
mturk 2004/10/08 00:18:04
Modified:jk/native/common jk_ajp14_worker.c
Log:
Comment the login service for now.
Revision ChangesPath
1.20 +4 -1 jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.c
Index: jk_ajp14_worker.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.c,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- jk_ajp14_worker.c 24 Feb 2004 08:45:48 - 1.19
+++ jk_ajp14_worker.c 8 Oct 2004 07:18:04 - 1.20
@@ -39,7 +39,10 @@
{
int cmd;
int i,j;
+#if 0
+/* Not used for now */
jk_login_service_t *jl = ae-worker-login;
+#endif
jk_context_item_t *ci;
jk_context_t*c;
char*buf;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31590] - Problem deploying a WAR with a META-INF/context.xml file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31590 Problem deploying a WAR with a META-INF/context.xml file --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 07:30 --- ok. Thanks for the information. So to summarize you're saying that the context.xml file cannot be used to tell the war to be deployed under a given context? I thought that was one of the main feature of the context.xml... At least that's what I was using it for till now... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common .indent.pro
mturk 2004/10/08 00:34:44 Added: jk/native/common .indent.pro Log: Indent file for mod_jk. Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native/common/.indent.pro Index: .indent.pro === -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1 -nut -ncs -Tjk_env_t -Tjk_worker_t -Tjk_worker_env_t -Tjk_endpoint_t -Tjk_channel_t -Tjk_sockbuf_t -Tjk_msg_t -Tjk_msg_buf_t -Tjk_map_t -Tjk_uri_worker_map_t -Tjk_pool_t -Tjk_pool_atom_t -Tjk_logger_t -Tjk_ws_service_t -Tjk_context_item_t -Tjk_context_t -Tjk_login_service_t - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31590] - Problem deploying a WAR with a META-INF/context.xml file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31590 Problem deploying a WAR with a META-INF/context.xml file --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 07:37 --- Indeed, since the place where it will be deployed is found using the war name as well. Conflicting information causes trouble, unfortunately, and needs additional complexity to handle (and the deployer is complex enough already :( ). Similarly, if you deploy a .xml file directly, its name would be used to get the webapp path. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Automated reply from h4host@www.h4host.com
Attention: A Spyware or virus was found in an Email message you sent. This Email scanner intercepted it and stopped the entire message reaching its destination. Please update your Spyware or virus scanner or contact your IT support personnel as soon as possible as you have a virus or Spyware on your system. We Recommend using BulletProofSoft.com 's Spyware/Virus/Trojan remover For more information visit: http://www.Bulletproofsoft.com Note: Spyware is a relatively new kind of threat that common anti-virus applications do not yet cover. If you are seeing things like excessive popups, new toolbars in your Internet Explorer that you didn't intentionally install, if your browser crashes, or if you browser start page has changed without your knowing, you most probably have spyware. Visit BulletProofSoft.com for more information http://www.bulletproofsoft.com Virus/Spyware detected by BulletProofSoft.com Spyware Remover.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp12_worker.c jk_ajp13.c jk_ajp13_worker.c jk_ajp14.c jk_ajp14_worker.c jk_ajp_common.c jk_connect.c jk_context.c jk_jni_worker.c jk_lb_worker.c jk_map.c jk_md5.c jk_msg_buff.c jk_nwmain.c jk_pool.c jk_sockbuf.c jk_uri_worker_map.c jk_util.c jk_worker.c jk_ajp12_worker.h jk_ajp13.h jk_ajp13_worker.h jk_ajp14.h jk_ajp14_worker.h jk_ajp_common.h jk_connect.h jk_context.h jk_global.h jk_jni_worker.h jk_lb_worker.h jk_logger.h jk_map.h jk_md5.h jk_msg_buff.h jk_mt.h jk_pool.h jk_service.h jk_sockbuf.h jk_uri_worker_map.h jk_util.h jk_version.h jk_worker.h jk_worker_list.h
mturk 2004/10/08 00:50:41 Modified:jk/native/common jk_ajp12_worker.c jk_ajp13.c jk_ajp13_worker.c jk_ajp14.c jk_ajp14_worker.c jk_ajp_common.c jk_connect.c jk_context.c jk_jni_worker.c jk_lb_worker.c jk_map.c jk_md5.c jk_msg_buff.c jk_nwmain.c jk_pool.c jk_sockbuf.c jk_uri_worker_map.c jk_util.c jk_worker.c jk_ajp12_worker.h jk_ajp13.h jk_ajp13_worker.h jk_ajp14.h jk_ajp14_worker.h jk_ajp_common.h jk_connect.h jk_context.h jk_global.h jk_jni_worker.h jk_lb_worker.h jk_logger.h jk_map.h jk_md5.h jk_msg_buff.h jk_mt.h jk_pool.h jk_service.h jk_sockbuf.h jk_uri_worker_map.h jk_util.h jk_version.h jk_worker.h jk_worker_list.h Log: Indent the entire source code, unifying all those different styles. Revision ChangesPath 1.14 +266 -250 jakarta-tomcat-connectors/jk/native/common/jk_ajp12_worker.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp12_worker.c.diff?r1=1.13r2=1.14 1.10 +5 -5 jakarta-tomcat-connectors/jk/native/common/jk_ajp13.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp13.c.diff?r1=1.9r2=1.10 1.15 +38 -42jakarta-tomcat-connectors/jk/native/common/jk_ajp13_worker.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp13_worker.c.diff?r1=1.14r2=1.15 1.20 +216 -186 jakarta-tomcat-connectors/jk/native/common/jk_ajp14.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp14.c.diff?r1=1.19r2=1.20 1.21 +200 -192 jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.c.diff?r1=1.20r2=1.21 1.59 +540 -503 jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c.diff?r1=1.58r2=1.59 1.27 +85 -88jakarta-tomcat-connectors/jk/native/common/jk_connect.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c.diff?r1=1.26r2=1.27 1.11 +59 -54jakarta-tomcat-connectors/jk/native/common/jk_context.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_context.c.diff?r1=1.10r2=1.11 1.26 +479 -506 jakarta-tomcat-connectors/jk/native/common/jk_jni_worker.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_jni_worker.c.diff?r1=1.25r2=1.26 1.24 +222 -227 jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c.diff?r1=1.23r2=1.24 1.14 +130 -141 jakarta-tomcat-connectors/jk/native/common/jk_map.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_map.c.diff?r1=1.13r2=1.14 1.11 +123 -120 jakarta-tomcat-connectors/jk/native/common/jk_md5.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_md5.c.diff?r1=1.10r2=1.11 1.18 +99 -122 jakarta-tomcat-connectors/jk/native/common/jk_msg_buff.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_msg_buff.c.diff?r1=1.17r2=1.18 1.6 +17 -23jakarta-tomcat-connectors/jk/native/common/jk_nwmain.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_nwmain.c.diff?r1=1.5r2=1.6 1.9 +23 -34jakarta-tomcat-connectors/jk/native/common/jk_pool.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_pool.c.diff?r1=1.8r2=1.9 1.10 +57 -60jakarta-tomcat-connectors/jk/native/common/jk_sockbuf.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_sockbuf.c.diff?r1=1.9r2=1.10 1.23 +245 -220 jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c.diff?r1=1.22r2=1.23 1.30 +248 -302 jakarta-tomcat-connectors/jk/native/common/jk_util.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c.diff?r1=1.29r2=1.30 1.16 +81 -85jakarta-tomcat-connectors/jk/native/common/jk_worker.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_worker.c.diff?r1=1.15r2=1.16 1.7 +8 -8 jakarta-tomcat-connectors/jk/native/common/jk_ajp12_worker.h http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp12_worker.h.diff?r1=1.6r2=1.7
ajp_proxy and unix-socket
Hi to all, Did there is plan to add unix-socket support in ajp_proxy ? Some people seems to use JK2 for the quick unix-socket and wonder if they could use them in mod_proxy/ajp_proxy. BTW, since ajp_proxy is 100% APR it should be easier ? Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/netscape jk_nsapi_plugin.c
mturk 2004/10/08 01:55:14 Modified:jk/native/apache-1.3 mod_jk.c jk/native/apache-2.0 mod_jk.c jk/native/domino dsapifilter.h inifile.c inifile.h jk_dsapi_plugin.c jk/native/iis jk_isapi_plugin.c jk/native/isapi inifile.c inifile.h jk_isapi_plugin.c poolbuf.c poolbuf.h jk/native/jni jk_jnicb.c jk/native/netscape jk_nsapi_plugin.c Log: Indent server sources. Revision ChangesPath 1.48 +601 -569 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c.diff?r1=1.47r2=1.48 1.96 +781 -784 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c.diff?r1=1.95r2=1.96 1.4 +242 -223 jakarta-tomcat-connectors/jk/native/domino/dsapifilter.h http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/domino/dsapifilter.h.diff?r1=1.3r2=1.4 1.6 +163 -165 jakarta-tomcat-connectors/jk/native/domino/inifile.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/domino/inifile.c.diff?r1=1.5r2=1.6 1.6 +3 -3 jakarta-tomcat-connectors/jk/native/domino/inifile.h http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/domino/inifile.h.diff?r1=1.5r2=1.6 1.14 +677 -667 jakarta-tomcat-connectors/jk/native/domino/jk_dsapi_plugin.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/domino/jk_dsapi_plugin.c.diff?r1=1.13r2=1.14 1.24 +570 -548 jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c.diff?r1=1.23r2=1.24 1.4 +163 -165 jakarta-tomcat-connectors/jk/native/isapi/inifile.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/isapi/inifile.c.diff?r1=1.3r2=1.4 1.4 +3 -3 jakarta-tomcat-connectors/jk/native/isapi/inifile.h http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/isapi/inifile.h.diff?r1=1.3r2=1.4 1.6 +700 -696 jakarta-tomcat-connectors/jk/native/isapi/jk_isapi_plugin.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/isapi/jk_isapi_plugin.c.diff?r1=1.5r2=1.6 1.4 +85 -87jakarta-tomcat-connectors/jk/native/isapi/poolbuf.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/isapi/poolbuf.c.diff?r1=1.3r2=1.4 1.4 +23 -22jakarta-tomcat-connectors/jk/native/isapi/poolbuf.h http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/isapi/poolbuf.h.diff?r1=1.3r2=1.4 1.6 +254 -222 jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c.diff?r1=1.5r2=1.6 1.12 +162 -176 jakarta-tomcat-connectors/jk/native/netscape/jk_nsapi_plugin.c http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/netscape/jk_nsapi_plugin.c.diff?r1=1.11r2=1.12 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problems with SSL_CLIENT_CERT_CHAIN_n from servlet
-Mensaje original- De: jean-frederic clere [mailto:[EMAIL PROTECTED] Enviado el: viernes, 08 de octubre de 2004 8:28 Para: Jesús Luna Asunto: Re: Problems with SSL_CLIENT_CERT_CHAIN_n from servlet I have not (yet) got it working but the idea to have more httpd variables available in the servlet sounds a needed feature. I agree with you about the need for a new set of variables availables to the servlet application (specially in the case of security!), however I've read the Java Servlet Specification v2.4 and it looks like the client's certificate chain should be exposed as an attribute in a mandatory way. The correspondent text from section SRV.4.7 SSL Attributes follows: If there is an SSL certificate associated with the request, it must be exposed by the servlet container to the servlet programmer as an array of objects of type java.security.cert.X509Certificate and accessible via a ServletRequest attribute of javax.servlet.request.X509Certificate. The order of this array is defined as being in ascending order of trust. The first certificate in the chain is the one set by the client, the next is the one used to authenticate the first, and so on. So I still can't figure out why my app can't get them. ___ Jesus Luna Garcia CertiVeR (EU Funded Project) [EMAIL PROTECTED] http://www.certiver.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajp_proxy and unix-socket
Henri Gomez wrote: Hi to all, Did there is plan to add unix-socket support in ajp_proxy ? Some people seems to use JK2 for the quick unix-socket and wonder if they could use them in mod_proxy/ajp_proxy. BTW, since ajp_proxy is 100% APR it should be easier ? Think that APR doesn't support AF_UNIX. My plan is to try to port them back to mod_jk from jk2. MT. smime.p7s Description: S/MIME Cryptographic Signature
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core NamingContextListener.java LocalStrings.properties
remm2004/10/08 02:34:02
Modified:catalina/src/share/org/apache/catalina/core
NamingContextListener.java LocalStrings.properties
Log:
- Register datasource with JMX.
- With DBCP, this is enough to provide JMX management and monitoring. It might work
well with many other data sources which might not
register themselves in JMX and expose their stuff in a java bean fashion. Note: I
didn't test it a lot, let me know how well it works.
Revision ChangesPath
1.10 +77 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/NamingContextListener.java
Index: NamingContextListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/NamingContextListener.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- NamingContextListener.java26 Jul 2004 16:04:01 - 1.9
+++ NamingContextListener.java8 Oct 2004 09:34:02 - 1.10
@@ -20,10 +20,13 @@
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
+import java.util.HashMap;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.StringTokenizer;
+import javax.management.MalformedObjectNameException;
+import javax.management.ObjectName;
import javax.naming.NameAlreadyBoundException;
import javax.naming.NamingException;
import javax.naming.Reference;
@@ -33,10 +36,13 @@
import org.apache.catalina.ContainerEvent;
import org.apache.catalina.ContainerListener;
import org.apache.catalina.Context;
+import org.apache.catalina.Engine;
+import org.apache.catalina.Host;
import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.Server;
+import org.apache.catalina.Service;
import org.apache.catalina.deploy.ContextEjb;
import org.apache.catalina.deploy.ContextEnvironment;
import org.apache.catalina.deploy.ContextLocalEjb;
@@ -48,6 +54,7 @@
import org.apache.catalina.util.StringManager;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
+import org.apache.commons.modeler.Registry;
import org.apache.naming.ContextAccessController;
import org.apache.naming.ContextBindings;
import org.apache.naming.EjbRef;
@@ -119,6 +126,12 @@
*/
protected javax.naming.Context envCtx = null;
+
+/**
+ * Objectnames hashtable.
+ */
+protected HashMap objectNames = new HashMap();
+
/**
* The string manager for this package.
@@ -631,6 +644,53 @@
/**
+ * Create an codeObjectName/code for this
+ * codeContextResource/code object.
+ *
+ * @param domain Domain in which this name is to be created
+ * @param resource The ContextResource to be named
+ *
+ * @exception MalformedObjectNameException if a name cannot be created
+ */
+protected ObjectName createObjectName(ContextResource resource)
+throws MalformedObjectNameException {
+
+String domain = null;
+if (container instanceof StandardServer) {
+domain = ((StandardServer) container).getDomain();
+} else if (container instanceof ContainerBase) {
+domain = ((ContainerBase) container).getDomain();
+}
+if (domain == null) {
+domain = Catalina;
+}
+
+ObjectName name = null;
+String quotedResourceName = ObjectName.quote(resource.getName());
+if (container instanceof Server) {
+name = new ObjectName(domain + :type=DataSource +
+,class= + resource.getType() +
+,name= + quotedResourceName);
+} else if (container instanceof Context) {
+String path = ((Context)container).getPath();
+if (path.length() 1)
+path = /;
+Host host = (Host) ((Context)container).getParent();
+Engine engine = (Engine) host.getParent();
+Service service = engine.getService();
+name = new ObjectName(domain + :type=DataSource +
+,path= + path +
+,host= + host.getName() +
+,class= + resource.getType() +
+,name= + quotedResourceName);
+}
+
+return (name);
+
+}
+
+
+/**
* Set the specified EJBs in the naming context.
*/
public void addEjb(ContextEjb ejb) {
@@ -778,6 +838,17 @@
logger.error(sm.getString(naming.bindFailed, e));
}
+if
cvs commit: jakarta-tomcat-connectors/jk/native/iis jk_isapi_plugin.c
mturk 2004/10/08 03:37:12
Modified:jk/native/iis jk_isapi_plugin.c
Log:
Remove computing properties file on each dll event.
Fix reporting error page to client, and few compile time warnigs.
Revision ChangesPath
1.25 +43 -38jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c
Index: jk_isapi_plugin.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- jk_isapi_plugin.c 8 Oct 2004 08:55:13 - 1.24
+++ jk_isapi_plugin.c 8 Oct 2004 10:37:12 - 1.25
@@ -71,6 +71,7 @@
#define BAD_PATH-2
#define MAX_SERVERNAME 128
+#define JK_TOLOWER(x) ((char)tolower((unsigned char)(x)))
#define GET_SERVER_VARIABLE_VALUE(name, place) \
do { \
@@ -128,7 +129,8 @@
static jk_worker_env_t worker_env;
-struct isapi_private_data
+typedef struct isapi_private_data_t isapi_private_data_t;
+struct isapi_private_data_t
{
jk_pool_t p;
@@ -136,7 +138,6 @@
unsigned bytes_read_so_far;
LPEXTENSION_CONTROL_BLOCK lpEcb;
};
-typedef struct isapi_private_data isapi_private_data_t;
static int JK_METHOD start_response(jk_ws_service_t *s,
@@ -171,7 +172,7 @@
static int base64_encode_cert_len(int len);
static int base64_encode_cert(char *encoded,
- const unsigned char *string, int len);
+ const char *string, int len);
static char x2c(const char *what)
@@ -256,8 +257,10 @@
else
l = 0;
n = l;
-while ((name[n] = name[m]))
-(++n, ++m);
+while ((name[n] = name[m])) {
+n++;
+m++;
+}
}
else
++l;
@@ -319,20 +322,19 @@
{
const unsigned char *s = (const unsigned char *)path;
unsigned char *d = (unsigned char *)dest;
-unsigned char *e = dest + destsize - 1;
-unsigned char *ee = dest + destsize - 3;
-unsigned c;
+unsigned char *e = d + destsize - 1;
+unsigned char *ee = d + destsize - 3;
-while ((c = *s)) {
-if (TEST_CHAR(c, T_OS_ESCAPE_PATH)) {
+while (*s) {
+if (TEST_CHAR(*s, T_OS_ESCAPE_PATH)) {
if (d = ee)
return JK_FALSE;
-d = c2x(c, d);
+d = c2x(*s, d);
}
else {
if (d = e)
return JK_FALSE;
-*d++ = c;
+*d++ = *s;
}
++s;
}
@@ -344,7 +346,7 @@
{
char *c = uri;
while (*c) {
-*c = tolower(*c);
+*c = JK_TOLOWER(*c);
c++;
}
if (strstr(uri, web-inf)) {
@@ -360,17 +362,16 @@
static void write_error_response(PHTTP_FILTER_CONTEXT pfc, char *status,
char *msg)
{
-char crlf[3] = { (char)13, (char)10, '\0' };
char ctype[30];
-DWORD len = strlen(msg);
+size_t len = strlen(msg);
-sprintf(ctype, Content-Type:text/html%s%s, crlf, crlf);
+strcpy(ctype, Content-Type:text/html\r\n\r\n);
/* reject !!! */
pfc-ServerSupportFunction(pfc,
SF_REQ_SEND_RESPONSE_HEADER,
- status, (DWORD) crlf, (DWORD) ctype);
-pfc-WriteClient(pfc, msg, len, 0);
+ status, (DWORD) ctype[0], 0);
+pfc-WriteClient(pfc, msg, (LPDWORD)len, 0);
}
@@ -395,7 +396,7 @@
if (s s-ws_private) {
isapi_private_data_t *p = s-ws_private;
if (!p-request_started) {
-DWORD len_of_status;
+size_t len_of_status;
char *status_str;
char *headers_str;
@@ -415,8 +416,7 @@
* Create response headers string
*/
if (num_of_headers) {
-unsigned i;
-unsigned len_of_headers;
+size_t i, len_of_headers;
for (i = 0, len_of_headers = 0; i num_of_headers; i++) {
len_of_headers += strlen(header_names[i]);
len_of_headers += strlen(header_values[i]);
@@ -442,7 +442,7 @@
if (!p-lpEcb-ServerSupportFunction(p-lpEcb-ConnID,
HSE_REQ_SEND_RESPONSE_HEADER,
status_str,
- (LPDWORD) len_of_status,
+ (LPDWORD) len_of_status,
cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt
mturk 2004/10/08 04:08:47 Modified:jk/native CHANGES.txt Log: Recent changes to jk. Revision ChangesPath 1.22 +7 -1 jakarta-tomcat-connectors/jk/native/CHANGES.txt Index: CHANGES.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- CHANGES.txt 14 Jul 2004 14:49:40 - 1.21 +++ CHANGES.txt 8 Oct 2004 11:08:47 - 1.22 @@ -1,6 +1,12 @@ JAKARTA TOMCAT CONNECTORS (JK) CHANGELOG:-*-text-*- Last modified at [$Date$] +Changes with JK 1.2.7 +* Fix iis redirector that was figuring .properties + file on each request [mturk] +* Start fixing 64/32 bit compatibility issues [mturk] +* Indent all source files. [mturk] + Changes with JK 1.2.6 * Fix POST Recovery problems in LB mode [hgomez] * Add CPING/CPONG support to avoid problems with hang tomcats [hgomez] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JK Todo List
Hi, Here is my Todo List for JK: - Documentation - Use Apache coding style (already done 90%) using simple .indent.pro - Fix all 64/32 bit compatibility issues. - Backport IIS Worker thread pool from JK2. - Backport some ajp messaging stuff from proxy_ajp (mostly performance). - Backport shared memory from JK2 for load balancer worker. What's more important: - Documentation - Put the JK2 in 'maintainer' mode. - Inform our users about that decision. - Inform out users that we are still in native-tomcat business :) Long term plans: - Documentation - Backport unix sockets from JK2 - Backport JNI from JK2 with lots improvements. - Use 1.4 API on Java side - Add full AJP14 protocol support - Add encryption and compression to AJP protocol - APR-ize JK Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
DO NOT REPLY [Bug 26523] - StandardEngine make two init() calls at sub Mbeans
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26523. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26523 StandardEngine make two init() calls at sub Mbeans [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 12:39 --- Alright, it's been 2.5 months since this enhancement was posted. Peter, if you still want to do it, go ahead, since you're now a committer and have the required karma ;) You can also reopen/resolve this issue if you want, but for now I'm closing since it has no impact, and no one cares about it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31581] - Tomcat Manager deploys the web application twice
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31581. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31581 Tomcat Manager deploys the web application twice --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 13:09 --- I guess by the new code you mean Tomcat 5.5.x, since in Tomcat 5.0.x you cannot use config and path parameter together, or more precisely path parameter is ignored in that case. I still think this is a bug, even because the Tomcat Manager's html interface offers such parameter usage. I think that setting the autoDeploy property to false is currently the only way how to get rid of the deuble deploy on 5.0.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31581] - Tomcat Manager deploys the web application twice
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31581. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31581 Tomcat Manager deploys the web application twice --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 13:11 --- And I don't think the behavior you describe is a bug -- you don't want autoDeploy, then turn if off. It's a boolean attribute exposed in server.xml, couldn't be easier to modify. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
+1, will help as much as possible On Fri, 08 Oct 2004 13:28:49 +0200, Mladen Turk [EMAIL PROTECTED] wrote: Hi, Here is my Todo List for JK: - Documentation - Use Apache coding style (already done 90%) using simple .indent.pro - Fix all 64/32 bit compatibility issues. - Backport IIS Worker thread pool from JK2. - Backport some ajp messaging stuff from proxy_ajp (mostly performance). - Backport shared memory from JK2 for load balancer worker. What's more important: - Documentation - Put the JK2 in 'maintainer' mode. - Inform our users about that decision. - Inform out users that we are still in native-tomcat business :) Long term plans: - Documentation - Backport unix sockets from JK2 - Backport JNI from JK2 with lots improvements. - Use 1.4 API on Java side - Add full AJP14 protocol support - Add encryption and compression to AJP protocol - APR-ize JK Regards, MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajp_proxy and unix-socket
May be we could ask us to work on this ? porting them from jk2 to jk is a good idea On Fri, 08 Oct 2004 11:06:08 +0200, Mladen Turk [EMAIL PROTECTED] wrote: Henri Gomez wrote: Hi to all, Did there is plan to add unix-socket support in ajp_proxy ? Some people seems to use JK2 for the quick unix-socket and wonder if they could use them in mod_proxy/ajp_proxy. BTW, since ajp_proxy is 100% APR it should be easier ? Think that APR doesn't support AF_UNIX. My plan is to try to port them back to mod_jk from jk2. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Mladen Turk wrote: Hi, Here is my Todo List for JK: - Documentation - Use Apache coding style (already done 90%) using simple .indent.pro - Fix all 64/32 bit compatibility issues. - Backport IIS Worker thread pool from JK2. - Backport some ajp messaging stuff from proxy_ajp (mostly performance). - Backport shared memory from JK2 for load balancer worker. What's more important: - Documentation - Put the JK2 in 'maintainer' mode. - Inform our users about that decision. - Inform out users that we are still in native-tomcat business :) Long term plans: - Documentation - Backport unix sockets from JK2 - Backport JNI from JK2 with lots improvements. I still don't see benefits in JNI as a transport for JK. Only trouble (no matter how I look at it, it seems like it would actually make the whole system much less robust) and complexity. Did I miss something ? - Use 1.4 API on Java side - Add full AJP14 protocol support - Add encryption and compression to AJP protocol - APR-ize JK Rmy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Remy Maucherat wrote: - Backport JNI from JK2 with lots improvements. I still don't see benefits in JNI as a transport for JK. Only trouble (no matter how I look at it, it seems like it would actually make the whole system much less robust) and complexity. Did I miss something ? The JNI was not meant to be used for transport layer. Sorry for the confusion. It will became a part of dynamic configuration, so that we don't need to write everything in C. Still this is very early draft, and it should be at the end of list, cause it might happened that it simply won't work :). MT. smime.p7s Description: S/MIME Cryptographic Signature
DO NOT REPLY [Bug 31473] - Windows installer for tomcat 5.5 mess up with tomcat 5.0 service
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31473. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31473 Windows installer for tomcat 5.5 mess up with tomcat 5.0 service [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 15:10 --- Situation is the same with two 5.0.X services. You can not install two versions of them using installer. The installer is meant to be used for users needing single TC, not such specific demands. Also introducing customizable service name during install process would be confusing for novice users. Also service name reflects service binaries to enable simple double-click on executable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with SSL_CLIENT_CERT_CHAIN_n from servlet
Yes, it is a known problem that using the AJP/1.3 Connector isn't spec-complient. The Ajp13 protocol is still stuck at Servlet v2.2, and only exposes one cert. - Original Message - From: Jesús Luna [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 08, 2004 1:55 AM Subject: RE: Problems with SSL_CLIENT_CERT_CHAIN_n from servlet -Mensaje original- De: jean-frederic clere [mailto:[EMAIL PROTECTED] Enviado el: viernes, 08 de octubre de 2004 8:28 Para: Jesús Luna Asunto: Re: Problems with SSL_CLIENT_CERT_CHAIN_n from servlet I have not (yet) got it working but the idea to have more httpd variables available in the servlet sounds a needed feature. I agree with you about the need for a new set of variables availables to the servlet application (specially in the case of security!), however I've read the Java Servlet Specification v2.4 and it looks like the client's certificate chain should be exposed as an attribute in a mandatory way. The correspondent text from section SRV.4.7 SSL Attributes follows: If there is an SSL certificate associated with the request, it must be exposed by the servlet container to the servlet programmer as an array of objects of type java.security.cert.X509Certificate and accessible via a ServletRequest attribute of javax.servlet.request.X509Certificate. The order of this array is defined as being in ascending order of trust. The first certificate in the chain is the one set by the client, the next is the one used to authenticate the first, and so on. So I still can't figure out why my app can't get them. ___ Jesus Luna Garcia CertiVeR (EU Funded Project) [EMAIL PROTECTED] http://www.certiver.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Remy Maucherat wrote: - Backport JNI from JK2 with lots improvements. I still don't see benefits in JNI as a transport for JK. Only trouble (no matter how I look at it, it seems like it would actually make the whole system much less robust) and complexity. Did I miss something ? I have to agree - for Apache ( even 2 ) the complexity of multiprocess is too big and it's not worth it in almost all cases. But having a jni library to access OS-specific features is not a bad idea. For example registry, change UID ( I know c-daemon could do the same), unix sockets, etc. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29521] - No destroy methods called on service shutdown
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29521. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29521 No destroy methods called on service shutdown --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 15:56 --- I would like to close that bug. There has been some work on procrun recently that surely address those issues. Can anyone test if this is the case with the latest distribution, or at least provide a simple test case (in java please :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch - Original Message - From: Mladen Turk [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 08, 2004 4:28 AM Subject: JK Todo List Hi, Here is my Todo List for JK: - Documentation - Use Apache coding style (already done 90%) using simple .indent.pro - Fix all 64/32 bit compatibility issues. - Backport IIS Worker thread pool from JK2. - Backport some ajp messaging stuff from proxy_ajp (mostly performance). - Backport shared memory from JK2 for load balancer worker. What's more important: - Documentation - Put the JK2 in 'maintainer' mode. - Inform our users about that decision. - Inform out users that we are still in native-tomcat business :) Long term plans: - Documentation - Backport unix sockets from JK2 - Backport JNI from JK2 with lots improvements. I agree with Remy here. It's not worth doing with the existing codebase. If you want JNI, you need to do it again from scratch. - Use 1.4 API on Java side - Add full AJP14 protocol support -0. This is what proxy_ajp is for. - Add encryption and compression to AJP protocol - APR-ize JK I'm very strongly -1 on requiring APR in JK. The main purpose of JK is for Luddites (myself included) who are still using Apache 1.3. Regards, MT. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Bill Barker wrote: Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch Well, we deceased JK2, for Apache2.1 we have proxy_ajp. Until Apache2.1 becomes the only server around the net, I'll stick with JK for all those not running my preferred web server :). MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core NamingContextListener.java LocalStrings.properties
[EMAIL PROTECTED] wrote: remm2004/10/08 02:34:02 Modified:catalina/src/share/org/apache/catalina/core NamingContextListener.java LocalStrings.properties Log: - Register datasource with JMX. - With DBCP, this is enough to provide JMX management and monitoring. It might work well with many other data sources which might not register themselves in JMX and expose their stuff in a java bean fashion. Note: I didn't test it a lot, let me know how well it works. This got requested zillions of time. Can someone test it in a semi production setting to see if it does what it's supposed to do ? (I did a test involving HSQL to see if the MBean was registered, and that's it) Thanks. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Mladen Turk wrote: Bill Barker wrote: Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch Well, we deceased JK2, for Apache2.1 we have proxy_ajp. Until Apache2.1 becomes the only server around the net, I'll stick with JK for all those not running my preferred web server :). Right. However, I think JK 1.2.x needs some level of stability. So APR, large architectural changes, etc seem bad ideas. Of your list, I think documentation (yah !) and the Unix sockets backport would be good (if not too complex), but that's about it. Modifications to the Java side is something independent. The new direction is basically making Apache (which has a continued overwhelming market share) the preferred native webserver, with the others still being supported, but with a limited feature set. For the long term, if you would want better support for the other servers, you can start a 100% APR replacement for JK 1.2 (I think it was a bit like your mod_ajp) if you want to. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31439] - Manager webapp cannot undeploy defunct webapp
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31439. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31439 Manager webapp cannot undeploy defunct webapp [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Remy Maucherat wrote: Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch Well, we deceased JK2, for Apache2.1 we have proxy_ajp. Until Apache2.1 becomes the only server around the net, I'll stick with JK for all those not running my preferred web server :). Right. However, I think JK 1.2.x needs some level of stability. So APR, large architectural changes, etc seem bad ideas. Of your list, I think documentation (yah !) and the Unix sockets backport would be good (if not too complex), but that's about it. Modifications to the Java side is something independent. I think it would rise the stability, but introduce new problems like building APR, etc.. so you are probably right. We'll see. For the long term, if you would want better support for the other servers, you can start a 100% APR replacement for JK 1.2 (I think it was a bit like your mod_ajp) if you want to. I'm surely do. The IIS6 support is something to chase :). MT. smime.p7s Description: S/MIME Cryptographic Signature
[GUMP@brutus]: Project jakarta-tomcat-catalina (in Module jakarta-tomcat-catalina) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project jakarta-tomcat-catalina has an issue affecting its community integration. This issue affects 13 projects. Project State : 'Failed' The following are affected: - avalon-http-context : Avalon SVN - avalon-http-demo : Avalon SVN - avalon-http-examples : Avalon SVN - avalon-http-impl : Avalon SVN - avalon-http-server : Avalon SVN - avalon-http-servlet : Avalon SVN - avalon-http-static : Avalon SVN - avalon-http-test : Avalon SVN - avalon-planet-facilities : Avalon SVN - jakarta-tomcat-5 : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-jk : Connectors to various web servers - metro-reflector-blocks-complete : Avalon SVN Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Output [naming-resources.jar] identifier set to output basename: [naming-resources] -DEBUG- Output [servlets-default.jar] identifier set to output basename: [servlets-default] -DEBUG- Output [naming-common.jar] identifier set to output basename: [naming-common] -DEBUG- Output [catalina.jar] identifier set to output basename: [catalina] -DEBUG- Output [bootstrap.jar] identifier set to output basename: [bootstrap] -DEBUG- Output [servlets-common.jar] identifier set to output basename: [servlets-common] -DEBUG- Output [servlets-invoker.jar] identifier set to output basename: [servlets-invoker] -DEBUG- Dependency on javamail exists, no need to add for property mail.jar. -DEBUG- Dependency on jaf exists, no need to add for property activation.jar. -DEBUG- Dependency on jmx exists, no need to add for property jmx.jar. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property servlet-api.jar. -DEBUG- Dependency on jakarta-servletapi-5-jsp exists, no need to add for property jsp-api.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xml-apis.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xercesImpl.jar. -DEBUG- Dependency on jakarta-tomcat-util exists, no need to add for property tomcat-util.jar. -DEBUG- Dependency on commons-logging exists, no need to add for property commons-logging-api.jar. -DEBUG- Dependency on ant exists, no need to add for property ant.home. -DEBUG- Dependency on jsse exists, no need to add for property jsse.home. -DEBUG- Dependency on jmx exists, no need to add for property jmx.home. -DEBUG- Dependency on jmx exists, no need to add for property jmxtools.jar. -DEBUG- Dependency on jndi exists, no need to add for property jndi.home. -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.home. -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.jar. -DEBUG- Dependency on javamail exists, no need to add for property mail.home. -DEBUG- Dependency on jaf exists, no need to add for property activation.home. -DEBUG- Dependency on jakarta-tomcat-coyote exists, no need to add for property tomcat-coyote.home. -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/gump_work/build_jakarta-tomcat-catalina_jakarta-tomcat-catalina.html Work Name: build_jakarta-tomcat-catalina_jakarta-tomcat-catalina (Type: Build) State: Failed Elapsed: 5 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtomcat33.home=--UnSet-- -Djsp-api.jar=/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar -Djmx.jar=/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar -Djmx.home=/usr/local/gump/packages/jmx-1_2-ri -Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar -Djtc.home=/usr/local/gump/public/workspace/jakarta-tomcat-connectors -Dmail.home=/usr/local/gump/packages/javamail-1.3 -Dant.home=/usr/local/gump/public/workspace/ant/dist -Dsite2.home=/usr/local/gump/public/workspace/jakarta-site2 -Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-08102004.jar
Re: [VOTE] Tomcat 4.1.31
From: Keith Wannamaker [EMAIL PROTECTED] Ballot [ ] Alpha [ ] Beta [X] Stable /Ballot I tested connector bugs 20184 24763 are fixed with this release. All the major branches have this fix now (3.x 4.1 and 5.x). I'm now aware that this release passes all the watchdog tests, too. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Getting Tomcat Tests
Where can I find test cases I can use to verify that my changes to the Coyote Connector haven't broken anything? I work for Unisys corporation, and we are modifying the Coyote Connector to integrate Tomcat 5.0.28 with our native HTTP server on MCP systems (mainframe systems with origins in the '70s). This is similar to integrating Tomcat with Apache. I want to make sure we haven't broken anything for supporting servlets. I just joined this list, and saw a reference to watchdog tests. Are these the tests I want? Any suggestions appreciated. Mitchell Fisher Unisys, ST, ClearPath MCP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
From: Mladen Turk [EMAIL PROTECTED] Remy Maucherat wrote: Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch Well, we deceased JK2, for Apache2.1 we have proxy_ajp. Until Apache2.1 becomes the only server around the net, I'll stick with JK for all those not running my preferred web server :). Right. However, I think JK 1.2.x needs some level of stability. So APR, large architectural changes, etc seem bad ideas. Of your list, I think documentation (yah !) and the Unix sockets backport would be good (if not too complex), but that's about it. Modifications to the Java side is something independent. I think it would rise the stability, but introduce new problems like building APR, etc.. so you are probably right. We'll see. I'm not very happy with the integrated APR build in JK2 for Apache 1.3. I did much of the work there and if I had to do it again, I'd prefer APR to be a build/runtime depend, built separately by the user first and loaded with LoadFile directive. With respect to JK, I'd rather not see it get APR'ized. Mostly so that Apache 1.3 support is kept simple and straightforward. For the long term, if you would want better support for the other servers, you can start a 100% APR replacement for JK 1.2 (I think it was a bit like your mod_ajp) if you want to. I'm surely do. The IIS6 support is something to chase :). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TCKs for 4.1.31
Hey Keith, Hey Amy, would you mind running the TCKs against the 4.1.31 rc? http://apache.org/~keith/rc2/ How does one go about obtaining these tests? I only have the TCKs for the latest specs Servlet 2.4/JSP2.0 so it won't be compatible with Tomcat 4.1. I believe Apache has contacts that have access to the TCKs. I'll see if I can get the previous TCks and Apache contacts' names. Thanks, Amy Thanks, Keith Amy Roh wrote: Thanks Jan for the update. I have confirmed that all JSP TCK tests pass with the latest StandardWrapper.java. I have retagged the file so the 5.5.3 release has the fix. Thanks, Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30774] - mod_jk2: It is not possible to set the AJP port to anything other than the default of 8009
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30774. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30774 mod_jk2: It is not possible to set the AJP port to anything other than the default of 8009 --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 23:23 --- I think the problem is not that you can only use 8009, but ports 32767 don't work because of bug 17579. I think this is a duplicate. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
