I am getting really tired of doing this you guys. I'll try taking a look at it, in the meantime can we burry the hatchets? If the case is that grey it probably means there isn't a good answer, I will talk with Scott in Vegas.
cheer up guys, the road is still long, marcf > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of David Jencks > Sent: Saturday, February 22, 2003 11:48 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is still the > best thing since sliced bread > > > 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 > ------------------------------------------------------- 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
