Lookup strings question

[Leena Diwan]

When do we use -

AccountRemoteHome accountHome = (AccountRemoteHome)
javax.rmi.PortableRemoteObject.narrow(
initialContext.[B]lookup(�java:comp/env/ejb/accounts�)[/B],
AccountRemoteHome.class
);  

and when do we use the following?

AccountRemoteHome accountHome = (AccountRemoteHome)
javax.rmi.PortableRemoteObject.narrow(
initialContext.[B]lookup(�accounts�)[/B],
AccountRemoteHome.class
);  

What is the diff? Is the diff in referring only either way being right or is it the scope or what? Can anyone help?

Regards,
Leena

[Leena Diwan]

I have seen the former version when referring ejbs defined in the ejb-ref elements. Well, it explains the 'java:comp/env' used in the lookup.

And the later one when looking up a fresh bean in the first part of a chain of processes. Like looking up for a 'ManageAccounts' session bean for FundTransfer.

So is it like -
The beans under 'ejb-ref' element under it (Accounts) can be accessed using 'java:comp/env/AccountsRef' - the former version.
Any bean defined under 'enterprise-beans' CAN BE found on its own with the later version. (say 'Accounts' tries get the home of AccountsRef using the later version)

Regards,
Leena

[Leena Diwan]

Does anyone know the answer to this?
Regards,
Leena

[Keerthi P]

You use java:comp/env to search for a home object in the bean's own private environment. This type of lookup will not succeed unless you define ejb-ref or ejb-local-ref for the bean that needs a lookup. The bean provider typically uses this reference name (ejb/accounts in your case) in his code, which a deployer later maps to the real JNDI name in the server. The deployer does this in a container-specific way. Note that your lookup code need not change even if the deployer chooses different real JNDI names. The real JNDI name can change arbitrarily at deploy-time.

The latter option can be used if you are playing both the role of a bean provider and deployer ,i.e, when you know before hand what the real JNDI name of the referred bean is. This way of programming is not recommended because, you may have to edit the lookup code if you would like to have a different real JNDI name.

Bean provider uses a logical names and codes his bean. Application assembler links this logical name to the actual EJB name in the deployment descriptor. The deployer maps the EJB name to the JNDI name at deployment using container specific tools.

[Binoj Viswanathan]

When do we use -
code:

AccountRemoteHome accountHome = (AccountRemoteHome)
javax.rmi.PortableRemoteObject.narrow(
initialContext.lookup(�java:comp/env/ejb/accounts�),
AccountRemoteHome.class
);

ejb1 referencing "accounts" ejb thru <ejb-ref> tag inside ejb1. here u hav2
specify an <ejb-link> to pint2 the "accounts" ejb. also u hav2 specify
<ejb-ref-name> as ejb/accounts. complete listing is something like this

<session>
<ejb-name>ejb1</ejb-name>
<home>com.ejb.sfsb.ejb1Home</home>
<remote>com.ejb.sfsb.ejb1</remote>
<ejb-class>com.ejb.sfsb.ejb1Bean</ejb-class>
<session-type>..as u like...</session-type>
<transaction-type>..as u like...</transaction-type>
<ejb-ref>
<description></description>
<ejb-ref-name>ejb/accounts</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.ejb.slsb.accountsHome</home>
<remote>com.ejb.slsb.accountsRemote</remote>
<ejb-link>ejb1.jar#accountsEjbName</ejb-link>
</ejb-ref>
</session>

***********************************************************************


when do we use the following?
code:

AccountRemoteHome accountHome = (AccountRemoteHome)
javax.rmi.PortableRemoteObject.narrow(
initialContext.lookup(�accounts�),
AccountRemoteHome.class
);


u can use this ven u r looking up the home from a client application other than ejb and u urself performs the duty of adeployer and a bean provider. ie, the actual name(specified thru container specific way) and logical name r same.


ven u r looking from an ejb, the container always starts searching from the subcontext java:comp/env in the JNDI tree

[Leena Diwan]

Thanks to both of you!

Regards,
Leena

[Keerthi P]

ven u r looking from an ejb, the container always starts searching from the subcontext java:comp/env in the JNDI tree

I guess not. It solely depends on the lookup code. If you use "java:comp/env", the lookup is performed under "java:/comp/env" subcontext from the root. If you use some arbitrary string "Accounts", the lookup will be performed under subscontext "Accounts" from the root.

Also, the JNDI implementation performs the lookup and not the 'container' as you have mentioned.

[Binoj Viswanathan]

quote:
--------------------------------------------------------------------------------I guess not. It solely depends on the lookup code. If you use "java:comp/env", the lookup is performed under "java:/comp/env" subcontext from the root. If you use some arbitrary string "Accounts", the lookup will be performed under subscontext "Accounts" from the root.

Also, the JNDI implementation performs the lookup and not the 'container' as you have mentioned
--------------------------------------------------------------------------------




