Re: [jgroups-dev] Improvements in org.jgroups.blocks.mux

I needed a return value that would express 3 possibilities:

1) subclass handled event and here is the non-null return value up() 
should return
2) subclass handled event and here is the null return value up() should 
return
3) subclass didn't handle event, up() needs to handle it.

I could have used a custom class for that, but that's added complexity; 
maybe it's the right way though. It was late. :) It's unfortunate the 
JDK does not include a simple immutable wrapper type; that's all that's 
needed.

On 06/09/2010 04:10 AM, Bela Ban wrote:
> OK. Why an AtomicReference; wouldn't a simple Object do ?
>
> Brian Stansberry wrote:
>> On 06/07/2010 04:03 PM, Brian Stansberry wrote:
>>> On 06/07/2010 02:49 AM, Bela Ban wrote:
>>
>>>> If that's the case, I'd say pass all state related calls to the default
>>>> handler and throw an exception if a non default handler does state.
>>>>
>>> HAPartition exposes a state transfer API to outside callers, and some
>>> internal HAPartition components use it (i.e. DRM). But yeah, I agree,
>>> with your general architectural point.
>>>
>>> The other thing is, the JGroups API exposes hooks (i.e. Muxer and
>>> UpHandler are both interfaces) such that I can plug in
>>> StateTransferFilter et al as AS-specific HAPartition behavior that
>>> doesn't need to be in JGroups.
>>>
>>
>> I think a simple solution is to add this method to MuxUpHandler:
>>
>> /**
>> * Extension point for subclasses called by up() when an event
>> * related to state transfer is received, allowing the subclass
>> * to override the default behavior of passing the event to the
>> * default up handler.
>> *
>> * @return true if the event was handled and no further processing
>> * should be done in up(), false if up() needs to handle
>> * the event. This default implementation always returns false
>> */
>> protected boolean handleStateTransferEvent(Event evt) {
>> return false;
>> }
>>
>> That largely removes the complexity and potential "oops - bad design"
>> issue from JGroups. HAPartition has always used a specialized
>> RpcDispatcher subclass, so having it override that method is no big
>> deal. The complexity is then an internal implementation detail of
>> HAPartition.
>>
>


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Javagroups-development mailing list