On 29 Jul 2010, at 21:40, Joe Bohn wrote: > On 7/28/10 10:43 AM, Valentin Mahrwald wrote: >> 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. > > I can see how classname might be useful for Transactions and other > interceptors. > >> >>> 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 > > I think Graham's proposal mitigates the first disadvantage because the > transaction schema can import the common bean/method elements and expose them > tx elements - providing both backward compatibility and a simplified xml for > the user. However, it is still more work. Using Graham's approach I think > we could refactor this and implement the split later when it is actually > necessary for more than one interceptor.
Yeah, I like Graham's proposal. Especially, if we can end up with a sufficiently general base class (for the namespace handler) that other interceptors could base their implementation on. (This could be extracted at a later stage I think) >> >>> 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? > > This previous question is where I was really interested in your perspective. > Were you suggesting moving the decision on associating a particular > interceptor with a bean from the current location (in the transaction > namespace handler) to a more generalized portion of interceptor logic that > could be utilized by all interceptors? Likewise, were you suggesting moving > the method level logic (ie. if the particular method is included) from within > the transaction interceptor (again the current implementation) to more > generalized interceptor processing such that a particular interceptor would > not be invoked at all if the method being invoked didn't match the criteria > specified in the blueprint xml? I think all of this makes sense but it might > be more valuable to implement once we actually have a case of multiple > interceptors that can share this capability. My drift was to separate the two concerns of the current transaction interceptor: what to do and where to do it (which beans, which methods ...). The concern of what to do is specific to each individual interceptor whereas where to apply the interceptor is pretty much the same concern for each interceptor. Ideally, then the logic would be implemented once and for all. Now, after mulling on Graham's comments I admit that this clear separation actually entails a significant loss of usability (especially in the particular xml I started with) and hence this might be just a futures. With Graham's proposed schema and a reusable base Namespace handler for interceptors, the separation is still achieved (although not as crystal-clear) and this seems like a much better compromise. >>> >>> 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 >> >> > > > -- > Joe Valentin
