tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote
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, 

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

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

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 {
  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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message