This content has been marked as final. Show 6 replies
Hmm, very basic, lots of errors.
Completely misunderstands the RMI bootstrap problem, which is really about how to get the initial stub used (e.g. the Registry or ActivationSystem stubs). The Registry is not by itself a solution to this, just another instance of the problem, but the LocateRegistry.getRegistry() method is, as it creates a Registry stub entirely from local materials without executing any RMI calls.
'A stub is created by the Naming class at the server'. Nonsense, stubs are created when exporting servers and are substituted for remote objects during marshalling, and this takes place for ]i\every RMI call.
'A stub is created by the Naming class at the server'. ... I agree with you. Good remarks.
Please furninsh more info on the online resources regarding the same, if you know any.
You don't really want to know much of this but it's discussed in my book (see below).
I sent the author of this article some feedback as follows:
Your article contains several errors.
1. You state the RMI bootstrap problem correctly but you incorrectly state that the Registry is the solution. Actually the Registry, being a remote object itself, is really just another an instance of this problem, not a solution to it. The solution is contained in the LocateRegistry.getRegistry() method, which creates a Registry stub entirely from local materials including the host+port supplied in the argument list.
2. You are incorrect in stating that you shouldn't use 'localhost' in Naming.bind()/rebind(). This is actually the only value that makes sense, as you can only bind to a registry in the local host anyway. You can certainly specify the full external host name if you wish, but there is little or no point, and you have just made your server application non-migratable. It is clients who must use the correct external hostname, and getting this wrong is a common beginner's error.
3. You are incorrect in asserting that Naming.lookup() creates stubs. RMI wouldn't be much use if you could only get a remote stub from Naming.lookup(). Actually stubs are created when an RMI server is exported, and it is the marshalling process which converts remote objects to their stubs. This occurs for every remote object in the object graph for each remote argument or result, not just for the tiny case of the result of Naming.lookup().
4. Skeletons are about six years out of date. It is untrue that 'were incorporated into the server itself'; rather, the RMI protocol was revised in JDK 1.2 to contain enough information for reflection to be used instead of a skeleton.
5. The getClass() method predates the Reflection package by some years, so stating that 'A stub is created by the Naming class at the server. For getting the stub class, it uses the Java Reflection feature' is doubly incorrect.
6. The technique you show for creating a stub is unnecessarily complex. Why woudn't you just use RemoteObject.toStub(Remote)?
7. As a matter of style your 'questions revisited' are really 3 not 5. This is just a waste of space and time.
author 'java.rmi': http://www.rmiproxy.com/javarmi
Hi Esmond ,
Thanks for your comments,
I will be doing more research on the same and will be correcting the errors.
By the way, i didnt get any of your mails.
It is really an honour to get an expert's feedback on a novice's article.
Thanks once again for your wonderful observations.
Ahamed Aslam K
Hmm, 10 weeks later and no changes.
Hmm, seven years later and no changes!