tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [JMX hooks/handler] was Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote
Date Mon, 13 Jan 2003 21:45:29 GMT
Jeanfrancois Arcand wrote:

>>Actually - this is a different story ( JMX-enabling different componets).
>>I'll check in similar additions to ValveBase, BaseContainer,
> Humm..I would like to be able to support hooks/Valves also using one
> approach. I'm not an expert with JMX, but it seems we can do it.

Regardless of the hook type - all components should know their name and
domain and should know when they are registered - so MBeanRegistration must
be implemented in all root components.

> StandardPipeline and ValveBase can be ported to support JMX notification
> also. We can add support for JMX notification in or
> port that method inside StandardPipeline and then use JMX notification
> without making major design change (the Digester will register the Valve
> mostly the same way, but this time using the jmx NotificationListener
> interface ). That should "JMX"-enabled StandardPipeline and valve that
> extends ValveBase

The main problem - the notification in JMX works in the same way as 
Event/Listener - i.e. iterate over listeners and call each one. 
Valves are recursive, each valve calls the next. I don't want to reopen
the discussion on what's better - we ( tomcat-dev) know both are valid and 
we agreed to disagree on this :-) That's why I added the recursive 
mechansim in BaseHook.

We could register Vavles using addNotification - and even modify modeler
to support both models ( right now it supports none - notification doesn't
seem to be completely implemented ). Not sure it's a big priority - but
if you have the time it would be great to at least see how it looks.

>>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).
> It is ValveContext that have a next :-), which is similar to an
> HandlerChain (Pipeline is starting the process, ValveContext is doing
> the rest).

I have a bad habbit to try to simplify some things :-) ( bad because 
sometimes things need to be complex - and it takes a lot of time ).
Doesn't matter how many classes are involved in this procept - the
concept is that you have a list and each element calls the next.

>>For configuration: I would be -1 for any new API / tomcat-specific config
> Then my question is: how do we specify, as an example, that the JSR 115
> authorization valve should be invoked before, let say, JNDI
> authorization valve? We are currently doing that implicitly in
> server.xml, but all valves are associated with the same pipeline
> implementation (or I'm missing something here). I would like to be able
> to configure more that one chain (one for connector, one for valve,
> etc.). As an example, an <Engine> may have a different chain behaviour
> than a <host> element when an exception occurs.

There are 2 ( or 3 ) solutions:

- explicit Chain MBean. You configure each module as a MBean, and you have 
one Chain MBean, where you specify the names of each mbean. A variation - in 
modeler we could add some modeler-specific mbean to control the 
notification chain of each modeled mbean. 
  <mbean name="catalina:Type=Chain,id=AuthHook" >
     <attribute name="module" value="catalina:Type=Module,id=JSR115Auth" />
     <attribute name="module" value="........." />

- next ( or "after" ) attribute in the valve. Something like that is done in 
jk2. You configure the JSR115 mbean, the JNDIAuth mbean - and you specify
the name of the first in the "after" attribute of the second. The base class
can easily take care of this - it'll just jmx.invoke "setNext".
  <mbean name="" />
    <attribute name="after" value="catalina:Type=Module,id=.... />
    <attribute name="chain" value="catalina:Type=Chain,id=AuthHook" /> (???)

Of course, things get interesting if you want to insert ( or remove ) 
mbeans at runtime ( without completely stoping the server if possible ).
Both mechanisms support that ( with either sync or with a "server pause"). 

>>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 ).
> I agree.

>>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 )
> That's true. But where do we get the initial value of those objects?

Configurable objects == mbeans.
You configure and name them, then use the reference ( name ) in the 
chain mbean configuration.

>>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.
> This is where I would like to go. Being able to set hooks at runtime
> using some descriptors. Or have an extension folder where JMX enabled
> hooks will be discovered and added, by default, to the end of the chain.

I like discovery - but for the server I preffer some explicit configuration.
Either Chain MBean or a "next"/"after" attributes are fine.

( a third option - each module can register itself explicitely during 
pre/post notifications or in start. ).

>>+0 - sounds good, but I would rather use NotificationBroadcaster :-)
>>( or some specialized version in modeler - to get around Filters ).
> True. Filtering will certaintly be a performance hit... the question is
> do we want to be able to fully support jmx notification mechanism or
> part of it (by skipping the filter invokation). In modeler, you seems to
> have a solution for the filtering invocation. Have you make some test to
> see if it is faster?

I haven't finished the implementation - but it should be as fast as the
"non-jmx" version ( either Interceptor or Valve ). 

The main idea is simple: if you specify a o.a.c.modeler.FixedFilter as 
filter, the notification broadcaster used by modeler can see that he knows
about the filter. FixedFilter contract will say: even if I'm a filter that
needs to be invoked before each notification, I can tell you now that
I'll allways filter a particular type/attribute.

And the broadcaster can use this info to construct individual chains for
each notification emitted - with the same overhead as 3.3 Interceptor
( in 3.3 we introspect each module to find what methods/hooks are 
implemented, that's the "filter" ).

Everything else should be equal. 

BTW, the "handback" object is pretty nice, ThreadPool could work very
well with notifications/listeners :-).

>>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 ).
> What about using the setUserData/getUserData for doing that?

I think "userData" should hold the Request or something like that.

Notification is a base class, just like Event. It is perfectly fine
to extend it with specialized methods - like 
  int getCode() 
  or getNote(). 

>>My preference is to try to just use JMX.
> I agree. I will try to speak in term of jmx next time :-)

I'm not saying that JMX is the best solution or that I would -1 
if you propose something that is not JMX.

I want to have a JMX-friendly solution because it makes the whole
thing much cleaner and easier to work with. If JMX is not good 
enough for something - we use a custom solution.


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

View raw message