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
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
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
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, 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. 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
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 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
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
-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 Im 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 points: ci1 and si1. If you regard this as more than one interceptor chain please explain your point of view. As I understand it, this is also essentially how we handle ejbs today: certainly we maintain both the client and server interceptor stacks on the server. It is not the same chain. Do the actual XML configuration remembering that a C++ IIOP client does not have client-side interceptors. You will find that in no way will you be able to define configuration such that one target object can receive requests from multiple transports at the same time with the current architecture. Maybe we eventually need to have the ability to define 2 separate interceptor chains. 1 for transport/target object specific things and 1 for generic target objects. Or maybe we should define the whole client
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
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
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
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
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
-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.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
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 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
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 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
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.invokeNext(). Otherwise, it replaces the interceptor iterator with one for the client side transport interceptor stack. \/ * Several interceptors (client side interceptors
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 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
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 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
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, 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
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 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
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 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
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
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 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
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, 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
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 \/ * 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
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 iterator also
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 similar to a local ejb call, except it may not start with a dynamic proxy ( I don't know what it would start with). Also I don't know it the invoker-like thing would do nothing or something.
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 : interceptor-pointcut name=j2ee class=com.* interceptors interceptor factory=Tx .../ interceptor factory=Security... ... / /interceptors /interceptor-poincut 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, 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 Remember what we're trying to do here. MyObject obj = new MyObject(...); obj.doSomeMethod(); construction is intercepted doSomeMethod is intercepted. To have a local invoker new MyObject(...) would have to create a non-dynamic proxy with MyObject. The is unacceptable because then we have to define a contract for doing AOP when
