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]>
