tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Proposal - Comet changes
Date Fri, 08 Sep 2006 14:21:39 GMT
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> head is clearing about...
>> since:
>> public class MyServlet implements HttpServlet, o.a.c.CometProcessor { 
>> ....
>> wouldn't it make sense for:
>> public class MyFilter implements Filter, o.a.c.CometFilter {....
>> and you'd declare it the same way, since we are piggy backing on the 
>> servlet logic to create Comet servlets, wouldn't it be smart to piggy 
>> back on the filter logic to create Comet filters?
>> the interface CometFilter would define the new application chain, ie 
>> void "event(CometEvent,CometFilterChain)"
>> achieves the new filter chain, piggy backs on mapping logic.
> Great ! Yes, mapping is easy to add, so since you like it, those 
> "filters" can completely use the existing infrastructure. Are you ok 
> if I start with adding your CometEvent interface to the main source 
> tree ?
> On the other side of the container fence, I would need to make some 
> mods to the "valve" type (since if I don't have any possibility to 
> integrate with JEE, my boss will murder me). Most likely I would add a 
> new "event" method to Valve and ValveBase (as a special case, the 
> "begin" event would be handled by the regular invoke method), and the 
> (very few) valves that need to do business per event would be able to 
> do it. AFAIK, all current valves "invoke" methods support Comet 
> without problems (they don't do any funky tricks, and provide 
> functionality that is still going to be needed on the initial event: 
> HTTP auth, error pages and reports, etc). I think we should also 
> specify that the response will be considered committed after the 
> initial event. This also means the event method in the servlet adapter 
> will not directly call the servlet (which IMO is a good idea).
> I missed it, but I am ok with adding a "close" method on the event 
> class, since it is more explicit (indeed, it is to be implemented by 
> closing the output buffer).
yes please get started, I want to spend some time in the clustering code 
right now, so I'll chime in a bit later.

> Rémy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message