On 10/4/07, David Jencks <david_jencks@yahoo.com> 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.
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.

Alex