Filip Hanik - Dev Lists wrote:
head is clearing up...how 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).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
