JNDI Context Retrieval in EJB 3.0

Question

I have a doubt about JNDI context retrieval in EJB 3.0. I know that when I call a bean from another bean I can use this line:
InitialContext ctx=new InitialContext();
But I'd like to know whether in a Client I am obliged to pass this parameter:
InitialContext ctx=new InitialContext(System.getProperties());
This method was the one I called when I used EJB 2.1..Now in many examples I find both these approaches...I'd like to know what differentiates one from another and which is the standard in EJB 3.0?
I read that when calling a bean from another bean I can use the first constructor with no parameters...but in clients I am obliged to give the param..why?
Thanks!

Answer 1

Correct me if I am wrong: the application client
container is a "static" container: you need to know
which EJB to call at develop time and you can not
change it later without recompiling.That's not quite right. First, there's nothing special about the application client
container with respect to retrieving Java EE dependencies that is not also true
of Java EE web containers and EJB containers. The programming model for
defining and accessing EE dependencies is exactly the same, independent of
whether the code is running in an Application Client, EJB container, etc.
It's true that dependencies are defined at development time, but one of the
whole reasons for the level of indirection provided by Java EE dependencies
is to allow the target of those dependencies to change without changing code.
E.g, with EJB dependencies this is done using the ejb-link attribute in ejb-ref
or ejb-local-ref. That specifies which EJB is the target of the ejb dependency
without changing the code used to retrieve the dependency.
>
JNDI was designed to be more flexible: you can
dynamically lookup EJB homes, then call a remote
method you like at runtime. Is that flexibility lost
with application client container. Is there any way
to dynamically inquiry-invoke?In the Java EE programming model, components always define what their
dependencies are so that the deployer can configure them. The idea of
doing a direct global lookup without using a Java EE dependency is
outside the scope of Java EE. It works in many implementations but the
specifics are not portable.
We have a presentation that covers some of these topics you might find
interesting. See here :
https://glassfish.dev.java.net/javaee5/ejb/compdependencies_xmlforum_nov15.pdf