From the spec EJB2.0 (126.96.36.199)
"An environment entry is scoped to the enterprise bean whose declaration contains the env-entry element.
This means that the environment entry is inaccessible from other enterprise beans at runtime, and
that other enterprise beans may define env-entry elements with the same env-entry-name without
causing a name conflict."
Thanks for the reply.
OK, so is there any standard form derivable from vendor-agnostic data in the ejb-jar.xml that an external client can reliably use for bean lookups, or does each client have to know the naming characteristics of the server it is using ? If there is such a standard, does JBoss follow it by default (best case) or can it be made to follow it with a suitable jboss.xml ?
By default JBoss uses ejb-name,
normally it is overriden to "application"/ejb-name in
jboss.xml to avoid collisions between applications.
"application" is a name you provide.
The response puts us on the right foot regarding understanding what an environement entry is, but doesn't tell use if anyone is working on implementing environment entries. Is someone working on this now?
Implementing environment entries?
Can you post a link to what you are talking about?
Perhaps I missunderstood the thread, but my understanding is that java:comp/env is not supported for jboss. This is the exerpt from the 2.0 spec that I'm talking about
20.2.4 Container Provider responsibility
The container provider has the following responsibilities:
1. Provide a deployment tool that allows the Deployer to set and modify the values of the enterprise bean’s environment entries.
2. Implement the java:comp/env environment naming context, and provide it to the enterprise bean instances at runtime. The naming context must include all the environment entries declared by the Bean Provider, with their values supplied in the deployment descriptor or set
by the Deployer. The environment naming context must allow the Deployer to create subcontexts if they are needed by an enterprise bean.
3. The Container must ensure that the enterprise bean instances have only read access to their environment variables. The Container must throw the javax.naming.OperationNotSupportedException from all the methods of the javax.naming.Context interface that modify the environment naming context and its subcontexts.
Of course that is supported. Although,"and modify" in point 1 might not be if this means
changing them after deployment without redeploying.
Here's an example where SecuredEJB is bound globally
as jbosstest/ejbs/SecuredEJB and referenced by
UnsecuredEJB as java:comp/env/ejb/Session
Great! Thanks for the reference. Answered another open question about the structure of jboss.xml at the same time.
I've read a little more on this, and I'd like to rephrase the question...
I now understand from the spec that java:comp/env is restricted to providing lookup access to beans specifically mentioned in a deployment descriptor as being referenced by the deployed code. From that point of view, it is consistent to say that, since a client does not have a deployment descriptor, it has no business using java:comp/env because no environment names have been declared for it.
What I'd like to know is how a client is supposed to derive from <ejb-name> a JNDI name which is guaranteed to locate the EJB in all vendor client containers.
Section 9.1 says "A client view of an entity bean is independent of the implementation of the entity bean and its container. This ensures that a client application is portable across all container implementations in which the entity bean might be deployed."
However, in section 9.4.1, we have the following:
For example, the remote home interface for the Account entity bean can be located using the following code segment:
Context initialContext = new InitialContext();
AccountHome accountHome = (AccountHome)
initialContext.lookup( java:comp/env/ejb/accounts ),
and section 6 contains the same example for session EJBs.
Am I incorrect in thinking that clients are arbitrary pieces of software which are not explicitly under the control of a deployer, and therefore have no deployment descriptors ? And if they have no deployment descriptors, then there is no place to define their relationships with EJBs, and therefore they shouldn't be able to use java:comp/env. But in that case, what are they suppposed to use (that is vendor-agnostic) and why does the spec recommend java:comp/env ?
This is the j2ee application client not standalone
An application client has a deployment descriptor,
so you can use <ejb-ref> to link to a <jndi-name>
on the server.
JBoss doesn't have an application client launcher as far
as I'm aware.
I've seen references in the spec to a "client container", and also read something somewhere about placing client code in the EAR file, but this doesn't seem to be a requirement. So far, all I do for clients is make the jboss client JARs available and have them call InitialContext. That seems to work fine. Can you point me to the material on client deployment descriptors ?
I guess my question is what are the rules for clients without deployment descriptors ? What is the contract between a J2EE server and clients which have not been predefined ? Or, alternatively, what is the contract between J2EE JNDI servers and the outside world as regards EJB names that can be looked up by any Tom, Dick, or Harry with access to a jndi.properties that names the EJB server's JNDI ? Or is EJB a completely closed loop, where everything everywhere has to be defined in a deployment descriptor, and names are not mandated by spec as long as all of the descriptors agree on them ?
There's a whole section on application clients in
the j2ee1.3 spec (not the same as the EJB2.0 spec)
The basic rule is that servers expose a global namespace
for use by anybody who can get an jndi context.
It is the deployer's reponsibility to decide the names
in the global namespace. The spec doesn't mandate any
naming convention for ejbs.
In JBoss <ejb-name> is used by default, but you
can override it with the jboss.xml <jndi-name> element.
The idea behind this is that a client can request
something like products/Product with an agreed set
The deployer is then free to deploy anything
that implements the interfaces.
With deployment descriptors and the
java:comp/env namespace you get even more flexibilty.
You can use an <ejb-ref> to link
ejb/products/Product to product/Product
then later link it to product/AnotherProduct
Ahhh, I will go read the J2EE spec. Thanks for your reply. This is starting to get clearer...
What about application-client.xml? Isn't this the appropriate place to define <ejb-ref> elements to be used by the client? The spec also "recommends" using an ejb/ prefix. It appears none of this is supported (granted I'm using 2.4.4) is this true?