tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java
Date Sat, 11 Jan 2003 04:16:37 GMT
Jeanfrancois Arcand wrote:

> Hi Costin, (you beat me on the proposal :-) )

Actually - this is a different story ( JMX-enabling different componets).
I'll check in similar additions to ValveBase, BaseContainer, 
CoyoteConnector.

The idea is for each component to be aware of its name and domain, 
and to "bridge" whatever notification/hook mechanism into JMX
notifications.

I don't think we need an additional extension mechansim - for all
that I need I think JMX notifications are good enough. I don't
know how hard ( or usefull ) it is to bridge all existing extension
points, but at least the connector should be able to send JMX notifications
and it can easily use this model for its own needs.



> what about having a concept of a chain somewhere (meaning hooks chain
> (handler :-) ). This way handler doesn't need to know which comes next
> (or previous), but the handler chain knows it. What I was having in mind
> was being able to define somewhere:

I'm ok with that too. Valves have a Next - and I assumed many people 
preffer this model ( and it involves fewer interfaces :-).
My only requirement is to be able to use it in iterative mode too
( I don't like the long stack traces and I feel better with iterative).

For configuration: I would be -1 for any new API / tomcat-specific config
format.

All configuration should be done using JMX. I have no doubt about
it ( well, JMX has its limitations, but the general model of 
manageable components with light coupling is essential ).

Instead of param-name/value - use JMX attributes. The handler is a JMX 
component. For registration - I think we should use the standard JMX 
notifications ( or your proposed API if JMX proves too complicated or
we can't get around its limitations )

We could use a Chain MBean component where you declare ( as attributes )
the various hooks in the chain. ActionCode will correspond to a Chain.
That may be very nice - allowing hooks to be inserted at runtime, etc.



> <handler-configuration>
>     <module name="org.apache.coyote>
...
>     <handler-chain>
> <handler-configuration>


> Using that information, an HandlerChainDispatcher can generically load
> that information and then instanciate the proper HandlerChain/Handler.
> In the code, that will result in
> 
> public interface HandlerChain{
>     public void addHandler(Handler);
>     public void addHandler(int index, Handler);
>     public boolean contains(Handler);
>     public boolean  handle(HandlerChainContext);
> // remove handler(Handler)
> }

+0 - sounds good, but I would rather use NotificationBroadcaster :-)
( or some specialized version in modeler - to get around Filters ).



> public interface Handler{
>     public boolean handle(HandlerContext);
>     public void setHandlerInfo(HandlerInfo);   // Same as ActionCode
>     public HandlerInfo getHandlerInfo(HandlerInfo);
>    
>     public void init();
>     public void destroy()
>     public void recycle();
> }

Again - I would rather use 

interface javax.management.NotificationListener {
  handleNotification( Notification n, Object handBack );
}

And normal JMX for init/destroy/etc. 


> public interface HandlerContext(){
>     public Object putAttribute(String,Object);
>     public Object getAttribute(String);
>     public Map getAttributes();
>     public void removeAttribute(String);
>     public void clear();
> }

That's a tricky one - besides String-based attributes 
I think we need to use the "notes" ( i.e. index based ).
But I think the HandlerContext should just be an instance
of Notification ( with added notes and an int notification
code for faster dispatch ).

> Finally, that looks like a small proposal ;-)

My preference is to try to just use JMX.

It is not perfect - but I think it's good enough and we'll
benefit more by using a standard and well-known API.

Costin





--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message