[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 38 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-06012005/build/libtool --silent --mode=compile gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-06012005/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/usr/local/gump/public/workspace/apr/dest-06012005/include/apr-1 -g -O2 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I /opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c /usr/local/gump/public/workspace/apache-httpd/dest-06012005/build/libtool: /usr/local/gump/public/workspace/apache-httpd/dest-06012005/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 2006012005, brutus:brutus-public:2006012005 Gump E-mail Identifier (unique within run) #17. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
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=25965. 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=25965 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|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]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm JDBCRealm.java
remm2005/01/06 03:33:23 Modified:catalina/src/share/org/apache/catalina/realm JDBCRealm.java Log: - Also log the exception. Revision ChangesPath 1.10 +2 -2 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JDBCRealm.java Index: JDBCRealm.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JDBCRealm.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- JDBCRealm.java22 Nov 2004 22:42:28 - 1.9 +++ JDBCRealm.java6 Jan 2005 11:33:22 - 1.10 @@ -540,7 +540,7 @@ } catch(SQLException e){ container.getLogger(). error(sm.getString(jdbcRealm.getPassword.exception, - username)); + username), e); } finally { if (rs!=null) { try { - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32646] - Serious: Exception retrieving password for username
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=32646. 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=32646 --- Additional Comments From [EMAIL PROTECTED] 2005-01-06 12:35 --- I've just added logging of the exception to get more details. This code section doesn't access the session, so I don't see why it would fail. I recommend migrating to the datasource realm, BTW. -- 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 31659] - Page context not fully populated for Exception if using app-wide error page
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=31659. 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=31659 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement OS/Version|Windows XP |All Version|5.0.28 |Unknown -- 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 17014] - ServletResponse.flushBuffer() no longer commits the response
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=17014. 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=17014 [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]| |m | -- 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 32569] - ServletContextListener will not die
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=32569. 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=32569 --- Additional Comments From [EMAIL PROTECTED] 2005-01-06 13:14 --- Where is applicationListeners[] array refreshed, at redeployment? StandardContext, declaration: /** * The set of application listener class names configured for this * application, in the order they were encountered in the web.xml file. */ private String applicationListeners[] = new String[0]; StandardContext: assign String[0], at declaration reassign String[0], in method destroy modify array in remove/addApplicationListeners Doing: cd jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina egrep (add|remove)ApplicationListener -r * print out only declarations or calls to add, no remove -- 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/coyote build.xml
remm2005/01/06 04:42:13 Modified:.build.xml coyote build.xml Log: - Don't create the coyote JAR for TC 5. Revision ChangesPath 1.220 +1 -4 jakarta-tomcat-5/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v retrieving revision 1.219 retrieving revision 1.220 diff -u -r1.219 -r1.220 --- build.xml 14 Oct 2004 07:40:34 - 1.219 +++ build.xml 6 Jan 2005 12:42:13 - 1.220 @@ -239,13 +239,10 @@ depends=init description=Build j-t-c/coyote echo== Building: tomcat-coyote /echo -ant dir=${jtc.home}/coyote target=jar.tomcat5 +ant dir=${jtc.home}/coyote target=compile.tomcat5 property name=catalina.home value=${tomcat.build}/ property name=build.home value=${tomcat.build}/ property name=tomcat5.detect value=true/ - !-- - property name=tomcat-coyote.jar value=${tomcat.build}/server/lib/tomcat-coyote.jar / - -- property name=tomcat-util.jar value=${tomcat.build}/server/lib/tomcat-util.jar/ property name=servlet.jar value=${servlet-api.jar}/ 1.31 +3 -2 jakarta-tomcat-connectors/coyote/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/build.xml,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- build.xml 1 Sep 2004 10:10:48 - 1.30 +++ build.xml 6 Jan 2005 12:42:13 - 1.31 @@ -214,6 +214,7 @@ target name=compile.tomcat5 if=tomcat5.detect + depends=static,compile.shared description=Compile Tomcat 5.x Adapter javac srcdir=${source.home} destdir=${build.home}/classes @@ -225,7 +226,7 @@ /javac /target - target name=jar.tomcat5 depends=static,compile.shared,compile.tomcat5 + target name=jar.tomcat5 depends=compile.tomcat5 jar jarfile=${tomcat-coyote.jar} index=true basedir=${build.home}/classes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
remm2005/01/06 04:43:15 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: - Content length should be ignored if there is chunking. Revision ChangesPath 1.117 +8 -8 jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java Index: Http11Processor.java === RCS file: /home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v retrieving revision 1.116 retrieving revision 1.117 diff -u -r1.116 -r1.117 --- Http11Processor.java 10 Dec 2004 00:00:00 - 1.116 +++ Http11Processor.java 6 Jan 2005 12:43:15 - 1.117 @@ -1222,14 +1222,6 @@ // Input filter setup InputFilter[] inputFilters = inputBuffer.getFilters(); -// Parse content-length header -long contentLength = request.getContentLengthLong(); -if (contentLength = 0) { -inputBuffer.addActiveFilter -(inputFilters[Constants.IDENTITY_FILTER]); -contentDelimitation = true; -} - // Parse transfer-encoding header MessageBytes transferEncodingValueMB = null; if (http11) @@ -1260,6 +1252,14 @@ // 501 - Unimplemented response.setStatus(501); } +} + +// Parse content-length header +long contentLength = request.getContentLengthLong(); +if (contentLength = 0 !contentDelimitation) { +inputBuffer.addActiveFilter +(inputFilters[Constants.IDENTITY_FILTER]); +contentDelimitation = true; } MessageBytes valueMB = headers.getValue(host); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32963] New: - lb setAttribute() spews bogus errors
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=32963. 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=32963 Summary: lb setAttribute() spews bogus errors Product: Tomcat 4 Version: 4.1.31 Platform: Macintosh OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: Connector:Coyote JK 2 (deprecated) AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Because necessary return JK_OKs are missing all over the place in setAttribute(), setting any attribute other than worker ends up with a bogus error message like the following: [Thu Jan 06 22:06:31 2005] [notice] config.setAttribute() Error setting lb: stickySession 1 [Thu Jan 06 22:06:31 2005] [notice] config.update(): done lb: else if (strcmp(name, attempts) == 0) { lb_priv-attempts = atoi(value); return JK_OK SHOULD HAVE BEEN HERE } return JK_ERR; } -- 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 32963] - lb setAttribute() spews bogus errors
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=32963. 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=32963 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-01-06 14:16 --- JK2 is deprecated. http://jakarta.apache.org/tomcat/connectors-doc/news/20041100.html#20041115.1 -- 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]
дºËÍ´óÀñ£¬Ïí·Òë·þÎñµÃ10%¾ªÏ²»ØÀ¡
13126577889 --10% [EMAIL PROTECTED] ([EMAIL PROTECTED] [EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JK 1.2.8 Stability
Remy Maucherat wrote: Mladen Turk wrote: Jess Holle wrote: For those of us lurking waiting for the outcome of this vote, it would seem to be extraordinarily slow Yes. Seems like seasons time :). I didn't vote because I didn't test it at all. Maybe I will tomorrow. Question: would it be possible to provide mod_jk binaries for Apache 2.0 on Windows ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 3534] - FileUpload doesn't work with Apache, mod_webapp and tomcat 4.0 RC1
On Jan 5, 2005, at 9:04 PM, [EMAIL PROTECTED] wrote: Bugzilla ran a sanity check last night, which caused some old mails to get sent. I don't know whether Bugzilla was correct about not having sent these, but this should not happen again. My apologies for the inconvenience. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
DO NOT REPLY [Bug 32967] New: - Session Id changing
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=32967. 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=32967 Summary: Session Id changing Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Running an application on Tomcat and when I access the servlet, it seems that the session Id is changing for each new request coming in (same client). I added a system.out to display my session Id and we get a different one each time. here is the exact sys out: System.out.println(ControllerUtil: aRequest.getSession().getId(): + aRequest.getSession().getId()); We need to maintain the same session in order to retrieve the error codes that might be writtent to the session. How does one have to go about to maintain the session info? -- 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 32968] New: - [connectors][PATCH] Documentation fixes
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=32968. 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=32968 Summary: [connectors][PATCH] Documentation fixes Product: Tomcat 5 Version: Unknown Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Connector:AJP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I'll attach patches for Jakarta Tomcat Connectors docs that fixes the following problems: - Corrected links that were dead - Corrected spelling - Revised the doccontrib document -- 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 32968] - [connectors][PATCH] Documentation fixes
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=32968. 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=32968 --- Additional Comments From [EMAIL PROTECTED] 2005-01-06 17:48 --- Created an attachment (id=13911) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13911action=view) Documentation patches -- 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 32969] New: - [connectors] Remaining problems with documentation
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=32969. 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=32969 Summary: [connectors] Remaining problems with documentation Product: Tomcat 5 Version: Unknown Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Connector:AJP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Here are some issues with the Jakarta Tomcat Connectors documentation that needs to be discussed and corrected in some way. There does not seem to be any links to the document /jk/xdocs/common/tools.xml Should it be removed? Directives for mod_jk are available in both /jk/xdocs/config/apache.xml and /jk/xdocs/howto/apache.xml They should be in one place to make it easier to maintain. Building instructions are available in both /jk/xdocs/howto/apache.xml and /jk/xdocs/install/apache1.xml and apache2.xml They should be in one place to make it easier to maintain. Change the sections in /jk/xdocs/changelog.xml from Changes from JK 1.2.7 Changes from JK 1.2.6 to Changes in JK 1.2.8 Changes in JK 1.2.7 To make it more understandable. -- 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 32967] - Session Id changing
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=32967. 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=32967 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-01-06 18:17 --- Bugzilla is NOT a support forum. Please ask questions like this on the tomcat-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]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
pero2005/01/06 12:15:23 Modified:catalina/src/share/org/apache/catalina/realm Tag: TOMCAT_5_0 RealmBase.java Log: Hups a strange typo.. Revision ChangesPath No revision No revision 1.33.2.4 +2 -2 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java Index: RealmBase.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v retrieving revision 1.33.2.3 retrieving revision 1.33.2.4 diff -u -r1.33.2.3 -r1.33.2.4 --- RealmBase.java9 Dec 2004 13:52:59 - 1.33.2.3 +++ RealmBase.java6 Jan 2005 20:15:23 - 1.33.2.4 @@ -1094,7 +1094,7 @@ byte[] digest = null; // Bugzilla 32137 -synchornized(md5Helper) { +synchronized(md5Helper) { digest = md5Helper.digest(valueBytes); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pluggable mechanism for loading context config files
Dear Tomcat developers, I would like to implement context config file encryption. It is a pretty useful feature since passwords to various resources are stored in those files Unfortunately the way how context config files are read is hard coded (InputSource for Digester is created from FileInputStream) and does not let me do so. It would be great if tomcat 5.5 provided some pluggable ConfigFileLoader in HostConfig (and may be on Engine level as well) to return InputStream for a given config file name (or decorator for FileInputStream ). It would be also great if it were possible to register context config file extensions other then *.xml - it would allow to use *.exml for encrypted XML config files (will save us a test of the file to se if it is encrypted or plain text) If it is not possible to make this enhancement may be you could re-factor ContextConfig class so it can be effectively subclassed and its input stream logic altered All you would need to do is to factor out protected void processContextConfig(InputStream) { } from protected void processContextConfig(File file) { if (log.isDebugEnabled()) log.debug(Processing context [ + context.getName() + ] configuration file + file); // Add as watched resource so that cascade reload occurs if a default // config file is modified/added/removed context.addWatchedResource(file.getAbsolutePath()); InputSource source = null; InputStream stream = null; try { if (file.exists()) { stream = new FileInputStream(file); source = new InputSource(file:// + file.getAbsolutePath()); } else if (log.isDebugEnabled()) { log.debug(Context [ + context.getName() + ] configuration file + file + not found); } } catch (Exception e) { log.error(sm.getString(contextConfig.defaultMissing) + file); } if (source == null) return; if (contextDigester == null){ contextDigester = createContextDigester(); } synchronized (contextDigester) { try { source.setByteStream(stream); . If processContextConfig(InputStream) is available, we can override this method, read from encrypted stream, decrypt create decrypted stream in memory and pass it to the original (superclass) processContextConfig(InputStream) Thank you very much for your assistance Alex Roytman [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JNDI resources available to auth realms?
On Wed, 5 Jan 2005 18:54:08 -0500, Andrew Jaquith [EMAIL PROTECTED] wrote: Greetings, A while back I did some patch work on the catalina.realm.JAASRealm class. I learned a lot in the process. Thanks for your patches -- I've been using them! In my JAAS LoginModule, I also tried to use JNDI resources, but gave it up for other reasons. I would be very interested in any headway that you make in this area. Also, it seems that JNDI *should* work from within the LoginModule since it's documented (by example) in the API docs: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/catalina/docs/api/org/apache/catalina/realm/JAASRealm.html Speaking of the JAASRealm, I tried to get my LoginModule to load from my webapp's classpath, but with no success. So, what does the useContextClassLoader do, exactly? Thanks, Ian Flanigan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pluggable mechanism for loading context config files
Alex, I would vote '-1' for any such addition Tomcat. Let me explain why by way of a simple example. Let us assume that Tomcat requires a plain text user name and password to connect to a database. First of all, consider the security risks if the information is stored in an unencrypted file somewhere on the server. Assuming that this file is not publicaly available, only users with access to the machine can access the file. With a little more configuration and possibly some network security only users with physical access to the machine can access the file and read the password. If one or more 'untrusted' users has physical access to the machine it is pretty much game over from a security point of view. With physical access there are a whole host of potential attacks I can think of that would enable an attacker to gain access to the file. Therefore, all we are trying to do is protect the contents of a file from a group of users all of whom are authorised to see it. What is the point? Looking at it from another perspective, lets say we do encrypt the file. How does Tomcat decrypt it? Tomcat needs access to the decryption key. If this is in a file, the file needs to be protected. How do you do this? This is the same problem we had before. We have just added another layer. It is a chicken and egg situation with no solution. The same applies to providing the password via some 'service'. How does the Tomcat process authenticate to this service to retrieve the password? It needs some credentials. Where are these stored? In a file... and so we start all over again... One thing that could work is not placing the password in a file at all but requiring it to be entered at start up. However, this exchanges a confidentiality security problem for an availability one - if the system fails it can only be restarted when there is someone present who knows the password. Also, people being people, there is a strong chance this password will get written down and your security has just got worse rather than better. Ultimately, the best thing you can do is leave the password unencrypted in a file and make sure the machine is electronically and physically secured with the right policies and procedures to ensure that it remains secure. Regards, Mark Roytman, Alex wrote: Dear Tomcat developers, I would like to implement context config file encryption. It is a pretty useful feature since passwords to various resources are stored in those files Unfortunately the way how context config files are read is hard coded (InputSource for Digester is created from FileInputStream) and does not let me do so. It would be great if tomcat 5.5 provided some pluggable ConfigFileLoader in HostConfig (and may be on Engine level as well) to return InputStream for a given config file name (or decorator for FileInputStream ). It would be also great if it were possible to register context config file extensions other then *.xml - it would allow to use *.exml for encrypted XML config files (will save us a test of the file to se if it is encrypted or plain text) If it is not possible to make this enhancement may be you could re-factor ContextConfig class so it can be effectively subclassed and its input stream logic altered All you would need to do is to factor out protected void processContextConfig(InputStream) { } from protected void processContextConfig(File file) { if (log.isDebugEnabled()) log.debug(Processing context [ + context.getName() + ] configuration file + file); // Add as watched resource so that cascade reload occurs if a default // config file is modified/added/removed context.addWatchedResource(file.getAbsolutePath()); InputSource source = null; InputStream stream = null; try { if (file.exists()) { stream = new FileInputStream(file); source = new InputSource(file:// + file.getAbsolutePath()); } else if (log.isDebugEnabled()) { log.debug(Context [ + context.getName() + ] configuration file + file + not found); } } catch (Exception e) { log.error(sm.getString(contextConfig.defaultMissing) + file); } if (source == null) return; if (contextDigester == null){ contextDigester = createContextDigester(); } synchronized (contextDigester) { try { source.setByteStream(stream); . If processContextConfig(InputStream) is available, we can override this method, read from encrypted stream, decrypt create decrypted stream in memory and pass it to the original (superclass) processContextConfig(InputStream) Thank you very much for your assistance Alex Roytman [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL
RE: Pluggable mechanism for loading context config files
Mark, I disagree, I have always felt it would be a good idea to have the database passwords and such encrypted when in the context files. Those context files fly all around stuffed in WAR files and stored in CVS repositories and 'Hey Bob, does this context file look right?'. That's an awful lot of chances for someone to 'see' a plain-text password, whether by malicious activity or a simple 'over the shoulder' accidental glance. If the password was encrypted using a method where the encrypted string can only be decrypted by Tomcat using a key stored safely on the Tomcat server. A key which can sit on the server and does not ever need to leave the server. The key can be used to encrypt passwords, which can then be put in the context files. Now the risk of someone 'seeing' the password in the context file is not as damaging, because the encrypted password won't be useful. In fact this could be used to encrypt the password, username, SID, etc. so that these details would be obscured as the context files go from the developer's workstation to home to their laptop to the test environment, etc. This is at best a strategy of obfuscation, but I think it is a worthy feature. Bernard Durfee -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, January 06, 2005 5:25 PM To: Tomcat Developers List Subject: Re: Pluggable mechanism for loading context config files Alex, I would vote '-1' for any such addition Tomcat. Let me explain why by way of a simple example. Let us assume that Tomcat requires a plain text user name and password to connect to a database. First of all, consider the security risks if the information is stored in an unencrypted file somewhere on the server. Assuming that this file is not publicaly available, only users with access to the machine can access the file. With a little more configuration and possibly some network security only users with physical access to the machine can access the file and read the password. If one or more 'untrusted' users has physical access to the machine it is pretty much game over from a security point of view. With physical access there are a whole host of potential attacks I can think of that would enable an attacker to gain access to the file. Therefore, all we are trying to do is protect the contents of a file from a group of users all of whom are authorised to see it. What is the point? Looking at it from another perspective, lets say we do encrypt the file. How does Tomcat decrypt it? Tomcat needs access to the decryption key. If this is in a file, the file needs to be protected. How do you do this? This is the same problem we had before. We have just added another layer. It is a chicken and egg situation with no solution. The same applies to providing the password via some 'service'. How does the Tomcat process authenticate to this service to retrieve the password? It needs some credentials. Where are these stored? In a file... and so we start all over again... One thing that could work is not placing the password in a file at all but requiring it to be entered at start up. However, this exchanges a confidentiality security problem for an availability one - if the system fails it can only be restarted when there is someone present who knows the password. Also, people being people, there is a strong chance this password will get written down and your security has just got worse rather than better. Ultimately, the best thing you can do is leave the password unencrypted in a file and make sure the machine is electronically and physically secured with the right policies and procedures to ensure that it remains secure. Regards, Mark Roytman, Alex wrote: Dear Tomcat developers, I would like to implement context config file encryption. It is a pretty useful feature since passwords to various resources are stored in those files Unfortunately the way how context config files are read is hard coded (InputSource for Digester is created from FileInputStream) and does not let me do so. It would be great if tomcat 5.5 provided some pluggable ConfigFileLoader in HostConfig (and may be on Engine level as well) to return InputStream for a given config file name (or decorator for FileInputStream ). It would be also great if it were possible to register context config file extensions other then *.xml - it would allow to use *.exml for encrypted XML config files (will save us a test of the file to se if it is encrypted or plain text) If it is not possible to make this enhancement may be you could re-factor ContextConfig class so it can be effectively subclassed and its input stream logic altered All you would need to do is to factor out protected void processContextConfig(InputStream) { } from protected void processContextConfig(File file) { if (log.isDebugEnabled()) log.debug(Processing context [ +
RE: Pluggable mechanism for loading context config files
Mark, Bernard, I think you make a good point here. I would like to clarify my purpose. I do not need to hide my passwords from people who maintain the servers - in fact they enter passwords into plain text config files which are encrypted on tomcat startup and stay encrypted. I need to make sure that if the server is compromised no password info should be gathered from its config files I would like to add that there could be two levels of security 1. Naïve - key is stored on tomcat server and therefore context file can be decrypted by the hacker. While it is naïve and can be broken (if hacker finds key in one of java classes) it is zero maintenance and can be used by people who accept this level of security 2. Better one - key is stored on removable media (USB disk, Smart Card ) which is required to be present for tomcat to start From management prospective it is a royal pain to encrypt each password so I prefer to encrypt entire file. I have this setup working but there is one weak link - I can not integrate well with tomcat. I am forced to have Host listener which decrypt all files on start, let contexts start and then delete decrypted copies. Not good - there is window of vulnerability, there is small chance encrypted file will get stuck on tomcat crash (although it will be cleaned up on next restart) plus deleted files can be recovered :-( Anyway I am looking for second line of defense here not an absolute solution. If I could only integrate with tomcat tightly I would be happy :-) PS: I am not asking tomcat developers to develop encryption - just open up file loading process. This pluggable config file loading can be useful for other things besides encryption (eg custom XML entity resolver which able to read some bits of XML from shared repositories (e.g. LDAP)for big installs with many similar configurations) Thanks again Alex Date: Thu, 06 Jan 2005 17:46:00 -0500 From: Durfee, Bernard [EMAIL PROTECTED] Subject: Pluggable mechanism for loading context config files Content-type: text/plain; charset=us-ascii Mark, I disagree, I have always felt it would be a good idea to have the database passwords and such encrypted when in the context files. Those context files fly all around stuffed in WAR files and stored in CVS repositories and 'Hey Bob, does this context file look right?'. That's an awful lot of chances for someone to 'see' a plain-text password, whether by malicious activity or a simple 'over the shoulder' accidental glance. If the password was encrypted using a method where the encrypted string can only be decrypted by Tomcat using a key stored safely on the Tomcat server. A key which can sit on the server and does not ever need to leave the server. The key can be used to encrypt passwords, which can then be put in the context files. Now the risk of someone 'seeing' the password in the context file is not as damaging, because the encrypted password won't be useful. In fact this could be used to encrypt the password, username, SID, etc. so that these details would be obscured as the context files go from the developer's workstation to home to their laptop to the test environment, etc. This is at best a strategy of obfuscation, but I think it is a worthy feature. Bernard Durfee -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, January 06, 2005 5:25 PM To: Tomcat Developers List Subject: Re: Pluggable mechanism for loading context config files Alex, I would vote '-1' for any such addition Tomcat. Let me explain why by way of a simple example. Let us assume that Tomcat requires a plain text user name and password to connect to a database. First of all, consider the security risks if the information is stored in an unencrypted file somewhere on the server. Assuming that this file is not publicaly available, only users with access to the machine can access the file. With a little more configuration and possibly some network security only users with physical access to the machine can access the file and read the password. If one or more 'untrusted' users has physical access to the machine it is pretty much game over from a security point of view. With physical access there are a whole host of potential attacks I can think of that would enable an attacker to gain access to the file. Therefore, all we are trying to do is protect the contents of a file from a group of users all of whom are authorised to see it. What is the point? Looking at it from another perspective, lets say we do encrypt the file. How does Tomcat decrypt it? Tomcat needs access to the decryption key. If this is in a file, the file needs to be protected. How do you do this? This is the same problem we had before. We have just added another layer. It is a chicken and egg situation with no solution. The same applies to providing the password via some 'service'. How does the Tomcat process authenticate to this service to retrieve the
Safely accessing Web Context info from JNDI factories
Dear Tomcat developers, I have a need to access web context info (such as name, physical path) from my various JNDI object factories. I was going through Tomcat 5.5 code and found that you publish repository info under comp:env/Resources and it has all required information. Could you please tell me if it is a right way to access web context info from classes which know nothing about web context (such as JNDI object factories) or should I use some other method. With tomcat 4 I could not find any way to do it so I had to use a context listener to build context info and publish it as context Environment entry to be looked up by whoever is interested. I hope there is a better way of doing it with tomcat 5.5 Please advice Thank you very much for your assistance Alex Roytman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pluggable mechanism for loading context config files
Roytman, Alex wrote: Dear Tomcat developers, I would like to implement context config file encryption. It is a pretty useful feature since passwords to various resources are stored in those files Unfortunately the way how context config files are read is hard coded (InputSource for Digester is created from FileInputStream) and does not let me do so. It would be great if tomcat 5.5 provided some pluggable ConfigFileLoader in HostConfig (and may be on Engine level as well) to return InputStream for a given config file name (or decorator for FileInputStream ). It would be also great if it were possible to register context config file extensions other then *.xml - it would allow to use *.exml for encrypted XML config files (will save us a test of the file to se if it is encrypted or plain text) If it is not possible to make this enhancement may be you could re-factor ContextConfig class so it can be effectively subclassed and its input stream logic altered All you would need to do is to factor out protected void processContextConfig(InputStream) { } from protected void processContextConfig(File file) { if (log.isDebugEnabled()) log.debug(Processing context [ + context.getName() + ] configuration file + file); // Add as watched resource so that cascade reload occurs if a default // config file is modified/added/removed context.addWatchedResource(file.getAbsolutePath()); InputSource source = null; InputStream stream = null; try { if (file.exists()) { stream = new FileInputStream(file); source = new InputSource(file:// + file.getAbsolutePath()); } else if (log.isDebugEnabled()) { log.debug(Context [ + context.getName() + ] configuration file + file + not found); } } catch (Exception e) { log.error(sm.getString(contextConfig.defaultMissing) + file); } if (source == null) return; if (contextDigester == null){ contextDigester = createContextDigester(); } synchronized (contextDigester) { try { source.setByteStream(stream); . If processContextConfig(InputStream) is available, we can override this method, read from encrypted stream, decrypt create decrypted stream in memory and pass it to the original (superclass) processContextConfig(InputStream) You should be able to easily plug your own Host or Context listener for configuration. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pluggable mechanism for loading context config files
Alex, Thanks for the clarification of the requirement. I think I still need some convincing ;). I view the naive level as, at best, security by obscurity. Whilst it might make people feel secure, it doesn't add much, if anything in terms of real security. On first impression the second option is more promising but if the machine is compromised a hacker doesn't need the password, they just need to supply a modified class/jar that exposes the password somehow and then sit back and wait for the machine to reboot. You could prevent this by digitally signing all of the 'approved' Java and using a security manager but then you have to protect the security policy file from compromise and you are back to square one. :) So the second option is really no more than a more complex security by obscurity. Stepping back from this a bit, have you done a full security audit of the system? Is this really the highest security risk you need to mitigate? It is possible that this is the case but I would be surprised. Bernard makes an interesting point about keeping production settings separate from the development environment but my own view is that procedure rather than technology is the way to handle this. Mark Roytman, Alex wrote: Mark, Bernard, I think you make a good point here. I would like to clarify my purpose. I do not need to hide my passwords from people who maintain the servers - in fact they enter passwords into plain text config files which are encrypted on tomcat startup and stay encrypted. I need to make sure that if the server is compromised no password info should be gathered from its config files I would like to add that there could be two levels of security 1. Naïve - key is stored on tomcat server and therefore context file can be decrypted by the hacker. While it is naïve and can be broken (if hacker finds key in one of java classes) it is zero maintenance and can be used by people who accept this level of security 2. Better one - key is stored on removable media (USB disk, Smart Card ) which is required to be present for tomcat to start From management prospective it is a royal pain to encrypt each password so I prefer to encrypt entire file. I have this setup working but there is one weak link - I can not integrate well with tomcat. I am forced to have Host listener which decrypt all files on start, let contexts start and then delete decrypted copies. Not good - there is window of vulnerability, there is small chance encrypted file will get stuck on tomcat crash (although it will be cleaned up on next restart) plus deleted files can be recovered :-( Anyway I am looking for second line of defense here not an absolute solution. If I could only integrate with tomcat tightly I would be happy :-) PS: I am not asking tomcat developers to develop encryption - just open up file loading process. This pluggable config file loading can be useful for other things besides encryption (eg custom XML entity resolver which able to read some bits of XML from shared repositories (e.g. LDAP)for big installs with many similar configurations) Thanks again Alex Date: Thu, 06 Jan 2005 17:46:00 -0500 From: Durfee, Bernard [EMAIL PROTECTED] Subject: Pluggable mechanism for loading context config files Content-type: text/plain; charset=us-ascii Mark, I disagree, I have always felt it would be a good idea to have the database passwords and such encrypted when in the context files. Those context files fly all around stuffed in WAR files and stored in CVS repositories and 'Hey Bob, does this context file look right?'. That's an awful lot of chances for someone to 'see' a plain-text password, whether by malicious activity or a simple 'over the shoulder' accidental glance. If the password was encrypted using a method where the encrypted string can only be decrypted by Tomcat using a key stored safely on the Tomcat server. A key which can sit on the server and does not ever need to leave the server. The key can be used to encrypt passwords, which can then be put in the context files. Now the risk of someone 'seeing' the password in the context file is not as damaging, because the encrypted password won't be useful. In fact this could be used to encrypt the password, username, SID, etc. so that these details would be obscured as the context files go from the developer's workstation to home to their laptop to the test environment, etc. This is at best a strategy of obfuscation, but I think it is a worthy feature. Bernard Durfee -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, January 06, 2005 5:25 PM To: Tomcat Developers List Subject: Re: Pluggable mechanism for loading context config files Alex, I would vote '-1' for any such addition Tomcat. Let me explain why by way of a simple example. Let us assume that Tomcat requires a plain text user name and password to connect to a database. First of all, consider the security risks if the information is stored in an unencrypted
RE: Pluggable mechanism for loading context config files
Rémy, I do not think that adding a Context listener will do me any good. I need to plug in my own ContextConfig. I know I can plug in my own ContextConfig but I would like to extend tomcat's one with minimum of changes or I will be running risk of being incompatible with next version of tomcat. That's why I am asking if existing ContextConfig could be refactored slightly to permit easy extension Thank you for your help Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]