[cdi-dev] CDI 1.1 EDR 1 draft posted

[Rick Hightower]

So ... this did not make it to the confirmed list...

https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12311062&version=12315956

So what do we need to make it to the confirm list... an implementor. :)

Maybe I can sign up for this... Although I don't know the Weld code base
very well. I am willing to take a shot at it. When is it due?



On Thu, Sep 29, 2011 at 8:22 PM, Rick Hightower
<richardhightower at gmail.com>wrote:

> Looks like I commented on it already.
>
>
> On Thu, Sep 29, 2011 at 8:04 PM, Marius Bogoevici <mariusb at redhat.com>wrote:
>
>> Rich,
>>
>> Oh, so you were rather looking at something similar to Spring method
>> injection?
>>
>> Perhaps I'm reading your email in a hurry, but I think that
>> https://issues.jboss.org/browse/CDI-110 (service handlers) provides
>> support for doing just that.
>>
>> Cheers,
>> Marius
>>
>> 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 at 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 at 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 at lists.jboss.org
>> > >>        https://lists.jboss.org/mailman/listinfo/cdi-dev
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Rick Hightower
>> > >> (415) 968-9037
>> > >> Profile
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> cdi-dev mailing list
>> > >> cdi-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> > >
>> > >
>>
>>
>>
>
>
> --
> *Rick Hightower*
> (415) 968-9037
> Profile <http://www.google.com/profiles/RichardHightower>
>
>


-- 
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20110929/1eae06b1/attachment.html