Woo hoo!! Thanks! This looks great!!! Will you guys mind if I fix minor oversights I notice (such as making handler names consistently upper case in ServerInvoker)?
Partly so I don't forget and partly to think out loud as I read the code, here are my initial comments: 1. There's kind of an impedance mismatch between the remoting invoke method and all the interceptor invoke methods. The interceptors all have some kind of invocation object that includes method name, args, sig, and extra params: these are separate arguments in the remoting's invoke method. I think the same signature everywhere would make integration everywhere easier. In particular, I'd like the Invoker to implement whatever Interceptor interface we finally come up with. I'm mildly in favor of a single Invocation argument, even though it is not the most natural for the original jmx remoting use case. 2. I need to have essentially client and server side invoker interceptors (e.g. the InvokerXAResource). I'm sure others will think of uses for this when it is available. If we decide one way or another on (1) I can implement this possibly using an adapter that could be removed if we decide to go with a single Invocation argument. 3. So far I've just looked at the socket server invoker. I want to be able to plug in a thread pool (implementing a standard interface). I also want the stuff that's done in the thread to be set up as an interceptor chain. For instance, I want the "extract the xid from the invocation and import it or prepare/commit/rollback/recover/forget" to be in one or more interceptors. I think most of this is taken care of by the selection of ServerInvocationHandler: I can make these be my interceptors. I wonder if a clearer architecture would move the ServerInvoker invoke(byte[]) method into a separate class that the transport mechanism runnable classes subclass. This object would then be the standardized object submitted to something like the jca 1.5 work interface. [this is the jca 1.5 thread pool, and it provides for both synchronous and asynchronous execution of a Work object. I like the idea of always using the same kind of object, but the Work interface itself is not appropriate since the contents of the ExecutionContext (tx context or xid) would not be determined until the thread starts processing. I'd like to build the jca 1.5 implementation out of more basic units.] 4. I haven't found yet how the client invokers get set up in the client. Are there situations in which they are obtained through rmi? Should they be mbeans in a client-side jmx server? Should this be optional? Working on the TrunkInvoker I made the client side piece into several mbeans that got created/registered when the first one got deserialized as a remote object. This considerably simplified keeping track of the pieces. Is something like this a good idea here too or at least compatible with what you have? 5. Since I think it is possible that jmx could be used without aop and aop without jmx, I'd like to suggest that we make a new module "invocation" that has the interceptor interface, and the Invocation and InvocationResponse objects in it. Otherwise I don't see how to unify our view of these fundamental classes without intruducing artificial dependencies. I'd like to get to work on the interceptor stuff I mentioned, so I'd like to get comments on this soon so at least I'll know how much I'll have to fight:-)))) This is awesome work. Thanks again david jencks On 2003.02.19 00:54 Jeff Haynie wrote: > I commited the jboss-remoting code tonight. There is now a separate > module named jboss-remoting, and it is aliased in jboss-mx and > jboss-head (because mx needs it). > > It looks like all 3 modules are compiling fine. There is more work that > Tom and I are doing this week to try and wrap up the initial testing - > however, the code should compile fine and the code isn't yet referenced > at all anywhere in the server so shouldn't cause any problems. If it > does cause problems in the next day or so, please let me or Tom Elrod > ([EMAIL PROTECTED]) if you have any issues - or just fix them > and let me and him know. > > -Jeff > > http://www.freeroller.net/page/jhaynie > > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > <HTML><HEAD> > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> > <TITLE>Message</TITLE> > > <META content="MSHTML 6.00.2800.1141" name=GENERATOR></HEAD> > <BODY> > <DIV><FONT face=Arial size=2><SPAN class=323323305-19022003>I commited > the > jboss-remoting code tonight. There is now a separate module named > jboss-remoting, and it is aliased in jboss-mx and jboss-head (because mx > needs > it).</SPAN></FONT></DIV> > <DIV><FONT face=Arial size=2></FONT> </DIV> > <DIV><SPAN class=323323305-19022003><FONT face=Arial size=2>It looks like > all 3 > modules are compiling fine. There is more work that Tom and I are > doing > this week to try and wrap up the initial testing - however, the code > should > compile fine and the code isn't yet referenced at all anywhere in the > server so > shouldn't cause any problems. If it does cause problems in the next > day or > so, please let me or Tom Elrod (<A > href="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</A>) if > you > have any issues - or just fix them and let me and him know. > </FONT></SPAN></DIV> > <DIV dir=ltr align=left><FONT face=Arial size=2></FONT> </DIV> > <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN > class=323323305-19022003>-Jeff</SPAN></FONT></DIV> > <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN > class=323323305-19022003></SPAN></FONT> </DIV> > <DIV dir=ltr align=left><FONT face=Arial size=2><A > >href="http://www.freeroller.net/page/jhaynie";>http://www.freeroller.net/page/jhaynie</A></FONT></DIV> > <DIV dir=ltr align=left><FONT face=Arial size=2></FONT> </DIV> > <DIV> </DIV></BODY></HTML> > ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
