• 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

ClientData problem

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My assignment states:
To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration.
Well, that means that this class (let's call it ClientData) will have to delegate to either the Data class for local mode, or for remote mode to RemoteData - a class which is sitting on the server side and accepts RMI method calls. Everything's clear, right? Not really! (at least for me).
This ClientData, when used in LOCAL mode will have to throw RemoteException for every method!!! That's stupid.. Of course i can do something like catching any exception thrown from the code of every method INSIDE the method, and then throwing an instance of a Runtime exception with appropriate message in it. This way nothing will have to be caught or declared. (don't know if it's a good idea or not). help, please
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by lev grevnin:
This ClientData, when used in LOCAL mode will have to throw RemoteException for every method!!! That's stupid..

Why? It's merely an expression of the fact that your ClientData may encapsulate a Remote implementation. This is the same as complaining that java.io.BufferedReader.close() still throws IOException when it's used to wrap a CharArrayReader. Of course it does. It's an expression of the fact that BufferedReader can wrap any kind of Reader, including the ones that can throw IOException in close(). If you just want a purely local implementation, you can use Data directly.

Of course i can do something like catching any exception thrown from the code of every method INSIDE the method, and then throwing an instance of a Runtime exception with appropriate message in it. This way nothing will have to be caught or declared.

But what's the point? You are just throwing away the benefit of checked exceptions and make exception handling more difficult. Not a good idea IMHO.
- Peter
 
lev grevnin
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter,
in my previous thread "Data Client Constructors" you said:

My understanding is merely that you will have some client-side "Data-like object" in networked mode. (I suspect that Sun included this requirement to force your architecture into a certain direction; there have been a number of posts about this). This object will have constructors that are different from those of Data for the simple reason that the networked mode works completely differently.
My understanding is also that there is a requirement for this object to exist. That doesn't mean you have to write that class yourself; an rmic-generated class can well satisfy the requirement. I personally used RMI in my project, and had a server-side Remote class implementing the Data interface. The rmic-generated stub for this class satisfies the requirement quoted above in every respect.


VERY ORIGINAL SOLUTION! I'd never thought of that... This statement from a different thread actually answers better the problem i posed in this thread. Just use the RMI stub for remote mode and use the Data class directly for local mode, to put it simply, right??
thanks again,
-lev
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by lev grevnin:
VERY ORIGINAL SOLUTION!

I think it's far from original, although I must admit feeling rather chuffed when I first came up with it

Just use the RMI stub for remote mode and use the Data class directly for local mode, to put it simply, right??

That's exactly what I did. Code the client to access a DataInterface. Have exactly two implementations of this interface, one local (Data), one Remote. The simplest thing that could possibly work. The assessor was happy enough with it.
- Peter
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic