aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject generalizing bean/method processing for interceptors
Date Tue, 27 Jul 2010 19:38:20 GMT
Under 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:include beanname="*Biz*" />
      <ic:include classname="*.biz.*" />

(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:include method="insert*" />
      <ic:include beanId="*Biz*" />
      <ic:include classname="*.biz.*" />

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.


View raw message