BayeuxRouter Injection Need for Bayeux4Netty

Bob McWhirter bmcwhirt at redhat.com
Mon Sep 21 08:38:53 EDT 2009


Trustin, I think that'd be a perfect solution.

Also, I'm not sure if I like the stack itself handling responses if  
you turn them around from your app's handler.  At this point, if you  
receive a Subscribe request, and just turn that exact object back as a  
response, the response chain will see it and create an appropriate  
Subscribe response.

To me, it'd seem sensible to put that behaviour into an  
AbstractBayeuxHandler which I could subclass.  That way, everything is  
still handled at the end of the chain, if my subclass chose to invoke  
the super-classes's handling of certain messages.  That could also  
simplify the actual bayeux protocol stack itself.

Taking it a step further, I think I'd enjoy creating, even if only in  
my own codebase, an abstract handler that's more like HTTP Servlets.   
Instead of a general handling method, branch out into a doSubscribe(),  
doUnsubscribe(), doConnect() etc type of methods.  Then the default  
handler could have a default implementation for doSubscribe() which  
could be overriden by subclasses if they wanted to do more.

	-Bob


On Sep 20, 2009, at 10:23 PM, Trustin Lee (이희승) wrote:

> I think the current BayeuxRouter implementation fits pretty well for
> most use cases.  What Bob says is that a user might want something
> more (or something diffferent) that the default behavior.  In such a
> case, the user might be able to implement such an additional feature
> by extending the current BayeuxRouter implementation or reimplementing
> the router.
>
> To support the two cases above (extension or re-implementaiton), I
> think BayeuxRouter should be an interface and the current
> implementation should be renamed to something like
> 'DefaultBayeuxRouter'.
>
> And then, we need to allow a user to specify a BayeuxRouter
> implementation in the constructor.  The constructor argument could be
> optional so that the default router implementation is used if no
> router is specified.
>
> — Trustin Lee, http://gleamynode.net/
>
> On Wed, Sep 2, 2009 at 5:05 PM, Dai Jun <guiwuu at gmail.com> wrote:
>> Hi all,
>>
>> I am sorry to intercept you by this. I copy Bob, Trustin and I's chat
>> of  BayeuxRouter injection here to have further discussion. And I am
>> looking forward to your suggesions. Thanks.
>>
>> On Wed, 2 Sep 2009 07:09:11 +0900 (KST) Bob McWhirter
>> <bmcwhirt at redhat.com> wrote:
>>>> I'd also like to not rely on the singleton
>>>> BayeuxRouter.getInstance(), but other code seems to assume that's  
>>>> how
>>>> we get it.  I'd like to be able to inject a router to be used by
>>>> BayeuxDecoder and BayeuxConnection.
>>>>
>>>> We could instead inject a BayeuxRouter instance into BayeuxDecoder,
>>>> which passes it along to BayeuxConnection.  All avoiding
>>>> getInstance()'s singleton, and allowing for multi-application
>>>> isolation.
>>>
>>
>> On Wed, Sep 2, 2009 at 8:02 AM, 이희승<trustin at gmail.com> wrote:
>>> +1
>>
>> +1, too. I was thinking about this problem recently. The current
>> singleton model is not enough in real server cases. With injection,  
>> we
>> can manage router in AS. But I am not familiar with injection. I have
>> to postpone it to next next update. If you or anybody else know about
>> it, we can speed it up. I'd love to discuss with it in another new
>> thread.
>>
>> Best regards,
>>
>> Dai Jun or Danny Dai(in English) - http://guiwuu.googlepages.com
>> GTalk: guiwuu at gmail.com | QQ: 93409048 | MSN: guiwuu at hotmail.com |
>> Twitter: @guiwuu
>> Sent from Beijing, 11, China
>> Charles de Gaulle  - "The better I get to know men, the more I find
>> myself loving dogs." -
>> http://www.brainyquote.com/quotes/authors/c/charles_de_gaulle.html
>>
>> _______________________________________________
>> netty-dev mailing list
>> netty-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-dev
>>
>
> _______________________________________________
> netty-dev mailing list
> netty-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-dev




More information about the netty-dev mailing list