Don't let these guys push you around. Bill's just in a pissy mood today.
-dain
On Friday, February 21, 2003, at 06:01 PM, Jeff Haynie wrote:
Oh, I buy into it - and I'm neither for OR against what David is saying. I'm merely saying you should separate the concerns - but it seems like that is obvious and redudant (although not so apparent with all the back in forth) to you.
As you know, I don't work for Jboss Group. I'm just merely trying to help out on my own *free time* and try and help make this a better product with what little value I can add.
Sorry I stepped into the flames. I was hoping to enlighten a little bit
to the fact that you could push some of this stuff into the remoting
stuff that tom and I worked on.
Jeff
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Haynie Sent: Friday, February 21, 2003 6:15 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad
Yes - but you guys don't seem to buy into it otherwise you won't be talking about where and how tx or remoting should go into AOP.
Maybe I'm missing something.
I'm not understanding you. I certainly buy into it and am implementing
stuff (albeit slowly). Whether you and David buy into it is irrelevent.
The vision is set. THis is where we're going. The whole point is
isolation and being able to dynamically remote or not remote with any
protocol you want. IMHO, Davids implementation for tx right now doesn't
allow for this isolation. He disagrees. So what? We disagree.
Eventually it will all flush out and either David and/or I will end up
rewriting everything. My bet David gets there first since I've got
A.D.D.
Bill
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, February 21, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad
I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the
functional areas that apply those specific semantics to the subsystems
since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote).
Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective.
Bill
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 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 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?
Regards, Hiram
--- Bill Burke <[EMAIL PROTECTED]> wrote:[mailto:[EMAIL PROTECTED]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.
[EMAIL PROTECTED]-----Original Message----- From:
Behalf Of Bill[mailto:[EMAIL PROTECTED]really really badBurke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split isbefore. Your design is
I've been thinking and should have posted thisfataly flawed when I start applying it to the AOPframework. Your designassumes that there is a proxy sitting in front ofeverything. In AOP thisyou'll see that I had tois not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.javacombine the clientInvoke and serverInvoke into onemethod because there isno proxy object between the application code andthe object instance.happens when the app
Ok...no problem you say....Well, think of whatdeveloper decides to remote an AOP'd object. Iwill have to havethe call is a2 sets of interceptor chains and have to figure out whetherinto the Invocation onremote call or local. Well, I guess I could insert a flagwhether the call went through a proxy or not. Butdo you see where I'mgoing? I don't think its a good design to rely onthe client to handletransaction semantics. I don't think its a goodidea for the "server" tohave to rely on client logic unless it really hasto.client/tx design will cause
All and all, my gut tells me that the currentproblems. I want interceptor designers in generalto avoid this kind ofdependency.[EMAIL PROTECTED]
Bill
-----Original Message----- From:
Behalf Of David-------------------------------------------------------really really goodJencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split isproblem with it is that I
On 2003.02.19 09:37 Bill Burke wrote:
What you implemented is fine. My onlydecide if it needs thethink it is more logical to let the servercallback could be avoidedtx, and that I think the registrationbookkeeping) even if the(with minimal redundant client sideimplementation would also be useddecision is made on the server side.
I got the impression that thisworry about CORBAin the other invokers, and that made mebe used with the IIOPinteroperability. If this approach will notThat we'll have to have ainvoker, I have no problem with it.
Yes this was my exact worry and still is.side for differentdifferent set of interceptors on the serverto be able totransports. This is unexceptable because we want each EJBsame time.listen to andservice calls from different transports at thecode, but is the design
David, I'm not suggesting to redesign yourserver-side based design?flexible enough so that we could switch to aIterationcurrent design to useis a fine thing....
I don't think we will have problems adapting mya clearcorba. Before we continue I think we should getunderstanding ofpolicy and the j2eewhat is supposed to happen when the corba txdescribed in specs?tx support disagree. Does anyone know where this istransaction in
Basically the corba design says "if there is athe contextthe server" whereasit must always be transmitted and imported onof the client sidej2ee does not always need to import the tx. The purposewon't be used. I thinkinterceptor is to not generate tx branches thatgoing to follow corbathat any reasonable corba implementation isclient for thesemantics and always generate a transaction branch on theis made within a tx theremote call, since as far as the corba spec goes, if the callgenerating a tx branch ontransaction will in fact be used on the server.
In my view the heaviest part of the process isbe prepared and/orthe client: once it is generated, then it has tomessages iscommitted. The communication overhead on thesedo it rightlikely to dwarf any other resource usage.
The choices I can see here are:
1. only generate the branch if it is needed, butand the only one that isaway. This is what I implemented and I think it is simplestat it in a week or two.likely to be comprehensible when someone looksdo it after the work is
2. Only generate the branch if it is needed butintroduces a lot ofdone. I think this is Ole's proposal. Thisside transactions tobookkeeping on the client to associate clientthis code, in a week Ibranches. I don't think I'd be able to maintaina day to figure it out,wouldn't remember how it worked. After spendinghave the xaresource returnI'd simplify it to (1).
3. Always generate a branch immediately, butbe imported. This isread-only on prepare if the tx did not need tothat there is onlyunacceptable because it forces 2pc in the casemethod-to-method-attributes mapone other branch.
Don't we need a client sidevalue can be cached?anyway for many other purposes such as determining if a return
david
Bill
=== message truncated ===Inc.This SF.net email is sponsored by: SlickEdit
__________________________________________________ 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
------------------------------------------------------- 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
------------------------------------------------------- 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
------------------------------------------------------- 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