On Thu, 2011-09-29 at 17:41 -0700, Richard wrote:
> 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.
>
> Questions
>
> 1 does cdi 1.0 have it and I just missed it?
> 2 does cdi 1.1 have it and I just missed it?
> 3 does cdi not have it?
>
> If it does not have it, can we table it for discussion.
>
>
>
> Sent from my iPad
>
> On Sep 29, 2011, at 2:54 PM, Marius Bogoevici <
mariusb@redhat.com> wrote:
>
> > Rick,
> >
> > On Thu, 2011-09-29 at 12:53 -0700, Rick Hightower wrote:
> >> My favorite new features is missing from the overview.
> >>
> >>
> >> :(
> >>
> >>
> >> Maybe it got dropped.
> >>
> >>
> >> Can interceptors still implement interfaces?
> >
> > What would be special about implementing interfaces? Any class can be an
> > interceptor as long as it is properly annotated, but then again, the
> > fact that they implement an interface or not shouldn't have any
> > particular meaning.
> >
> >>
> >> On Thu, Sep 29, 2011 at 11:28 AM, Pete Muir <
pmuir@redhat.com> wrote:
> >> Expert group
> >>
> >> Please review this draft:
> >>
> >>
http://docs.jboss.org/cdi/spec/1.1.EDR1/
> >>
http://docs.jboss.org/cdi/api/1.1.EDR1/
> >>
> >> I would like to submit this to the JCP on Tuesday 4th October
> >> as EDR1, but to do that I want your approval :-)
> >>
> >> I am trying to stage the api jar as well as produce javadoc,
> >> but the JBoss nexus isn't cooperating :-(
> >>
> >> JBoss Nexus now syncs the cdi-api to central, so this will
> >> appear there shortly after Paul Gier beats Nexus into
> >> submission with a big enough stick ;-)
> >>
> >> I'll ping the group anyway.
> >>
> >> Pete
> >> _______________________________________________
> >> cdi-dev mailing list
> >>
cdi-dev@lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >>
> >>
> >>
> >> --
> >> Rick Hightower
> >>
(415) 968-9037
> >> Profile
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >>
cdi-dev@lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> >