Re: Fwd: Re: Tomcat and LDAP Issues
I just tested it, and the fix seems to work well. At first I thought that your null check would actually cause a problem, in case the exception is something besides a connection(or socket) closed, and the provider chose to not to set the message on the exception. But, I think the fact that the retry is wrapped in yet another try catch block means that life will probably go on. I've been doing all sorts of fun weird things to my LDAP server to try to get other types of exceptions thrown, and it behaves as I would expect with your fix. With defect 20518 -- It does seem innocent, though if the primary LDAP server is down for an extended period of time, you would constantly be trying it first, then the alternate. But, I'm guessing the performance hit is not huge and the fix seems correct beyond that. (IE, to assume the primary is forever gone is a bad idea and it is better to take the potential performance hit). You closed the bug regarding the userSubtree not working I see. I'm not sure but that there are still issues there, and I'm still investigating. I can get it to work if I add the [Public] object as a trustee to any subcontext that I want searched, but this is by no means a standard thing to do since it opens up your user containers to potential security exploits. Most of the exploits involve social engineering; with public access to the names of the users in the container, you can impersonate a user whose name you see and call up and ask a help desk technician to change their password for you. What I'm not sure about is if there is some other acceptable way to grant browse rights to some other object and then have Tomcat go in as that object. If so, then that would need to be documented if it is not already. If that is not possible, then the userSubtree feature is fairly useless since most directory administrators would not take the security risk to make it work. Also, there are other bugs with this feature like the fact that the first level is not searched for users, ONLY the sublevels are. I emailed marek about the CLIENT-CERT problem, still no response. I'm going to look into it and see what the gist of Mario's objections were, and if the patch is good. I know nothing about the iPlanet issue (except for what is in the bug report), so that will be great if you have a fix... Thanks Tim for working on these issues. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/5/03 11:42:43 AM I got eager and saw you bug update yesterday and applied a patch to 4.1 last night. Here's a link to the PATCH email: http://marc.theaimsgroup.com/?l=tomcat-devm=106004487327965w=2 The commit also does a null pointer check on the getMessage() to fix a related bug and also avoids doing the toString(). As for bug 20518 - did this seem right? It seemed like an innocent fix. (But they are the ones that seem to cause the most trouble) IIRC, the only two bugs left I know of is: 1) The CLIENT-CERT one which I wish not to do but rather leave to someone to Extend JNDIRealm. (But if someone else wants to commit it - I won't care) 2) Enhancement request for IPlanet since in a non-user binding the SHA1 check isn't compatible with the way tomcat generates a hash. I have a patch on my own from another project that might fix this. (If I can find the code) AFAIK - All other JNDIRealm bugs are fixed or enhancements. If you can test from 4.1 and give me the OK - I can port the patch to 5. (I know I committed in the wrong order :( , but did it on the hope that the patch had a better chance of being tested) -Tim - 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-catalina/catalina/src/conf web.xml
luehe 2003/08/06 13:03:15 Modified:catalina/src/conf web.xml Log: - Replaced JspServlet's tagPoolSize config param with the correct tagpoolMaxSize in web.xml - Removed getTagPoolSize() from Options, because tag pool size is no longer needed at compile time Revision ChangesPath 1.22 +2 -2 jakarta-tomcat-catalina/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/web.xml,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- web.xml 22 Jul 2003 21:05:38 - 1.21 +++ web.xml 6 Aug 2003 20:03:15 - 1.22 @@ -157,7 +157,7 @@ !-- reloading Should Jasper check for modified JSPs? [true] -- !-- -- !-- suppressSmapShould the generation of SMAP info for JSR45 -- - !-- debugging be suppressed? [false] -- + !-- debugging be suppressed? [false] -- !-- -- !-- dumpSmapShould the SMAP info for JSR45 debugging be-- !-- dumped to a file? [false] -- @@ -167,7 +167,7 @@ !-- compiling JSP pages? [default work directory -- !-- for the current web application] -- !-- -- - !-- tagPoolSize The tag handler pool size -- + !-- tagpoolMaxSize The maximum tag handler pool size [5] -- !-- -- !-- xpoweredBy Determines whether X-Powered-By response -- !-- header is added by generated servlet -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22291] - Missing ant tasks for JMX proxy functionality
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22291. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22291 Missing ant tasks for JMX proxy functionality --- Additional Comments From [EMAIL PROTECTED] 2003-08-11 07:02 --- Created an attachment (id=7735) The JMX Query task code - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22290] - HttpServlet should use Wrapper class for doHead
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22290. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22290 HttpServlet should use Wrapper class for doHead [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-08-11 06:53 --- Note that even if this is/was legal, I think there is no harm in using the wrappers provided here and it will reduce the code volume. The way in which the spec gets violated is a little obscure, but it depends on SRV.8.2 Using a Request Dispatcher, which says: To use a request dispatcher, a servlet calls either the include method or forward method of the RequestDispatcher interface. The parameters to these methods can be either the request and response arguments that were passed in via the service method of the javax.servlet interface, or instances of subclasses of the request and response wrapper classes that were introduced for version 2.3 of the specification. In the latter case, the wrapper instances must wrap the request or response objects that the container passed into the service method. The problem occurs if I write a servlet based on HttpServlet and in doGet call a RequestDispatcher with the response that was passed in to doGet. For a HEAD method, this is not the response passed to the service method, nor is it a wrapper of that object. This leads to a class of errors for webapps that want/need to unwrap to the objects passed to service not working for HEAD requests. I have actually seen such problems in the field. cheers cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22293] New: - JasperLoader prepends fixed package name
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22293. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22293 JasperLoader prepends fixed package name Summary: JasperLoader prepends fixed package name Product: Tomcat 4 Version: 4.1.24 Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Recent versions of the Jasper ant task use the directory name for the package so you can compile a whole tree. That's great. However, JasperLoader always looks for org.apache.jsp.JSP_NAME, which results in (root cause of a servlet exception): java.lang.NoClassDefFoundError: org/apache/jsp/cookieMonster_jsp (wrong name: admin/cookieMonster_jsp) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:488) at java.lang.ClassLoader.defineClass(ClassLoader.java:423) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:215) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:131) at org.apache.jasper.JspCompilationContext.load(JspCompilationContext.java:497) at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:150) I've tried this out on 4.1.24, and according to CVS the files haven't changed for 4.1.27 so I imagine it still exists. Not having a decent way to precompile JSPs is really hurting our production environment. With the large number of JSPs we have, using the web.xml fragment is a bit impractical and prevents any recompilation at a later date by the live server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22295] - Catalina is not able to stop on the first time: it just stops on the second
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22295. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22295 Catalina is not able to stop on the first time: it just stops on the second [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-08-11 10:38 --- This works for me. I'm almost certain this is a user error: please do not reopen the bug report unless you can explain in detail how to reproduce the error. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22294] - JSPC class name doesn't match Jasper
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22294. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22294 JSPC class name doesn't match Jasper [EMAIL PROTECTED] changed: What|Removed |Added BugsThisDependsOn||22293 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta newsletter Tomcat post
Thank you Remy! Uploaded to nagoya (ApacheWiki). Anyone can modify/append to it up to the Editorial Deadline (00:00 (PDT), 9th August) http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue1 http://www.apache.org/newsletter/ -- Tetsuya ([EMAIL PROTECTED]) On Fri, 08 Aug 2003 12:06:42 +0200 (Subject: Jakarta newsletter Tomcat post) Remy Maucherat [EMAIL PROTECTED] wrote: Still my bug with large POSTs to Nagoya because of NAT (apparently). Feel free to modify the entry, or add more community info, etc. bJakarta Tomcat/b Tomcat 4.1.27 has been released, fixing number of security issues which were recently discovered, and integrating other bugfixes. When downloading it, make sure to also download and install the hotfix fixing a regression in webapp reloading (bugzilla item 22096). Tomcat 5.0 release plan was voted, and is now quickly making its way towards beta, with a focus on bugfixing. Many old, long standing, Tomcat issues which needed non trivial refactoring are addressed during this period. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat and IIS 6.0
Hello, Did anybody develop Connectors for IIS 6.0? If so, please let me know and I need one. If anybody who can develop connector for IIS 6.0, I'm ready to pay a small fee for it. Pls let me know. Thanks Kiran
DO NOT REPLY [Bug 22174] - tomcat service launcher does not accept path to jvm.dll with spaces
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22174. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22174 tomcat service launcher does not accept path to jvm.dll with spaces --- Additional Comments From [EMAIL PROTECTED] 2003-08-06 20:29 --- I am not sure that 22187 is really a duplicate or not. In my examples there are no blanks .. but the service will still not start unless only the keyword 'java' is specified. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse JSSE14SocketFactory.java JSSESocketFactory.java
luehe 2003/08/11 14:46:41
Modified:util/java/org/apache/tomcat/util/net/jsse
JSSE14SocketFactory.java JSSESocketFactory.java
Log:
- Added support for specifying comma-separated list of SSL protocol
variants to be enabled
This may be useful to disable the less secure SSLv2.
- Fixed bug where if none of the requested ciphers were actually supported, no
error was reported
Revision ChangesPath
1.9 +5 -1
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java
Index: JSSE14SocketFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- JSSE14SocketFactory.java 11 Aug 2003 18:12:29 - 1.8
+++ JSSE14SocketFactory.java 11 Aug 2003 21:46:41 - 1.9
@@ -133,7 +133,11 @@
sslProxy = context.getServerSocketFactory();
// Determine which cipher suites to enable
-enabledCiphers = getEnabledCiphers(sslProxy.getSupportedCipherSuites());
+String requestedCiphers = (String)attributes.get(ciphers);
+if (requestedCiphers != null) {
+enabledCiphers = getEnabledCiphers(requestedCiphers,
+
sslProxy.getSupportedCipherSuites());
+}
} catch(Exception e) {
if( e instanceof IOException )
1.5 +75 -15
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
Index: JSSESocketFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JSSESocketFactory.java18 Jul 2003 05:26:45 - 1.4
+++ JSSESocketFactory.java11 Aug 2003 21:46:41 - 1.5
@@ -155,25 +155,28 @@
public void handshake(Socket sock) throws IOException {
((SSLSocket)sock).startHandshake();
}
-
+
/*
* Determines the SSL cipher suites to be enabled.
*
- * @return Array of SSL cipher suites to be enabled, or null if the
- * cipherSuites property was not specified (meaning that all supported
- * cipher suites are to be enabled)
+ * @param requestedCiphers Comma-separated list of requested ciphers
+ * @param supportedCiphers Array of supported ciphers
+ *
+ * @return Array of SSL cipher suites to be enabled, or null if none of the
+ * requested ciphers are supported
*/
-protected String[] getEnabledCiphers(String[] supportedCiphers) {
+protected String[] getEnabledCiphers(String requestedCiphers,
+ String[] supportedCiphers) {
String[] enabledCiphers = null;
-String attrValue = (String)attributes.get(ciphers);
-if (attrValue != null) {
+if (requestedCiphers != null) {
Vector vec = null;
int fromIndex = 0;
-int index = attrValue.indexOf(',', fromIndex);
+int index = requestedCiphers.indexOf(',', fromIndex);
while (index != -1) {
-String cipher = attrValue.substring(fromIndex, index).trim();
+String cipher
+= requestedCiphers.substring(fromIndex, index).trim();
/*
* Check to see if the requested cipher is among the supported
* ciphers, i.e., may be enabled
@@ -189,7 +192,7 @@
}
}
fromIndex = index+1;
-index = attrValue.indexOf(',', fromIndex);
+index = requestedCiphers.indexOf(',', fromIndex);
}
if (vec != null) {
@@ -200,7 +203,7 @@
return enabledCiphers;
}
-
+
/*
* Gets the SSL server's keystore password.
*/
@@ -288,15 +291,72 @@
*/
abstract void init() throws IOException ;
+/*
+ * Determines the SSL protocol variants to be enabled.
+ *
+ * @param requestedProtocols Comma-separated list of requested SSL
+ * protocol variants
+ * @param supportedProtocols Array of supported SSL protocol variants
+ *
+ * @return Array of SSL protocol variants to be enabled, or null if none of
+ * the requested protocol variants are supported
+ */
+private String[] getEnabledProtocols(String requestedProtocols,
+ String[] supportedProtocols) {
DO NOT REPLY [Bug 22247] New: - org.apache.catalina.ant - unknown protocol: c on DeployTask
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22247.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22247
org.apache.catalina.ant - unknown protocol: c on DeployTask
Summary: org.apache.catalina.ant - unknown protocol: c on
DeployTask
Product: Tomcat 5
Version: 5.0.6
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I'm having this Ant-Tomcat build issue with Ant 1.5.3 and Ant 1.6alpha. The
same script worked with Tomcat 5.0.2. I am using ant-catalina.jar from the
Tomcat 5.0.6 distro.
I'm running on a windows xp pro development box that has j2sdk1.4.1_03
installed.
Please let me know if there is a better place for this bug or if you need any
more information. -- Joe
ANT -V OUTPUT
=
undeploy:
[echo] Undeploying myApp.
[remove] OK - Undeployed application at context path /myApp
deploy:
[echo] Deploying myApp.
[deploy] FAIL - Encountered exception java.net.MalformedURLException:
unknown protocol: c
[deploy] OK - Deployed application at context path /myApp
BUILD FAILED
file:c:/SuperFly/Source/myApp/build.xml:128: FAIL - Encountered exception
java.net.MalformedURLException: unknown protocol: c
at org.apache.catalina.ant.AbstractCatalinaTask.execute
(AbstractCatalinaTask.java:278)
at org.apache.catalina.ant.DeployTask.execute(DeployTask.java:229)
at org.apache.tools.ant.Task.perform(Task.java:341)
at org.apache.tools.ant.Target.execute(Target.java:309)
at org.apache.tools.ant.Target.performTasks(Target.java:336)
at org.apache.tools.ant.Project.executeTarget(Project.java:1339)
at org.apache.tools.ant.Project.executeTargets(Project.java:1255)
at org.apache.tools.ant.Main.runBuild(Main.java:609)
at org.apache.tools.ant.Main.start(Main.java:196)
at org.apache.tools.ant.Main.main(Main.java:235)
Caused by: FAIL - Encountered exception java.net.MalformedURLException:
unknown protocol: c
at org.apache.catalina.ant.AbstractCatalinaTask.execute
(AbstractCatalinaTask.java:274)
... 9 more
--- Nested Exception ---
FAIL - Encountered exception java.net.MalformedURLException: unknown protocol:
c
at org.apache.catalina.ant.AbstractCatalinaTask.execute
(AbstractCatalinaTask.java:274)
at org.apache.catalina.ant.DeployTask.execute(DeployTask.java:229)
at org.apache.tools.ant.Task.perform(Task.java:341)
at org.apache.tools.ant.Target.execute(Target.java:309)
at org.apache.tools.ant.Target.performTasks(Target.java:336)
at org.apache.tools.ant.Project.executeTarget(Project.java:1339)
at org.apache.tools.ant.Project.executeTargets(Project.java:1255)
at org.apache.tools.ant.Main.runBuild(Main.java:609)
at org.apache.tools.ant.Main.start(Main.java:196)
at org.apache.tools.ant.Main.main(Main.java:235)
Total time: 29 seconds
c:\SuperFly\Source\myApp
ANT SCRIPT
==
!-- Properties are read from build.properties with a property/ tag. --
!-- WAR file creation omitted. --
target name=undeploy description=Undeploys the Web Application
depends=backupsource
echo message=Undeploying ${tomcat.app.name}./
remove url=${tomcat.manager.url} username=${tomcat.mgr.username}
password=${tomcat.mgr.password} path=/${tomcat.app.name}/
/target
target name=deploy description=Deploys the Web Application
depends=undeploy
echo message=Deploying ${tomcat.app.name}./
deploy url=${tomcat.manager.url} username=${tomcat.mgr.username}
password=${tomcat.mgr.password} path=/${tomcat.app.name}
war=file:${tomcat.app.name}-(bld${build.number})-${build.time}.war/
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.7] New build by Sunday
jean-frederic clere wrote: Remy Maucherat wrote: Hi, I plan to make a new build available by Sunday. Comments ? Any issues which would need to be resolved by then ? A number of issues have been filed about commons-daemon and the new Windows .exe wrapper. Is anyone working on resolving them ? (Mladen, JF ?) I could have helped on that, but the requirement for Visual C++ prevents me from doing so. Is there any way around ? I use _only_ cygwin and gcc for the developements I have done for windoze. Even for the .exe wrapper for Windows ? How does it work ? Could you explain ? (I don't have than many bugs to work anymore on Tomcat itself, so I could help too) Thanks :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22263] New: - autodeploy conflicts with manager undeploy/deploy cycle
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22263. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22263 autodeploy conflicts with manager undeploy/deploy cycle Summary: autodeploy conflicts with manager undeploy/deploy cycle Product: Tomcat 5 Version: 5.0.6 Platform: Other OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When autodeploy is enabled on the server, it creates contention with the manager deploy command when the update=true flag is set. When this flasg is set, the manager first performs and undeploy if necessary and then a deploy. After the undeploy, the autodeployer often redeploys the web application before the manager gets a chance to. This results in the manager, returning an error that the application is already deployed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug Report - 4.1.27 Race Condition
Hello, I have found a small bug during my work embedding the tomcat server into our application. When a secure connector is added to an instance of Embedded, and embedded is startd and stopped several times in quick succession (which is part of our test framework) a race condition occurs. Sometimes i am presented with an exception with a root cause of... Caused by: LifecycleException: Coyote connector has not been started at org.apache.coyote.tomcat4.CoyoteConnector.stop(CoyoteConnector.java:1199) at org.apache.catalina.startup.Embedded.stop(Embedded.java:1030) (NOTE: This exception is thrown after a call to the start method of Embedded has been made and connectors added) Other times the test is successful. Sometimes (although a little more rare than these two outcomes), I recieve an 'Address already in use', which seems to be the inverse of the exception above, and occurs on a call to start() after a stop() has already been made. Placing a Thread.sleep(x) between start/stop attempts seems to increase the likelyhood of the test being successful and increasing the interval increase the percentage of successful test runs until upon reaching an interval of 75ms the success rate becomes 100%. It seems there is a race condition in starting up or shutting down of Embedded vs The secure connector. Sometimes Embedded.start() will return before the connector has been started and the same with Embedded.stop(). Unfortunatly, i cannot seem to locate the Coyote source to verify this. Presumably, this issue is pretty minor as the only circumstance i can see where someone will be running stops and starts in quick succession is a contrived test case, but i thought i would bring it to your attention anyway. Regards Wesley I. Hall P.S. If Mr Bill Barker is reading this, your advice on my https problem worked like a charm. I owe you a beer! =o) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP] Build Failure - Tomcat 3.x
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-08-06/jakarta-tomcat.html Buildfile: build.xml detect: uptodate: msg.ant15: [echo] Detected Ant 1.5 msg.jdk12: [echo] Detected JDK1.2 msg.jsse: [echo] Detected JSSE msg.jmx: [echo] Detected JMX msg.jmxtools: [echo] Detected JMX TOOLS msg.puretls: msg.commons-dbcp: [echo] Detected commons-DBCP and required jars msg.jtc: msg.jtc.util: [echo] tomcat-util.jar is up to date msg.log4j: init: prepare.dirs: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf/auto [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/logs [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/webapps [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/modules [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copying 10 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Copying 18 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [copy] Copying 44 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [copy] Copying 85 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common [move] Moving 4 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin prepare.jaxp101: include.jaxp: prepare.jaxp11: prepare.xerces: prepare.xerces2: prepare.xml-parser: prepare.jaxp: prepare: dep.tomcat-util: tomcat_util: [javac] Compiling 47 source files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common/core_util.jar [copy] Copying 2 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common BUILD FAILED /home/rubys/jakarta/jakarta-tomcat/build.xml:467: Warning: Could not find file /home/rubys/jakarta/jakarta-commons/commons-logging-1.0.2/commons-logging-api.jar to copy. Total time: 9 seconds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22293] - JasperLoader prepends fixed package name
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22293. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22293 JasperLoader prepends fixed package name --- Additional Comments From [EMAIL PROTECTED] 2003-08-11 22:30 --- *** Bug 22294 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
