RE: [JBoss-dev] TxInterceptor split is really really bad
On 2003.02.22 00:13 Bill Burke wrote: Tx propagation can be pushed to a generic remoting framework/object if the underlying transport supports it. Class/Interface Metadata can't. Why not? I thought the txsupport stuff demonstrated that it could. It certainly doesn't depend on any special properties of TrunkInvoker: it is there only because the remoting framework was not generic when I wrote it. david Bill --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TxInterceptor split is really really bad
lördagen den 22 februari 2003 kl 00.45 skrev Bill Burke: I'm not understanding you. Maybe this is Your / Our Problem ? ... !!! ... --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have problems adapting my current design to use corba. Before we continue I think we should get a clear understanding of what is supposed to happen when the corba tx policy and the j2ee tx support disagree. Does anyone know where this is described in specs? Basically the corba design says if there is a transaction in the context it must always be transmitted and imported on the server whereas j2ee does not always need to import the tx. The purpose of the client side interceptor is to not generate tx branches that won't be used. I think that any reasonable corba implementation is going to follow corba semantics and always generate a transaction branch on the client for the remote call, since as far as the corba spec goes, if the call is made within a tx the transaction will in fact be used on the server. In my view the heaviest part of the process is generating a tx branch on the client: once it is generated, then it has to be prepared and/or committed. The communication overhead on these messages is likely to dwarf any other resource usage. The choices I can see here are: 1. only generate the branch if it is needed, but do it right away. This is what I implemented and I think it is simplest and the only one that is likely to be comprehensible when someone looks at it in a week or two. 2. Only generate the branch if it is needed but do it after the work is done. I think this is Ole's proposal. This introduces a lot of bookkeeping on the client to associate client side transactions to branches. I don't think I'd be able to maintain this code, in a week I wouldn't remember how it worked. After spending a day to figure it out, I'd simplify it to (1). 3. Always generate a branch immediately, but have the xaresource return read-only on prepare if the tx did not need to be imported. This is unacceptable because it forces 2pc in the case that there is only one other branch. Don't we need a client side method-to-method-attributes map anyway for many other purposes such as determining if a return value can be cached? david Bill --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___
RE: [JBoss-dev] TxInterceptor split is really really bad
I'm getting kind of tired of what I find vague complaints without detailed explanations of the framework in which you think there might be a problem. I think remote AOP is going to need; 1. some representation of the object you are calling 2. client interceptors. For instance, to get the security context. 3. a transport mechanism 4. something on the other end of the transport mechanism to find the right target 5. server side interceptors If you disagree please explain in detail what you propose. Personally I think the AOP stuff should do this always, with a possible null transport mechanism, at least for remotable objects. If you agree, then I hope you will agree that there has to be some metadata on the client side to define the client interceptors and the transport. If there is some place to put metadata, why can't I use it for the tx support? 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. I also think you will admit that even in aop you could have two interceptors even if both were on the server side: one to get the tx from the context if appropriate or remove it if appropriate, one to start a new tx if appropriate. On 2003.02.21 16:12 Bill Burke wrote: I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. You could have written two separate interceptors, one with the client invoke and one with the server invoke. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. Do you mean transport? I don't understand. But do you see where I'm going? nope I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. So serialization and RMI are a bad idea because they allow moving server logic to the client? In this case the transaction support HAS TO RELY ON THE CLIENT TRANSACTION MANAGER or there will be no dtm. I don't understand why you are getting your knickers in such a twist when I want to move some static data to the client to reduce complexity and comply with the industry standard dtm spec. david All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have problems adapting my current design to use corba. Before we continue I think we should get a clear understanding of what is supposed to happen when the corba tx policy and the j2ee tx support disagree. Does anyone know where this is described in specs? Basically the corba design says if there is a transaction in the context it must always
RE: [JBoss-dev] TxInterceptor split is really really bad
I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have problems adapting my current design to use corba. Before we continue I think we should get a clear understanding of what is supposed to happen when the corba tx policy and the j2ee tx support disagree. Does anyone know where this is described in specs? Basically the corba design says if there is a transaction in the context it must always be transmitted and imported on the server whereas j2ee does not always need to import the tx. The purpose of the client side interceptor is to not generate tx branches that won't be used. I think that any reasonable corba implementation is going to follow corba semantics and always generate a transaction branch on the client for the remote call, since as far as the corba spec goes, if the call is made within a tx the transaction will in fact be used on the server. In my view the heaviest part of the process is generating a tx branch on the client: once it is generated, then it has to be prepared and/or committed. The communication overhead on these messages is likely to dwarf any other resource usage. The choices I can see here are: 1. only generate the branch if it is needed, but do it right away. This is what I implemented and I think it is simplest and the only one that is likely to be comprehensible
RE: [JBoss-dev] TxInterceptor split is really really bad
I think AOP has a separate functional requirement from Remoting and should be separated. Remoting depends (potentially) on AOP. AOP should be the instrumenting, invocation and interception framework. Remoting should then add any semantics for transport and discovery. Individual subsystems (JMX,JMS,EJB), then have a client side proxy (of some sorts, yet to be determined) and a server side invocation handler that know how to convert the local invocation into a remote one using the remoting framework (CLIENT) and know how to take the remote invocation and create a local invocation and return it (SERVER). We should de-couple them into their respective modules of responsibility and functionality. I think the remote tx stuff should be an AOP interceptor that is applied to the EJB client side side remote proxy (that makes the client invoker via remoting) by adding the TX to the invocation payload and then on the other side extracting the TX from the invocation and applying... I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code
RE: [JBoss-dev] TxInterceptor split is really really bad
I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have problems adapting my current design to use corba. Before we continue I think we should get a clear understanding of what is supposed to happen when the corba tx policy and the j2ee tx support disagree. Does anyone know where this is described in specs? Basically the corba design says if there is a transaction in the context it must always be transmitted
RE: [JBoss-dev] TxInterceptor split is really really bad
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a Yes, obviously, but the old tx client proxy just stuffed the tx context in the invocation. The problem with AOP is that (at least for 1st iteration) the POJO can be accessed directly and through a proxy at the same time. yes, I can work around this by having a flag in the Invocation object on whether or not the invocation passed through a proxy, but IMHO, this is a hack. different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? 1st iteration, DynamicProxy. This is trivial since we have already done this sort of thing for EJB and how to do AOP (or how to do it wrong, depends how you look at it), is already there for us to see. Remote AOP with DP is just an iteration to me from the current EJB stuff. 2nd iteration will be with all java classes. The hard part will be how instrumentation works on the client side, how the client receives pointcuts and such. Bill Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have problems adapting my current design to use corba. Before we continue I think we should get a clear understanding of what is supposed to happen when the corba tx
RE: [JBoss-dev] TxInterceptor split is really really bad
Yes - but you guys don't seem to buy into it otherwise you won't be talking about where and how tx or remoting should go into AOP. Maybe I'm missing something. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, February 21, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have
RE: [JBoss-dev] TxInterceptor split is really really bad
Whoops, forgot to send this too. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Friday, February 21, 2003 5:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I'm getting kind of tired of what I find vague complaints without detailed explanations of the framework in which you think there might be a problem. I don't think I was vague. I gave a specific example. The same object could be accessed locally and remotely. Locally through a regular/plain Java reference. Remotely, through a proxy. Because of the way you have defined the TM interaction, the server-side tx interceptor for AOP will have to know if the invocation passed through a Proxy since the object instance can be referenced directly locally. I think remote AOP is going to need; 1. some representation of the object you are calling 2. client interceptors. For instance, to get the security context. 3. a transport mechanism 4. something on the other end of the transport mechanism to find the right target 5. server side interceptors Stop being obvious. If you disagree please explain in detail what you propose. Personally I think the AOP stuff should do this always, with a possible null transport mechanism, at least for remotable objects. Definately no null transport. This would require a proxy. This goes against the primary goal of the framework, to provide J2EE services and remoteness for plain Java objects/classes transparently. So a programmer could say, I have this ordinary Object, I want it accessible as a WebService and yet still access the object locally. For 1st iteration, I intend to require that POJOs can only be remotely accessed via a DynamicProxy. I think this is relatively trivial to implement and will allow us to get an AOP remoting framework out there pretty quickly. 2nd iteration, I want to remove this DynamicProxy requirement, but IMHO, this requires much more thought. If you agree, then I hope you will agree that there has to be some metadata on the client side to define the client interceptors and the transport. If there is some place to put metadata, why can't I use it for the tx support? Again, it has nothing to do about metadata and all about keeping the server isolated from client quirkiness. I just think your tx separation is fragile in this respect. 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. I also think you will admit that even in aop you could have two interceptors even if both were on the server side: one to get the tx from the context if appropriate or remove it if appropriate, one to start a new tx if appropriate. But if there is a remote proxy in between, the client stuff happens twice unless I specifically check to see if there was a proxy in front of the client. BIll --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
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 also think you will admit that even in aop you could have two interceptors even if both were on the server side: one to get the tx from the context if appropriate or remove it if appropriate, one to start a new tx if appropriate. Yes, but I still have to figure out whether or not the method call went through a proxy or was a regular java method call. Bill --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a Yes, obviously, but the old tx client proxy just stuffed the tx context in Orthoganal problem. The ability to have smarter client proxies that have highly coupled interations with a serverside components is a requirment that everybody will agree with. the invocation. The problem with AOP is that (at least for 1st iteration) the POJO can be accessed directly and through a proxy at the same time. This might sound a little crazy... but how about allowing multiple server-side interceptor stacks per object? One for local access, one for stuff over IIOP (that does tx the ots way), one for stuff over JRMP etc. yes, I can work around this by having a flag in the Invocation object on whether or not the invocation passed through a proxy, but IMHO, this is a hack. yes. I am starting to agree. different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? 1st iteration, DynamicProxy. This is trivial since we have already done this sort of thing for EJB and how to do AOP (or how to do it wrong, depends how you look at it), is already there for us to see. Remote AOP with DP is just an iteration to me from the current EJB stuff. 2nd iteration will be with all java classes. The hard part will be how instrumentation works on the client side, how the client receives pointcuts and such. In either case, I'm more intersted in WHO will be responsible creaing proxy objects?? Will it be automatic done when the object is serialized? Or will the application have to make an API call to get a proxy?? Regards, Hiram Bill Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different
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. I also think you will admit that even in aop you could have two interceptors even if both were on the server side: one to get the tx from the context if appropriate or remove it if appropriate, one to start a new tx if appropriate. Yes, but I still have to figure out whether or not the method call went through a proxy or was a regular java method call. Bill --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Haynie Sent: Friday, February 21, 2003 6:15 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad Yes - but you guys don't seem to buy into it otherwise you won't be talking about where and how tx or remoting should go into AOP. Maybe I'm missing something. I'm not understanding you. I certainly buy into it and am implementing stuff (albeit slowly). Whether you and David buy into it is irrelevent. The vision is set. THis is where we're going. The whole point is isolation and being able to dynamically remote or not remote with any protocol you want. IMHO, Davids implementation for tx right now doesn't allow for this isolation. He disagrees. So what? We disagree. Eventually it will all flush out and either David and/or I will end up rewriting everything. My bet David gets there first since I've got A.D.D. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, February 21, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided
RE: [JBoss-dev] TxInterceptor split is really really bad
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 6:30 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a Yes, obviously, but the old tx client proxy just stuffed the tx context in Orthoganal problem. The ability to have smarter client proxies that have highly coupled interations with a serverside components is a requirment that everybody will agree with. the invocation. The problem with AOP is that (at least for 1st iteration) the POJO can be accessed directly and through a proxy at the same time. This might sound a little crazy... but how about allowing multiple server-side interceptor stacks per object? One for local access, one for stuff over IIOP (that does tx the ots way), one for stuff over JRMP etc. In the long run, maybe this can't be avoided, but I would like to avoid it. yes, I can work around this by having a flag in the Invocation object on whether or not the invocation passed through a proxy, but IMHO, this is a hack. yes. I am starting to agree. different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? 1st iteration, DynamicProxy. This is trivial since we have already done this sort of thing for EJB and how to do AOP (or how to do it wrong, depends how you look at it), is already there for us to see. Remote AOP with DP is just an iteration to me from the current EJB stuff. 2nd iteration will be with all java classes. The hard part will be how instrumentation works on the client side, how the client receives pointcuts and such. In either case, I'm more intersted in WHO will be responsible creaing proxy objects?? Will it be automatic done when the object is serialized? Or will the application have to make an API call to get a proxy?? 1st iteration, API: Take a look at how EJB does it and how it works with multiple invokers. This is the approach I will take. I hope to iterate better and cleaner this time around though. Bill Regards, Hiram Bill Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical
RE: [JBoss-dev] TxInterceptor split is really really bad
-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. That's not the issue. The issue is configuration. He wants to avoid sending over metadata about the method/tx bindings. 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. 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. Bill --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
Oh, I buy into it - and I'm neither for OR against what David is saying. I'm merely saying you should separate the concerns - but it seems like that is obvious and redudant (although not so apparent with all the back in forth) to you. As you know, I don't work for Jboss Group. I'm just merely trying to help out on my own *free time* and try and help make this a better product with what little value I can add. Sorry I stepped into the flames. I was hoping to enlighten a little bit to the fact that you could push some of this stuff into the remoting stuff that tom and I worked on. Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Haynie Sent: Friday, February 21, 2003 6:15 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad Yes - but you guys don't seem to buy into it otherwise you won't be talking about where and how tx or remoting should go into AOP. Maybe I'm missing something. I'm not understanding you. I certainly buy into it and am implementing stuff (albeit slowly). Whether you and David buy into it is irrelevent. The vision is set. THis is where we're going. The whole point is isolation and being able to dynamically remote or not remote with any protocol you want. IMHO, Davids implementation for tx right now doesn't allow for this isolation. He disagrees. So what? We disagree. Eventually it will all flush out and either David and/or I will end up rewriting everything. My bet David gets there first since I've got A.D.D. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, February 21, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid
RE: [JBoss-dev] TxInterceptor split is really really bad
--- Bill Burke [EMAIL PROTECTED] wrote: This might sound a little crazy... but how about allowing multiple server-side interceptor stacks per object? One for local access, one for stuff over IIOP (that does tx the ots way), one for stuff over JRMP etc. In the long run, maybe this can't be avoided, but I would like to avoid it. What are the problems related in implementing this?? Regards. Hiram __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TxInterceptor split is really really bad
Jeff, Don't let these guys push you around. Bill's just in a pissy mood today. -dain On Friday, February 21, 2003, at 06:01 PM, Jeff Haynie wrote: Oh, I buy into it - and I'm neither for OR against what David is saying. I'm merely saying you should separate the concerns - but it seems like that is obvious and redudant (although not so apparent with all the back in forth) to you. As you know, I don't work for Jboss Group. I'm just merely trying to help out on my own *free time* and try and help make this a better product with what little value I can add. Sorry I stepped into the flames. I was hoping to enlighten a little bit to the fact that you could push some of this stuff into the remoting stuff that tom and I worked on. Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Haynie Sent: Friday, February 21, 2003 6:15 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad Yes - but you guys don't seem to buy into it otherwise you won't be talking about where and how tx or remoting should go into AOP. Maybe I'm missing something. I'm not understanding you. I certainly buy into it and am implementing stuff (albeit slowly). Whether you and David buy into it is irrelevent. The vision is set. THis is where we're going. The whole point is isolation and being able to dynamically remote or not remote with any protocol you want. IMHO, Davids implementation for tx right now doesn't allow for this isolation. He disagrees. So what? We disagree. Eventually it will all flush out and either David and/or I will end up rewriting everything. My bet David gets there first since I've got A.D.D. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, February 21, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February
RE: [JBoss-dev] TxInterceptor split is really really bad
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Haynie Sent: Friday, February 21, 2003 7:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad Oh, I buy into it - and I'm neither for OR against what David is saying. I'm merely saying you should separate the concerns - but it seems like that is obvious and redudant (although not so apparent with all the back in forth) to you. As you know, I don't work for Jboss Group. I'm just merely trying to help out on my own *free time* and try and help make this a better product with what little value I can add. As Dain said, just ignore flames and don't let them deter you from entering the conversation. (Yes I flamed you, and no, I'm not sorry. But I'd still go out for beers if you're still coming to Boston.) Sorry I stepped into the flames. I was hoping to enlighten a little bit to the fact that you could push some of this stuff into the remoting stuff that tom and I worked on. Tx propagation can be pushed to a generic remoting framework/object if the underlying transport supports it. Class/Interface Metadata can't. Bill Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Haynie Sent: Friday, February 21, 2003 6:15 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad Yes - but you guys don't seem to buy into it otherwise you won't be talking about where and how tx or remoting should go into AOP. Maybe I'm missing something. I'm not understanding you. I certainly buy into it and am implementing stuff (albeit slowly). Whether you and David buy into it is irrelevent. The vision is set. THis is where we're going. The whole point is isolation and being able to dynamically remote or not remote with any protocol you want. IMHO, Davids implementation for tx right now doesn't allow for this isolation. He disagrees. So what? We disagree. Eventually it will all flush out and either David and/or I will end up rewriting everything. My bet David gets there first since I've got A.D.D. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, February 21, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app
