Hi,
I see you still want to implement alternative RMI . I can't understad this.
1. RemoteException. "}catch(ARMIRuntimeException are){" is it better ?
You handle fatal exeptions, don't you ?
Generate wrappers for remote interfaces, and you will not have any problems
with remote exception handling.
2. Remote interface. RMI must know how to marshal objects, by value or by
reference. Remote interface tells this.
Your ARMI knows this, don't it ? Have you a better solution ?
3. You want to have same remote and local interfaces. Use factory design
pattern and generated wrappers if your code does not depend on marshaling.
4. You want to use alternative transport. Is it JAVA RMI problem ? Use
java.rmi.server.RMIServerSocketFactory and
java.rmi.server.RMIClientSocketFactory, it is possible implement RMI over
ARMI :).
5. Most of distributed applications hosted by EJB servers, Is ARMI useful
for j2ee application ?
I see no ARMI advantages. Use RMI, well known design patterns and you will
have portable and good code.
I thing it can be useful project if you use standard JAVA RMI, implement
code generators for wrappers, IDE plugins, alternative
transports, default remote exception handlers, write documentation for RMI
design patterns.
At 18:41 2002-01-03 +0000, you wrote:
>Folks,
>
>Any thoughts for ARMI (though it needs a rename as "Async RMI" already
>used). Is commons the place for it? Yes/No?
>
>Regards,
>
>- 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]>