hi,
Yes it shd be. When the client of ur EJB is a non-ejb client vat u hav explaind is perfectli right.----It solely depends on the lookup code. If you use "java:comp/env", the lookup is performed under "java:/comp/env" subcontext from the root. If you use some arbitrary string "Accounts", the lookup will be performed under subscontext "Accounts" from the root. ....


But ven u r looking from an ejb, the container always starts searching from the subcontext java:comp/env in the JNDI tree.

for example ny ejb-jar.xml has:

<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>TestSFSB</ejb-name>
<home>com.ejb.sfsb.SFSBTestHome</home>
<remote>com.ejb.sfsb.SFSBTest</remote>
<ejb-class>com.ejb.sfsb.SFSBTestBean</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Container</transaction-type>
<env-entry>
<env-entry-name>name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>binoj</env-entry-value>
</env-entry>
<ejb-ref>
<description></description>
<ejb-ref-name>ejb/SLSB</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.ejb.slsb.SLSBTestHome</home>
<remote>com.ejb.slsb.SLSBTest</remote>
<ejb-link>SLSBTestEJB.jar#TestSLSB</ejb-link>
</ejb-ref>
<ejb-local-ref>
<description></description>
<ejb-ref-name>ejb/SLSBLocal</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local-home>com.ejb.slsb.SLSBTestLocalHome</local-home>
<local>com.ejb.slsb.SLSBLocalTest</local>
<ejb-link>SLSBTestEJB.jar#TestSLSB</ejb-link>
</ejb-local-ref>
</session>
........
</enterprise-beans>
........
</ejb-jar>


from TestSFSB i have the code to look up env entry is :
****************************
Context ctx = new InitialContext();
Context subCtx = (Context)ctx.lookup("java:comp/env");
System.out.println("env value of name ==="+subCtx.lookup("name"));

****************************

from TestSFSB i have the code to look up local intf home is :
****************************
Context ctx = new InitialContext();
Object obj = ctx.lookup("java:comp/env/ejb/SLSBLocal");
****************************


This works perfectily fine. and ven i try 2 use without java:comp/env/ its gives me namingexce..n

thax
binoj v

[Keerthi P]

Context ctx = new InitialContext();
Context subCtx = (Context)ctx.lookup("java:comp/env");
System.out.println("env value of name ==="+subCtx.lookup("name"));

This code should work obviously because it is same as ctx.lookup("java:/comp/env/name"). You already have the subCtx variable pointing to the subcontext "java:comp/env". In this case, only the lookup code in the client program and not the container, is deciding where start searching the object.

Context ctx = new InitialContext();
Object obj = ctx.lookup("java:comp/env/ejb/SLSBLocal");

This code also should work. Instead of using a subCtx variable, you are directly pointing to the "java:comp/env/ejb" subcontext. Here again, it is your lookup code that specifies and decides where to lookup.

In both the above cases, the lookup code is instructing the underlying JNDI implementation to search from java:comp/env namespace.

and ven i try 2 use without java:comp/env/ its gives me namingexce..n

Yes. It obviously will. Without java:comp/env, your lookup strings would be "name" and "ejb/SLSBLocal". When these are used in the client code, the JNDI tries to search for them from the root. But, these are actually bounded under "java:comp/env" branch. So the lookup fails.

When you have a resource ref or ejb ref or env entries or resource env refs in the deployment descriptor for an EJB, the container "binds" them to java:comp/env because these references are 'this' bean's own references. And since java:comp/env namespace is a bean's own private space, it makes sense for the container to bind the above references to this namespace so that other beans cannot access them. So it is apt to say that the container "binds" the refered objects to java:comp/env namespace rather than 'container performs lookup in java:comp/env'.

Whether your client is EJB or POJO, if it needs a lookup, it needs to "explicitly" specify where the JNDI should start looking from. The container has no knowledge about where an ejb client wants to do lookup.
[ February 21, 2005: Message edited by: Keerthi P ]

[Leena Diwan]

Originally posted by Keerthi P:
If you use some arbitrary string "Accounts", the lookup will be performed under subscontext "Accounts" from the root.

Can you share some study resource which explains this? I have not come across this. Read often about the resource environment subcontexts everywhere. But not this.

Regards,
Leena

[Binoj Viswanathan]

When you have a resource ref or ejb ref or env entries or resource env refs in the deployment descriptor for an EJB, the container "binds" them to java:comp/env because these references are 'this' bean's own references. And since java:comp/env namespace is a bean's own private space, it makes sense for the container to bind the above references to this namespace so that other beans cannot access them. So it is apt to say that the container "binds" the refered objects to java:comp/env namespace rather than 'container performs lookup in java:comp/env'.

hi,

Thanks keerthi!!!1

I had incorrect interpretation of the above mentioned topic.
Sorry for misleading you guys.

binoj