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
