You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by re...@apache.org on 2001/10/01 03:09:54 UTC
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote ActionCode.java
remm 01/09/30 18:09:54
Modified: coyote/src/java/org/apache/coyote ActionCode.java
Log:
- Add a commit action code.
Revision Changes Path
1.2 +6 -3 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java
Index: ActionCode.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ActionCode.java 2001/07/10 02:54:59 1.1
+++ ActionCode.java 2001/10/01 01:09:54 1.2
@@ -70,16 +70,19 @@
// -------------------------------------------------------------- Constants
- public static final ActionCode ACTION_CUSTOM = new ActionCode();
+ public static final ActionCode ACTION_ACK = new ActionCode();
public static final ActionCode ACTION_CLOSE = new ActionCode();
- public static final ActionCode ACTION_RESET = new ActionCode();
+ public static final ActionCode ACTION_COMMIT = new ActionCode();
- public static final ActionCode ACTION_ACK = new ActionCode();
+ public static final ActionCode ACTION_CUSTOM = new ActionCode();
+
+
+ public static final ActionCode ACTION_RESET = new ActionCode();
// ----------------------------------------------------------- Constructors
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote
ActionCode.java
Posted by cm...@yahoo.com.
On Mon, 1 Oct 2001 cmanolache@yahoo.com wrote:
> 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 ?
Actually, forget about ints - my mistake. You can add a lot more to
ActionCode later, and then the fact it's an object will help :-)
BTW, I didn't say I don't like 'listeners', just that I prefer to use the
name Listener if it implements the 'typical' Even/Listener model, it's
confusing ( at least for me ) to have the name but not the pattern.
Costin
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote
ActionCode.java
Posted by cm...@yahoo.com.
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
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote ActionCode.java
Posted by Remy Maucherat <rm...@home.com>.
> 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
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote
ActionCode.java
Posted by cm...@yahoo.com.
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.
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 )
Costin
On 1 Oct 2001 remm@apache.org wrote:
> remm 01/09/30 18:09:54
>
> Modified: coyote/src/java/org/apache/coyote ActionCode.java
> Log:
> - Add a commit action code.
>
> Revision Changes Path
> 1.2 +6 -3 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java
>
> Index: ActionCode.java
> ===================================================================
> RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -u -r1.1 -r1.2
> --- ActionCode.java 2001/07/10 02:54:59 1.1
> +++ ActionCode.java 2001/10/01 01:09:54 1.2
> @@ -70,16 +70,19 @@
> // -------------------------------------------------------------- Constants
>
>
> - public static final ActionCode ACTION_CUSTOM = new ActionCode();
> + public static final ActionCode ACTION_ACK = new ActionCode();
>
>
> public static final ActionCode ACTION_CLOSE = new ActionCode();
>
>
> - public static final ActionCode ACTION_RESET = new ActionCode();
> + public static final ActionCode ACTION_COMMIT = new ActionCode();
>
>
> - public static final ActionCode ACTION_ACK = new ActionCode();
> + public static final ActionCode ACTION_CUSTOM = new ActionCode();
> +
> +
> + public static final ActionCode ACTION_RESET = new ActionCode();
>
>
> // ----------------------------------------------------------- Constructors
>
>
>
>