-
1. Re: Name lookup fails, reason unknown
peterj Jan 21, 2010 1:36 PM (in response to jvm)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
-
2. Re: Name lookup fails, reason unknown
jvm Jan 22, 2010 5:06 AM (in response to peterj)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.
-
3. Re: Name lookup fails, reason unknown
jvm Jan 22, 2010 6:10 AM (in response to 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>
-
4. Re: Name lookup fails, reason unknown
peterj Jan 22, 2010 10:46 AM (in response to jvm)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.
-
5. Re: Name lookup fails, reason unknown
jvm Jan 25, 2010 12:52 PM (in response to peterj)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.
-
6. Re: Name lookup fails, reason unknown
peterj Jan 25, 2010 1:02 PM (in response to jvm)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.
-
7. Re: Name lookup fails, reason unknown
jvm Jan 25, 2010 1:58 PM (in response to peterj)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 EventContextThank you. -
8. Re: Name lookup fails, reason unknown
peterj Jan 25, 2010 3:26 PM (in response to jvm)"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?
-
9. Re: Name lookup fails, reason unknown
jvm Jan 26, 2010 5:30 AM (in response to peterj)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, ControlledValueManagerRemoteI 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" whichseems 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:10992010-01-26 09:47:06,022 DEBUG ContextFactory:41 - Connecting to localhost:10992010-01-26 09:47:06,025 DEBUG BeanFinder:57 - Looking up bean: myapp/myfacade/remote2010-01-26 09:47:06,243 DEBUG BeanFinder:68 - Completed bean lookupjava.lang.ClassCastException: javax.naming.Reference cannot be cast to package.interfaces.myfacadeat 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 beable 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... -
10. Re: Name lookup fails, reason unknown
jvm Jan 26, 2010 5:50 AM (in response to 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?
-
11. Re: Name lookup fails, reason unknown
jvm Jan 26, 2010 7:00 AM (in response to 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?