[ALTRMI] ClassRetriever patch

Paul, Patch to generate the exception correctly from classretrievers. [ getResourceStream does NOT raise any exception but returns a 'null' InputStream on failure to find a resource ] Regards, V i n a y Index: PlainClassRetriever.java

[ALTRMI] ProxyGenerator patch

Paul, We should generate proxies for calls declared in the remote interface ONLY , and should NOT generate calls in proxies for methods inherited from the base interface(or class) . Am I right ..? [See attached patch ] Regards, V i n a y Index: ProxyGeneratorImpl.java

Re: [ALTRMI] ProxyGenerator fix

Paul, I will give a look into the kewl work done on DGC front ... IMO we should have good unit tests too. Most of the tests that we have are actually samples/proof-of-concept works . Maybe we should have proper junit testcases going around. Thoughts ...? And thus the present so-called 'test'

[Altrmi] Callback iteration

Paul, Skeleton work on Callback It doesnt actually do the callback(:))) but just mocks the way we can acheive it. I have short-circuited the handling , and thus the tests work fine tooo (can you check the performance drop),only difference being the way data is read from the server.

Re: [Altrmi] PATCH Passing pf remote obj ' ref

Paul, I worked with a fresh CVS checkout and it (pipeda from tests.xml) target works well without any hiccups .. I wasn't able to reproduce it out at my machine . Morevoer the patch's that I sent second time doesn't seems to be commited(Passing_Facade.patch). Can you verify the way's I have

Re: [Altrmi] PATCH Passing pf remote obj ' ref

) Comments ...:-? Regards, Vinay --- vinaysahil chandran [EMAIL PROTECTED] wrote: Paul, I worked with a fresh CVS checkout and it (pipeda from tests.xml) target works well without any hiccups .. I wasn't able to reproduce it out at my machine . Morevoer the patch's that I sent second time

Re: [Altrmi] PATCH Passing pf remote obj ' ref

Paul, No excuses , I had NOT done *ant clean* before building the src after the changes .. Here is the patch that I missed ... But can you get the reason behind the getMethodInvocationHandler(MethodRequest mr,String objectName) .. Wont a more generic call like :

Re: [ALTRMI]-PATCH JNDI interface for Altrmi clients

3) your name has replaced mine as auther of the smaller class, as i did nothing really. :-)) haha 1) I hate the env.put() business of JNDI. Should we also provide a helper factory (optional use) that will make an InitialContext for comon types of transport? It would be a

[ALTRMI]-PATCH tests.xml

a typo cvs -q diff tests.xml (in directory C:\jcommons\cvs\jakarta-commons-sandbox\altrmi) Index: tests.xml === RCS file: /home/cvspublic/jakarta-commons-sandbox/altrmi/tests.xml,v retrieving revision 1.7 diff -r1.7 tests.xml

[ALTRMI]-PATCH DefaultMethodInvocationHandler,TestInterface*,SocketServerTest

Paul, The referenceID that is generated from within DefaultMethodInvocationHandler must be class level variable. The modified Testcases (I have done this excercise with only SocketServerTest , if you say I can do the same with other publish methods too) for the same also attached along with

Re: [ALTRMI]-PATCH DefaultMethodInvocationHandler,TestInterface*,SocketServerTest

Paul, You are absolutely right .. I was trying to merely test the grounds with another 3rd interface .. Neverthelesss it wud had definitely confused a newbiew for sure . Kewl, V i n a y --- Paul Hammant [EMAIL PROTECTED] wrote: Vinay, Paul, The referenceID that is generated from within

Re: [AltRMI] (PATCH) BEEP wire

Paul, My understandin was that XML exchanges were carried out to establish a session and henceforth its header+payload traveling back and forth.. I admit there would be some extra header info being passed here and there and moreover some sync' issues , but never expected the performance to

[AltRMI] (PATCH) BEEP wire

files :-)) ) We can benchmark it with Socket layer too. (It might performs well too compared to the '2 socket connection' approach when callbacks come into picture..) way to go ... Regards, V i n a y. --- vinaysahil chandran [EMAIL PROTECTED] wrote: Hey dude, you're scaring me with RMI

Re: [AltRMI] multiplexing over single connection

Paul, So would the right place to export an Object from an API standpoint be : AltrmiFactory.exposeObject(Object o); ? Regards, Vinay --- Paul Hammant [EMAIL PROTECTED] wrote: Vinay, Yes you are right BEEP looks better. There is a BSD impl on SF :-

Re: [AltRMI] multiplexing over single connection

Hey dude, you're scaring me with RMI interfaces! Sorry not my intention but somehow couldn't stop thinking of this example over Altrmi without much of an modification... Pub/Sub is just an fancy name for callbacks not so? Are we not talking about the same thing? We are ... Maybe I

Re: [AltRMI] Event Notifier

There was also that (LGPL) project at sourceforge that could multiplex any traffic over one connection. I guess BEEP protocol also address multiplexing over single TCP socket connection. http://www.beepcore.org Again there is a LGPL java beep library at sourceforge .

Re: [AltRMI] Passing stubs around

the repercussions it might have , but I guess this would be a much cleaner way . comments V i n a y --- vinaysahil chandran [EMAIL PROTECTED] wrote: Hi, The client stubs should be capable of being passed around as an argument(s).. a simple program to give the stub one got from

[PATCH] ALTRMI ClassLoaderInputStream

Hi, Patch to enable the ObjectInputStream a chance to use its resolveClass(..) to load classes . V i n a y Index: ClassLoaderObjectInputStream.java === RCS file: