wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes RMI stub classes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "RMI stub classes " Watch "RMI stub classes " New topic
Author

RMI stub classes

Marcos Motta
Ranch Hand

Joined: Apr 28, 2002
Posts: 56
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

Joined: Jul 30, 2003
Posts: 493
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


SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
Marcos Motta
Ranch Hand

Joined: Apr 28, 2002
Posts: 56
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

Joined: Jul 30, 2003
Posts: 493
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

Joined: Apr 28, 2002
Posts: 56
Bharat,
My client manifest goes like this:

Marcos
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11432
    
  85

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


    The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
    Marcos Motta
    Ranch Hand

    Joined: Apr 28, 2002
    Posts: 56
    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

    Joined: Mar 28, 2003
    Posts: 11432
        
      85

    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.
     
    subject: RMI stub classes