"alesj" wrote : Lame in what way?
| Why the need for ServiceLocator, what do you gain?
Lame in the way that the EJB3 Spec allowed intracontainer injection of
dependencies; why not provide the same utility to client applications? And in
the process...abstract the inner plumbing of JNDI Lookups
Another thread about service locator:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=97959
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009246#4009246
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009246
_
Thank you for your replies!
The need of service locator was to hide the multiple JNDI calles and in EJB2.x
to cache the interfaces so that you would not have to 'ask' it every time you
need a common used EJB reference.
I am bit confused how we can achieve this kind of caching! or maybe is this
Sometime I have to use a service locator like because I am in a class that is
not a EJB3.
A small example:
Some of my entities have a @EntityListener. Implementation of the entity
listener needs to use a service provided by an EJB3 session. In the source code
of the entity listener, I can not
"javaneze" wrote :
| At the moment I am just doing JNDI calls from my web layer...and its a bit
lame..
|
Lame in what way?
Why the need for ServiceLocator, what do you gain?
EJB3 simplified things so much that a simple JNDI look-up of wanted EJB session
bean (interface) is all you need.