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
