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

Jakub Korab

Greenhorn
+ Follow
since Feb 04, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
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.
Jake
Try
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.
Jake
Thanks Janne, that clears it up.
Hi,
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.
Jake
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();
client.go();
}
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
System.out.println(advisor.getAdvice());
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
-----
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 com.sun.corba.ee.internal.iiop.messages.ReplyMessage_1_2.getSystemExc
eption(ReplyMessage_1_2.java:93)
at com.sun.corba.ee.internal.iiop.ClientResponseImpl.getSystemException(
ClientResponseImpl.java:108)
at com.sun.corba.ee.internal.POA.GenericPOAClientSC.invoke(GenericPOACli
entSC.java:132)
at org.omg.CORBA.portable.ObjectImpl._invoke(Unknown Source)
at headfirst._Advice_Stub.getAdvice(Unknown Source)
at AdviceClient.go(AdviceClient.java:39)
at AdviceClient.main(AdviceClient.java:10)
-----
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,
Jake