File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

RMI stub classes

 
Marcos Motta
Ranch Hand
Posts: 56
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Marcos Motta
Ranch Hand
Posts: 56
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Marcos Motta
Ranch Hand
Posts: 56
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bharat,
My client manifest goes like this:

Marcos
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11831
181
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marcos
I think you already know the advantages.
Potential disadvantages:
  • may not be possible to use external RMI Registry
  • 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).


  • Regards, Andrew
     
    Marcos Motta
    Ranch Hand
    Posts: 56
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks again Andrew (you really read all of these messages! amazing)
    Just to see if I understand the limitations:

    may not be possible to use external RMI Registry

    why? anything related to security policy?

    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).

    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?
    thanks
     
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander
    Pie
    Posts: 11831
    181
    C++ Firefox Browser IntelliJ IDE Java Mac Oracle
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Marcos,
    (you really read all of these messages! amazing)

    Sad isn't it?
    [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
     
    Don't get me started about those stupid light bulbs.
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic