CDI 1.1 EDR 1 draft posted

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

CDI 1.1 EDR 1 draft posted

Pete Muir
Administrator
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Rick Hightower
My favorite new features is missing from the overview.

:(

Maybe it got dropped.

Can interceptors still implement interfaces?

On Thu, Sep 29, 2011 at 11:28 AM, Pete Muir <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Pete Muir
Administrator
What's the feature?

I don't understand interceptors?

--
Pete Muir

On 29 Sep 2011, at 20:53, Rick Hightower <[hidden email]> wrote:

My favorite new features is missing from the overview.

:(

Maybe it got dropped.

Can interceptors still implement interfaces?

On Thu, Sep 29, 2011 at 11:28 AM, Pete Muir <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Pete Muir
Administrator
Err, i don't understand the comment about interceptors. They always have been able to implement interfaces...

--
Pete Muir

On 29 Sep 2011, at 22:08, Peter Muir <[hidden email]> wrote:

What's the feature?

I don't understand interceptors?

--
Pete Muir

On 29 Sep 2011, at 20:53, Rick Hightower <[hidden email]> wrote:

My favorite new features is missing from the overview.

:(

Maybe it got dropped.

Can interceptors still implement interfaces?

On Thu, Sep 29, 2011 at 11:28 AM, Pete Muir <[hidden email][hidden email]> 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
[hidden email][hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
Rick Hightower
(415) 968-9037
Profile 

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Marius Bogoevici
In reply to this post by Rick Hightower
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 <[hidden email]> 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
>         [hidden email]
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>
>
> --
> Rick Hightower
> (415) 968-9037
> Profile
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Rick Hightower
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 <[hidden email]> 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 <[hidden email]> 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
>>        [hidden email]
>>        https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>
>>
>>
>> --
>> Rick Hightower
>> (415) 968-9037
>> Profile
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Marius Bogoevici
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 <[hidden email]> 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 <[hidden email]> 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
> >>        [hidden email]
> >>        https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >>
> >>
> >>
> >> --
> >> Rick Hightower
> >> (415) 968-9037
> >> Profile
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> >


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Rick Hightower
That is the one. So it is proposed but not voted in yet? Correct?

On Thu, Sep 29, 2011 at 8:04 PM, Marius Bogoevici <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >>        [hidden email]
> >>        https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >>
> >>
> >>
> >> --
> >> Rick Hightower
> >> <a href="tel:%28415%29%20968-9037" value="+14159689037">(415) 968-9037
> >> Profile
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> >





--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Rick Hightower
In reply to this post by Marius Bogoevici
Looks like I commented on it already.

On Thu, Sep 29, 2011 at 8:04 PM, Marius Bogoevici <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >>        [hidden email]
> >>        https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >>
> >>
> >>
> >> --
> >> Rick Hightower
> >> <a href="tel:%28415%29%20968-9037" value="+14159689037">(415) 968-9037
> >> Profile
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> >





--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

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


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 <[hidden email]> wrote:
Looks like I commented on it already.


On Thu, Sep 29, 2011 at 8:04 PM, Marius Bogoevici <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >>        [hidden email]
> >>        https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >>
> >>
> >>
> >> --
> >> Rick Hightower
> >> <a href="tel:%28415%29%20968-9037" value="+14159689037" target="_blank">(415) 968-9037
> >> Profile
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> >





--
Rick Hightower
<a href="tel:%28415%29%20968-9037" value="+14159689037" target="_blank">(415) 968-9037
Profile 




--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Pete Muir
Administrator
Hi Rick,

This EDR release I've posted is essentially an "Alpha1" of CDI 1.1 - it's not supposed to be feature complete for CDI 1.1. We fully intend to get this feature in by the next EDR :-) The reason for this release is to give people (EG, wider community) a chance to comment on the work so far, and raise points like yours.

The list of changes in the spec includes those that are already done, not those that are still proposed.

When I post this spec and blog about it etc. I will make this clearer :-)

Regarding getting this done, George has made a start, and provided an initial changeset, which I reviewed and am waiting for him to update. https://github.com/jboss/cdi/pull/28 - if you want to help, that would be ideal - but don't forget you signed up for @TransactionScoped as well :-) We're not looking for you to implement this feature in Weld (we will do that). What we want from you is

a) a changeset for the spec itself, and the api (which is where George is at right now)
b) a changeset for the TCK (this can come later) - the TCK is now fully built on arquillian, so that should make life easier.

HTH

Pete

On 30 Sep 2011, at 04:25, Rick Hightower wrote:

> 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 <[hidden email]> wrote:
> Looks like I commented on it already.
>
>
> On Thu, Sep 29, 2011 at 8:04 PM, Marius Bogoevici <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> > >>        [hidden email]
> > >>        https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Rick Hightower
> > >> (415) 968-9037
> > >> Profile
> > >>
> > >>
> > >> _______________________________________________
> > >> cdi-dev mailing list
> > >> [hidden email]
> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > >
>
>
>
>
>
> --
> Rick Hightower
> (415) 968-9037
> Profile
>
>
>
>
> --
> Rick Hightower
> (415) 968-9037
> Profile
>


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Rick Hightower
Ok. I will try to get a draft of Transaction scope by end of month.

