10 Replies Latest reply on May 13, 2009 9:12 AM by alesj

    Naming, @JNDI and OnDemand

    alesj

      WRT
      - initial ml post: http://lists.jboss.org/pipermail/jboss-development/2008-November/012997.html
      - the latest ml post (where Adrian moves his code to svn): http://lists.jboss.org/pipermail/jboss-development/2009-May/014341.html

      A few questions after checking the code.
      (1)

      /**
       * JNDI.
       *
       * TODO move to AS integration project
       * @author <a href="adrian@jboss.com">Adrian Brock</a>
      

      Where exactly would you wanna move this?
      What should we do with "duplicated" @JndiBinding in AOP-MC-int?

      (2) Why do we have two diff impls of AbstractJNDILifecycleCallback, when they do exactly the same?

      (3) Basically the OnDemand test is completely broken. :-)

      By default it was passed an AUTOMATIC mode,
      which meant it was never really On_Demand.

      Once I fixed this, there is this problem with @JNDI and On_Demand.
      @JNDI matches AOP lifecycle, which needs a _real_ state (not Not_Installed) in order to kick in.
      Whereas the OnDemand beans just stay at Not_Installed,
      meaning they will not get "intercepted" by @JNDI lifecycle hooks until they move fwd.

      What to do? :-)
      (a) have OnDemand stay in Pre_Install
      (b) add extra Not_Installed AOP lifecycle hook



        • 1. Re: Naming, @JNDI and OnDemand
          alesj

           

          "alesj" wrote:

          What to do? :-)
          (a) have OnDemand stay in Pre_Install

          PreInstall is too soon, as we don't have the MetaData fully populated till then.
          e.g. we only know how to match @JNDI with AOP lifecycle in Described state

          While moving aop lifecycle to describe
           <lifecycle-describe xmlns="urn:jboss:aop-beans:1.0"
           name="JNDIPreInstallAdvice"
           class="org.jboss.naming.microcontainer.JNDIOnDemandLifecycleCallback"
           classes="@org.jboss.naming.microcontainer.JNDI">
           </lifecycle-describe>
          

          and this hack
           KernelControllerContext context = getControllerContext("Test", ControllerState.NOT_INSTALLED);
           change(context, ControllerState.DESCRIBED);
           assertBinding("Test", "Hello");
          

          then the OnDemand test works.


          • 2. Re: Naming, @JNDI and OnDemand
            alesj

             

            "alesj" wrote:

            (2) Why do we have two diff impls of AbstractJNDILifecycleCallback, when they do exactly the same?

            Stupid question, disregard it. :-)

            • 3. Re: Naming, @JNDI and OnDemand
              alesj

               

              "alesj" wrote:

              What to do? :-)
              (a) have OnDemand stay in Pre_Install
              (b) add extra Not_Installed AOP lifecycle hook

              As seen, none of these two will work.
              Only moving On_Demand to Describe will work,
              but that defeats the purpose of On_Demand.

              The only solution I can think of right now are explicit instructions
              to put On_Demand bean into JNDI.
              e.g.
              <jndi-on-demand bean="some-existing-bean" ...
              

              with a programmatic/api support as well.

              For non On_Demand beans the @JNDI will work.

              • 4. Re: Naming, @JNDI and OnDemand

                 

                "alesj" wrote:
                "alesj" wrote:

                What to do? :-)
                (a) have OnDemand stay in Pre_Install
                (b) add extra Not_Installed AOP lifecycle hook

                As seen, none of these two will work.
                Only moving On_Demand to Describe will work,
                but that defeats the purpose of On_Demand.


                Why does it defeat the purpose of "On Demand"?

                The idea of On Demand is to not create the bean, we can still look at its metadata
                and see what we would do if we were to construct it and activate it.

                That's why it is called "Described" and its where "On Demand" originally left things
                until "PreInstall" was introduced.

                • 5. Re: Naming, @JNDI and OnDemand
                  alesj

                   

                  "adrian@jboss.org" wrote:

                  Why does it defeat the purpose of "On Demand"?

                  I thought it was meant to do *nothing*. :-)

                  "adrian@jboss.org" wrote:

                  That's why it is called "Described" and its where "On Demand" originally left things until "PreInstall" was introduced.

                  Really?

                  Hmmm, I though our PreInstall didn't change things.
                  Or why we now leave them in Not_Installed?

                  • 6. Re: Naming, @JNDI and OnDemand

                     

                    "alesj" wrote:
                    WRT
                    - initial ml post: http://lists.jboss.org/pipermail/jboss-development/2008-November/012997.html
                    - the latest ml post (where Adrian moves his code to svn): http://lists.jboss.org/pipermail/jboss-development/2009-May/014341.html

                    A few questions after checking the code.
                    (1)
                    
                    /**
                     * JNDI.
                     *
                     * TODO move to AS integration project
                     * @author <a href="adrian@jboss.com">Adrian Brock</a>
                    

                    Where exactly would you wanna move this?
                    What should we do with "duplicated" @JndiBinding in AOP-MC-int?


                    We need a standard annotation that is provided independent of the implementation.
                    AS integration project is here:
                    http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/integration/
                    as previously discussed on the dev list it is supposed to allow users to not have to
                    worry about the implemementations of how it is actually implemented.
                    e.g. in maven you import org.jboss.integration:naming not jnpserver or aop.


                    (3) Basically the OnDemand test is completely broken. :-)


                    I said it was largely untested, but you were in a hurry for me to commit it. :-)


                    • 7. Re: Naming, @JNDI and OnDemand

                       

                      "alesj" wrote:

                      "adrian@jboss.org" wrote:

                      That's why it is called "Described" and its where "On Demand" originally left things until "PreInstall" was introduced.

                      Really?

                      Hmmm, I though our PreInstall didn't change things.
                      Or why we now leave them in Not_Installed?


                      We'll maybe I'm dreaming and didn't actually implement it properly (yet ;-)

                      The same issue is also required for this feature:
                      https://jira.jboss.org/jira/browse/JBMICROCONT-78
                      where an "on demand" pojo is registered in JMX before the instance exists
                      with a simple mbean that just has a "start" operation until you click/invoke it
                      to create the real pojo.

                      You aren't going to know whether to register it in JMX unless you've looked
                      at the annotations (both instance and class) which happens in the describe stage.

                      • 8. Re: Naming, @JNDI and OnDemand
                        alesj

                         

                        "adrian@jboss.org" wrote:

                        We need a standard annotation that is provided independent of the implementation.
                        AS integration project is here:
                        http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/integration/
                        as previously discussed on the dev list it is supposed to allow users to not have to
                        worry about the implemementations of how it is actually implemented.
                        e.g. in maven you import org.jboss.integration:naming not jnpserver or aop

                        Sure, the only problem I see is that we can end up with 1M sub-projects containing a single @annotation.

                        Perhaps some common integration annotations should be under the same sub-project.
                        e.g. org.jboss.integration:api or org.jboss.integration:annotations

                        • 9. Re: Naming, @JNDI and OnDemand
                          alesj

                           

                          "adrian@jboss.org" wrote:

                          We'll maybe I'm dreaming and didn't actually implement it properly (yet ;-)

                          I guess we need something like this:
                          Index: dependency/src/main/java/org/jboss/dependency/plugins/AbstractController.java
                          ===================================================================
                          --- dependency/src/main/java/org/jboss/dependency/plugins/AbstractController.java (revision 88788)
                          +++ dependency/src/main/java/org/jboss/dependency/plugins/AbstractController.java (working copy)
                          @@ -726,8 +726,9 @@
                           }
                           }
                          
                          - if (ControllerMode.AUTOMATIC.equals(context.getMode()))
                          - context.setRequiredState(ControllerState.INSTALLED);
                          + // set the required state
                          + ControllerMode mode = context.getMode();
                          + context.setRequiredState(mode.getRequiredState());
                          
                           if (trace)
                           log.trace("Installing " + context.toShortString());
                          Index: dependency/src/main/java/org/jboss/dependency/spi/ControllerMode.java
                          ===================================================================
                          --- dependency/src/main/java/org/jboss/dependency/spi/ControllerMode.java (revision 88788)
                          +++ dependency/src/main/java/org/jboss/dependency/spi/ControllerMode.java (working copy)
                          
                           public enum ControllerMode
                           {
                          - AUTOMATIC("Automatic"),
                          - @XmlEnumValue("On Demand") ON_DEMAND("On Demand"),
                          + AUTOMATIC("Automatic", ControllerState.INSTALLED),
                          + @XmlEnumValue("On Demand") ON_DEMAND("On Demand", ControllerState.DESCRIBED),
                           MANUAL("Manual"),
                           DISABLED("Disabled"),
                           ASYNCHRONOUS("Asynchronous");
                          @@ -46,6 +47,9 @@
                           /** The mode string */
                           private final String modeString;
                          
                          + /** The required state */
                          + private ControllerState requiredState;
                          +
                           /**
                           * Create a new mode
                           *
                          @@ -53,9 +57,18 @@
                           */
                           private ControllerMode(String modeString)
                           {
                          + this(modeString, null);
                          + }
                          +
                          + private ControllerMode(String modeString, ControllerState requiredState)
                          + {
                           if (modeString == null)
                           throw new IllegalArgumentException("Null mode string");
                          + if (requiredState == null)
                          + requiredState = ControllerState.NOT_INSTALLED;
                          +
                           this.modeString = modeString;
                          + this.requiredState = requiredState;
                           }
                          
                           /**
                          @@ -87,6 +100,16 @@
                           return modeString;
                           }
                          
                          + /**
                          + * The required state.
                          + *
                          + * @return the required state
                          + */
                          + public ControllerState getRequiredState()
                          + {
                          + return requiredState;
                          + }
                          +
                          


                          • 10. Re: Naming, @JNDI and OnDemand
                            alesj

                             

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

                            We'll maybe I'm dreaming and didn't actually implement it properly (yet ;-)

                            I guess we need something like this:

                            https://jira.jboss.org/jira/browse/JBMICROCONT-431