> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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
I am sorry I am boring you. Summarized, my major concern with the TX refactor is that it will not work for clients that cannot have interceptor chains (i.e. non-Java), but support Tx propagation (CORBA) for all trans-attributes (specifically, NotSupported, and RequiresNew). I thought Marc's vision for creating these generic, transport specific invokers was to isolate the EJB Container from the transport layer, and I see this refactor as breaking this vision. The only way I see this working is if we have separate transport-specific interceptor chains on the server to support non-Java clients. I wanted to avoid this because this is what has happened when I put in support for multiple invokers. Client-side interceptor configuration became bloated. All this to avoid creating and passing over a TxId. See my point now? =========================== As far as AOP goes, I'm hoping that as we implement services on top of the Framework and apply the framework to JMX and remoting, the requirements and API will be fleshed out as we iterate. I'd like the design of AOP to be driven by "real-world" requirements and applications rather than what we might think as the perfect (and probably bloated) design/API might be currently. I'm not afraid of throwing code out or having to modify huge amounts of code to iterate. Iteration is key. Allows us to get to market quick and to quickly notice bad designs. Didn't somebody say "Release early, release often"? Bill > 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
