This is really boring and unpleasant, bill. We don't seem to have a shared understanding of how interceptors ought to work with local and remote calls. Most of your comments make no sense to me, and I think contrariwise. I'll try to explain my view one more time, and I'll write an interceptor framework that satisfies my understanding of what is needed for mbeans, ejbs, remoting, and aop (which I don't understand all that well). If you don't like it and I can't understand your objections, I'll let you indulge your previously expressed wish to write a transaction manager. You might also get that wish fulfilled if you say the following is obvious. I thought it was, but I don't think we have agreed on it. I'm writing it down to try to form a basis for discussion, which is currently missing.
========================== Dave's mental model for invocations. Lets assume first you already have something representing the object you are interested in (such as an ejb Remote interface object, mbean thingy, aop-ized object, or some kind of proxy). Items marked with a * might be removed for non-remotable objects. Key to symbols: \/ interceptor chain "invokeNext()" calls. \/ || method/field access/... calls whose nature may vary depending on the application and that are not part of the interceptor/invocation framework. \/ \/ calls between "segments". These are of the form invoke(invocation) on a particular object found by the current interceptor. .......... sequence of interceptors in a chain. || || transport mechanism. For a remote object, this is the boundary between client and server. =========================== Some program does something on the "object" \/ || The Object \/ || Something that knows about interceptor chains and metadata. It looks at the method (or field access, ...) call and its environment and determines what interceptor chain to use. It constructs an Invocation object that includes an iterator over the selected chain, the method call data, and some metadata. Then it starts the invocation down the chain. I will call this a Container. I believe it corresponds to your aop Advisor(s). \/ Several interceptors (client side interceptors specific to the object/class you are calling) ..... \/ * Transport selector interceptor. This examines the metadata and picks a transport endpoint. It calls invoke(invocation) on the selected transport endpoint. It does not call invocation.invokeNext(), so this may be the end of the use of the original interceptor iterator. \/ \/ * Transport endpoint. If this is a local "do nothing" transport, it may simply call invocation.invokeNext(). Otherwise, it replaces the interceptor iterator with one for the client side transport interceptor stack. \/ * Several interceptors (client side interceptors specific to the transport endpoint you are calling. Examples would include the XAResource representing a remote jboss instance (whenever the branch is created, you still need an XAResource, and it needs to know about the method calls), and the clustering thingy that picks a remote server) \/ * client side end of the transport. I believe this is essentially the remoting framework. || || || * server side end of the transport. This may include some kind of relationship with a thread pool. Lets assume the work is dispatched with a thread, no matter how it is picked and how synchronous/asynchronous it is. Anyway, the reconstituted invocation object has its interceptor iterator replaced with one for the transport specific server side interceptors \/ * Several interceptors (server side interceptors specific to the transport. In my current dtm implementation, one of these would import an xid in the invocation into the server side tm) ..... * Target selector. Based on the metadata, this interceptor picks and locates a target object, and calls invoke(invocation) on it. This is the end of the transport specific server side interceptor chain. \/ \/ * Server side target object. This is analogous to the current server side ejb Container object. It replaces the invocation's interceptor iterator and starts it off by calling invocation.invokeNext(). \/ Server side interceptors. For non remotable objects and for "no transport" local remotable objects, the original interceptor chain would continue here. ....... \/ Final interceptor. This uses the metadata and the method information to do something to the actual object instance we are working with. \/ || object of interest. Note that this requires, for remotable objects, being able to get two interceptor iterators: one for the client side iterators, and one for the server side iterators. For "local only" objects, you only need one interceptor iterator. For objects that can be local or remote, looking up the server side target object can be avoided if the client side interceptor iterator also includes all the server side interceptors: the (client side) Transport Endpoint would (after determining that the call is local) simply call invokeNext() on the invocation. Lets see if we can come to an agreement on this much before we consider constructors or how to get something representing a remote object. Please remember that I consider this very obvious, but I don't think we agree on it: I think if we did your comments would make sense to me, and so far they don't. Saying something like "don't be obvious" will indicate to me that you are not interested in discussing this aspect of jboss architecture with me, so I will take your recommendation and stop working with interceptors, at least until my curiousity gets the better of my sense. david ------------------------------------------------------- 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
