• 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

Thin Line Between JNDI and Resource Managers

 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Everyone,
According to the HF EJB Book, there are certain methods that allow u to access JNDI but not method invocation on other beans and also not allow u to access Resource Managers.
For example, ejbCreate() & ejbRemove() of Stateless Session Beans and ejbActivate() and ejbPassivate() of Entity Beans allow u to access JNDI but do not allow for Resource Managers.
My question here is that whats is the diffrence here between JNDI access and Resource manager access(Dont u get yr Resource Mangers from JNDI itself).
Also does simple JNDI access in the cases i mentioned above allow me to access ENV-ENTRIES i made in the Deployment Descriptor.Or for that matter allow me to access ejb-ref or resource-env-ref.
I need to understand the fine line of division between :
JNDI
1)<resource-ref>
2)<resource-env-ref>
3)<env-entry>
4)<ejb-ref>
I get all the 4 mentioend resources through JNDI itself, so does mean access to JNDI allow me to access all 4 resources fully.
OR there is some demarcation between JNDI and Resource Managers.
Anyone's help in this regard, would be really appreciated.
 
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is a definite distinction between access to JNDI and access to a resource ref, resource manager, or another bean. There's a really great blurb in the HF EJB book that talks about the difference between "Can and Can." The key point to remember is that the test is only concerned with what the EJB spec says you can do. Physical reality is irrelevant. So, for instance, a stateless session bean's ejbCreate method can in physical reality get a reference to a resource connection factory via a JNDI lookup. But, the EJB spec says that it should not use this reference to actually access the database. Thus, on the exam, if it asks you if you can access a database in the ejbCreate method of a stateless session bean, you say NO, because that's what ejb law dictates.
In the HF EJB book, when it says you can access your "special JNDI environment," just think of it as being able to access env-entry(s). Access to resources/beans that you can get at from a lookup are a whole different story.
In my humble opinion, the topic you brought up relates to the weakest section in the HF EJB book. It's difficult to rationalize some of the "what can you access and when" rules because the reasons why are hard to pinpoint. What helped me to remember these rules was thinking of what scenario would cause me to want to do certain things in a certain method.
For example, why would I want to access a database in the ejbCreate method of a stateless session bean? At the time that ejbCreate is called, no client is doing anything with a bean. What possible use could I have for wanting to access a database at a point when an object is not being used by anyone. If you did store some db data in your bean's data members, it would be stupid to do it during ejbCreate for a stateless session bean because, by the time any client actually calls the method, the data could be stale.
I hope this helps.
 
Rajnish Bhasin
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks a lot for yr view of the problem Anthony.
But the BIG Question still remains....
CAN I OR CAN I NOT access Environment-Entries,EJB-Refrences,Resource-ENV-Refrences from ejbCreate(), ejbRemove() in Stateless Session Beans and ejbActivate() and ejbPassivate() in Entity Beans ?
For the matter of RESOURCE-REF like a DataSource Object, i might get the instance in these methods but cannot use it.....
What if i put in a Similar Question for <env-entry>. Can i retrieve it from JNDI , but not use it?
Need Help On this...
 
Ranch Hand
Posts: 143
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
<env-entry> is a different case coz its mere a value. But with the other ones <resource-ref>, <ejb-ref>, <resource-env-ref> these are actually references to access the desired object. So when the HFE book says you can only access the JNDI from a method then that means u can only obtain the reference but not the desired object from that reference. like say u can get a reference for a connection factory but u cannot obtain a connection from that factory reference.
 
Rajnish Bhasin
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sudhir,
Thanks for yr views on this.
But aerent we forgetting that <env-entry> is not a mere value in case of EJB.
It delas only with Objects i.e String and Wrapper Classes.
So it might be possible to actually get the Wrapper Object, but not call doubleValue() or whatever desired function on the Object to get the desired value.
Let me know if i am right...
 
Anthony Watson
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Everywhere that the HF EJB book says that you can access your special JNDI environment, you can successfully get the value out of any env-entry(s). The only time you can't get at the env-entry(s) is in a bean's constructor.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic