Hi Graham Thanks. If we go with what you are proposing, from the user's perspective, they still declare transactions element using method and bean as the attribute, along with transactionAttribute, which is the same as what we have in our svn right now, except the Tinterceptor type can also used by other interceptors.
Lin On Wed, Jul 28, 2010 at 3:46 PM, Graham Charters <[email protected]> wrote: > 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 >>> >>> >> >
