You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Joe Bohn <jo...@gmail.com> on 2010/07/27 21:38:20 UTC
generalizing bean/method processing for interceptors
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.
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">
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.
--
Joe
Re: generalizing bean/method processing for interceptors
Posted by Valentin Mahrwald <vm...@googlemail.com>.
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
Re: generalizing bean/method processing for interceptors
Posted by Joe Bohn <jo...@gmail.com>.
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.
>
>> 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.
>>
>> 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
Re: generalizing bean/method processing for interceptors
Posted by Lin Sun <li...@gmail.com>.
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 <gc...@gmail.com> 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 <gc...@gmail.com> 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 <vm...@googlemail.com> 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
>>>
>>>
>>
>
Re: generalizing bean/method processing for interceptors
Posted by Graham Charters <gc...@gmail.com>.
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 <gc...@gmail.com> 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 <vm...@googlemail.com> 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
>>
>>
>
Re: generalizing bean/method processing for interceptors
Posted by Graham Charters <gc...@gmail.com>.
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 <vm...@googlemail.com> 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
>
>
Re: generalizing bean/method processing for interceptors
Posted by Valentin Mahrwald <vm...@googlemail.com>.
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