realityforge
commented
3 years ago After about a years production use it seems these would be extremely valuable in some circumstances and of no value in others. (i.e. There has been limited demand for these in Frontend applications but lots of demand when Sting is used in CLI apps or backend apps). Some server-side scenarios where Sting is not used is only because interceptors are not supported. i.e. If we had interceptors for transactions then we use Sting to replace CDI in several scenarios.
As an implementation strategy we could probably have a generic Interceptor interface(s) (maybe before, after and around callbacks) and the interceptors becomes an. implicit dependency and applies equally to all typed interactions with service.
Interceptors can either be applied statically at build time or dynamically at runtime. It is unclear whether the current set of Sting applications could benefit from this feature or not. To enable interceptors in Sting we would need to add another annotation and possibly a separate package for managing interceptor types. The annotation would either select all public methods or all non-private methods as candidates for interception, allowing the developer to override specific methods to mark them as overridable or as intercepted by different interceptors. The framework would need to make sure all intercepted methods could be overridden.
This feature would expand Stings use case to almost all server-side scenario but it comes at the cost of increased complexity which may not be justified.