10:22 p.m.
[
https://issues.jboss.org/browse/CDI-110?page=com.atlassian.jira.plugin.sy...
]
Richard Hightower commented on CDI-110:
---------------------------------------
Forgive the over explanation, just trying to be clear....
An interceptor typically intercepts concrete classes.
Say LibraryServiceImpl needs a LogInterceptor, or a TransactionInterceptor, or whatever.
The interceptor is sort of a dynamic decorator design pattern instead of implementing the
same interface as the service impl, it uses reflection constructs so that it can intercept
any concrete class (ignore CDI decorators for a moment) with the same cross cutting
service I.e, logging, transactions, security, etc.
So later the same two interceptors can implement the BankServiceImpl (class).
Ok at this point hopefully we are on the same page....
What I am asking and hoping is that I can have an interceptor intercept calls to an
interface like LibraryService and use the same constructs to provide an implementation of
an arbitrary interface ( or any abstract class).
Thus there is no final proceed. The interceptor is the implementation. So if I wanted to
provide an interceptor that translated method calls into REST calls then I could have an
interceptor called RESTInterceptor that decorates the LibraryService interface and I can
intercept calls and turn those into rest calls for a remote client automatically where
LibraryService is an interface and nor a class. I could also intercept calls to
LibraryService with JMSInterceptor and implement the methods by sending JMS messages.
In the past I used this technique with Spring interceptors to create methods on the fly
that accessed JPA named queries. You could also do this with mixin support.
The plumbing is there already. The leap from implementing interceptors for concrete
classes to intercepting interfaces so that the interfaces have an implementation is not
that far off in scope or implementation.
AspectJ has it. Spring 1.0 has it. Spring 2 improved it. I think CDI should have it.
I thought I saw someone discussing it for CDI 1.1 at some point and thought it would be in
the summary.
Provide support for binding an invocation handler to an interface or
abstract class
-----------------------------------------------------------------------------------
Key: CDI-110
URL: https://issues.jboss.org/browse/CDI-110
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Inheritance and Specialization
Affects Versions: 1.0
Reporter: George Gastaldi
Assignee: George Gastaldi
Labels: cdi
Fix For: 1.1 (Proposed)
The purpose of this feature is to allow interfaces and abstract classes to be
automatically implemented by an invocation handler to which all abstract method
invocations are delegated. The invocation handler would get "bound" to the type
using the same strategy as is used for interceptor binding.
Binding type:
{code:java}
@Target({ METHOD, TYPE })
@Retention(RetentionPolicy.RUNTIME)
@ServiceHandlerBindingType
public @interface EchoService {}
{code}
Invocation handler:
{code:java}
@ServiceHandler
@EchoService
public class EchoServiceHandler {
@AroundInvoke
public Object invoke(InvocationContext ctx) {
return ctx.getMethod().getName().toString();
}
}
{code}
Usage:
{code:java}
@EchoService
public interface HelloWorld {
String helloWorld();
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira