由于JMX的天生麗質(zhì)，適合作為一個大型應(yīng)用程序的框架/平臺，JBoss便成為其實驗品中之一。利用JMX作為應(yīng)用程序
框架的好處至少在于：1）所有（核心的和非核心的）component和service都可以hot instrumentation到JMX
Server上，作為相對獨立的MBean，JMX
Server本身作為一個獨立于各組件與服務(wù)的“總線”，并有MBean之間的Notification的機制——服務(wù)器平臺是Scalable的。2）
由于JMX所聲稱的優(yōu)點，它的Distribute
Tier可以支持RMI、HTTP等等多種客戶端（以后還包括WS乃至更多），客戶端也是Scalable的。3）各組件與服務(wù)作為MBean，其狀態(tài)與
行為都可以通過MBean的操作在運行時控制，這樣的Server無疑具有很好的Usablity。
類裝載器
Java中的Class實例，不僅是全限定名（包名+類名）的函數(shù)，也是類裝載器的函數(shù)，即：
:Class = f(name, Li, Ld)
其中，name表示類名，Li為初始裝載器，Ld表示定義裝載器。
初
始裝載器為在其上發(fā)生loadClass調(diào)用返回Class實例的那個裝載器；定義裝載器則是實際為Class實例執(zhí)行defineClass，從
bytecode中讀入類定義的那個裝載器。因為loadClass方法可以被子類重載，其中對defineClass的調(diào)用有可能被delegate給
其它裝載器做，所以Li和Ld不一定相同。
于是，
- 兩個不同類裝載器裝載的類，即使類全限定名相同，都不能相互cast，否則拋出ClassCastException。
- 如果裝載器L1裝載的類p.A有包可見的方法f，則裝載器L2裝載的類p.B不能訪問f，否則拋出IllegalAccessException。
- 如果有Class1和Class2的name，Li相同，而Ld不同，它們實例之間的引用賦值時會觸發(fā)裝載限制檢查，拋出LinkageError。
為了熱deploy模塊的需要，JBoss實現(xiàn)了自己的類裝載器UnifiedClassLoader3，一般來說，一個頂層的deployment就有一個UnifiedClassLoader3實例為之工作。JBoss所裝載的類呈平面模型——也就是說，一個deployment所裝載的類，其他 deployment是可見的。全局唯一的UnifiedLoaderRepository3實例用于管理這些類，以及裝載它們的UnifiedClassLoader3。UnifiedLoaderRepository3實例和UnifiedClassLoader3實例是一對多的關(guān)系。
一個deployment要裝載一個類，
1）先查看全局的UnifiedLoaderRepository3實例里的cache是否已存在，存在則返回。
2）否則，用deployment自己的UnifiedClassLoader3裝載，成功則更新UnifiedLoaderRepository3的cache，并返回。
3）否則用UnifiedLoaderRepository3里的其他UnifiedClassLoader3裝載，成功則更新UnifiedLoaderRepository3的cache，并返回。
4）否則拋出ClassNotFoundException。
要查看默認的全局唯一的UnifiedLoaderRepository3里裝載Class的情況，見名為JMImplementation:name=Default,service=LoaderRepository的MBean。它有displayClassInfo(String)的方法，用于查看有關(guān)Class的ClassLoader；還有getPackageClassLoaders(String)方法，用于得到“哪些ClassLoader有裝載某個package的能力”。
JBoss的平面類裝載機制決定了，一般情況下，相同類名的類在整個JBoss運行環(huán)境中，只裝載一次。如果要不同的EAR包中，有不同版本的a.b.C類，需要為EAR指定自己的HeirarchicalLoaderRepository3，先和這個Repository一起工作找到自己版本的C類而不是到全局的UnifiedLoaderRepository3里去找全局的版本。這個機制叫做Scoping Classes——即EAR有自己獨立的類裝載空間。要配置Scoping Class，需要在META-INF/jboss-app.xml描述符里注明：
<jboss-app>
<loader-repository>some.dot.com:loader=webtest.ear</loader-repository>
</jboss-app>
其中，MBean名稱（粗體部分）可以是符合MBean名稱規(guī)范的隨意名稱。
說明：
1）Server
Loader是一個NoAnnotationURLClassLoader的實例（見ServerLoad.load方法），它控制的URL有$
JBOSS_HOME/lib下的jboss-jmx.jar、concurrent.jar、log4j-boot.jar、jboss-
common.jar、jboss-system.jar、jboss-xml-binding.jar、namespace.jar以及其他用命令行參
數(shù)指定的jar包。它負責(zé)load的類包括org.jboss.system.server.ServerImpl、
org.jboss.mx.server.MBeanServerImpl、UnifiedLoaderRepository3等等。
2）全局唯
一的UnifiedLoaderRepository3實例是實現(xiàn)JBoss平面類裝載模型的關(guān)鍵。這個實例是標(biāo)準的
javax.management.MBeanServer的成員，可以用標(biāo)準的方法:
MBeanServer.getClassLoaderRepository()得到。
3）ServerTCL是一個
UnifiedClassLoader3的實例，它控制的URL是server/<config>/conf（用于有關(guān)resources的
裝載）。它負責(zé)ServerInfo、ServiceController、MainDeployer、JARDeployer、SARDeployer
等MBean的類裝載和實例化，在這幾個MBean的創(chuàng)建和start的上下文中，它作為當(dāng)前線程ContextClassLoader。
實現(xiàn)自定義service
JBoss平臺沒有在它之上實現(xiàn)service規(guī)定了諸多限制，相反，它為MBean的部署和訪問提供了許多方便：Service可以在不重啟動
JBoss平臺的情況下，被熱部署或者熱刪除；Service不必擔(dān)心它引用的jar包如何到位，將這些jar包放在合理的位置，它們就直接能被部署器找
到了；如果service需要較好的生命周期管理，或引用其他service，對JBoss平臺的依賴才派上用場。
一個部署到JBoss的service可以是放置在$JBOSS_HOME/server/<config>/deploy目錄下的一個
*.sar包，一個*.sar文件夾，或者由*-service.xml描述，或者是其他的形式。一個service經(jīng)由xml文件描述可以暴露多個
mbean。
一個部署到JBoss的service可以是不依賴于JBoss平臺的任何符合JMX規(guī)范的mbean，也可以是一個借用JBoss
Service的生命周期管理和依賴管理的一個MBean，也可以是利用JBoss
XMBean描述規(guī)范將普通的Java對象“升級”而出的一個mbean：
1）mbean可以沒有對JBoss的任何依賴。以standard
mbean為例，三個文件就足夠提供一個service：org.abc.HelloMBean接口，實現(xiàn)該接口的org.abc.Hello類，以及一
個service描述文件——該描述文件可以是sar包或目錄內(nèi)的META-INF/jboss-service.xml，也可以是一個單獨作為部署單位
的文件，如直接在deploy目錄（或其子目錄）下的hello-service.xml。
2）如果用戶定義的mbean需要生命周期的管理，它
可以實現(xiàn)org.jboss.system.ServiceMBean接口及其create，start，stop，destroy等生命周期方法，或者
干脆擴展org.jboss.system.ServiceMBeanSupport類。
3）開發(fā)者可以在service描述文件里說明本
mbean對其他mbean的依賴。所謂“依賴”是指，本mbean在create/start時先檢查被依賴的mbean是否已經(jīng)存在/啟動，否則調(diào)用
它的create/start方法；一個被依賴的mbean被stop/destroy時，依賴于它的mbean首先被調(diào)用stop/destroy方
法。
4）除了基于JMX標(biāo)準的mbean實現(xiàn)方案，JBoss還支持用一個xml文件描述的方式將普通的Java對象開放為一個mbean，即
XMBean。在service描述文件里可以用xmbean-dd屬性指明一個外部的XMBean定義，或者將xmbean-dd屬性賦值為""，在
mbean標(biāo)簽中內(nèi)嵌xmbean的內(nèi)容說明。XMBean的優(yōu)勢在于a）不需要目標(biāo)Java對象實現(xiàn)任何JMX有關(guān)的接口；b）相對Standard
MBean可以在xmbean-dd的xml內(nèi)提供豐富的元數(shù)據(jù)描述信息。
理論上，放置在$JBOSS_HOME/server/<config>
/deploy（包括子目錄）下的所有jar包都會被URLDeploymentScanner監(jiān)控，為其他的service所用。這些jar包也是可動
態(tài)添加的。實際上，我們吧my-service.xml和my-service.jar（假設(shè)my-service.xml描述的mbean的類定義在
my-service.jar內(nèi)）放置在deploy目錄下，然后啟動JBoss，my-service是不能成功啟動的，因為JBoss的
MainDeployer部署包有一個順序，基本上是.deployer>deployer.xml>.sar>.rar>
ds.xml>service.xml>.har>.jar>.war>.wsr>.ear>.zip>.
bsh>.last，可見my-service.xml是在my-service.jar之前得到部署的，自然引用不到my-
service.jar之內(nèi)的類了。
如果將jar放在sar（目錄或包）內(nèi)的任一層子目錄內(nèi)，sar對應(yīng)的service引用這些jar是沒有問題的，因為sar相關(guān)的部署器做了“深度優(yōu)先”的部署——先部署這些jar包，然后部署sar。
因為UnifiedLoaderRepository所決定的平面類裝載模型，在一個sar內(nèi)引用（部署）成功了a.jar，其他大部分service也可以使用a.jar了。
*-service.xml里的server標(biāo)簽有一個classpath的子標(biāo)簽，用來指定sar的外部類路徑。classpath標(biāo)簽的
codebase屬性默認是以$JBOSS_HOME/server/<config>為根的，archives屬性的值可以是一個或多個逗
號格開的jar文件名（注意只能是一層文件名）