> On Fri, 5 Apr 2002, Remy Maucherat wrote: > > > > There is no problem if we use 2 Http11Protocol, one with ThreadPool the > > > other with 4.0 threads. Right now I'm working on the TP one. > > > > We don't need two, so I'll try yours ;-) > > Do you plan to write the Http11ProtocolHandler ? > > Already done, but I have a bug I'm trying to fix ( the classical body > sent before headers or mixed up, I've seen this at least 10 times :-). > > I'll check it in, it doesn't affect anything else ( it's not pretty yet, > I moved code from few places ).
Ok, please do. Since I'll probably use it, I'll try to improve it (assuming it needs improving). > Now the big question - can you take a look at util.handler.TcHandler ? > I'm don't want to replace ActionHook ( for now :-), but maybe have Action > extend TcHandler - or something similar, so the hook can use the ctx > ( and pass and return information ). I can also use TcHandlerContext ( > i.e. just a set of int-indexed notes ) as param for Action hook as the > first step. I have no problems getting rid of the current 'action' mechanism and replacing it with your handler. > Long term I think we should use TcHandler as the main hook and deprecate > ActionHook/JkHandler/etc. Of course, the name and interface is open > to change - we can rename it TcHook and make it interface, or use > action() and pass an object similar with ActionCode ( maybe ActionChain - > since each ActionCode represents a specific category of hooks chained ) Given what and where the ActionHook/Code is used, I really have no problem replacing it if the replacement object allows me to do the same things. >From TC, the action stuff is used through the Catalina API, so there's nothing impacted outside of Coyote. The protocol handler change should also have zero impact, as I just need to rewrite the CatalinaConnector wrapper to use it instead of using its own pooling. Very easy to do overall. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>