On 2003.02.21 18:58 Bill Burke wrote: > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > Hiram > > Chirino > > Sent: Friday, February 21, 2003 6:44 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is really really bad > > > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I would like to note that my future plans for this > > > involve method specific > > > > interceptor chains with a variety of "client side" > > > and "server side" tx > > > > interceptors, each one performing half of the > > > TxSupport work. No maps, > > > > just different specialized interceptors, with > > > different interceptors per > > > > method depending on the tx support. > > > > > > > > > > Hmmmm...thanks for mentioning this. The AOP > > > framework will have to change > > > to support his type of per method intercepiton. > > > > > > Currently the ClassAdvisor asks the > > > InterceptorFactory for an instance of an > > > Interceptor and adds it to the interceptor chain. > > > For what you want to do, > > > this will have to change. The InterceptorFactory > > > should be responsible for > > > adding interceptors to the chain. Otherwise, my > > > isolation and separation of > > > metadata, interceptors, and pointcuts will be > > > broken. > > > > > > > I don't think that you model would be too broken. > > His interceptors should only hav to implement the > > org.jboss.aop.InvocationFilterInterceptor interface: > > boolean intercepts(Invocation invocation); > > > > The org.jboss.aop.Invocation.invokeNext() will skip > > over interceptors that do not interested the > > invocation. Currently invokeNext() interogates the > > intercetors on every invocation, but I think that we > > should be able to keep a per Invocation interceptor > > stack cache so that we can skip the interogation after > > the first method call.
Per method interceptor stacks will eliminate the need to the interceptor filter interface. > > > > That's not the issue. The issue is configuration. He wants to avoid > sending over metadata about the method/tx bindings. WTF??? I want to send to the client the information about whether an exising tx needs to be sent, and as I have indicated I would like to encode this in which interceptor is in each method's client side invocation chain. Until we have method specific interceptor chains, I need a method to tx support map. TO do this he > creates a > Mandatory.java class and attaches it to the method. You see now? > > Actually David, you actually have almost the same memory footprint. As what??? > WIthout > per method , you have one instance of the Tx interceptor. WIth, you have > an > instance per interceptor. Almost the same as a hashmap of methodnames > and > strings identifying the tx attribute. yes, this is obvious. Maybe we have really different ideas about what will go in the interceptor stack for an aop object. I was assuming that it would go like this, just like an ejb: local aop object > ci1 > ci2 > "local invoker" > si1 > si2 > si2 > actual aop object and remote aop object > ci1 > ci2 > real invoker (transport) > si1 > si2 > actual aop object where ci are client interceptors and si are server interceptors. This way any aop object gets the same interceptor stack no matter if it is local or remote. I don't really care if either the local or remote aop object is the actual object or some kind of proxy: I don't think it makes any difference. I don't see why the remote aop thingy can't be the actual object rather than a dynamic proxy, it's just that all the work gets tossed over to a different server. If you plan to leave out the ci's for local aop objects I want to know how you have any chance of getting even mildly similar behavior between local and remote versions. =========== corba My current (limited) understanding of corba tx support leads me to believe that any working corba implementation will use the corba tx policies to their fullest advantage and will have already established and enlisted a transaction branch on the corba tx manager whenever it sends a transaction with an invocation. We can't do anything about this, so we can't save it some work if it happens to be calling a method (not supported or requires new) that won't use the tx that was sent. I assume we can't install any kind of real client side interceptors in corba, we just have to take what is sent to us. If this is wrong please speak up. Therefore, we have to duplicate the functionality of the client side interceptors somewhere on the server side in the iiop invoker. If we don't do this we will get the wrong semantics. I don't know exactly how the iiop invoker works, but I would hope that we could set it up so that it looks like: outside world >>> something corba and proxy-like > ci1 > ci2 > some kind of invoker-like thing > si1 > si2 > actual target object This is really similar to a local ejb call, except it may not start with a dynamic proxy ( I don't know what it would start with). Also I don't know it the invoker-like thing would do nothing or something. For the same reason that I think you need exactly the same client and server interceptors for aop objects I think you need exactly the same interceptors for corba and non-corba objects. With corba, these "client" interceptors just have to live on the server before the "invoker/transport" david > > Bill > > > > ------------------------------------------------------- > 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
