DO NOT REPLY [Bug 33117] Deep link into Bugzilla broken on ROOT/index.jsp
https://issues.apache.org/bugzilla/show_bug.cgi?id=33117 rodriguez...@aol.com changed: What|Removed |Added Status|CLOSED |RESOLVED -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 33117] Deep link into Bugzilla broken on ROOT/index.jsp
https://issues.apache.org/bugzilla/show_bug.cgi?id=33117 Konstantin Kolinko changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48694] WebappClassLoader deadlock if web application uses it's own classloader
https://issues.apache.org/bugzilla/show_bug.cgi?id=48694 --- Comment #11 from aullr...@blackducksoftware.com 2010-03-13 15:44:31 UTC --- Can't see how you'd get into this situation with the current source code. The stack traces indicate that findClass on the WebappClassLoader would have to be a synchronized method? Is JRebel changing the byte code of the loader by any chance? But maybe I'm just blind ;-) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48903] ClassLoader deadlock when compiling JSP pages in 6.0.26
https://issues.apache.org/bugzilla/show_bug.cgi?id=48903 --- Comment #3 from Konstantin Kolinko 2010-03-14 00:31:00 UTC --- Created an attachment (id=25125) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25125) MyClassLoader.java - sample of reflectively calling JDK7 API I just tested that the JDK7 ClassLoader methods that I mentioned in comment 2 can be reflectively called by a class compiled with JDK 6. I was afraid that registerAsParallelCapable() will not work when called through reflection. I am attaching a sample ClassLoader implementation that calls those methods. On success it prints something like this: Result: true Lock: java.lang.obj...@1befab0 where the lock is not the classloader, but some other object. I tested that it runs successfully with JDK7 early access milestone 5 (jre-7-ea-bin-b76-windows-i586-12_nov_2009). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48906] New: Client's context information is not updated automatically in conf/Catalina
https://issues.apache.org/bugzilla/show_bug.cgi?id=48906 Summary: Client's context information is not updated automatically in conf/Catalina Product: Tomcat 6 Version: 6.0.26 Platform: PC OS/Version: other Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: t...@let-it-out.com Updating/deploying a client with new context information will not trigger an update of the client context information in conf/Catalina/.xml. I normally keep the context file in the META-INF folder inside my client (e.g webapps//META-INF/context.xml) which contains the database information amongst others. eg. Then I run the ant script to replace and redeploy the client to the usual webapps folder and finally start Tomcat. Upon launch I was expecting Tomcat to reread the context file from the META-INF and update itself but it didn't do that. I had to manually change that. Kind Regards Tony -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48906] Client's context information is not updated automatically in conf/Catalina
https://issues.apache.org/bugzilla/show_bug.cgi?id=48906 Konstantin Kolinko changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Konstantin Kolinko 2010-03-14 03:34:05 UTC --- Your expectations are wrong. That is a feature. You may read the docs or ask/search on the tomcat-users mailing list for details. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Using JIRA instead STATUS.txt
Hi, I would suggest that we use JIRA instead maintaining STATUS.txt files. Each branch can then be a separate component and each status vote JIRA issue classified as either bug, feature, etc... Voting is supported except that one cannot vote for the created issue, so that would be presumed. However there is no -1 vote, so that would have to be done like today by entering the comment with -1. Nice thing is that patches can be directly attached without the need to scp to the people.a.o. If we decide on that I'll work with IT to allow only committers write access. Comments? Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
