svn commit: r400313 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/membership/McastService.java

[fhanik]

Author: fhanik
Date: Sat May  6 06:41:55 2006
New Revision: 400313

URL: http://svn.apache.org/viewcvs?rev=400313&view=rev
Log:
Add the ability to change the payload on the fly

Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/membership/McastService.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/membership/McastService.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/membership/McastService.java?rev=400313&r1=400312&r2=400313&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/membership/McastService.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/membership/McastService.java
 Sat May  6 06:41:55 2006
@@ -390,6 +390,10 @@
 
 public void setPayload(byte[] payload) {
 this.payload = payload;
+if ( localMember != null ) {
+localMember.setPayload(payload);
+localMember.getData(true,true);
+}
 }
 
 /**



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r400201 - in /tomcat/container/tc5.5.x/modules: groupcom/build/ groupcom/src/share/org/apache/catalina/tribes/ groupcom/src/share/org/apache/catalina/tribes/membership/ groupcom/test/j

[Filip Hanik - Dev Lists]

sure thing,
The current implementation was:
- add a domain field
- broadcast the domain field
- change replication code to accomodate for the field
- change server.xml to set the domain
- replication only occurs within the domain

The exact same functionality could have been achieved:
- change mcastAddr in server.xml
- replication only occurs within the domain

So as you can see, so much code was written that could have been done
with one tiny configuration change. And, the comm layer had no benefit 
of it either,
so it was an applicatin specific need, and the code trickled down all 
the way to the comm layer,
and that is the problem with the old app. many features needed in the 
app layer, were coded in the comm layer and the other way around.


If the data was only valuable to the application that sits on top, then 
it should be managed by the application on top.

The functionality still exists:
http://people.apache.org/~fhanik/tribes/javadoc/org/apache/catalina/tribes/MembershipService.html#setPayload(byte[])

When a channel is created today, the application can set a custom 
payload (domain,admin JMX port,load averages,anything you can think of)
can be broadcasted. So the feature is still there, its just application 
specific. The comm layer knows nothing about domains.


With the custom payload you have lost 0 features over the old 
implementation, but you have gained a lot more flexibility, as you not 
are limited to just broadcasting a domain, you can broadcast all kinds 
of useful data.


Remember, that you can also build a custom interceptor that modifies 
both membership and message data as it passes through the channel, only 
your imagination becomes the limitation here.


For example, TcpFailureDetector, a simple implementation that overrides 
the multicast membership for failure detection.

http://people.apache.org/~fhanik/tribes/javadoc/org/apache/catalina/tribes/group/interceptors/TcpFailureDetector.html
this interceptor keeps its own membership and if a member times out, it 
will verify the timeout with a connection attempt.


This is just a simple example of how an interceptor can override 
implemented membership logic, you can create an interceptor that 
implements all kinds of logic to manipulate membership.


What we've done with "ha" and "groupcom" modules is to split logic to 
keep it where it belongs.
I have compiled a little introduction to Tribes which gives you a basic 
understanding of the feature set

http://people.apache.org/~fhanik/tribes/docs/introduction.html

As you can see, tribes is extremely customizable, only you imagination 
is the limit.


Filip


Peter Rossbach wrote:

Can you please explain how domain memberships at future works?

Peter

Am 06.05.2006 um 00:59 schrieb [EMAIL PROTECTED]:


Author: fhanik
Date: Fri May  5 15:59:35 2006
New Revision: 400201

URL: http://svn.apache.org/viewcvs?rev=400201&view=rev
Log:
Removed domains, since we are doing so many changes, there is no 
reason we can't implement that correctly


M


-
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 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33453





--- Additional Comments From [EMAIL PROTECTED]  2006-05-06 14:04 ---
(In reply to comment #51)
> I've fixed it, getting the fix incorporated into the codebase appears to be 
> the
> impossible part.  Feel free to use the code from my patch and give feedback if
> you find any problems.

Thanks, but it seems we will be migrating to JBoss 4.0.4 when the GA version
comes out and it shouldn't be an issue anymore. I'm fortunate enough I don't
have to use Tomcat standalone.

-- 
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 39503] New: - getContextPath() returns a decoded string contrary to the servlet spec

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39503

   Summary: getContextPath() returns a decoded string contrary to
the servlet spec
   Product: Tomcat 5
   Version: 5.5.17
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


This is similar to Bug 39278 but with respect to the request.getContextPath()
method.

The Servlet spec section for request methods, 15.1.3.2, says, "...The container
does not decode this string."

However, if you use a space in the context name and deploy to Tomcat, a call to
getContextPath() does not return an encoded string with '%20' for the space
character. Instead, the string includes the space character. A simple JSP can be
used to reproduce the issue.


Also, I noticed another similar issue with getRequestURI() on a forwarded
request. If you have a servlet or JSP that forwards to another servlet/JSP (via
request.getRequestDispatcher().forward()) in the web app that has a space in the
context path, the forward request behaves differently. The call to
getRequestURI() will return an encoded string from the original request but
returns a decoded URI in the forwarded request. The value in
request.getAttribute("javax.servlet.forward.request_uri") will still contain the
encoded '%20' but getRequestURI() returns a string containing a space. Would you
like me to open a different bug for this issue with respect to forwarding to
track separately?

-- 
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 39503] - getContextPath() returns a decoded string contrary to the servlet spec

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39503


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2006-05-07 00:08 ---
I am totally opposed to fixing this, which has to be an obvious specification 
issue.

The last part is invalid (getRequestUri will return what you gave to the
dispatcher).

-- 
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]