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