JNDI Context Retrieval in EJB 3.0
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!
[713 byte] By [
albertthea] at [2007-11-27 9:34:32]
# 1
When using the JNDI API to access dependencies/resources such as EJB references, the only
portable approach defined by Java EE is the no-arg InitialContext combined with a lookup relative
to java:comp/env/.The issue is not whether the code performing the lookup is a "client" or not.
What matters is what kind of Java EE component the code is running in.Java EE defines a
1st class client component called an Application Client. That's what should be used to write
portable Java EE clients.In that case, as well as for code running within web/EJB components, it's
up to the container to bootstrap the naming provider.Passing properties to InitialContext defeats
one of the main goals of Java EE, which is to remove plumbing code from the application itself.
You can find more information in our EJB FAQ :
https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#AppClientDef
ksaksa at 2007-7-12 22:59:02 >
# 2
1. If use no-arg InitialContext, then how to specify user name and password?
2. Will the InitialConext give the "global context" (all JNDI names in the server)?
or just list JNDI names in the application?
Thanks.
> When using the JNDI API to access
> dependencies/resources such as EJB references, the
> only
> portable approach defined by Java EE is the no-arg
> InitialContext combined with a lookup relative
> to java:comp/env/.
# 3
Authentication is independent of the naming service.If you're accessing protected resources, that's
another reason to write an Application Client. The Application Client container will perform
authentication as needed at runtime.
Portable lookup code does not depend on a global namespace. All lookups are performed within
the private component environment, which is accessed relative to java:comp/env/.
In Java EE 5, the easier approach is to use injection so you don't have to worry about lookups.
See our simple examples here :
https://glassfish.dev.java.net/javaee5/ejb/EJB30.html
ksaksa at 2007-7-12 22:59:02 >
# 5
> 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
ksaksa at 2007-7-12 22:59:02 >
