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
