So to summarize what I understand from the discussion so far: 1) The Admin Console is going to update JBoss AS using the DeploymentService 2) The Admin Console is going to start out not knowing anything about the JBoss instance it is running on, but learns by having services created through it.
Well I have a problem, and solution, with 2). The concept of the Admin Console "learning" works great for services such as Datasources, i.e. it is reasonable for users to start with an empty list and add new Datasources to it. However the concept breaks down when applied to monolithic services such as JMS: It is not reasonable for users to create the JMS service, e.g. specifying the cache manager and security manager settings, from scratch. The Admin Console must be able to find the existing settings and display them. So how can the Admin Console find these settings? Answer: JMX. For monolithic services, e.g. JMS, Tomcat, JTA Transaction Service, we can use hard-coded ObjectName's to locate MBeans and from those, all the necessary information should be available. Specifying the ObjectNames in a configuration file would allow us to update them if for some reason they changed between versions of JBossAS. For example, lookup the MBean "jboss.mq:service=DestinationManager" and from there you can get references to the JMS Cache Manager, Persistence Manager and State Manager (but oddly not the Security Manager?). These MBeans provide all the information you could possible want on the base JMS settings. In addition doing a lookup of "jboss.mq:service=InvocationLayer,type=HTTP" gives you an MBean with with all the JMS HTTPIL settings. This approach does have an important implication: You should not change settings via the jmx-console if you are also using the Admin Console. The problem is that changes made through the jmx-console, which are mostly transient, could be made permanent. For example, 1) Start JBoss up 2) Go to the JMX console and update the HighMemoryMark on jboss.mq:service=MessageCache 3) Open up the Admin Console and browse to the JMS settings. You will see the change made in 2) 4) In the Admin Console change the MaxMemoryMark on the CacheManager. 5) Commit the change in the Admin Console. You will persist the changes made in both steps 2) and 4). This is unexpected behaviour and is therefore bad. Thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3862975#3862975 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3862975 ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
