JMX有实际意义吗？谁有过经验

JMX主要是用来实现动态配置吧，感觉将POJO做成Singleton也可以办到啊，就是少了JNDI绑定而已。有必要为了这么点功能将JMX的技术复杂性引入到一个项目中去么，除非想做cluster范围的动态配置

如果你想编写App Server，那么就很用，或者你想编写一个JVM的监测工具，也很有用，如果你仅仅编写应用代码，那么就没有用。

JMX的应用不仅于此吧，JMX是相当有用的一个规范，硬件管理平台可以基于它，你也可以为你的应用写一个管理工具，hibernate也实现了JMX规范。

Enabling Component Architectures with JMX
JBossGroup的CEO Marc Fleury的几年前的一篇文章
没什么新意 但把JMX在JBoss中的地位说清楚了

特别是以下两段：
------------------------------------------------------------------------------------
JMX allows a centralized management of managed beans, or MBeans, which act as wrappers for applications, components, or resources in a distributed network. This functionality is provided by a MBean server, which serves as a registry for all MBeans, exposing interfaces for manipulating them. In addition, JMX contains the m-let service which allows dynamic loading of MBeans over the network. In the JMX architectural model, the MBean server becomes the spine of the server where all server components plug in and discover other MBeans via the MBean server notification mechanism.
------------------------------------------------------------------------------------
Instead of restricting the use of JMX to management only, JBoss uses JMX as a means to provide automated open source integration. By being fully modular, JBoss pioneers the next generation JMX architectures of the J2EE servers. For other vendors to achieve the same ease of use and dynamic configurability, they will need to follow suit as JMX is more than just a management interface. It is a natural architecture for service-based frameworks and the only way to cleanly manage the different parts of it both at run-time and in development.
------------------------------------------------------------------------------------

WebLogic也是以JMX作为核心的
至于在JFox2中 JMX的地位有所变化了

以下是JFox开发人员的讨论摘录
————----------------------------------------------------------------------------
JFox 以前是采用的JFoxMX 作为微内核， JMX 是一个不错的管理对象管理框架， 对于应用服务器这样的系统，或者说其他的应用系统，系统模块化和可插拔性显得越来越重要，使用JMX 所有的被管对象都必须要按照JMX的规范实现MBean接口，随着系统越来越复杂，这些MBean是系统内部的结构反而变得复杂，不易于维护，而且没有很透明的解决系统组件间耦合关系的管理问题。
IoC 容器正好就解决这这个组件间的耦合管理问题，由于同时我们也需要对外提供对App Server提供很好的监控和管理功能，所以将这两者结合起来，只是在需要对外提供管理接口的地方使用JMX, 而不是用它来作为系统的连接各个组件间的微内核。
JFoxSOAF 中也采用了这样一个IoC容器作为微内核，用于集成各个组件。

基于组件的开发要解决两个非常重要的问题：组件的耦合和管理。
组件的耦合具体的表现就是运行时，组件之间的相互依赖，组件之间通过相互依赖并进行协作达到组件的集成；
组件的管理表现为通过从外部调用组件的接口，完成对组件的状态、生命周期的控制。
JMX 能够很好的解决组件管理，但是并没有提供组件依赖功能，虽然象JBoss通过对JMX进行一些扩展，也实现了对组件的依赖关系的控制，但是在内部，JMX仍然不适合做为一个专业的解决组件依赖关系以及实现组件集成的框架；
IoC正好与JMX互补，用来解决组件依赖问题。
通过扩展JMX来使其能够解决依赖关系问题，以及通过扩展IoC容器，使其具备组件管理功能，是达到最后目的的两条路径。我们经过仔细衡量，觉得采用IoC内核，然后在此基础上开发一个用来管理组件的标准组件，是更好的解决问题的方式。
使用IoC内核作为基础组件框架，基本上不会破坏组件的设计思路，要注意的就是需要提供一些接口对满足各种类型组件，比如：对于JNDI服务这样的基础的服务，需要在被装载的时候就启动；还有就是要注意组件的注册的顺序，被依赖的组件需要先注册，等等问题。
总之，经过我们的亲身体验，IoC更适合做基础组件集成框架。
-------------------------------------------------------------------------------------

当初去面试我现在的公司时，老板说他们的应用是基于JMX的，问我会不会，我很郁闷的告诉他不会，回去后恶补了一个礼拜JMX，我去那家公司后直到现在也没有发现JMX的影子，更郁闷，看来21世纪的人才就得会吹 :P 

我们在做一些后台线程使用了JMX。有一些对象jndi的初始化也可使用JMX。其他的还没使用过。JMX在一般的应用中好像用的不多。

其实JMX就是分布式的singleton？


That's my point.我想说的就是如果类似spring的ioc可以更好地实现这个任务，只不过由于是lightweight，所以没有distributed功能

嗯，说得有理

感觉JMX作为应用的管理工具还是很有意义的，我想JMX的应用决不会局限于应用服务器级别的，否则sun也不会把它加到j2se5.0中。我现在就在做一个项目，用JMS实现对组件的远程管理和操作

JMX里面很重要的一点，是它能将服务通过一个可配置、可监测的虚拟软件总线组织起来了。而IoC则更多的是解决离散的软件依赖与构建问题，所管理组件或服务之间并不需要很强的内聚性。
    因此个人觉得做整体设计的时候，需要从JMX的设计角度来考虑，如何将不同服务，以JMX软件总线组织到一起，如何从服务而非组件层面管理；而在实现层面，则可以适应IoC容器，如Spring/PicoContainer进行基于依赖关系的组件管理。两者可以说各有所长，互相补充的关系。