Fight EJB (2)

Our ultimate goal is to call EJB on different machines. Now we have to experience distributed architecture.
Set up a server on another machine, deploy the EJB, and change the IP address in the client code to prepare and run!
Succeeded?
What I expect is a failure.
If you see greetings from remote connection, don't be excited. check whether a J2EE Ri is running on the machine running the client?
I am calling remote ejbs. What is the relationship with the server on my local machine? Don't worry about this. Shut it down.
Congratulations, the Code finally failed normally.

Who is willing to face failure? If a problem occurs, we need to solve it.
The exception prompt is a good start point.
Javax. Naming. communicationexception: Can't Find serialcontextprovider
At com. Sun. Enterprise. Naming. serialcontext. getprovider (serialcontext. Java: 63)
At com. Sun. Enterprise. Naming. serialcontext. Lookup (serialcontext. Java: 120)
At javax. Naming. initialcontext. Lookup (unknown source)
......
Obviously, this is not a good reminder, because we cannot get more information from the exception information, but we know the class with the error.
Fortunately, sun's J2EE RI source code is open, which saves the trouble of decompiling class files.
Open Com. sun. enterprise. naming. in the serialcontext class, find the getprovider. One of the debug variables has aroused my interest. This is a sign of debugging. If you set it to true, some debugging information will flow out.
I have affirmed my idea and changed Debug. But how can I compile the source code?
I don't want to bother compiling the huge source code of J2EE Ri. After all, all I need is to change one of the classes, rather than studying the entire J2EE Ri.

Use your usual magic weapon to create a project in your ide. After creating a project, directly add the jar files containing the target class (some jar files may be compared) to the project, in this way, all the content required for compiling this class will be available.
I have taken my target class and put it into the project according to the package structure, so that the code can be compiled normally.
After the changed class file is inserted into the jar file, my changes will start to play a role.

Through modification, we can have more information.
Org. Omg. CORBA. comm_failure: vmcid: Sun minor code: 201 completed: No
At com. Sun. CORBA. ee. Internal. IIOP. connectiontable. getconnection (connectiontable. Java: 176)
At com. Sun. CORBA. ee. Internal. IIOP. connectiontable. getconnection (connectiontable. Java: 68)
At com. Sun. CORBA. ee. Internal. IIOP. giopimpl. getconnection (giopimpl. Java: 70)
......
What is a CORBA error? Yes, it is. This is not easy to handle. Although I have heard of the intricate relationship between ejbs and CORBA, I am a layman of the standard CORBA.
After making up my mind not to start learning CORBA from scratch, I decided to continue to explore the cause of the problem using the previous method.

The opposite result is that I found such information.
Com. Sun. CORBA. ee. Internal. IIOP. giopimpl (thread [main, 5, main]): getendpoint (iiop_clear_text, 0, null)
Com. Sun. CORBA. ee. Internal. IIOP. giopimpl (thread [main, 5, main]): createlistener (sockettype = iiop_clear_text Port = 0)
Com. Sun. CORBA. ee. Internal. IIOP. connectiontable (thread [main, 5, main]): client get called: host = localhost Port = 1050
Com. sun. CORBA. ee. internal. IIOP. connectiontable (thread [main, 5, main]): exception Java. lang. runtimeexception: Connection refused: connect while creating socket for new connection: Aborting connection
Com. Sun. CORBA. ee. Internal. IIOP. connectiontable (thread [main, 5, main]): deleteconn called: host = localhost Port = 1050
Com. Sun. CORBA. ee. Internal. IIOP. connectiontable (thread [main, 5, main]): client get called: host = localhost Port = 1050
Strange! Localhost is displayed here. Intuitively, we clearly write in the code that calls remote ejbs, and there should be no localhost at all. The fact is that it is strange that we should go to localhost when calling it, which is why we can see greetings from afar if a J2EE Ri is initiated on the local machine.
It gave me a new direction when I wondered how to proceed.
I pulled up the related documents of J2EE Ri. Yes, I have been exploring it myself.
In the J2EE SDK tools documentation, runclient has a section titled "accessing a remote server", which is obviously a big touch to me.
The attribute org. Omg. CORBA. orbinitialhost is mentioned ".
By setting this attribute, you can access remote EJB ???
What are you waiting?
We know that using-D to define an attribute during Java runtime has the same effect as using system. setproperty directly in code, so the following code appears:
System. setproperty ("org. Omg. CORBA. orbinitialhost", "XXX. XXX ");
Run and pray!
Greetings from far away finally appeared in front of me. I believe that the excitement is the feeling that programmers are willing to appreciate it after countless experiences. I am willing to equate this feeling with drug abuse. It is completely an addiction, which makes me willing to face the challenges again and overcome one difficulty after another.

"Looking for her in the crowd, suddenly looking back, that person is in the dark"
It should be said that my habits are not good. When I poll my brains, I did not think that I had the best answer when I waved Google to search around.
To solve the problem in the future, you must first understand the content in the relevant documents.