Win a copy of Spark in Action this week in the Open Source Projects forum!

Jakub Korab

+ Follow
since Feb 04, 2004
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jakub Korab

Oops replied to the wrong message.
I got a very quick education in the subtleties of CLASSPATHs when I suddenly didn't have an Ant script.
D:\WorkSpace\JavaPlayground\EJB\Advice>java -cp %CLASSPATH%;AdviceAppClient.jar;. AdviceClient
instead of
D:\WorkSpace\JavaPlayground\EJB\Advice>java -cp %CLASSPATH%:AdviceAppClient.jar;. AdviceClient
Windows paths are semicolon seperated, you're using a colon before the jar file.
Thanks Janne, that clears it up.
There's something I'm have trouble with. I was going through an sample question in HFEJB to do with what could access what and it messed me up. To paraphrase:
You have a remote client 'R', that has valid references to session beans 'A' and 'B'. A is a local client to B.
Apparently, R can pass its reference for A to B. The handle(?) for A gets serialized and passed to B. I can live with that.
I'm assuming that R is in a different VM to A and B (remote), and that A and B share a VM (local). A has a local view of B.
Now what's just happened is that R has passed its remote view of A to B, presumably so that B can do something with A. Given that you can't mix remote and local syntax, B therefore has to reference A as a remote object, going through stub, EJBObject and then to the bean itself in order to call a method.
Firstly - is this actually legal? My impression was that you had to use a local view within the same VM. And if it is, why not just handle every bean via the remote syntax? Narrowing and checking for a RemoteExceptions doesn't seem like that big a price to pay for a standard way of handling all EJBs.
I'm definitely missing something here...
Jake <- I couldn't wait to use one of these things
Thanks Jayant. Recompiled with a new method name, and it ran through beautifully. It's such a relief to finally see it working, nothing worse than not being able to get the first sample app to run.
Hoping someone can help out with this. I'm getting some really strange behaviour on the intro application.
My environment:
Win XP
J2SDKSE 1.3.1_10
J2SDKEE 1.3.1
For people without the book, Stateless Session bean.
remote interface - headfirst.Advice
ejb class - headfirst.AdviceBean
remote home interface - headfirst.AdviceHome
I have deployed the sample application (JNDI name - "Advisor") into the J2EE RI server, having verified it using the deployment tool. Deployment went through OK, j2ee is happy - no errors.
I have an test class (some println's removed, so ignore the line numbers on the exception that follows...):
import javax.naming.*;
import java.rmi.*;
import javax.rmi.*;
import headfirst.*;
import javax.ejb.*;
public class AdviceClient {
public static void main (String[] args) {
AdviceClient client = new AdviceClient();
public void go() {
try {
// 1. get a reference to the JDNI InitialContext
Context context = new InitialContext();
// 2. use the context to do a lookup on the home interface of the bean
Object object = context.lookup("Advisor");
// 3. narrow and cast
AdviceHome home = (AdviceHome)
PortableRemoteObject.narrow(object, AdviceHome.class);
// 4. call create() on the home interface to get a reference to the
// component interface
Advice advisor = home.create();
// 5. use the component
} catch (Exception ex) {
At step 5, I get the following exception:
java.rmi.RemoteException: CORBA BAD_OPERATION 0 No; nested exception is:
org.omg.CORBA.BAD_OPERATION: minor code: 0 completed: No
org.omg.CORBA.BAD_OPERATION: minor code: 0 completed: No
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Unknown Source)
at org.omg.CORBA.portable.ObjectImpl._invoke(Unknown Source)
at headfirst._Advice_Stub.getAdvice(Unknown Source)
at AdviceClient.go(
at AdviceClient.main(
I checked some of the newsgroups, and the closest thing I could find was that the CORBA exception is caused by calling a method on the interface that is not implemented on the stub (I think, can't recall exactly).
I double-checked the bean class against the remote interface, and it's all good. Even got them both to extend/implement the same interface just to be certain (although the verifier probably catches this...).
If anybody has any ideas, it would be greatly appreciated. Cheers,