12 Replies Latest reply on Sep 18, 2008 9:02 AM by jaikiran

    JNDI Bindings

    alrubinger

      I'd like to nail down JNDI Bindings at the EJB level, interface level, etc for GA.

      We'd discussed this previously in http://www.jboss.com/index.html?module=bb&op=viewtopic&t=139843

      S,
      ALR

        • 1. Re: JNDI Bindings
          jaikiran

           

          "ALRubinger" wrote:

          So I read many @RemoteBindings as targeted to expose any N number of bindings for the Default Business Interface Proxy.

          So if we have:

          @RemoteBinding(jndiBinding="Busi1")
          public interface MyBusinessInterface1{...}
          
          @RemoteBinding(jndiBinding="Busi2")
          public interface MyBusinessInterface2{...}
          
          public interface MyBusinessInterface3{...}
          
          @Stateless
          @RemoteBindings({
           @RemoteBinding(jndiBinding="MyBean")
           @RemoteBinding(jndiBinding="MySSLBean", clientBindUrl="sslsocket://0.0.0.0:3843")
          })
          public class MyBean implements MyBusinessInterface1, MyBusinessInterface2, MyBusinessInterface3{...}


          ..then we've defined @RemoteBindings at both the interface and EJB level. As a user I'd expect to find in the JNDI Tree:

          + Busi1 (Proxy implements MyBusinessInterface1)
          + Busi2 (Proxy implements MyBusinessInterface2)
          + MyBean (Proxy implements MyBusinessInterface1, MyBusinessInterface2, MyBusinessInterface3)
          + MySSLBean ((Proxy implements MyBusinessInterface1, MyBusinessInterface2, MyBusinessInterface3) < Exposes SSL Transport


          This way, an interface-targeted JNDI Binding is specified at the interface level, and any @RemoteBinding(s) on the class level apply to all Remote Business Interfaces. And it'd require no API changes.



          Going by what we are suggesting here, it looks like we are trying to provide an option for the bean developer to specify multiple bindings for the default business interface proxy.

          1) One of the possible reasons, that i can think of, why the bean developer would want to do this is to provide a different transport to use. Is there any other valid reason why the developer would want to do this?

          2) Does this multiple bindings apply on to Remote business interfaces? Is there any specific reason why the same reasoning can't be used to have something like @LocalBindings?


          • 2. Re: JNDI Bindings
            alrubinger

             

            "jaikiran" wrote:
            1) One of the possible reasons, that i can think of, why the bean developer would want to do this is to provide a different transport to use. Is there any other valid reason why the developer would want to do this?


            The most pressing reason is the transport.

            I'm sure app developers could come up with a reason for many equivalent bindings - maybe they're migrating to a new JNDI name scheme and want to keep the old for backwards-compatibility?

            "jaikiran" wrote:
            2) Does this multiple bindings apply on to Remote business interfaces? Is there any specific reason why the same reasoning can't be used to have something like @LocalBindings?


            Yes, I'm in favor of adding N Local Bindings support. What's interesting is that there's no backing metadata model (ie. LocalBindingMetaData) for this.

            S,
            ALR

            • 3. Re: JNDI Bindings
              jaikiran

               

              "ALRubinger" wrote:

              I'm sure app developers could come up with a reason for many equivalent bindings - maybe they're migrating to a new JNDI name scheme and want to keep the old for backwards-compatibility?


              Makes sense.

              "ALRubinger" wrote:

              What's interesting is that there's no backing metadata model (ie. LocalBindingMetaData) for this.



              Yeah, i had noticed that some time back. But wasn't sure why it wasn't available.

              • 4. Re: JNDI Bindings
                jaikiran

                Andrew,

                Currently i think we are not considering the mappedName attribute on the @Stateless annotation (i think i had tried this on Beta4, not sure of CR1). From what i see of the javadocs of @Stateless:


                mappedName:
                A product specific name(e.g. global JNDI name) that this session bean should be mapped to.


                So if a developer specifies a mappedName for the bean, do we have plans to support that too?



                • 5. Re: JNDI Bindings
                  jaikiran

                   

                  "jaikiran" wrote:
                  Andrew,

                  Currently i think we are not considering the mappedName attribute on the @Stateless annotation



                  I used Stateless bean just as an example. In general, i am talking about beans having the mappedName attribute.




                  • 6. Re: JNDI Bindings
                    alrubinger

                    The following should be treated equally:

                    * @Stateful/@Stateless/@WhateverEJB.mappedName (or XML equivalent)
                    * jndi-name (jboss.xml)
                    * @RemoteBinding.jndiName

                    The question is, what to do in case of conflict?

                    @Stateless(mappedName="MyBean")
                    class MyEJB{...}


                    ejb-jar.xml:
                    <mappedName>MyBeanInSpecXML</mappedName>


                    jboss.xml:
                    <jndiName>MyBeanInJBossXML</jndiName>


                    I say make these additive (little harm in unintentional extra bindings). The fail-fast would be to throw an error.

                    S,
                    ALR

                    • 7. Re: JNDI Bindings
                      jaikiran

                       

                      "ALRubinger" wrote:

                      I say make these additive (little harm in unintentional extra bindings). The fail-fast would be to throw an error.



                      From what i know of some of the annotations for beans and their corresponding XML equivalent, the XML equivalent in the deployment descriptors is treated as an override for annotations. So is this an option too, to be consistent with the behaviour of other annotations and their equivalent XML?




                      • 8. Re: JNDI Bindings
                        starksm64

                         

                        "ALRubinger" wrote:

                        I say make these additive (little harm in unintentional extra bindings). The fail-fast would be to throw an error.

                        Additive meaning create duplicate bindings? The metadata processing should already be treating mappedName annotation as being overriden by the jboss jndi-name. We don't have an xml form for @RemoteBinding.jndiName do we?

                        • 9. Re: JNDI Bindings
                          alrubinger

                          Brain melt. Just realized I hadn't considered overrides (XML overrides Annotations)...

                          So that'll require some more thought. :)

                          S,
                          ALR

                          • 10. Re: JNDI Bindings
                            alrubinger

                             

                            "scott.stark@jboss.org" wrote:
                            Additive meaning create duplicate bindings? The metadata processing should already be treating mappedName annotation as being overriden by the jboss jndi-name. We don't have an xml form for @RemoteBinding.jndiName do we?


                            Ah, I wasn't aware jboss.xml "jndi-name" overrides spec "mappedName".

                            No, we've got no XML @RemoteBinding equiv, or way of specifying more than one (ie JNDI Name) in XML. This was probably not the original intent, but @RemoteBinding as it stands tangles:

                            * JNDI Targets
                            * clientBindUrl (invokerLocator and protocol)
                            * Interceptor Stack
                            * Proxy Factory

                            TBH, I'm not even sure which of those are currently supported.

                            ...so I'm starting to wonder about this notion of creating duplicate bindings. The waters get murky and confusing either way, and I want to provide the most intuitive mechanism we can (with much better logging). JNDI problems are at the top of the gripes of new users.

                            Also related (noted before) is the absence of LocalBindingMetaData/LocalBindingsMetaData.

                            S,
                            ALR

                            • 11. Re: JNDI Bindings
                              wolfc

                              From an EJB3 perspective jboss.xml jndi-name is deprecated, mapped-name should be used instead.

                              You can have remote-binding elements in the descriptor and these can have jndi-name. They're under a session element.

                              We should really have a remote binding bindings (hmm) in the assembly element. Then you can re-use the annotated remote bindings or completely override them (with jndi-name being the identifier).

                              • 12. Re: JNDI Bindings
                                jaikiran

                                 

                                "wolfc" wrote:

                                You can have remote-binding elements in the descriptor and these can have jndi-name. They're under a session element.



                                Is this currently available? The jboss_5_0.dtd http://www.jboss.org/j2ee/dtd/jboss_5_0.dtd does not mention this