On Sun, 30 Sep 2001, Remy Maucherat wrote: > > 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. > > 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 problem is not the name, but the fact I don't understand it too well :-) > 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). I see. So we want the container to notify the adapter about certain events and/or actions, for connection control. I'm not sure about 'extensibility' here - this is supposed to work with all kinds of adapters, and we'll need all kind of actions here. Unless I'm missing something, there is one communication between the adapter and the servlet container, and one in reverse. Is the Action this container->adapter interface ? If so, we do need a lot of extensibility and much more power. If not - then maybe we can use whatever mechanism we'll use for container->adapter for Action as well. > 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. Yes, but with int you can also do switch, and it would be simpler - why use an object when all you need is a simple enumeration ? > 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). So we'll have 3 layers - coyote, adapter, container. It's not bad - we just need to spend some more time disucussing it and see how it'll fit with ajp/jni/http11/warp/etc. Costin
