Excuse me, but Paul answered the exact opposite of what you meant. AltRMI is intended to make the whole remote call transparent, while you said:
>From Paulo Gaspar: > Your app will always be more robust if you do NOT ignore the > specific issues of a remote call. Not that it matters much; I just wanted to ask you why you think your app is more robust if you have to handle specific remote exceptions. The world seems to be spinning the other way (as in GLUE, AltRMI). Un saludo, Alex. > -----Mensaje original----- > De: Paulo Gaspar [mailto:[EMAIL PROTECTED]] > Enviado el: viernes 1 de febrero de 2002 14:20 > Para: Jakarta General List > Asunto: RE: [OT] J2EE considered harmful > > > Paul just answered to what I meant in a better way than I > would be able > to do. > > BTW Paul, you know JAspect and Dynamic Proxies don't you? > > > Have fun, > Paulo Gaspar > > > -----Original Message----- > > From: Paul Hammant [mailto:[EMAIL PROTECTED]] > > Sent: Friday, February 01, 2002 12:44 PM > > To: Jakarta General List > > Subject: Re: [OT] J2EE considered harmful > > > > > > Alex, > > > > My experience is that people either immediately decide they > like AltRMI > > or strongly dislike it. One of my strongest critics (in > commons mail > > list) is coming round to it after much effort :-) > > > > For many it is inline with something they have felt for > ages : Remote > > interface and RemoteException suck. Many other are quite > happy with RMI > > as is and always have been. > > > > AltRMI is really about remote publishing an object via it's > normal Java > > interfaces. It also has local publishing capabilities for complex > > classloader situations. > > > > >I do not agree with that. More robust how? > > > > > You can set retry policies. In the middle of a method > invocation and > > unknown to the caller, the connection can be reestablished. > It is a > > programmable API in that the developer can choose between the two > > extremes "never retry, log & fail imediately" and "retry > eternally". > > > > >If you want to signal that something can go wrong on the remote > > side, throw > > >an exception; if you want to signal that the remote > connection does not > > >work, then delay the call and/or send a runtime exception. > > > > > Or a derivative (AltrmiInvocationException). You can catch > it or not. > > In the case of 'not' I'd hope the container/handler knows > what to do > > with it . > > > > >Otherwise, what is the purpose of AltRMI? I thought it was > to avoid the > > >cumbersomeness of throwing RemoteException all the time. > > > > > It is. > > > > I've started a project "Enterprise Object Broker" at > Sourceforge to try > > out the use of AltRMI. -> http://eob.sourceforge.net/ > > It is Apache license, and if it is any good and has built a > community, I > > think Jakarta would be its natural home. > > > > - Paul H > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
