On 2003.02.24 10:39 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?
Not quite. I tend to regard the functionality in client interceptors as really required to make anything work. I agree that chain/invoker is excessive. I think we need the same client side interceptor stack no matter what the transport. For java clients, these interceptors will really live on the client. For non java-clients, they will be somewhere inside the server side of the transport mechanism. I also think that the transport layer needs both client and server side interceptors for behavior that is specific to the transport layer. This should allow all "ejb-specific" client side interceptor chains to be independent of the transport layer. Does this seem reasonable? I think making the functionality in client interceptors optional will only lead to confusion and trouble. I'm still interested to know if you have any objections to the model I sketched out. thanks david > > =========================== > > 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
