Bill, what I find really boring and unpleasant about this discussion is that I can't find any evidence that you read most of my posts, or that you remember the reasons for my design decisions for more than about 5 minutes. I've written fairly detailed explanations of my views of both interceptor architecture and corba integration and asked for comments or whether you agree or disagree. I haven't seen any direct responses.
At this point I don't want to read the same argument from you again. Please implement your idea for how dtm will work so we can discuss something concrete. thanks david On 2003.02.24 13:37 Bill Burke wrote: > Sure. The TxSupport class is a nice change and makes the code much more > readable. I have stated this before. But.... > > Merge TxSupport.clientInvoke and serverInvoke into one method. Remove > all > logic from client interceptor except TX propagation. Propagate the TX > always. Again, my reasoning is to isolate the EJB container from the > transport mechanism. Currently, in 3.2, you can invoke on an EJB from > any > protocol at the same time. With David's change, non-Java clients that > support TX propagation would require that TxSupport.clientInvoke be run > on > the server thus requiring us to have transport specific server-sdie > interceptor chains and a change to the current architecture. I think > that > this creates further complication in the server-side architecture and > will > further bloat configuration. All just to save a tx propagation for > NotSupported and RequiresNew methods. > > Or are you talking about the AOP stuff? Well, it is implemented, I do > have > an API. I have written the AOP Tx interceptor and it is tested within > the > testsuite. I am working on the Security one. So far, my design seems to > fit. The real test will be with the persistence metadata since this is > much more complicated. I've made an attempt to explain my design with > the > bootcamp slides and the crappy documentation I put together on the > website > /developers/projects/jboss/aop.jsp. > > > Bill > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Dain > > Sundstrom > > Sent: Monday, February 24, 2003 12:36 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] TxInterceptor split is still the best thing > > since sliced bread > > > > > > Bill, > > > > Where is you design? David's design looks totally obvious to me. It > > is well understood, and based on our existing "real-world" experiences. > > To me it looks like you are the one invent "the perfect design/API". > > So can you present you invocation chain as did and show us the error in > > our logic? > > > > -dain > > > > On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote: > > > > > > > > > > >> -----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 > > > > > > > > ------------------------------------------------------- > > 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 > > > > ------------------------------------------------------- > 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 > > ------------------------------------------------------- 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
