3 Replies Latest reply on Jan 17, 2007 10:13 AM by Adrian Brock

    Recent changes Microcontainer

    Adrian Brock Master

      isAssignable/Progression

      This logic needs moving into the TypeInfo abstraction, see the TODO
      I added to the code. isProgression is just a special form isAssignable.

      For now I've fixed the failing tests (that don't provide a classloader)
      by stealing it from the bean's class.

      Builder

      I've refactored the builder so the main entry point is part of the spi.
      I moved the implementation into its own package so it doesn't get confused
      as implementation of the metadata itself.

      I also removed the use of reflection and made the impl type safe.
      We have to use reflection sometimes because we don't know the types
      or "joinpoints" at compile time, but using reflection bypasses compiler checks
      which means you only find out it is broken at runtime, so we should avoid it
      where it is possible.

      Finally, the builder needs some tests. One of my "laws of programming"
      is "If it isn't tested, it doesn't work" :-)

        • 1. Re: Recent changes Microcontainer
          Ales Justin Master

           

          "adrian@jboss.org" wrote:
          isAssignable/Progression

          This logic needs moving into the TypeInfo abstraction, see the TODO
          I added to the code. isProgression is just a special form isAssignable.

          For now I've fixed the failing tests (that don't provide a classloader)
          by stealing it from the bean's class.


          How do I get a TypeInfo from String typeName and ClassLoader in Configurator?

          Configurator.isAssignable() ...
          
          if (typeNames[j] != null)
          {
           TypeInfo info = null; // TODO - use typeNames[j] and cl
           if (typeInfos[j].isAssignableFrom(info) == false)
           {
           return false;
           }
          }
          


          • 2. Re: Recent changes Microcontainer
            Ales Justin Master

            Using KernelConfigFactory to get KernelConfig (which can provide this)?

            Putting KernelConfig instance into Configurator?
            It's a 'loop' usage. Looks wrong.

            I see we are already using KernelConfig as a parameter.
            Doing it the same here (adding it as a parameter in resolveProperty method)?
            If I do this (just tried), then almost every method in Configurator needs it. Yuck.

            Any other ways / ideas?

            • 3. Re: Recent changes Microcontainer
              Adrian Brock Master

               

              "alesj" wrote:
              Using KernelConfigFactory to get KernelConfig (which can provide this)?

              Putting KernelConfig instance into Configurator?
              It's a 'loop' usage. Looks wrong.

              I see we are already using KernelConfig as a parameter.
              Doing it the same here (adding it as a parameter in resolveProperty method)?
              If I do this (just tried), then almost every method in Configurator needs it. Yuck.

              Any other ways / ideas?


              It is the KernelConfigurator that has this information.

              The problem is that the current code uses a static singleton as a delegate
              AbstractKernelConfigurator -> Configurator
              so one way to fix would be to move the code to the AbstractKernelConfigurator
              that needs kernel specific config.

              Perhaps a simpler solution is to expose the TypeInfoFactory on the TypeInfo interface.

              You would then be able to do
              TypeInfoFactory typeInfoFactory = beanInfo.getClassInfo().getTypeInfoFactory();
              TypeInfo typeInfo = typeInfoFactory.getTypeInfo(name, classLoader);