1 2 Previous Next 15 Replies Latest reply on Feb 8, 2008 4:33 AM by starksm64

    property values in ManagementViewImpl.applyTemplate

    aloubyansky

      The following part in ManagementViewImpl looks strange to me.
      What is the logic with serializable?
      The componentName for connection factories is always null. Even if it wasn't, they wouldn't be registered to the kernel, would they? Or I missing the part where they are registered?

      Thanks!

      public void applyTemplate(DeploymentPhase phase, String deploymentBaseName, DeploymentTemplateInfo info)
      ...
       // TODO - decide what is the type of value when we set it
       // since currently get always returns MetaValue, but we see some cases
       // where plain Serializable is enough
       Serializable serializable;
       MetaValue metaValue;
       Object value = prop.getValue();
       if (value instanceof MetaValue)
       {
       metaValue = (MetaValue)value;
       MetaType metaType = metaValue.getMetaType();
       if (metaType.isSimple())
       serializable = ((SimpleValue)metaValue).getValue();
       else if (metaType.isGeneric())
       serializable = ((GenericValue)metaValue).getValue();
       else
       serializable = null;
       }
       else
       {
       serializable = (Serializable)value;
       metaValue = metaValueFactory.create(value);
       }
      // I add this check for the tests to pass if(serializable != null)
       ctxProp.setValue(serializable);
       // todo - should this also dispatch to runtime component?
       Object componentName = getComponentName(ctxProp);
       if("xa-datasource-properties".equals(ctxProp.getName()))
       System.out.println("componentName for prop=" + ctxProp.getName() + ": " + componentName + " " + ctxProp.getManagedObject());
       if (componentName != null)
       dispatcher.set(componentName, ctxProp.getName(), metaValue);
       }
       }
      


        • 1. Re: property values in ManagementViewImpl.applyTemplate
          aloubyansky

           

          "Scott" wrote:
          Ales did the dispatch work, so I'm not sure how the component registry
          is being maintained. The getComponentName method relies on the
          ManagedObject.targetManagedObject setting, and this relies on the
          @ManagementObjectRef/@ManagementObjectID annotations for the relations.

          When you say connection factories, what property are you talking about?
          A connection factory should have a component name based on its
          @ManagementObjectID. The logic in getComponentName should also be
          considering ManagedObjects with a proper name as a connection factory
          would, based on its jndiName property:

          @ManagementProperty(name="jndi-name", description="The global JNDI
          name to bind the factory under")
          @ManagementObjectID(type="DataSource")
          public String getJndiName()
          {
          return jndiName;
          }

          Looking at the logic for setting the ManagedObject.setComponentName
          value, the componentName relies on a ManagementRuntimeRef. This is
          something Ales added. Let's move this discussion to the forum as there
          needs to be a general understanding of how ManagedObjects are named and
          referenced.


          • 2. Re: property values in ManagementViewImpl.applyTemplate
            aloubyansky

            I mean for managed objects that represent MCF ManagedObject.getComponentName() returns null (at least what I saw in the test). MO.getName() returns the JNDI name, IIRC.

            • 3. Re: property values in ManagementViewImpl.applyTemplate
              starksm64

              See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=126318. We need to use the ManagementRuntimeRef to define how the jndiName maps to the mbean object name.

              • 4. Re: property values in ManagementViewImpl.applyTemplate
                aloubyansky

                I had a problem with registering managed objects for MCF under their name (i.e.) jndi-name. The template info defines management interface, i.e. it creates managed objects and properties. Which are re-used to create different MCF's. The JNDI name is a value of a managed property. So, it can't be used in the template info as MO's name.

                Currently, ManagedConnectionFactoryParserDeployer in build(...) method has the following hack

                if(deployment.getDeployments() != null)
                 {
                 for(ManagedConnectionFactoryDeploymentMetaData mcf : deployment.getDeployments())
                 {
                 ManagedObject mo = moFactory.initManagedObject(mcf, null, null);
                 if (mo != null)
                 {
                 // mcf.getClass().getName(), mo.getName() returns JndiName
                 // which won't work in the DsDataSourceTemplateInfo
                 managedObjects.put(mcf.getClass().getName(), mo);
                 }
                 }
                 }


                • 5. Re: property values in ManagementViewImpl.applyTemplate
                  starksm64

                  I"m not following what the problem is. How come mo.getName() can't be used?

                  • 6. Re: property values in ManagementViewImpl.applyTemplate
                    aloubyansky

                    Because, during template's start we create managed properties. That belong to managed objects. So, we create template managed objects before receiving property values from the user. There is no JNDI name at this point.

                    So, if I just use mo.getName() it will fail to find the MO.

                    java.lang.IllegalArgumentException: Failed to map key: org.jboss.resource.metadata.mcf.LocalDataSourceDeploymentMetaData to managed attachments for deployment
                     at org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:624)
                     at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
                     at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
                     at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:56)
                     at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:795)
                     at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
                     at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373)
                     at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
                     at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
                     at org.jboss.remoting.Client.invoke(Client.java:1634)
                     at org.jboss.remoting.Client.invoke(Client.java:548)
                     at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
                     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
                     at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
                     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
                     at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
                     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
                     at AOPProxy$1.applyTemplate(AOPProxy$1.java)
                     at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.createComponentTest(ProfileServiceUnitTestCase.java:711)


                    • 7. Re: property values in ManagementViewImpl.applyTemplate
                      starksm64

                      There has to be a stable graph in terms of names when the MOs were originally created, so what test generates this error so I can understand where the mismatch occurs?

                      • 8. Re: property values in ManagementViewImpl.applyTemplate
                        aloubyansky

                        Any test that creates a connection factory using template service in ProfileServiceUnitTestCase.

                        • 9. Re: property values in ManagementViewImpl.applyTemplate
                          starksm64

                          I'll look more into this as soon as I commit the datasource properties type of value changes. We talked about this being related to the problem I'm seeing with properties from runtime=true ManagedObjects not getting mapped to the configuration object. I'm not sure its exactly the same issue, but we need to clarify naming across configuration, runtime and templates to be sure this works for any type of deployment model.

                          • 10. Re: property values in ManagementViewImpl.applyTemplate
                            aloubyansky

                            I created ManagedObjectNameProperty which every time overrides the managed object's name whenever a new value is set.
                            This hack eliminates the hack in ManagedConnectionFactoryParserDeployer. And would work for JMS destinations if there was a way for a client to know the full path of the JMS destination deployment they are creating. The problem is to get the deploy directory path. I tried

                            InitialContext ctx = getInitialContext();
                             ProfileService ps = (ProfileService) ctx.lookup("ProfileService");
                             return ps.getActiveProfile().getRootFile(ManagedDeployment.DeploymentPhase.APPLICATION).getPathName();

                            But this is on the client side and Profile is not serializable.

                            I am committing the changes.

                            • 11. Re: property values in ManagementViewImpl.applyTemplate
                              aloubyansky

                              I've got some conflicts committing. Will do it later unless there are objections.

                              • 12. Re: property values in ManagementViewImpl.applyTemplate
                                starksm64

                                Can you send it to me so I can look at what your doing.

                                • 13. Re: property values in ManagementViewImpl.applyTemplate
                                  starksm64

                                   

                                  "alex.loubyansky@jboss.com" wrote:
                                  I created ManagedObjectNameProperty which every time overrides the managed object's name whenever a new value is set.
                                  This hack eliminates the hack in ManagedConnectionFactoryParserDeployer. And would work for JMS destinations if there was a way for a client to know the full path of the JMS destination deployment they are creating.
                                  ...

                                  Ok, I see what the problem is with the template ManagedProperty to ManagedObject.name is. What is needed is a mapping from the required ManagedProperty that provides the value of the ManagementObjectID(jndi name for DS) to ManagedObject name. So, the applyTemplate code first has to scan through the DeploymentTemplateInfo to find the one with the ManagementObjectID annotation, and then update the associated ManagedProperty's ManagedObject name. I'll test that.


                                  • 14. Re: property values in ManagementViewImpl.applyTemplate
                                    starksm64

                                    I have this working for the datasources. The ManagedConnectionFactoryParserDeployer still has to promote the toplevel ManagedObject.deployments property to toplevel ManagedObject using their jndi name, but this is really just because the deployments property maps to the ManagedDeployment seen by the client.

                                    I'm taking a look at the jms deployments now.

                                    1 2 Previous Next