Jeanfrancois Arcand wrote: >>>>+1 if all new code goes in a separate module ( instead of catalina ), >>>>and is built as separate .jar(s). >>>> >>>> >>>I wanted to, however I can't do that without changing the API some stuff >>>in the session package (the damn classes are all package private) :-P >>> >>>I suppose it's a lot better to stop the hacks *now*, fix that, and put >>>everything in the cluster package. >>> >>> >> >>Well, if you must - you must. >>But we shouldn't have the core depend on the clustering, just add the >>minimal stuff that you need in the session. >> >>If we can stop the hacks and clean something - I think 5.0 is the best >>chance. >> >>I would preffer to have a consistent hook mechanism for everything - >>I'm not sure what callbacks will be involved in the clustering. >> > Are you thinking about having coyote Action(s)? If yes, we might one to > extend the current API having in mind that we will need to supports > Clustering, Authentification, Authorization, etc.
I don't care too much if it is called Coyote Action, Jk2 Handler, 3.3 Interceptor(with a single method), or 4.0 Valve ( in multiple chains ) or Axis Handler/Chain. Or even Event/Listener. Some time ago I started a package to implement yet-another hook, as a replacement for Action in coyote. I remove it because there is absolutely no point for yet another API - any of those APIs can do the job. All I want is a single and simple and consistent hook mechanism that is used for callbacks in all "extension points" ( simple is quite important :-) Since Coyote is now used in all tomcat versions and also jk - I think it is a good idea to use with coyote Action. But I'm +1 on anything else - as long as we converge on a single mechanism ( it is simple to wrap any hook - Vavle, interceptor, action. into any interface ) Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
