> > 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. > 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?? 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
