Jasper and external entities parsing
From what I see in the 5.5.8 code the external entities cannot be
resolved since we provide an InputSource to the documentBuilder in
ParseUtils :
private void processWebDotXml(ServletContext ctxt) throws JasperException {
InputStream is = null;
try {
is = ctxt.getResourceAsStream(WEB_XML);
if (is == null) {
// no web.xml
return;
}
ParserUtils pu = new ParserUtils();
TreeNode webApp = pu.parseXMLDocument(WEB_XML, is);
if (webApp == null
|| !2.4.equals(webApp.findAttribute(version))) {
defaultIsELIgnored = true;
return;
}
As such when the documentBuilder found a partial external entities,
like !ENTITY base SYSTEM base.xml, it has no idea of its root
location and as such consider as a file and provide it a dummy base
location.
What could be done it to use the ctxt.getResourceAsStream() after
cleaning the systemId reference from any file:// reference (ie:
file:///C:/eclipse3/base.xml = WEB-INF/base.xml).
Remmy do you agree on this since which such we stay independancy from
being on file or other way ?
Regards
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk2
Was there a reason mod_jk2 was replaced with mod_jk? I found mod_jk2 much easier to use and it's a pity it's gone. Is it just looking for a maintainer? Were there advantages of mod_jk2 over mod_jk? Alistair - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34036] - uriworkermap not redirecting requests to workers properly.
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=34036. 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=34036 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 10:46 --- (In reply to comment #3) Looks I was closing the case on a second topic. For you case use: /*/=worker1 I have tried this as well. It does not still work. Currently I have the worker map like this: /developer/*=worker2 /*/=worker1 With this, all contexts fo to worker1. It is almost like the map for worker2 did not exist. When I try a resource that has to be served by worker2, for example: http://myhost.com/developer/newsletter.html, I get a HTTP 404. When I check the logs, the request has actually gone to worker1. Should it not have gone to worker2? I still feel this could be a bug! I might be wrong.. but I am unable to get it to work either. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) 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 the folk at [EMAIL PROTECTED] Project jakarta-tomcat-jk-native has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 13 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat-jk-native : Connectors to various web servers Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: make [Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native] - Making all in common make[1]: Entering directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' /bin/sh /usr/local/gump/public/workspace/apache-httpd/dest-17032005/build/libtool --silent --mode=compile gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-17032005/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/usr/local/gump/public/workspace/apr/dest-17032005/include/apr-1 -g -O2 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I /opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c /usr/local/gump/public/workspace/apache-httpd/dest-17032005/build/libtool: /usr/local/gump/public/workspace/apache-httpd/dest-17032005/build/libtool: No such file or directory make[1]: *** [jk_ajp12_worker.lo] Error 127 make[1]: Leaving directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' make: *** [all-recursive] Error 1 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 3117032005, brutus:brutus-public:3117032005 Gump E-mail Identifier (unique within run) #27. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk2
Alistair Young wrote: Was there a reason mod_jk2 was replaced with mod_jk? Too complex, uses APR that behaves badly with Apache1.3, and lot more. Browse the mail archive for further details. I found mod_jk2 much easier to use and it's a pity it's gone. No it is not, but that's kind of personal opinion in any case. Is it just looking for a maintainer? No! Please, I'm tired of JK/JK2 discussions :). It's a dead code. There are two active connectors projects already mod_jk and mod_proxy for Apache 2.2 When AJP14 protocol gets accepted we'll probably have a third one, so that's enough, thought. Were there advantages of mod_jk2 over mod_jk? None. If you *really* like JK2 code, it's a BSD license, so you can do with it what ever you wish, just don't call it Apache or Jakarta. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34036] - uriworkermap not redirecting requests to workers properly.
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=34036. 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=34036 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 11:24 --- Not sure for 1.2.8, but 1.2.9-dev is working like I explained with /*/ Wait couple of days for release. Mladen. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk2
ok, that's enlightening! many thanks, Alistair On 17 Mar 2005, at 10:13, Mladen Turk wrote: Alistair Young wrote: Was there a reason mod_jk2 was replaced with mod_jk? Too complex, uses APR that behaves badly with Apache1.3, and lot more. Browse the mail archive for further details. I found mod_jk2 much easier to use and it's a pity it's gone. No it is not, but that's kind of personal opinion in any case. Is it just looking for a maintainer? No! Please, I'm tired of JK/JK2 discussions :). It's a dead code. There are two active connectors projects already mod_jk and mod_proxy for Apache 2.2 When AJP14 protocol gets accepted we'll probably have a third one, so that's enough, thought. Were there advantages of mod_jk2 over mod_jk? None. If you *really* like JK2 code, it's a BSD license, so you can do with it what ever you wish, just don't call it Apache or Jakarta. Regards, Mladen. - 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 34006] - Undeploy of webapps with antiResourceLocking in META-INF\context.xml fails after Tomcat restart
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=34006. 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=34006 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34016] - antiResourceLocking webapp fails to deploy on Tomcat restart after Commit Changes in Admin 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=34016. 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=34016 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContext.java
remm2005/03/17 02:53:44
Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java
Log:
- Ignore ';' if it is in the query string.
Revision ChangesPath
1.27 +4 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
Index: ApplicationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- ApplicationContext.java 23 Jun 2004 13:51:35 - 1.26
+++ ApplicationContext.java 17 Mar 2005 10:53:44 - 1.27
@@ -417,6 +417,9 @@
* purposes
*/
int semicolon = path.indexOf(';');
+if (pos = 0 semicolon pos) {
+semicolon = -1;
+}
uriCC.append(path, 0, semicolon 0 ? semicolon : pos);
context.getMapper().map(uriMB, mappingData);
if (mappingData.wrapper == null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_version.h
mturk 2005/03/17 03:31:22 Modified:jk/native/common jk_version.h Log: Prepare for 1.2.9-beta release. Revision ChangesPath 1.34 +4 -4 jakarta-tomcat-connectors/jk/native/common/jk_version.h Index: jk_version.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_version.h,v retrieving revision 1.33 retrieving revision 1.34 diff -u -r1.33 -r1.34 --- jk_version.h 24 Dec 2004 11:07:38 - 1.33 +++ jk_version.h 17 Mar 2005 11:31:22 - 1.34 @@ -29,10 +29,10 @@ #define JK_VERSTRING1.2.9 /* Beta number */ -#define JK_VERBETA 0 -#define JK_BETASTRING 0 +#define JK_VERBETA 1 +#define JK_BETASTRING 1 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ -#define JK_VERISRELEASE 0 +#define JK_VERISRELEASE 1 #define JK_VERRC0 #define JK_RCSTRING 0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jasper and external entities parsing
Henri Gomez wrote:
From what I see in the 5.5.8 code the external entities cannot be
resolved since we provide an InputSource to the documentBuilder in
ParseUtils :
private void processWebDotXml(ServletContext ctxt) throws JasperException {
InputStream is = null;
try {
is = ctxt.getResourceAsStream(WEB_XML);
if (is == null) {
// no web.xml
return;
}
ParserUtils pu = new ParserUtils();
TreeNode webApp = pu.parseXMLDocument(WEB_XML, is);
if (webApp == null
|| !2.4.equals(webApp.findAttribute(version))) {
defaultIsELIgnored = true;
return;
}
As such when the documentBuilder found a partial external entities,
like !ENTITY base SYSTEM base.xml, it has no idea of its root
location and as such consider as a file and provide it a dummy base
location.
What could be done it to use the ctxt.getResourceAsStream() after
cleaning the systemId reference from any file:// reference (ie:
file:///C:/eclipse3/base.xml = WEB-INF/base.xml).
Remmy do you agree on this since which such we stay independancy from
being on file or other way ?
Ask Jan. It seems quite ugly and special purpose.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native configure.in
mturk 2005/03/17 03:35:11
Modified:jk/native configure.in
Log:
Add --enable-prefork configure flag so that threading code can be
excluded when compiling for apache1 or apache2/prefork.
Revision ChangesPath
1.40 +17 -1 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.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- configure.in 25 Feb 2005 08:26:03 - 1.39
+++ configure.in 17 Mar 2005 11:35:11 - 1.40
@@ -286,6 +286,22 @@
])
AC_SUBST(CFLAGS)
+dnl CFLAGS for preforks mode
+dnl it also allows the CFLAGS environment variable.
+CFLAGS=${CFLAGS}
+AC_ARG_ENABLE(
+prefork,
+[ --enable-prefork Turn on prefork web server mode],
+[
+case ${enableval} in
+y | Y | YES | yes | TRUE | true )
+CFLAGS=${CFLAGS} -DJK_PREFORK
+AC_MSG_RESULT([...Enabling Prefork mode...])
+;;
+esac
+])
+AC_SUBST(CFLAGS)
+
dnl the APXSCFLAGS is given by apxs to the C compiler
dnl the APXSLDFLAGS is given to the linker (for APRVARS).
dnl APXSLDFLAGS=
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 Makefile.apxs.in Makefile.in
mturk 2005/03/17 03:37:39
Modified:jk/native/apache-1.3 Makefile.apxs.in Makefile.in
Log:
Add -DJK_PREFORK define for Apache1.3 as default.
Revision ChangesPath
1.6 +1 -1
jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.apxs.in
Index: Makefile.apxs.in
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.apxs.in,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Makefile.apxs.in 17 Feb 2005 09:11:31 - 1.5
+++ Makefile.apxs.in 17 Mar 2005 11:37:39 - 1.6
@@ -7,7 +7,7 @@
[EMAIL PROTECTED]@
JK=../common/
-JK_INCL=-DUSE_APACHE_MD5 -I ${JK}
+JK_INCL=-DUSE_APACHE_MD5 -DJK_PREFORK -I ${JK}
JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L
${JAVA_HOME}/lib/${ARCH}/native_threads
1.14 +1 -1
jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.in
Index: Makefile.in
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.in,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- Makefile.in 17 Feb 2005 09:11:31 - 1.13
+++ Makefile.in 17 Mar 2005 11:37:39 - 1.14
@@ -25,7 +25,7 @@
APACHE_FILES = Makefile.tmpl Makefile.libdir libjk.module
JK=../common/
-JK_INCL=-DUSE_APACHE_MD5 -I ${top_srcdir}/common
+JK_INCL=-DUSE_APACHE_MD5 -DJK_PREFORK -I ${top_srcdir}/common
JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L
${JAVA_HOME}/lib/${ARCH}/native_threads
[EMAIL PROTECTED]@ @APXSCFLAGS@ @APXSCPPFLAGS@ -I${top_srcdir}/common
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24628] - Unable to use multiple JkAutoAlias directives
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=24628. 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=24628 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 12:45 --- You can have only one JkAutoAlias per virtual host. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/iis jk_isapi_plugin.c
mturk 2005/03/17 04:06:03
Modified:jk/native/apache-1.3 mod_jk.c
jk/native/apache-2.0 mod_jk.c
jk/native/iis jk_isapi_plugin.c
Log:
Use 404 instead 403 when client tries to access WEB-INF.
This is to comply with Servlet spec.
Revision ChangesPath
1.74 +3 -3 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
retrieving revision 1.73
retrieving revision 1.74
diff -u -r1.73 -r1.74
--- mod_jk.c 22 Feb 2005 14:40:36 - 1.73
+++ mod_jk.c 17 Mar 2005 12:06:03 - 1.74
@@ -2122,9 +2122,9 @@
if (!strcasecmp(child_dir, WEB-INF) ||
!strcasecmp(child_dir, META-INF)) {
jk_log(l, JK_LOG_DEBUG,
- mod_jk::jk_translate, AutoAlias
FORBIDDEN for URI: %s,
+ mod_jk::jk_translate, AutoAlias
HTTP_NOT_FOUND for URI: %s,
r-uri);
-return FORBIDDEN;
+return HTTP_NOT_FOUND;
}
}
}
1.131 +3 -3 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.130
retrieving revision 1.131
diff -u -r1.130 -r1.131
--- mod_jk.c 22 Feb 2005 14:40:37 - 1.130
+++ mod_jk.c 17 Mar 2005 12:06:03 - 1.131
@@ -2568,9 +2568,9 @@
|| !strcasecmp(child_dir, META-INF)) {
if (JK_IS_DEBUG_LEVEL(conf-log))
jk_log(conf-log, JK_LOG_DEBUG,
- mod_jk::jk_translate, AutoAlias
HTTP_FORBIDDEN for URI: %s,
+ mod_jk::jk_translate, AutoAlias
HTTP_NOT_FOUND for URI: %s,
r-uri);
-return HTTP_FORBIDDEN;
+return HTTP_NOT_FOUND;
}
}
}
1.45 +49 -49jakarta-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.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- jk_isapi_plugin.c 25 Feb 2005 10:54:26 - 1.44
+++ jk_isapi_plugin.c 17 Mar 2005 12:06:03 - 1.45
@@ -79,11 +79,11 @@
Your browser (or proxy) sent a request that
\
this server could not
understand./DL/DD/BODY/HTML
-#define HTML_ERROR_403 !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML
4.0 Transitional//EN\ \
-HTMLHEADTITLEAccess
forbidden!!/TITLE/HEAD \
-BODYH1Access forbidden!/H1DLDD\n
\
-You don't have permission to access the
requested object. \
-It is either read-protected or not readable
by the server./DL/DD/BODY/HTML
+#define HTML_ERROR_404 !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML
4.0 Transitional//EN\ \
+HTMLHEADTITLEObject not
found!/TITLE/HEAD \
+BODYH1The requested URL was not found
on this server \
+/H1DLDD\nIf you entered the URL
manually please check your \
+spelling and try
again./DL/DD/BODY/HTML
#define JK_TOLOWER(x) ((char)tolower((BYTE)(x)))
@@ -337,42 +337,42 @@
int status;
char *reason;
} *r, reasons[] = {
-{ 100, Continue },
-{ 101, Switching Protocols },
-{ 200, OK },
-{ 201, Created },
-{ 202, Accepted },
-{ 203, Non-Authoritative Information },
-{ 204, No Content },
-{ 205, Reset Content },
-{ 206, Partial Content },
-{ 300, Multiple Choices },
-{ 301, Moved Permanently },
-{ 302, Moved Temporarily },
-{ 303, See Other },
-{ 304, Not Modified },
-{ 305, Use Proxy },
-{ 400, Bad Request },
-{ 401, Unauthorized },
-
DO NOT REPLY [Bug 32696] - WEB-INF protection stops IIS
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=32696. 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=32696 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 13:07 --- Fixed in the CVS for mod_jk. Thanks for spotting that we did not follow the Servlet spec. Mladen -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32998] - Error in communication between Apache and Tomcat through AJP
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=32998. 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=32998 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 13:12 --- Those are all related to mod_jk2. mod_jk2 is not supported any more, please use mod_jk. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native configure.in
mturk 2005/03/17 04:31:13
Modified:jk/native configure.in
Log:
Allow multiple APR include dirs. Fixes #33248
Revision ChangesPath
1.41 +6 -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.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- configure.in 17 Mar 2005 11:35:11 - 1.40
+++ configure.in 17 Mar 2005 12:31:13 - 1.41
@@ -145,7 +145,11 @@
APXS_CPPFLAGS=
else
WEBSERVER=apache-2.0
- APRINCLUDEDIR=-I`$APXS -q APR_INCLUDEDIR`
+ APRINCLUDEDIR=
+ INCTEMP=-I`$APXS -q APR_INCLUDEDIR`
+ for INC in ${INCTEMP}; do
+ APRINCLUDEDIR=${APRINCLUDEDIR} -I${INC}
+ done
APXSCFLAGS=`${APXS} -q CFLAGS` `${APXS} -q
EXTRA_CFLAGS` -DHAVE_APR ${APRINCLUDEDIR}
APXSCPPFLAGS=`${APXS} -q EXTRA_CPPFLAGS`
APACHE_CONFIG_VARS=`${APXS} -q
exp_installbuilddir`/config_vars.mk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33248] - mod_jk fails to build
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=33248. 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=33248 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 13:33 --- Fixed in the CVS. You can try from HEAD or wait for 1.2.9. Mladen -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34036] - uriworkermap not redirecting requests to workers properly.
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=34036. 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=34036 --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 13:41 --- (In reply to comment #5) Not sure for 1.2.8, but 1.2.9-dev is working like I explained with /*/ Wait couple of days for release. Mladen. Phew... Thanks for that. Where would I find the dev version of 1.2.9? Is it available for download? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native configure.in
mturk 2005/03/17 04:48:40
Modified:jk/native configure.in
Log:
No need to add -I when calling apxs
Revision ChangesPath
1.42 +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.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- configure.in 17 Mar 2005 12:31:13 - 1.41
+++ configure.in 17 Mar 2005 12:48:40 - 1.42
@@ -146,7 +146,7 @@
else
WEBSERVER=apache-2.0
APRINCLUDEDIR=
- INCTEMP=-I`$APXS -q APR_INCLUDEDIR`
+ INCTEMP=`$APXS -q APR_INCLUDEDIR`
for INC in ${INCTEMP}; do
APRINCLUDEDIR=${APRINCLUDEDIR} -I${INC}
done
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34033] - Cannot delete users using Administration Tool webapp (HTTP 500 error)
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=34033. 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=34033 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 15:21 --- Thanks :) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK 1.2.9 on 3/17/2005
Hi, I could help with Solaris info. If you tell me, what you are interested in, I can do some tests. Regards, Rainer Mladen Turk wrote: Mark Thomas wrote: I suspect that most of them are invalid/already fixed bug would be grateful if you could take a look. Hi, Yes, most are fixed. Other I simply do not understand. I'll clean up fixed and invalid, and instruct the reporters to check beta version. Some problem like Solaris one are really hard to track down without a box :) Regards, Mladen - 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 34057] New: - Deploy of war to context path like /foo/bar fails (but /foo works).
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=34057. 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=34057 Summary: Deploy of war to context path like /foo/bar fails (but /foo works). Product: Tomcat 5 Version: 5.5.7 Platform: Sun OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: Webapps:Manager AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] From the manager app: Context Path (optional): /foo/bar WAR or Directory URL: /tmp/bunk.war fails with -- INFO: HTMLManager: install: Installing web application at '/foo/bar' from '/tmp/bunk.war' java.io.FileNotFoundException: /bus/deploy/productA.55/webapps/foo/bar.war (No such file or directory) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at org.apache.catalina.manager.ManagerServlet.copyInternal(ManagerServlet.java:1540) at org.apache.catalina.manager.ManagerServlet.copy(ManagerServlet.java:1505) at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:806) This error is fixed by a mkdir WEBAPPS_BASE/foo before the deploy, but this still does not end up deploying the app. The war file is placed in WEBAPPS_BASE/foo/bar.war, but it is not expanded, and it is not deployed. It also is not deployed if tomcat is restarted. The deploy only works if a single level path is specified. The same behaviour happens with 5.5.8. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34057] - Deploy of war to context path like /foo/bar fails (but /foo works).
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=34057. 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=34057 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 16:38 --- I say no to feature bloat. This would need generation of a context file - too complex. You can still do dynamic deployment, but not with the manager webapp. So sorry, it's not going to be supported. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK 1.2.9 on 3/17/2005
Rainer Jung wrote: Hi, I could help with Solaris info. If you tell me, what you are interested in, I can do some tests. Build, socket_timeout and JkShmFile. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34061] New: - Tomcat hangs while starting
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=34061. 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=34061 Summary: Tomcat hangs while starting Product: Tomcat 4 Version: 4.1.24 Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P1 Component: Connector:HTTP/1.1 (deprecated) AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Tomcat is working Fine , in WINDOW machine . And also working Fine in One Linux server on UAT .while same stops working on production . When istart same on Production it doesn't go ahead and hangs showing below message. HttpConnector Opening server socket on all host IP addresses . While same is working Fine in other WINdows as well as UAT Linux Box. I can send Server.xml if required. Help would be appriciated, As my production is getting delayed. Abhishek -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34061] - Tomcat hangs while starting
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=34061. 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=34061 --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 17:40 --- Created an attachment (id=14510) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14510action=view) Server.xml Server.xml file -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34061] - Tomcat hangs while starting
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=34061. 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=34061 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Tomcat hangs while starting |Tomcat hangs while starting -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK 1.2.9 on 3/17/2005
Hi Mladen,
- Build for apache 1.3 OK (but see detailed comments).
- Running with apache 1.3 and JkShmFile: Looks OK
- jkstatus: Looks OK
- socket_timeout: Still needs to be tested (will try later)
- Logging shows mod_jk initialization two times! Once for a process A,
which does no longer exist after apache startup has finished, and a
second time the same lines for the usual parent process B. System call
trace shows, that A forks B and exits during startup. In my case, apache
is not run from the root account.
Anything else (apart from socket_timeout) I should test (test cases?)
Details:
Code from CVS HEAD today 17:00 CET.
Environment Solaris 8 UltraSparc, autoconf 2.59, automake 1.9, libtool
1.5, GNU m4 1.4.2, GNU make 3.80, gcc 3.2, Solaris ld 1.279.
CFLAGS set to -O2, CC set to gcc -specs=MY_SPECS_PATH/specs and the
specs file differs from the standard one by:
51c51
%{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc
-lgcc_eh}%{shared-libgcc:-lgcc_s%M -lgcc}}%{shared:-lgcc_s%M}}}
---
%{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc
-lgcc_eh}%{shared-libgcc:-lgcc_s%M -lgcc}}}
This is to link statically against libgcc. Otherwise the runtime system
must have libgcc_s.so, which usually is not the case for Solaris systems.
buildconf.sh warns:
configure.in:59: warning: underquoted definition of JK_CHECK_SETSOCKOPT
run info '(automake)Extending aclocal'
or see
http://sources.redhat.com/automake/automake.html#Extending%20aclocal
configure.in: installing `scripts/build/unix/install-sh'
configure.in: installing `scripts/build/unix/missing'
The underquoted warning means, that future versions of automake might
require line 59 to include additional brackets:
AC_DEFUN([JK_CHECK_SETSOCKOPT], [
./configure --with-apxs=MY_APXS_PATH/apxs
Nothing special.
make: Warning:
libtool: install: warning: remember to run `libtool --finish SOME_PATH'
libtool: install: warning: remember to run `libtool --finish SOME_PATH'
but inspection of libtools show, that --finish would not do anything in
our case.
Copied apache-1.3/mod_jk.so.0.0.0 to libexec/mod_jk.so.
Configured apache:
LoadModule jk_module libexec/mod_jk.so
AddModule mod_jk.c
JkWorkersFile /SOME_PATH/conf/workers.properties
JkShmFile /SOME_PATH/logs/mod_jk.shm
JkLogFile /SOME_PATH/logs/mod_jk.log
JkLogLevel trace
...
# Inside virtual host
# Where to put jk logs
JkLogFile /SOME_PATH/logs/mod_jk_21000.log
JkLogLevel trace
JkMount /status status
JkMount /*.jsp balancer
Test:
lynx -cfg=/home/jung/lib/lynx.cfg http://localhost:21000/status
shows version 1.2.9 and detail info for load balancing worker and single
worker.
Regards,
Rainer
Mladen Turk wrote:
Rainer Jung wrote:
Hi,
I could help with Solaris info. If you tell me, what you are
interested in, I can do some tests.
Build, socket_timeout and JkShmFile.
Regards,
Mladen.
-
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 34057] - Deploy of war to context path like /foo/bar fails (but /foo works).
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=34057. 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=34057 --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 18:32 --- If anything other than single level context paths are not supported by the manager webapp then it should at least produce a message that says why the deployment failed, and if a subdirectory of webapps base happens to be there, it should probably not put the undeployed war file there. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34061] - Tomcat hangs while starting
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=34061. 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=34061 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 19:56 --- Everything in this bug report suggests a configuration problem and nothing suggests a bug. Bugzilla is NOT a support forum. Please direct this question, and others like it, to the tomact-user mailing list. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33885] - Tomcat 5.5.7 deleting context configuration and 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=33885. 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=33885 --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 20:04 --- This bug is present in Tomcat 5.5.7 but is no longer present in the current cvs HEAD. The following stacktrace was captured during deletion of the test case app supplied using Tomcat 5.5.7: at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:267) at org.apache.catalina.startup.HostConfig.checkResources (HostConfig.java:1024) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1166) at org.apache.catalina.startup.HostConfig.lifecycleEvent (HostConfig.java:292) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent (LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.backgroundProcess (ContainerBase.java:1301) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChil dren(ContainerBase.java:1561) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChil dren(ContainerBase.java:1570) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run (ContainerBase.java:1550) at java.lang.Thread.run(Thread.java:595) This bug appears to have been fixed along with the fix for Bug 33572 in revision 1.55 of jakarta-tomcat- catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java [See comments 5 and 6 on that Bug 33572 as well.] The fix should appear in release 5.5.8 (if it goes out) and later. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK 1.2.9 on 3/17/2005
Concerning socket_timeout: 1) In common/jk_connect.c there is a typo: 374 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, 375 (const void *) tv, sizeof(tv)); 376 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, 377 (const void *) tv, sizeof(tv)); so both setsockopts use the same option. It should be SO_SNDTIMEO in line 376. Maybe that's easy enough to change for 1.2.9. 2) The test in configure about functionality of the timeouts is broken. The test program does not compile under Solaris, because it needs -lsocket. Undefined first referenced symbol in file socket /var/tmp//ccKuhLE0.o setsockopt /var/tmp//ccKuhLE0.o ld: fatal: Symbol referencing errors. No output written to conftest collect2: ld returned 1 exit status configure:19481: $? = 1 configure: program exited with status 1 When I compile the test program with -lsocket it compiles but it exits as expected with 1. So under Solaris the two timeouts are defined in the include files, but they do not work with setsockopt. Since this doesn't change the result in the end, it might also be corrected after 1.2.9. 3) in common/jk_connect.c in method jk_is_socket_connected the second argument timeout is never used. 4) Still need to test functionality of socket_timeout under Solaris. Regards, Rainer Rainer Jung wrote: Hi, I could help with Solaris info. If you tell me, what you are interested in, I can do some tests. Build, socket_timeout and JkShmFile. Regards, Mladen. - 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: Tagging JK 1.2.9 on 3/17/2005
Rainer Jung wrote: Concerning socket_timeout: 1) In common/jk_connect.c there is a typo: 374 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, 375 (const void *) tv, sizeof(tv)); 376 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, 377 (const void *) tv, sizeof(tv)); so both setsockopts use the same option. It should be SO_SNDTIMEO in line 376. Maybe that's easy enough to change for 1.2.9. Yes, it should be SO_SNDTIMEO. Seems like typo :). 2) The test in configure about functionality of the timeouts is broken. The test program does not compile under Solaris, because it needs -lsocket. Can you provide a patch for that? When I compile the test program with -lsocket it compiles but it exits as expected with 1. So under Solaris the two timeouts are defined in the include files, but they do not work with setsockopt. Since this doesn't change the result in the end, it might also be corrected after 1.2.9. Sure, that's the purpose of JK_CHECK_SETSOCKOPT function. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_connect.c
mturk 2005/03/17 11:41:58 Modified:jk/native/common jk_connect.c Log: Fix typo. We needed SO_SNDTIMEO here. Revision ChangesPath 1.48 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_connect.c Index: jk_connect.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v retrieving revision 1.47 retrieving revision 1.48 diff -u -r1.47 -r1.48 --- jk_connect.c 15 Mar 2005 08:23:38 - 1.47 +++ jk_connect.c 17 Mar 2005 19:41:58 - 1.48 @@ -373,7 +373,7 @@ tv.tv_usec = 0; setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, (const void *) tv, sizeof(tv)); -setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, +setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (const void *) tv, sizeof(tv)); #endif if (JK_IS_DEBUG_LEVEL(l)) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_connect.c
mturk 2005/03/17 11:49:23
Modified:jk/native/common jk_connect.c
Log:
WIN32 - do not change exiting var, because it is later used by nb_connect.
Revision ChangesPath
1.49 +4 -4 jakarta-tomcat-connectors/jk/native/common/jk_connect.c
Index: jk_connect.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- jk_connect.c 17 Mar 2005 19:41:58 - 1.48
+++ jk_connect.c 17 Mar 2005 19:49:23 - 1.49
@@ -362,11 +362,11 @@
if (timeout 0) {
#if defined(WIN32)
-timeout = timeout * 1000;
+int tmout = timeout * 1000;
setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
- (const char *) timeout, sizeof(int));
+ (const char *) tmout, sizeof(int));
setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO,
- (const char *) timeout, sizeof(int));
+ (const char *) tmout, sizeof(int));
#elif defined(SO_RCVTIMEO) defined(USE_SO_RCVTIMEO)
defined(SO_SNDTIMEO) defined(USE_SO_SNDTIMEO)
struct timeval tv;
tv.tv_sec = timeout;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK 1.2.9 on 3/17/2005
jk 1.2.9-dev build on iSeries without problem. Wit my admins to redeploy and test it On Thu, 17 Mar 2005 20:37:58 +0100, Mladen Turk [EMAIL PROTECTED] wrote: Rainer Jung wrote: Concerning socket_timeout: 1) In common/jk_connect.c there is a typo: 374 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, 375 (const void *) tv, sizeof(tv)); 376 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, 377 (const void *) tv, sizeof(tv)); so both setsockopts use the same option. It should be SO_SNDTIMEO in line 376. Maybe that's easy enough to change for 1.2.9. Yes, it should be SO_SNDTIMEO. Seems like typo :). 2) The test in configure about functionality of the timeouts is broken. The test program does not compile under Solaris, because it needs -lsocket. Can you provide a patch for that? When I compile the test program with -lsocket it compiles but it exits as expected with 1. So under Solaris the two timeouts are defined in the include files, but they do not work with setsockopt. Since this doesn't change the result in the end, it might also be corrected after 1.2.9. Sure, that's the purpose of JK_CHECK_SETSOCKOPT function. Regards, Mladen. - 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: Tagging JK 1.2.9 on 3/17/2005
Henri Gomez wrote: jk 1.2.9-dev build on iSeries without problem. Wit my admins to redeploy and test it Cool! I'll probably tag that tomorrow. Its getting late here :) Since Apache infrastructure will be unavailable over the weekend I hope the beta will be mirrored by that time. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK 1.2.9 on 3/17/2005
Greetings All, Still get a clean build for NetWare against Apache 2.1 and 2.0.53. The XML pages work fine, although the HTML status pages might put the numbers under headings better if 'border=1' was enabled. AFAIK builds for Apache 1.1.3 for NetWare still has issues, since I've not seen mention of updates for that version. Perhaps JJC can comment? Regards, Norm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK 1.2.9 on 3/17/2005
2) The test in configure about functionality of the timeouts is broken. The test program does not compile under Solaris, because it needs -lsocket. Can you provide a patch for that? How about: *** configure.in.orig Thu Mar 17 17:00:36 2005 --- configure.inThu Mar 17 21:28:29 2005 *** *** 56,63 dnl check for flock function. AC_CHECK_FUNC(flock, AC_DEFINE(HAVE_FLOCK,1,[Have flock()])) ! AC_DEFUN(JK_CHECK_SETSOCKOPT, [ AC_MSG_CHECKING(whether to use $1 with setsockopt()) AC_TRY_RUN([ #include sys/types.h #include sys/socket.h --- 56,65 dnl check for flock function. AC_CHECK_FUNC(flock, AC_DEFINE(HAVE_FLOCK,1,[Have flock()])) ! AC_DEFUN([JK_CHECK_SETSOCKOPT], [ AC_MSG_CHECKING(whether to use $1 with setsockopt()) + saved_LIBS=$LIBS + LIBS=$saved_LIBS -lsocket AC_TRY_RUN([ #include sys/types.h #include sys/socket.h *** *** 88,93 --- 90,96 , [ AC_MSG_RESULT([yes]) AC_DEFINE(USE_$1, 1, [Define to use $1 with setsockopt()]) ] , [ AC_MSG_RESULT([no]) ] ) + LIBS=$saved_LIBS ])dnl dnl check for SO_RCVTIMEO and SO_SNDTIMEO Since it's only changed line and three added I did not use local CVS to make diff -u and I hope this context diff suffices. That way the test runs smoothly, of course with the same negative but clean result: configure:19433: checking whether to use SO_RCVTIMEO with setsockopt() configure:19480: gcc -specs=/usr/local/apautobuild/specs -o conftest -O2 conftest.c -lsocket 5 configure:19483: $? = 0 configure:19485: ./conftest configure:19488: $? = 1 configure: program exited with status 1 Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
I had e-mailed this to users mailing list, but I have what I believe is a more dev follow-on question: Is there a good way to get my own start/stop action called at a per-VM level? This is assuming I end up having to move log4j up into Tomcat's classloaders -- at which point I'll want to install my LoggerRepository controlling MBeans up at this level as well -- as log4j's MBeans have issues and using log4j loggers means you don't get the (admittedly sparse) java.util.logging MBean coverage. -- Jess Holle Jess Holle wrote: I have been trying to get really serious about log4j in web apps. I note that Tomcat (thanks to commons-logging) uses java.util.logging *except* for loggers created while my web app's classloader is the current contextual classloader -- at which point it suddenly uses log4j (since my web app does) without giving my web app a chance to initialize it in any way as best I can tell. My web app has a ServletContextListener which initializes log4j by setting up its own LoggerRepository, configuration file and watcher (since log4j's won't shutdown), etc. Of course, every Tomcat logger created within my web app up until this point is now using log4j from my web app (!) and using the basic log4j.properties [if present] from my web app -- for loggers that apply to all web apps! How is one supposed to work this? I am currently using a static LoggerRepository reference within my web app so that a log4j loaded higher in the classloader tree won't cause LoggerRepository sharing. I was using a JNDI-based LoggerRepositorySelector as per log4j author recommendations, but this goes a step further than above -- it puts all the Tomcat loggers that are errantly using my log4j into my LoggerRepository -- which would be fine if these loggers were not shared with other web apps. What's the solution here? Do I have to put log4j into Tomcat's lib directories to force it to use its own centralized log4j? Is that the best solution? -- Jess Holle
Edward Furlong/IE/TLS/PwC is out of the office.
I will be out of the office starting 16/03/2005 and will not return until 21/03/2005. . _ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/valve AccessLogValveForm.java AddValveAction.java DeleteValveAction.java DeleteValvesAction.java EditValveAction.java RemoteAddrValveForm.java RemoteHostValveForm.java RequestDumperValveForm.java SaveAccessLogValveAction.java SaveRemoteAddrValveAction.java SaveRemoteHostValveAction.java SaveRequestDumperValveAction.java SaveSingleSignOnValveAction.java SingleSignOnValveForm.java ValveForm.java ValveUtil.java
markt 2005/03/17 12:51:05 Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin ActionTag.java ActionsTag.java ApplicationServlet.java CommitChangesAction.java DataTag.java DumpRegistryAction.java DumpServerAction.java LabelTag.java LogOutAction.java RowTag.java SetLocaleAction.java SetUpTreeAction.java TableTag.java TomcatTreeBuilder.java TreeControlTestAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector AddConnectorAction.java DeleteConnectorAction.java DeleteConnectorsAction.java EditConnectorAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/defaultcontext AddDefaultContextAction.java DefaultContextForm.java DeleteDefaultContextAction.java DeleteDefaultContextForm.java DeleteDefaultContextsAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/filters SetCharacterEncodingFilter.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/host AddAliasAction.java AddHostAction.java DeleteAliasAction.java DeleteAliasForm.java DeleteAliasesAction.java DeleteHostAction.java DeleteHostForm.java DeleteHostsAction.java EditHostAction.java SaveAliasAction.java SaveHostAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/logger AddLoggerAction.java DeleteLoggerAction.java DeleteLoggersAction.java EditLoggerAction.java LoggerForm.java SaveLoggerAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm AddRealmAction.java DeleteRealmAction.java DeleteRealmsAction.java EditRealmAction.java JDBCRealmForm.java JNDIRealmForm.java MemoryRealmForm.java RealmForm.java SaveJDBCRealmAction.java SaveJNDIRealmAction.java SaveMemoryRealmAction.java SaveUserDatabaseRealmAction.java UserDatabaseRealmForm.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources BaseForm.java DataSourceForm.java DataSourcesForm.java DeleteDataSourcesAction.java DeleteEnvEntriesAction.java DeleteMailSessionsAction.java DeleteResourceLinksAction.java DeleteUserDatabasesAction.java EnvEntriesForm.java EnvEntryForm.java ListDataSourcesAction.java ListEnvEntriesAction.java ListMailSessionsAction.java ListResourceLinksAction.java ListUserDatabasesAction.java MailSessionForm.java MailSessionsForm.java ResourceLinkForm.java ResourceLinksForm.java ResourceUtils.java SaveDataSourceAction.java SaveEnvEntryAction.java SaveMailSessionAction.java SaveResourceLinkAction.java SaveUserDatabaseAction.java SetUpDataSourceAction.java SetUpEnvEntryAction.java SetUpMailSessionAction.java SetUpResourceLinkAction.java SetUpUserDatabaseAction.java UserDatabaseForm.java UserDatabasesForm.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/server EditServerAction.java SaveServerAction.java ServerForm.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service AddServiceAction.java DeleteServiceAction.java DeleteServicesAction.java EditServiceAction.java SaveServiceAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users BaseForm.java DeleteGroupsAction.java DeleteRolesAction.java DeleteUsersAction.java GroupForm.java GroupsForm.java ListGroupsAction.java ListRolesAction.java ListUsersAction.java RoleForm.java RolesForm.java SaveGroupAction.java SaveRoleAction.java SaveUserAction.java SetUpGroupAction.java
Re: ExpandWar doesn't set the lastModified attribute
Nag! The mail below was sent by me two weeks ago. Is the idea to maintain timestamps so absurd, that it's not even worth a comment? -- Hi, would anyone please be so nice and comment http://issues.apache.org/bugzilla/show_bug.cgi?id=33636 Please note, that it contains a suggested patch. Regards, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
P.S. Why does Tomcat use Commons Logging rather than UGLI? Jess Holle wrote: I had e-mailed this to users mailing list, but I have what I believe is a more dev follow-on question: Is there a good way to get my own start/stop action called at a per-VM level? This is assuming I end up having to move log4j up into Tomcat's classloaders -- at which point I'll want to install my LoggerRepository controlling MBeans up at this level as well -- as log4j's MBeans have issues and using log4j loggers means you don't get the (admittedly sparse) java.util.logging MBean coverage. -- Jess Holle Jess Holle wrote: I have been trying to get really serious about log4j in web apps. I note that Tomcat (thanks to commons-logging) uses java.util.logging *except* for loggers created while my web app's classloader is the current contextual classloader -- at which point it suddenly uses log4j (since my web app does) without giving my web app a chance to initialize it in any way as best I can tell. My web app has a ServletContextListener which initializes log4j by setting up its own LoggerRepository, configuration file and watcher (since log4j's won't shutdown), etc. Of course, every Tomcat logger created within my web app up until this point is now using log4j from my web app (!) and using the basic log4j.properties [if present] from my web app -- for loggers that apply to all web apps! How is one supposed to work this? I am currently using a static LoggerRepository reference within my web app so that a log4j loaded higher in the classloader tree won't cause LoggerRepository sharing. I was using a JNDI-based LoggerRepositorySelector as per log4j author recommendations, but this goes a step further than above -- it puts all the Tomcat loggers that are errantly using my log4j into my LoggerRepository -- which would be fine if these loggers were not shared with other web apps. What's the solution here? Do I have to put log4j into Tomcat's lib directories to force it to use its own centralized log4j? Is that the best solution? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web apps vs. Logging vs. Tomcat
UGLI is far from mature enough to be used by Tomcat at this point. When log4j 1.3 is out, we'll see. Yoav -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 4:17 PM To: Tomcat Developers List Subject: Re: Web apps vs. Logging vs. Tomcat P.S. Why does Tomcat use Commons Logging rather than UGLI? Jess Holle wrote: I had e-mailed this to users mailing list, but I have what I believe is a more dev follow-on question: Is there a good way to get my own start/stop action called at a per-VM level? This is assuming I end up having to move log4j up into Tomcat's classloaders -- at which point I'll want to install my LoggerRepository controlling MBeans up at this level as well -- as log4j's MBeans have issues and using log4j loggers means you don't get the (admittedly sparse) java.util.logging MBean coverage. -- Jess Holle Jess Holle wrote: I have been trying to get really serious about log4j in web apps. I note that Tomcat (thanks to commons-logging) uses java.util.logging *except* for loggers created while my web app's classloader is the current contextual classloader -- at which point it suddenly uses log4j (since my web app does) without giving my web app a chance to initialize it in any way as best I can tell. My web app has a ServletContextListener which initializes log4j by setting up its own LoggerRepository, configuration file and watcher (since log4j's won't shutdown), etc. Of course, every Tomcat logger created within my web app up until this point is now using log4j from my web app (!) and using the basic log4j.properties [if present] from my web app -- for loggers that apply to all web apps! How is one supposed to work this? I am currently using a static LoggerRepository reference within my web app so that a log4j loaded higher in the classloader tree won't cause LoggerRepository sharing. I was using a JNDI-based LoggerRepositorySelector as per log4j author recommendations, but this goes a step further than above -- it puts all the Tomcat loggers that are errantly using my log4j into my LoggerRepository -- which would be fine if these loggers were not shared with other web apps. What's the solution here? Do I have to put log4j into Tomcat's lib directories to force it to use its own centralized log4j? Is that the best solution? -- Jess Holle - 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: Web apps vs. Logging vs. Tomcat
Thanks. That answers that part of the question quite succinctly. Now what remains is how can I work with log4j and commons logging -- commons logging's behavior vis-a-vis the contextual classloader seems onerous if not just plain wrong. The only way I can see to fix this is to deploy log4j in Tomcat's own lib directories -- and deploy my log4j controller MBeans there for the default LoggeRepository and again in each web app for each web app's LoggerRepository. If that's what I need to do, I'll get on with doing it, but I'd like to know I'm not just overlooking the obvious... -- Jess Holle Yoav Shapira wrote: UGLI is far from mature enough to be used by Tomcat at this point. When log4j 1.3 is out, we'll see. Yoav -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 4:17 PM To: Tomcat Developers List Subject: Re: Web apps vs. Logging vs. Tomcat P.S. Why does Tomcat use Commons Logging rather than UGLI? Jess Holle wrote: I had e-mailed this to users mailing list, but I have what I believe is a more dev follow-on question: Is there a good way to get my own start/stop action called at a per-VM level? This is assuming I end up having to move log4j up into Tomcat's classloaders -- at which point I'll want to install my LoggerRepository controlling MBeans up at this level as well -- as log4j's MBeans have issues and using log4j loggers means you don't get the (admittedly sparse) java.util.logging MBean coverage. -- Jess Holle Jess Holle wrote: I have been trying to get really serious about log4j in web apps. I note that Tomcat (thanks to commons-logging) uses java.util.logging *except* for loggers created while my web app's classloader is the current contextual classloader -- at which point it suddenly uses log4j (since my web app does) without giving my web app a chance to initialize it in any way as best I can tell. My web app has a ServletContextListener which initializes log4j by setting up its own LoggerRepository, configuration file and watcher (since log4j's won't shutdown), etc. Of course, every Tomcat logger created within my web app up until this point is now using log4j from my web app (!) and using the basic log4j.properties [if present] from my web app -- for loggers that apply to all web apps! How is one supposed to work this? I am currently using a static LoggerRepository reference within my web app so that a log4j loaded higher in the classloader tree won't cause LoggerRepository sharing. I was using a JNDI-based LoggerRepositorySelector as per log4j author recommendations, but this goes a step further than above -- it puts all the Tomcat loggers that are errantly using my log4j into my LoggerRepository -- which would be fine if these loggers were not shared with other web apps. What's the solution here? Do I have to put log4j into Tomcat's lib directories to force it to use its own centralized log4j? Is that the best solution? -- Jess Holle - 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: Web apps vs. Logging vs. Tomcat
Hola, Your approach is right and should work. You basically have to move everything up the classloader hierarchy into Tomcat's section, and have a copy of the MBean stuff in each webapp classloader repository that you want to manage. And I agree that it sucks... Yoav -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 4:30 PM To: Tomcat Developers List Subject: Re: Web apps vs. Logging vs. Tomcat Thanks. That answers that part of the question quite succinctly. Now what remains is how can I work with log4j and commons logging -- commons logging's behavior vis-a-vis the contextual classloader seems onerous if not just plain wrong. The only way I can see to fix this is to deploy log4j in Tomcat's own lib directories -- and deploy my log4j controller MBeans there for the default LoggeRepository and again in each web app for each web app's LoggerRepository. If that's what I need to do, I'll get on with doing it, but I'd like to know I'm not just overlooking the obvious... -- Jess Holle Yoav Shapira wrote: UGLI is far from mature enough to be used by Tomcat at this point. When log4j 1.3 is out, we'll see. Yoav -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 4:17 PM To: Tomcat Developers List Subject: Re: Web apps vs. Logging vs. Tomcat P.S. Why does Tomcat use Commons Logging rather than UGLI? Jess Holle wrote: I had e-mailed this to users mailing list, but I have what I believe is a more dev follow-on question: Is there a good way to get my own start/stop action called at a per-VM level? This is assuming I end up having to move log4j up into Tomcat's classloaders -- at which point I'll want to install my LoggerRepository controlling MBeans up at this level as well -- as log4j's MBeans have issues and using log4j loggers means you don't get the (admittedly sparse) java.util.logging MBean coverage. -- Jess Holle Jess Holle wrote: I have been trying to get really serious about log4j in web apps. I note that Tomcat (thanks to commons-logging) uses java.util.logging *except* for loggers created while my web app's classloader is the current contextual classloader -- at which point it suddenly uses log4j (since my web app does) without giving my web app a chance to initialize it in any way as best I can tell. My web app has a ServletContextListener which initializes log4j by setting up its own LoggerRepository, configuration file and watcher (since log4j's won't shutdown), etc. Of course, every Tomcat logger created within my web app up until this point is now using log4j from my web app (!) and using the basic log4j.properties [if present] from my web app -- for loggers that apply to all web apps! How is one supposed to work this? I am currently using a static LoggerRepository reference within my web app so that a log4j loaded higher in the classloader tree won't cause LoggerRepository sharing. I was using a JNDI-based LoggerRepositorySelector as per log4j author recommendations, but this goes a step further than above -- it puts all the Tomcat loggers that are errantly using my log4j into my LoggerRepository -- which would be fine if these loggers were not shared with other web apps. What's the solution here? Do I have to put log4j into Tomcat's lib directories to force it to use its own centralized log4j? Is that the best solution? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users DeleteGroupsAction.java DeleteUsersAction.java
markt 2005/03/17 13:38:28
Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanUtils.java
webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users
DeleteGroupsAction.java DeleteUsersAction.java
Log:
Support managing users/groups with names containing '=' (and other odd
characters) from within
the admin webapp.
- Port of fixes for 28178 and 34033 from TC5
Revision ChangesPath
1.51 +3 -3
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java
Index: MBeanUtils.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -r1.50 -r1.51
--- MBeanUtils.java 26 Aug 2004 21:36:08 - 1.50
+++ MBeanUtils.java 17 Mar 2005 21:38:28 - 1.51
@@ -1173,7 +1173,7 @@
ObjectName name = null;
name = new ObjectName(domain + :type=Group,groupname= +
- group.getGroupname() + ,database= +
+ encodeStr(group.getGroupname()) + ,database=
+
group.getUserDatabase().getId());
return (name);
@@ -1559,7 +1559,7 @@
ObjectName name = null;
name = new ObjectName(domain + :type=User,username= +
- user.getUsername() + ,database= +
+ encodeStr(user.getUsername()) + ,database= +
user.getUserDatabase().getId());
return (name);
1.4 +4 -2
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/DeleteGroupsAction.java
Index: DeleteGroupsAction.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/DeleteGroupsAction.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- DeleteGroupsAction.java 17 Mar 2005 20:51:03 - 1.3
+++ DeleteGroupsAction.java 17 Mar 2005 21:38:28 - 1.4
@@ -19,6 +19,7 @@
import java.io.IOException;
+import java.net.URLDecoder;
import java.util.Locale;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
@@ -126,7 +127,8 @@
for (int i = 0; i groups.length; i++) {
ObjectName oname = new ObjectName(groups[i]);
-params[0] = oname.getKeyProperty(groupname);
+params[0] =
+URLDecoder.decode(oname.getKeyProperty(groupname));
mserver.invoke(dname, removeGroup,
params, signature);
}
1.4 +3 -2
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/DeleteUsersAction.java
Index: DeleteUsersAction.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/DeleteUsersAction.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- DeleteUsersAction.java17 Mar 2005 20:51:03 - 1.3
+++ DeleteUsersAction.java17 Mar 2005 21:38:28 - 1.4
@@ -19,6 +19,7 @@
import java.io.IOException;
+import java.net.URLDecoder;
import java.util.Locale;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
@@ -126,7 +127,7 @@
for (int i = 0; i users.length; i++) {
ObjectName oname = new ObjectName(users[i]);
-params[0] = oname.getKeyProperty(username);
+params[0] =
URLDecoder.decode(oname.getKeyProperty(username));
mserver.invoke(dname, removeUser,
params, signature);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
Yoav Shapira wrote: UGLI is far from mature enough to be used by Tomcat at this point. When log4j 1.3 is out, we'll see. I already voted on that: -1. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
Remy Maucherat wrote: Yoav Shapira wrote: UGLI is far from mature enough to be used by Tomcat at this point. When log4j 1.3 is out, we'll see. I already voted on that: -1. Why out of curiosity? I don't have a pro-UGLI ax to grind here, but Commons-Logging's behavior in Tomcat is really undesirable as is. Now if you're inside JBoss and it has pre-established log4j and configured it prior to Tomcat loading, then I don't see a problem with Commons Logging. Standalone Tomcat's Commons Logging behavior vis-a-vis log4j would seem to be an issue, though. The issues are especially bad and bizarre when log4j is used in a web app but Tomcat itself does not have log4j installed, but this is only part of the issue. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
Just one more stupid question: How/where would I register/deregister (start/stop) MBeans at the Tomcat level for the Tomcat-level log4j LoggerRepository -- rather than in my ServletContextListener? For per-web-app MBeans, I can use ServletContextListener, of course, but given that log4j loggers are not JMX-exposed, I'd like to put some MBeans to do this up at the Tomcat application level. I do this in my web app, but I'd like to have the Tomcat-level MBeans installed even without any of my web apps installed. -- Jess Holle Yoav Shapira wrote: Hola, Your approach is right and should work. You basically have to move everything up the classloader hierarchy into Tomcat's section, and have a copy of the MBean stuff in each webapp classloader repository that you want to manage. And I agree that it sucks... Yoav -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 4:30 PM To: Tomcat Developers List Subject: Re: Web apps vs. Logging vs. Tomcat Thanks. That answers that part of the question quite succinctly. Now what remains is how can I work with log4j and commons logging -- commons logging's behavior vis-a-vis the contextual classloader seems onerous if not just plain wrong. The only way I can see to fix this is to deploy log4j in Tomcat's own lib directories -- and deploy my log4j controller MBeans there for the default LoggeRepository and again in each web app for each web app's LoggerRepository. If that's what I need to do, I'll get on with doing it, but I'd like to know I'm not just overlooking the obvious... -- Jess Holle Yoav Shapira wrote: UGLI is far from mature enough to be used by Tomcat at this point. When log4j 1.3 is out, we'll see. Yoav -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 4:17 PM To: Tomcat Developers List Subject: Re: Web apps vs. Logging vs. Tomcat P.S. Why does Tomcat use Commons Logging rather than UGLI? Jess Holle wrote: I had e-mailed this to users mailing list, but I have what I believe is a more dev follow-on question: Is there a good way to get my own start/stop action called at a per-VM level? This is assuming I end up having to move log4j up into Tomcat's classloaders -- at which point I'll want to install my LoggerRepository controlling MBeans up at this level as well -- as log4j's MBeans have issues and using log4j loggers means you don't get the (admittedly sparse) java.util.logging MBean coverage. -- Jess Holle Jess Holle wrote: I have been trying to get really serious about log4j in web apps. I note that Tomcat (thanks to commons-logging) uses java.util.logging *except* for loggers created while my web app's classloader is the current contextual classloader -- at which point it suddenly uses log4j (since my web app does) without giving my web app a chance to initialize it in any way as best I can tell. My web app has a ServletContextListener which initializes log4j by setting up its own LoggerRepository, configuration file and watcher (since log4j's won't shutdown), etc. Of course, every Tomcat logger created within my web app up until this point is now using log4j from my web app (!) and using the basic log4j.properties [if present] from my web app -- for loggers that apply to all web apps! How is one supposed to work this? I am currently using a static LoggerRepository reference within my web app so that a log4j loaded higher in the classloader tree won't cause LoggerRepository sharing. I was using a JNDI-based LoggerRepositorySelector as per log4j author recommendations, but this goes a step further than above -- it puts all the Tomcat loggers that are errantly using my log4j into my LoggerRepository -- which would be fine if these loggers were not shared with other web apps. What's the solution here? Do I have to put log4j into Tomcat's lib directories to force it to use its own centralized log4j? Is that the best solution? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20752] - Soft links to jars in a webapp causes IllegalArgumentException
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=20752. 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=20752 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version||All --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 23:40 --- You need to use the allowLinking property. See http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/resources.html -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20752] - Soft links to jars in a webapp causes IllegalArgumentException
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=20752. 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=20752 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
- Original Message - From: Jess Holle [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, March 17, 2005 2:25 PM Subject: Re: Web apps vs. Logging vs. Tomcat Just one more stupid question: How/where would I register/deregister (start/stop) MBeans at the Tomcat level for the Tomcat-level log4j LoggerRepository -- rather than in my ServletContextListener? Sounds like a good use for conf/tomcat5-mbeans.xml. It invokes the standard Lifecycle methods (e.g. 'init', 'start', 'stop', 'destroy') of your MBeans at the corresponding points of the Engine's Lifecycle, as well as handling JMX registration and un-registration. For per-web-app MBeans, I can use ServletContextListener, of course, but given that log4j loggers are not JMX-exposed, I'd like to put some MBeans to do this up at the Tomcat application level. I do this in my web app, but I'd like to have the Tomcat-level MBeans installed even without any of my web apps installed. -- Jess Holle Yoav Shapira wrote: Hola, Your approach is right and should work. You basically have to move everything up the classloader hierarchy into Tomcat's section, and have a copy of the MBean stuff in each webapp classloader repository that you want to manage. And I agree that it sucks... Yoav -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 4:30 PM To: Tomcat Developers List Subject: Re: Web apps vs. Logging vs. Tomcat Thanks. That answers that part of the question quite succinctly. Now what remains is how can I work with log4j and commons logging -- commons logging's behavior vis-a-vis the contextual classloader seems onerous if not just plain wrong. The only way I can see to fix this is to deploy log4j in Tomcat's own lib directories -- and deploy my log4j controller MBeans there for the default LoggeRepository and again in each web app for each web app's LoggerRepository. If that's what I need to do, I'll get on with doing it, but I'd like to know I'm not just overlooking the obvious... -- Jess Holle Yoav Shapira wrote: UGLI is far from mature enough to be used by Tomcat at this point. When log4j 1.3 is out, we'll see. Yoav -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 4:17 PM To: Tomcat Developers List Subject: Re: Web apps vs. Logging vs. Tomcat P.S. Why does Tomcat use Commons Logging rather than UGLI? Jess Holle wrote: I had e-mailed this to users mailing list, but I have what I believe is a more dev follow-on question: Is there a good way to get my own start/stop action called at a per-VM level? This is assuming I end up having to move log4j up into Tomcat's classloaders -- at which point I'll want to install my LoggerRepository controlling MBeans up at this level as well -- as log4j's MBeans have issues and using log4j loggers means you don't get the (admittedly sparse) java.util.logging MBean coverage. -- Jess Holle Jess Holle wrote: I have been trying to get really serious about log4j in web apps. I note that Tomcat (thanks to commons-logging) uses java.util.logging *except* for loggers created while my web app's classloader is the current contextual classloader -- at which point it suddenly uses log4j (since my web app does) without giving my web app a chance to initialize it in any way as best I can tell. My web app has a ServletContextListener which initializes log4j by setting up its own LoggerRepository, configuration file and watcher (since log4j's won't shutdown), etc. Of course, every Tomcat logger created within my web app up until this point is now using log4j from my web app (!) and using the basic log4j.properties [if present] from my web app -- for loggers that apply to all web apps! How is one supposed to work this? I am currently using a static LoggerRepository reference within my web app so that a log4j loaded higher in the classloader tree won't cause LoggerRepository sharing. I was using a JNDI-based LoggerRepositorySelector as per log4j author recommendations, but this goes a step further than above -- it puts all the Tomcat loggers that are errantly using my log4j into my LoggerRepository -- which would be fine if these loggers were not shared with other web apps. What's the solution here? Do I have to put log4j into Tomcat's lib directories to force it to use its own centralized log4j? Is that the best solution? -- Jess Holle - 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
Re: Web apps vs. Logging vs. Tomcat
Bill Barker wrote: - Original Message - From: Jess Holle [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, March 17, 2005 2:25 PM Subject: Re: Web apps vs. Logging vs. Tomcat Just one more stupid question: How/where would I register/deregister (start/stop) MBeans at the Tomcat level for the Tomcat-level log4j LoggerRepository -- rather than in my ServletContextListener? Sounds like a good use for conf/tomcat5-mbeans.xml. It invokes the standard Lifecycle methods (e.g. 'init', 'start', 'stop', 'destroy') of your MBeans at the corresponding points of the Engine's Lifecycle, as well as handling JMX registration and un-registration. Cool! Thanks! Do I have to actually implement Lifecycle or just provide these methods? Will a standard/dynamic MBean do or does it have to be a model MBean? [Mine extend StandardMBean and implement MBeanRegistration at the moment.] -- Jess Holle
Re: Web apps vs. Logging vs. Tomcat
Jess Holle wrote: Why out of curiosity? I don't have a pro-UGLI ax to grind here, but Commons-Logging's behavior in Tomcat is really undesirable as is. It would be the same anyway: the loading configuration and the logger instances will be tied to the webapp classloader. It has to work this way. As I understand it, the thing that does not work for you right now is that Tomcat uses your webapp's logger namespace before your callbacks are called. Now if you're inside JBoss and it has pre-established log4j and configured it prior to Tomcat loading, then I don't see a problem with Commons Logging. Standalone Tomcat's Commons Logging behavior vis-a-vis log4j would seem to be an issue, though. The issues are especially bad and bizarre when log4j is used in a web app but Tomcat itself does not have log4j installed, but this is only part of the issue. I don't see any real difference. There should be plenty of container listeners and stuff available to configure this. (I see Bill just mentioned conf/tomcat5-mbeans.xml but I have no clue what it is) BTW, JBoss (supposedly, I didn't check personally) uses commons-logging everywhere, and the logging implementation used is log4j. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK 1.2.9 on 3/17/2005
Greetings, As Norm did, I was able to build and test against 2.1.4 beta and 2.0.52 for NetWare. I ran load testing against 1.2.9dev today with 400 virtual clients requesting JSPs and Servlets on a dual proc p4 with HT enabled. It is looking solid. The test will run overnight. I will find time tomorrow to look at the 1.3 issues, I did not build for 1.3 since jk1.2.8. Regards, JJ [EMAIL PROTECTED] 3/17/2005 1:26:49 PM Greetings All, Still get a clean build for NetWare against Apache 2.1 and 2.0.53. The XML pages work fine, although the HTML status pages might put the numbers under headings better if 'border=1' was enabled. AFAIK builds for Apache 1.1.3 for NetWare still has issues, since I've not seen mention of updates for that version. Perhaps JJC can comment? Regards, Norm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
- Original Message - From: Jess Holle [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, March 17, 2005 3:12 PM Subject: Re: Web apps vs. Logging vs. Tomcat Bill Barker wrote: - Original Message - From: Jess Holle [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, March 17, 2005 2:25 PM Subject: Re: Web apps vs. Logging vs. Tomcat Just one more stupid question: How/where would I register/deregister (start/stop) MBeans at the Tomcat level for the Tomcat-level log4j LoggerRepository -- rather than in my ServletContextListener? Sounds like a good use for conf/tomcat5-mbeans.xml. It invokes the standard Lifecycle methods (e.g. 'init', 'start', 'stop', 'destroy') of your MBeans at the corresponding points of the Engine's Lifecycle, as well as handling JMX registration and un-registration. Cool! Thanks! Do I have to actually implement Lifecycle or just provide these methods? Will a standard/dynamic MBean do or does it have to be a model MBean? [Mine extend StandardMBean and implement MBeanRegistration at the moment.] You just need to provide the methods (if you wanted to code against Catalina, you'd just create a LifecycleListener :). This is a hook into commons-modeler, so you technically could use a plain old JavaBean. Otherwise, DynamicMBeans probably work best (or, at least give you the most control). -- Jess Holle 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]
Bernhard Kluschat/EZW/EN01 ist außer Haus.
Ich werde ab 18.03.2005 nicht im Büro sein. Ich kehre zurück am 04.04.2005. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. In dringenden Fällen wenden Sie sich bitte an meinen Kollegen Rolf-Dieter Gross, Tel.: 02056/ 259-5440 e-mail:[EMAIL PROTECTED] oder erreichen mich unter Mobil: 0172 745 81 45 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web apps vs. Logging vs. Tomcat
Hi, Yoav Shapira wrote: UGLI is far from mature enough to be used by Tomcat at this point. When log4j 1.3 is out, we'll see. I already voted on that: -1. Rémy Yup, I know. I'm holding out for the possibility that UGLI will be a good enough solution and a significant enough improvement of JCL to merit re-consideration at some future time. As I said, it's not something I'm pushing now, as the above is far (on the time scale) from happening. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
Remy Maucherat wrote: Jess Holle wrote: Why out of curiosity? I don't have a pro-UGLI ax to grind here, but Commons-Logging's behavior in Tomcat is really undesirable as is. It would be the same anyway: the loading configuration and the logger instances will be tied to the webapp classloader. It has to work this way. As I understand it, the thing that does not work for you right now is that Tomcat uses your webapp's logger namespace before your callbacks are called. Yes. The issue is really that Tomcat uses log4j out of my web app for loggers that are to be used outside my web app. Not only is the library used out of my web app but so is the configuration -- meaning web app A gets core Tomcat log output from web apps B and C... Yoav confirmed that the solution is to move log4j and a default configuration higher in the stack so that everything uses it. This together with a per-web-app ClassLoader (but not contextual classloader!) based LoggerRepository will ensure each web app gets its own loggers and configuration files and Tomcat core gets its own. Now if you're inside JBoss and it has pre-established log4j and configured it prior to Tomcat loading, then I don't see a problem with Commons Logging. Standalone Tomcat's Commons Logging behavior vis-a-vis log4j would seem to be an issue, though. The issues are especially bad and bizarre when log4j is used in a web app but Tomcat itself does not have log4j installed, but this is only part of the issue. I don't see any real difference. There should be plenty of container listeners and stuff available to configure this. (I see Bill just mentioned conf/tomcat5-mbeans.xml but I have no clue what it is) The nice thing about this as I understand it is that it would allow me to set up my own MBeans for a Tomcat-level / app-wide log4j LoggerRepository. You're right, though, as far as per-web-app MBeans and LoggerRepository's -- there are more than enough servlet listeners, etc, in the servlet spec to handle this. BTW, JBoss (supposedly, I didn't check personally) uses commons-logging everywhere, and the logging implementation used is log4j. That works since *everything* uses log4j. The issue is with Tomcat is really one of *not* having log4j at the Tomcat level but having it in your web app. This leads to: * whole crop of loggers using java.util.logging (fine, to be expected, and there are Java 5 MBeans -- albeit limited -- to interact with these) * a few core Tomcat loggers that are *not* by nature per web app loggers using the log4j jar and configuration of the first web app that uses the class enclosing them (e.g. the first web app to get a request!) * the web app's own classes using whatever you specify It is the 2nd of these 3 bullet that is so disturbing to me. I'd like to see these either have separate loggers for each web app, or behave like the rest the Tomcat loggers and cause a leak of data and references between web apps. This -- and a reasonable set of MBeans to control/expose loggers seems quite doable with the approach Yoav and Bill laid out. It's just unfortunate that the out-of-the-box behavior with web apps using log4j is so onerous. -- Jess Holle
Re: Web apps vs. Logging vs. Tomcat
Bill Barker wrote: You just need to provide the methods (if you wanted to code against Catalina, you'd just create a LifecycleListener :). This is a hook into commons-modeler, so you technically could use a plain old JavaBean. Otherwise, DynamicMBeans probably work best (or, at least give you the most control). I have gotten used to using my own subclasses to StandardMBean. This allows me to lay out the static portion of my MBean with an interface and extend it as necessary -- adding dynamic and open MBean behaviors as necessary in my own classes. Java 1.5's APT turns out to make automated generation of MBean descriptions, operation parameter names, impacts, etc, from MBean interface Javadoc, formal parmeter names, annotations, etc, quite simple. A little more elbow grease and the descriptions are localized (based on the server's locale). -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
