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? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3932535#3932535 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3932535 ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
