10 Replies Latest reply on Aug 15, 2006 6:59 AM by Ales Justin

    Bean property inspection and actual injection

    Ales Justin Master

      What should be the right order of property wiring / bean injection?
      XML over @Inject? (as in ejb3)

      Is 'org.jboss.kernel.plugins.injection' right place to put some Injection utils?

      Rgds, Ales

        • 1. Re: Bean property inspection and actual injection
          Adrian Brock Master

          XML should override annotations, yes.

          There should be no "Inject utils".
          All processing on the POJO should be handled by the
          ClassInfo/BeanInfo/Configurator abstraction.

          Although the Configurator needs some tidyup. :-)

          • 2. Re: Bean property inspection and actual injection
            Ales Justin Master

             

            "adrian@jboss.org" wrote:

            Although the Configurator needs some tidyup. :-)


            I rewrote the injection inspection stuff.
            But it is not put into Configurator.

            Should I rewrite it into Configurator or wait for tidyup?

            • 3. Re: Bean property inspection and actual injection
              Adrian Brock Master

              The inspection should come from "reflection abstraction"
              in the container module which is integrated via the
              Configurator/BeanInfo.

              The other parts of the injection is just mapping this to
              the context name via the new dependeny item which will then
              get used in the AbstractDependencyValueMetaData.

              Also your package names are wrong.
              Everything should be either under
              "spi" (contract - definitions) or
              "plugins" (implemementation details/choices)

              Injection is not a part of the general contract.
              It is a part of one possible implementation of the contract,
              i.e. the xml or AbstractDependencyValueMetaData

              The general contract is just the ValueMetaData
              and MetaDataVisitor.

              I do intend in future to define a proper contract
              such that you can more easily "write your own dependency".
              See other threads in this forum.

              • 4. Re: Bean property inspection and actual injection
                Ales Justin Master

                 

                "adrian@jboss.org" wrote:

                With the annotation approach it is your job to create/add an ADVM to the metadata.

                I do intend in future to define a proper contract
                such that you can more easily "write your own dependency".
                See other threads in this forum.


                I'm about to write bean class inspection for property @Inject - which will take place in DescribeAction - and will add PropertyMetaData to existing BeanMetaData (as discused).

                Should I wait for 'I do intend in future to define a proper contract'?

                How to make this more general - handling all kinds of annotations, different injections (not just property, also constructor, collections, ...)?

                • 5. Re: Bean property inspection and actual injection
                  Ales Justin Master

                   

                  "alesj" wrote:

                  How to make this more general - handling all kinds of annotations, different injections (not just property, also constructor, collections, ...)?


                  Sort of BeanAnnotationBinding?
                  Stumbling upon annotation - get the right AnnotationHandler, which can handle property MD creation, constructor MD creation, parameter MD, .... ?

                  • 6. Re: Bean property inspection and actual injection
                    Adrian Brock Master

                     

                    "alesj" wrote:

                    I'm about to write bean class inspection for property @Inject - which will take place in DescribeAction - and will add PropertyMetaData to existing BeanMetaData (as discused).

                    Should I wait for 'I do intend in future to define a proper contract'?


                    No since I've got no idea what that contract is, except
                    that it is a generalization of all the inject/depends/demands
                    such that a specific dependency type can be "plugged in"
                    without having to modify the kernel.
                    e.g. pseudo idea
                    <register dependency="JNDI">
                     <.../> <!-- description of dependency mechanism>
                    </register>
                    
                    <inject bean="Blah" type="JNDI"/>
                    



                    How to make this more general - handling all kinds of annotations, different injections (not just property, also constructor, collections, ...)?


                    Again, I haven't given any thought to it.
                    You can certainly use parameter annotations to describe
                    parameter injections.

                    • 7. Re: Bean property inspection and actual injection
                      Adrian Brock Master

                      What were you trying to fix here?

                      Author: alesj
                      Date: 2006-08-13 12:26:29 -0400 (Sun, 13 Aug 2006)
                      New Revision: 55853
                      
                      Modified:
                       projects/microcontainer/trunk/dependency/src/main/org/jboss/dependency/plugins/AbstractController.java
                       projects/microcontainer/trunk/kernel/src/tests/org/jboss/test/kernel/inject/test/PropertyContextualInjectionTestCase.java
                      Log:
                      AbstractController.allContexts.remove after failure in confiruration phase.
                      Added NullName expected throwable.
                      
                      Modified: projects/microcontainer/trunk/dependency/src/main/org/jboss/dependency/plugins/AbstractController.java
                      ===================================================================
                      --- projects/microcontainer/trunk/dependency/src/main/org/jboss/dependency/plugins/AbstractController.java 2006-08-13 15:45:00 UTC (rev 55852)
                      +++ projects/microcontainer/trunk/dependency/src/main/org/jboss/dependency/plugins/AbstractController.java 2006-08-13 16:26:29 UTC (rev 55853)
                      @@ -443,6 +443,7 @@
                       {
                       log.error("Error installing to " + toState.getStateString() + ": " + context.toShortString(), error);
                       uninstallContext(context, ControllerState.NOT_INSTALLED, trace);
                      + allContexts.remove(context.getName()); //missing if contexts failes during configuration phase
                       errorContexts.add(context);
                       context.setError(error);
                       return false;
                      


                      This breaks the validate() method and makes it impossible
                      to retrieve the error that occurred since the installed context
                      no longer exists. (The controller has lost all reference to it).

                      • 8. Re: Bean property inspection and actual injection
                        Ales Justin Master

                         

                        "adrian@jboss.org" wrote:
                        What were you trying to fix here?

                        This breaks the validate() method and makes it impossible
                        to retrieve the error that occurred since the installed context
                        no longer exists. (The controller has lost all reference to it).


                        When I was running my tests - when my bean threw a throwable - due to multiple matching beans - which was my expected exception.
                        Even after I undeployed this 'multiple matching beans' test deployment that 'failed', my next deployment threw an exception saying that context with this name already existed.

                        • 9. Re: Bean property inspection and actual injection
                          Adrian Brock Master

                           

                          "adrian@jboss.org" wrote:
                          What were you trying to fix here?


                          The real problem was in AbstractKernelDeployer.undeployBean()
                          not uninstalling beans that were in error.
                          I've corrected this, so your test works now.