> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Hiram > Chirino > Sent: Friday, February 21, 2003 6:30 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is really really bad > > > > > I have to disagree. Take a higher level look at > > the > > > basics: All client proxies have a dependency on > > their > > > corresponsing server side stub. You can't mix a > > > > Yes, obviously, but the old tx client proxy just > > stuffed the tx context in > > Orthoganal problem. The ability to have smarter > client proxies that have highly coupled interations > with a serverside components is a requirment that > everybody will agree with. > > > the invocation. The problem with AOP is that (at > > least for 1st iteration) > > the POJO can be accessed directly and through a > > proxy at the same time. > > This might sound a little crazy... but how about > allowing multiple server-side interceptor stacks per > object? One for local access, one for stuff over IIOP > (that does tx the ots way), one for stuff over JRMP > etc. >
In the long run, maybe this can't be avoided, but I would like to avoid it. > > yes, I can work around this by having a flag in the > > Invocation object on > > whether or not the invocation passed through a > > proxy, but IMHO, this is a > > hack. > > yes. I am starting to agree. > > > > > > different proxys and stub types. Therefore it is > > ok > > > for a client side interceptor to have a dependency > > on > > > the server side interceptor. > > > > > Can you describe your AOP problem in more detail. > > How > > > are you going to be remoting POJO with AOP?? With > > a > > > proxy? Who will create the proxy objet? > > > > > > > 1st iteration, DynamicProxy. This is trivial since > > we have already done > > this sort of thing for EJB and how to do AOP (or how > > to do it wrong, depends > > how you look at it), is already there for us to see. > > Remote AOP with DP is > > just an iteration to me from the current EJB stuff. > > > > 2nd iteration will be with all java classes. The > > hard part will be how > > instrumentation works on the client side, how the > > client receives pointcuts > > and such. > > In either case, I'm more intersted in WHO will be > responsible creaing proxy objects?? Will it be > automatic done when the object is serialized? Or will > the application have to make an API call to get a > proxy?? > 1st iteration, API: Take a look at how EJB does it and how it works with multiple invokers. This is the approach I will take. I hope to iterate better and cleaner this time around though. Bill > Regards, > Hiram > > > > > Bill > > > > > Regards, > > > Hiram > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > Ok, maybe I shouldn't have said "fatally > > flawed". > > > > But again, my gut tells > > > > me that it is bad to have a dependency between > > > > server and client > > > > interceptors if it is not absolutely needed. > > > > > > > > > -----Original Message----- > > > > > From: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > [mailto:[EMAIL PROTECTED] > > > > Behalf Of Bill > > > > > Burke > > > > > Sent: Friday, February 21, 2003 4:12 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: RE: [JBoss-dev] TxInterceptor split > > is > > > > really really bad > > > > > > > > > > > > > > > I've been thinking and should have posted this > > > > before. Your design is > > > > > fataly flawed when I start applying it to the > > AOP > > > > framework. Your design > > > > > assumes that there is a proxy sitting in front > > of > > > > everything. In AOP this > > > > > is not the case. If you look at > > > > > varia/src/org/jboss/aop/plugins/TxSupport.java > > > > you'll see that I had to > > > > > combine the clientInvoke and serverInvoke into > > one > > > > method because there is > > > > > no proxy object between the application code > > and > > > > the object instance. > > > > > > > > > > Ok...no problem you say....Well, think of what > > > > happens when the app > > > > > developer decides to remote an AOP'd object. > > I > > > > will have to have > > > > > 2 sets of > > > > > interceptor chains and have to figure out > > whether > > > > the call is a > > > > > remote call > > > > > or local. Well, I guess I could insert a flag > > > > into the Invocation on > > > > > whether the call went through a proxy or not. > > But > > > > do you see where I'm > > > > > going? I don't think its a good design to > > rely on > > > > the client to handle > > > > > transaction semantics. I don't think its a > > good > > > > idea for the "server" to > > > > > have to rely on client logic unless it really > > has > > > > to. > > > > > > > > > > All and all, my gut tells me that the current > > > > client/tx design will cause > > > > > problems. I want interceptor designers in > > general > > > > to avoid this kind of > > > > > dependency. > > > > > > > > > > Bill > > > > > > > > > > > -----Original Message----- > > > > > > From: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > [mailto:[EMAIL PROTECTED] > > > > Behalf Of David > > > > > > Jencks > > > > > > Sent: Wednesday, February 19, 2003 11:02 AM > > > > > > To: [EMAIL PROTECTED] > > > > > > Subject: RE: [JBoss-dev] TxInterceptor split > > is > > > > really really good > > > > > > > > > > > > > > > > > > On 2003.02.19 09:37 Bill Burke wrote: > > > > > > > > > > > > > > > > What you implemented is fine. My only > > > > problem with it is that I > > > > > > > > think it is more logical to let the > > server > > > > decide if it needs the > > > > > > > > tx, and that I think the registration > > > > callback could be avoided > > > > > > > > (with minimal redundant client side > > > > bookkeeping) even if the > > > > > > > > decision is made on the server side. > > > > > > > > > > > > > > > > I got the impression that this > > > > implementation would also be used > > > > > > > > in the other invokers, and that made me > > > > worry about CORBA > > > > > > > > interoperability. If this approach will > > not > > > > be used with the IIOP > > > > > > > > invoker, I have no problem with it. > > > > > > > > > > > > > > > > > > > > > > Yes this was my exact worry and still is. > > > > That we'll have to have a > > > > > > > different set of interceptors on the > > server > > > > side for different > > > > > > > transports. > > > > > > > This is unexceptable because we want each > > EJB > > > > to be able to > > > > > > listen to and > > > > > > > service calls from different transports at > > the > > > > same time. > > > > > > > > > > > > > > David, I'm not suggesting to redesign your > > > > code, but is the design > > > > > > > flexible > > > === message truncated === > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > > > ------------------------------------------------------- > 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
