如上一篇文章所见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的关键方法调用过程：
接触过动态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的关键方法调用过程：