> However, if you want an opinion, the quickest answer I can contrive is for > application partitioning, especially when assembling an > application/subsystem management view using MBeans from multiple vendors.
I was thinking about this, along the lines of giving non-jboss mbeans a separate server (bound to the "user" domain)... though I have never actually tried to create more than one of these. > One thing to bear in mind is that, ok I know this is going to sound really > obvious, JMX is an api whose intent is to allow you to expose things for > *managment*. I have been keeping that in mind. > Personally, I think your question stems from the knowledge that JBoss > could not survive without the MBeanServer. I recently explained to a > colleage my opinion that EJB (and perhaps most of J2EE) is nothing more > than a great big third party binding see > http://c2.com/cgi/wiki?ThirdPartyBinding > > In JBoss the intercomponent bus for the binding is JMX. Right... which works fine as long as we limit the actual usage to decoupling components and do no try to push all communication over it. > That's a far cry from "and here's how your application can be managed by > ZippyConsole version2.0". I don't think there is any reason why a ZippyConsole (is there such a thing?) would not be able to manage a JBoss server... it should. I have been looking at JMX + JBoss from an administration aspect from the start. More recently I have been working on making it more embeddable. I was trying to think if it would be possible to start up two separate JBoss instances inside the same VM. If we could get/limit the JMX usage to only component linking and figure out a way to effectively use ObjectName to lookup/query components, then this could happen. I am still trying to figure out why they (jmx designers) made some of the choices they made... Thanks for your input. =) --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
