4 Replies Latest reply on Nov 5, 2004 3:26 AM by lameguy

hardcoded JNDI names on clientside...

lameguy Oct 31, 2004 2:06 AM

Hi, I have some hardcoded JNDI names on clientside, wish to know if I have alternatives to that. Before going any further:

Bean itself

/**
 * @ejb.bean
 * name="GroupEJB"
 * local-jndi-name="ejb/UserGroup"
 * display-name="User Group EJB"
 * description="User Group EJB"
 * cmp-version="2.x"
 * type="CMP"
 * view-type="local"
 * schema="Group"
 * reentrant="false"
 * primkey-field="UIN"
 *
 * @ejb.persistence
 * table-name="GROUPS"
 *
 * @ejb.finder
 * query="SELECT OBJECT(g) FROM Group AS g"
 * signature="java.util.Collection findAllGroups()"
 *
 * @ejb.interface
 * local-extends="javax.ejb.EJBLocalObject, java.lang.Comparable, java.io.Serializable"
 * local-class="com.aa.samples.interfaces.GroupLocal"
 *
 * @ejb.home
 * local-class="com.aa.samples.interfaces.GroupLocalHome"
 *
 * @jboss.persistence
 * datasource="java:/jdbc/dev01"
 * datasource-mapping="mySQL"
 * create-table="false"
 * remove-table="false"
 */
public abstract class GroupBean implements EntityBean, Serializable, Comparable {
...
...
}

And on clientside:

groups=(Collection) servlet.getServletContext().getAttribute(constants.AVAILABLE_GROUPS);
if(groups==null) {
 home = (GroupLocalHome) context.lookup("ejb/UserGroup");
 groups=home.findAllGroups();
 ...
 ...
}

Any suggestion?

1. Re: hardcoded JNDI names on clientside...

raist_majere Oct 31, 2004 3:54 AM (in response to lameguy)

A possible solution is provide an utility class using the ejb.util tag on the EJB's you need to access. Read the XDoclet docs if you want to know more about this tag.
Actions
2. Re: hardcoded JNDI names on clientside...

lameguy Oct 31, 2004 4:23 AM (in response to lameguy)
This tag is optional, and lets you define whether or not a util class should be generated, and whether to use the logical component name (java:comp/env) or the physical JNDI name to do the lookup. If this tag is not specified, the util class will be generated using logical lookups (provided the <utilobject/> subtask is used)

XDoclet REF: http://xdoclet.sourceforge.net/xdoclet/tags/ejb-tags.html#@ejb_util__0__1_

Applies to: Applies to Entity Beans and Session Beans

What's "logical component name"? or "Physical JNDI name"? When I do look up, I do something like this, using JNDI name as specified on "jboss.xml" JNDI-name-to-EJB-name mapping section:

context = new InitialContext(); Object ref = context.lookup("ejb/UserAuthenticationManager"); //THAT's JNDI name - is there distinction between "Physical" JNDI names and other type of JNDI name? authManagerHome = (AuthenticationManagerHome)PortableRemoteObject.narrow(ref, AuthenticationManagerHome.class); authManager=authManagerHome.create();

Bean:
/** * * @ejb.bean name="UserAuthenticationManagerEJB" * display-name="User Authentication Manager EJB" * description="User Authentication Manager" * view-type="remote" * jndi-name="ejb/UserAuthenticationManager" * type=stateless * @ejb.interface * remote-class="com.aa.samples.interfaces.AuthenticationManager" * @ejb.home * remote-class="com.aa.samples.interfaces.AuthenticationManagerHome" * */ public class AuthenticationManagerBean implements SessionBean { ... }

My understanding is that jndi-name="ejb/UserAuthenticationManager" gets rendered into "jboss.xml" by XDoclet:

EJB name to JNDI name mapping in "jboss.xml": <session> <ejb-name>UserAuthenticationManagerEJB</ejb-name> <jndi-name>ejb/UserAuthenticationManager</jndi-name> </session>

What's the distincation between:
1. Physical JNDI names
2. other kinds of JNDI names
3. Logical component names

Thanks!
Actions
3. Re: hardcoded JNDI names on clientside...

raist_majere Nov 4, 2004 7:23 PM (in response to lameguy)
I'll try to do my best with the explanation, but I don't know if it will be clear enough...
Every component on a J2EE has its own "environment" with which the component can reference another component (an EJB, datasource...) by a "logical" name. This logical component name is used by programmers to reference another component in programming time because they must not know the real JNDI name of the component they are accessing, which may be known on deployment time. That name is not (or may not be) the real name of the other component, so when deploying that component there has to be a mapping between these two references (the logical one, that is, the one used on the component; and the real one, that is, the one in the JNDI).
To give you an example, an EJB accessing another EJB uses in its code this lookup:
ic.lookup("java:comp/env/ejb/Users");

and in the ejb-jar.xml defines that reference with "ejb/Users" and its local and local home interfaces. Another EJB can access another EJB using the same logical name, but using other interfaces because it has another reference definition (every EJB has its own logical definitions, which are not shared between each other).
Then, using the jboss.xml file (on the JBoss AS), the deployer maps this logical references to real JNDI names.

Well, now the difference using XDoclet. If you use logical component names, you define a reference and then map it to the real JNDI name; in the other hand, if you use physical JNDI names, you directly access the real JNDI names, without using a logical mapping. Using one or another is your choice.

I hope I was able to clearly explain you the difference.
Actions
4. Re: hardcoded JNDI names on clientside...

lameguy Nov 5, 2004 3:26 AM (in response to lameguy)

Hi Raist, thanks for the tip. I'm in the middle of managing a few things at the same time (including a new job the coming Monday). So, havent been able to get back to you on this any sooner. I've bookmarked this thread, and will certainly take time to digest your every word you wrote as soon as I can manage to sit down and cool my head.

But, thanks.
Actions

Go to original post