> Hi Remy, > > Can you explain a bit what's this ActionCode ? I understant it as a hook > mechanism, and I like that - but I'm not sure I like the implementation. > > For example, any reason not to use a plain 'int' as action code ? At least > that would allow switch() which is slightly faster ( when the number of > actions will grow ). > > Also, how do you plan to 'grow' - you can't just add static fields - what > about dynamic hook ? If you allow ActionCodes that are not defined as > static fields ( so you can use == ), you'll be forced to use .equals(), > that would be pretty bad.
Ok. The "action" thing is not a generic event mechanism. Remember, the name was listener, but you complained about that, and I changed it. The point is just to be able to expose a bit the underlying connection control. The event / hook / handler / valve / interceptor is on the application side, and is something else altogether. Do I need to change the name again ? The main need for that is to allow the servlet container to tell the connector that the request has been accepted and is ready to be processed (it's the HTTP/1.1 100 status code). I then added some additional code which mat also be useful. So since it's meant for connection control only, very little, if any, extensibility is needed (there's the "custom" type if you really need it, though). Note: I don't see why ints would be faster. The reference comparison should be a pointer comparison, which is checking if two ints are equal. It's all about modularity: here, I'm not trying to replicate all the functionality of, for example, the connector package of Catalina. Coyote and its connectors are supposed to be dumb : parse the request, enforce the protocol on the response, handle the underlying connection. Of course, that's already quite an important responsability. Then, the Adapter is doing the application specific logic (note: I probably still need to remove a few things from the Request and Response). To compare it with the Tomcat 3.3 core, I would say that the Adapter would be some code from Request and Response + the OutputBuffer (which I plan to reuse - although I'll modify it a bit). > There are few other things we need to discuss before implementing - but > that's one of the most obvious. > > ( I'm not saying that Hooks are better, just that we need to discuss a bit > the details of coyote ) No, Hooks / Valves / ... are something totally different. I don't plan to replace or remove them. Remy
