Some Issues Building Clients for Local Stateless Session EJB


General J2EE: Some Issues Building Clients for Local Stateless Session EJB

  1. 1. From what I've seen, I still need to import the remote exceptions. I don't see the need for this since I will be calling my EJB locally. Am I looking at bad examples or is the use of the packages javax.rmi and java.rmi required?

    2. In the ejb-jar.xml, the <ejb-name> tag is suppose to be a nickname (according to my app server vendor) for JNDI purposes. if so, then how does the compiler know about the nickname? Here's a snipplet where GreeterEJB is an actual nickmane (i.e. does not correspond to any class).

    Object o = ctx.lookup("GreeterEJB");
    GreeterEJBHome home = (GreeterEJBHome)PortableRemoteObject.narrow(o,GreeterEJBHome.class);GreeterEJB test = home.create();


    Threaded Messages (7)

  2. 1. No, it isn't. Maybe some other parts of the code you looked at do make remote calls?

    2. The "GreeterEJB" string is not resolved by the compiler. It is used at runtime to look up the home object. However, this line:
    GreeterEJB test = home.create();
    Is resolved by the compiler. If GreeterEJB does not resolve to any class in this context, the compiler will signal an error. The ejb-name is a "nickname" for the deployed bean, not the bean itself (e.g it's classes). You can deploy the same bean several times with different ejb-name values and get completely different deployments.

  3. I see...[ Go to top ]

    Gal, thanks for the reply.

    1. The example that I was looking at intended to be client for both local and remote EJBs. So they left in the catching of the remote exceptions.

    2. Here I understand was going on with the runtime resolution but don't quite get the motivation for ever declaring a name within <ejb-name> that is different than the one given to the EJBs implementation class. This just "naively speaking" seems to be a trap for compiler errors. I know this is not the case, what am I missing conceptualy here?

    Appreciate the discussion.
  4. I see...[ Go to top ]

    2. The ejb-name and the class name are not neccesarily related in a one-to-one relationship (although they usually are). You could potentially have two beans with the same implementation, but different deployment options (say, different transactional attributes). But the point is, and ejb-name defines a logical bean, and the implementation class is just one of the properties of this bean. It might be a little comfusing at first, but I'm sure once you get used to it you would see the logic behind it.

  5. Still Floating in Outer Space[ Go to top ]


    Thanks for helping me understand this a little better. My confusion stems from the fact that I don't see the logical name benefit provided by <ejb-name> if in fact one needs to know the true class name to compile the client. if not, then one gets class not found errors.

    Four i.e., say we have four different implementation classes then despite the encapsulation provided by the logical name, one still needs to know the true class name at compile time. So this seems to defeat the logical name functionality.

    Like I said, I'm still floating on this one.

  6. Still Floating in Outer Space[ Go to top ]

    You don't need to know the implementation classes when compiling the _client_, only the interfaces which you need anyway.
  7. Still Floating in Outer Space[ Go to top ]

    The abtraction provided by the ejb-name is not for the client. The client is never exposed to the ejb-name. It is an abstraction used by the different layers of the deployment descriptor (assembly, deployment, administration, ...) to refer to the logical bean. Any other value, like the bean's interface or implementation, would not suffice because:
    - One interface may have multiple implementations deployed seperately.
    - One implementation may have several deployment instances with different attributes.

    Finally, using the interface or implementation as an identifier is just not comfortable. In the administration screen you want to see some meaningful name, not a long class name that you have to be a Java programmer to understand. It would also be comfusing to use a class name, because a bean has many classes associated with it (remote interface, local interface, ...).

    By the way, the client does not need to know the implementation class of a bean, or even have it on his classpath. The client only needs to know the interface.

  8. Appreciate the Feedback[ Go to top ]

    "is an abstraction used by the different layers of the deployment descriptor"

    Ah... Now it all makes perfect sense. I thought the abstraction was specifically for the client's benefit given that <ejb-name> is also the JNDI bind name.

    EJBs are a brand new beast for me; hence, I certainly appreciate the responses. I believe I got those ideas straightened out. Time to stumble somewhere else...