Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyoteActionCode.java
On Mon, 1 Oct 2001 [EMAIL PROTECTED] 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/coyoteActionCode.java
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/coyoteActionCode.java
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 [EMAIL PROTECTED] wrote: > remm01/09/30 18:09:54 > > Modified:coyote/src/java/org/apache/coyote ActionCode.java > Log: > - Add a commit action code. > > Revision ChangesPath > 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 > > > >