Hi Joe, comments below.
On 27 Jul 2010, at 20:38, Joe Bohn wrote: > Under https://issues.apache.org/jira/browse/ARIES-369 Valentin proposed that > we perhaps should consider generalizing the parsing of bean and method > elements so that they could be common when multiple interceptors are > supported. I think this is perhaps a better discussion to have on the dev > list rather than in a JIRA. > > From Valentin: > Just a thought :) > > Does it make sense to have a notion of a selector subelement that could be > reused by other cross-cutting interceptors (logging, security ...)? Something > like > > <tx:transaction method="insert*" value="Required"> > <ic:select> > <ic:include beanname="*Biz*" /> > <ic:include classname="*.biz.*" /> > </ic:select> > </tx> > > (similar in spirit to what Ant does with filesets). > > > > > From Lin: > Thanks for the suggestion. I think it may makes sense if we start to support > more than transaction interceptors. One possible could be also common out the > method attribute, like > > <tx:transaction value="Required"> > <ic:select> > <ic:include method="insert*" /> > <ic:include beanId="*Biz*" /> > <ic:include classname="*.biz.*" /> > </ic:select> > </tx> > > > And this can apply to both top level and bean level transaction > configuration, except that beanId and classname isn't supported for bean > level configuration. I am not convinced why classname is needed, as it can be > achieved by using the beaId. Classname and bean name would probably be mostly covering the same space. But imagine a scenario where all transaction sensitive code lives in one package. So your classnames already have a sensible convention that can be exploited for expressing the interceptor, requiring a bean name convention in this case is just overhead. > On the other hand, if you look at our current impl, it is not hard to support > another interceptor either, as we just simply need to add the bean and method > attribute to the custom element. From the user's point of view, the current > schema means less xml writing for the user, i.e > > <tx:transaction method="insert*" bean="*Biz*" value="Required"> Very fair point. Thinking about a general design makes only sense if we expect more interceptors to be used. I personally would argue interceptors are a rather neat way to configure cross-cutting concerns of which there a few (transaction, logging and possibly the security). Having a generic syntax would be nice. There are two main benefits here: - different interceptors support the same configuration syntax - different interceptors can reuse the same implementation for matching Blueprint component to which they should be applied And the disadvantages: - more xml - slightly more overhead for just a single interceptor > And now from me: > I think a change such as Valentin suggested would imply that the logic to > select the appropriate bean/method/class is in the interceptor management > rather than in the specific interceptor itself. That might be a good change - > but it is different than what we currently have in the transactions > interceptor today. The current implementation has the transaction interceptor > always being invoked on every method for every bean upon which it is defined. > The namespace handler determines if the interceptor should be added for a > particular bean. The logic in the transaction interceptor then decides if > the method is within the scope of what was defined as applicable methods. Am > I reading too much into your proposal Valentin? > > It would seem logical to generalize that processing out so that all > interceptors could benefit by common code and logic to determine the > appropriate beans and methods. But Lin has a good point that the current > syntax is much more simple and backward compatible. Lin proposed that we > could pull the logic for parsing and processing the bean/method attributes > into some utilities. I think that might be a good compromise for now. Yeah, there is definitely a trade-off between conciseness and reusability here. With a more generic approach we would be in a better position to compete with the generic capabilities that Spring 2.0, which allows transactions and other crosscutting concerns to be implemented generically via aspect oriented advice. > -- > Joe
