1 Reply Latest reply on Oct 21, 2010 12:23 PM by brian.stansberry

    Management view on the ServiceContainer

    thomas.diesler

      Folks,

       

      I wrapped the new ServiceContainer.dumpServices() functionality in an MBean.

       

      You can now point jconsole to 'jboss:ServiceContainer' to get access to this management inferface

       

           public interface ManagedServiceContainer { 
      
               List<String> listServices(); 
       
               List<String> listServicesByMode(String mode); 
       
               List<String> listServicesByState(String state); 
       
               void setMode(String serviceName, String mode); 
           }
      
      

       

      Besides providing general state information on registered services, this also allows to set the mode on a given service controller. Hence, it can be used to bring up ON_DEMAND services for example.

       

      With the OSGi integration we were looking for a solution that allows us to bring up the OSGi subsystem triggered by an external provisioning system ( e.g. our hudson testsuite). One obvious approach would have been to copy a dummy bundle into the 'deployments' folder, which would trigger an OSGi deployment. Another approach would have been to register a dummy FrameworkMBean that would allow bundle installation. That MBean would than have to be replaced by its propper implementation that we currently get from Apache Aries.

       

      I figured however that this would be a general problem of bringing up/shutting down arbitrary services.

       

      https://jira.jboss.org/browse/JBAS-8542

       

      cheers

      -thomas

        • 1. Re: Management view on the ServiceContainer
          brian.stansberry

          If we're going to expose stuff like this, we need to carefully design our JMX domain namespaces. Well, we need to do that anyway.

           

          We need users to be able to clearly distinguish mbeans that represent a view on the proper domain-model based management API vs. those that are bypassing it and tweaking internals. This mbean is the latter. The former is what we can commit to as a stable long term API.