RE: [JBoss-dev] JBoss 4.0 Entity Redesign
-Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of David Jencks Sent: Monday, October 21, 2002 4:52 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign On 2002.10.21 10:50:45 -0400 Bill Burke wrote: 1. Interceptors do not belong in the JMX layer. JMX should stay simple. If you want interceptors in front of an MBean, you should make the MBean an aspect. Let's gut out the JMX interceptors in favor of using Hiram's Aspect stuff when its mature enough. I disagree. Juha implemented the mbean server based on interceptors for the same reason most of jboss is based on interceptors. I think there should only be one kind of interceptor stack, used for mbeans, clients, aspects, ejbs. In the server, what's on the top makes it an mbean. In a client, it can be the proxy. For aspects, maybe something else. But we only need one kind of interceptor (as in interface that all interceptors implement and how do we invoke each interceptor in the stack, not as in they should all be stateless/ful). Yes there should be only one kind of interceptor stack. This is the Aspect framework (all aspects are, are interceptors anyways). JMX worries about deployment, dependencies, management, basically its a lightweight component framework. Aspects provide the interceptors. If you implement an MBean as an Aspect you can use the power of the Aspect framework. Complete separation. As you said, there only needs to be one kind of interceptor stack. This is the Aspect Framework. So both POJOs and MBeans can have interceptors via the Aspect Framework. Unified. For ejbs, this will translate into a slightly odd kind of mbean, since there won't exactly be one particular object at the end of the stack, but rather the instance will get selected by one of the interceptors. Its not odd at all. The object at the end of the stack is the Interceptor that invokes on the actual EJB. Bill 2. I really don't like this idea of storing state in some detached hashmap somewhere. You're getting back to functional programing with structures and functions. I agree with Marc, hashmap.getvalue is just plain unreadable as well. Hiram, example of state? An example is the Nuke pattern for replicated SFSB. The state of the SFSB stays with the client in the vent of a total destruction of the server. The client provides the state in the event of a failover. Another is IDEMPOTENT methods. Idenpotent methods return the same value no matter what. An interceptor knowing this could store the state of the returned method call and avoid a remote invocation. The above are examples of state per instance. Now I believe you would have singleton interceptors that needed to maintain state. An example is a client side interceptor that does clustering, loadbalancing and failover. It needs to maintain a list of available nodes. There are kind of 3 kinds of state: Configuration of interceptor instances of the same class, conceptually from some kind of interceptor factory. This should definitely be kept in the interceptor instance. Related to this is which interceptors are in the stack. Both of these are currently recorded in jboss.xml as a config-name for ejb stacks. State of interceptor instances depending not on stack name but on identity the top of stack object. This includes, for ejbs, stuff like local jndi environment, security proxy instances, tx-method associations. I think this is what we are debating. I think it will lead to significantly simpler stack management and clearer thinking about interceptors to store this in a hashmap at the top of the stack. If this state info is stored in the interceptors, you need an instance of the interceptor for each top of stack object. If it is store in the top of stack object, you only need one instance of each interceptor for each stack definition. Currently, most interceptors are stateless in this way, although many already are stateless because they store the state info in the top of stack object. I'm proposing that we formalize this and make the remaining interceptors (such as security proxy) use this model as well. Thirdly, there is state from the method invocation. I think everyone agrees that this state should stay in the method invocation, and we should not create and configure a stack for each invocation. david jencks Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Hiram Chirino Sent: Sunday, October 20, 2002 11:25 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign I think for simplicity we should have only stateless interceptors, any interceptor can store per-stack state in a the stack top in a hashmap. I rewrote
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
Guys this is a great discussion but it needs to move to www.jboss.org/forums in the Aspects on JBoss forums marc f -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 22, 2002 4:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of David Jencks Sent: Monday, October 21, 2002 4:52 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign On 2002.10.21 10:50:45 -0400 Bill Burke wrote: 1. Interceptors do not belong in the JMX layer. JMX should stay simple. If you want interceptors in front of an MBean, you should make the MBean an aspect. Let's gut out the JMX interceptors in favor of using Hiram's Aspect stuff when its mature enough. I disagree. Juha implemented the mbean server based on interceptors for the same reason most of jboss is based on interceptors. I think there should only be one kind of interceptor stack, used for mbeans, clients, aspects, ejbs. In the server, what's on the top makes it an mbean. In a client, it can be the proxy. For aspects, maybe something else. But we only need one kind of interceptor (as in interface that all interceptors implement and how do we invoke each interceptor in the stack, not as in they should all be stateless/ful). Yes there should be only one kind of interceptor stack. This is the Aspect framework (all aspects are, are interceptors anyways). JMX worries about deployment, dependencies, management, basically its a lightweight component framework. Aspects provide the interceptors. If you implement an MBean as an Aspect you can use the power of the Aspect framework. Complete separation. As you said, there only needs to be one kind of interceptor stack. This is the Aspect Framework. So both POJOs and MBeans can have interceptors via the Aspect Framework. Unified. For ejbs, this will translate into a slightly odd kind of mbean, since there won't exactly be one particular object at the end of the stack, but rather the instance will get selected by one of the interceptors. Its not odd at all. The object at the end of the stack is the Interceptor that invokes on the actual EJB. Bill 2. I really don't like this idea of storing state in some detached hashmap somewhere. You're getting back to functional programing with structures and functions. I agree with Marc, hashmap.getvalue is just plain unreadable as well. Hiram, example of state? An example is the Nuke pattern for replicated SFSB. The state of the SFSB stays with the client in the vent of a total destruction of the server. The client provides the state in the event of a failover. Another is IDEMPOTENT methods. Idenpotent methods return the same value no matter what. An interceptor knowing this could store the state of the returned method call and avoid a remote invocation. The above are examples of state per instance. Now I believe you would have singleton interceptors that needed to maintain state. An example is a client side interceptor that does clustering, loadbalancing and failover. It needs to maintain a list of available nodes. There are kind of 3 kinds of state: Configuration of interceptor instances of the same class, conceptually from some kind of interceptor factory. This should definitely be kept in the interceptor instance. Related to this is which interceptors are in the stack. Both of these are currently recorded in jboss.xml as a config-name for ejb stacks. State of interceptor instances depending not on stack name but on identity the top of stack object. This includes, for ejbs, stuff like local jndi environment, security proxy instances, tx-method associations. I think this is what we are debating. I think it will lead to significantly simpler stack management and clearer thinking about interceptors to store this in a hashmap at the top of the stack. If this state info is stored in the interceptors, you need an instance of the interceptor for each top of stack object. If it is store in the top of stack object, you only need one instance of each interceptor for each stack definition. Currently, most interceptors are stateless in this way, although many already are stateless because they store the state info in the top of stack object. I'm proposing that we formalize this and make the remaining interceptors (such as security proxy) use this model as well. Thirdly, there is state from the method invocation. I think everyone agrees that this state should stay
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
See my responses online at www.jboss.org we need to start breaking down the development and letting people get in our development in a more transparent fashion. 1. Interceptors do not belong in the JMX layer. JMX should stay simple. If you want interceptors in front of an MBean, you should make the MBean an aspect. Let's gut out the JMX interceptors in favor of using Hiram's Aspect stuff when its mature enough. Agreed. 2. I really don't like this idea of storing state in some detached hashmap somewhere. You're getting back to functional programing with structures and functions. I agree with Marc, hashmap.getvalue is just plain unreadable as well. Yes and no. I argue these online in response to your thread. marc f --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
Good point, answered online marc f -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Monday, October 21, 2002 10:54 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign I think we need 2 types of interceptors Per instance(per target object) and Singleton (one interceptor serving all target objects). See my previous email for use cases. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Hiram Chirino Sent: Sunday, October 20, 2002 11:41 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign Previously we were on opposite sides of this debate:-) I think for simplicity we should have only stateless interceptors, any interceptor can store per-stack state in a the stack top in a hashmap. This was the way I created the aspect stuff initially. The interceptors were tottaly statless. Even intercetor config was not stored in the interceptor. The config was put at the top of the stack. Advantage: 1 interceptor instance could be used for all stack instances. (less memory usage?? not really, the config objects are created and put at the top of the stack) Disadvantages: Hard to develop the interceptors and I think it lead to worse perfomance. I had to do a hashmap look up of the config every time it had to handle an invocation. --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ 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 emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
While you guys discussed this like a bunch of academics, I have almost all of the code done. I'll commit it when I get back on Friday or Saturday. The changes I have made pass stateful information between interceptors using the Invocation object. Anyway, I'll let the code speak for me. -dain marc fleury wrote: Good point, answered online marc f -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Monday, October 21, 2002 10:54 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign I think we need 2 types of interceptors Per instance(per target object) and Singleton (one interceptor serving all target objects). See my previous email for use cases. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Hiram Chirino Sent: Sunday, October 20, 2002 11:41 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign Previously we were on opposite sides of this debate:-) I think for simplicity we should have only stateless interceptors, any interceptor can store per-stack state in a the stack top in a hashmap. This was the way I created the aspect stuff initially. The interceptors were tottaly statless. Even intercetor config was not stored in the interceptor. The config was put at the top of the stack. Advantage: 1 interceptor instance could be used for all stack instances. (less memory usage?? not really, the config objects are created and put at the top of the stack) Disadvantages: Hard to develop the interceptors and I think it lead to worse perfomance. I had to do a hashmap look up of the config every time it had to handle an invocation. --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ 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 emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
marc fleury wrote: One more request: stateless vs stateful interceptors. It is clear to me that both are needed. For example: stateful are easy to code you just have your variable in there and it is easy. A good example of stateless (taken from invocation) is the read-ahead interceptor. The read-ahead interceptor lives in the CMP stack (if you coded your CMP stack with interceptors). You need to have that information from the client. The client can then set the READ-AHEAD bucket to 3-5 or 20 or whatever it is that he wants to display, the invocation carries that information under the READ-AHEAD value and the interceptor reads it under that value *from the invocation*. It is my feeling that this is now a configuration thingy passed by the XML files. It is good as is, meaning we need the defaults to be configured by the XML file for all the invocations but let the Invocation overwrite them. Bottom line is that I believe the CMP optimization of READ-AHEAD is a good example of both coding practices, in fact they show the *need* for both. CMP will be an set of interceptors so this type of optimization will be trivial. Based on the work I've already done, I think I can eliminate EntityContainer, StatefullSessionContainer, StatelessSessionContainer and MessageDrivenContainer and replace all of them with the single Container class plus some interceptors. I'm not sure about this yet, but it looks like it will be a simple solution in the end. -dain --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
we want to get this stuff under Hiram's aspect framework so that not every subproject in JBoss uses a different interceptor mechanism. Take a look at Hiram's stuff. ITs good. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Tuesday, October 22, 2002 10:22 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign marc fleury wrote: One more request: stateless vs stateful interceptors. It is clear to me that both are needed. For example: stateful are easy to code you just have your variable in there and it is easy. A good example of stateless (taken from invocation) is the read-ahead interceptor. The read-ahead interceptor lives in the CMP stack (if you coded your CMP stack with interceptors). You need to have that information from the client. The client can then set the READ-AHEAD bucket to 3-5 or 20 or whatever it is that he wants to display, the invocation carries that information under the READ-AHEAD value and the interceptor reads it under that value *from the invocation*. It is my feeling that this is now a configuration thingy passed by the XML files. It is good as is, meaning we need the defaults to be configured by the XML file for all the invocations but let the Invocation overwrite them. Bottom line is that I believe the CMP optimization of READ-AHEAD is a good example of both coding practices, in fact they show the *need* for both. CMP will be an set of interceptors so this type of optimization will be trivial. Based on the work I've already done, I think I can eliminate EntityContainer, StatefullSessionContainer, StatelessSessionContainer and MessageDrivenContainer and replace all of them with the single Container class plus some interceptors. I'm not sure about this yet, but it looks like it will be a simple solution in the end. -dain --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com /javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
sorry single container looks like a good idea. It will probably be refactored a bit more to fit in the Aspect stuff. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Tuesday, October 22, 2002 10:22 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign marc fleury wrote: One more request: stateless vs stateful interceptors. It is clear to me that both are needed. For example: stateful are easy to code you just have your variable in there and it is easy. A good example of stateless (taken from invocation) is the read-ahead interceptor. The read-ahead interceptor lives in the CMP stack (if you coded your CMP stack with interceptors). You need to have that information from the client. The client can then set the READ-AHEAD bucket to 3-5 or 20 or whatever it is that he wants to display, the invocation carries that information under the READ-AHEAD value and the interceptor reads it under that value *from the invocation*. It is my feeling that this is now a configuration thingy passed by the XML files. It is good as is, meaning we need the defaults to be configured by the XML file for all the invocations but let the Invocation overwrite them. Bottom line is that I believe the CMP optimization of READ-AHEAD is a good example of both coding practices, in fact they show the *need* for both. CMP will be an set of interceptors so this type of optimization will be trivial. Based on the work I've already done, I think I can eliminate EntityContainer, StatefullSessionContainer, StatelessSessionContainer and MessageDrivenContainer and replace all of them with the single Container class plus some interceptors. I'm not sure about this yet, but it looks like it will be a simple solution in the end. -dain --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com /javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
On 2002.10.21 10:50:45 -0400 Bill Burke wrote: 1. Interceptors do not belong in the JMX layer. JMX should stay simple. If you want interceptors in front of an MBean, you should make the MBean an aspect. Let's gut out the JMX interceptors in favor of using Hiram's Aspect stuff when its mature enough. I disagree. Juha implemented the mbean server based on interceptors for the same reason most of jboss is based on interceptors. I think there should only be one kind of interceptor stack, used for mbeans, clients, aspects, ejbs. In the server, what's on the top makes it an mbean. In a client, it can be the proxy. For aspects, maybe something else. But we only need one kind of interceptor (as in interface that all interceptors implement and how do we invoke each interceptor in the stack, not as in they should all be stateless/ful). For ejbs, this will translate into a slightly odd kind of mbean, since there won't exactly be one particular object at the end of the stack, but rather the instance will get selected by one of the interceptors. 2. I really don't like this idea of storing state in some detached hashmap somewhere. You're getting back to functional programing with structures and functions. I agree with Marc, hashmap.getvalue is just plain unreadable as well. Hiram, example of state? An example is the Nuke pattern for replicated SFSB. The state of the SFSB stays with the client in the vent of a total destruction of the server. The client provides the state in the event of a failover. Another is IDEMPOTENT methods. Idenpotent methods return the same value no matter what. An interceptor knowing this could store the state of the returned method call and avoid a remote invocation. The above are examples of state per instance. Now I believe you would have singleton interceptors that needed to maintain state. An example is a client side interceptor that does clustering, loadbalancing and failover. It needs to maintain a list of available nodes. There are kind of 3 kinds of state: Configuration of interceptor instances of the same class, conceptually from some kind of interceptor factory. This should definitely be kept in the interceptor instance. Related to this is which interceptors are in the stack. Both of these are currently recorded in jboss.xml as a config-name for ejb stacks. State of interceptor instances depending not on stack name but on identity the top of stack object. This includes, for ejbs, stuff like local jndi environment, security proxy instances, tx-method associations. I think this is what we are debating. I think it will lead to significantly simpler stack management and clearer thinking about interceptors to store this in a hashmap at the top of the stack. If this state info is stored in the interceptors, you need an instance of the interceptor for each top of stack object. If it is store in the top of stack object, you only need one instance of each interceptor for each stack definition. Currently, most interceptors are stateless in this way, although many already are stateless because they store the state info in the top of stack object. I'm proposing that we formalize this and make the remaining interceptors (such as security proxy) use this model as well. Thirdly, there is state from the method invocation. I think everyone agrees that this state should stay in the method invocation, and we should not create and configure a stack for each invocation. david jencks Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Hiram Chirino Sent: Sunday, October 20, 2002 11:25 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign I think for simplicity we should have only stateless interceptors, any interceptor can store per-stack state in a the stack top in a hashmap. I rewrote the mbean interceptors this way, it works fine, but then juha committed a completely different reimplementation. David there is no reason to enforce one. We need both coding styles it is easier. I don't think it is easier to always code invocation.getValue(COMMIT-OPTION); as opposed to commitOption when the commit option is configured at deployment. Clearly we can achieve the same result but there is we shouldn't enforce one. When you guys talk about statefullness.. I get a little lost. Marc, is that commitOption statefull: (1) per proxy interceptor instance. 1 interceptor instance is created for each DP. (2) per stack interceptor instance. 1 interceptor instance is created for a stack (shared by DP). Right now the aspect stuff does (2), but you can do the invocation.attachments.get(COMMIT-OPTION); to get a value that was attached to the DP. Regards, Hiram
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
I'm looking at Hiram's aspect stuff and will try to implement client-side interceptors with this new framework. After that i would like to move to the containers. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of marc fleury Sent: Sunday, October 20, 2002 7:47 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign Sounds good, When are we planing on converting the interceptor to having only a single invoke method? I can easily do this with a new abstract interceptor that breaks into the two methods based on invocation type. Any objections? not really, it was a needed clean step. Why must the last interceptor, ContainerInterceptor, be defined by the container? Unless there is a reason, I'm going to move this of the container. A reflective invoking interceptor is a good idea as it is needed for the pure aspect interceptors. One more request: stateless vs stateful interceptors. It is clear to me that both are needed. For example: stateful are easy to code you just have your variable in there and it is easy. A good example of stateless (taken from invocation) is the read-ahead interceptor. The read-ahead interceptor lives in the CMP stack (if you coded your CMP stack with interceptors). You need to have that information from the client. The client can then set the READ-AHEAD bucket to 3-5 or 20 or whatever it is that he wants to display, the invocation carries that information under the READ-AHEAD value and the interceptor reads it under that value *from the invocation*. It is my feeling that this is now a configuration thingy passed by the XML files. It is good as is, meaning we need the defaults to be configured by the XML file for all the invocations but let the Invocation overwrite them. Bottom line is that I believe the CMP optimization of READ-AHEAD is a good example of both coding practices, in fact they show the *need* for both. Does anyone have any general objections to this change? -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
On 2002.10.20 19:46:52 -0400 marc fleury wrote: Sounds good, When are we planing on converting the interceptor to having only a single invoke method? I can easily do this with a new abstract interceptor that breaks into the two methods based on invocation type. Any objections? not really, it was a needed clean step. Why must the last interceptor, ContainerInterceptor, be defined by the container? Unless there is a reason, I'm going to move this of the container. A reflective invoking interceptor is a good idea as it is needed for the pure aspect interceptors. One more request: stateless vs stateful interceptors. It is clear to me that both are needed. For example: stateful are easy to code you just have your variable in there and it is easy. A good example of stateless (taken from invocation) is the read-ahead interceptor. The read-ahead interceptor lives in the CMP stack (if you coded your CMP stack with interceptors). You need to have that information from the client. The client can then set the READ-AHEAD bucket to 3-5 or 20 or whatever it is that he wants to display, the invocation carries that information under the READ-AHEAD value and the interceptor reads it under that value *from the invocation*. It is my feeling that this is now a configuration thingy passed by the XML files. It is good as is, meaning we need the defaults to be configured by the XML file for all the invocations but let the Invocation overwrite them. Bottom line is that I believe the CMP optimization of READ-AHEAD is a good example of both coding practices, in fact they show the *need* for both. Previously we were on opposite sides of this debate:-) I think for simplicity we should have only stateless interceptors, any interceptor can store per-stack state in a the stack top in a hashmap. I rewrote the mbean interceptors this way, it works fine, but then juha committed a completely different reimplementation. I still haven't had a chance to look at the aspect stuff, I do think --interceptor lifecycle events --stateless interceptors, with interceptor state stored in the stack top keyed by interceptor. --one model of interceptors jboss-wide are essential. david jencks Does anyone have any general objections to this change? -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
I think for simplicity we should have only stateless interceptors, any interceptor can store per-stack state in a the stack top in a hashmap. I rewrote the mbean interceptors this way, it works fine, but then juha committed a completely different reimplementation. David there is no reason to enforce one. We need both coding styles it is easier. I don't think it is easier to always code invocation.getValue(COMMIT-OPTION); as opposed to commitOption when the commit option is configured at deployment. Clearly we can achieve the same result but there is we shouldn't enforce one. the stack top keyed by interceptor. --one model of interceptors jboss-wide are essential. not really. In fact it is a minor point. It is one of these things were you can achieve the same thing with 2 different coding styles and there is no reason to enforce one over the other. It is an artificial decision. In fact if you think about it you will realize that we have no business in deciding this bit of the coding practice. The clear difference is 1- If you need the client to send the information then clearly you need the stateless stuff 2- if you don't, don't. marc f --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
Previously we were on opposite sides of this debate:-) I think for simplicity we should have only stateless interceptors, any interceptor can store per-stack state in a the stack top in a hashmap. This was the way I created the aspect stuff initially. The interceptors were tottaly statless. Even intercetor config was not stored in the interceptor. The config was put at the top of the stack. Advantage: 1 interceptor instance could be used for all stack instances. (less memory usage?? not really, the config objects are created and put at the top of the stack) Disadvantages: Hard to develop the interceptors and I think it lead to worse perfomance. I had to do a hashmap look up of the config every time it had to handle an invocation. --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
On 2002.10.19 13:55:07 -0400 Dain Sundstrom wrote: While I was off line for the last two and a half weeks I worked on a redesign of entities from EntityContainer down. The most important part of the redesign is the replacement of the EntityPersistentManager with some new interceptors. very cool. Anyway, I have some questions regarding the container. Are there any other important EntityPersistentManagers other then BMP and CMP? David, I saw the one in connector and I think it will benefit from the new design as it can return to being just an interceptor. excellent. When are we planing on converting the interceptor to having only a single invoke method? I can easily do this with a new abstract interceptor that breaks into the two methods based on invocation type. Any objections? I implemented this a couple of weeks ago and it works except for cmp relations, so I didn't check it in. The testsuite was fucked up at the time, once I got the testsuite working again and found out about the cmr problem I haven't had time to get back to it. It's probably just a dumb mistake. Would you like to take a look? Why are the basic interceptor functions like addInterceptor or getInterceptor implemented in EntityContainer and not Container? I think I moved them. Why must the last interceptor, ContainerInterceptor, be defined by the container? Unless there is a reason, I'm going to move this of the container. Good. All the entity/session/mdb setup stuff should be in an interceptor anyway IMO. Does anyone have any general objections to this change? What I've done might be worth looking at first, save you a day or so. david -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
David Jencks wrote: On 2002.10.19 13:55:07 -0400 Dain Sundstrom wrote: When are we planing on converting the interceptor to having only a single invoke method? I can easily do this with a new abstract interceptor that breaks into the two methods based on invocation type. Any objections? I implemented this a couple of weeks ago and it works except for cmp relations, so I didn't check it in. The testsuite was fucked up at the time, once I got the testsuite working again and found out about the cmr problem I haven't had time to get back to it. It's probably just a dumb mistake. Would you like to take a look? Yes. Is it checked in? Why are the basic interceptor functions like addInterceptor or getInterceptor implemented in EntityContainer and not Container? I think I moved them. This is not checked in. What I've done might be worth looking at first, save you a day or so. I'm doing training in Seattle next week, so I may not get to this until the week after. If you have changes check them in, and I'll fix the cmr problems. I have a fairly big change to EntityContainer, so please don't check in any changes to it until I've got mine in. -dain -dain --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
On 2002.10.19 16:07:29 -0400 Dain Sundstrom wrote: David Jencks wrote: On 2002.10.19 13:55:07 -0400 Dain Sundstrom wrote: When are we planing on converting the interceptor to having only a single invoke method? I can easily do this with a new abstract interceptor that breaks into the two methods based on invocation type. Any objections? I implemented this a couple of weeks ago and it works except for cmp relations, so I didn't check it in. The testsuite was fucked up at the time, once I got the testsuite working again and found out about the cmr problem I haven't had time to get back to it. It's probably just a dumb mistake. Would you like to take a look? Yes. Is it checked in? No, I didn't want to break cmr, especially since I haven't figured out how to fix it. Want a diff or want to wait? Why are the basic interceptor functions like addInterceptor or getInterceptor implemented in EntityContainer and not Container? I think I moved them. This is not checked in. What I've done might be worth looking at first, save you a day or so. I'm doing training in Seattle next week, so I may not get to this until the week after. If you have changes check them in, and I'll fix the cmr problems. I have a fairly big change to EntityContainer, so please don't check in any changes to it until I've got mine in. Will this be, like, today? If not can you send me a diff or something? Do you have any guess at all where I might have installed the problem with cmr by messing with interceptors? There are no exceptions, but assigning a collection from one entity to another results in both collections being empty. Thanks david -dain -dain --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
David Jencks wrote: On 2002.10.19 16:07:29 -0400 Dain Sundstrom wrote: Will this be, like, today? If not can you send me a diff or something? Yes, once I figure out this build error: $ ./build.sh build.sh: *WARNING* Ignoring environment value for $ANT_HOME build.sh: Executing: /cygdrive/c/work/jboss/jboss-head/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:c:/work/jboss/jboss-head/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 2 seconds Do you have any guess at all where I might have installed the problem with cmr by messing with interceptors? There are no exceptions, but assigning a collection from one entity to another results in both collections being empty. No. Did you only change the interceptors? -dain --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
Looks like thirdparty/xdoclet/xdoclet is not checked out. Where did you get your jboss-head from? to fix, you can: cd thirdparty cvs get _thirdparty_xdoclet_xdoclet --jason On Sat, 19 Oct 2002, Dain Sundstrom wrote: David Jencks wrote: On 2002.10.19 16:07:29 -0400 Dain Sundstrom wrote: Will this be, like, today? If not can you send me a diff or something? Yes, once I figure out this build error: $ ./build.sh build.sh: *WARNING* Ignoring environment value for $ANT_HOME build.sh: Executing: /cygdrive/c/work/jboss/jboss-head/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:c:/work/jboss/jboss-head/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 2 seconds Do you have any guess at all where I might have installed the problem with cmr by messing with interceptors? There are no exceptions, but assigning a collection from one entity to another results in both collections being empty. No. Did you only change the interceptors? -dain --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
On 2002.10.19 17:39:13 -0400 Dain Sundstrom wrote: David Jencks wrote: On 2002.10.19 16:07:29 -0400 Dain Sundstrom wrote: Will this be, like, today? If not can you send me a diff or something? Yes, once I figure out this build error: $ ./build.sh build.sh: *WARNING* Ignoring environment value for $ANT_HOME build.sh: Executing: /cygdrive/c/work/jboss/jboss-head/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:c:/work/jboss/jboss-head/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 2 seconds Yukko. Do you have a structure that is the same as a fresh checkout? You may have missed the excitement with the build system. Head now has to be checked out fresh with cvs ... co -r HEAD jboss-head Do you have any guess at all where I might have installed the problem with cmr by messing with interceptors? There are no exceptions, but assigning a collection from one entity to another results in both collections being empty. No. Did you only change the interceptors? I had to change some of the invoker also to not call invokeHome, and also the containers. Where is the main work of adding a collection to a cmr done? thanks david -dain --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
You did miss the build system fun. Check out cvs ... co -r HEAD jboss-head Each branch now has its own set of module definitiions: jboss-all == jboss-3.0 jboss-3.2 jboss-head david jencks On 2002.10.19 19:25:14 -0400 Dain Sundstrom wrote: Jason Dillon wrote: Looks like thirdparty/xdoclet/xdoclet is not checked out. Where did you get your jboss-head from? to fix, you can: cd thirdparty cvs get _thirdparty_xdoclet_xdoclet --jason I just did a clean check out of jboss-all and I still get the error: build.sh: Executing: /cygdrive/c/work/jboss/jboss-all/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger clean Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:c:/work/jboss/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 2 seconds I cleaned up my env variable so it wouldn't bitch but I still get the error. I have XDoclet checked out. Administrator@GODEL ~/work/jboss/jboss-all $ ls thirdparty/xdoclet/xdoclet/lib/ CVS xdoclet-java-module.jar xdoclet-web-module.jar commons-logging.jar xdoclet-jboss-module.jar xdoclet-xdoclet-module.jar xdoclet-bea-module.jar xdoclet-jdo-module.jarxdoclet.jar xdoclet-ejb-module.jar xdoclet-jmx-module.jarxjavadoc.jar Any ideas? -dain --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
David Jencks wrote: You did miss the build system fun. Check out cvs ... co -r HEAD jboss-head Do I really have to put the -r HEAD? I'm glad I wasn't around for this one, but this solution seems like a huge hack. Anyway it will take me a while to move my changes from my old tree to the new one. -dain --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
On 2002.10.19 20:41:32 -0400 Dain Sundstrom wrote: David Jencks wrote: You did miss the build system fun. Check out cvs ... co -r HEAD jboss-head Do I really have to put the -r HEAD? no, that's just for [misplaced] emphasis, sorry. cvs ... co jboss-head works fine. You should be able to update your old tree and copy the new thirdparty directory over your old one and get a working build. Jason's suggestion would have the same effect. I'm glad I wasn't around for this one, but this solution seems like a huge hack. It's better than all the alternatives we could think of. It allows us to update the build module structure on later releases. david Anyway it will take me a while to move my changes from my old tree to the new one. -dain --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
You don't need to use the HEAD tag explicitly. This solution is a hack for deficiencies with CVS. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, October 19, 2002 5:41 PM Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign Do I really have to put the -r HEAD? I'm glad I wasn't around for this one, but this solution seems like a huge hack. Anyway it will take me a while to move my changes from my old tree to the new one. -dain --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
