Skip to main content

EJB3 JNDI name is mangled!

7 replies [Last post]
platinumdragon
Offline
Joined: 2005-04-06

After deploying my stateless session bean: com.test.RemoteSecurity, doing a lookup(RemoteSecurity.class.getName()) gives me a NameNotFoundException.

Sure enough, looking at the JNDI entries, it has been entered as com.test.RemoteSecurity__3_x_Internal_RemoteBusiness__.

I thought you were supposed to be able to lookup EJBs by their interface name in EJB (or did I misinterpret a JBoss-specific functionality for being J2EE functionality?).

Thanks,
Mike

Reply viewing options

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

> After deploying my stateless session bean:
> com.test.RemoteSecurity, doing a
> lookup(RemoteSecurity.class.getName()) gives me a
> NameNotFoundException.
>
> Sure enough, looking at the JNDI entries, it has been
> entered as
> com.test.RemoteSecurity__3_x_Internal_RemoteBusiness__
> .
>
> I thought you were supposed to be able to lookup EJBs
> by their interface name in EJB (or did I misinterpret
> a JBoss-specific functionality for being J2EE
> functionality?).
Yes, anything having to do with specific syntax of physical JNDI names is non-portable. In addition, I assume you're attempting to access the EJB from a stand-alone java client, which is also non-portable. The best way to write the client is to use an Application Client component. That gives portability and also lets you use all the new ease-of-use features in Java EE 5.

E.g., you would add the following to your Application Client main class :

import javax.ejb.EJB;

private static @EJB RemoteSecurity rsRef;

When your Application Client is initialized rsRef will be automatically injected by the container. If the Application Client is packaged within the same .ear as the RemoteSecurity ejb you don't need to deal with any physical JNDI name mappings for the rsRef dependency. If the Applicaiton Client is part of a different application than the target EJB, you'll need to map the rsRef dependency to the correct physical JNDI name.

Java EE 5 provides a new way to do this using an attribute called mappedName. Using the previous example, it would look like :

private static
@EJB(mappedName="com.test.RemoteSecurity") RemoteSecurity rsRef;

>
> Thanks,
> Mike

gbrose
Offline
Joined: 2005-10-10

> > I thought you were supposed to be able to lookup
> > EJBs by their interface name in EJB (or did I
> > misinterpret a JBoss-specific functionality for being
> > J2EE functionality?).
> Yes, anything having to do with specific syntax of
> physical JNDI names is non-portable.

The EJB3 spec. says that if the name is not explicitly
set, it defaults to the fully qualified class name. Why
is that non-portable?

> In addition, I assume you're attempting to access the
> EJB from a stand-alone java client, which is also
> non-portable.

Again, why is using the standardized remote APIs
non-portable? It appears it should be the other way
round...

Thanks, Gerald.

ksaks
Offline
Joined: 2005-04-05

> The EJB3 spec. says that if the name is not
> explicitly
> set, it defaults to the fully qualified class name.
> Why
> is that non-portable?

Which section are you referring to? The Java EE specs don't have any requirements on physical jndi-names. That's left up to the implementation. Are you talking about the rules for default *logical* names of environment dependencies? If so, that's something that only applies to code running within a Java EE component, so it wouldn't have anything to do with stand-alone java client programs.

On a separate note, we have implemented the feature that allows access to the Remote 3.0 Business interface from a stand-alone java client. If you don't specify a physical jndi-name in sun-ejb-jar.xml, it will default to the fully qualified remote business interface name. Here's an example :

InitialContext ic = new InitialContext();
MyRemoteBusinessIntf rbi = (RemoteBusinessIntf) ic.lookup("com.acme.MyRemoteBusinessIntf");
rbi.foo();

This is available in the latest builds.

--ken

>
> > In addition, I assume you're attempting to access
> the
> > EJB from a stand-alone java client, which is also
> > non-portable.
>
> Again, why is using the standardized remote APIs
> non-portable? It appears it should be the other way
> round...
>
> Thanks, Gerald.

gbrose
Offline
Joined: 2005-10-10

> > The EJB3 spec. says that if the name is not
> > explicitly set, it defaults to the fully qualified
> > class name.
>
> Which section are you referring to? The Java EE
> specs don't have any requirements on physical
> jndi-names. That's left up to the implementation.

This is in the different sections on name annotations and
in 18.2 in the core spec (on the deployment descriptors).

> Are you talking about the rules for default
> t *logical* names of environment dependencies?

Yes.

> If so, that's something that only applies to code
> running within a Java EE component, so it wouldn't
> have anything to do with stand-alone java client
> programs.

Checked the spec again, you are right. However, it is
handy for clients to be able use just the class name as
a default, and it would come in handy for deployments that
don't have descriptors (cf. below).

> On a separate note, we have implemented the feature
> that allows access to the Remote 3.0 Business
> interface from a stand-alone java client. If you
> don't specify a physical jndi-name in
> sun-ejb-jar.xml, it will default to the fully
> qualified remote business interface name.

Thanks, exactly what I'm looking for. Any chance this
could be the default behavior even in cases without any
descriptor files (as with JBoss)?

Thanks, Gerald.

ksaks
Offline
Joined: 2005-04-05

>
> Thanks, exactly what I'm looking for. Any chance this
>
> could be the default behavior even in cases without
> any
> descriptor files (as with JBoss)?

Yes, that is the behavior within our Java EE 5 implementation. If there is no jndi-name set in sun-ejb-jar.xml(or no sun-ejb-jar.xml at all :-) ) , the global jndi-name defaults to the fully qualified Remote 3.0 Business interface class name or the 2.x Remote Home class name.

BTW, just noticed a typo in my ealier code snippet :

>>MyRemoteBusinessIntf rbi = (RemoteBusinessIntf)
>>ic.lookup("com.acme.MyRemoteBusinessIntf");

The cast should be (MyRemoteBusinessIntf), not (RemoteBusinessIntf)

--ken

>
> Thanks, Gerald.

gbrose
Offline
Joined: 2005-10-10

> > Thanks, exactly what I'm looking for. Any chance
> > this could be the default behavior even in cases
> > without any descriptor files (as with JBoss)?
>
> Yes, that is the behavior within our Java EE 5
> implementation. If there is no jndi-name set in
> sun-ejb-jar.xml(or no sun-ejb-jar.xml at all :-) ) ,
> the global jndi-name defaults to the fully qualified
> Remote 3.0 Business interface class name or the 2.x
> Remote Home class name.

With the new build 22, I am now seeing three mangled
names in the JNDI browsing window. When using a
standalone CosNaming client browser, only one of these
shows up, and the class name cannot be resolved to a
remote reference from a standalone client. So I am
assuming this behavior is not available for standalone
clients, right? Any plans to make it externally
available?

Thanks, Gerald.

ksaks
Offline
Joined: 2005-04-05

>
> With the new build 22, I am now seeing three mangled
>
> names in the JNDI browsing window. When using a
> standalone CosNaming client browser, only one of
> these
> shows up, and the class name cannot be resolved to a
>
> remote reference from a standalone client. So I am
> assuming this behavior is not available for
> standalone
> clients, right? Any plans to make it externally
> available?

They are available for stand-alone clients, but those clients must use the app server's naming service. That means including appserv-rt.jar in your client's classpath and instantiating the no-arg InitialContext constructor.

The Remote 3.0 Business view is not an RMI object. It doesn't implement java.rmi.Remote and is not the kind of object that can be stored in a CosNaming service. If you need to access the app server via a CosNaming service, you can always define a set of 2.x Home/Remote interfaces for your 3.0 session bean and access it that way.

>
> Thanks, Gerald.