cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

[costin]

costin  2003/01/14 10:46:25

  Removed: coyote/src/java/org/apache/coyote BaseHook.java
  Log:
  Rollback...
  
  A much better solution is to just use plain NotificationListener, without
  any tomcat/coyote/jk-specific modifications.
  
  All JK and coyote hooks ( "extension points" ) work fine with the Notification
  model - there is no need for the recursive call. In the processing phase
  we can just use the Valves ( eventually plugged in using a ValveNotificationListener 
).

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

Re: [JMX hooks/handler] was Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

[Costin Manolache]

Jeanfrancois Arcand wrote:

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

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

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
>>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  may have a different chain behaviour
> than a  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. 
  
 
 
  

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


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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

[costin]

costin  2003/01/10 23:08:33

  Modified:coyote/src/java/org/apache/coyote BaseHook.java
  Log:
  Added NotificationListener.
  
  JMX notifications are not as flexible - I really don't know
  what is the best solution here. Less flexibility might be very
  good - it can keep things simpler.
  
  I'll add a BaseNotification to modeler - with an int code,
  notes, etc. And then I'll try to find a way to use standard
  notifications side-by-side with the native mechanism ( ActionCode ).
  
  Opinions ?? I'm not very sure...
  
  Revision  ChangesPath
  1.2   +26 -4 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/BaseHook.java
  
  Index: BaseHook.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/BaseHook.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- BaseHook.java 10 Jan 2003 22:36:43 -  1.1
  +++ BaseHook.java 11 Jan 2003 07:08:33 -  1.2
  @@ -61,6 +61,8 @@
   import javax.management.MBeanRegistration;
   import javax.management.ObjectName;
   import javax.management.MBeanServer;
  +import javax.management.NotificationListener;
  +import javax.management.Notification;
   
   
   /**
  @@ -69,21 +71,33 @@
* @author Remy Maucherat
* @author Costin Manolache
*/
  -public class BaseHook implements ActionHook, MBeanRegistration {
  +public class BaseHook
  +implements ActionHook, MBeanRegistration, NotificationListener
  + {
   protected BaseHook next;
   
   /**
  + * XXX DO WE REALLY NEED THIS ? handleNotification should be enough !!
  + *
* Send an action to the connector.
* Both recursive and iterative invocation is possible - the
* hook may call itself the next hook ( like catalina ) or the
* controller may call the next.
  - * 
  + *
  + * The call pattern for this is:
  + *   while( hook!=null ) {
  + *  hook=action( code, param );
  + *   }
  + * If the hooks has special needs - it can call next itself and decide
  + * to return null or whatever the next hook returned.
  + *
  + * The reason for iterative calls - smaller stacks ( and stack traces ).
  + *
* @param param Action parameter
* @return  A hook that can be executed next.
*/
   public BaseHook action(int code, Object param) {
  -if( next==null ) return next;
  -return next.action( code, param );
  +return next;
   };
   
   /** Backward compat
  @@ -134,5 +148,13 @@
   public void postDeregister() {
   }
   
  +//  Notification listener  
  +
  +public void handleNotification(Notification notification, Object handback) {
  +// we need a special CoyoteNotification that will include the code
  +// and param.
  +
  +// It would be better to use a generic class in modeler.
  +}
   
   }
  
  
  

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

Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

[Costin Manolache]

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

I think it's ok. You can either implement MBeanRegistration - or just
do nothing. The main purpose of this addition is to have a consistent
getObjectName and getDomain, as well as access to the mbean server. 

I would also like to use the attributes from the name - and attach
the valve to the right component in preRegister(). Not sure if it's
worth it - but it could be usefull.

The problem with interfaces is that if you add a method, all
implementations will need to be changed. 

> Of course, the current JDK1.4.x dependency of 5.x prevents me from even
> thinking about using it  ;-).

Do we still have a 1.4 dependency ? We should fix that.

I just run it with JDK1.3 - and seemed fine.

Costin


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

Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

[Bill Barker]

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

Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

[Costin Manolache]

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.

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.



> 
>  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:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

[costin]

costin  2003/01/10 14:36:43

  Added:   coyote/src/java/org/apache/coyote BaseHook.java
  Log:
  Added a base implementation of ActionHook - with some small additions :-)
  
  First, there is a getNext/setNext to allow multiple hooks to be chained.
  Both recursive and iterative will be supported - you can call next directly or
  just return it ( still need to tune this - only recursive works now )
  
  In addition, the hook implements MBeanRegistration ( again: we did vote on
  JMX dependency ). Tomcat3.3 may be a problem ( since it's using the same code),
  but if someone wants to use the new connector he can also add jmx in the
  path. If anyone has a problem with that - please let me know, I can hack
  some conditional compilation, but I would like to keep it simple.
  
  I'll change the 2 hook implementations to extend this after it settles down.
  
  Feel free to make changes - or ask for changes or just say -1.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/BaseHook.java
  
  Index: BaseHook.java
  ===
  /*
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights 
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer. 
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:  
   *   "This product includes software developed by the 
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written 
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   * [Additional notices, if required by prior licensing conditions]
   *
   */ 
  package org.apache.coyote;
  
  import javax.management.MBeanRegistration;
  import javax.management.ObjectName;
  import javax.management.MBeanServer;
  
  
  /**
   * Action hook.
   *
   * @author Remy Maucherat
   * @author Costin Manolache
   */
  public class BaseHook implements ActionHook, MBeanRegistration {
  protected BaseHook next;
  
  /**
   * Send an action to the connector.
   * Both recursive and iterative invocation is possible - the
   * hook may call itself the next hook ( like catalina ) or the
   * controller may call the next.
   * 
   * @param param Action parameter
   * @return  A hook that can be executed next.
   */
  public BaseHook action(int code, Object param) {
  if( next==null ) return next;
  return next.action( code, param );
  };
  
  /** Backward compat
   *
   * @param actionCode
   * @param param
   */
  public void action( ActionCode actionCode, Obje