Re: OS/2 Launchers in 5.0.29?
Thanks for your quick reply! Let see. Cant we create a contrib directory under bin (or under the catalina root itself) it would contain some readme which says these stuff are officially not supported. Then comes some subdirectories per OS and place the launchers there. For a normal user the name of contrib is enough to mark those stuff AS IS without official support. Leslie Kishalmi Shapira, Yoav wrote: Hi, We've seen your enhancement submission -- thank you for that. We have several others along the same lines, for different operating systems. The question is where to put them such that it's clear to everyone we don't support them. I don't know the answer to that question, so I've asked on this list, and apparently no one else knows or cares that much. So we're at a standstill. Don't hold your breath ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 12, 2004 12:21 PM To: [EMAIL PROTECTED] Subject: OS/2 Launchers in 5.0.29? Dear all, I've filed http://issues.apache.org/bugzilla/show_bug.cgi?id=31361 , asking for adding OS/2 launchers to the tomcat distribution nearly a month ago. I've also prepared the full set of launchers. I've seen that 5.0.29 is coming out. Can't add the OS/2 launchers to it. I'm know that OS/2 is not officially supported by the TomCat team, but I would. It also would help to support NetBeans Web Development on OS/2. I also think those launchers won't break anything. Thanks, Laszlo Kishalmi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31689] New: - Omission of Process Runner in 5.0.25 and higher
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=31689. 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=31689 Omission of Process Runner in 5.0.25 and higher Summary: Omission of Process Runner in 5.0.25 and higher Product: Tomcat 5 Version: 5.0.25 Platform: Other OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In tomcat 5.0.19 the windows version had a window that automaticcally started with the tomcatw.exe executable. This window called the Process Runner (version 1.1.0) displayed the standard output from any servlets run on the webserver... This window has been omitted in tomcat 5.0.25 and higher. I have looked through the documentation and can find no mention of how to start this utility in any of the version above 5.0.25. Is this available in these versions or is it a seperate download? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java
remm2004/10/13 01:17:47
Modified:catalina/src/share/org/apache/catalina/connector
Connector.java
Log:
- Fix cut and paste error.
- Logger as private (I don't quite see why it's bad to have it as protected).
Revision ChangesPath
1.14 +4 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java
Index: Connector.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- Connector.java12 Oct 2004 22:53:16 - 1.13
+++ Connector.java13 Oct 2004 08:17:47 - 1.14
@@ -54,7 +54,7 @@
public class Connector
implements Lifecycle, MBeanRegistration
{
-protected static Log log = LogFactory.getLog(Connector.class);
+private static Log log = LogFactory.getLog(Connector.class);
// Constructor
@@ -439,9 +439,9 @@
/**
- * Set the enable DNS lookups flag.
+ * Set the empty session path flag.
*
- * @param enableLookups The new enable DNS lookups flag value
+ * @param emptySessionPath The new empty session path flag value
*/
public void setEmptySessionPath(boolean emptySessionPath) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31382] - Stack overflow at JspServlet with self referencing JSP tag files.
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=31382. 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=31382 Stack overflow at JspServlet with self referencing JSP tag files. [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-10-13 11:05 --- I sent this e-mail earlier to Dominik, since I disagree with his choice to mark this as not-a-bug. But since I didn't receive a reply yet, I'll post it as a comment here. Hi Dominik, In bug-report http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31382 you seem to be missing the point of the bug. It actually IS a tomcat-bug, imho. I'll describe what happens more clearly, perhaps you agree with me afterwards: The tag I displayed there is a recursive tag, indeed. And yes, there seems to be unbound recursion... But not when executing the tag, the unbound recursion is at tag-recompile-time. When the tag is first created, and there are no class/java-files for it, everything goes fine (including executing the tag). But when the tag changes, the COMPILER goes into the recursion. My guess is that the tag is reparsed, but that the compiler/parser/whatever notices it depends on a certain tag (itself) and notices that that dependency is also changed (doh)... That dependency is reparsed/recompiled and the compiler notices a dependency (itself again...), of course the dependency has changed so that needs recompilation/reparsing... And again, again, again etc. The above does not happen for new tags, nor when you remove the .class/.java-files for the specific tag. Why this only fails when a tag changes, I don't know. There is probably some save-guard or another order of compilation when a new tag is used. Please see for yourself using the test.jsp and test.tag I displayed there. That should not run into unbound recursion, since it is only allowed 5 steps... (I tested it) Best regards, Arjen van der Meijden PS, my guess is that this may also fail when there are more tags involved in the recursion. But I haven't tested that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31382] - Stack overflow at JspServlet with self referencing JSP tag files.
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=31382. 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=31382 Stack overflow at JspServlet with self referencing JSP tag files. --- Additional Comments From [EMAIL PROTECTED] 2004-10-13 11:34 --- Hi, isn't this a duplicate of 29887, which I reported for 5.0.25? If so, it was reported fixed and there exists a test case attached to my bug report to see if simple recursions still break upon file modification (in the case of 29887 it was the file modification check that caused the infinite recursion). I have never tested, though, if recursions which involve more than one tag file (as Arjen correctly noted are an issue that needs to be dealt with) were fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31382] - Stack overflow at JspServlet with self referencing JSP tag files.
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=31382. 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=31382 Stack overflow at JspServlet with self referencing JSP tag files. [EMAIL PROTECTED] changed: What|Removed |Added Version|5.0.25 |5.0.27 --- Additional Comments From [EMAIL PROTECTED] 2004-10-13 13:26 --- Yes, it appears to be the same. But your word choice prevented me from finding your report :) I do believe that the fix in your report won't fix the case where a tag calls another tag which in turn calls the first one again or any other level of recursion apart from the trivial one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.3 Stability Rating
Remy Maucherat wrote: - Allowing pluggability for commons-modeler Can you elaborate a bit more on this ? The basic functionality of modeler is to take an object and a descriptor and return an mbean. This can be made pluggable - a simple interface with a single method is probably enough to hide most of modeler's logic. But all the descriptors need to be converted. But what do you want to use instead and how ? Move the mbean descriptors to conf/ so it can be replaced with another format ( since this is specific to modeler ) ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.3 Stability Rating
Costin Manolache wrote: Remy Maucherat wrote: - Allowing pluggability for commons-modeler Can you elaborate a bit more on this ? The basic functionality of modeler is to take an object and a descriptor and return an mbean. This can be made pluggable - a simple interface with a single method is probably enough to hide most of modeler's logic. But all the descriptors need to be converted. But what do you want to use instead and how ? Move the mbean descriptors to conf/ so it can be replaced with another format ( since this is specific to modeler ) ? To give an example, in JBoss, I would use the XMBeans model MBean implementation. I would use XSL to convert the existing descriptors during the build process, and for the introspected ones, I'll have to add the same kind of support to XMBeans. This has an advantage from a configurability and management perspective. I didn't start yet (right now, I'm still finalizing the design of my cache), so I don't know at all if it'll be really practical. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Authenticate against realm in web app: JAAS TomcatRealmProxyLoginModule? (WAS: The good way of making JAAS and Realm authentication use the same back-end authentication system?)
Hi, How do you authenticate uid/pwd against a Tomcat realm, from within a web application? We have a half-baked JMX-based solution; but it is not satisfactory because we would have to move JARs around because of classloader issues. Whether the code in the web app does this authentication JAAS-based or another way is somewhat irrelevant, although JAAS would seem natural. The main problem really is: How to find the current Tomcat Realm, from within a custom written (easy; done) JAAS LoginModule? If others agree that this would be nice to have, how can we get something like a TomcatRealmProxyLoginModule into Tomcat? More background below, if interested. Thanks a lot, Michael === Background: On e.g. WebLogic or WebSphere, we can use the JAAS API to authenticate uid/pwd from within a web application, because they both have built-in JAAS LoginModule implementations which forward to whatever they call a realm. This is sometimes very useful. (For BEA there is a weblogic.security.auth.login.UsernamePasswordLoginModule; for WebSphere simply using ClientContainer as Application/LoginModuleName when constructing the LoginContext does the trick, it uses their com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy.) On Tomcat, we have not found a clean way to authenticate uid/pwd against a Tomcat realm, from within a web application; unless we miss the obvious? This is an alternative use of JAAS, different from the JAASRealm included with Tomcat, it's sort of opposite, makes sense? In fact, Tomcat does include one class that may be conceptually vaguely similar to what I am trying to achieve: The JAASMemoryLoginModule... what we are looking for is help for a cleaner and more generic re-implementation of the same idea, so that it works e.g. on top of a JNDIRealm too, or indeed any maybe custom-written Tomcat Realm. A few words on why we'd like to get this Access Tomcat Realm through JAAS API from app JAASMemoryLoginModule-like approach working, instead of the JAASRealm-based one: To e.g. use the JAASRealm with a simple text file, I had to patch com.tagish.auth.FileLogin to be able to use it with Tomcat; to simply do what MemoryRealm already does. To use this with LDAP is a mess as there doesn't seem be a working JAAS LDAP LoginModule (the JNDI-based one included with JDK doesn't work too well, see also earlier posts on this list) - what really works is your Tomcat JNDIRealm. This is why the interest in this approach. Now, granted, I could write a JAAS LoginModule copy/pasting the code from Tomcat JNDIRealm, and then use the JAASRealm... but... agreed the other way around would be nicer? Also easier for deployment; people use to realms, but confused with JAAS. If people on this list think that this other way around is not the way to go for some reason (despite e.g. WebLogic or WebSphere doing it like that; haven't looked at JAAS in JBoss yet, anybody?) please do respond, too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CGIRunner (at CGIServlet) problem
Hi!
I've found a problem in CGI module (servlets-cgi.jar) in Tomcat distribution.
The problem occures in some occasions that are hard to reproduce.
We have Tomcat that invokes some CGI (webmail) on Linux (Debian).
Everthings worked fine, but
after few days we discoverd lots of cgi programms that are hanged in WRITE mode.
So after a week, we needed fast restart of Tomcat (OutOfMemoryError - hanging
forked proceses).
Problem was detected in next few line (thread that reads from forked process and
wirites data to client). In few occasions we catched this exception:
java.net.SocketExcpetion: ClientAbortException (in code below)
and our forked process didn't finish
his work and remained hanging (in write mode ), but sometimes we got this exception:
java.net.SocketException: Broken pipe (in catalina.out) and forked process finished
his work as supposed.
Both exceptions are thrown wheb client closes his/her browser before anthing appears.
First excpetion is very hard to reproduce (try it :-).
The solution is to add try-catch block in while loop. With this modification, any
forked process will finish his work and be able to write the complete content
(somewhere).
while ((bufRead = commandsStdOut.read(cBuf)) != -1) {
if (servletContainerStdout != null) {
if (debug = 4) {
log(runCGI: write(\ + new String(cBuf, 0, bufRead) + \));
}
/
// new code
try {
servletContainerStdout.write(cBuf, 0, bufRead); // old line
} catch (java.net.SocketException se {
servletContainerStdout = null;
// end of new code
}
}
kresimir
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGIRunner (at CGIServlet) problem
Kreimir Pavi wrote:
Hi!
I've found a problem in CGI module (servlets-cgi.jar) in Tomcat distribution.
The problem occures in some occasions that are hard to reproduce.
We have Tomcat that invokes some CGI (webmail) on Linux (Debian).
Everthings worked fine, but
after few days we discoverd lots of cgi programms that are hanged in WRITE mode.
So after a week, we needed fast restart of Tomcat (OutOfMemoryError - hanging
forked proceses).
Problem was detected in next few line (thread that reads from forked process and
wirites data to client). In few occasions we catched this exception:
java.net.SocketExcpetion: ClientAbortException (in code below)
and our forked process didn't finish
his work and remained hanging (in write mode ), but sometimes we got this exception:
java.net.SocketException: Broken pipe (in catalina.out) and forked process finished
his work as supposed.
Both exceptions are thrown wheb client closes his/her browser before anthing appears.
First excpetion is very hard to reproduce (try it :-).
The solution is to add try-catch block in while loop. With this modification, any
forked process will finish his work and be able to write the complete content
(somewhere).
while ((bufRead = commandsStdOut.read(cBuf)) != -1) {
if (servletContainerStdout != null) {
if (debug = 4) {
log(runCGI: write(\ + new String(cBuf, 0, bufRead) + \));
}
/
// new code
try {
servletContainerStdout.write(cBuf, 0, bufRead); // old line
} catch (java.net.SocketException se {
servletContainerStdout = null;
// end of new code
}
}
With your code, there could also be numerous exceptions being caught,
again not something optimal.
I think the best would be to do the rest of the reading in a finally block.
try{
while ((bufRead = commandsStdOut.read(cBuf)) !=
-1) {
if (servletContainerStdout != null) {
if (debug = 4) {
log(runCGI: write(\ +
new String(cBuf, 0, bufRead) +
\));
}
servletContainerStdout.write(cBuf, 0,
bufRead);
}
}
} finally {
if (bufRead != -1) {
while ((bufRead = commandsStdOut.read(cBuf)) != -1) {}
}
}
I got to see some of the surrounding code, and I also don't understand:
BufferedWriter servletContainerStdout = null;
try {
if (response.getOutputStream() != null) {
servletContainerStdout =
new BufferedWriter(new OutputStreamWriter
(response.getOutputStream()));
}
} catch (IOException ignored) {
//NOOP: no output will be written
}
How about removing that stuff and replacing it with
servletContainerStdout = response.getWriter() ? What would the
difference be ?
Anyone caring about CGI who would want to optimize the CGI servlet ?
(Mladen ? ;) )
(a good start would be to publish benchmarks of Tomcat + CGI vs Apache
to show how good or how bad it is, and where we stand)
Rmy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31707] New: - HTMLManager App doesn't confirm before undeploying or stopping app.
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=31707. 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=31707 HTMLManager App doesn't confirm before undeploying or stopping app. Summary: HTMLManager App doesn't confirm before undeploying or stopping app. Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] HTMLManager App doesn't confirm before undeploying or stopping app. This is due to improperly escaped single quotes in string literal which result in no quotes in the resulting Javascript on the page. Submitting patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31707] - HTMLManager App doesn't confirm before undeploying or stopping app.
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=31707. 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=31707 HTMLManager App doesn't confirm before undeploying or stopping app. --- Additional Comments From [EMAIL PROTECTED] 2004-10-13 18:52 --- Are you really running against nightly build? If so a nightly build of the 5.5 or 5.0 codebase? I thought I already fixed this for 5.0.29 and 5.5.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31707] - HTMLManager App doesn't confirm before undeploying or stopping app.
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=31707. 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=31707 HTMLManager App doesn't confirm before undeploying or stopping app. --- Additional Comments From [EMAIL PROTECTED] 2004-10-13 18:53 --- Created an attachment (id=13079) Patch to correct quote escaping in HTMLManagerServlet.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31707] - HTMLManager App doesn't confirm before undeploying or stopping app.
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=31707. 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=31707 HTMLManager App doesn't confirm before undeploying or stopping app. --- Additional Comments From [EMAIL PROTECTED] 2004-10-13 18:55 --- I used the build.xml script from: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/build.xml just a few minutes ago. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
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=26372. 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=26372 java.lang.ThreadDeath when trying to reload an application --- Additional Comments From [EMAIL PROTECTED] 2004-10-13 18:56 --- There's a significant difference between commons-logging.jar and commons- logging-api.jar, it's not just a rename. Every version of commons-logging has both distributions and for good reason. As for the rant about being able to use whatever library and not wortying about the web server dying: I'd point out it's only 'dying' when you're trying the app reload, nor normal usage. This feature is not mandated by the Spec so we're not obliged to provided it in the first place: it's caused mostly trouble and has very limited usage in production environments. So if you have patches for it, that's great, but the common usage scenario for Tomcat doesn't include webapp reload, and so doesn't suffer from this issue at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31683] - It should be documented that JDBCRealm doesn't support digest authentication
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=31683. 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=31683 It should be documented that JDBCRealm doesn't support digest authentication --- Additional Comments From [EMAIL PROTECTED] 2004-10-13 18:57 --- Care to submit a doc patch? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31689] - Omission of Process Runner in 5.0.25 and higher
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=31689. 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=31689 Omission of Process Runner in 5.0.25 and higher [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-10-13 18:58 --- It might be gone altogether, by design. I'm not sure. But please don't use Bugzilla as a discussion forum: post your question on the mailing list(s). If it's determined to be a bug, feel free to reopen this item. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31707] - HTMLManager App doesn't confirm before undeploying or stopping app.
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=31707. 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=31707 HTMLManager App doesn't confirm before undeploying or stopping app. --- Additional Comments From [EMAIL PROTECTED] 2004-10-13 18:59 --- OK, cool. I assume you built with and tested your patch? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31707] - HTMLManager App doesn't confirm before undeploying or stopping app.
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=31707. 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=31707 HTMLManager App doesn't confirm before undeploying or stopping app. --- Additional Comments From [EMAIL PROTECTED] 2004-10-13 19:10 --- I did. It looks like you doubled up the single quotes which didn't work for that formatter. Tripling them did the trick. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31707] - HTMLManager App doesn't confirm before undeploying or stopping app.
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=31707. 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=31707 HTMLManager App doesn't confirm before undeploying or stopping app. --- Additional Comments From [EMAIL PROTECTED] 2004-10-13 20:58 --- Created an attachment (id=13081) Same patch for 5.0.29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to get context realm from servlet and filter.
I am trying to get the current contexts realms from a servlet (and maybe a filter). I do not see a getContext().getRealm() method. So I am guessing there is another way to get to this, but I do not see it. Can any one provide some quick direction to me on this. Thank you! Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hi
-- Virus Warning Message (on uusnwa0p) Found virus WORM_NETSKY.Z in file Textfile.txt .exe (in Textfile.zip) The file is deleted. - Important textfile! -- Virus Warning Message (on uusnwa0p) Textfile.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31711] New: - Clone used incorrectly in o.a.c.u.Enumerator constructor
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=31711. 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=31711 Clone used incorrectly in o.a.c.u.Enumerator constructor Summary: Clone used incorrectly in o.a.c.u.Enumerator constructor Product: Tomcat 4 Version: 4.1.30 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] o.a.c.u.Enumerator(Iterator iterator, boolean clone) is actually doing the clone when clone is false. It is not doing the clone when the clone is true. The logic must be reversed. Change if (clone) to if (!clone) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
