• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

nx:URLyBird RMI registry and server startup

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm thinking about is it a good approach to require manual starting of RMI registry with classpath set to runme.jar before starting of the server?
I know - there are alternative approaches, like creating of registry on application startup by means of LocateRegistry.createRegistry or specifying the system property: java.rmi.server.codebase=<path to server classes>, but to my oppinion those ways have serious drawbacks:
- LocateRegistry.createRegistry - it does not allow to place RMI registry on remote machine.
- java.rmi.server.codebase property - this approach contradicts with the requirement - "You must provide all classes pre-installed so that no dynamic class downloading occurs". The server still can be run this way if the user who starts the server specify this property in command
line using -D key of JVM, however, this approach voilates another requirement - "Your programs must not require use of command line arguments other than the single mode flag".
It is possible to combine those approach, e.g. check if the RMI registry is available and start it in case of its absence by LocateRegistry.createRegistry, but such a solution
will add superfluous complexity to the entire project.
I want your judgement on my decision to require manual starting of rmiregistry with properly set classpath.
 
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Alexei,

Originally posted by Alexei Antipin:
I'm thinking about is it a good approach to require manual starting of RMI registry with classpath set to runme.jar before starting of the server?

No. If submission A requires the examiner to manually start the RMI registry (which means you have to explain in the user's guide how to do this), and submission B doesn't require the examiner to do anything regarding the RMI registry, which do you think the examiner is likely to prefer.

I know - there are alternative approaches, like creating of registry on application startup by means of LocateRegistry.createRegistry

That's the solution I recommend.

or specifying the system property: java.rmi.server.codebase=<path to server classes>,

I'm not sure how this helps the RMI registry?

but to my oppinion those ways have serious drawbacks:
- LocateRegistry.createRegistry - it does not allow to place RMI registry on remote machine.

Why would you want to place the RMI registry on a remote machine? When I start my application in server mode on a computer I want to use that computer as the database server. Therefore I want to have the RMI registry started on that machine.

- java.rmi.server.codebase property - this approach contradicts with the requirement - "You must provide all classes pre-installed so that no dynamic class downloading occurs".

I agree that you cannot use dynamic class downloading.

The server still can be run this way if the user who starts the server specify this property in command
line using -D key of JVM, however, this approach voilates another requirement - "Your programs must not require use of command line arguments other than the single mode flag".

I agree that you can't use command-line arguments (except for the single mode flag).

It is possible to combine those approach, e.g. check if the RMI registry is available and start it in case of its absence by LocateRegistry.createRegistry, but such a solution
will add superfluous complexity to the entire project.

I don't think this is superfluous, I think it's necessary. I think that candidates whose submissions make the examiner do more work than the minimum necessary are asking to lose points.

I want your judgement on my decision to require manual starting of rmiregistry with properly set classpath.

If you're determined to start the RMI registry outside of your application (which I think is a bad decision), then at least can you create an executable jar file that does that without requiring the user to properly set the classpath. The user of my project doesn't even have to know what a classpath is.

 
We begin by testing your absorbancy by exposing you to this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic