----- Original Message -----
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 10, 2003 8:16 PM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java
> 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.
>
I currently have custom Valves in 4.1.x that *don't* extend ValveBase (I
feel strongly that my code shouldn't depend on anything other than
o.a.catalina), which work quite well with JMX. I'd really hate to lose
this for 5.x.
Of course, the current JDK1.4.x dependency of 5.x prevents me from even
thinking about using 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.
>
>
>
> > 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:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
