`
Tyrion
  • 浏览: 261032 次
  • 性别: Icon_minigender_1
  • 来自: 南京
社区版块
存档分类
最新评论

Tomcat7中的JMX使用(二)Dynamic MBean

阅读更多

 上一篇文章所见Standard MBean在Tomcat的例子并不多,在jconsole中所看到的大量MBean(如Catalina下的Connector、Engine、Server、Service等),实际上是动态MBean(Dynamic MBean)。本文主要讲述Tomcat7中如何通过动态MBean的方式构造MBean的。

 

接触过动态MBean的朋友一定知道,它的实例肯定要实现一个接口,即javax.management.DynamicMBean。实现这个接口就意味着同时要实现它下面的6个方法:

    public Object getAttribute(String attribute) throws AttributeNotFoundException,MBeanException, ReflectionException; 

    public void setAttribute(Attribute attribute) throws AttributeNotFoundException,InvalidAttributeValueException, MBeanException, ReflectionException ; 
    
    public AttributeList getAttributes(String[] attributes);
    
    public AttributeList setAttributes(AttributeList attributes);
    
    public Object invoke(String actionName, Object params[], String signature[]) throws MBeanException, ReflectionException ;    

    public MBeanInfo getMBeanInfo();

通过实现这个通用接口,jvm允许程序在运行时获取和设置MBean公开的属性和调用MBean上公开的方法。

 

上面简要介绍了动态MBean的实现方式,Tomcat中的实际情况比这个要复杂。因为要生成很多种MBean,如果每种类型都用代码写一个MBean就失去了动态MBean的威力,Tomcat7中实际是通过配置文件(即每个组件所在的包下面的mbeans-descriptors.xml)结合通用的动态MBean(org.apache.tomcat.util.modeler.BaseModelMBean)、描述MBean配置信息的org.apache.tomcat.util.modeler.ManagedBean来简化MBean的构造。(笔者注:实际就是用动态MBean实现了模型MBean的功能)

 

一般情况下动态MBean的产生分为两个阶段:一、加载org.apache.tomcat.util.modeler.ManagedBean对象,二、注册MBean实例。

 

1.加载org.apache.tomcat.util.modeler.ManagedBean对象

在Tomcat启动时加载的配置文件server.xml中有这么一行配置:

  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
因此在Tomcat启动时将加载这个类,在这个类中有一个静态成员变量registry:
    /**
     * The configuration information registry for our managed beans.
     */
    protected static Registry registry = MBeanUtils.createRegistry();
也就是说类加载时registry就会获得Registry类的实例,这个Registry类很重要,在MBean的构造过程中将会多次涉及这个类里的方法。先看看MBeanUtils.createRegistry()方法:
    /**
     * Create and configure (if necessary) and return the registry of
     * managed object descriptions.
     */
    public static synchronized Registry createRegistry() {

        if (registry == null) {
            registry = Registry.getRegistry(null, null);
            ClassLoader cl = MBeanUtils.class.getClassLoader();

            registry.loadDescriptors("org.apache.catalina.mbeans",  cl);
            registry.loadDescriptors("org.apache.catalina.authenticator", cl);
            registry.loadDescriptors("org.apache.catalina.core", cl);
            registry.loadDescriptors("org.apache.catalina", cl);
            registry.loadDescriptors("org.apache.catalina.deploy", cl);
            registry.loadDescriptors("org.apache.catalina.loader", cl);
            registry.loadDescriptors("org.apache.catalina.realm", cl);
            registry.loadDescriptors("org.apache.catalina.session", cl);
            registry.loadDescriptors("org.apache.catalina.startup", cl);
            registry.loadDescriptors("org.apache.catalina.users", cl);
            registry.loadDescriptors("org.apache.catalina.ha", cl);
            registry.loadDescriptors("org.apache.catalina.connector", cl);
            registry.loadDescriptors("org.apache.catalina.valves",  cl);
        }
        return (registry);

    }
注意第8行Registry.getRegistry(null, null)方法的调用,看下它的实现就会发现返回的实际是Registry类的静态变量,这种调用后面会多次看到。接着还需要看一下MBeanUtils类的registry的定义:
    /**
     * The configuration information registry for our managed beans.
     */
    private static Registry registry = createRegistry();
因为此时MBeanUtils类还没在JVM里面加载过,它的成员变量registry为null,所以会调用Registry.getRegistry(null, null)方法构造对象,接下来会多次调用loadDescriptors方法,以下面这一句代码为例:
registry.loadDescriptors("org.apache.catalina.connector", cl);
这里org.apache.catalina.connector实际上是一个package的路径全名,看下loadDescriptors方法:
    /** Lookup the component descriptor in the package and
     * in the parent packages.
     *
     * @param packageName
     */
    public void loadDescriptors( String packageName, ClassLoader classLoader  ) {
        String res=packageName.replace( '.', '/');

        if( log.isTraceEnabled() ) {
            log.trace("Finding descriptor " + res );
        }

        if( searchedPaths.get( packageName ) != null ) {
            return;
        }
        String descriptors=res + "/mbeans-descriptors.ser";

        URL dURL=classLoader.getResource( descriptors );

        if( dURL == null ) {
            descriptors=res + "/mbeans-descriptors.xml";
            dURL=classLoader.getResource( descriptors );
        }
        if( dURL == null ) {
            return;
        }

        log.debug( "Found " + dURL);
        searchedPaths.put( packageName,  dURL );
        try {
            if( descriptors.endsWith(".xml" ))
                loadDescriptors("MbeansDescriptorsDigesterSource", dURL, null);
            else
                loadDescriptors("MbeansDescriptorsSerSource", dURL, null);
            return;
        } catch(Exception ex ) {
            log.error("Error loading " + dURL);
        }

        return;
    }
第13到15行是先在Registry类的缓存searchedPaths中查找是否已经加载了该package所对应的配置文件,如果没有在第16到18行会在该包路径下面查找是否有mbeans-descriptors.ser文件,没有则在第20到23行查找同路径下的mbeans-descriptors.xml文件。找到之后在第29行放入缓存searchedPaths。我们既然以org.apache.catalina.connector为例,则找到的是该路径下的mbeans-descriptors.xml。所以会接着执行第32行loadDescriptors("MbeansDescriptorsDigesterSource", dURL, null):
    private void loadDescriptors(String sourceType, Object source,
            String param) throws Exception {
        load(sourceType, source, param);
    }
这段代码会执行load方法:
    public List<ObjectName> load( String sourceType, Object source,
            String param) throws Exception {
        if( log.isTraceEnabled()) {
            log.trace("load " + source );
        }
        String location=null;
        String type=null;
        Object inputsource=null;

        if( source instanceof URL ) {
            URL url=(URL)source;
            location=url.toString();
            type=param;
            inputsource=url.openStream();
            if( sourceType == null ) {
                sourceType = sourceTypeFromExt(location);
            }
        } else if( source instanceof File ) {
            location=((File)source).getAbsolutePath();
            inputsource=new FileInputStream((File)source);            
            type=param;
            if( sourceType == null ) {
                sourceType = sourceTypeFromExt(location);
            }
        } else if( source instanceof InputStream ) {
            type=param;
            inputsource=source;
        } else if( source instanceof Class<?> ) {
            location=((Class<?>)source).getName();
            type=param;
            inputsource=source;
            if( sourceType== null ) {
                sourceType="MbeansDescriptorsIntrospectionSource";
            }
        }
        
        if( sourceType==null ) {
            sourceType="MbeansDescriptorsDigesterSource";
        }
        ModelerSource ds=getModelerSource(sourceType);
        List<ObjectName> mbeans =
            ds.loadDescriptors(this, type, inputsource);

        return mbeans;
    }
第10到35行说穿是是为该方法适配多种数据源类型给inputsource变量赋上一个输入流。第40行会根据sourceType构造一个ModelerSource对象:
    private ModelerSource getModelerSource( String type )
            throws Exception
    {
        if( type==null ) type="MbeansDescriptorsDigesterSource";
        if( type.indexOf( ".") < 0 ) {
            type="org.apache.tomcat.util.modeler.modules." + type;
        }

        Class<?> c = Class.forName(type);
        ModelerSource ds=(ModelerSource)c.newInstance();
        return ds;
    }

上面看到sourceType传入的值是"MbeansDescriptorsDigesterSource"。所以getModelerSource方法最后返回的是org.apache.tomcat.util.modeler.modules.MbeansDescriptorsDigesterSource类的一个实例。

最后执行该ModelerSource对象的loadDescriptors(this, type, inputsource) 方法,因为该方法是一个抽象方法,所以这里实际执行的org.apache.tomcat.util.modeler.modules.MbeansDescriptorsDigesterSource类的loadDescriptors方法:

    @Override
    public List<ObjectName> loadDescriptors( Registry registry, String type,
            Object source) throws Exception {
        setRegistry(registry);
        setType(type);
        setSource(source);
        execute();
        return mbeans;
    }
前三个set方法毋庸多言,关键是最后的execute方法:
    public void execute() throws Exception {
        if (registry == null) {
            registry = Registry.getRegistry(null, null);
        }

        InputStream stream = (InputStream) source;

        if (digester == null) {
            digester = createDigester();
        }
        ArrayList<ManagedBean> loadedMbeans = new ArrayList<ManagedBean>();
        
        synchronized (digester) {
            
            // Process the input file to configure our registry
            try {
                // Push our registry object onto the stack
                digester.push(loadedMbeans);
                digester.parse(stream);
            } catch (Exception e) {
                log.error("Error digesting Registry data", e);
                throw e;
            } finally {
                digester.reset();
            }
        
        }
        Iterator<ManagedBean> iter = loadedMbeans.iterator();
        while (iter.hasNext()) {
            registry.addManagedBean(iter.next());
        }
    }
}
在第3行又看到了前面提到的Registry.getRegistry(null, null)方法,这里就是获取Registry的静态成员的引用。这段方法作用就是对source进行一次Digester解析,如果还不了解Digester解析,可以看看之前Tomcat源码分析的一篇文章:Tomcat7启动分析(三)Digester的使用。注意第18行digester的顶层对象是loadedMbeans,重点看下第9行createDigester()方法的调用:
    protected static Digester createDigester() {

        Digester digester = new Digester();
        digester.setNamespaceAware(false);
        digester.setValidating(false);
        URL url = Registry.getRegistry(null, null).getClass().getResource
            ("/org/apache/tomcat/util/modeler/mbeans-descriptors.dtd");
        digester.register
            ("-//Apache Software Foundation//DTD Model MBeans Configuration File",
                url.toString());
        
        // Configure the parsing rules
        digester.addObjectCreate
            ("mbeans-descriptors/mbean",
            "org.apache.tomcat.util.modeler.ManagedBean");
        digester.addSetProperties
            ("mbeans-descriptors/mbean");
        digester.addSetNext
            ("mbeans-descriptors/mbean",
                "add",
            "java.lang.Object");
        
        digester.addObjectCreate
            ("mbeans-descriptors/mbean/attribute",
            "org.apache.tomcat.util.modeler.AttributeInfo");
        digester.addSetProperties
            ("mbeans-descriptors/mbean/attribute");
        digester.addSetNext
            ("mbeans-descriptors/mbean/attribute",
                "addAttribute",
            "org.apache.tomcat.util.modeler.AttributeInfo");
				
	......
        
        return digester;
    }

上面这段代码其实很长,但绝大部分都是模板代码,理解几句的含义后面代码都很相似。这就是一个xml文件的解析,第13到15行是值在碰到xml文件的mbeans-descriptors节点的子节点mbean时构造一个org.apache.tomcat.util.modeler.ManagedBean对象,第16到17行是读取该节点属性值填充到ManagedBean对象的pojo属性中,第18到21行以ManagedBean对象为入参调用上一段代码分析提到的loadedMbeans对象的add方法。类似的,第23到31行是指在碰到mbeans-descriptors/mbean/attribute节点时构造org.apache.tomcat.util.modeler.AttributeInfo对象,填充pojo属性,并调用父节点构造的对象(即ManagedBean对象)的addAttribute方法。其它代码类似,不再赘述。

 

接回到上面MbeansDescriptorsDigesterSource类的execute方法第28到31行,在Digester解析完成之后迭代loadedMbeans对象,并调用registry.addManagedBean方法将这些ManagedBean添加到registry中。这样,一次registry.loadDescriptors("org.apache.catalina.connector", cl)调用就会加载该包路径下相对应的ManagedBean对象到Registry类的成员变量中。

 

下面的时序图列出从GlobalResourcesLifecycleListener类加载其静态成员变量registry到Registry类加载完相应包所对应的ManagedBean的关键方法调用过程:



2.注册MBean实例

2.1.查找ManagedBean

上面说的是一个ManagedBean的加载过程,但它不是一个MBean,可以把它看作一个描述MBean的配置信息的对象,以前面提到的org.apache.catalina.connector为例,在Tomcat7的默认配置启动后实际上有两个Connector实例,因为在server.xml中配置了两条connector节点:

    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
...

    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

所对应jconsole中会看到两个相应的MBean对象:


但ManageBean实际只是加载了一次。了解了ManagedBean与MBean的对应关系,接下来看看一个MBean是怎么注册到JVM中的。

 

看过前面Tomcat启动分析的朋友知道容器各组件在启动过程中会相继调用它们的initInternal()、startInternal()两个方法,还是以上面提到的Connector组件为例,Tomcat启动时解析server.xml文件过程中碰到Connector节点配置会构造org.apache.catalina.connector.Connector对象并调用它的initInternal方法:

    @Override
    protected void initInternal() throws LifecycleException {

        super.initInternal();

...
在这个方法的开始会调用它的父类org.apache.catalina.util.LifecycleMBeanBase的initInternal方法:
    private ObjectName oname = null;
    protected MBeanServer mserver = null;
    
    /**
     * Sub-classes wishing to perform additional initialization should override
     * this method, ensuring that super.initInternal() is the first call in the
     * overriding method.
     */
    @Override
    protected void initInternal() throws LifecycleException {
        
        // If oname is not null then registration has already happened via
        // preRegister().
        if (oname == null) {
            mserver = Registry.getRegistry(null, null).getMBeanServer();
            
            oname = register(this, getObjectNameKeyProperties());
        }
    }
先获取MBeanServer的实例,接着调用内部的register方法,将当前对象注册到MBeanServer中,看下register方法:
    protected final ObjectName register(Object obj,
            String objectNameKeyProperties) {
        
        // Construct an object name with the right domain
        StringBuilder name = new StringBuilder(getDomain());
        name.append(':');
        name.append(objectNameKeyProperties);

        ObjectName on = null;

        try {
            on = new ObjectName(name.toString());
            
            Registry.getRegistry(null, null).registerComponent(obj, on, null);
        } catch (MalformedObjectNameException e) {
            log.warn(sm.getString("lifecycleMBeanBase.registerFail", obj, name),
                    e);
        } catch (Exception e) {
            log.warn(sm.getString("lifecycleMBeanBase.registerFail", obj, name),
                    e);
        }

        return on;
    }
重点是第14行调用Registry类的registerComponent方法来注册:
    public void registerComponent(Object bean, ObjectName oname, String type)
           throws Exception
    {
        if( log.isDebugEnabled() ) {
            log.debug( "Managed= "+ oname);
        }

        if( bean ==null ) {
            log.error("Null component " + oname );
            return;
        }

        try {
            if( type==null ) {
                type=bean.getClass().getName();
            }

            ManagedBean managed = findManagedBean(bean.getClass(), type);

            // The real mbean is created and registered
            DynamicMBean mbean = managed.createMBean(bean);

            if(  getMBeanServer().isRegistered( oname )) {
                if( log.isDebugEnabled()) {
                    log.debug("Unregistering existing component " + oname );
                }
                getMBeanServer().unregisterMBean( oname );
            }

            getMBeanServer().registerMBean( mbean, oname);
        } catch( Exception ex) {
            log.error("Error registering " + oname, ex );
            throw ex;
        }
    }
在第18行根据当前要注册的对象(即Connector对象)的类型查找ManagedBean,沿着这个方法追会发现依次调用了一堆同名的findManagedBean方法,一直到findManagedBean(String name):
    public ManagedBean findManagedBean(String name) {
        // XXX Group ?? Use Group + Type
        ManagedBean mb = descriptors.get(name);
        if( mb==null )
            mb = descriptorsByClass.get(name);
        return mb;
    }
这段代码意思是依次从Registry类的静态成员变量descriptors、descriptorsByClass中查找相应ManagedBean。那这两个HashMap是什么时候put值进去的呢?答案就在上一部分分析的最后加载ManagedBean时最终调用Registry类的addManagedBean方法:
    public void addManagedBean(ManagedBean bean) {
        // XXX Use group + name
        descriptors.put(bean.getName(), bean);
        if( bean.getType() != null ) {
            descriptorsByClass.put( bean.getType(), bean );
        }
    }

2.2.创建DynamicMBean

在上面的registerComponent方法的第21行调用查找到的ManagedBean对象的createMBean方法来获取实际的DynamicMBean对象:

    public DynamicMBean createMBean(Object instance)
        throws InstanceNotFoundException,
        MBeanException, RuntimeOperationsException {

        BaseModelMBean mbean = null;

        // Load the ModelMBean implementation class
        if(getClassName().equals(BASE_MBEAN)) {
            // Skip introspection
            mbean = new BaseModelMBean();
        } else {
            Class<?> clazz = null;
            Exception ex = null;
            try {
                clazz = Class.forName(getClassName());
            } catch (Exception e) {
            }
          
            if( clazz==null ) {  
                try {
                    ClassLoader cl= Thread.currentThread().getContextClassLoader();
                    if ( cl != null)
                        clazz= cl.loadClass(getClassName());
                } catch (Exception e) {
                    ex=e;
                }
            }
    
            if( clazz==null) { 
                throw new MBeanException
                    (ex, "Cannot load ModelMBean class " + getClassName());
            }
            try {
                // Stupid - this will set the default minfo first....
                mbean = (BaseModelMBean) clazz.newInstance();
            } catch (RuntimeOperationsException e) {
                throw e;
            } catch (Exception e) {
                throw new MBeanException
                    (e, "Cannot instantiate ModelMBean of class " +
                     getClassName());
            }
        }
        
        mbean.setManagedBean(this);
        
        // Set the managed resource (if any)
        try {
            if (instance != null)
                mbean.setManagedResource(instance, "ObjectReference");
        } catch (InstanceNotFoundException e) {
            throw e;
        }
        return (mbean);

    }
这段代码看起来长,仔细分析实际就是根据ManagedBean对象的getClassName方法返回的值通过反射等方式来构造一个对象返回。而getClassName方法调用的实际就是第1部分提到的Digester解析时构造ManagedBean对象时自动从xml文件中读取并填充的pojo属性className,以现在所说的Connector为例,在mbeans-descriptors.xml中的配置:
  <mbean         name="CoyoteConnector"
            className="org.apache.catalina.mbeans.ConnectorMBean"
          description="Implementation of a Coyote connector"
               domain="Catalina"
                group="Connector"
                 type="org.apache.catalina.connector.Connector">
所以此时构造返回的是一个org.apache.catalina.mbeans.ConnectorMBean对象。可以看到这个类的继承关系,它的父类是org.apache.catalina.mbeans.ClassNameMBean,它父类的父类就是org.apache.tomcat.util.modeler.BaseModelMBean,从这三种类中可以分别看到通常的动态MBean要实现的6个方法的定义,有兴趣的可以继续研究这些方法的实现,实际上它们都用到了什么所说的ManagedBean对象的相关方法,因为与该MBean要暴露的方法、操作的描述信息都是在加载相应的ManagedBean对象时读取的,所以动态MBean的实现必然也是需要调用它们的。

 

2.3.注册DynamicMBean

在上面的registerComponent方法的第30行getMBeanServer().registerMBean( mbean, oname),这就是将该DynamicMBean对象注册到MBeanServer中。

 

下面的时序图列出从Connector的initInternal方法到注册MBean的关键方法调用过程:

 

0
0
分享到:
评论

相关推荐

    JMX、MXBean学习

    7. **使用场景**:JMX常用于性能监控、日志管理、配置管理以及健康检查等任务。例如,你可以通过JMX监控Tomcat服务器的线程池状态,或者调整数据库连接池的参数。 8. **自定义MBean**:根据需求,开发者可以创建...

    《jmx技术介绍》配套源代码

    这些例子可以帮助读者快速上手,理解如何创建、注册MBeans,如何通过MBean Server进行操作,以及如何设置和使用JMX连接器。通过实践,学习者可以更深入地掌握JMX的精髓。 总结来说,JMX是Java平台的重要管理工具,...

    jmx简单实例,附带jar包完整项目

    在这个“jmx简单实例”中,我们将会探讨JMX的基本概念,以及如何使用所提供的jar包来构建和运行一个简单的JMX示例。 1. **JMX基础** JMX由三部分组成:MBeans(Managed Beans)、Servers和Agents。MBeans代表管理...

    JAVA JMX 学习资料

    在应用服务器如Tomcat、JBoss中,JMX也被用来管理服务器配置和组件。 8. **Spring对JMX的支持**: Spring框架提供对JMX的全面支持,可以方便地注册MBeans,以及集成Spring的管理功能。 9. **安全性**: JMX支持...

    JMX in Action

    JMX允许开发者创建可管理和监控的MBeans(Managed Beans),这些MBeans代表了系统中的各种资源或服务,如内存使用、线程状态、网络连接等。通过MBeans,开发者可以暴露系统状态,并提供操作接口来调整配置或执行管理...

    JMXTools.jar和jmxri.jar下载

    在Java应用程序中,当你需要在运行时使用JMX服务,比如注册MBeans(Managed Beans),监听MBean属性变化或执行管理操作时,就需要包含`jmxri.jar`。 `jmxtools-1.2.1.jar`则是JMX工具集,提供了许多实用工具和API,...

    java of core jmx

    7. **JMX与Spring的集成**:Spring框架提供了与JMX的集成,可以方便地将Spring Bean注册为MBeans,简化了JMX的使用。 8. **安全性**:JMX支持安全管理,可以通过设置权限来控制哪些客户端可以访问特定的MBeans,...

    JMX入门教程 程序管理功能的框架

    **二、JMX的使用** 在JMX中,一个简单的“Hello World”示例通常包括以下步骤: 1. **创建MBean**: 定义一个实现了特定接口的类,该接口定义了管理属性和操作。例如,`Hello`类实现了`HelloMBean`接口,包含了`...

    jmx资料

    例如,许多Java应用服务器,如Tomcat、Jetty等,都内置了JMX支持,可以通过JMX接口获取服务器的运行状态,如线程池信息、内存使用情况等。开发者可以编写自定义的MBeans来监控特定的服务或者业务指标。 在提供的...

    JMX学习资料

    例如,Tomcat、Jetty等Web服务器,以及Hadoop、Apache Kafka等大数据组件都使用JMX来提供管理功能。 9. **JMX工具**:Java自带了一些JMX工具,如jconsole和jvisualvm,它们可以帮助开发者直观地查看和管理MBeans。...

Global site tag (gtag.js) - Google Analytics