5 Replies Latest reply on Mar 8, 2008 7:45 AM by adrian.brock

    Updated Codebase

      I've updated the MC codebase with the following changes:

      1) JBoss Reflect and JBoss MDR (MetaDataRepository)
      2) JBossXB latest snapshot
      3) Now uses JAXB style annotations for parsing

      While I was doing it I also reworked the pom and .classpath dependencies
      to make them easier to manage. (I'll explain/discuss this on a different thread
      next week).

      There's still some failures in the tests (I haven't run the aop-mc-int tests,
      I already know they are broken because Kabir hasn't finished ;-)

      * Alias tests (expected)
      * Policy tests (expected)
      * Reliance rules (knock on from aop-mc-int)

      The issue I can see with reliance rules is that there is a top level
      element (lifecycle-describe) that is not reachable from AOPDeployment.

      I thought I'd added something for this, but obviously I dreamt it,
      or it was in a different context.
      Maybe it was in first prototype of the annotations and I never ported it?

      Anyway its easy to fix. You just need to be able to specify additional
      root classes when creating the schema, e.g.

      @JBossXMLSchema(...,
       additional=
       {
       DescribeLifecycleBeanMetaDataFactory.class,
       ConfigureLifecycleBeanMetaDataFactory.class
       }
      )
      public class AOPDeployment
      


        • 1. Re: Updated Codebase

           

          "adrian@jboss.org" wrote:

          Anyway its easy to fix. You just need to be able to specify additional
          root classes when creating the schema, e.g.


          When I say it is easy to fix, I mean the feature is trivial to implement.
          Don't try it yet since it doesn't exist. ;-)

          • 2. Re: Updated Codebase

             

            "adrian@jboss.org" wrote:

            There's still some failures in the tests (I haven't run the aop-mc-int tests,
            I already know they are broken because Kabir hasn't finished ;-)


            If this proves to be a big stumbling block, we can always revert the config
            in SingleSchemaBIndingResolver for aop-beans.

            • 3. Re: Updated Codebase

               

              "adrian@jboss.org" wrote:
              "adrian@jboss.org" wrote:

              There's still some failures in the tests (I haven't run the aop-mc-int tests,
              I already know they are broken because Kabir hasn't finished ;-)


              If this proves to be a big stumbling block, we can always revert the config
              in SingleSchemaBIndingResolver for aop-beans.


              Actually, Kabir has two versions. SingletonSchemaBindingResolver was
              defining the wrong one.
              But that still doesn't fix the reliance-rules tests because he doesn't
              have a lifecycle-describe binding in the real version yet. ;-)

              • 4. Re: Updated Codebase

                 

                "adrian@jboss.org" wrote:

                * Policy tests (expected)


                I've fixed the policy parsing.

                • 5. Re: Updated Codebase

                   

                  "adrian@jboss.org" wrote:

                  * Alias tests (expected)


                  I've fixed this so now the testsuite is back at 100% for Kernel!!! :-)

                  I've reworked the way aliases are parsed.
                  Instead of the crippled:
                  <alias class="whatever">cant do much</alias>
                  


                  you can now do
                  <alias><javabean ...></alias>
                  


                  NO POINT RE-INVENTING THE WHEEL :-)

                  Which means you can parse anything you like,
                  it still seems pointless as feature to me. ;-)

                  However, to make it work, I had to put a horrible hack in the AbstractKernelControllerContext, because the aliases need to be determined
                  early and the basic BeanMetaData only accepts plain Objects.

                  
                   /**
                   * Determine the aliases
                   *
                   * @return the aliases
                   */
                   private static Set<Object> determineAliases(BeanMetaData metaData)
                   {
                   if (metaData == null)
                   return null;
                  
                   // FIXME THIS IS HACK
                   if (metaData instanceof AbstractBeanMetaData)
                   {
                   AbstractBeanMetaData abmd = (AbstractBeanMetaData) metaData;
                   Set<AliasMetaData> aliasMetaDatas = abmd.getAliasMetaData();
                   if (aliasMetaDatas != null && aliasMetaDatas.isEmpty() == false)
                   {
                   Set<Object> aliases = abmd.getAliases();
                   if (aliases == null)
                   {
                   aliases = new HashSet<Object>();
                   abmd.setAliases(aliases);
                   }
                   for (AliasMetaData aliasMetaData : aliasMetaDatas)
                   aliases.add(aliasMetaData.getAliasValue());
                   }
                   }
                   return metaData.getAliases();
                   }
                  


                  I'd suggest that if we are going to continue to support AliasMetaData
                  then BeanMetaData becomes
                  - Set<Object> getAliases();
                  + Set<AliasMetaData> getAliases();
                  


                  Personally, I'd rather just drop it and have aliases as plain strings in the xml. ;-)