1 2 Previous Next 15 Replies Latest reply on Jun 25, 2009 8:35 AM by Ales Justin

    MC tools

    Ales Justin Master

      Just yesterday I was thinking of needing nice MC tool(s)
      to help me with some migration, optimization.

      So, the idea is next (all cmd line tools):
      (1) help migrate -service.xml --> -beans.xml
      * single file, ant patterns
      * warn on non portable elements (perhaps being able to type in the fix/change)

      (2) display services dependencies (pojos, mbeans, aliases, deployments, ...) via apiwiz
      * at descriptor file level (-beans.xml, -service.xml, jboss-dependency.xml, jboss-classloading.xml)
      * at (Bean|Service)MetaData level (hook into Deployers attachments)
      * at kernel level (inspect ControllerContexts for DependencyItems)

      This would require a new mc-tools projects,
      with 2 modules: migration, dependencies

      Both tools should come pretty much in-handy with JBoss6.
      (1) moving all those mbeans to mc pojos
      (2) helping determining how to handle On_Demand mode

        • 1. Re: MC tools
          Flavia Rainone Master

           

          "alesj" wrote:
          Just yesterday I was thinking of needing nice MC tool(s)
          to help me with some migration, optimization.

          So, the idea is next (all cmd line tools):
          (1) help migrate -service.xml --> -beans.xml
          * single file, ant patterns
          * warn on non portable elements (perhaps being able to type in the fix/change


          I'm doing some investigation to implement this tool.

          "alesj" wrote:

          Both tools should come pretty much in-handy with JBoss6.
          (1) moving all those mbeans to mc pojos

          Should the migration tool generate a beans.xml file that declares every MBean just as a POJO, without injecting the @JMX annotation?
          If yes, how exactly are we dealing with those MBeans? For example, suppose that I use the migration tool to migrate my MBean X to a MC bean. But suppose that another MBean Y, deployed at the MBeanServer, has an attribute that is initialized with the name of old MBean X, and it uses this property internally to look up for X in the MBeanServer. Now that I'm not deploying X as an MBean anymore, Y is hence broken. How do we deal with that?

          • 2. Re: MC tools
            Ales Justin Master

             

            "flavia.rainone@jboss.com" wrote:

            Should the migration tool generate a beans.xml file that declares every MBean just as a POJO, without injecting the @JMX annotation?
            If yes, how exactly are we dealing with those MBeans? For example, suppose that I use the migration tool to migrate my MBean X to a MC bean. But suppose that another MBean Y, deployed at the MBeanServer, has an attribute that is initialized with the name of old MBean X, and it uses this property internally to look up for X in the MBeanServer. Now that I'm not deploying X as an MBean anymore, Y is hence broken. How do we deal with that?


            I would do it like this.

            Ask if all beans should get @JMX:
            (a) yes, all
            (b) none
            (c) prompt for every mbean

            If (b) is used then the new bean name is previous mbean name.
            For (a) and (c) I would make a plugable mechanism.
            e.g. -Dname_transformer=org.jboss.mc.tools.naming.UseServiceProperty
            Where this naming class would know how to create a new bean name from the old mbean name.
            Or it could force a prompt, while already suggesting some name.


            • 3. Re: MC tools
              Flavia Rainone Master

              Ales,

              Regarding the convertion tool, what do I do with embedded XMBeans and with XMBeans with references to external descriptors?

              I'm guessing this is going to be unsupported feature, but let me know what you think.

              • 4. Re: MC tools
                Ales Justin Master

                 

                "flavia.rainone@jboss.com" wrote:

                Regarding the convertion tool, what do I do with embedded XMBeans and with XMBeans with references to external descriptors?

                It's been a while since I used this, so how does this exactly look like?
                Although we have beans nested within beans, is this it?

                • 5. Re: MC tools
                  Flavia Rainone Master

                   

                  "alesj" wrote:
                  "flavia.rainone@jboss.com" wrote:

                  Regarding the convertion tool, what do I do with embedded XMBeans and with XMBeans with references to external descriptors?

                  It's been a while since I used this, so how does this exactly look like?
                  Although we have beans nested within beans, is this it?


                  This is when you define one of the attributes xmbean-dd (external descriptor) or xmbean-code (embedded), in order to define the interface of the MBean.

                  • 6. Re: MC tools
                    Ales Justin Master

                     

                    "flavia.rainone@jboss.com" wrote:

                    This is when you define one of the attributes xmbean-dd (external descriptor) or xmbean-code (embedded), in order to define the interface of the MBean.

                    This is then similar to @ManagedX annotations?

                    OK, leave it out atm.
                    If there is some demand, we might persuade the one with the demand to do it. :-)

                    • 7. Re: MC tools
                      Ales Justin Master

                      Looking at the JBossBeanXMLMarshaller::marshal.

                       else if(value instanceof BeanMetaData)
                       {
                       BeanMetaData anonymousBean = (BeanMetaData) value;
                      

                      I guess a recursions could be used here?

                      • 8. Re: MC tools
                        Ales Justin Master

                        I would also handle different metadata classes/values differently, more OO.
                        As it would be much easier to extend (and support) in the future.

                        Every excessive "if" usage usually indicates lack of OO. ;-)

                        • 9. Re: MC tools
                          Flavia Rainone Master

                           

                          "alesj" wrote:
                          Looking at the JBossBeanXMLMarshaller::marshal.
                           else if(value instanceof BeanMetaData)
                           {
                           BeanMetaData anonymousBean = (BeanMetaData) value;
                          

                          I guess a recursions could be used here?


                          It shouldn't, unless you want to make the code less clear.
                          The method that receives the BeanMetaData does not deal with anonymous beans, as is the case of the internal bean. Plus, the internal bean is much simpler, it can only have properties.

                          I think that the point here is that I wrote the code converting ServiceMetaData to BeanMetaData counting on using JBoss XB marshalling. This marshalling would validate my bean meta data (I'm absolutly sure that this meta data I'm generating is not correct, if I passed it along to MC it wouldn't interpret all the meta data the same way I'm doing it).

                          Now, that discovered that I can't use JBoss XB marshalling:
                          http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234012

                          I think that converting meta data is pointless, IMO. I'm considering to get rid of that convertion and to generate the XML directly, based on ServiceMetaData.

                          What do you think?

                          • 10. Re: MC tools
                            Flavia Rainone Master

                            For the record, this thread is related to the Jira issue:
                            https://jira.jboss.org/jira/browse/JBMICROCONT-444

                            • 11. Re: MC tools
                              Flavia Rainone Master

                               

                              "alesj" wrote:
                              I would also handle different metadata classes/values differently, more OO.
                              As it would be much easier to extend (and support) in the future.

                              Every excessive "if" usage usually indicates lack of OO. ;-)


                              This is the case when you can edit the types you're dealing with and add a method to them to do what you want to do. So, instead of doing:

                              CommonSuperClass obj =...;
                              if (obj instance of A) { System.out.println("A blablabla"); }
                              else if (obj instance of B) { System.out.println("B bla bla bla");}


                              You change A and B classes to:
                              class A extends CommonSuperClass
                              {
                              ...
                              public String getMessage() { return "A blablabla";}
                              }
                              
                              class B extends CommonSuperClass
                              {
                              ...
                              public String getMessage() { return "B bla bla bla";}
                              }


                              And now you can do:
                              CommonSuperClass obj = ...;
                              System.out.println(obj.getMessage());


                              But, of course, I can't change the meta data classes, adding a method that generates the XML form of each one of them. So, how can I get rid of my if instanceof statements and still generate proper XML for every meta data type?

                              I guess I missed what you're trying to tell me. So, please, elaborate :)

                              • 12. Re: MC tools
                                Ales Justin Master

                                 

                                "flavia.rainone@jboss.com" wrote:

                                I think that converting meta data is pointless, IMO. I'm considering to get rid of that convertion and to generate the XML directly, based on ServiceMetaData.

                                What do you think?

                                No, I would still do it over conversion.

                                * it's more type safe.
                                * it shows how SMD and BMD, or mbeans and pojos, relate to each other
                                * once XB has proper marshaling, it will be trivial to spit out xml

                                • 13. Re: MC tools
                                  Ales Justin Master

                                   

                                  "flavia.rainone@jboss.com" wrote:

                                  But, of course, I can't change the meta data classes, adding a method that generates the XML form of each one of them. So, how can I get rid of my if instanceof statements and still generate proper XML for every meta data type?

                                  I guess I missed what you're trying to tell me. So, please, elaborate :)

                                  I don't know the name of the pattern, but it's trivial to do it. ;-)
                                  Instead of changing the classes, you can write proper adapters / delegates.

                                  e.g. (pseudo code)
                                  // T --> SMD side metadata type; e.g. ServiceInjectionValueMetaData
                                  // U --> BMD side metadata type; e.g. AbstractInjectionValueMetaData
                                  interface SMD2BMD<T, U>
                                  {
                                   Class<T> mappingClass();
                                  
                                   U toBMD(T t);
                                  
                                   String toXML(U u);
                                  }
                                  


                                  Where now instead of multiple ifs, you would simply do something like this:
                                  Map<?, ?> adapters = ...;
                                  SMD2BMD s2b = adapters.get(smd.getClass());
                                  if (s2b == null)
                                  {
                                   // no exact mapping class match, lets iterate
                                   for (Class key : adapters.keySet())
                                   {
                                   if (key.isInstance(smd))
                                   {
                                   s2b = adapters.get(key);
                                   break;
                                   }
                                   }
                                   if (s2b == null)
                                   throw new IllegalArgumentException("No such mapping " + smd);
                                  }
                                  


                                  • 14. Re: MC tools
                                    Flavia Rainone Master

                                     

                                    "alesj" wrote:
                                    I don't know the name of the pattern, but it's trivial to do it. ;-)
                                    Instead of changing the classes, you can write proper adapters / delegates.

                                    I have started implementing this and it really looks much better. :-)
                                    The first version of these classes, implementing only the metadata to metadata conversion, is committed to svn.

                                    1 2 Previous Next