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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