On Fri, Sep 30, 2011 at 3:39 AM, Pete Muir <[hidden email]> wrote:
Hi Rick,

This EDR release I've posted is essentially an "Alpha1" of CDI 1.1 - it's not supposed to be feature complete for CDI 1.1. We fully intend to get this feature in by the next EDR :-) The reason for this release is to give people (EG, wider community) a chance to comment on the work so far, and raise points like yours.

The list of changes in the spec includes those that are already done, not those that are still proposed.

When I post this spec and blog about it etc. I will make this clearer :-)

Regarding getting this done, George has made a start, and provided an initial changeset, which I reviewed and am waiting for him to update. https://github.com/jboss/cdi/pull/28 - if you want to help, that would be ideal - but don't forget you signed up for @TransactionScoped as well :-) We're not looking for you to implement this feature in Weld (we will do that). What we want from you is

a) a changeset for the spec itself, and the api (which is where George is at right now)
b) a changeset for the TCK (this can come later) - the TCK is now fully built on arquillian, so that should make life easier.

HTH

Pete

On 30 Sep 2011, at 04:25, Rick Hightower wrote:

> 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 <[hidden email]> wrote:
> Looks like I commented on it already.
>
>
> On Thu, Sep 29, 2011 at 8:04 PM, Marius Bogoevici <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> > >>        [hidden email]
> > >>        https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Rick Hightower
> > >> <a href="tel:%28415%29%20968-9037" value="+14159689037">(415) 968-9037
> > >> Profile
> > >>
> > >>
> > >> _______________________________________________
> > >> cdi-dev mailing list
> > >> [hidden email]
> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > >
>
>
>
>
>
> --
> Rick Hightower
> <a href="tel:%28415%29%20968-9037" value="+14159689037">(415) 968-9037
> Profile
>
>
>
>
> --
> Rick Hightower
> <a href="tel:%28415%29%20968-9037" value="+14159689037">(415) 968-9037
> Profile
>




--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Pete Muir
Administrator
In reply to this post by Pete Muir
Here is the API jar in the staging repo. Once we agree on this draft, it will be promoted to central.

On 29 Sep 2011, at 19:28, Pete Muir 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Pete Muir
Administrator
https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-160/

On 30 Sep 2011, at 20:22, Pete Muir wrote:

> Here is the API jar in the staging repo. Once we agree on this draft, it will be promoted to central.
>
> On 29 Sep 2011, at 19:28, Pete Muir 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Rick Hightower
In reply to this post by Pete Muir
I missed the vote... but a symbolic +1


On Fri, Sep 30, 2011 at 12:22 PM, Pete Muir <[hidden email]> wrote:
Here is the API jar in the staging repo. Once we agree on this draft, it will be promoted to central.

On 29 Sep 2011, at 19:28, Pete Muir 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Pete Muir
Administrator
I tend to operate by a policy of silent agreement and assume that if you don't say anything you are happy :-)

But the deadline for feedback is Monday so still time for comments!

--
Pete Muir

On 30 Sep 2011, at 21:51, Rick Hightower <[hidden email]> wrote:

I missed the vote... but a symbolic +1


On Fri, Sep 30, 2011 at 12:22 PM, Pete Muir <[hidden email]> wrote:
Here is the API jar in the staging repo. Once we agree on this draft, it will be promoted to central.

On 29 Sep 2011, at 19:28, Pete Muir 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR 1 draft posted

Mark Struberg
So far it looks fine, but still need some time to re-read all parts.

Hope I can do it till monday.

LieGrue,
strub




>________________________________
>From: Peter Muir <[hidden email]>
>To: Rick Hightower <[hidden email]>
>Cc: "[hidden email]" <[hidden email]>
>Sent: Friday, September 30, 2011 11:37 PM
>Subject: Re: [cdi-dev] CDI 1.1 EDR 1 draft posted
>
>
>I tend to operate by a policy of silent agreement and assume that if you don't say anything you are happy :-)
>
>
>But the deadline for feedback is Monday so still time for comments!
>
>--
>Pete Muir
>http://in.relation.to/Bloggers/Pete
>
>On 30 Sep 2011, at 21:51, Rick Hightower <[hidden email]> wrote:
>
>
>I missed the vote... but a symbolic +1
>>
>>
>>
>>On Fri, Sep 30, 2011 at 12:22 PM, Pete Muir <[hidden email]> wrote:
>>
>>Here is the API jar in the staging repo. Once we agree on this draft, it will be promoted to central.
>>>
>>>
>>>On 29 Sep 2011, at 19:28, Pete Muir 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>
>>>_______________________________________________
>>>cdi-dev mailing list
>>>[hidden email]
>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>
>>
>>
>>--
>>Rick Hightower
>>(415) 968-9037
>>Profile 
>>
>>
>_______________________________________________
>cdi-dev mailing list
>[hidden email]
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev