Name lookup fails, reason unknown

[jvm]

Hello,

I am a beginner with JBoss and J2EE. I am trying to get an app running from our source tree. I have JBoss 4.0.5 running okay. I have built and deployed the EAR successfully (I can see console and log messages to that effect and it appears in the JMX console).

The app uses EJB3 annotations and has no ejb-jar.xml

According to the JBoss docs (for v4.4 - don't know if things were different for 4.0.5) a remote client looks up a bean using the name:

"myapp/MyBean/remote"

where:

"myapp.ear" is the name of the deployed EAR file

"MyBean" is the name of the bean class as deployed in the EAR

"remote" is added for a remote call from a client

I am seeing:

javax.naming.NameNotFoundException: myapp not bound

I am feeding in the jndi properties via my own properties file which contains the following naming related parameters:

# Naming service parameters

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

java.naming.provider.url=jnp://localhost:1099

Please can anyone deduce the problem in this case?

Thank you.

[peterj]

Why are you using 4.0.5? The EJB3 support in that version was only a technical preview. If you are really just starting out to learn Java EE and EJB3, you should download and use JBoss AS 5.1.0.

Also, for name not found exceptions, this wiki page should help: http://community.jboss.org/wiki/DisplayTheJDNITreeWithTheJMXConsole

[jvm]

Hello Peter,

Thank you for your response. If I was starting a fresh app I would certainly use a newer version.

But the app I am modifying for the client  is currently deployed on JBoss v4.0.4 so I am using the same version (well actually installed 4.0.5 but the app is running on 4.0.4) to try and keep as close as possible to that.

I did go through the process and I can only see queues and factories in the global JNDI namespace which I guess just confirms the fact that the bean has not been bound to its name.

One thing I did not mention in my original post is that the app has a small web interface (2 JSP pages) deployed in a WAR inside the EAR which appears in the JNDIView java:comp namespace along with the EJB but I am trying to access the EJB from a remote thick client.

So back to my question as to why?

Any help appreciated.

Thank you.

[jvm]

Just to note that the stack trace was:  [I have hidden real app name for client confidentiality]

Connecting to server jnp://localhost:1099

2010-01-22 11:04:26,573 DEBUG ContextFactory:41 - Connecting to jnp://localhost:1099

2010-01-22 11:04:26,577 DEBUG BeanFinder:49 - Starting bean lookup

2010-01-22 11:04:26,800 ERROR BeanFinder:65 - Context factory - looking for myapp/MyAppFacade/remote

javax.naming.NameNotFoundException: myapp not bound

at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)

The EAR file was named myapp.ear

The bean was deployed in beans.jar inside the EAR

No ejb-jar.xml

No JBoss specific xml files were present

application.xml contains:

<display-name>MyApp</display-name>

<module>

     <ejb>beans.jar</ejb>

</module>

<module>

<web>

     <web-uri>web.war</web-uri>

     <context-root>myapp</context-root>

</web>

</module>

[peterj]

How did you get EJB3 support in 4.0.4? If I recall correctly, to get EJB3 support in 4.0.5 you had to run the JEMS installer and select the EJB3 option. I cannot recall if there was such an option for 4.0.4; it has been a long time. If you are using the 4.0.4 binary distribution, the one that you simply unpack to install, then it does not contain EJB3 support.

[jvm]

Hello Peter,

Thanks for the help. Unfortunately a combination of:

1. I am a beginner with JBoss and AS/J2EE in general

2. Person with experience for the client is now in US and not easy to ask questions

But the app is running on JBoss 4.0.4 which I can see from logging in and the console output.

The app is using EJB annotations with no deployment descriptors or extending EJBHome etc so that makes it EJB 3 I believe

HOWEVER...

I have switched to use JBoss v5.1.0.GA as you recommended and I am almost there...

JBoss 5.1.0.GA is installed and running and I can connect on localhost.

The app deploys okay I think as I can see all the various beans in the JNDIView listing.

I can access the web interface okay via Safari as well.

Only thing still not working is the client code does a check to see if it can get hold of the remote interface via a name lookup thus:

remoteFacade = (RequestFacade)beanFinder.lookup(jndiName);

This fails because the object returned is a javax.naming.Reference so of course a ClassCastException is thrown.

Please can you explain why this fails?

Is it because the client is requesting a remote resource and so the object is not being returned, only the name of the class that creates it?

If so do I always have to create the object via reflection or something here?

Or would I expect to get the remote proxy as an object if it was bound properly? I would have thought that the remote proxy would be sent as a serialized object over the wire and that that is what I should receive (which I assume is what the code is expecting hence the cast)?

If the latter then is there still a binding problem?

Not sure if this means I should start a new thread?

Thank you.

[peterj]

If your lookup code is returning a javax.naming.Reference, then you JNDI name is not complete. For example, if the full JNDI name is aaa/bbb/ccc and you look up aaa/bbb, then you will get a Reference. One thing you could do is use the methods on Reference to examine the names within that namespace, that might help suggest a solution.

Did you double-check the JNDIView in 5.1.0 to ascertain the full name of the deployed EJB? How does that name compare to the value of "jndiName" in your example code. (By the way, providing a code example that contains a variable instead of a literal is fairly useless when it comes to debugging problems. Without knowing the value of jndiName, all I can do is make guesses as to what the name is and thus what the problem might be.)

A JNDI name lookup for an EJB always returns a proxy (not entirely true, I think that when accessing the a local EJB you get the actual object). With EJB3, the proxy implements the remote and/or local interface so casting the proxy to the interface is not a problem.

[jvm]

Hello Peter,

Wow quick response. Thank you.

I am contracting with a client and so client confidentiality prevents me from posting actual code or details of the app but I will try and generalize by using:

<myapp> = name of the ear file, e.g. aaa for aaa.ear

<myfacade> = class name of remote interface class

<package> = java package

I have transcribed these for the actual output below.

(A) console output

I see the following output suggesting that maybe JNDI is binding the bean where I think:

17:25:50,129 INFO  [SessionSpecContainer] Starting jboss.j2ee:ear=myapp.ear,jar=beans.jar,name=myfacade,service=EJB3

17:25:50,130 INFO  [EJBContainer] STARTED EJB: <package>.myfacadeRemoteBean ejbName: myfacade

17:25:50,159 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

myapp/myfacade/remote - EJB3.x Default Remote Business Interface

myapp/myfacade/remote-<package>.myfacade - EJB3.x Remote Business Interface

(B) JNDIView global namespace shows

I see:

myfacade (class: org.jnp.interfaces.NamingContext)

+-   remote (class: Proxy for: package.interfaces.myfacade)

+-   remote-package.interfaces.myfacade (class: Proxy for: package.interfaces.myfacade)

(C) Code

I think that the name being looked up is correct. The name being looked up is "<myapp>/<myfacade>/remote"

Looking in the Reference object that is returned I see:

Reference Class Name: Proxy for: <package>.interfaces.myfacade

Type: ProxyFactoryKey

Content: ProxyFactory/myapp/myfacade/myapp/myfacade/remote

Type: EJB Container Name

Content: jboss.j2ee:ear=myapp.ear,jar=beans.jar,name=myfacade,service=EJB3

Type: Proxy Factory is Local

Content: false

Type: Remote Business Interface

Content: <package>.interfaces.myfacade

Type: Remoting Host URL

Content: socket://127.0.0.1:3873/

(D) There are two other things I should mention:

(1) The remote interface class extends all of the other bean interfaces so it is a super remote to all of the other bean interfaces.

The corresponding bean implementation class has a set of:

@EJB(beanName=<a name>)

private xyzManager xyzSession;

(2) The console log showed a couple of warnings:

17:25:51,445 INFO  [Ejb3Configuration] Processing PersistenceUnitInfo [

name: myapp

...]

17:25:51,680 WARN  [Ejb3Configuration] Persistence provider caller does not implement the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null.

...

17:25:53,343 WARN  [SessionFactoryObjectFactory] InitialContext did not implement EventContext

Thank you.

[peterj]

"I am contracting with a client and so client confidentiality prevents me from posting actual code or details of the app "

I have no problem with obfuscated code, providing that the obfuscated code mimics tha patterns in the actual code. An obfuscated JNDI name pattern is still much more enlightening than a variable whose contents I can only guess at.

One thing has me confused. There is this statement: "The name being looked up is "<myapp>/<myfacade>/remote" But later you give this code:

@EJB(beanName=<a name>)

private xyzManager xyzSession;

How does xyzSession relate to "<myapp>/<myfacade>/remote", or is it something completely different? If completely different, why mention it? If is is the same, why is it not:

@EJB(beanName=<a name>)

private <myfacade> xyzSession;

Alos ,the reference object looks OK - it would appear to be a referencefor a "ProxyFactory/myapp/myfacade/myapp/myfacade/remote" which seems to indicate that if you cast it to myfacade you should be OK. That is verififed by this info:

Type: Remote Business Interface

Content: <package>.interfaces.myfacade

     "(1) The remote interface class extends all of the other bean interfaces so it is a super remote to all of the other bean interfaces."

I wonder is this is causing the problem. Which interfaces have the @Remote annotation?

     "The console log showed a couple of warnings:"

I don't think that the warnings have anything to do with this particular problem - as long as the name shows up in the JNDI tree, you should be able to look up the EJB. Of course, you might run into issues later with accessing entity beans.

Where does the client live - the one that is looking up the EJB?

[jvm]

SORRY THE MARKUP MESSED UP - SOMEHOW THE MARKUP IS NOT BEING HONOURED

+One thing has me confused. There is this statement: "The name being looked up is "<myapp>/<myfacade>/remote" But later you give this code:+

EJB(beanName=<a name>)
private xyzManager xyzSession;

+How does xyzSession relate to "<myapp>/<myfacade>/remote", or is it something completely different? If completely different, why mention it?

If is is the same, why is it not:+

