DO NOT REPLY [Bug 3787] New: - Starting TomCat 4.0

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: TC 4.0 RPM Packaging - WAS: [ANNOUNCEMENT] Apache Tomcat 4.0 Fina l Release

Quoting GOMEZ Henri <[EMAIL PROTECTED]>: > Still no answer to this question ... > > Let me clarify : > > RPM policies insist in having NO binary packages > included or required to build or deploy and use > a tool. > > It's allready the case for JSSE, and if I build > RPM against JSSE to have S

DO NOT REPLY [Bug 3784] New: - Long URLs cause ArrayIndexOutOfBoundsException

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: TC 3.3: Form authentication vs. Application reloading

[EMAIL PROTECTED] wrote: > > My understanding is that ContextXmlReader actually produces 'fresh' > > instances every time. > > True. Do you think it would be better ( or simpler ) to just change > ContextXmlReader to create a new set of per/context interceptors ? > > My thinking was that the i

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server JNIEndpoint.java

nacho 01/09/23 15:17:36 Modified:src/share/org/apache/tomcat/modules/server JNIEndpoint.java Log: Add some checks Revision ChangesPath 1.8 +3 -1 jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIEndpoint.java Index: JNIEndpoint.java ==

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server JNIEndpoint.java JNIConnectionHandler.java

nacho 01/09/23 15:14:35 Modified:src/share/org/apache/tomcat/modules/server JNIEndpoint.java JNIConnectionHandler.java Log: Adding shutdown to JNI. Revision ChangesPath 1.7 +3 -3 jakarta-tomcat/src/share/org/apache/tomcat/modules/ser

cvs commit: jakarta-tomcat/src/native/mod_jk/apache1.3 mod_jk.c

nacho 01/09/23 15:11:46 Modified:src/native/mod_jk/apache1.3 mod_jk.c Log: CRLF problems Revision ChangesPath 1.18 +4 -2 jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c Index: mod_jk.c ==

RE: TC 4.0 RPM Packaging - WAS: [ANNOUNCEMENT] Apache Tomcat 4.0 Fina l Release

Still no answer to this question ... Let me clarify : RPM policies insist in having NO binary packages included or required to build or deploy and use a tool. It's allready the case for JSSE, and if I build RPM against JSSE to have SSL stuff compiled, the requirement is not mandatory for run t

RE: JK in TC 4.0 ?

+1 of course We could use the current mod_jk in JTC since many (if not all) of the latest works done in TC 3.3 has been ported to JTC. Only one exception, the ajp13 java part but should be easy :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .)

Re: [PATCH] SSL how-to documentation

Ahh ... I see. It needs to be the same JDK where JSSE was installed in order to specify RSA as the algorithm. Applied the patches. Thanks! Quoting Patrick Luby <[EMAIL PROTECTED]>: > Christopher, > > You are correct that this problem has nothing to do with Tomcat. > Instead, it is a merely a p

cvs commit: jakarta-tomcat-4.0/catalina/src/conf server-noexamples.xml.config server.xml

ccain 01/09/23 14:03:11 Modified:catalina/src/conf server-noexamples.xml.config server.xml Log: Specify that the keytool in the $JAVA_HOME JDK (where JSSE should have been installed) should be used when generating self-signed certs. Submitted by: Patrick Luby <[EMAIL PROTEC

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs ssl-howto.xml

ccain 01/09/23 14:01:10 Modified:webapps/tomcat-docs ssl-howto.xml Log: Specify that the keytool in JAVA_HOME (the JDK where JSSE should have been installed) should be used when generating a self-signed cert. Submitted by: Patrick Luby <[EMAIL PROTECTED]> Revision Cha

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators ErrorHandler.java

nacho 01/09/23 11:17:48 Modified:src/share/org/apache/tomcat/modules/generators ErrorHandler.java Log: Avoiding output when javax.servlet.error.message is null. Revision ChangesPath 1.19 +5 -3 jakarta-tomcat/src/share/org/apache/tomca

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server JNIRequestAdapter.java JNIResponseAdapter.java JNIConnectionHandler.java JNIEndpoint.java

costin 01/09/23 11:10:11 Modified:src/share/org/apache/tomcat/modules/server JNIConnectionHandler.java JNIEndpoint.java Added: src/share/org/apache/tomcat/modules/server JNIRequestAdapter.java JNIResponseAdapter.java Log: Move

Re: cvs commit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/utilProcessHelper.java

on 9/21/01 6:26 PM, "Rob S." <[EMAIL PROTECTED]> wrote: > Exactly! The answer is/was "well, it works, deal with it yourself." I'm > not (wasn't) in a position of authority, so there's not much I could > do. My boss was there, he agreed with that statement . > > Some people have very little to

DO NOT REPLY [Bug 3727] - Switched included request parameters

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 3760] - When forwaring from one servlet to another, path info may get lost

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 3602] - Tomcat is enabled by default after an rpm install

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 3780] New: - Documentation Notes

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 3606] - Tomcat rpms are not FHS compliant

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 3604] - /etc/rc.d scripts and stop command

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 3600] - /etc/rc.d scripts of the rpm

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 3768] - Path errors

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Bug report for Tomcat 4 [2001/09/23]

+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

Bug report for Tomcat 3 [2001/09/23]

+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

DO NOT REPLY [Bug 3745] - Http10Interceptor hangs on PUT without Content-Length

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: [PATCH] SSL how-to documentation

Christopher, You are correct that this problem has nothing to do with Tomcat. Instead, it is a merely a problem that comes from having more than 1 JDK installation on your local host. Specifically, the problem I described shows up on Unix platforms where your $PATH environment variable points to

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java

larryi 01/09/23 08:31:30 Modified:src/share/org/apache/tomcat/core ContextManager.java Log: Update for Release Candidate 1 Revision ChangesPath 1.195 +1 -1 jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java Index: ContextManager.java ==

cvs commit: jakarta-tomcat/src/webpages index.html

larryi 01/09/23 08:31:07 Modified:src/webpages index.html Log: Update for Release Candidate 1 Revision ChangesPath 1.18 +2 -2 jakarta-tomcat/src/webpages/index.html Index: index.html ===

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config IISConfig.java

larryi 01/09/23 08:29:51 Modified:src/share/org/apache/tomcat/modules/config IISConfig.java Log: Fix syntax for extension mapping and use default.worker Revision ChangesPath 1.8 +2 -2 jakarta-tomcat/src/share/org/apache/tomcat/modules/config/IISConfig.java

Re: Solution to mod_webapp.so:undefined symbol: pthread_sigmaskon Red Hat Linux 7.1

"Justin Erenkrantz" <[EMAIL PROTECTED]> wrote: > On Sat, Sep 22, 2001 at 01:11:29AM +, Janek Bogucki wrote: >> Hi, >> >> I may have solved (or at least worked around) the the missing >> 'pthread_sigmask' symbol error encountered when trying to use >> mod_webapp.so. From the mailing list it a

Re: Tomcat v4.0 webapp connector module for Apache

"Robert Daugherty" <[EMAIL PROTECTED]> wrote: > On the recommendation of Ted Husted I'm submitting this question to the > Developers list. Please let me know if you believe it belongs elsewhere. > > I have recently installed Tomcat release v4.0 on a server that was already > running apache. I

Re: [PATCH] SSL how-to documentation

Hi Patrick. Could you explain this a little further? Actually creating a keystore using keytool of course has nothing to do with Tomcat per se, so I assume you mean that the keystore created might not work with Tomcat. Under what conditions would a keystore generated by one JDK not work with an