I have coded a small application that deals with stateless and entity beans. Stateless bean calls the local interfaces of the entity bean. I'm deploying this in JBoss 4.2.3 bean and below are my config files
Through my stand alone client, I was able to lookup Session bean and invoke a method, successfully. But when I try to look up the local home interface of the entity bean, I'm seeing
I have also verified the JMX and see that
My JNDI name on jboss.xml is MyEJB/Employee, but in JMX it is showing as local/Employee.
Please advice on figuring the eisse and compn
Joined: Mar 18, 2010
but when I try to look up the local home interface of the entity bean
from where ? the facade or directly from the client ? and how, i.e. what code are you using to lookup ?
Your suggestion worked for me and I have also gone through the link you provided.
Please help me and advice, if my understanding is correct.
Entity Beans should be referred using java:comp/env context. Is this true for both remote and local beans ?
If my above statement is true, then what is the purpose of jboss.xml.
Why did it not work, when I created the context with properties loaded? Is that because, local entities are deployed on JBoss which itself is implementing JNDI.
Its a bit confusing to me. Would you mind elaborating it here?
Joined: Mar 18, 2010
let me see if i get this right...
As you know, the ejb spec was designed from the ground up to fulfill the commercial holly grail of software engineering - the supermarket of sw components; where an application assembler could go through the shelves filling his cart with the fresh beans of the season grown by ...yep bean providers :) and then hand it (sell it) to organizations where deployers would install the app in an environment given by one of many container providers, and so on ...
In practice, in many organizations (if not most of them...but this is just a gut feeling), a lot of the ejb roles are performed by the same person, wearing different hats, sometimes without even being aware of it.
This separation of roles led to the need to create mechanisms that while isolating the responsibilities of each role, would still allow communication to take place between them. So in this particular case, when you create a bean, you tell the application assembler (and in the case of security metadata, the deployer too, but that's a different matter...) which resources your particular bean uses, without knowing the actual names they will be associated with when the application is actually assembled.
So you, while wearing the enterprise bean programmer's hat, must use "local" names for the external resources your bean uses, whether they are other beans, data-sources, jms destinations, you name it. The application assembler (yep that's you again!) links your references to the actual beans, in the deployment descriptor.
The container ensures that when your bean is instantiated, it has its own jndi environment, where all the resources you declared as references in the dd are available under the tree "java:comp/env" accessible via the Context created with InitialContext() - no params. The spec suggests you use the prefix "ejb" for the ejb references so that an ejb, local or remote, is accessible using "java:comp/env/ejb/<BeanName>" but you don't have to (as your example shows). There is one such "Enterprise Naming Context (ENC)" - refer to the link i sent you - per ejb instance.
For remote beans your bean may act like a standalone application and retrieve remote ejbs through their jndi name in the GLOBAL namespace (which the ejb 3.1 finally standardizes) where they reside associated with the names you provide in the jboss.xml. Local ejbs do not work that way (in glassfish 2.1 for instance they don't even show up in this jndi tree) so you have to access them through the ENC (which you should always do in the first place for the beans that you reference, may them be local or remote - as long as they are in the same jee app).
The definite reference about this subject is chapter 20 "Enterprise Bean Environment" of the ejb 2.1 spec. You may also look into the equivalent chapter 16 of the 3.0 spec.
The link about the jboss stuff also seemed quite exhaustive and although I only skimmed through it would still recommend it.