On 10/4/07, David Jencks <email@example.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.
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".
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.
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.Not sure, but I think what I've described above would work for embedded implementations too...