[JBoss-dev] 福建东南汽车
[JBoss-dev] 福建东南汽车
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
> 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
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'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
