Here's what I was thinking, schema wise.... Abstract type for others to extend, which could have generic processing associated with it.
<xsd:schema xmlns="http://aries.apache.org/xmlns/interceptor/v1.0.0"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; targetNamespace="http://aries.apache.org/xmlns/interceptor/v1.0.0"; elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0.0"> <xsd:complexType name="Tinterceptor" abstract="true"> <xsd:attribute name="method" type="xsd:string" /> <xsd:attribute name="bean" type="xsd:string" /> </xsd:complexType> </xsd:schema> Different concrete handlers extend the above type. <xsd:schema xmlns="http://aries.apache.org/xmlns/transactions/v1.0.0"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; targetNamespace="http://aries.apache.org/xmlns/transactions/v1.0.0"; xmlns:int="http://aries.apache.org/xmlns/interceptor/v1.0.0"; elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0.0"> <xsd:import namespace="http://aries.apache.org/xmlns/interceptor/v1.0.0"; schemaLocation="blueprint-interceptor.xsd" /> ... <xsd:complexType name="Ttransaction"> <xsd:complexContent> <xsd:extension base="int:Tinterceptor"> <xsd:attribute name="value" type="TtransactionAttribute" use="required" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="transaction" type="Ttransaction"> </xsd:schema> On 28 July 2010 18:14, Graham Charters <[email protected]> wrote: > I really don't like the more verbose syntax and think if we went that > route we would be compromising the many for the needs of the few. If > we really think that the selection of bean/methods is going to be > common across a number of namespace extensions, is there any reason > why we can't define an abstract base XML type that defines the > selection attributes and then extend that to create the types for > <tx:transaction ../> and so on. This would give us the compact syntax > whilst allowing us to define common semantics and the processing could > also be common. > > Regards, Graham. > > On 28 July 2010 15:43, Valentin Mahrwald <[email protected]> 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. >> >>> 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 >> >> >
