RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
Plus, it is ... a spec requirement! > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Burke > Sent: vendredi, 28. février 2003 01:13 > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is still the > best thing since sliced bread > > > We will eventually be forced to work with non-java clients. > The world is > not Java centric. We will eventually work with companies > that required a > lot of non-java integration. I've already worked at 2 before JBG. --- 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
We will eventually be forced to work with non-java clients. The world is not Java centric. We will eventually work with companies that required a lot of non-java integration. I've already worked at 2 before JBG. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Dain > Sundstrom > Sent: Thursday, February 27, 2003 6:51 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] TxInterceptor split is still the best thing > since sliced bread > > > I've had only two customers ask about CORBA support, but only as an > interim solution until the clients can be rewritten. Fortunately both > decided to just port the clients at the same time. > > -dain > > On Thursday, February 27, 2003, at 05:04 PM, Luke Taylor wrote: > > > David Jencks wrote: > >> Maybe we're confusing 2 issues here: > >> 1. writing a maintainable usable jboss dtm > >> 2. supporting corba etc. > > > > Does anyone actually use CORBA clients agains JBoss - from Java even, > > never mind C++. > > I can understand the desire to use CORBA the other way - i.e. calling > > out to access a > > legacy system, but is there any reason why anone would choos to use > > CORBA clients. Maybe supporting them isn't really so important. > > > > At one point CORBA was intended to support interceptors (client and > > server side) in a standard way, but I've no idea if the spec. was ever > > completed - they always seemed to be arguing about it and that was > > years ago. If it was, you could probably supply a set of JBoss CORBA > > interceptors which did the same job as the custom Java ones. > > > > Luke. > > > > > > -- > > Luke Taylor. Monkey Machine Ltd. > > PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk > > > > > > > > > > > > --- > > 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 --- 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
Re: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
I've had only two customers ask about CORBA support, but only as an interim solution until the clients can be rewritten. Fortunately both decided to just port the clients at the same time. -dain On Thursday, February 27, 2003, at 05:04 PM, Luke Taylor wrote: David Jencks wrote: Maybe we're confusing 2 issues here: 1. writing a maintainable usable jboss dtm 2. supporting corba etc. Does anyone actually use CORBA clients agains JBoss - from Java even, never mind C++. I can understand the desire to use CORBA the other way - i.e. calling out to access a legacy system, but is there any reason why anone would choos to use CORBA clients. Maybe supporting them isn't really so important. At one point CORBA was intended to support interceptors (client and server side) in a standard way, but I've no idea if the spec. was ever completed - they always seemed to be arguing about it and that was years ago. If it was, you could probably supply a set of JBoss CORBA interceptors which did the same job as the custom Java ones. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- 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
Re: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
I couldn't agree more. -dain On Wednesday, February 26, 2003, at 04:03 AM, Jason Dillon wrote: IMO interceptors are much simpilar than hard coded invokers. --jason On Tue, 25 Feb 2003, Bill Burke wrote: What I'm saying is, why add this complication? Do we really need it? KISS. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Tuesday, February 25, 2003 11:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread How about implementing some kind of seperate interceptor framwork around the client side and server side invocation layers?? David, if yoiu had a configurable way to plug in your tx interceptors at the invocation layer you would be ok right? I think david just needs to avoid duplicating the code that is in the trunk invoker all over the place. Bill, how doable is that? Regards, Hiram Bill Burke <[EMAIL PROTECTED]> wrote: IMHO, CORE client interceptors such as security and tx should be written such that if the client doesn't support interceptors (C++) you don't break the server side or put additional configuration requirements on the server side. Bill -- -- -- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
Oh, you just want invoker interceptors for generic tx importation. I guess this is fine. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Hiram > Chirino > Sent: Tuesday, February 25, 2003 1:10 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > since sliced bread > > > I though what I sugested was KISS. Tx imporation is > currently done at the invoker level. I want to keep > it there but make it plugable via interceports at the > invoker level. > > I guess it would be more KISS to just duplicate the > code that is in the trunk invoker over to all ther > other java based transports. But that seems more > error prone to me. > > Regards, > Hiram > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > What I'm saying is, why add this complication? Do > > we really need it? KISS. > > -Original Message- > > From: > > [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > > Behalf Of Hiram > > Chirino > > Sent: Tuesday, February 25, 2003 11:23 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is > > still the best thing since > > sliced bread > > > > > > How about implementing some kind of seperate > > interceptor framwork around > > the client side and server side invocation layers?? > > > > David, if yoiu had a configurable way to plug in > > your tx interceptors at > > the invocation layer you would be ok right? I think > > david just needs to > > avoid duplicating the code that is in the trunk > > invoker all over the place. > > > > Bill, how doable is that? > > > > Regards, > > Hiram > > > >Bill Burke <[EMAIL PROTECTED]> wrote: > > > > > > > > IMHO, CORE client interceptors such as security > > and tx should be written > > such that if the client doesn't support > > interceptors (C++) you don't > > break > > the server side or put additional configuration > > requirements on the > > server > > side. > > > > > > Bill > > > > > > > > > > > > > > > > > > > -- > -- > > -- > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, and > > more > > > > > __ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > > > --- > 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
Maybe we're confusing 2 issues here: 1. writing a maintainable usable jboss dtm 2. supporting corba etc. I realize I am not entirely comfortable with the client interceptors, and I notice that they are not really used in the local proxies. I don't think my idea of using the client interceptors inside a corba invoker will work, because there will be no way to simulate a client environment. So I'm basically abandoning my idea of always using the same client interceptors for all clients including local, remote, and corba. I think the current client interceptor stack configuration system may be lousy and need redesign, but that is sort of a third question. I think it should not be tied to the invoker but to local/remote/corba choice. The fact that all client interceptor stacks today are identical supports this view. How about: server side interceptor gets back the functionality of suspending transactions that are not needed (for not supoorted and requires new) client side interceptor for remote client does this also, to avoid creating unneeded branches. Local clients won't need the client side tx interceptor. The corba clients will continue creating branches based on the corba transaction policy, and we will import all such transactions that arrive via corba immediately. The server side tx interceptor may suspend these tx in the case of notsupported and requiresNew. There's nothing we can do about the remote corba tm creating unneeded branches, and the simplest way to deal with them is simply to import them so when a prepare/commit/etc request comes we just let our tm deal with it. - (in reference to Hiram's comment) On the client side, I need 2 pieces of functionality: a tx-support aware interceptor per remote object (ejb name, not instance) and an xaresource per remote jboss server. I'm still convinced this is by far the simplest possible implementation for dtm. I think writing the xaresource as a transport-level interceptor will have many many simplifying advantages, but it is not necessary, only about half as complex as my previous solution. It could be written once and plugged in some other way, but I don't see the point in using an inferior architecture to an interceptor stack. Thanks david --- 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
I though what I sugested was KISS. Tx imporation is currently done at the invoker level. I want to keep it there but make it plugable via interceports at the invoker level. I guess it would be more KISS to just duplicate the code that is in the trunk invoker over to all ther other java based transports. But that seems more error prone to me. Regards, Hiram --- Bill Burke <[EMAIL PROTECTED]> wrote: > What I'm saying is, why add this complication? Do > we really need it? KISS. > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of Hiram > Chirino > Sent: Tuesday, February 25, 2003 11:23 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is > still the best thing since > sliced bread > > > How about implementing some kind of seperate > interceptor framwork around > the client side and server side invocation layers?? > > David, if yoiu had a configurable way to plug in > your tx interceptors at > the invocation layer you would be ok right? I think > david just needs to > avoid duplicating the code that is in the trunk > invoker all over the place. > > Bill, how doable is that? > > Regards, > Hiram > >Bill Burke <[EMAIL PROTECTED]> wrote: > > > > IMHO, CORE client interceptors such as security > and tx should be written > such that if the client doesn't support > interceptors (C++) you don't > break > the server side or put additional configuration > requirements on the > server > side. > > > Bill > > > > > > > > > > -- > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, and > more > __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
What I'm saying is, why add this complication? Do we really need it? KISS. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Hiram ChirinoSent: Tuesday, February 25, 2003 11:23 AMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread How about implementing some kind of seperate interceptor framwork around the client side and server side invocation layers?? David, if yoiu had a configurable way to plug in your tx interceptors at the invocation layer you would be ok right? I think david just needs to avoid duplicating the code that is in the trunk invoker all over the place. Bill, how doable is that? Regards,Hiram Bill Burke <[EMAIL PROTECTED]> wrote: IMHO, CORE client interceptors such as security and tx should be writtensuch that if the client doesn't support interceptors (C++) you don't breakthe server side or put additional configuration requirements on the serverside.Bill Do you Yahoo!?Yahoo! Tax Center - forms, calculators, tips, and more
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
How about implementing some kind of seperate interceptor framwork around the client side and server side invocation layers?? David, if yoiu had a configurable way to plug in your tx interceptors at the invocation layer you would be ok right? I think david just needs to avoid duplicating the code that is in the trunk invoker all over the place. Bill, how doable is that? Regards,Hiram Bill Burke <[EMAIL PROTECTED]> wrote: IMHO, CORE client interceptors such as security and tx should be writtensuch that if the client doesn't support interceptors (C++) you don't breakthe server side or put additional configuration requirements on the serverside.BillDo you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Monday, February 24, 2003 3:02 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > since sliced bread > > > On 2003.02.24 14:35 Bill Burke wrote: > > > > > > > > > > Bill, what I find really boring and unpleasant about this > discussion is > > > that I can't find any evidence that you read most of my posts, or that > > you > > > > Ditto. > > > > I thought I did read your stuff and replied appropriately. Maybe I > > missed > > something. What I saw you propose for non-Java and I'll quote you: > > > > "outside world >>> something corba and proxy-like > ci1 > ci2 > > some kind > > of > > invoker-like thing > si1 > si2 > actual target object" > > > > My argument against this was that you would have to maintain 2 separate > > interceptor chains on the server. > > > > For IIOP the chain would be (as you stated) > > > > IIOPInvoker > ci1 > ci2 > si1 > si2 > actual target object. > > > > For RMI/Java the chain would be > > > > DP > ci1 > ci2 > network --- JRMPInvoker > si1 > si2 > > > > I voiced a similar problem with AOP where the AOP interceptors > would have > > to > > know whether the call had traveled through a remote proxy object. > > I wrote the lengthy description/picture below in an attempt to find out > what you are talking about, since this argument doesn't make sense to me. > I didn't see any response from you about it. > > I'll try to explain why, specifically, your argument makes no sense to me. > > I think interceptors all implement required functionality. If > you put them > in the chain, it's for a reason: they are doing something you need. > Therefore, however many transport steps are in the middle, any invocation > should go through the same (target specific) interceptors. (IMO transport > layer interceptors on both ends are a good idea too, but that's a separate > argument). If the interceptor chains have different > interceptors, you will > get different behavior, and you should be getting that through other means > such as additional deployments. > > Therefore, for a conceptual interceptor chain of ci1 > ci2 > si1 > si2, > this might end up as > > ci1 > ci2 > ||transport from client machine to server || > si1 > si2 > > target object. > > or > > ci1 > ci2 > ||do nothing "transport" on same machine || > si1 > si2 > > target object. > > It might be possible to arrange for > > ci1 > ci2 > si1 > si2 > target object but I don't see why you'd want to > particularly. > > Furthermore, for corba, > > java-corba-endpoint on server > ci1 > ci2 > || possible "transport" > translation layer whose need is questionable || > si1 > si2 > target > object. > What I"m saying is that you've created a need for this construct with the split in TxSupport of clientINvoke and serverInvoke. With your current design, ci1 needs the EJB's trans-attribute method map. Thus we need 2 different interceptor chains on the server to service IIOP and JRMP. With the current architecture this interceptor chain requirement wouldn't allow the same EJB target object to service calls from both IIOP and JRMP at the same time. You would have to create two separate EJBs with two different Container Configurations. Here's what it would look like in reality with an endpoint target object with id 1223 C++ Client -- network --- endpoint Invoker> MBean invoke > SERVER SIDE CHAIN: ci Tx > ci2 > si 1 > si 2 > 1223 Target Object Java client > DP > ci Tx > ci2 --- network -- Invoker > Mbean invoke > si1 > si2 > 1223 Target Object Look at the configuration in standardjboss.xml. The configuration for client and server side interceptors are separate. If you would configure the above example in XML you would see that you would be defining 2 separate chains and as a result, you would not be able to have the same Target object receive requests from 2 separate For JBoss 3.2 and 3.0. All the tx interceptor did was propagate the transaction. This interceptor is not needed for a C++ iiop client because the IIOP transport does the propagation for you. Thus you have no need to > To me these are all the same interceptor chain: they all have the same > members, with the exception of the one missing any kind of transport. The > chain has 2 entry p
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
> well, aside from my and babelfish's inability to translate that... Yeah... That's because I did a mistake... Shame... It is not "Ortille", but "Ortie", which means "nettle". That gives: "Maybe I am pushing Grand Mother in the nettles" (i.e. maybe I go too far...) > 1. I was planning to move the invocation reassembly and > targeting into a > bunch of interceptors on the server side. Ok, so my loosy argument is in fact something you wanted to do ;) > 2. I think your argument applies with exactly equal force to > the client > side interceptors and if we put the functionality for IIOP > into the invoker > on the server side we should for exactly the same reason > eliminate client > side interceptors everywhere and put them in the client side of "more > capable" (than IIOP) invokers. No, that's not what I mean. I meant that with IIOP we have *no* way to do something on the client-side anyway i.e. with IIOP we are *forced* to do everything on the server side. Nevertheless, because IIOP imply that does *not* mean that it should dictate it for java clients able to use client side interceptor. Don't forget that CSI (client side interceptors) are not only used to populate information in the invocation but also to get information from the client side JVM/environment. Oviously, this cannot be mimic'ed on the server side. > Just because we haven't used > the client > interceptors for any customization doesn't mean they aren't a > good idea. Sure. > If we ever found a use for including additional context > information, we > would be able to include it in all transports simply be > writing one client > and one server interceptor and adding it to the chains for > the objects we > wanted it for. For IIOP, I think this would result in the > fewest changes: > I think basically we'd just have to add the C++ (or whatever) > code to send > the additional context info. OK, but, again, in this case, the SSI (server side interceptor) is only used to do something useful: the extraction of the context information can be done in a generic way inside the invoker (or any other object that satisfy a lambda design pattern...): the "IIOP-packet"-to-"JBoss-Invocation-object" conversion must take place at a single place as once the conversion is done, we forget about the original IIOP packet. Sorry if what I say is a non-sense for DTMs: I am really focused on a specific case: non-necessarly-Java IIOP clients. Am I making (partial) sense? Cheers, Sacha --- 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
On 2003.02.25 02:58 Sacha Labourey wrote: > Hello, > > This discussion is somehow strange because, and I agree with David: you > don't seem to be speaking about the same thing at the same time... > Asynchronous argumentation is hard to follow... > > - I think we should have interceptors > - Yes, but the sky is blue > - No! Invokers can't handle DTM in this case > - You mean AOP? > > I understand David's point of view. David loves orthogonal designs and > the > idea to have somehow symetric interceptors (between the client and the > server), possibly with a null invoker in the middle of the chain makes > his > design pleaseant. Nevertheless, where I think I agree with Bill is that > we > first have to check if we don't go too far just for the beauty of it. > Let's > take IIOP as an example. In the general case, IIOP can only transport the > same kind of data: > - invocations information (method name, arguments, etc.) > - arbitrary context information > > In the arbitrary payload, you may find security information, transaction > information, etc. The question is: at the end of the day, do we really > need > a stack of interceptors just to extract this set of information and > populate > a JBoss invocation object? Couldnt we more simply just extract "all this > stuff" and put it in the Invocation Object (and the server side Invoker > could do that). > > I agree, it would look much smarter to have this "separation of concern" > and > have each interceptor from a virtual-client-stack (i.e. client side > interceptors living on the server and mimic-ing client-side behaviour) > put > only what is needed inside the JBoss invocation object. NEVERTHELESS, as > this information will always be similar, why not simply do that in a > generic > way inside the invoker: in-mass population of the invocation with > well-known > key names for well-known invocation content. > > If you think about it, the invoker already does that: it extracts the > target > MBean ObjectName from the invocation and push the invocation to it: if > you > push your reasoning far enough, that's already a concern that shouldn't > be > put in a pure "transport-focused invoker". But I agree, and as French > say: > "Je pousse mémé dans les ortilles". Translation left as an exercise. well, aside from my and babelfish's inability to translate that... 1. I was planning to move the invocation reassembly and targeting into a bunch of interceptors on the server side. 2. I think your argument applies with exactly equal force to the client side interceptors and if we put the functionality for IIOP into the invoker on the server side we should for exactly the same reason eliminate client side interceptors everywhere and put them in the client side of "more capable" (than IIOP) invokers. Just because we haven't used the client interceptors for any customization doesn't mean they aren't a good idea. If we ever found a use for including additional context information, we would be able to include it in all transports simply be writing one client and one server interceptor and adding it to the chains for the objects we wanted it for. For IIOP, I think this would result in the fewest changes: I think basically we'd just have to add the C++ (or whatever) code to send the additional context info. thanks david > > Cheers, > > > Sacha > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of David Jencks > > Sent: lundi, 24. février 2003 21:02 > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is still the > > best thing since sliced bread > > > > > > On 2003.02.24 14:35 Bill Burke wrote: > > > > > > > > > > > > > > Bill, what I find really boring and unpleasant about this > > discussion is > > > > that I can't find any evidence that you read most of my > > posts, or that > > > you > > > > > > Ditto. > > > > > > I thought I did read your stuff and replied appropriately. Maybe I > > > missed > > > something. What I saw you propose for non-Java and I'll quote you: > > > > > > "outside world >>> something corba and proxy-like > ci1 > > > ci2 > some kind > > > of > > > invoker-like thing > si1 > si2 > actual target object" > > > > > > My argument against this was that you would have to > > maintain 2 separate > > > interceptor chain
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
Hello, This discussion is somehow strange because, and I agree with David: you don't seem to be speaking about the same thing at the same time... Asynchronous argumentation is hard to follow... - I think we should have interceptors - Yes, but the sky is blue - No! Invokers can't handle DTM in this case - You mean AOP? I understand David's point of view. David loves orthogonal designs and the idea to have somehow symetric interceptors (between the client and the server), possibly with a null invoker in the middle of the chain makes his design pleaseant. Nevertheless, where I think I agree with Bill is that we first have to check if we don't go too far just for the beauty of it. Let's take IIOP as an example. In the general case, IIOP can only transport the same kind of data: - invocations information (method name, arguments, etc.) - arbitrary context information In the arbitrary payload, you may find security information, transaction information, etc. The question is: at the end of the day, do we really need a stack of interceptors just to extract this set of information and populate a JBoss invocation object? Couldnt we more simply just extract "all this stuff" and put it in the Invocation Object (and the server side Invoker could do that). I agree, it would look much smarter to have this "separation of concern" and have each interceptor from a virtual-client-stack (i.e. client side interceptors living on the server and mimic-ing client-side behaviour) put only what is needed inside the JBoss invocation object. NEVERTHELESS, as this information will always be similar, why not simply do that in a generic way inside the invoker: in-mass population of the invocation with well-known key names for well-known invocation content. If you think about it, the invoker already does that: it extracts the target MBean ObjectName from the invocation and push the invocation to it: if you push your reasoning far enough, that's already a concern that shouldn't be put in a pure "transport-focused invoker". But I agree, and as French say: "Je pousse mémé dans les ortilles". Translation left as an exercise. Cheers, Sacha > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of David Jencks > Sent: lundi, 24. février 2003 21:02 > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is still the > best thing since sliced bread > > > On 2003.02.24 14:35 Bill Burke wrote: > > > > > > > > > > Bill, what I find really boring and unpleasant about this > discussion is > > > that I can't find any evidence that you read most of my > posts, or that > > you > > > > Ditto. > > > > I thought I did read your stuff and replied appropriately. Maybe I > > missed > > something. What I saw you propose for non-Java and I'll quote you: > > > > "outside world >>> something corba and proxy-like > ci1 > > ci2 > some kind > > of > > invoker-like thing > si1 > si2 > actual target object" > > > > My argument against this was that you would have to > maintain 2 separate > > interceptor chains on the server. > > > > For IIOP the chain would be (as you stated) > > > > IIOPInvoker > ci1 > ci2 > si1 > si2 > actual target object. > > > > For RMI/Java the chain would be > > > > DP > ci1 > ci2 > network --- JRMPInvoker > si1 > si2 > > > > I voiced a similar problem with AOP where the AOP > interceptors would have > > to > > know whether the call had traveled through a remote proxy object. > > I wrote the lengthy description/picture below in an attempt > to find out > what you are talking about, since this argument doesn't make > sense to me. > I didn't see any response from you about it. > > I'll try to explain why, specifically, your argument makes no > sense to me. > > I think interceptors all implement required functionality. > If you put them > in the chain, it's for a reason: they are doing something you need. > Therefore, however many transport steps are in the middle, > any invocation > should go through the same (target specific) interceptors. > (IMO transport > layer interceptors on both ends are a good idea too, but > that's a separate > argument). If the interceptor chains have different > interceptors, you will > get different behavior, and you should be getting that > through other means > such as additional deployments. > > Therefore, for a conceptual interceptor chain of ci1 > ci2 > > si1 > si2, &g
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
On 2003.02.24 15:16 Igor Fedorenko wrote: > David, > > Can you remind me how you are going to deal with possible loops in > transaction tree. > > Consider this scenario: node A starts a transaction, does some work and > calls node B. Node B does some more work and calls node A back. There is > no way node B can know if the transaction has visited node A or not, and > if I understood your design correctly node B will enlist node A into the > transaction and create a loop. yes. I don't really see any alternative. B has to send A some indication of what transaction the work should be done in, and A has to be able to send back some indication that the work failed, tx is marked for rollback. Of course, this is no big deal, all you > have to do is to write TransactionImpl to re-entrant and make sure that > TransactionImpl.prepare returns "read-only" if the transaction is already > being prepared. I guess one part of this is that the tx import should recognize if there is already a branch of the tx on the machine, and use the original import/original tx. I'll have to review to see if this is what happens. Thanks david > > Thanks in advance. > > > > > -Original Message- > > From: David Jencks [mailto:[EMAIL PROTECTED] > > Sent: Monday, February 24, 2003 2:11 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > > since sliced bread > > > > > > Bill, what I find really boring and unpleasant about this > > discussion is > > that I can't find any evidence that you read most of my > > posts, or that you > > remember the reasons for my design decisions for more than > > about 5 minutes. > > I've written fairly detailed explanations of my views of > > both interceptor > > architecture and corba integration and asked for comments or > > whether you > > agree or disagree. I haven't seen any direct responses. > > > > At this point I don't want to read the same argument from you again. > > Please implement your idea for how dtm will work so we can discuss > > something concrete. > > > > thanks > > david > > > > > > On 2003.02.24 13:37 Bill Burke wrote: > > > Sure. The TxSupport class is a nice change and makes the > > code much more > > > readable. I have stated this before. But > > > > > > Merge TxSupport.clientInvoke and serverInvoke into one > > method. Remove > > > all > > > logic from client interceptor except TX propagation. > > Propagate the TX > > > always. Again, my reasoning is to isolate the EJB > > container from the > > > transport mechanism. Currently, in 3.2, you can invoke on > > an EJB from > > > any > > > protocol at the same time. With David's change, non-Java > > clients that > > > support TX propagation would require that > > TxSupport.clientInvoke be run > > > on > > > the server thus requiring us to have transport specific server-sdie > > > interceptor chains and a change to the current > > architecture. I think > > > that > > > this creates further complication in the server-side > > architecture and > > > will > > > further bloat configuration. All just to save a tx propagation for > > > NotSupported and RequiresNew methods. > > > > > > Or are you talking about the AOP stuff? Well, it is > > implemented, I do > > > have > > > an API. I have written the AOP Tx interceptor and it is > > tested within > > > the > > > testsuite. I am working on the Security one. So far, my > > design seems to > > > fit. The real test will be with the persistence metadata > > since this is > > > much more complicated. I've made an attempt to explain my > > design with > > > the > > > bootcamp slides and the crappy documentation I put together on the > > > website > > > /developers/projects/jboss/aop.jsp. > > > > > > > > > Bill > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > > Behalf Of Dain > > > > Sundstrom > > > > Sent: Monday, February 24, 2003 12:36 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [JBoss-dev] TxInterceptor split is still the > > best thing > > > > since sliced bread > > > > > > > > > > > > Bill, &
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
David, Can you remind me how you are going to deal with possible loops in transaction tree. Consider this scenario: node A starts a transaction, does some work and calls node B. Node B does some more work and calls node A back. There is no way node B can know if the transaction has visited node A or not, and if I understood your design correctly node B will enlist node A into the transaction and create a loop. Of course, this is no big deal, all you have to do is to write TransactionImpl to re-entrant and make sure that TransactionImpl.prepare returns "read-only" if the transaction is already being prepared. Thanks in advance. > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED] > Sent: Monday, February 24, 2003 2:11 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > since sliced bread > > > Bill, what I find really boring and unpleasant about this > discussion is > that I can't find any evidence that you read most of my > posts, or that you > remember the reasons for my design decisions for more than > about 5 minutes. > I've written fairly detailed explanations of my views of > both interceptor > architecture and corba integration and asked for comments or > whether you > agree or disagree. I haven't seen any direct responses. > > At this point I don't want to read the same argument from you again. > Please implement your idea for how dtm will work so we can discuss > something concrete. > > thanks > david > > > On 2003.02.24 13:37 Bill Burke wrote: > > Sure. The TxSupport class is a nice change and makes the > code much more > > readable. I have stated this before. But > > > > Merge TxSupport.clientInvoke and serverInvoke into one > method. Remove > > all > > logic from client interceptor except TX propagation. > Propagate the TX > > always. Again, my reasoning is to isolate the EJB > container from the > > transport mechanism. Currently, in 3.2, you can invoke on > an EJB from > > any > > protocol at the same time. With David's change, non-Java > clients that > > support TX propagation would require that > TxSupport.clientInvoke be run > > on > > the server thus requiring us to have transport specific server-sdie > > interceptor chains and a change to the current > architecture. I think > > that > > this creates further complication in the server-side > architecture and > > will > > further bloat configuration. All just to save a tx propagation for > > NotSupported and RequiresNew methods. > > > > Or are you talking about the AOP stuff? Well, it is > implemented, I do > > have > > an API. I have written the AOP Tx interceptor and it is > tested within > > the > > testsuite. I am working on the Security one. So far, my > design seems to > > fit. The real test will be with the persistence metadata > since this is > > much more complicated. I've made an attempt to explain my > design with > > the > > bootcamp slides and the crappy documentation I put together on the > > website > > /developers/projects/jboss/aop.jsp. > > > > > > Bill > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > Behalf Of Dain > > > Sundstrom > > > Sent: Monday, February 24, 2003 12:36 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [JBoss-dev] TxInterceptor split is still the > best thing > > > since sliced bread > > > > > > > > > Bill, > > > > > > Where is you design? David's design looks totally > obvious to me. It > > > is well understood, and based on our existing > "real-world" experiences. > > > To me it looks like you are the one invent "the perfect > design/API". > > > So can you present you invocation chain as did and show > us the error in > > > our logic? > > > > > > -dain > > > > > > On Monday, February 24, 2003, at 09:39 AM, 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
> > One more thing. This was fine in 2.4 and 3.0 when there was a one to one > mapping between client, transport and EJB Container, but in 3.2 and > higher, > there is a many to one relationship between transport and EJB Container. > So? I just checked standard jboss.xml and all the client interceptor chains depend only on the nature of the object at the top, not the transport mechanism. IMO the transport mechanism should not affect the functionality of the interceptor chain, and the transport mechansim should be completely pluggable. I tend to regard the 2 or 3 chains for clients (home, single bean, and list) as conceptually different chains: certainly if we have method-specific interceptor chains they will be different. So, once more: my idea of a chain is like: ci1 ci2 ... plugable transport layer si1 si2 ... target object. Whatever transport layer you plug in, the interceptors should be the same. This goes for remote, local, corba, whatever. Where the ci's live is a separate question. david --- 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
; the server thus requiring us to have transport specific server-sdie > > > interceptor chains and a change to the current architecture. I think > > > that > > > this creates further complication in the server-side architecture and > > > will > > > further bloat configuration. All just to save a tx propagation for > > > NotSupported and RequiresNew methods. > > > > > > Or are you talking about the AOP stuff? Well, it is implemented, I > do > > > have > > > an API. I have written the AOP Tx interceptor and it is tested > within > > > the > > > testsuite. I am working on the Security one. So far, my > > design seems to > > > fit. The real test will be with the persistence metadata since this > is > > > much more complicated. I've made an attempt to explain my design > with > > > the > > > bootcamp slides and the crappy documentation I put together on the > > > website > > > /developers/projects/jboss/aop.jsp. > > > > > > > > > Bill > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > > Behalf Of Dain > > > > Sundstrom > > > > Sent: Monday, February 24, 2003 12:36 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [JBoss-dev] TxInterceptor split is still the best > thing > > > > since sliced bread > > > > > > > > > > > > Bill, > > > > > > > > Where is you design? David's design looks totally obvious to me. > It > > > > is well understood, and based on our existing "real-world" > > experiences. > > > > To me it looks like you are the one invent "the perfect > design/API". > > > > So can you present you invocation chain as did and show us > > the error in > > > > our logic? > > > > > > > > -dain > > > > > > > > On Monday, February 24, 2003, at 09:39 AM, 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? > > > > > > > > > > === > > > > > > > > > > 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 &g
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
> > > > > > > Bill, what I find really boring and unpleasant about this discussion is > > that I can't find any evidence that you read most of my posts, > or that you > > Ditto. > > I thought I did read your stuff and replied appropriately. Maybe I missed > something. What I saw you propose for non-Java and I'll quote you: > > "outside world >>> something corba and proxy-like > ci1 > ci2 > > some kind of > invoker-like thing > si1 > si2 > actual target object" > One more thing. This was fine in 2.4 and 3.0 when there was a one to one mapping between client, transport and EJB Container, but in 3.2 and higher, there is a many to one relationship between transport and EJB Container. > My argument against this was that you would have to maintain 2 separate > interceptor chains on the server. > > For IIOP the chain would be (as you stated) > > IIOPInvoker > ci1 > ci2 > si1 > si2 > actual target object. > > For RMI/Java the chain would be > > DP > ci1 > ci2 > network --- JRMPInvoker > si1 > si2 > > I voiced a similar problem with AOP where the AOP interceptors > would have to > know whether the call had traveled through a remote proxy object. > > > remember the reasons for my design decisions for more than about > > 5 minutes. > > I've written fairly detailed explanations of my views of both > interceptor > > architecture and corba integration and asked for comments or whether you > > agree or disagree. I haven't seen any direct responses. > > > > At this point I don't want to read the same argument from you again. > > Please implement your idea for how dtm will work so we can discuss > > something concrete. > > > > I think I already have (see below), but will reread your posts to > make sure. > > Bill > > > > > thanks > > david > > > > > > On 2003.02.24 13:37 Bill Burke wrote: > > > Sure. The TxSupport class is a nice change and makes the > code much more > > > readable. I have stated this before. But > > > > > > Merge TxSupport.clientInvoke and serverInvoke into one method. Remove > > > all > > > logic from client interceptor except TX propagation. Propagate the TX > > > always. Again, my reasoning is to isolate the EJB container from the > > > transport mechanism. Currently, in 3.2, you can invoke on an EJB from > > > any > > > protocol at the same time. With David's change, non-Java clients that > > > support TX propagation would require that > TxSupport.clientInvoke be run > > > on > > > the server thus requiring us to have transport specific server-sdie > > > interceptor chains and a change to the current architecture. I think > > > that > > > this creates further complication in the server-side architecture and > > > will > > > further bloat configuration. All just to save a tx propagation for > > > NotSupported and RequiresNew methods. > > > > > > Or are you talking about the AOP stuff? Well, it is implemented, I do > > > have > > > an API. I have written the AOP Tx interceptor and it is tested within > > > the > > > testsuite. I am working on the Security one. So far, my > > design seems to > > > fit. The real test will be with the persistence metadata > since this is > > > much more complicated. I've made an attempt to explain my design with > > > the > > > bootcamp slides and the crappy documentation I put together on the > > > website > > > /developers/projects/jboss/aop.jsp. > > > > > > > > > Bill > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > > Behalf Of Dain > > > > Sundstrom > > > > Sent: Monday, February 24, 2003 12:36 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [JBoss-dev] TxInterceptor split is still the best thing > > > > since sliced bread > > > > > > > > > > > > Bill, > > > > > > > > Where is you design? David's design looks totally obvious > to me. It > > > > is well understood, and based on our existing "real-world" > > experiences. > > > > To me it looks like you are the one invent "the perfect > design/API". > > > > So can you present you invocation chain as did and show us > > the error
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
> > Bill, what I find really boring and unpleasant about this discussion is > that I can't find any evidence that you read most of my posts, or that you Ditto. I thought I did read your stuff and replied appropriately. Maybe I missed something. What I saw you propose for non-Java and I'll quote you: "outside world >>> something corba and proxy-like > ci1 > ci2 > some kind of invoker-like thing > si1 > si2 > actual target object" My argument against this was that you would have to maintain 2 separate interceptor chains on the server. For IIOP the chain would be (as you stated) IIOPInvoker > ci1 > ci2 > si1 > si2 > actual target object. For RMI/Java the chain would be DP > ci1 > ci2 > network --- JRMPInvoker > si1 > si2 I voiced a similar problem with AOP where the AOP interceptors would have to know whether the call had traveled through a remote proxy object. > remember the reasons for my design decisions for more than about > 5 minutes. > I've written fairly detailed explanations of my views of both interceptor > architecture and corba integration and asked for comments or whether you > agree or disagree. I haven't seen any direct responses. > > At this point I don't want to read the same argument from you again. > Please implement your idea for how dtm will work so we can discuss > something concrete. > I think I already have (see below), but will reread your posts to make sure. Bill > thanks > david > > > On 2003.02.24 13:37 Bill Burke wrote: > > Sure. The TxSupport class is a nice change and makes the code much more > > readable. I have stated this before. But > > > > Merge TxSupport.clientInvoke and serverInvoke into one method. Remove > > all > > logic from client interceptor except TX propagation. Propagate the TX > > always. Again, my reasoning is to isolate the EJB container from the > > transport mechanism. Currently, in 3.2, you can invoke on an EJB from > > any > > protocol at the same time. With David's change, non-Java clients that > > support TX propagation would require that TxSupport.clientInvoke be run > > on > > the server thus requiring us to have transport specific server-sdie > > interceptor chains and a change to the current architecture. I think > > that > > this creates further complication in the server-side architecture and > > will > > further bloat configuration. All just to save a tx propagation for > > NotSupported and RequiresNew methods. > > > > Or are you talking about the AOP stuff? Well, it is implemented, I do > > have > > an API. I have written the AOP Tx interceptor and it is tested within > > the > > testsuite. I am working on the Security one. So far, my > design seems to > > fit. The real test will be with the persistence metadata since this is > > much more complicated. I've made an attempt to explain my design with > > the > > bootcamp slides and the crappy documentation I put together on the > > website > > /developers/projects/jboss/aop.jsp. > > > > > > Bill > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > Behalf Of Dain > > > Sundstrom > > > Sent: Monday, February 24, 2003 12:36 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [JBoss-dev] TxInterceptor split is still the best thing > > > since sliced bread > > > > > > > > > Bill, > > > > > > Where is you design? David's design looks totally obvious to me. It > > > is well understood, and based on our existing "real-world" > experiences. > > > To me it looks like you are the one invent "the perfect design/API". > > > So can you present you invocation chain as did and show us > the error in > > > our logic? > > > > > > -dain > > > > > > On Monday, February 24, 2003, at 09:39 AM, 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, b
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
Bill, what I find really boring and unpleasant about this discussion is that I can't find any evidence that you read most of my posts, or that you remember the reasons for my design decisions for more than about 5 minutes. I've written fairly detailed explanations of my views of both interceptor architecture and corba integration and asked for comments or whether you agree or disagree. I haven't seen any direct responses. At this point I don't want to read the same argument from you again. Please implement your idea for how dtm will work so we can discuss something concrete. thanks david On 2003.02.24 13:37 Bill Burke wrote: > Sure. The TxSupport class is a nice change and makes the code much more > readable. I have stated this before. But > > Merge TxSupport.clientInvoke and serverInvoke into one method. Remove > all > logic from client interceptor except TX propagation. Propagate the TX > always. Again, my reasoning is to isolate the EJB container from the > transport mechanism. Currently, in 3.2, you can invoke on an EJB from > any > protocol at the same time. With David's change, non-Java clients that > support TX propagation would require that TxSupport.clientInvoke be run > on > the server thus requiring us to have transport specific server-sdie > interceptor chains and a change to the current architecture. I think > that > this creates further complication in the server-side architecture and > will > further bloat configuration. All just to save a tx propagation for > NotSupported and RequiresNew methods. > > Or are you talking about the AOP stuff? Well, it is implemented, I do > have > an API. I have written the AOP Tx interceptor and it is tested within > the > testsuite. I am working on the Security one. So far, my design seems to > fit. The real test will be with the persistence metadata since this is > much more complicated. I've made an attempt to explain my design with > the > bootcamp slides and the crappy documentation I put together on the > website > /developers/projects/jboss/aop.jsp. > > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Dain > > Sundstrom > > Sent: Monday, February 24, 2003 12:36 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] TxInterceptor split is still the best thing > > since sliced bread > > > > > > Bill, > > > > Where is you design? David's design looks totally obvious to me. It > > is well understood, and based on our existing "real-world" experiences. > > To me it looks like you are the one invent "the perfect design/API". > > So can you present you invocation chain as did and show us the error in > > our logic? > > > > -dain > > > > On Monday, February 24, 2003, at 09:39 AM, 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? > > > > > > === > > > > > > As far as AOP goes, I'm hoping that as we implement services on top > of
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
Sure. The TxSupport class is a nice change and makes the code much more readable. I have stated this before. But Merge TxSupport.clientInvoke and serverInvoke into one method. Remove all logic from client interceptor except TX propagation. Propagate the TX always. Again, my reasoning is to isolate the EJB container from the transport mechanism. Currently, in 3.2, you can invoke on an EJB from any protocol at the same time. With David's change, non-Java clients that support TX propagation would require that TxSupport.clientInvoke be run on the server thus requiring us to have transport specific server-sdie interceptor chains and a change to the current architecture. I think that this creates further complication in the server-side architecture and will further bloat configuration. All just to save a tx propagation for NotSupported and RequiresNew methods. Or are you talking about the AOP stuff? Well, it is implemented, I do have an API. I have written the AOP Tx interceptor and it is tested within the testsuite. I am working on the Security one. So far, my design seems to fit. The real test will be with the persistence metadata since this is much more complicated. I've made an attempt to explain my design with the bootcamp slides and the crappy documentation I put together on the website /developers/projects/jboss/aop.jsp. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Dain > Sundstrom > Sent: Monday, February 24, 2003 12:36 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] TxInterceptor split is still the best thing > since sliced bread > > > Bill, > > Where is you design? David's design looks totally obvious to me. It > is well understood, and based on our existing "real-world" experiences. > To me it looks like you are the one invent "the perfect design/API". > So can you present you invocation chain as did and show us the error in > our logic? > > -dain > > On Monday, February 24, 2003, at 09:39 AM, 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? > > > > === > > > > 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 > >
Re: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
Bill, Where is you design? David's design looks totally obvious to me. It is well understood, and based on our existing "real-world" experiences. To me it looks like you are the one invent "the perfect design/API". So can you present you invocation chain as did and show us the error in our logic? -dain On Monday, February 24, 2003, at 09:39 AM, 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? === 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.invok
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
On 2003.02.24 11:22 Sacha Labourey wrote: > Hello David, > > > 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. > > My guess is that for non-java client, we will (in almost all cases) not > decide what can be done on the client side. Consequently, it will most > probably be the role of the server side invoker to populate the > Invocation > object with additional "well-known-attributes" that are directly > extracted > from the "context" of this specific transport (and not by some > jbossish-client-interceptor as they won't exist in this case) I think, then, that we agree that the functionality implemented by client-side interceptors is not optional but required. I was proposing for simplicity and flexibility that we always implement this functionality with the same code: for non java clients, we have to run these client side interceptors on the server, and the specific transport will have to provide an environment equivalent to the java client environment so that the "client" interceptors can still work. Since we can't really control which client interceptors people will want to use, I don't think we can hardcode the client interceptor functionality into the transport specific code. david > > > > > --- > 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
Hello David, > 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. My guess is that for non-java client, we will (in almost all cases) not decide what can be done on the client side. Consequently, it will most probably be the role of the server side invoker to populate the Invocation object with additional "well-known-attributes" that are directly extracted from the "context" of this specific transport (and not by some jbossish-client-interceptor as they won't exist in this case) --- 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
> -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? === 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
I am getting really tired of doing this you guys. I'll try taking a look at it, in the meantime can we burry the hatchets? If the case is that grey it probably means there isn't a good answer, I will talk with Scott in Vegas. cheer up guys, the road is still long, marcf > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > 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 > 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 > >\/ >
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 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 iter
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Friday, February 21, 2003 9:26 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > since sliced bread > > > 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. > > > > > > > > > > > > > H...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. > Implementation detail. Who cares. > > > > > > > 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. > Actually I thought of another reason why having a per method interceptor for TX is bad. You wouldn't be able to override the behavior at runtime. One of the goals I have for the AOP framework and JBOss in general is the ability to override behavior for one and only one method call. Maybe you want to programatically decide transaction boundaries for a method call. But anyways.you raise a good point that I haven't thought of even though I think per method interceptor for TX is a bad idea. In AOP I want the definition of class metadata and interceptions(pointcuts) to remain isolated. Currently the ClassAdvisor asks the interceptor factory for an instance of an interceptor and adds it to the chain. I need to switch this around so that the factory has control on how interceptors get attached to the chain instead. This is so I can define chains easily for a whole range of classes : Yet, be able to have per method interceptor stacks for a particular interceptor type by letting the factory handle how interceptor(s) get attached to the Class. Am I making sense? Yes? good, No? Doesn't matter, implementation detail > > > TO do this he > > creates a > > Mandatory.java class and attaches it to the method. You see now? > > > > Actually David, yo
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
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. > > > > > > > > > > H...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 sim
