7 Replies Latest reply on Oct 24, 2008 9:32 AM by Andrew Rubinger

    Kill Default Remote Binding if 1+ @RemoteBinding is specifie

    Andrew Rubinger Master

      The current implementation treats @RemoteBinding as an additional binding to the defaults. This makes for a situation that may present collisions.

      Given:

      @Stateless(name="MyBean")
      @Remote(MyRemote.class)
      @RemoteBinding(jndiBinding="MyBean")
      class MyBean{...}


      Right now this would produce:

      /MyBean - Explicit from @RemoteBinding
      /MyBean/remote - Default Remote Business Interface Proxy Binding


      ...this makes for a CCE when attempting a Context.bind() on the 2nd entry because "MyBean" would not be a subcontext.

      So I'm going to make a rule that says:

      "If at least one @RemoteBinding is specified, then the default remote business interface binding will not be applied."

      Anyone see problems w/ this approach?

      S,
      ALR

        • 2. Re: Kill Default Remote Binding if 1+ @RemoteBinding is spec
          jaikiran pai Master

           

          "ALRubinger" wrote:

          Given:

          @Stateless(name="MyBean")
          @Remote(MyRemote.class)
          @RemoteBinding(jndiBinding="MyBean")
          class MyBean{...}


          Right now this would produce:

          /MyBean - Explicit from @RemoteBinding
          /MyBean/remote - Default Remote Business Interface Proxy Binding




          From what i had seen this far, if @RemoteBinding was specified, the the default binding would not be done. Let me give this a try again and see if i am mistaken.


          • 3. Re: Kill Default Remote Binding if 1+ @RemoteBinding is spec
            jaikiran pai Master

             

            "jaikiran" wrote:

            From what i had seen this far, if @RemoteBinding was specified, the the default binding would not be done. Let me give this a try again and see if i am mistaken.



            For this bean:

            
            @Stateless
            @Remote (UserManagerRemote.class)
            @RemoteBinding (jndiBinding = "RemoteUserManagerBean")
            public class UserManagerBean implements UserManagerLocal, UserManagerRemote {


            deployed in ZEJB3Persistence.ear, this is what i see in JNDIView

            +- ZEJB3Persistence (class: org.jnp.interfaces.NamingContext)
             | +- UserManagerBean (class: org.jnp.interfaces.NamingContext)
             | | +- local-org.myapp.ejb.UserManagerLocal (class: Proxy for: org.myapp.ejb.UserManagerLocal)
             | | +- remote-org.myapp.ejb.UserManagerRemote (class: Proxy for: org.myapp.ejb.UserManagerRemote)
             +- RemoteUserManagerBean (class: Proxy for: org.myapp.ejb.UserManagerRemote)


            So i don't see that when the @RemoteBinding is specified, the Default binding too is done. I am on JBoss-5 CR2. I haven't tested this on Trunk.

            • 4. Re: Kill Default Remote Binding if 1+ @RemoteBinding is spec
              jaikiran pai Master

              I now understand how to reproduce this. Your workaround description in that JIRA issue helped me reproduce this issue :-)

              So i changed my bean to:

              @Stateless
              @Remote (UserManagerRemote.class)
              @RemoteBinding (jndiBinding = "ZEJB3Persistence/UserManagerBean")
              public class UserManagerBean implements UserManagerLocal, UserManagerRemote {


              The ZEJB3Persistence is the name of my EAR file in which this bean is deployed.

              And it fails during deploy time with CCE (on CR2 and trunk) as you mentioned. But from what i see, it fails while binding the business interface specific proxies at ZEJB3Persistence/UserManagerBean/remote-org.myapp.ejb.UserManagerRemote and not the default business proxy.


              • 5. Re: Kill Default Remote Binding if 1+ @RemoteBinding is spec
                Carlo de Wolf Master

                What happens if:

                @Stateless(name="MyBean")
                @Local(MyLocal.class)
                @Remote(MyRemote.class)
                @RemoteBinding(jndiBinding="MyBean")
                class MyBean{...}


                • 6. Re: Kill Default Remote Binding if 1+ @RemoteBinding is spec
                  Andrew Rubinger Master

                   

                  "jaikiran" wrote:
                  So i don't see that when the @RemoteBinding is specified, the Default binding too is done. I am on JBoss-5 CR2


                  That's because in CR2 the rule was incorrect:

                  * Take JBossSessionBeanMetaData.getRemoteBindings()[]0] (First entry)
                  * If there, replace the default remote business binding

                  This didn't account for N bindings.

                  S,
                  ALR

                  • 7. Re: Kill Default Remote Binding if 1+ @RemoteBinding is spec
                    Andrew Rubinger Master

                     

                    "wolfc" wrote:
                    What happens if:
                    @Stateless(name="MyBean")
                    @Local(MyLocal.class)
                    @Remote(MyRemote.class)
                    @RemoteBinding(jndiBinding="MyBean")
                    class MyBean{...}


                    I thought of something similar to this after going to bed last night.

                    We need to reserve the namespace used by default bindings. Your example above shows a collision:

                    MyBean - Explicit from MyBean
                    MyBean/local - Default Local Business


                    ...but also there's the stuff under the namespace:

                    MyBean/remote-MyRemote.class


                    So the rule's gotta be twofold:

                    * If at least 1 @RemoteBinding is specified, skip binding of default remote business location
                    * @LocalBinding and @RemoteBinding must not interfere with the namespace

                    This is all dependent upon the binding namespace; I'm assuming a JAR packaging above. In an EAR this all becomes prefixed w/ "[earName/".

                    Keep in mind that the idea of a "namespace" is provided by our implementation details ie. BasicJndiBindingPolicy, and other JNDI Binding Policies may not have this restriction. So we cannot validate against the namespace itself as a validation check; we'd have to validate all of the targeted JNDI bindings against each other to check for conflicts. Skipping the validation check just throws a CCE from Context.bind, which doesn't tell the user too much.

                    S,
                    ALR