Javadoc
Definition of a service decorator, which (by default) is derived from a service decorator method.
A note on decorator scheduling. The scheduling is based on the desired order of behavior. Thus, if logging
should occur before security checks, and security checks should occur before transaction management, then the desired
decorator order is Logging, Security, Transactions. This might be specified as having Security occur after Logging,
and Transactions occur after Security. It might also be specified by having Logging ordered "before:*", and
Transactions ordered "after:*" with no specified scheduling for Security.
Once this order is established, decorators are applied in reverse order. Each decorator's job is to create
an interceptor for the service, that delegates to the next implementation. This implies that the decorators
are executed last to first. In the above example, the core service implementation would be passed to the Transaction
decorator, resulting in the Transaction interceptor. The Transaction interceptor would be passed to the Security
decorator, resulting in the Security interceptor. The Security interceptor would be passed to the Logging decorator,
resulting in the Logging interceptor. Thus at runtime, the Logging interceptor will execute first, then delegate to
the Security interceptor, which would delegate to the Transaction interceptor, which would finally delegate to the
core service implementation.
Service decorators are part of the initial version of Tapestry IoC. Starting in release 5.1, their use has been
deprecated, in favor of
org.apache.tapestry5.ioc.AdvisorDef, which is based on
org.apache.tapestry5.ioc.services.AspectInterceptorBuilder.
Note: service decorators are applied around the interceptor generated via any
org.apache.tapestry5.ioc.AdvisorDefs (for compatibility with Tapestry 5.0). In general, you should use service
decoration or service advice, not both.