Skip to main content

@EJB and the name() attribute

4 replies [Last post]
ljnelson
Offline
Joined: 2003-08-04
Points: 0

This link (
http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#EJB_ejb-ref_ejb_local...)
says that the name() attribute is relative to "java:comp/env/".

This link (
http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#How_do_I_define_my_ow...)
says that you can "absolutize" the name() attribute, i.e. that the value of
the name() attribute is relative to "java:comp/env/" only when it does not
start with "java:comp/", "java:module/", "java:app/" or "java:global/".

The EJB 3.1 specification is silent on the matter. So is the Java EE 6
specification. Both hint at the idea that the name() attribute might not
*have* to be relative to java:comp/env/ if it is appropriately constructed,
but neither says so outright.

The Javadoc for the @EJB element says "The logical name of the ejb
reference within the declaring component's (e.g., java:comp/env)
environment." "E.g." means "for example" so I don't know whether this is
prescriptive or not.

Is this link (
http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#How_do_I_define_my_ow...)
really correct? Can I do this, for example:

@EJB(name = "java:app/ejb/Foobar")
private Foobar foobar;

...and have it automatically injected provided there is only one
implementation of Foobar? Please tell me this does not define a name of
java:comp/env/java:app/ejb/Foobar. That would make me weep.

I know that I can do this:

@EJB(lookup = "java:app/ejb/Foobar")
private Foobar foobar;

...which is really equivalent to this:

@EJB(lookup = "java:app/ejb/Foobar", name =
"the.fully.qualified.name.of.ThisClass/foobar")
private Foobar foobar;

...but that requires the assembler to explicitly put a bean in that slot.
I don't want to use mappedName(), beanName() or lookup() for this reason
(if there's only one EJB that could "fit" in this slot, I don't want anyone
to have to configure anything).

I *do* want to use name(), so that the assembler can easily change the
linkage of several @EJB references all at once. If I have 30 instances of
@EJB(name = "foo/bar"), then a single
foo/bar... at
the root of an application that has several candidates for injection into
that slot will suffice.

I need to be able to count on the fact that name() can behave like
http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#How_do_I_define_my_ow...
it should, because when injecting @EJBs into JAX-RS resource classes,
those resource classes are required to be @ManagedBeans, and @ManagedBeans
have no component environment, so a simple "foo/bar" name won't cut it.

Thanks for any and all clarification in this area.

Best,
Laird

--
http://about.me/lairdnelson

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mvatkina
Offline
Joined: 2005-04-04
Points: 0

Hi Laird,

EJB 3.2 section "Injection of EJB References" has been fixed and now
describes @EJB annotation elements in more details. In particular it says

"The name element refers to the name by which the resource is to be
looked up in the environment."

Which matches the FAQ entry that you refer to.

-marina

On 8/1/13 1:21 PM, Laird Nelson wrote:
> This link
> (http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#EJB_ejb-ref_ejb_local...)
> says that the name() attribute is relative to "java:comp/env/".
>
> This link
> (http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#How_do_I_define_my_ow...)
> says that you can "absolutize" the name() attribute, i.e. that the
> value of the name() attribute is relative to "java:comp/env/" only
> when it does not start with "java:comp/", "java:module/", "java:app/"
> or "java:global/".
>
> The EJB 3.1 specification is silent on the matter. So is the Java EE
> 6 specification. Both hint at the idea that the name() attribute
> might not *have* to be relative to java:comp/env/ if it is
> appropriately constructed, but neither says so outright.
>
> The Javadoc for the @EJB element says "The logical name of the ejb
> reference within the declaring component's (e.g., java:comp/env)
> environment." "E.g." means "for example" so I don't know whether this
> is prescriptive or not.
>
> Is this link
> (http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#How_do_I_define_my_ow...)
> really correct? Can I do this, for example:
>
> @EJB(name = "java:app/ejb/Foobar")
> private Foobar foobar;
>
> ...and have it automatically injected provided there is only one
> implementation of Foobar? Please tell me this does not define a name
> of java:comp/env/java:app/ejb/Foobar. That would make me weep.
>
> I know that I can do this:
>
> @EJB(lookup = "java:app/ejb/Foobar")
> private Foobar foobar;
>
> ...which is really equivalent to this:
>
> @EJB(lookup = "java:app/ejb/Foobar", name =
> "the.fully.qualified.name.of.ThisClass/foobar")
> private Foobar foobar;
>
> ...but that requires the assembler to explicitly put a bean in that
> slot. I don't want to use mappedName(), beanName() or lookup() for
> this reason (if there's only one EJB that could "fit" in this slot, I
> don't want anyone to have to configure anything).
>
> I *do* want to use name(), so that the assembler can easily change the
> linkage of several @EJB references all at once. If I have 30
> instances of @EJB(name = "foo/bar"), then a single
> foo/bar...
> at the root of an application that has several candidates for
> injection into that slot will suffice.
>
> I need to be able to count on the fact that name() can behave like
> http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#How_do_I_define_my_ow...
> says it should, because when injecting @EJBs into JAX-RS resource
> classes, those resource classes are required to be @ManagedBeans, and
> @ManagedBeans have no component environment, so a simple "foo/bar"
> name won't cut it.
>
> Thanks for any and all clarification in this area.
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson

ljnelson
Offline
Joined: 2003-08-04
Points: 0

On Thu, Aug 1, 2013 at 9:04 PM, Marina Vatkina wrote:

> EJB 3.2 section "Injection of EJB References" has been fixed and now
> describes @EJB annotation elements in more details. In particular it says
>
> "The name element refers to the name by which the resource is to be looked
> up in the environment."
>

Thanks.

So @EJB(name = "java:app/Foo", lookup = "java:app/Bar") is intended to be
legal?

Dumb, but legal?

Next question (related to
http://stackoverflow.com/questions/17985337/from-an-ear-files-applicatio...
):

If I have this in my .ear's lib directory:

@ManagedBean // yeah, yeah, I know; but
https://www.google.com/search?q=jax-rs+managedbean
public class ManagedBean {
@EJB(name = "*java:app/Foo*")
private *Foo* foo;
}

...and in my application I pack up only one EJB that implements Foo, I
should need no other configuration for this reference to work, correct?

If I package up two EJBs that implement Foo, then I need to add an
element in (say) my ear file's
META-INF/application.xmlfile, right, like this:

*java:app/Foo*
someJar.jar#*FooEJB*

I've found that this does not work in GlassFish 3.1.2.2. Is this a bug?

Best,
Laird

--
http://about.me/lairdnelson

ljnelson
Offline
Joined: 2003-08-04
Points: 0

On Fri, Aug 2, 2013 at 6:49 AM, Laird Nelson wrote:

> I've found that this does not work in GlassFish 3.1.2.2. Is this a bug?
>

After thinking and staring cross-eyed at the problem for a while I have
concluded this is indeed a bug and have filed
GLASSFISH-20739 with
a DropBox-linked test case (I couldn't attach files to the JIRA).

The application in the test case "deploys successfully" but actually
doesn't; there is an unbound reference inside it.

Best,
Laird

--
http://about.me/lairdnelson

ljnelson
Offline
Joined: 2003-08-04
Points: 0

On Fri, Aug 2, 2013 at 6:49 AM, Laird Nelson wrote:

> So @EJB(name = "java:app/Foo", lookup = "java:app/Bar") is intended to be
> legal?
>
> Dumb, but legal?
>

Prosecution withdraws the question. Of course it's legal: it's defining a
name for this reference ("java:app/Foo") and saying that unless otherwise
specified the container must look for a deployer-bound component for this
"slot" in java:app/Bar.

Best,
Laird

--
http://about.me/lairdnelson