6 Replies Latest reply on May 31, 2005 4:05 PM by Adrian Brock

    An injection wiring scenario

    Scott Stark Master

      Do we have all the pieces in place for this scenario:

      - A named pojo instance (in its most strict form this could be a singleton) that has two Properties maps attributes
      + The pojo has methods to manipulating the Properties contents
      + The pojo has these methods exposed via JMX

      - Another pojo needs the named pojo instance Properties maps injected to function correctly. This pojo only has a default ctor, and the only point for injecting the Properties maps is this initialize method:

       public void initialize(Subject subject, CallbackHandler callbackHandler,
       Map sharedState, Map options)
      


      The Properties should be found in the options argument under the keys "users" and "roles". However, by the time the initialize method is called, the options Map is a read-only object.

      Do we have a framework that can acomplish this wiring yet?


        • 1. Re: An injection wiring scenario
          Adrian Brock Master

           

          "scott.stark@jboss.org" wrote:
          Do we have all the pieces in place for this scenario:

          - A named pojo instance (in its most strict form this could be a singleton) that has two Properties maps attributes
          + The pojo has methods to manipulating the Properties contents
          + The pojo has these methods exposed via JMX


          Yes


          - Another pojo needs the named pojo instance Properties maps injected to function correctly. This pojo only has a default ctor, and the only point for injecting the Properties maps is this initialize method:

           public void initialize(Subject subject, CallbackHandler callbackHandler,
           Map sharedState, Map options)
          


          The Properties should be found in the options argument under the keys "users" and "roles". However, by the time the initialize method is called, the options Map is a read-only object.

          Do we have a framework that can acomplish this wiring yet?


          No. Do we really want to support an xml scripting language in the configuration?

          Complicated/Programmatic config like this can be handled by "lifecycle advices".
          I'd guess in this case it would be "create"? But it could also be
          construction or any other joinpoint.

          i.e.
          advice depends upon properties (or named pojo)
          "another" depends upon advice

          • 2. Re: An injection wiring scenario
            Scott Stark Master

            By wiring I did not mean that it had to be strictly via configuration level constructs between the two pojos. There actually is a natural point for joining these before having to deal with the initialize() method. The usecase here is a login configuration with a login module that may take its options from a static configuration, or injection of another object's attributes.

            static:

             <application-policy name="testXMLLoginModule">
             <authentication>
             <login-module code="SomeLoginModule" flag="required">
             <module-option name="users">
             <lm:users xmlns:lm="urn:jboss:jaas">
             <lm:user name="user1" password="pass1" />
             <lm:user name="user2" password="pass2" />
             </lm:users>
             </module-option>
             <module-option name="roles">
             <lm:roles xmlns:lm="urn:jboss:jaas">
             <lm:user name="user1">
             <lm:role name="Role1"/>
             <lm:role name="Role2"/>
             <lm:role name="callerJduke" group="CallerPrincipal" />
             </lm:user>
             </lm:users>
             </module-option>
            ...
            


            injection:
             <application-policy name="testXMLLoginModule2">
             <authentication>
             <login-module code="SomeLoginModule" flag="required">
             <module-option name="users">
             <depends name="PropertiesSource" property="Users" />
             </module-option>
             <module-option name="roles">
             <depends name="PropertiesSource" property="Roles" />
             </module-option>
            ...
            




            • 3. Re: An injection wiring scenario
              Adrian Brock Master

              Ok, so you just want to inject a bean's property rather than the bean value.

              The only way this could be done with the current metadata model would
              be to put a dummy factory inbetween that did the getting.

              But this seems such a trivial usecase that I don't see why it could not be supported
              directly.

              In MC XML (note the property attribute is what we are talking about and is not currently supported)

              <property name="roles">
               <inject bean="PropertiesSource" property="roles" />
              </property>
              


              Whether we want to go further into xml scripting is another issue, e.g.
               <inject bean="PropertiesSource" script="getRoles().toString()" />
               <inject bean="PropertiesSource" script="getRoles().get("Value1"))" />
               // transient property PropertiesSource.getRoles().getSize()
               <inject bean="PropertiesSource" property="roles.size" />
               etc.
              


              Including "abitrary" initialize methods could also be supported
              with something like
               <depends>
               <create method="initialize">
               <parameter><inject bean="PropertiesSource" property="roles"/></parameter>
               </create>
              


              One problem with the latter (besides it fails the 95%/5% use case rule)
              is that the annotation version requires parameter annotations
              (although it isn't something you want to do in this case :-)

              @CreateLifecycle
              public void initialize(
              @Inject(bean="PropertiesSource", property="users")
              Map users,
              @Inject(bean="PropertiesSource", property="roles")
              Map roles
              )
              {
              // Do it
              }
              


              • 4. Re: An injection wiring scenario
                Adrian Brock Master

                I'd only anticapted supporting lifecycle methods with no arguments.

                • 5. Re: An injection wiring scenario
                  Adrian Brock Master

                  I just added support for the property injection, passing parameters in lifecycle operations
                  will come soon...

                  Commit message:

                  Add support for injecting a property of a bean rather than a bean,
                   e.g.
                   <bean name="MyService" class="MyClass">
                   <property name="transactionManager">
                   <inject bean="TransactionManagerService" property="instance"/>
                   </property>
                   </bean>
                   or
                   MyClass.setTransactionManager(TransactionManagerService.getInstance());
                  
                   This also works anywhere there is an injection, i.e. properties, factories,
                   parameters, collections, etc.
                  


                  • 6. Re: An injection wiring scenario
                    Adrian Brock Master

                    The ability to override lifecycle methods is now supported.

                    e.g. rather than doing

                    <bean>
                     <depends>SomeName</depends>
                    </bean>
                    


                    You can now do
                    public void initialize(SomeBean bean)
                    {
                    // etc.
                    }
                    <bean>
                     <create method="initialize">
                     <parameter><inject bean="SomeName"></parameter>
                     </create>
                    </bean>
                    


                    Of course, other parameters such as plain values, collections, bean properties
                    are also supported.