cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx package.html

[co...@apache.org]

costin      2002/06/05 15:19:50

  Added:       util/java/org/apache/tomcat/util/mx package.html
  Log:
  Documentation for the package. Note that it 'documents' what we should have there,
  not what we have ( most of what's described is not ready ), but the overall
  design is there ( most of it was discussed and is implemented on the C side )
  
  It is part of the ( new ? ) config layer for the jk components ( it's not
  very new - basically JMX as API and reimplement the ideas from the C side
  for config abstraction  - so old stuff )
  
  Revision  Changes    Path
  1.1                  jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/package.html
  
  Index: package.html
  ===================================================================
  <h2>Low level management wrappers</h2>
  
  This package provides a Dynamic MBean wrapper to Jk and other components ( tomcat
  Interceptors, Ant tasks, etc ) that follow Java Bean setter patterns. 
  
  <p>
  It will also provide an abstraction of the config mechanism used - allowing multiple
  config repositories to be used, and allowing persistence of the configuration. This 
  is not yet implemented - the idea is similar with what happens on jk_config.c, 
  i.e. have all configuration done via JMX layer, and have the JMX layer manage
  the config file ( eventually via an abstraction layer )
  
  <h3>JkConfig</h3>
  
  This will be the main class for dealing with configs. 
  It doesn't depend on JMX - all DynamicBeans will call JkConfig to actually 
  set/get parameters on the various components.
  
  It'll manage a tree ( with 2 levels ) represnetation of the config. Each
  component will have a node, and we'll store the attribute names and 
  ( original ) attribute values. Ant-style substitution will happen before 
  calling the actual setter. 
  
  Runtime changes will be reflected in the config file. Since we maintain
  the tree with whatever the user explicitely configures we don't have to
  call getters or guess what has to be stored and what doesn't.
  
  Internally it uses IntrospectionUtil to do all the conversions and magic.
  
  <h3>DynamicMBeanProxy</h3>
  
  This is what JMX sees. It'll make calls on JkConfig for handling the actual
  configuration.
  
  XXX Right now it does all the work, we must move it to JkConfig when ready.
  
  <h3>JkHandlerMX</h3>
  
  <h3>ProxyMX</h3>
  
  
  

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>