tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeanfrancois Arcand <jfarc...@apache.org>
Subject [JMX hooks/handler] was Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java
Date Mon, 13 Jan 2003 20:29:23 GMT
Sorry for the delay....

Costin Manolache wrote:

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

>
>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.
>
StandardPipeline and ValveBase can be ported to support JMX notification 
also. We can add support for JMX notification in ValveContext.next() 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

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

>
>For configuration: I would be -1 for any new API / tomcat-specific config
>format.
>  
>
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.

>
>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?

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

>
>
>
>  
>
>><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 ).
>  
>
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?

>
>
>
>  
>
>>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 );
>}
>  
>
I agree. The concept stay the same, but we should use JMX 
NotifcationListener for implementing the concept.

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

>
>  
>
>>Finally, that looks like a small proposal ;-)
>>    
>>
>
>My preference is to try to just use JMX.
>
I agree. I will try to speak in term of jmx next time :-)

-- Jeanfrancois

>
>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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message