On Oct 4, 2007, at 11:21 AM, Alex Karasulu wrote:
On 10/4/07, David Jencks <[EMAIL PROTECTED]> wrote:
On Oct 4, 2007, at 10:38 AM, Matt Peterson wrote:
Alex,
I'm not sure that including two sets of operational parameters for
calls to the partition is the right answer. Doing this would
allow partitions to be written that could not benefit from
optimizations made by interceptors. I like the interceptor
paradigm because it encourages modularity and code reuse. I think
that it would be wise to "encourage" partition authors to use
interceptors appropriately and not embed into the partition what
should be in an interceptor.
However, it would also be wise to allow users the option of not
using certain interceptors with a particular partition. In other
words, we need per-partition interceptor configuration. I'm
fairly focused on my current project, but I think it would be
generally useful to make the interceptor configurations a property
of the partition configuration (in server.xml). This way users
can select the set of interceptors that they'd like to use with a
given partition. Situations where interceptor functionality is
required by a partition (such as normalization) could easily be
detected in individual partition initialization code and result in
the appropriate (graceful) warning or failure.
I think its clear that there are problems with the current "skip
list" approach when people add custom interceptors that perhaps
should only be used in some circumstances.
The problem resides in the fact that you cannot list the
interceptors to use since you don't know if they will be present.
So the only option is the skip list but yes this data structure is
not serving us well. Plus on top of this there are all sorts of
interceptor dependencies which is causing serious coupling issues.
I've wondered if this problem could be solved by explicitly
configuring the interceptor lists for each purpose in the spring
xml rather than any of hardcoding the skips (current approach),
hardcoding the "applies" (opposite and perhaps even worse approach)
or building a logic engine to decide (I think this has in fact been
tried by some projects). I think jetspeed uses an approach similar
to "configure lots of lists explicitly".
You know this sounds similar to an idea I have been bouncing around
with Emmanuel. Using a variant of the CoR pattern to have a
different chain for each operation: i.e. add, modify, ...
If this idea of configuring lots of interceptor lists in server.xml
worked out it might be pretty easy for these to be specified per
partition as well.
I think we could have a combinatorial explosion if we did this.
Perhaps partitions should just
expose their "skiplist" rather than defining a chain specifically
for each partition's suffix for each
operation.
The combinatorial explosion certainly seems like a real danger. I
kind of think the skip list goes with the operation better than with
the partition.
Thinking about how the skip lists work now I recall that they aren't
based on interceptor identity but name although in trunk the name is
by default the class name of the interceptor. lets see if I can
explain this so anyone can understand what I'm thinking.... if the
skip lists work by functional name and the partitions supply the skip
lists with the interceptors named functionally then the skip lists
would work with different interceptor chains even though the
implementation of some functions would be with different classes.
e.g. the normalization would be done by a different interceptor in
the normal and the Matt partitions, but they'd have the same name...
so if a skip list included "Normalization" that interceptor, whatever
it happened to be for the target partition, would get skipped.
I'll try to explain again from a different point of view...
- partitions specify a "complete" interceptor stack for themselves.
The interceptors have functional names that reflect what they do
rather than necessarily their class.
- skip lists are based on these functional names
- there's something before we get into the interceptor stack that
picks the right interceptor stack based on the target partition
- the skip lists now work for any interceptor stack because they say
what functionality to skip.
What I don't know is if (3), the thing that picks the correct
interceptor stack, is possible to write.
Not sure, but I think what I've described above would work for
embedded implementations too...
Personally I think it's slightly easier to understand what is going
on in the bigbang branch and if you pursue something like the
"explicit lists" approach we could actually commit it without
rewriting if you work against that moving target.
Perhaps we need more discussion around different patterns that we
can use to solve these problems. It's not something we'll be
getting to soon in the code until all the JNDI demolition settles
so this gives us some time to research and discuss.
definitely
thanks
david jencks
Alex
