Re: Minutes from AvalonCon #1

[Paul Hammant]

Peter,
Even if we were to create
Avalon Method Invocation we would still need a AMIException for the same
use anyways,
Yes but extend RuntimeException not Exception.  GLUE does this and it is
seamless.
I like the fact that Remote is not a runtime exception. It forces the 
developer to write code that behaves nicely in a distributed environment. You 
should be catching this down low and dealing with them gracefully IMHO ;)

It forces the developer to catch RemoteException at each invocation of a 
remote method.  What to do with it?  I catch a lot of coders declaring 
it in throws to decrease the amount of code they have to write, suddenly 
you find throws RemoteException proliferating around a system.  What to 
do with it?  Try again? Hmm, Typically people have new exceptions like 
"QuoteServiceFailedException" and wrap the remote in that before 
throwing it.  I've had nothing but misery since 98 with RemoteException. 
It's a major pain in the ass that, strictly speaking, you can't even 
test.  No I really do prefer handling wobbly connections at a single 
handler level in an API.  Plenty of others do too.  Take a look at 
Glue's examples Peter ( 
http://www.themindelectric.com/products/glue/releases/GLUE-1.3/docs/guide/exceptions.html 
-> sample calculator exception is simple enough).

About the only thing that really and truly sucks about RMI is that you have 
to have two versions of interfaces and that your implementation has to 
implement the Remote version (bleck!!!). 

Agree it sucks. Not agree on "only".
They fixed this in EJBs because now EJBs no longer have to implement the 
remote interface - yaya!!!!! I have thought about doing a proxy/wrapper/stub 
compiler that just exported local version and was automagically generated. In 
a perfect world the setup per class would be something like

interface Foo 
{ 
 void doStuff();
}
class FooImpl implements Foo {}

interface RemoteFoo extends Foo
{
 void doStuff() throws RemoteException;
}
class RemoteFooStub extends RemoteObject implements RemoteFoo { ]
The first two would be human created while the second two would be computer 
generated.

I Just don't like it Peter.  

Now RMI should continue to be used for client to server comms (JAMES and 
FTPServer use it for admin), but I really donlt think we need it for the 
inter-sar communication.  Sun, sooner or later, are going to come along 
with a fresh replacement RMI.  They are not adverse to such efforts 
(look at nio package in JDK1.4).  That replacement is going to be a lot 
easier to use because it will be seamless.  The RMI registry needs an 
overhaul too.

Regards,
- Paul H

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>