Thank Kathy......it helped.....
Ah... the now-infamous CORBA.BAD_OPERATION error...
Sorry I didn't even think to come over to this forum and check; I'll do that from now on -- this discussion has been going on over in the EJB cert forum, but then Johannes alerted me to this discussion, so here I am.
O'Reilly should have something up in the next day or two about this.
Here's the deal:
1) There's a bug in the J2EE RI, that only appears in some implementations (not yet sure which). Obviously, it doesn't appear on my current set-up (Linux distribution of J2EE 1.3.1, J2SE 1.3.1, running under OSX 10.2 and 10.3)
2) The *official* bug at Sun is documented a little differently, but I talked with someone from the J2EE team today, and here's the story...
* You can get this error if you have a Remote interface name that has a business method with a name that has matching characters!! Yep, that's it. And this workaround will definitely fix the BAD_OPERATION problem, assuming you've done everything else correctly.
* So the problem is that we have an interface that looks like this:
public interface Advice extends EJBObject {
public
String getAdvice() throws RemoteException;
}
// notice that getAdvice() contains a String matching the interface name. This is NOT a restriction of Java or even RMI, but once you get CORBA involved, naming problems can happen, and this is one...
3) To fix it, you need to:
* Change the component interface business method to something *other* than getAdvice(). So, you could change it to
public String getTheMessage() throws RemoteException
* Change the corresponding business method in the bean class
* Change the client code to invoke this method instead of getAdvice()
* Recompile everything.
* Now, you must recreate your enterprise bean and redeploy.
The safest way to do this (although it might be overkill) is to do the following:
* Run 'cleanup' (without the quotes) at the command-line. This will undeploy all of your applications (you probably only have one at this point), and restore the server to the way it was when you installed it. The logs are cleared, etc. along with the repository that holds your server's deployed applications.
* Be sure the server is shut down, and deploytool is shut down
* Delete your .ear file from your Advice directory (or wherever you have it).
* Delete any temp files that were put in that directory as well
* Restart the server
* Restart deploytool
* Start over making your AdviceApp, (follow the steps in the book again) and creating the bean... the only difference from the previous app is the name of the business method.
* Run your client
* Hold your breath (until it completes)
* Yay! Success.
Note: some people have found a different workaround, but it involves taking the classes out of their packages. Don't do this! Don't ask me why that workaround fixed this bug, but it's definitely not the right solution since you really do need these classes to be in packages.
So, keep *everything* exactly the same as it is in the book, except give the business method ANY name other than the one it has. And if you continue to use the RI, and you are on a system that produces this error, then keep that in mind when naming other business methods in other Remote interfaces.
And remember, if you *are* planning to take the exam, this naming problem is NOT an EJB rule -- it is simply a bug related to CORBA use in the RI.
Whew!
OK, so far, everyone who has tried this fix has been successful, so we're certain that this is indeed the problem.
On the Sun site, we never even thought to check for a bug report on this since I've never had a problem (I've also tested this code under Solaris, but haven't tried it on a Windows machine under J2EE 1.3.1...)
cheers and thanks for your patience,
Thanks to the quick work of the javaranchers, we've solved the mystery of the RI...
You can go back to having fun now
-Kathy
--------------------
