1 2 3 4 5 Previous Next 61 Replies Latest reply on Feb 21, 2008 8:42 AM by ataylor Go to original post
      • 45. Re: JBM 2 Management Interfaces
        mazz

         

        The user is not going to be starting up any other RHQ serves just so they can see the JBM interface, that would suck.


        Agreed. RHQ is for production management. If you want a small, simple management UI (for, say, developers to use), RHQ is not what you want to use.

        But, what you will want to do is make your management interface remotely accessible so you CAN plug into a production management environment (like RHQ) so I can manage your jbm services along side of my other production apps/services.

        So, I can import my jbm services into RHQ's inventory along with my JBossAS servers, and other managed products so, when I *do* deploy jbm in production, I can manage it with all my other things in a single management platform. Because if I have to load up your management console UI separately from my other management tools just to manage jbm, that would suck too. Its a "production" enviroment vs. "development" environment thing.


        • 46. Re: JBM 2 Management Interfaces
          ataylor

           

          "@JMX" is not a standard annotation from the JDK libraries, so we can't have it in our core classes since it will introduce a build time dependency on whatever library that comes from (AOP?), and we don't want to force our embedded users to drag in jars they don't need.


          These can be moved to the configuration

          • 47. Re: JBM 2 Management Interfaces
            ataylor

             

            But, what you will want to do is make your management interface remotely accessible so you CAN plug into a production management environment (like RHQ) so I can manage your jbm services along side of my other production apps/services.


            Again, they will be exposed via the JMX route inside JBoss

            • 48. Re: JBM 2 Management Interfaces
              ataylor
              • 49. Re: JBM 2 Management Interfaces
                timfox

                 

                "mazz@jboss.com" wrote:


                Agreed. RHQ is for production management. If you want a small, simple management UI (for, say, developers to use), RHQ is not what you want to use.

                But, what you will want to do is make your management interface remotely accessible so you CAN plug into a production management environment (like RHQ) so I can manage your jbm services along side of my other production apps/services.

                So, I can import my jbm services into RHQ's inventory along with my JBossAS servers, and other managed products so, when I *do* deploy jbm in production, I can manage it with all my other things in a single management platform. Because if I have to load up your management console UI separately from my other management tools just to manage jbm, that would suck too. Its a "production" enviroment vs. "development" environment thing.


                Well.. I guess if we just expose our beans via JMX using the standard JDK stuff as Jeff suggested, then we have the best of both worlds.

                It's just a shame we can't get the nice UI unless we have the "big-iron" server.

                • 50. Re: JBM 2 Management Interfaces
                  mazz

                   

                  "timfox" wrote:

                  It's just a shame we can't get the nice UI unless we have the "big-iron" server.


                  I didn't talk about the new JBoss5 embedded console and this may address this point you bring up.

                  The new JBoss5 embedded console will actually ship with the RHQ "plugin container" running in-process with it. So, the "big iron" and the embedded console will use the same RHQ plugin architecture. The embedded console will actually be:

                  a) a web app war with its own little seam-based UI (not the big-iron RHQ core UI but with some shared RHQ UI code nonetheless)
                  b) the RHQ plugin container (the same plugin container running in the RHQ Agent - the RHQ Agent is just a shell that wraps the RHQ plugin container)
                  c) the RHQ JBossAS5 plugin, which is deployed in the plugin container

                  So, it is concievable that you could write your jbm management UI and have it interface with the RHQ plugin (that talks to your jbm management interface) by embedding the plugin container just like the JBoss5 microcontainer's embedded console will do. That way you have one plugin that works in either your smaller mgmt UI console AND the big-iron RHQ Server stuff.


                  • 51. Re: JBM 2 Management Interfaces
                    timfox

                     

                    "mazz@jboss.com" wrote:
                    "timfox" wrote:


                    I didn't talk about the new JBoss5 embedded console and this may address this point you bring up.

                    The new JBoss5 embedded console will actually ship with the RHQ "plugin container" running in-process with it. So, the "big iron" and the embedded console will use the same RHQ plugin architecture. The embedded console will actually be:

                    a) a web app war with its own little seam-based UI (not the big-iron RHQ core UI but with some shared RHQ UI code nonetheless)
                    b) the RHQ plugin container (the same plugin container running in the RHQ Agent - the RHQ Agent is just a shell that wraps the RHQ plugin container)
                    c) the RHQ JBossAS5 plugin, which is deployed in the plugin container

                    So, it is concievable that you could write your jbm management UI and have it interface with the RHQ plugin (that talks to your jbm management interface) by embedding the plugin container just like the JBoss5 microcontainer's embedded console will do. That way you have one plugin that works in either your smaller mgmt UI console AND the big-iron RHQ Server stuff.


                    Now that sounds interesting.





                    • 52. Re: JBM 2 Management Interfaces
                      mazz

                      For more information on the embedded console, see the Design POJO Server forum:

                      http://www.jboss.com/index.html?module=bb&op=viewforum&f=208

                      Scott, Mark Spritzler and Charles Crouch know more about the embedded console. I think they talk about it on that forum.

                      • 53. Re: JBM 2 Management Interfaces
                        jmesnil

                         

                        "jmesnil" wrote:
                        "timfox" wrote:
                        I don't want to end up in a situation where we have to start an MBean server just so we can expose our POJOs


                        For the standalone case, the simple way is to register our POJOs as MBeans on the JVM platform MBeanServer, enable a remote access to it and use a generic JMX console (e.g. jconsole).


                        As an example, it is only a 3-line 0-dependency change to be able to manage a MessagingServer from a GUI.

                        Step 1/ Expose our POJO as MBeans on the platform mbeanserver. E.g using JBM's trunk EmbeddedExample:

                        MessagingServer messagingServer = ...;
                        
                        // add the next 3 lines:
                        StandardMBean serverMBean = new StandardMBean(messagingServer, MessagingServer.class);
                        ObjectName serverON = ObjectName.getInstance("org.jboss.messaging:name=MessagingServer");
                        ManagementFactory.getPlatformMBeanServer().registerMBean(serverMBean, serverON);
                        
                        messagingServer.start();
                        


                        Step 2/ Run JBM in standalone and add jmx management. On Sun JVM, set
                        -Dcom.sun.management.jmxremote


                        That's all we need to do to be able to use a generic JMX console.

                        Step 3/ Open jconsole and connect using the "local" connection.
                        In the "MBeans" tab, go to "org.jboss.remoting:name=MessagingServer".
                        In the "Operations", start and stop the messaging server as much as you want.

                        To sum up, to get this minimal support for a GUI management console, the only thing we need to do is register our POJO on the platform mbean server.

                        This can be done very simply in any POJO implementation which conforms to an interface:
                        class ServiceImpl implements ServiceIntf
                        {
                         public ServiceImpl(...)
                         {
                         ...
                         ObjectName on = new ObjectName(...) // based on POJO fields
                         // this instance is exposed as a MBean of the ServiceIntf interface...
                         StandardMBean mbean = new StandardMBean(this, ServiceIntf.class);
                         // ... and registered on the JVM platform mbean server
                         ManagementFactory.getPlatformMBeanServer().registerMBean(mbean, on);
                         }
                        
                         // somewhere in the POJO lifecycle, we should also unregister its MBean
                        }
                        


                        As long as we stick to standard JMX conventions (get/set for properties, etc.), we could have a usable GUI console for (almost) free.

                        The memory footprint to register the mbeans on the platform mbean server is negligible and this could be done regardless of the way JBM is run (as long as we unregister mbeans properly when the managed resources are disposed)

                        • 54. Re: JBM 2 Management Interfaces
                          timfox

                          Sounds like a sensible approach - we should certainly allow the ability to expose the new management API that Andy is working on that way (there should be a switch to prevent it being exposed too).

                          We should also look at the "embedded" JON stuff that mazz mentioned too.

                          • 55. Re: JBM 2 Management Interfaces
                            mazz

                            As long as we stick to standard JMX conventions (get/set for properties, etc.), we could have a usable GUI console for (almost) free.

                            And would make integration into RHQ very simple. Doing it that way should allow you to use the RHQ JMX plugin to connect and use your MBeans with very little to no code (just define your MBean metadata in the RHQ plugin and you get the RHQ production-level management features "for free"). Your plugin could then conceivably be deployed in the embedded console and work in there too.

                            Your developers can use JConsole, MC4J or similar JMX consoles as a alternative, lightweight management console.

                            • 56. Re: JBM 2 Management Interfaces

                              Hi guys, glad to be a part of this conversation.

                              After reading through the thread, I thought I'd add my 2 cents with regards to using RHQ and Embedded Console, if that is the route you should choose. (Which I think is the best route :) )

                              OK, so think of this in just three parts.
                              1) The UI (Embedded Console)
                              2) Plugins and the RHQ Plugin Container
                              3) Your Management Interface for JBM

                              I hope you don't mind be going top down.

                              1) The Embedded Console is just a Seam app, so all it needs is something that can "deploy" a Seam app, I believe that includes the Microcontainer. The great thing about the console is that it is generic, just create a plugin and drop it in the plugins dir, and the console will display it nice and pretty. It does use the RHQ plugin container embedded in it. Think of this as an embedded RHQ agent, so no seperate server or agent to start up.

                              So its dependencies are
                              Seam
                              JSF
                              RichFaces
                              JSTL
                              JDom
                              3 apache commons jars
                              RHQ core

                              2) Plugins
                              You include whatever plugins you want the UI to display. This is the only thing for the UI that you will need to create. Mazz gave you all the info about plugins and what they need.

                              The plugin's dependencies are anything it needs to communicate to what it plans to manage and monitor. In a lot of cases it might already have been provided for you. In looking at our plugins, it is only the jmx-plugin that has one jar with it for the EMS library that it uses.

                              3)Your Management Interface for JBM.
                              Now this is completely up to you. All the plugin will need is an ability to connect to it, locally or remotely. Remotely more for everyone to re-use your plugin in other servers. So you can choose any transport you want. You just might need to include that transports jar files in the plugin jar.


                              Let me use an example of the AS 5 plugin.

                              AS 5 has the Profile Service which is the management interface that AS 5 exposes (3). In the AS 5 plugin, it simply does a JNDI lookup for the profile service and then just codes to that api. In the rhq-plugin.xml I define my resources and what props, metric statistics and operations each resource type can expose (2).

                              I simply drop the AS 5 plugin into the plugins directory of the Embedded Console war and now the Console manages and monitors AS 5 (1).

                              So the dependencies are very small, the JON team designed and built it such that it was as simple as possible for plugin developers to add management and monitoring capabilities to their products.

                              I hope that helps.

                              Thanks

                              • 57. Re: JBM 2 Management Interfaces
                                starksm64

                                 

                                "timfox" wrote:
                                "@JMX" is not a standard annotation from the JDK libraries, so we can't have it in our core classes since it will introduce a build time dependency on whatever library that comes from (AOP?), and we don't want to force our embedded users to drag in jars they don't need.

                                This is the main issue that requires administration to be treated as an aspect that can be applied as an integration concern. We override the default jms destinations to apply the management aspect in jbossas. In general, we need to support different aspect mappings to allow projects to use whatever is natural to them.

                                If you want to use jmx, fine. If you want to use the mc @ManagementObject stuff, fine. The integration layer need to define the correct aspect that allows this information to be properly brought into the management view of the environment.


                                • 58. Re: JBM 2 Management Interfaces
                                  timfox

                                   

                                  "scott.stark@jboss.org" wrote:

                                  This is the main issue that requires administration to be treated as an aspect that can be applied as an integration concern. We override the default jms destinations to apply the management aspect in jbossas. In general, we need to support different aspect mappings to allow projects to use whatever is natural to them.

                                  If you want to use jmx, fine. If you want to use the mc @ManagementObject stuff, fine. The integration layer need to define the correct aspect that allows this information to be properly brought into the management view of the environment.


                                  The way I look at it, whether an class is exposed via management or not, is configuration information - deploy time configuration, and should not be hardcoded into the source. Actually this is a gripe I have with annotations as they are used in many situations - deploy time meta-data infects the source. This seems plain wrong to me.

                                  Yes, one way around this is to move out those classes into an integration layer, but since the same classes need to be used in a non MC environment we would then have to maintain two versions of the same classes - one with and one without the annotations in the worst case, or at least subclass the files with versions with annotations and put the annotated subclasses in an integration layer.

                                  This seems very hacky to me. I believe deploy time meta data (which this is) belongs in configuration files, not in the source code!

                                  Can't we just specify management in our microcontainer jbm-beans.xml config? This would make more sense to me.

                                  • 59. Re: JBM 2 Management Interfaces
                                    ataylor

                                     

                                    Can't we just specify management in our microcontainer jbm-beans.xml config? This would make more sense to me.


                                    yes, ive just changed it