Peter, >><survey> >> Have any regulars actually tried AltRMI yet? >> Thouhts? >></survey> >> > >I tried it a bit back but haven't had a chance to try it again ;) > Well it has changed a little. More transports, more robust. This might help for those that have little time ( pasted from a private email ) :
Proposal : http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/altrmi/PROPOSAL If you (like me) are example orientated, then this should help: Consider an interface......... http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/test/TestInterface.java And the serverside class that implements it...... http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/test/TestInterfaceImpl.java Now it's use on the client side.......... http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/test/SocketClientTest.java ( The the smallest code would be ) ........ ArmiFactory af = new ServerClassAltrmiFactory(false); af.setHostContext(new SocketObjectStreamHostContext("127.0.0.1", 1234)); TestInterface ti = (TestInterface) af.lookup("Hello"); new TestClient(ti); // client performs tests and is blind to where the impl is. The crucial bit is the interface. It is not special. It does not extends Remote. It does not have "throws RemoteException" on every method. It is just a normal* Java interface. * Should, but not has to be designed along facade pattern lines. Regards, - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
