You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Blevins <da...@visi.com> on 2003/11/24 02:26:31 UTC
Re: Proposal: Change the way interceptors are stacked
On Sun, Nov 23, 2003 at 05:47:40PM -0800, Jeremy Boynes wrote:
> Currently the interceptor stack is built from the front backwards using
> the addInterceptor method on the container.
>
> I would like to propose we change to build the stack in the opposite
> order, from the back forward. This would allow us to make the next
> interceptor a private final initialized in the Interceptor's
> constructor. It also makes multi-headed interceptor chains easier to
> understand which will help with OpenEJB integration, and simplifies the
> code in the containers that builds the stacks.
>
+1
I'll note for others reading that with the current front-back (first-last) style of building the stack makes it impossible to add another interceptor later -- it would actually end up after the "final" interceptor in the chain and would never be invoked. Putting the final/end interceptor in the stack first allows you to keep adding interceptors in front of it.
-David
Re: Proposal: Change the way interceptors are stacked
Posted by James Strachan <ja...@yahoo.co.uk>.
On 24 Nov 2003, at 01:26, David Blevins wrote:
> On Sun, Nov 23, 2003 at 05:47:40PM -0800, Jeremy Boynes wrote:
>> Currently the interceptor stack is built from the front backwards
>> using
>> the addInterceptor method on the container.
>>
>> I would like to propose we change to build the stack in the opposite
>> order, from the back forward. This would allow us to make the next
>> interceptor a private final initialized in the Interceptor's
>> constructor. It also makes multi-headed interceptor chains easier to
>> understand which will help with OpenEJB integration, and simplifies
>> the
>> code in the containers that builds the stacks.
>>
>
> +1
>
> I'll note for others reading that with the current front-back
> (first-last) style of building the stack makes it impossible to add
> another interceptor later -- it would actually end up after the
> "final" interceptor in the chain and would never be invoked. Putting
> the final/end interceptor in the stack first allows you to keep adding
> interceptors in front of it.
+1
Sounds convincing to me.
James
-------
http://radio.weblogs.com/0112098/
Re: Proposal: Change the way interceptors are stacked
Posted by Jeremy Boynes <je...@coredevelopers.net>.
Aaron Mulder wrote:
> Couldn't we construct the new stack "next to" the old one, and
> then "swap it in" at the beginning of the next invocation? That way the
> old invocation completes against the complete old stack, getNext() has no
> problems, etc. but new invocations complete against the complete new
> stack.
>
Kind of, but we need to know when the 'next' invocation is - I think it
is best if all invocations in the same transaction use the same stack.
I think this means we need some form of global config version id which
can be included into a transaction, or maybe we can determine this from
a global transaction id. Anyway, the thought of multiple concurrent
versions of the same container gives me the creeps and for now KISS says
just stop, reconfigure and restart :-)
Whatever we come up with for this though, I don't think it affects the
switch to building the stack from the inside out.
--
Jeremy
Re: Proposal: Change the way interceptors are stacked
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Sun, 23 Nov 2003, Jeremy Boynes wrote:
> This most definitely does *not* support changing the stack on the fly.
> In Geronimo, the stack is built when the container is started and
> remains constant until it stops. This avoids the need to synchronize on
> getNext(), and eliminates the potential for the stack changing part of
> the way through an invocation.
>
> I would look at your usecase in Castor _really_ hard and see if you can
> take the stack offline to do the switch. We will be doing that in
> Geronimo with versioned containers.
Couldn't we construct the new stack "next to" the old one, and
then "swap it in" at the beginning of the next invocation? That way the
old invocation completes against the complete old stack, getNext() has no
problems, etc. but new invocations complete against the complete new
stack.
Aaron
Re: Proposal: Change the way interceptors are stacked
Posted by Jeremy Boynes <je...@coredevelopers.net>.
Bruce Snyder wrote:
> Dain and I were talking about this at ApacheCon. I'm considering adding
> an interceptor stack to Castor JDO for various reasons. One of those
> reasons is the need to change the stack on the fly. But I'm not sure
> if I understand how switching the order of the stack would allow this
> to happen?
>
This most definitely does *not* support changing the stack on the fly.
In Geronimo, the stack is built when the container is started and
remains constant until it stops. This avoids the need to synchronize on
getNext(), and eliminates the potential for the stack changing part of
the way through an invocation.
I would look at your usecase in Castor _really_ hard and see if you can
take the stack offline to do the switch. We will be doing that in
Geronimo with versioned containers.
--
Jeremy
Re: Proposal: Change the way interceptors are stacked
Posted by Bruce Snyder <fe...@frii.com>.
This one time, at band camp, David Blevins said:
DB>On Sun, Nov 23, 2003 at 05:47:40PM -0800, Jeremy Boynes wrote:
DB>> Currently the interceptor stack is built from the front backwards using
DB>> the addInterceptor method on the container.
DB>>
DB>> I would like to propose we change to build the stack in the opposite
DB>> order, from the back forward. This would allow us to make the next
DB>> interceptor a private final initialized in the Interceptor's
DB>> constructor. It also makes multi-headed interceptor chains easier to
DB>> understand which will help with OpenEJB integration, and simplifies the
DB>> code in the containers that builds the stacks.
DB>>
DB>
DB>+1
DB>
DB>I'll note for others reading that with the current front-back (first-last) style of building the stack makes it impossible to add another interceptor later -- it would actually end up after the "final" interceptor in the chain and would never be invoked. Putting the final/end interceptor in the stack first allows you to keep adding interceptors in front of it.
Dain and I were talking about this at ApacheCon. I'm considering adding
an interceptor stack to Castor JDO for various reasons. One of those
reasons is the need to change the stack on the fly. But I'm not sure
if I understand how switching the order of the stack would allow this
to happen?
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://incubator.apache.org/projects/geronimo.html