9 Replies Latest reply on Jul 20, 2007 12:19 PM by starksm64

    ProfileService todos for deployer changes

    starksm64

      Some issues remaining from the deployer changes affecting the profile service are:

      + testDataSourceDeploymentType is broken because the getDeploymentNamesForType cannot be implemented. This is probably useless functionality, as it relies on the DeploymentContext.getTypes(). What is really needed is the ability to view the jsr77 types in a deployment structure.

      + testJmsDestinationComponents is broken because the ManagedDeployment/ManagedComponent tree cannot be built from the DeploymentUnit or client Deployment view as there is no access to the service descriptor component mbeans. A destinations-service.xml corresponds to multiple mbeans of various component types. In general the component types are unknown. We need to move the ManagedDeployment construction out of the client view of the profile service into a ManagedDeploymentDeployer, and start adding annotations to the other deployers/deployments to identify the component/jsr77 types that are produced.

        • 1. Re: ProfileService todos for deployer changes

           

          "scott.stark@jboss.org" wrote:

          + testJmsDestinationComponents is broken because the ManagedDeployment/ManagedComponent tree cannot be built from the DeploymentUnit or client Deployment view as there is no access to the service descriptor component mbeans. A destinations-service.xml corresponds to multiple mbeans of various component types. In general the component types are unknown. We need to move the ManagedDeployment construction out of the client view of the profile service into a ManagedDeploymentDeployer, and start adding annotations to the other deployers/deployments to identify the component/jsr77 types that are produced.


          I don't understand this. The managed objects are built on the server side
          by the MainDeployer with the help of the (parsing) deployers.
          The client should not be doing anything except asking for the ManagedObjects.

          IMHO the "jsr77 types" should be a part of the managed object api.
          i.e. you deploy a -ds.xml and you then ask for the managed objects
          you get back a set of managed objects which
          return "datasource" or "connectionfactory" from
          ManagedObject.getType()

          • 2. Re: ProfileService todos for deployer changes
            starksm64

            The ManagedObject api does not reflect the full structure currently. They only map to the attachments managed for a given DeploymentContext. The full structural view is what the ManagedDeployment/ManagedComponent being created by the aspects associated with the ManagementViewImpl provide. I think we are saying the same thing. The ManagedDeployment should be moved into the org.jboss.managed.api package and created on the server side as part of the deployer chain.

            • 3. Re: ProfileService todos for deployer changes
              starksm64

              The direction I'm currently heading is to generalize the profile service DeployerAspects to build the ManagedDeployment/ManagedComponent tree from the deployment metadata. The metadata handlers would come from the deployers who handle the associated component metadata. A component handler is something like:

              public interface ManagedDeploymentCreator<T>
              {
               public buildComponents(ManagedDeployment ctx, Set<? extends T> metaData);
              }
              


              And the *-service.xml component handler would be:
              public class ServiceMetaDataManagedDeploymentCreator
               implements ManagedDeploymentCreator<ServiceMetaData>
              {
              
               public void buildComponents(ManagedDeployment ctx, Set<? extends ServiceMetaData> metaData)
               {
              ...
               }
              
              }
              


              The DeployerAspects builds up the ManagedDeployment/ManagedComponent graph by calling out to the ManagedDeploymentCreators:
              public class DeployerAspects
              {
               /** The metadata type to ManagedComponent handlers */
               private Map<Class, ManagedDeploymentCreator> mdCreators;
              ...
               ManagedDeployment md = ...;
               for(Class mdType : mdCreators.keySet())
               {
               Set metadata = unit.getAllMetaData(mdType);
               if( metadata == null || metadata.size() == 0 )
               continue;
               ManagedDeploymentCreator creator = mdCreators.get(mdType);
               creator.buildComponents(md, metadata);
               }
              


              There can be interaction between multiple ManagedDeploymentCreators. For example, with jca, the factories(the managed components) and properties are determined by the ManagedConnectionFactoryDeploymentGroup metadata, but there are runtime ops and stats that have to come from the ServiceMetaData of the mbeans that the jca layer currently uses as the runtime objects implementing the factories. Those mbeans should not be showing up as some manageable sar, while jms destinations currently are deployed as just a collection of mbeans.


              • 4. Re: ProfileService todos for deployer changes

                I don't get the use AOP (DeployerAspects) for this?

                This api should be (and already is) part of the main deployers api.
                If it is wrong, then it needs changing.

                • 5. Re: ProfileService todos for deployer changes
                  starksm64

                  It is wrong as the top level DeploymentUnit managed element needs to be a ManagedDeployment, not a ManagedObject instance or set.

                  • 6. Re: ProfileService todos for deployer changes

                     

                    "scott.stark@jboss.org" wrote:

                    There can be interaction between multiple ManagedDeploymentCreators. For example, with jca, the factories(the managed components) and properties are determined by the ManagedConnectionFactoryDeploymentGroup metadata, but there are runtime ops and stats that have to come from the ServiceMetaData of the mbeans that the jca layer currently uses as the runtime objects implementing the factories. Those mbeans should not be showing up as some manageable sar, while jms destinations currently are deployed as just a collection of mbeans.


                    Ok, I mentioned this before, but without any conclusion in how this should work.

                    It does need a generic mechanism where the jca created managed object
                    is able to respond to a request (assuming it is runtime configurable)
                    "mydatasource".setProperty("max-pool-size", 100);
                    with a redirect to the MBean (or POJO).

                    Only the JCA Deployer knows the ObjectName/Attribute
                    that "mydatasource"/max-pool-size maps to.
                    But that ObjectName should not be a part of what the client uses or even cares about.

                    That's not to say it can't get help from the real ServiceDeployer to actually
                    handle the dispatch of the request.
                    It's only the real ServiceDeployer that knows how the ServiceMetaData
                    really maps to the runtime objects, i.e. mbeanserver.setAttribute(...);

                    But that solution seems like a very long winded and brittle mechanism?

                    My preferred solution would be to use KernelBus, but that is not
                    up-to-date in terms of dispatching MBean/POJO invocations
                    (Attribute and InvokeDispatchContext).

                    • 7. Re: ProfileService todos for deployer changes
                      starksm64

                       

                      "adrian@jboss.org" wrote:

                      It does need a generic mechanism where the jca created managed object
                      is able to respond to a request (assuming it is runtime configurable)
                      "mydatasource".setProperty("max-pool-size", 100);
                      with a redirect to the MBean (or POJO).

                      Only the JCA Deployer knows the ObjectName/Attribute
                      that "mydatasource"/max-pool-size maps to.
                      But that ObjectName should not be a part of what the client uses or even cares about.

                      That's not to say it can't get help from the real ServiceDeployer to actually
                      handle the dispatch of the request.
                      It's only the real ServiceDeployer that knows how the ServiceMetaData
                      really maps to the runtime objects, i.e. mbeanserver.setAttribute(...);

                      But that solution seems like a very long winded and brittle mechanism?

                      My preferred solution would be to use KernelBus, but that is not
                      up-to-date in terms of dispatching MBean/POJO invocations
                      (Attribute and InvokeDispatchContext).

                      Ok, as we discussed on the call there may not be any interaction in terms of the managed object view between the jca and service deployers, other than, the service deployer should not be assuming that the ServiceDeployment is a managable sar for which it should be creating a management view.


                      • 8. Re: ProfileService todos for deployer changes

                         

                        "scott.stark@jboss.org" wrote:

                        Ok, as we discussed on the call there may not be any interaction in terms of the managed object view between the jca and service deployers, other than, the service deployer should not be assuming that the ServiceDeployment is a managable sar for which it should be creating a management view.


                        One point I didn't state was that we might still actually want
                        the managable sar view for "power users" who want to see
                        what is really going on.

                        But that would require some notion of the managed object
                        being "synthetic" (i.e. an implementation detail)
                        so it doesn't appear in the normal management view.

                        It would just be a "read only" view for debugging purposes,
                        not something that the profile service would maintain.


                        • 9. Re: ProfileService todos for deployer changes
                          starksm64

                           

                          "adrian@jboss.org" wrote:

                          One point I didn't state was that we might still actually want
                          the managable sar view for "power users" who want to see
                          what is really going on.

                          Ok, that makes sense. Maybe that is the annotation the jca deployer puts on its resulting ServiceDeployment (a read-only annotation).