• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Lookup strings question

 
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When do we use -


and when do we use the following?



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
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does anyone know the answer to this?
Regards,
Leena
 
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks to both of you!

Regards,
Leena
 
Keerthi P
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
A wop bop a lu bob a womp bam boom. Tutti frutti ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic