RE: [Maybe spam] unsubscribe trouble
Hi, We appreciate your interest in vPOST. We have noted on your feedback and will make the necessary arrangements to filter your email from receiving our newsletter. We apologise for any inconvenience caused. Thank you and have a nice day. Yours sincerely, vPOST Customer Service [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] From: miji mathews [mailto:[EMAIL PROTECTED] Sent: Sat 10/6/2006 8:04 PM To: [EMAIL PROTECTED] Cc: tomcat-dev@jakarta.apache.org Subject: [Maybe spam] unsubscribe trouble how do I unsubscribe ? Im geeting all these emails that I didnt sign up for . I already tried unsubscribe email about 10 times Please help miji - 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]
RE: [Maybe spam] unsubscribe trouble
Hi, Who are u? Thank you and have a nice day. Yours sincerely, vPOST Customer Service [EMAIL PROTECTED] From: enquiries Sent: Tue 13/6/2006 2:09 PM To: Tomcat Developers List Subject: RE: [Maybe spam] unsubscribe trouble Hi, We appreciate your interest in vPOST. We have noted on your feedback and will make the necessary arrangements to filter your email from receiving our newsletter. We apologise for any inconvenience caused. Thank you and have a nice day. Yours sincerely, vPOST Customer Service [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] From: miji mathews [mailto:[EMAIL PROTECTED] Sent: Sat 10/6/2006 8:04 PM To: [EMAIL PROTECTED] Cc: tomcat-dev@jakarta.apache.org Subject: [Maybe spam] unsubscribe trouble how do I unsubscribe ? Im geeting all these emails that I didnt sign up for . I already tried unsubscribe email about 10 times Please help miji - 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 39794] New: - getResource method of WebappClassLoader does not return URLs for packages
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=39794. 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=39794 Summary: getResource method of WebappClassLoader does not return URLs for packages Product: Tomcat 5 Version: 5.0.30 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] In my application scenario I need to be able to find all resources located within a given package. Therefore, I use the getResource method to find first the package along the classpath and afterwards I list all resources located within this package. I need this functionality to find all available Hibernate mapping documents so that I can dynamically configure Hibernate and dont need to know exact names of mapping documents. However, the WebappClassLoader does not return URLs for packages. For example Thread.currentThread().getContextClassLoader().getResource(path/to/package); returns null. The workaround for this issue is to place a resource with a fixed name in this package, so that this resource can be found. From the returned URL I extract the directory and than list the resources within that directory. However, the getResource method of the JVM classloader implementation also returns URLs for packages so that this workaround is not needed I 'normal' java applications. I am not sure whether or not this is a bug of the webapp classloader implementation. I use tomcat 5.0.30 and Java 1.5.0_07. Kind regards Markus jessenitschnig -- 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]
Re: WebappLoader RFC
Glen Marchesani wrote: Loader className=org.apache.catalina.loader.MyWebappLoader extendedClasspath=C:/mycode/myproject/lib/*.jar;C:/mycode/myproject2/lib/*.jar;C:/mycode/myproject2/classes/ / /Context The reason for doing this is when developping a webapp that consists of several smaller projects I wanted to be able to from within the ide edit-compile-run skipping the deploy step. Skipping the deploy step saves a fair bit of tediousness. Which IDE are you using ? My IDE understands both the containers classpath and the web-app classpath fairly well. This means my IDE is able to resolve a dependency tree so its able to calculate the best possible approach to take. My IDE also supports hot-code replace (providing the JVM will allow it for a given situation, adding fields is a problem when one or more instances exist). My IDE also supports exporting of a JAR from another project into the WEB-INF/lib of the web-app project that is running under a debugging version of TC. If you are now bypassing all of the above, how do you cope with the problematic scenarios this now presents ? On the face of it; it may appear to skip the redeploy process but how can you be sure what you are debugging is the current version of code ? Then how in the future as IDE technology and tooling gets better can it make the best decision given that only the IDE has all the available knowledge about the edit-compile-run process. In short if one popular IDE is able to do so much (without patching features into TC) then it would appear to set the mark of what is possible. It questions if your approach would be a long term fix or just a patch over how you currently see the problem in the moment. Maybe your problem is more of configuration. Infact I think might be worth adding a section to the documentation outlining the features TC supports in the development cycle and when and how to set them up for use. Then another section on how setup (or tips) on working with a particular IDE (from the web-app developers PoV). Darryl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39795] New: - ServletContext.getInitParameter() is null after jsp has been recompiled
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=39795. 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=39795 Summary: ServletContext.getInitParameter() is null after jsp has been recompiled Product: Tomcat 5 Version: 5.5.17 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Jasper AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] A have set a context parameter in the server.xml [...] host [...] Context path=/somewebapp Parameter name=realm_id value=1 / [...] In the jsp I get the parameter by % String realmId = getServletContext().getInitParameter(realm_id); % This works ok, but when the jsp page are modified and recompiled, the parameter is null. Instaid of getServletContext() I have also used the application attribute, but with the same result. -- 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 39795] - ServletContext.getInitParameter() is null after jsp has been recompiled
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=39795. 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=39795 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2006-06-13 08:22 --- This obviously works. -- 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]
code structure and api docs for Tomcat 5.5
Hello, I have checked-out and built Tomcat sources in Eclipse as described at http://tomcat.apache.org/tomcat-5.5-doc/building.html. Although there are a number of errors when trying to run the code, it seems that (at least the build part) is all right. However, I'm having some problems understanding the structure of the whole project because the apparent inconsistency between the documentation (Tomcat API for v. 5.5) and the source code in the (5) Tomcat projects. For instance, I cannot locate the org.apache.jk.* packages in the sources of any of these projects, although I would expect them to be in the connector project, or maybe in the catalina/container project. Also, the Tomcat API docs seem to cover packages for both the catalina and connector projects, but misses a number of other packages (webapps, juli, etc). I would appreciate very much if you could give me some more details about the structure of the project, and how this matches the API docs for Tomcat 5.5. Thank you in advance, Adrian __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
What triggers jspDestroy?
Hello, I got no response for this on the tomcat-users list. I think it may be more appropriate for this list since it's more about the internals of Tomcat: -- I have a page that renders a very large report using the apache jstl tags. When the page has finished running, my memory usage jumps up 70MB. Even if I force a full garbage collection (verified in my garbage collector log), memory usage does not decrease. There is no data being cached or stored in the user's session, it's simply dumped into the request and rendered by the JSP. I've found that if I un-deploy the war and force a full garbage collection, memory usage drops 70MB. I've also found that after waiting about 30 minutes, the memory is released. When I did memory snapshots before and after running that page, I could still see the page exists in memory (org.apache.jsp.ContactReport_jsp) and appears to be holding on to that 70MB. From what I've read (http://issues.apache.org/bugzilla/show_bug.cgi?id=25623) , it's seems like the memory that is used by the jstl foreach tag is not released until the page is destroyed. I'd like to verify this is truly the case and I'd also like to find out exactly what triggers the call to jspDestroy. Is there a timer, a thread, a memory threshold? Is there something I can/should configure to keep the page from eating up all of that memory for so long? I've tried disabling tag pooling, but that had no effect. Thanks!!
DO NOT REPLY [Bug 39803] New: - Unified EL impl doesn't support enums
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=39803. 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=39803 Summary: Unified EL impl doesn't support enums Product: Tomcat 6 Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: blocker Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Forgive me if Jacob already fixed this. Now that Tomcat 6 Bugzilla seems to be working, I wanted to get this in here so it won't be forgotten. Last time I checked, enum support, as defined in section 1.18.6 of the EL spec, was missing. -- 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 39804] New: - JspFactory.getDefaultFactory() returns null
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=39804. 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=39804 Summary: JspFactory.getDefaultFactory() returns null Product: Tomcat 6 Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Jasper AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Section 5.6.1 of the JSF 1.2 spec requires that an ELResolver be added to the JspApplicationContext at application initialization time. So, JSF does this in a ServletContextListener: JspFactory factory = JspFactory.getDefaultFactory(); JspApplicationContext appCtx = factory.getJspApplicationContext(servletContext); appCtx.addELResolver(myResolver); However, at this point the org.apache.jasper.compiler.JspRuntimeContext class has not been loaded. So, getDefaultFactory() returns null. If I add this to my ServletContextListener then everything works: Class.forName(org.apache.jasper.compiler.JspRuntimeContext); This workaround is Tomcat-specific and doesn't belong in JSF code. Tomcat's implementation of getDefaultFactory() should load the JspRuntimeContext if it has not already been created. It should never return null. -- 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 39805] New: - Annotations only working for public methods
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=39805. 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=39805 Summary: Annotations only working for public methods Product: Tomcat 6 Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The new annotations feature is only working for public methods. Section 5.2.3 of the JEE spec says that you can annotate members with any access modifier. The problem is that AnnotationProcessor calls IntrospectionUtils.findMethods(). findMethods() uses Class.getMethods() which only returns public methods. -- 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]
HELP Wanted
Summarry: I have five webased web site with java application. One application per web site. Here is my current enviroment: OS = Linux RedHat 4.0 Appache 2.0.50 Connector JK 1.2.6 Tomcat 5.5.4 I am currently have each website and application run on one machine. I also have some machine with two Tomcat instance. Each Tomcat instance support one virtual website and one application (context). Here is my new requirements: I have 5 webased application: Main Site: I would like all five web site run on the same machine #1 (with Apache and JK connector). I would like all five application using the same Tomcat instance (multiple context) on the same machine #2. Security and protect for both web site and application container need tobe consider in your implementation. Failover and Clustering Site: I would like machine #3 to be in cluster with machine #1 and machine #4 to be cluster with machine number #2. I will use load balance for the appache (machine #1 and machine #3). If you have a better sugguestion, I am listening. I also included a sample topology. I have built and configured all of my site with appache, tomcat and connector. The part I need help with is the multiple context with one Tomcat instance and clustering. I am currently have very little time to figure out how multiple context and clustering works. This is where I can use some help from some of you who have experienced with it and wanted to make some extra money. Please email if you are interested. If none of you volunteer I will have to post my need on the list and keep bother you all until I get some solution (-: (-: [EMAIL PROTECTED] Thanks much, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HELP Wanted with attachment
Summarry: I have five webased web site with java application. One application per web site. Here is my current enviroment: OS = Linux RedHat 4.0 Appache 2.0.50 Connector JK 1.2.6 Tomcat 5.5.4 I am currently have each website and application run on one machine. I also have some machine with two Tomcat instance. Each Tomcat instance support one virtual website and one application (context). Here is my new requirements: I have 5 webased application: Main Site: I would like all five web site run on the same machine #1 (with Apache and JK connector). I would like all five application using the same Tomcat instance (multiple context) on the same machine #2. Security and protect for both web site and application container need tobe consider in your implementation. Failover and Clustering Site: I would like machine #3 to be in cluster with machine #1 and machine #4 to be cluster with machine number #2. I will use load balance for the appache (machine #1 and machine #3). If you have a better sugguestion, I am listening. I also included a sample topology. I have built and configured all of my site with appache, tomcat and connector. The part I need help with is the multiple context with one Tomcat instance and clustering. I am currently have very little time to figure out how multiple context and clustering works. This is where I can use some help from some of you who have experienced with it and wanted to make some extra money. Please email if you are interested. If none of you volunteer I will have to post my need on the list and keep bother you all until I get some solution (-: (-: [EMAIL PROTECTED] Thanks much, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What triggers jspDestroy?
Hi Bob, Bob Damato wrote On 06/13/06 07:49,: Hello, I got no response for this on the tomcat-users list. I think it may be more appropriate for this list since it's more about the internals of Tomcat: -- I have a page that renders a very large report using the apache jstl tags. When the page has finished running, my memory usage jumps up 70MB. Even if I force a full garbage collection (verified in my garbage collector log), memory usage does not decrease. There is no data being cached or stored in the user's session, it's simply dumped into the request and rendered by the JSP. I've found that if I un-deploy the war and force a full garbage collection, memory usage drops 70MB. I've also found that after waiting about 30 minutes, the memory is released. When I did memory snapshots before and after running that page, I could still see the page exists in memory (org.apache.jsp.ContactReport_jsp) and appears to be holding on to that 70MB. From what I've read (http://issues.apache.org/bugzilla/show_bug.cgi?id=25623) , it's seems like the memory that is used by the jstl foreach tag is not released until the page is destroyed. I'd like to verify this is truly the case and I'd also like to find out exactly what triggers the call to jspDestroy. Is there a timer, a thread, a memory threshold? Is there something I can/should configure to keep the page from eating up all of that memory for so long? I've tried disabling tag pooling, but that had no effect. jspDestroy() is called when the container invokes the destroy() method of the servlet into which your JSP page was compiled, which will happen when the webapp containing your JSP is undeployed. Are you overriding jspDestroy() in your page? Notice that jspDestroy() is different from Tag.release(), which is invoked on a tag handler once all invocations on the tag handler are completed. If pooling is disabled, a tag handler's release() method will be called right after the tag handler's doEndTag() method, but when pooling is enabled, each pooled tag handler's release() method will be invoked as part of the servlet's destroy(). Jan Thanks!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r413988 - in /tomcat/container/tc5.5.x/modules/groupcom: src/share/org/apache/catalina/tribes/ src/share/org/apache/catalina/tribes/group/ src/share/org/apache/catalina/tribes/group/interc
Author: fhanik
Date: Tue Jun 13 15:07:01 2006
New Revision: 413988
URL: http://svn.apache.org/viewvc?rev=413988view=rev
Log:
Completed almost all of the coordinator, still need test cases for all the use
cases that exists
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/UniqueId.java
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/ChannelInterceptorBase.java
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/TcpFailureDetector.java
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/membership/McastService.java
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/util/Arrays.java
tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/test/interceptors/TestNonBlockingCoordinator.java
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java?rev=413988r1=413987r2=413988view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
Tue Jun 13 15:07:01 2006
@@ -165,9 +165,14 @@
* @throws ChannelException if a startup error occurs or the service is
already started.
* @see Channel
*/
-public void stop(int svc) throws ChannelException;
-
+public void stop(int svc) throws ChannelException;
+public void fireInterceptorEvent(InterceptorEvent event);
+
+interface InterceptorEvent {
+int getEventType();
+ChannelInterceptor getInterceptor();
+}
}
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/UniqueId.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/UniqueId.java?rev=413988r1=413987r2=413988view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/UniqueId.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/UniqueId.java
Tue Jun 13 15:07:01 2006
@@ -60,5 +60,11 @@
public byte[] getBytes() {
return id;
}
+
+public String toString() {
+StringBuffer buf = new StringBuffer(UniqueId);
+buf.append(org.apache.catalina.tribes.util.Arrays.toString(id));
+return buf.toString();
+}
}
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/ChannelInterceptorBase.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/ChannelInterceptorBase.java?rev=413988r1=413987r2=413988view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/ChannelInterceptorBase.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/ChannelInterceptorBase.java
Tue Jun 13 15:07:01 2006
@@ -162,6 +162,10 @@
public void stop(int svc) throws ChannelException {
if (getNext() != null) getNext().stop(svc);
}
+
+public void fireInterceptorEvent(InterceptorEvent event) {
+//empty operation
+}
}
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java?rev=413988r1=413987r2=413988view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
Tue Jun 13 15:07:01 2006
@@ -33,6 +33,9 @@
import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicInteger;
import org.apache.catalina.tribes.membership.*;
+import
svn commit: r413996 - in /tomcat/container/tc5.5.x/modules/groupcom: src/share/org/apache/catalina/tribes/group/interceptors/ src/share/org/apache/catalina/tribes/transport/nio/ test/java/org/apache/c
Author: fhanik
Date: Tue Jun 13 15:45:25 2006
New Revision: 413996
URL: http://svn.apache.org/viewvc?rev=413996view=rev
Log:
Fine tuned the test cases, we don't need long sleeps, it should all go pretty
quick
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/transport/nio/NioReplicationThread.java
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/test/interceptors/TestNonBlockingCoordinator.java
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java?rev=413996r1=413995r2=413996view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
Tue Jun 13 15:45:25 2006
@@ -241,8 +241,19 @@
protected void sendElectionMsgToNextInline(MemberImpl local,
CoordinationMessage msg) throws ChannelException {
int next = Arrays.nextIndex(local,msg.getMembers());
+int current = next;
msg.leader = msg.getMembers()[0];
-if ( next = 0 )
sendElectionMsg(local,(MemberImpl)msg.getMembers()[next],msg);
+boolean sent = false;
+while ( !sent current = 0 ) {
+try {
+sendElectionMsg(local, (MemberImpl) msg.getMembers()[current],
msg);
+sent = true;
+}catch ( ChannelException x ) {
+log.warn(Unable to send election message
to:+msg.getMembers()[current]);
+current =
Arrays.nextIndex(msg.getMembers()[current],msg.getMembers());
+if ( current == next ) throw x;
+}
+}
}
public Member getNextInLine(MemberImpl local, MemberImpl[] others) {
@@ -479,7 +490,7 @@
if ( membership == null ) setupMembership();
if ( membership.memberAlive((MemberImpl)member) )
super.memberAdded(member);
try {
-fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_MBR_ADD,this,Member add));
+fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_MBR_ADD,this,Member
add(+member.getName()+)));
if (started elect) startElection(false);
}catch ( ChannelException x ) {
log.error(Unable to start election when member was added.,x);
@@ -495,7 +506,7 @@
membership.removeMember((MemberImpl)member);
super.memberDisappeared(member);
try {
-fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_MBR_DEL,this,Member remove));
+fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_MBR_DEL,this,Member
remove(+member.getName()+)));
if ( started (isCoordinator() ||
member.equals(getCoordinator())) )
startElection(false);
//to do, if a member disappears, only the coordinator can start
@@ -696,7 +707,8 @@
}
public void fireInterceptorEvent(InterceptorEvent event) {
-System.out.println(event);
+if (event instanceof CoordinationEvent
+((CoordinationEvent)event).type == CoordinationEvent.EVT_CONF_RX)
System.out.println(event);
}
public static class CoordinationEvent implements InterceptorEvent {
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/transport/nio/NioReplicationThread.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/transport/nio/NioReplicationThread.java?rev=413996r1=413995r2=413996view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/transport/nio/NioReplicationThread.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/transport/nio/NioReplicationThread.java
Tue Jun 13 15:45:25 2006
@@ -191,11 +191,13 @@
Object mutex = this.getPool().getInterestOpsMutex();
synchronized (mutex) {
try {
-// cycle the selector so this key is active again
-key.selector().wakeup();
-// resume interest in OP_READ, OP_WRITE
-
svn commit: r413998 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
Author: fhanik
Date: Tue Jun 13 15:45:59 2006
New Revision: 413998
URL: http://svn.apache.org/viewvc?rev=413998view=rev
Log:
Log to the logger
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java?rev=413998r1=413997r2=413998view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
Tue Jun 13 15:45:59 2006
@@ -708,7 +708,8 @@
public void fireInterceptorEvent(InterceptorEvent event) {
if (event instanceof CoordinationEvent
-((CoordinationEvent)event).type == CoordinationEvent.EVT_CONF_RX)
System.out.println(event);
+((CoordinationEvent)event).type == CoordinationEvent.EVT_CONF_RX)
+log.info(event);
}
public static class CoordinationEvent implements InterceptorEvent {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r414002 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
Author: fhanik
Date: Tue Jun 13 15:59:16 2006
New Revision: 414002
URL: http://svn.apache.org/viewvc?rev=414002view=rev
Log:
Added a semaphore for not receiving messages
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java?rev=414002r1=414001r2=414002view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
Tue Jun 13 15:59:16 2006
@@ -465,6 +465,7 @@
} else if (
Arrays.contains(msg.getMessage().getBytesDirect(),0,COORD_HEADER,0,COORD_HEADER.length)
) {
try {
+if ( !started ) return;
CoordinationMessage cmsg = new
CoordinationMessage(msg.getMessage());
Member[] cmbr = cmsg.getMembers();
fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_MSG_ARRIVE,this,Coord Msg
Arrived(+Arrays.toNameString(cmbr)+)));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: code structure and api docs for Tomcat 5.5
Adrian M wrote: However, I'm having some problems understanding the structure of the whole project because the apparent inconsistency between the documentation (Tomcat API for v. 5.5) and the source code in the (5) Tomcat projects. For instance, I cannot locate the org.apache.jk.* packages in the sources of any of these projects, although I would expect them to be in the connector project, or maybe in the catalina/container project. It is in: http://svn.apache.org/repos/asf/tomcat/connectors/trunk/jk/java/org/apache/jk/ Also, the Tomcat API docs seem to cover packages for both the catalina and connector projects, but misses a number of other packages (webapps, juli, etc). Yep. Not sure if this is deliberate for the webapps. Probably an oversight for juli. I would appreciate very much if you could give me some more details about the structure of the project, and how this matches the API docs for Tomcat 5.5. The best we have is http://tomcat.apache.org/svn.html If you want to contribute patches to the documentation, that woudl be great. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP Wanted
Tom Miller wrote: If none of you volunteer I will have to post my need on the list and keep bother you all until I get some solution (-: (-: Or until I or one of the other list owners get fed up with your spam and unsubscribe you. I'll keep hassling you until you help me isn't what open source is all about. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r414005 - in /tomcat/container/tc5.5.x/modules/groupcom: VERSION src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
Author: fhanik
Date: Tue Jun 13 16:21:30 2006
New Revision: 414005
URL: http://svn.apache.org/viewvc?rev=414005view=rev
Log:
Added version notes
Modified:
tomcat/container/tc5.5.x/modules/groupcom/VERSION
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
Modified: tomcat/container/tc5.5.x/modules/groupcom/VERSION
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/VERSION?rev=414005r1=414004r2=414005view=diff
==
--- tomcat/container/tc5.5.x/modules/groupcom/VERSION (original)
+++ tomcat/container/tc5.5.x/modules/groupcom/VERSION Tue Jun 13 16:21:30 2006
@@ -1,3 +1,5 @@
+0.9.2.6
+ - first version of the NonBlockingCoordinator implemented
0.9.2.5
- minor updates
0.9.2.4
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java?rev=414005r1=414004r2=414005view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
Tue Jun 13 16:21:30 2006
@@ -104,10 +104,8 @@
* A sends Z{A-ldr, A-src, mbrs-A,B,C,C1,D,E} to B and the chain continues
until A receives the token again.
* At that time A optionally sends out Z{A-ldr, A-src, mbrs-A,B,C,C1,D,E,
confirmed} to A,B,C,C1,D,E
* /p
- * pIf we wanted to ensure that the view gets implemented at all nodes at
the same time,
- *ie, implementing a blocking coordinator, we would simply require that
each view, before it gets installed
- *has to receive a VIEW_CONF message, this is the 'confirmed' message that
is optional above.
- *
+ * pTo ensure that the view gets implemented at all nodes at the same time,
+ *A will send out a VIEW_CONF message, this is the 'confirmed' message
that is optional above.
* pIdeally, the interceptor below this one would be the TcpFailureDetector
to ensure correct memberships/p
*
* pThe example above, of course can be simplified with a finite
statemachine:br
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebappLoader RFC
Its unclear now what you are trying to fix. Your first post stated you wanted to cut down on the deploy part (I pointed out the features we currently get that we'd loose with your approach; also that deploy is necessary to flush out the old version of the code in the JVM) and this last post I get the impression you want to cut down on the build and copy JAR to WEB-INF/lib step. I think I understand your situation as I have been there too but lets work through your points. Glen Marchesani wrote: The IDE features you mention sound cool which one is it? I don't want to get into any religious IDE war but Eclipse 3 with WTP 1.0. Any pointers/links to how you got that setup? See below for the outline. Unfortunately for the environment I am working in an IDE specific solution would be incomplete. We have a broad range of use cases (IDEs, OSes) as well as users where we need people to be able to checkout a project and be productive with it in a minimal amount of time. So doing IDE specific tweaks won't cut it. Our solution has worked extremely well with other app containers for example WebSphere, Resin and Jetty (all three that we use) come with support for something like this out of the box. I understand what you are saying, from your commercial standpoint you see the lack of this feature as causing a headache in supporting your customer base container diversity. My point from a technical standpoint your feature is already obsolete since at least one popular IDE already has a working solution which probably works for all containers the IDE supports (I've never tested on anything but TC) which includes the ones you list above. It is just matter of time before the other popular IDEs play catch up. The IDE we use really depends on the customer, project and environment. So could be any of the following ant+text editors, eclipse, WSDC, and/or netbeans... We can seemlessly switch between any of these using this technique by just adding the extendedClasspath line to the context and dropping a jar in server/lib/ all of which is handled by our ant scripts. I am all for continuing this tangential discussion of webapp development techniques but it really is tangential to the intent of the original post.. I'm not against your feature per say just the reasons you cite the need for it. Hot-code replace works fine in this scenario, I get the impression that you think it doesn't. As for your comments about future proofing. I am very confident that IDE's will from now on into the future will compile my .java files to some directory on the disk and that this option will be configurable and use some consistent default. So this solution is completely future-proof. In all the jar exporting to WEB-INF stuff I have seen in various IDE's you need to manually kick off that process so it is adding a step to the edit-compile process. Are you really sure hot code replace work fine in this scenario, I thought the IDE had to be able to understand from its internal dependency graph that the compiled .class file is running on the JVM to be able to push an update to that JVM. The situation you present sounds like you have a web-app running under TC under the IDE and another standalone java project in the IDE. If you edit this standalone project sure you get a compiled .class file out of it, but why would the IDE then offer it up to the TC JVM ? For all intents and purposes the standalone project is disconnected from the running web-app. Since Eclipse WTP 1.0 you can create a J2EE Utility Project which can contribute a JAR into the WEB-INF/lib of J2EE Dynamic Web Project (create those 2 project types, goto the Project Properties page J2EE Module Dependancy of the DWP and tick the box). You can have both projects open and develop them at the same time with the IDE automatically propagating the new compiled code. This feature is still not perfect since TC will auto-redeploy when a JAR changes, the WTP feature would be better if it had a toggle to allow the J2EE Utility Project exported as individual .class files into the WEB-INF/classes tree this would allow Eclipse to attempt a Hot-code replace and thwart some unnecessary TC reloading. In any case if you alter the fields of a class which has one or more active instances Sun's JVM doesn't allow that class to be hot-code-replaced you get an error and Eclipse offers to continue/restart/shutdown the JVM. But there are many common cases where it works well, like adding/changing methods. Eclipse's solution is nearer my vision of the future and generic this makes it future proof to me. What you are proposing as a solution to this problem is a band aid, a dead end; that prohibits the next step to be taken by the IDE towards the ultimate seamless developer experience. Geez I should try marketing. Effectively adding a deploy step so you have edit-compile-deploy. Which is exactly what I am trying to
DO NOT REPLY [Bug 39794] - getResource method of WebappClassLoader does not return URLs for packages
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=39794. 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=39794 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-06-14 01:44 --- This works as you require in the latest 5.5.x code from svn. I have had a quick look at the change log but can't see any obvious patch that would have fixed this. I am going to resolve this as fixed. If you particularly want this fixed in the 5.0.x branch feel free to re-open it but as far as I am aware there is unlikely to be another 5.0.x release so it will get closed again as WONTFIX. -- 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 39793] - Domain name Catalina:type=... is hardcoded in several 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=39793. 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=39793 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2006-06-14 02:24 --- I have checked through the source and as far as I can tell the places where the domain is hardcoded are all due to the mbeans being created before server.xml is read. In this case, there is no way for the code to know what is in server.xml and therefore the default is used. I can think of a number of ways of getting around this but none of them are especially pretty. Since, in my view, the benefit doesn't outweigh the cost, I am going to mark this as won't fix. -- 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 39646] - UnknownHostException. Intermitent. Fixes if tomcat restarted.
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=39646. 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=39646 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2006-06-14 03:01 --- As far as I can tell from your description, it is your application that is doing the screen scraping and the reverse proxying. If this is the case, I can't see how a Tomcat bug could be causing the issue you are seeing. It looks more like an application bug or network problem to me. Restarting Tomcat will, of course, also restart your applciation. I suggest you try the tomcat users mailing list for assistance. If you can find something that points to Tomcat being the problem, and better yet provide a way we can reproduce the issue, then please feel free to re-open this issue. -- 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]
svn commit: r414056 - in /tomcat/container/tc5.5.x/modules/groupcom: src/share/org/apache/catalina/tribes/ src/share/org/apache/catalina/tribes/group/interceptors/ src/share/org/apache/catalina/tribes
Author: fhanik
Date: Tue Jun 13 21:05:24 2006
New Revision: 414056
URL: http://svn.apache.org/viewvc?rev=414056view=rev
Log:
Created a coordination demo, text only, to show how election works
Added:
tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/demos/CoordinationDemo.java
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/util/Arrays.java
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java?rev=414056r1=414055r2=414056view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
Tue Jun 13 21:05:24 2006
@@ -171,6 +171,7 @@
interface InterceptorEvent {
int getEventType();
+String getEventTypeDesc();
ChannelInterceptor getInterceptor();
}
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java?rev=414056r1=414055r2=414056view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
Tue Jun 13 21:05:24 2006
@@ -14,10 +14,12 @@
*/
package org.apache.catalina.tribes.group.interceptors;
-import java.util.LinkedHashMap;
+import java.util.concurrent.atomic.AtomicBoolean;
import org.apache.catalina.tribes.Channel;
import org.apache.catalina.tribes.ChannelException;
+import org.apache.catalina.tribes.ChannelInterceptor;
+import org.apache.catalina.tribes.ChannelInterceptor.InterceptorEvent;
import org.apache.catalina.tribes.ChannelMessage;
import org.apache.catalina.tribes.Member;
import org.apache.catalina.tribes.UniqueId;
@@ -30,12 +32,6 @@
import org.apache.catalina.tribes.membership.Membership;
import org.apache.catalina.tribes.util.Arrays;
import org.apache.catalina.tribes.util.UUIDGenerator;
-import java.util.concurrent.atomic.AtomicBoolean;
-import java.util.concurrent.atomic.AtomicInteger;
-import org.apache.catalina.tribes.membership.*;
-import org.apache.catalina.tribes.test.interceptors.TestNonBlockingCoordinator;
-import org.apache.catalina.tribes.ChannelInterceptor.InterceptorEvent;
-import org.apache.catalina.tribes.ChannelInterceptor;
/**
* pTitle: Auto merging leader election algorithm/p
@@ -217,9 +213,11 @@
//no message arrived, send the coord msg
fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_WAIT_FOR_MSG,this,Election, waiting
timed out.));
startElection(true);
+} else {
+fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_ELECT_ABANDONED,this,Election
abandoned));
}
}//end if
-fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_START_ELECT,this,Election in
progress));
+
}
}
@@ -372,7 +370,7 @@
}
viewChange(viewId,view.getMembers());
-fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_CONF_RX,this,Accepted View
id(+this.viewId+)));
+fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_CONF_RX,this,Accepted View));
if ( suggestedviewId == null
hasHigherPriority(merged.getMembers(),membership.getMembers()) ) {
startElection(false);
@@ -401,6 +399,14 @@
return (view != null view.hasMembers()) ? view.getMembers()[0] :
null;
}
+public Member[] getView() {
+return (view != null view.hasMembers()) ? view.getMembers() : new
Member[0];
+}
+
+public UniqueId getViewId() {
+return viewId;
+}
+
/**
* Block in/out messages while a election is going on
*/
@@ -723,6 +729,7 @@
static final int EVT_SEND_MSG = 10;
static final int EVT_STOP = 11;
static final int EVT_CONF_RX = 12;
+static final int EVT_ELECT_ABANDONED = 13;
svn commit: r414060 - /tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/demos/CoordinationDemo.java
Author: fhanik
Date: Tue Jun 13 21:13:19 2006
New Revision: 414060
URL: http://svn.apache.org/viewvc?rev=414060view=rev
Log:
Added count to demo
Modified:
tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/demos/CoordinationDemo.java
Modified:
tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/demos/CoordinationDemo.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/demos/CoordinationDemo.java?rev=414060r1=414059r2=414060view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/demos/CoordinationDemo.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/demos/CoordinationDemo.java
Tue Jun 13 21:13:19 2006
@@ -19,13 +19,14 @@
static int CHANNEL_COUNT = 5;
static int SCREEN_WIDTH = 120;
StringBuffer statusLine = new StringBuffer();
-Status[] status = new Status[CHANNEL_COUNT];
+Status[] status = null;
BufferedReader reader = null;
/**
* Construct and show the application.
*/
public CoordinationDemo() {
reader = new BufferedReader(new InputStreamReader(System.in));
+status = new Status[CHANNEL_COUNT];
}
@@ -136,6 +137,7 @@
public static void main(String[] args) throws Exception {
+if ( args.length == 1 ) CHANNEL_COUNT = Integer.parseInt(args[0]);
CoordinationDemo demo = new CoordinationDemo();
demo.waitForInput();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r414061 - in /tomcat/container/tc5.5.x/modules/groupcom: VERSION to-do.txt
Author: fhanik Date: Tue Jun 13 21:15:00 2006 New Revision: 414061 URL: http://svn.apache.org/viewvc?rev=414061view=rev Log: Completed coordination demo Modified: tomcat/container/tc5.5.x/modules/groupcom/VERSION tomcat/container/tc5.5.x/modules/groupcom/to-do.txt Modified: tomcat/container/tc5.5.x/modules/groupcom/VERSION URL: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/VERSION?rev=414061r1=414060r2=414061view=diff == --- tomcat/container/tc5.5.x/modules/groupcom/VERSION (original) +++ tomcat/container/tc5.5.x/modules/groupcom/VERSION Tue Jun 13 21:15:00 2006 @@ -1,5 +1,6 @@ 0.9.2.6 - first version of the NonBlockingCoordinator implemented + - org.apache.catalina.tribes.demos.CoordinationDemo implemented 0.9.2.5 - minor updates 0.9.2.4 Modified: tomcat/container/tc5.5.x/modules/groupcom/to-do.txt URL: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/to-do.txt?rev=414061r1=414060r2=414061view=diff == --- tomcat/container/tc5.5.x/modules/groupcom/to-do.txt (original) +++ tomcat/container/tc5.5.x/modules/groupcom/to-do.txt Tue Jun 13 21:15:00 2006 @@ -46,16 +46,6 @@ 49. Implement versioning on the AbstractReplicatedMap - -9. CoordinatorInterceptor - manages the selection of a cluster coordinator - just had a brilliant idea, if GroupChannel keeps its own view of members, - the coordinator interceptor can hold on to the member added/disappared event - It can also intercept down going messages if the coordinator disappeared - while a new coordinator is chosen - It can also intercept down going messages for members disappeared that the - calling app not yet knows about, to avoid a ChannelException - The coordinator is needed because of the mixup when two channels startup instantly - 48. Periodic refresh of the replicated map (primary -backup) 47. Delta(session) versioning. increase version number each time, easier to keep maps in sync @@ -308,3 +298,14 @@ 19. Implement a hardcoded tcp membership Notes: Completed + +9. CoordinatorInterceptor - manages the selection of a cluster coordinator + just had a brilliant idea, if GroupChannel keeps its own view of members, + the coordinator interceptor can hold on to the member added/disappared event + It can also intercept down going messages if the coordinator disappeared + while a new coordinator is chosen + It can also intercept down going messages for members disappeared that the + calling app not yet knows about, to avoid a ChannelException + The coordinator is needed because of the mixup when two channels startup instantly +Notes: Completed. org.apache.catalina.tribes.group.interceptors.NonBlockingCoordinatorInterceptor + implements an automerging algorithm. \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r414073 - in /tomcat/container/tc5.5.x/modules/groupcom: src/share/org/apache/catalina/tribes/group/interceptors/ src/share/org/apache/catalina/tribes/util/ test/java/org/apache/catalina/t
Author: fhanik
Date: Tue Jun 13 21:53:55 2006
New Revision: 414073
URL: http://svn.apache.org/viewvc?rev=414073view=rev
Log:
Fixed nextIndex bug and added support for multi threading during start/stop of
the entire demo
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/TcpFailureDetector.java
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/util/Arrays.java
tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/demos/CoordinationDemo.java
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/TcpFailureDetector.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/TcpFailureDetector.java?rev=414073r1=414072r2=414073view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/TcpFailureDetector.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/TcpFailureDetector.java
Tue Jun 13 21:53:55 2006
@@ -33,6 +33,7 @@
import org.apache.catalina.tribes.io.XByteBuffer;
import org.apache.catalina.tribes.membership.MemberImpl;
import org.apache.catalina.tribes.membership.Membership;
+import java.net.ConnectException;
/**
* pTitle: A perfect failure detector /p
@@ -254,6 +255,8 @@
}//end if
return true;
} catch ( SocketTimeoutException sx) {
+//do nothing, we couldn't connect
+} catch ( ConnectException cx) {
//do nothing, we couldn't connect
}catch (Exception x ) {
log.error(Unable to perform failure detection check, assuming
member down.,x);
Modified:
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/util/Arrays.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/util/Arrays.java?rev=414073r1=414072r2=414073view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/util/Arrays.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/util/Arrays.java
Tue Jun 13 21:53:55 2006
@@ -163,9 +163,13 @@
}
public static int nextIndex(Member member, Member[] members) {
-int idx = indexOf(member,members);
-if (idx == (members.length-1) ) return members.length0?0:-1;
-else return idx+1;
+int idx = indexOf(member,members)+1;
+if (idx = members.length ) idx = ((members.length0)?0:-1);
+
+//System.out.println(Next index:+idx);
+//System.out.println(Member:+member.getName());
+//System.out.println(Members:+toNameString(members));
+return idx;
}
Modified:
tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/demos/CoordinationDemo.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/demos/CoordinationDemo.java?rev=414073r1=414072r2=414073view=diff
==
---
tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/demos/CoordinationDemo.java
(original)
+++
tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/demos/CoordinationDemo.java
Tue Jun 13 21:53:55 2006
@@ -18,6 +18,7 @@
public class CoordinationDemo {
static int CHANNEL_COUNT = 5;
static int SCREEN_WIDTH = 120;
+static boolean MULTI_THREAD = false;
StringBuffer statusLine = new StringBuffer();
Status[] status = null;
BufferedReader reader = null;
@@ -38,9 +39,10 @@
public void printMenuOptions() {
System.out.println(Commands:);
-System.out.println(start [member id]);
-System.out.println(stop [member id]);
-System.out.println(quit);
+System.out.println(\tstart [member id]);
+System.out.println(\tstop [member id]);
+System.out.println(\tprint (refresh));
+System.out.println(\tquit);
System.out.print(Enter command:);
}
@@ -90,33 +92,9 @@
String[] args = tokenize(l);
while ( args.length = 1 (!quit.equalsIgnoreCase(args[0]))) {
if (start.equalsIgnoreCase(args[0])) {
-if ( args.length == 1 ) {
-setSystemStatus(System starting up...);
-for (int i = 0; i status.length; i++) status[i].start();
-setSystemStatus(System started.);
-} else {
-int index = -1;
-try { index =
DO NOT REPLY [Bug 39810] New: - Security flaw in security-constraint when request made by \
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=39810. 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=39810 Summary: Security flaw in security-constraint when request made by \ Product: Tomcat 5 Version: 5.5.17 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P3 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I've the following web-xml part... security-constraint web-resource-collection web-resource-nameAdminPages/web-resource-name descriptionAccessible by registered users/description url-pattern/admin/*/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint descriptionThese are the roles who have access/description role-nameregistered/role-name /auth-constraint /security-constraint and all the other necessary parts... the problem is that everithing is fine... while the request are like http://localhost:8080/admin/something; as expected it sends me to the defined login page BUT THE PROBLEM IS WHEN I USE \ (backslash) AS THE SEPARATOR like... http://localhost:8080/admin\something; tomcat retrives the resource with no security concerns... hope this is helpfully enought... oohhh while I was writing this I realize that this bug is only showing in firefox browser so I imagine maybe it their bug... please let me know so I put this to them if this is not the place where I should put this... any way it seems very important for you so I'm posting... David Castañeda -- 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]
