0 Replies Latest reply on Jun 5, 2006 6:28 AM by sateh

    Would this @LocalBinding change make sense?

    sateh

      A common pattern that I see is the following:

      @Remote
      public interface HelloService {
       ...
      }
      
      @Stateless @RemoteBinding(jndiName = "myproject/services/Hello")
      public class HelloServiceBean implements HelloService {
       ...
      }
      


      This works great to reference your service from other applications and clients through a simple lookup in the global JNDI namespace.

      However, what I almost always also do is use that same service from the same application:

      class SomeOtherServiceBean implements SomeOtherService {
       @EJB(mappedName = "myproject/services/Hello")
       HelloService helloService;
      }
      


      Because I used @RemoteBinding for HelloService I also have to use the full global JNDI name here to reference the service. It makes sense of course, it is just a little inconvenient because you lose the simplicity of just throwing an @EJB annotation in there.

      class SomeOtherServiceBean implements SomeOtherService {
       @EJB
       HelloService helloService;
      }
      


      I know the difference is subtle, but I think a lot of these little improvements can make a big productivity difference. The more stuff the container takes out of my hands/mind the better.

      So what I would like to ask is if it would make sense to optionally let @RemoteBinding leave the original naming scheme intact so that 'blind' @EJB annotations still work in the same application.

      Maybe something like this:

      @Remote
      public interface HelloService {
       ...
      }
      
      @Stateless @RemoteBinding(jndiName = "myproject/services/Hello", replaceDefaultBinding = false)
      public class HelloServiceBean implements HelloService {
       ...
      }
      


      I'll be happy to add this myself if that is an option.

      S.