4 Replies Latest reply on Mar 7, 2008 2:13 PM by Adrian Brock

    Reflection and MetaDataRepository refactoring

    Adrian Brock Master

      The devil is always in the detail ;-)

      I've found a couple of other wrong dependencies while splitting out this code.

      The first is the ArrayInfo using the Signature class from the metadata repository
      to determine primitive array class information.
      This should clearly be delegating to PrimitiveInfo in both cases.

      The second is this horrible method in BeanInfo

       /**
       * Bean may have additional dependencies
       * that the kernel cannot initially resolve. (currently defined by ClassAdapter)
       *
       * @param metaData the metadata
       * @return the list of dependencies
       */
       List<DependencyBuilderListItem<?>> getDependencies(MetaData metaData);
      


      This has always bothered me since we first started the aop integration.
      It doesn't really belong there. It's really part of the Kernel api.

      The original intention isn't even used (instance ClassAdapters for AOP
      instance containers).

      And the latest rev has some horrible opaque type which is seen here in
      the
      <?>
      which is actually the KernelControllerContext.

      The issue came up again since it causes jboss-reflection to be based
      on the metadata repository for no logical reason.

      I'm finally going to bite the bullet and move this api to the kernel project
      and remove all reference to the DependencyBuilder from the reflection project.

      Like I said only aop-mc-int implements it and then only from the MC Pojo lifecycle.

        • 1. Re: Reflection and MetaDataRepository refactoring
          Adrian Brock Master

          Additionally, the DependencyBuilderListItem also needs a removeDependency()
          method, but I'll take that up with Kabir seperately.

          He needs to write a proper test for redeploying changing aop dependencies
          without undeploying the bean which will show why this a problem.

          • 2. Re: Reflection and MetaDataRepository refactoring
            Adrian Brock Master

            Since this has been more work than I thought, I'm going to do
            beta10 releases of these projects and validate it integrates back into the
            microcontainer, aop and jbossxb projects before doing the CR1s.

            • 3. Re: Reflection and MetaDataRepository refactoring
              Adrian Brock Master

              I'm well behind schedule on this :-(

              I thought it would take me a couple of hours on Monday and most of that
              would maven problems ;-)

              Anyway its been a good excercise none the less,
              because I've found and fixed a lot of problems that I wouldn't otherwise have known existed.

              • 4. Re: Reflection and MetaDataRepository refactoring
                Adrian Brock Master

                Tomorrow I'm going to upgrade the MC project to
                the new jboss-reflection and jboss-mdr projects.

                Unfortunately, I didn't catch Alex before he left the office to get approval
                for a jboss-xb release, so I'll do a snapshot until I can speak to him next week.

                I also want to put some JBossXB testsuite support in JBossXB
                so each project doesn't have to write their own jbossxb test harness
                like we do now, so that's probably not a bad thing anyway since it isn't done yet.

                Once I've completed this, the other projects will (hoperfully :-) be lot a easier
                since they are already in a sane state unlike the tangled web that the container
                project had become. ;-)

                We can also remove the schema initialization hacks from our test code
                since that will be provided by JBossXB factory settings.