This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
Hi, I included all RMI stub classes in the client jar file to avoid configuring codebase, policy file and security manager. Everything works perfect on all OS I tested: Linux, Win2k, WinXP, Mac. But, I am wondering what I have missed by doing this because I will probably have to defend this approach in the essay and I realized that I dont know all of the pros and cons. What am I missing? thank you
Hey Marcos, I don't know which assignment you are doing, but you wrote:
I included all RMI stub classes in the client jar file to avoid configuring codebase, policy file and security manager. Everything works perfect on all OS I tested: Linux, Win2k, WinXP, Mac.
Why are you including a security manager? I am not yet done with my assignment, but there are a number of threads here that say that you don't have to or you shouldn't be needing/installing a security manager. Just a word of caution! My assignment certainly and explicitly states that we do not need to be concerned with the security manager. Regards. Bharat
Joined: Apr 28, 2002
Bharat, I apologize for not being clear enough. I did not used any SecurityManager; the user is NOT required to configure any codebase environment variable or policy file. The inclusion of the stubs in the client jar allowed me to avoid this complicated stuff. The codebase is required if the client has to download the stubs. The security manager is used to check permissions related to the download process. The security manager is likely to use a policy file to retrieve the configured permissions. I have bypassed all of these configuration when I put the stubs accessible from the client's class path. My question is: What are the disadvantages of this approach? Marcos
Joined: Jul 30, 2003
Hello Marcos, You wrote:
I have bypassed all of these configuration when I put the stubs accessible from the client's class path
How do you define client's class path? Do you have an environment variable defined or do you have this defined within the Manifest file contained in the JAR file? If it is latter then you are OK in my opinion. I may be wrong however. Regards. Bharat
[Andrew] may not be possible to use external RMI Registry [Marcos] why? anything related to security policy?
I was thinking more of the way most people start the registry programattically, and just exit the program if they cannot start their own registry. But since we are talking about security, there is another potential problem with people starting their own registries. If you don't have a security manager, then no other application can bind to your registry. This is something you probably only want to make a note of, because we don't really want to be adding a fully fledged security manager to our application. But if we don't allow the port number to be changed, we don't attempt to bind to an already running registry, and we don't allow anyone else to bind to our registry
[Andrew] since stubs are local to client, if ever you change server side, you will have to provide clients with new stubs (rather than the client dynamically downloading them as required). [Marcos] This is because the client is tied to a specific remote interface but the server can use different implementing classes and the client will download them as needed?
Yes. Or even the server changes something minor which results in a new version of the stub being generated with a different serialVersionUID, so the existing stubs no longer work. Regards, Andrew