M, You've been a JavaRanch member for nine months, and posted nearly 100 times, and still your display name doesn't comply with the JavaRanch rules. How do you manage to do it?
Anyway, regarding your question, my guess is that you have a CLASSPATH problem. It looks like your client cannot find the (EJB) home object stub.
Unfortunately, based on the [incredible lack of] information you have provided, I cannot be more specific. Perhaps you should look through other postings in this forum to get an idea of what details you need to provide in order to get more helpful answers.
Originally posted by Jeanne Boyarsky: One thing you can do to help debug this is to add System.out.println(homeObject);
before doing the cast. This will tell you what java thinks that class is.
Avi, "M Burke"'s name is fine. If you double check the naming policy, it states "You can even use initials for the first name if you like."
Hi Jeanne, It printed out what I expected, entities.Entity1LocalHome. But I did just notice something when I did the JNDI lookup, I got this warning...
ConnectionFac I J2CA0122I: Resource reference ejb/entities/Entity1LocalHome could not be located, so default values of the following are used: [Resource-ref settings]
I am using IBM Websphere as a server, and Oracle 9 as a DB. Could it be a Oracle to IBM problem?
I did set the jndi name in the server as a datasourse. I saw a message when the server was starting up: Binding Data source 1 as ejb/entities/Entity1LocalHome [ March 27, 2005: Message edited by: M Burke ]
While you should fix the warning (check your resource reference settings - container should be used), this isn't causing the error.
Are you getting a classcast error? I remember seeing or inferring that, but I can't find it in the original post now. In WebSphere, I've gotten classcasts in the past when the class name appeared to be correct. It could be one of two things: 1) The stubs are out of synch - try regenerating code 2) You are pointing at two versions of the code - check the classpath
ejb/entities/Entity1LocalHome could not be located
Exactly what I said: Your client cannot find (either) the stub (or the interface).
However, I just realized that your lookup name -- "Entity1LocalHome" -- implies a local interface (and not a remote one). While a lookup name can be anything you like, perhaps you are trying a remote lookup of a local interface. (And I'm pretty sure that's not going to work!)
Now you say "Entity1LocalHome" is the lookup name of a datasource, but isn't it supposed to be the name of an entity EJB's "home" interface? Maybe you need to re-read the example you are trying out, here?
Good Luck, Avi.
Joined: Jan 09, 2001
Keep the generated stubs in classpath. It solves the problem..
Joined: Feb 17, 2005
To confuse you even more, I’ll tell you that you don’t need any stubs in your classpath. Modern containers use dynamic proxies and all you need in your client jar or your ejb-jar is the bean class and remote/home (with their local siblings) interfaces. Most of these could be generated with tools like ejbgen or XDoclet. Bottom line is that if you pack your ejb correctly, providing all these java classes and you’re using correct deployment descriptors then it must work. One more thing you can try is to use your container’s tools and check the jndi tree; check if your bean bounds into the jndi tree correctly. You also might check whether you use ejb references or not. Finally your way of doing intrigued me:
I did set the jndi name in the server as a datasourse. I saw a message when the server was starting up: Binding Data source 1 as ejb/entities/Entity1LocalHome
What do you mean by this: did you really create a data source with this name? Well that’s wrong then, because you cannot bind two different objects with the same compound name into the jndi. You’ll end up having a data source with this name: ejb/entities/Entity1LocalHome but wen your container will read your deployment descriptor and try to deploy the bean will fail. I believe the exception you’ll get is NameAlreadyBoundException, or something like that and you’re probably not doing this. Please clarify this first. Ultimately you might send me your sources and your ejb-jar file and I’ll try to deploy your application to Weblogic 8.1 and let you know if it works. It's your call though ... Regards.
I think, therefore I exist -- Rene Descartes
Joined: Jun 25, 2004
I am sorry about my lack of clarity, but I am new to ejb's.
I did regenerate. In fact, Websphere prompts you to if you make any change. I only have one copy of the code.
In the WP EJB Deployment descripter editor, I set Entity1 bean to WebSphere Binding -> jndi name to 'ejb/entities/Entity1LocalHome'.
And in JNDI - CMP factory Connection Binding -> JNDI name I set it to jdbc/TestEjb. (I had this wrong before)
I then created the binding for the server and it generated a jndi entry (jdbc/TestEjb) for the CMP. But it created nothing for 'ejb/entities/Entity1LocalHome' (I'm not sure it should)
I wonder if it's a problem specific to Oracle running on WAS. [ March 28, 2005: Message edited by: M Burke ]
For what it's worth, we are using CMPs with Oracle and WAS. So it can be done
Did you check the std_err logs? Sometimes WAS puts useful information there.
I think the lookup is fine becauase you get an object of the correct type when doing the println. The other thing I can think of to check is the classloader settings for the EAR. It's possible that something is masking the classes you need.
Joined: Mar 05, 2003
You should set the bean's <local-jndi-name> in stead of <jndi-name> to that jndi name you are looking up. Since you are doing a localHome lookup. [ March 30, 2005: Message edited by: Peter Ye ]
Joined: Jun 25, 2004
Well, I think I am missing a step somewhere along the line. I found a step by step giude to make entity beans in Websphere. I will follow it and see what I am missing.
Session beans are no problem for me. Looks like there are extra steps for local home jndi beans.
Joined: Jun 25, 2004
Well, I got it to work, with Cloudscape anyway. There was a problem with my Websphere install. So I reinstalled it and it works now. It seems Websphere needs to be refreshed every so often.