> Hi, > > In order to merge the connector-related code in Coyote and jk, I need > a different abstraction. Processor takes InputStream/OutputStream params, > and assumes the connector will listen on the port, etc. > > The problem is that it doesn't map to things like JNI and is hard to > abstract things like UnixSocket.
I know. > I would like to replace it with a similar interface, ProtocolHandler, > which is stateless ( Servlet-like ) and will just have a init()/destroy() > method, letting the protocol deal with the threads. > > It's easy to implement it in http11 - this is duplicated in the 33/40 > versions. I would prefer to use the 33 thread pool from util, but > I'm ok with the code used in 40 ( or I can implement both, with an > option ). The 4.0 pool works good, so I don't plan to fix it since it's not broken :) > Also, I would like to reduce/eliminate the use of Socket and the other > dependencies between Coyote and the protocol impl ( it is supposed > to abstract it, but there are few details.. ) > > Remy, Bill - is it ok ? The HTTP/1.1 processor is written for IS and OS, and in general blocking IO. You can't use any message based processing with it, that's for sure. Will it still work after abstracting this ? Anyway, the init/destroy and other things are probably needed. I'll have to look into the design a lot more .... Also, since the current code is stable and works good, I wanted to make a 1.0 release of Coyote and the HTTP/1.1 processor so I have something to fall back on if there are some problems with merging to JK. I'd like to: - Release a Coyote 1.0 RC with the current code - Create a 1.0 branch in j-t-c based on the current code Is it ok ? Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
