14 Replies Latest reply on May 14, 2002 7:39 PM by Russ Moul

    Why can't clients use java:comp/env/ejb ??

    Frank Griffin Novice

      I searched the forums using "comp/env/ejb" and found several references to the docs (which I had read previously) saying that JBoss does not currently support the use of lookup("java:comp/env/ejb/beanname") from a client.

      However, I can't find any explanation as to WHY this is, whether it is in-spec or not, or whether there is any intention of correcting it if it isn't.

      I'm trying to write code that can be tested with JBoss, but be deployed on whatever the customer uses. In addition, I'd like client code to be usable either externally or internally, so that assemblers and deployers have the option to combine classes in EARs or not. I'd also like to avoid the mandatory use of vendor-specific deployment descriptors like jboss.xml, and use naming conventions in code and the ejb-jar.xml that don't require the use of such files.

      References like Monson-Haefel's EJB book seem to indicate that the URI approach is the standard one, and the JBoss doc reference to "not yet supported" seems to bear that out.

      Could someone please post the authoritative skinny on this issue ?

        • 1. Re: Why can't clients use java:comp/env/ejb ??
          Adrian Brock Master

          From the spec EJB2.0 (20.2.1.2)

          "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."

          Regards,
          Adrian

          • 2. Re: Why can't clients use java:comp/env/ejb ??
            Frank Griffin Novice

            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 ?

            • 3. Re: Why can't clients use java:comp/env/ejb ??
              Adrian Brock Master

              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.

              Regards,
              Adrian

              • 4. Re: Why can't clients use java:comp/env/ejb ??
                Mac Rinehart Newbie

                Adrain,

                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?

                - Mac

                • 5. Re: Why can't clients use java:comp/env/ejb ??
                  Adrian Brock Master

                  Implementing environment entries?
                  Can you post a link to what you are talking about?

                  Regards,
                  Adrian

                  • 6. Re: Why can't clients use java:comp/env/ejb ??
                    Mac Rinehart Newbie

                    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.

                    • 7. Re: Why can't clients use java:comp/env/ejb ??
                      Adrian Brock Master

                      Yes,

                      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

                      http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/jbosstest/src/resources/web/META-INF/
                      http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/jbosstest/src/main/org/jboss/test/web/

                      Regards,
                      Adrian

                      • 8. Re: Why can't clients use java:comp/env/ejb ??
                        Mac Rinehart Newbie

                        Great! Thanks for the reference. Answered another open question about the structure of jboss.xml at the same time.

                        - Mac

                        • 9. Re: Why can't clients use java:comp/env/ejb ??
                          Frank Griffin Novice

                          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)
                          javax.rmi.PortableRemoteObject.narrow(
                          initialContext.lookup( java:comp/env/ejb/accounts ),
                          AccountHome.class);

                          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 ?

                          • 10. Re: Why can't clients use java:comp/env/ejb ??
                            Adrian Brock Master

                            This is the j2ee application client not standalone
                            clients.
                            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.

                            Regards,
                            Adrian

                            • 11. Re: Why can't clients use java:comp/env/ejb ??
                              Frank Griffin Novice

                              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 ?

                              • 12. Re: Why can't clients use java:comp/env/ejb ??
                                Adrian Brock Master

                                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
                                of interfaces.
                                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

                                Regards,
                                Adrian

                                • 13. Re: Why can't clients use java:comp/env/ejb ??
                                  Frank Griffin Novice

                                  Ahhh, I will go read the J2EE spec. Thanks for your reply. This is starting to get clearer...

                                  • 14. Re: Why can't clients use java:comp/env/ejb ??
                                    Russ Moul Newbie

                                    What about application-client.xml? Isn't this the appropriate place to define &lt;ejb-ref&gt; 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?

                                    Russ