@EJB(beanName=<a name>)
private <myfacade> xyzSession;

Sorry Peter I should have made this clearer. I have re-examined the code and what I said is not correct. The myfacade class is a remote interface and decorated with:

@Remote

It extends a set of other interfaces but those interfaces are decorated with @Local, they are NOT remote.

It extends one interface which has no decoration. Rather oddly the implementing class for that interface is decorated thus:

@Stateless(name="ControlledValueManager")
@Remote(value={ControlledValueManagerRemote.class})
public class ControlledValueManagerBean implements ControlledValueManagerLocal, ControlledValueManagerRemote

I don't understand this but I don't see how it can be the cause as the bean seems to be running and the JNDI name seems set.

So I think this is okay. The class contains most of the client calls and uses the other helper beans to do the work.

It uses dependency injection for the helper beans. I suppose the clue was in the name of the class!!

Here are some real examples from the code:

@EJB(beanName="ServiceManager)
private ServiceManager serviceSession;
 
@EJB(beanName="InstanceManager")
private InstanceManager instanceSession;
 
@EJB(beanName="SearchManager")
private SearchManager searchSession;

Each interface is @Local.

+Also ,the reference object looks OK - it would appear to be a reference for a "ProxyFactory/myapp/myfacade/myapp/myfacade/remote" which

seems to indicate that if you cast it to myfacade you should be OK. That is verififed by this info:+

+Type: Remote Business Interface+

+Content: <package>.interfaces.myfacade+

Okay. It looks like a standard java ClassCastException. So we are trying to cast a javax.naming.Reference to a package.interfaces.myfacade and that fails which I would expect from J2SE. The error output is:

Connecting to server localhost:1099
2010-01-26 09:47:06,022 DEBUG ContextFactory:41 - Connecting to localhost:1099
2010-01-26 09:47:06,025 DEBUG BeanFinder:57 - Looking up bean: myapp/myfacade/remote
2010-01-26 09:47:06,243 DEBUG BeanFinder:68 - Completed bean lookup
java.lang.ClassCastException: javax.naming.Reference cannot be cast to package.interfaces.myfacade
 at package.mySession.<init>(mySession.java:64)

I believe it used to be necessary to do a PortableRemoteObject.narrow (Object obj, Class cls) to cast the returned remote proxy to the correct type but that is no longer necessary with EJB 3? Is the same thing happening but now hidden somehow?

Otherwise surely you would expect a ClassCast because a javax.naming.Reference is not a package.interfaces.myfacade?

+The console log showed a couple of warnings:+

+I don't think that the warnings have anything to do with this particular problem - as long as the name shows up in the JNDI tree, you should be

able to look up the EJB. Of course, you might run into issues later with accessing entity beans.+

Yes that was what I thought. Hibernate issues would presumably not affect the naming service, only trying to use persistence.

+Where does the client live - the one that is looking up the EJB?+

I am running the client which is a java thick client via Eclipse on my MacBook Pro along with JBoss.

The databases are on a local dev server.

Frustrating as it seems to be running fine but the attempt to use it is failing...

[jvm]

Ah one thing looks odd. Here is the output of the Refeernce that is returned by the lookup:

Class factory: org.jboss.ejb3.proxy.impl.objectfactory.session.stateless.StatelessSessionProxyObjectFactory

Proxy for: package.interfaces.MyFacade

Looks fine. But the addrs vector contains the following:

Type: ProxyFactoryKey

Content: ProxyFactory/myapp/MyFacade/myapp/MyFacade/remote

Type: EJB Container Name

Content: jboss.j2ee:ear=myapp.ear,jar=beans.jar,name=MyFacade,service=EJB3

Type: Proxy Factory is Local

Content: false

Type: Remote Business Interface

Content: package.interfaces.MyFacade

Type: Remoting Host URL

Content: socket://127.0.0.1:3873/

The proxy factory key looks odd as it repeats myapp/MyFacade twice. Is this correct? Or a clue to the issue?

[jvm]

Peter,

I have pursued some investigation of whether it is a ClassLoader issue having read some other posts and linked pages. The full definition for the identity of a class is the combination of class loader + FQDN of the class.

(1) Display class info for a bean

I tried running http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=JMImplementation%3Aservice%3DLoaderRepository%2Cname%3DDefault

and doing a lookup of class info for MyFacade which gave:

MyFacade Information
Not loaded in repository cache

The context here was fixing a ClassCast due to the fact that classloaders were different when multiple instances of a class are present in the AS. You then two multiple entries when looking up class info. Presumably you expect a single entry for the class but I don't see any entry. Not sure if this is significant?

(2) Dump classloader names

I ran the client again and printed out the classloaders for returned object from the lookup.

Returned object from lookup:

classloader was null (which some implementations return to signify the bootstrap classloader)

Client interface being cast to (myFacade):

classloader was sun.misc.Launcher$AppClassLoader@<hex addr>

So this looks like it could be the problem?

Not sure whether this is a red herring and how to fix it?