Implement MessagePublishingInterceptor [INT-28]

[spring-operator]

Mark Fisher opened INT-28 and commented

This issue was deferred from the 1.0.x roadmap, because the use of EL will provide a much better experience for mapping arguments, return values, and exceptions to the Message to be published. I am re-opening and assigning to 2.0-M1 now that we depend on Spring 3.0 and have the EL support.

This was the original description back in the early milestones (things will be a bit different now because of EL - see the version in the sandbox for a rough idea):
"The MessagePublishingInterceptor will serve as an AOP-driven messaging gateway - providing a setter for the output channel. It should also allow for configuration of the type of interception (before or after) as well as an optional Message-preparing/payload-extracting strategy. For 'before' interception (e.g. auditing), the MethodInvocation itself would be passed as Message payload, unless a payload extractor is provided. For 'after' interception, the default behavior (when no payload extractor is provided) will depend on the message outcome: if the method returns successfully, the return value will be passed as the Message payload, but if the method throws an exception, the exception will be the payload (of an ErrorMessage). The sending of ErrorMessages should probably be configurable - minimally with a simple enable/disable boolean flag. The default interception type should most likely be 'after'."

---

Sub-tasks:

• Add @Publisher annotation [INT-792] #4799 Add @Publisher annotation

• Add support for non-annotation based binding of an EL expression to Message payload and headers [INT-809] #4815 Add support for non-annotation based binding of an EL expression to Message payload and headers

• Add documentation for AOP-based Message publishing interceptor [INT-814] #4820 Add documentation for AOP-based Message publishing interceptor

• Create interceptor and AOP advisor for @Publisher annotation [INT-817] #4823 Create interceptor and AOP advisor for @Publisher annotation

[spring-operator]

Mark Fisher commented

Implemented with only "after-returning" advice behavior for now.

[spring-operator]

Mark Fisher commented

For 0.5, this is used for after advice only. Will add a new issue for extending the functionality in the 1.0 timeframe.

[spring-operator]

Mark Fisher commented

Moving this parent issue to 2.0-M2 since the non-annotation approach will be supported in M2. The core functionality (interceptor, annotation, and advisor) are already available in M1 however.