9 Replies Latest reply on Mar 27, 2006 2:48 PM by epstein

    Are EJB3 Stateless Session beans as boneheaded as they look?

    epstein

      OK, now that the flame baits out of the way.... Following the EJB3 trail I read:

      <<Since the container-generated stub object routes the call from the client to the service object, the client does not need to know the actual implementation class of the bean inside the container.>>

      OK, sounds reasonable and might even be 1/2 as useful as old-fashioned Objective-C / SmallTalk dynamic method invocation, but the kicker is the example.

      You look up the stateless session bean via JNDI. And what do you pass to JNDI?

      <<EAR-FILE-BASE-NAME/EJB-CLASS-NAME/local>>

      e.g.,

      <<EJB3Trail/StatelessCalculator/local>>

      Now lets see, StatelessCalculator is the name of a CLASS that implements the Calculator interface. Is it just me or does this famous "decoupling" seem entirely missing. "Look ma, I can finally lookup a class via a String, see it's not C++, it really is a dynamic language!" Aww shucks. Thanks reflection. It really ain't even 50% of Obj-C it's like 15% of it. What's the point? What's the big deal? And where's even the modest promise of looking up the bean by its interface? this clearly shows looking it up by a part of its class name!

      OK, now that there's more fuel, in some honesty: what am I missing? Is this just a bad example or are the folks behind the specs still chasing their tails as they were with EJB 1 and EJB 2?

        • 1. Re: Are EJB3 Stateless Session beans as boneheaded as they l
          gavin.king

          Have you heard of the concept of the ENC, existing since EJB 2.0?

          If not, please go and learn EJB properly before ranting, TIA :-)

          • 2. Re: Are EJB3 Stateless Session beans as boneheaded as they l
            bill.burke

            @Stateless(name="YourAnIdiot")
            public class MyBean implement My {...}


            // remote client

            My my = (My)jndi.lookup("YourAnIdiot/remote");


            // Refereneced

            @EJB My my;

            • 3. Re: Are EJB3 Stateless Session beans as boneheaded as they l
              bill.burke

              @Stateless(name="ImAnIdiotCauseICantSpell")

              • 4. Re: Are EJB3 Stateless Session beans as boneheaded as they l
                mazz

                While you deserved the thrashing that Gavin and Bill just gave you :-), I'll be a little more diplomatic.

                The example you gave only relies on the classname of the bean because that's the default naming convention (if you don't name it yourself). If you can come up with a more rational, common-sensical default for your JNDI name, well... you should have spoken up during the EJB3 spec committee's public discussions.

                But - if you want the decoupling you mention, you merely have to follow Bill's example - you use EJB3 annotations (or, optionally, an XML config) to define the lookup names.

                "StatelessCalculator/remote" is merely the default that the container comes up with if you elect NOT to define the name yourself. If you don't like it, name it yourself via the name= annotation attribute.

                You really should read alittle more deeply into a subject before attempting the arrogant route. Reading the specification would have been the first thing you should have checked and the answer would have been found there.

                • 5. Re: Are EJB3 Stateless Session beans as boneheaded as they l

                  They were going to use Foo and Bar as the defaut binding names but a preliminary study exposed the strategy as sub-optimal for implementations that were neither single nor dual-bean in nature. The class name seemed like a suitable, portable, default.

                  Reasonable or not, I was also visibly upset by the decision and ended up decoupling it myself with a generic method -- one line of code so not too bad.

                  Regarding the objective-c comparison, my computations show EJB 3.0 as being 15.1% objective-C not 15% as you stated. Did you factor in the fact that Objective-C is dead? That would account for the 0.1% variance plus or minus 99.9%.

                  Finally, ignore Gavin and Bill. They are always showing up professing to be some sort of experts on the subject. Go figure:)

                  • 6. Re: Are EJB3 Stateless Session beans as boneheaded as they l
                    bill.burke

                    actually the EJB3 specification does not specify how JNDI names are supposed to be calculated. This is vendor specific. One way to change the JNDI name is to use @Stateless.name() attribute, but the /remote /local is still appended. If you want to totally change the jndi name, then use the @org.jboss.annotation.ejb.RemoteBinding annotation.

                    • 7. Re: Are EJB3 Stateless Session beans as boneheaded as they l

                      Thanks for clarifying I was under the impression the recent JNDI name pattern was a standard default. The EAR file name prefix does have a bit of an odor to it but that will evaporate when the web tier gets @EJB injection. Having a default name is a good thing. I can parameterize the pattern in my own getEJB method for different platforms. Meanwhile I don't have to name every bean with a naked string.

                      • 8. Re: Are EJB3 Stateless Session beans as boneheaded as they l
                        mazz

                        Yes, sorry for adding to the confusion. I meant the specification would have shown you the @Stateless(name="foo") annotation as the way to override the container's default, not necessarily what the default is.

                        • 9. Re: Are EJB3 Stateless Session beans as boneheaded as they l
                          epstein

                           

                          I was annoyed by a bad example, not bad technology

                          Examples contributed back are of course welcome :-)