The bad thing first. Standardized JNDI names for EJBs that are the same on all ApplicationServer will be available with EJB 3.1. All I've got is EJB 3.0 so I'm in a world with vendor specific JNDI-Names. On Weblogic 10.3.0.0 I've got the following options to get an EJB reference:
- Annotate a field or method with @EJB. The container will inject then a reference to the EJB and this even works when there is no JNDI name definition for the EJB. Sounds great. But read again. The container will do it. This is fine as long as you run in such a container. A swing rich client won't run in such a container. Well Glassfish create an appclient container that should solve this but I haven't found such a client container for Weblogic.
- Do it the EJB 2.1 way and define a JNDI name in the weblogic-ejb-jar.xml. I don't have to comment this except to the point that oracle itself doesn't recommend it. At http://download.oracle.com/docs/cd/E13222_01/wls/docs92/ejb/DDreference-ejb-jar.html#wp1114738 the tell that it will have issues with libraries and high network traffic on startup when run as cluster.
- Use the annotation weblogic.javaee.JNDIName. When reading the documentation at http://download-llnw.oracle.com/docs/cd/E12840_01/wls/docs103/ejb30/annotations.html#wp1438214 it turns out that this is just the annotation counterpart to entry in weblogic-ejb-jar.xml. It has the same warning as the xml entry. So you save xml editing at the cost of more references to weblogic specific code. Sounds like a bad trade-off.
- Use the mappedName
attribute of javax.ejb.Stateless.
Yes
this is a standard attribute of a standard annotation. Nothing
vendor specific. But if you look up the javadoc it says that the
handling of this attribute is vendor specific. Weblogic will create a
JNDI name like mappedName#full_name_of_businessInterface.
See http://download-llnw.oracle.com/docs/cd/E12840_01/wls/docs103/ejb30/annotations.html#wp1417411
for more details. The advantage of this solution is that you do not
have to edit xml files and you do not add direct references to weblogic
specific code. But the solution is not ideal as referencing of the EJBs
may still change when you switch from one application server to another.