7:57 a.m.
Hi all,
Just to give you a small feedback of my Devoxx week regarding CDI and CDI 2.0 (for the
rest, what happens in Devoxx stays in Devoxx ;) )
1) Great expectations:
I’m not going to state the obvious, but end user and other specs are watching us and
expect a lot from CDI 2.0 (the question of total EJB replacement came more than once)
2) Antonin Stefanutti and myself delivered a very valuable content in our CDI advanced
university. I don’t remember being so proud of a talk material I released before. I
encourage you to give it an eye and use it if you want. you can watch it on Slideshare [1]
or grab the source slides on Antonin’s Github repo [2]
3) Other spec are really willing to have a better integration.
I met JMS, Servlet, JSF and MVC spec leaders, they all are looking for a better
integration with CDI and are ok to take CDI specific part related to their spec back in
their spec (Servlet and JSF mostly). Working with them will bring a more consistent Java
EE and will reduce extra code from the spec.
4) After months of discussion I finally met Jurgen Hoeller (Spring Framework) and
Christian Gruber (Dagger and Guice) and we all agreed on a new version or MR of AtInject
spec. Juergen will probably be the spec lead and we hope to have the big work done before
mid 2015 (cross finger) to met our various agenda. That will probably add extra work for
CDI 2.0 but will bring clarity and a good signal to the community. Thanks to Antonio who
helped me on this.
For those who remember the history of JSR 330 and JSR 299 the following picture will be
nearly an historical one ;) [3]
Antoine
[1] http://www.slideshare.net/antoinesd/going-further-with-cdi-41411812
[2] https://github.com/astefanutti/further-cdi
[3] http://twitter.com/antoine_sd/status/533710069255667712/photo/1
9:28 a.m.
Hi,
On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
<antoine(a)sabot-durand.net> wrote:
Just to give you a small feedback of my Devoxx week regarding CDI and
CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
1) Great expectations:
[...] (the question of total EJB replacement came more than once)
I heard this a number of times as well, both before and during Devoxx.
A great number of issues for decoupling EJB features (meaning,
providing CDI based replacements) have already been created as spec
issues:
* Decoupling the @Schedule annotation from the EJB component model (EJB_SPEC-1)
* Decoupling the TimerService API from the EJB component model (EJB_SPEC-2)
* Decoupling the @Asynchronous annotation from the EJB component model
(EJB_SPEC-3)
* Decoupling the @Lock/@AccessTimeout annotations from the EJB
component model (EJB_SPEC-4)
* Decoupling the @Startup/@DependsOn annotations from the EJB
component model (EJB_SPEC-19)
* Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113)
* Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
* Standardize Abstractions for Common Message Processing Patterns (JMS_SPEC-154)
* Allow Java EE components other than MDBs to consume messages
asynchronously (JMS_SPEC-100)
* Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
* Support for "self" injection (CDI-414)
* Allow access-control related JSR-250 security annotations on managed
beans (JAVASERVERFACES_SPEC_PUBLIC-495)
* Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
There are some additional features that may not yet have been covered
(but maybe I missed them), such as:
* Control over passivation
* Support for the extended persistence context
* Destroying a bean whenever an exception occurs (I was just working
on this the other week)
* Logging the exception thrown by a bean (yes, trivial, but part of EJB)
* The concept where every method call on a proxy is routed to another
bean instance, which is then automatically unavailable for other calls
as long as it doesn't return (related to the "Standardize Pooling"
issue)
* Binary remoting without all the explicit mapping that's needed for
say JAX-RS (yes, thorny issue which we may not wish to support
anymore?)
* General support for @RolesAllowed/@RunAs etc (often mentioned, and
two issues for JSF managed beans resp Servlets were created, but no
general issue)
The question is perhaps where all this functionality should live.
TimerService and @Asynchronous in the concurrency spec?
All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?
@RolesAllowed etc in the security spec (if that spec will actually happen)
@Startup in the CDI spec itself?
Destroying bean on exception in CDI spec?
But where should e.g. pooling belong?
Kind regards,
Arjan Tijms
9:53 a.m.
@Startup could also make sense in Concurrency in Java EE, like @Pooling
(there's thread pools behind). BTW I was talking to the Oracle guys and it
looks like the Concurrency spec will be updated in EE 8... I don't know how
far the update will go.
As for the JMS stuff, we talked with Nigel and he likes the idea of MDB
replacement going to where it belongs : the JMS spec
Antonio
On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms(a)gmail.com> wrote:
Hi,
On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
<antoine(a)sabot-durand.net> wrote:
> Just to give you a small feedback of my Devoxx week regarding CDI and
CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
>
> 1) Great expectations:
> [...] (the question of total EJB replacement came more than once)
I heard this a number of times as well, both before and during Devoxx.
A great number of issues for decoupling EJB features (meaning,
providing CDI based replacements) have already been created as spec
issues:
* Decoupling the @Schedule annotation from the EJB component model
(EJB_SPEC-1)
* Decoupling the TimerService API from the EJB component model (EJB_SPEC-2)
* Decoupling the @Asynchronous annotation from the EJB component model
(EJB_SPEC-3)
* Decoupling the @Lock/@AccessTimeout annotations from the EJB
component model (EJB_SPEC-4)
* Decoupling the @Startup/@DependsOn annotations from the EJB
component model (EJB_SPEC-19)
* Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113)
* Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
* Standardize Abstractions for Common Message Processing Patterns
(JMS_SPEC-154)
* Allow Java EE components other than MDBs to consume messages
asynchronously (JMS_SPEC-100)
* Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
* Support for "self" injection (CDI-414)
* Allow access-control related JSR-250 security annotations on managed
beans (JAVASERVERFACES_SPEC_PUBLIC-495)
* Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
There are some additional features that may not yet have been covered
(but maybe I missed them), such as:
* Control over passivation
* Support for the extended persistence context
* Destroying a bean whenever an exception occurs (I was just working
on this the other week)
* Logging the exception thrown by a bean (yes, trivial, but part of EJB)
* The concept where every method call on a proxy is routed to another
bean instance, which is then automatically unavailable for other calls
as long as it doesn't return (related to the "Standardize Pooling"
issue)
* Binary remoting without all the explicit mapping that's needed for
say JAX-RS (yes, thorny issue which we may not wish to support
anymore?)
* General support for @RolesAllowed/@RunAs etc (often mentioned, and
two issues for JSF managed beans resp Servlets were created, but no
general issue)
The question is perhaps where all this functionality should live.
TimerService and @Asynchronous in the concurrency spec?
All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?
@RolesAllowed etc in the security spec (if that spec will actually happen)
@Startup in the CDI spec itself?
Destroying bean on exception in CDI spec?
But where should e.g. pooling belong?
Kind regards,
Arjan Tijms
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>
|
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
9:55 a.m.
2014-11-17 16:53 GMT+01:00 Antonio Goncalves <antonio.goncalves(a)gmail.com>:
@Startup could also make sense in Concurrency in Java EE, like
@Pooling
(there's thread pools behind). BTW I was talking to the Oracle guys and it
looks like the Concurrency spec will be updated in EE 8... I don't know how
far the update will go.
As for the JMS stuff, we talked with Nigel and he likes the idea of MDB
replacement going to where it belongs : the JMS spec
MDBs are not all JMS so IMO MDBs don't belong to JMS at all. Would be
a big regression to do it. In particular when EE 8/9 will bring nicer
connectors
Antonio
On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms(a)gmail.com> wrote:
>
> Hi,
>
> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
> <antoine(a)sabot-durand.net> wrote:
> > Just to give you a small feedback of my Devoxx week regarding CDI and
> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
> >
> > 1) Great expectations:
> > [...] (the question of total EJB replacement came more than once)
>
> I heard this a number of times as well, both before and during Devoxx.
>
> A great number of issues for decoupling EJB features (meaning,
> providing CDI based replacements) have already been created as spec
> issues:
>
> * Decoupling the @Schedule annotation from the EJB component model
> (EJB_SPEC-1)
> * Decoupling the TimerService API from the EJB component model
> (EJB_SPEC-2)
> * Decoupling the @Asynchronous annotation from the EJB component model
> (EJB_SPEC-3)
> * Decoupling the @Lock/@AccessTimeout annotations from the EJB
> component model (EJB_SPEC-4)
> * Decoupling the @Startup/@DependsOn annotations from the EJB
> component model (EJB_SPEC-19)
> * Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113)
> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
> * Standardize Abstractions for Common Message Processing Patterns
> (JMS_SPEC-154)
> * Allow Java EE components other than MDBs to consume messages
> asynchronously (JMS_SPEC-100)
> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
> * Support for "self" injection (CDI-414)
> * Allow access-control related JSR-250 security annotations on managed
> beans (JAVASERVERFACES_SPEC_PUBLIC-495)
> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
>
>
> There are some additional features that may not yet have been covered
> (but maybe I missed them), such as:
>
> * Control over passivation
> * Support for the extended persistence context
> * Destroying a bean whenever an exception occurs (I was just working
> on this the other week)
> * Logging the exception thrown by a bean (yes, trivial, but part of EJB)
> * The concept where every method call on a proxy is routed to another
> bean instance, which is then automatically unavailable for other calls
> as long as it doesn't return (related to the "Standardize Pooling"
> issue)
> * Binary remoting without all the explicit mapping that's needed for
> say JAX-RS (yes, thorny issue which we may not wish to support
> anymore?)
> * General support for @RolesAllowed/@RunAs etc (often mentioned, and
> two issues for JSF managed beans resp Servlets were created, but no
> general issue)
>
> The question is perhaps where all this functionality should live.
>
> TimerService and @Asynchronous in the concurrency spec?
> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?
> @RolesAllowed etc in the security spec (if that spec will actually happen)
> @Startup in the CDI spec itself?
> Destroying bean on exception in CDI spec?
>
> But where should e.g. pooling belong?
>
> Kind regards,
> Arjan Tijms
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code
under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
9:58 a.m.
It won't be called "MDBs", just "Managed Listeners". The JMS spec
will
still have listeners and now it will get managed listeners.
Antonio
On Mon, Nov 17, 2014 at 4:55 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com>
wrote:
2014-11-17 16:53 GMT+01:00 Antonio Goncalves
<antonio.goncalves(a)gmail.com
>:
> @Startup could also make sense in Concurrency in Java EE, like @Pooling
> (there's thread pools behind). BTW I was talking to the Oracle guys and
it
> looks like the Concurrency spec will be updated in EE 8... I don't know
how
> far the update will go.
>
> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB
> replacement going to where it belongs : the JMS spec
>
MDBs are not all JMS so IMO MDBs don't belong to JMS at all. Would be
a big regression to do it. In particular when EE 8/9 will bring nicer
connectors
> Antonio
>
> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms(a)gmail.com>
wrote:
>>
>> Hi,
>>
>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
>> <antoine(a)sabot-durand.net> wrote:
>> > Just to give you a small feedback of my Devoxx week regarding CDI and
>> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
>> >
>> > 1) Great expectations:
>> > [...] (the question of total EJB replacement came more than once)
>>
>> I heard this a number of times as well, both before and during Devoxx.
>>
>> A great number of issues for decoupling EJB features (meaning,
>> providing CDI based replacements) have already been created as spec
>> issues:
>>
>> * Decoupling the @Schedule annotation from the EJB component model
>> (EJB_SPEC-1)
>> * Decoupling the TimerService API from the EJB component model
>> (EJB_SPEC-2)
>> * Decoupling the @Asynchronous annotation from the EJB component model
>> (EJB_SPEC-3)
>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB
>> component model (EJB_SPEC-4)
>> * Decoupling the @Startup/@DependsOn annotations from the EJB
>> component model (EJB_SPEC-19)
>> * Standardize Pooling and Decouple from EJB Component Model
(EJB_SPEC-113)
>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
>> * Standardize Abstractions for Common Message Processing Patterns
>> (JMS_SPEC-154)
>> * Allow Java EE components other than MDBs to consume messages
>> asynchronously (JMS_SPEC-100)
>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
>> * Support for "self" injection (CDI-414)
>> * Allow access-control related JSR-250 security annotations on managed
>> beans (JAVASERVERFACES_SPEC_PUBLIC-495)
>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
>>
>>
>> There are some additional features that may not yet have been covered
>> (but maybe I missed them), such as:
>>
>> * Control over passivation
>> * Support for the extended persistence context
>> * Destroying a bean whenever an exception occurs (I was just working
>> on this the other week)
>> * Logging the exception thrown by a bean (yes, trivial, but part of EJB)
>> * The concept where every method call on a proxy is routed to another
>> bean instance, which is then automatically unavailable for other calls
>> as long as it doesn't return (related to the "Standardize
Pooling"
>> issue)
>> * Binary remoting without all the explicit mapping that's needed for
>> say JAX-RS (yes, thorny issue which we may not wish to support
>> anymore?)
>> * General support for @RolesAllowed/@RunAs etc (often mentioned, and
>> two issues for JSF managed beans resp Servlets were created, but no
>> general issue)
>>
>> The question is perhaps where all this functionality should live.
>>
>> TimerService and @Asynchronous in the concurrency spec?
>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?
>> @RolesAllowed etc in the security spec (if that spec will actually
happen)
>> @Startup in the CDI spec itself?
>> Destroying bean on exception in CDI spec?
>>
>> But where should e.g. pooling belong?
>>
>> Kind regards,
>> Arjan Tijms
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
intellectual
>> property rights inherent in such information.
>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
intellectual
> property rights inherent in such information.
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>
|
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
10:04 a.m.
2014-11-17 16:58 GMT+01:00 Antonio Goncalves <antonio.goncalves(a)gmail.com>:
It won't be called "MDBs", just "Managed
Listeners". The JMS spec will still
have listeners and now it will get managed listeners.
Ok get it, what I meant was mainly that connectors should integrate
with CDI rather than doing anything specific for MDBs, no?
Antonio
On Mon, Nov 17, 2014 at 4:55 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com>
wrote:
>
> 2014-11-17 16:53 GMT+01:00 Antonio Goncalves
> <antonio.goncalves(a)gmail.com>:
> > @Startup could also make sense in Concurrency in Java EE, like @Pooling
> > (there's thread pools behind). BTW I was talking to the Oracle guys and
> > it
> > looks like the Concurrency spec will be updated in EE 8... I don't know
> > how
> > far the update will go.
> >
> > As for the JMS stuff, we talked with Nigel and he likes the idea of MDB
> > replacement going to where it belongs : the JMS spec
> >
>
> MDBs are not all JMS so IMO MDBs don't belong to JMS at all. Would be
> a big regression to do it. In particular when EE 8/9 will bring nicer
> connectors
>
> > Antonio
> >
> > On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms(a)gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
> >> <antoine(a)sabot-durand.net> wrote:
> >> > Just to give you a small feedback of my Devoxx week regarding CDI and
> >> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
> >> >
> >> > 1) Great expectations:
> >> > [...] (the question of total EJB replacement came more than once)
> >>
> >> I heard this a number of times as well, both before and during Devoxx.
> >>
> >> A great number of issues for decoupling EJB features (meaning,
> >> providing CDI based replacements) have already been created as spec
> >> issues:
> >>
> >> * Decoupling the @Schedule annotation from the EJB component model
> >> (EJB_SPEC-1)
> >> * Decoupling the TimerService API from the EJB component model
> >> (EJB_SPEC-2)
> >> * Decoupling the @Asynchronous annotation from the EJB component model
> >> (EJB_SPEC-3)
> >> * Decoupling the @Lock/@AccessTimeout annotations from the EJB
> >> component model (EJB_SPEC-4)
> >> * Decoupling the @Startup/@DependsOn annotations from the EJB
> >> component model (EJB_SPEC-19)
> >> * Standardize Pooling and Decouple from EJB Component Model
> >> (EJB_SPEC-113)
> >> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
> >> * Standardize Abstractions for Common Message Processing Patterns
> >> (JMS_SPEC-154)
> >> * Allow Java EE components other than MDBs to consume messages
> >> asynchronously (JMS_SPEC-100)
> >> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
> >> * Support for "self" injection (CDI-414)
> >> * Allow access-control related JSR-250 security annotations on managed
> >> beans (JAVASERVERFACES_SPEC_PUBLIC-495)
> >> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
> >>
> >>
> >> There are some additional features that may not yet have been covered
> >> (but maybe I missed them), such as:
> >>
> >> * Control over passivation
> >> * Support for the extended persistence context
> >> * Destroying a bean whenever an exception occurs (I was just working
> >> on this the other week)
> >> * Logging the exception thrown by a bean (yes, trivial, but part of
> >> EJB)
> >> * The concept where every method call on a proxy is routed to another
> >> bean instance, which is then automatically unavailable for other calls
> >> as long as it doesn't return (related to the "Standardize
Pooling"
> >> issue)
> >> * Binary remoting without all the explicit mapping that's needed for
> >> say JAX-RS (yes, thorny issue which we may not wish to support
> >> anymore?)
> >> * General support for @RolesAllowed/@RunAs etc (often mentioned, and
> >> two issues for JSF managed beans resp Servlets were created, but no
> >> general issue)
> >>
> >> The question is perhaps where all this functionality should live.
> >>
> >> TimerService and @Asynchronous in the concurrency spec?
> >> All JMS/messaging listener stuff (aka MDB replacements) in the JMS
> >> spec?
> >> @RolesAllowed etc in the security spec (if that spec will actually
> >> happen)
> >> @Startup in the CDI spec itself?
> >> Destroying bean on exception in CDI spec?
> >>
> >> But where should e.g. pooling belong?
> >>
> >> Kind regards,
> >> Arjan Tijms
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code under the Apache License, Version 2
> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >> provided on this list, the provider waives all patent and other
> >> intellectual
> >> property rights inherent in such information.
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> > code
> > under the Apache License, Version 2
> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual
> > property rights inherent in such information.
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
10:30 a.m.
Guys, don’t forget the commons annotation specification since we’re going to ask for a MR
for it. It could be a convenient solution to share annotation without having a huge
dependency to have it (think of SE).
Antoine
Le 17 nov. 2014 à 16:53, Antonio Goncalves
<antonio.goncalves(a)gmail.com> a écrit :
@Startup could also make sense in Concurrency in Java EE, like @Pooling (there's
thread pools behind). BTW I was talking to the Oracle guys and it looks like the
Concurrency spec will be updated in EE 8... I don't know how far the update will go.
As for the JMS stuff, we talked with Nigel and he likes the idea of MDB replacement going
to where it belongs : the JMS spec
Antonio
On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms(a)gmail.com
<mailto:arjan.tijms@gmail.com>> wrote:
Hi,
On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
<antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote:
> Just to give you a small feedback of my Devoxx week regarding CDI and CDI 2.0 (for
the rest, what happens in Devoxx stays in Devoxx ;) )
>
> 1) Great expectations:
> [...] (the question of total EJB replacement came more than once)
I heard this a number of times as well, both before and during Devoxx.
A great number of issues for decoupling EJB features (meaning,
providing CDI based replacements) have already been created as spec
issues:
* Decoupling the @Schedule annotation from the EJB component model (EJB_SPEC-1)
* Decoupling the TimerService API from the EJB component model (EJB_SPEC-2)
* Decoupling the @Asynchronous annotation from the EJB component model
(EJB_SPEC-3)
* Decoupling the @Lock/@AccessTimeout annotations from the EJB
component model (EJB_SPEC-4)
* Decoupling the @Startup/@DependsOn annotations from the EJB
component model (EJB_SPEC-19)
* Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113)
* Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
* Standardize Abstractions for Common Message Processing Patterns (JMS_SPEC-154)
* Allow Java EE components other than MDBs to consume messages
asynchronously (JMS_SPEC-100)
* Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
* Support for "self" injection (CDI-414)
* Allow access-control related JSR-250 security annotations on managed
beans (JAVASERVERFACES_SPEC_PUBLIC-495)
* Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
There are some additional features that may not yet have been covered
(but maybe I missed them), such as:
* Control over passivation
* Support for the extended persistence context
* Destroying a bean whenever an exception occurs (I was just working
on this the other week)
* Logging the exception thrown by a bean (yes, trivial, but part of EJB)
* The concept where every method call on a proxy is routed to another
bean instance, which is then automatically unavailable for other calls
as long as it doesn't return (related to the "Standardize Pooling"
issue)
* Binary remoting without all the explicit mapping that's needed for
say JAX-RS (yes, thorny issue which we may not wish to support
anymore?)
* General support for @RolesAllowed/@RunAs etc (often mentioned, and
two issues for JSF managed beans resp Servlets were created, but no
general issue)
The question is perhaps where all this functionality should live.
TimerService and @Asynchronous in the concurrency spec?
All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?
@RolesAllowed etc in the security spec (if that spec will actually happen)
@Startup in the CDI spec itself?
Destroying bean on exception in CDI spec?
But where should e.g. pooling belong?
Kind regards,
Arjan Tijms
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/cdi-dev
<https://lists.jboss.org/mailman/listinfo/cdi-dev>
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html
<http://www.apache.org/licenses/LICENSE-2.0.html>). For all other ideas provided on
this list, the provider waives all patent and other intellectual property rights inherent
in such information.
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org/> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
Paris JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
2:53 p.m.
Would you like to see @Inject in JSR 250 ? I don't think it's a good idea
to put everything in Commons Annotations. It makes sense to have @Startup,
@Pooling, @Scedule, @Asynchronous where it fits better.
Antonio
On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand <
antoine(a)sabot-durand.net> wrote:
Guys, don’t forget the commons annotation specification since we’re
going
to ask for a MR for it. It could be a convenient solution to share
annotation without having a huge dependency to have it (think of SE).
Antoine
Le 17 nov. 2014 à 16:53, Antonio Goncalves <antonio.goncalves(a)gmail.com>
a écrit :
@Startup could also make sense in Concurrency in Java EE, like @Pooling
(there's thread pools behind). BTW I was talking to the Oracle guys and
it looks like the Concurrency spec will be updated in EE 8... I don't know
how far the update will go.
As for the JMS stuff, we talked with Nigel and he likes the idea of MDB
replacement going to where it belongs : the JMS spec
Antonio
On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms(a)gmail.com>
wrote:
> Hi,
>
> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
> <antoine(a)sabot-durand.net> wrote:
> > Just to give you a small feedback of my Devoxx week regarding CDI and
> CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
> >
> > 1) Great expectations:
> > [...] (the question of total EJB replacement came more than once)
>
> I heard this a number of times as well, both before and during Devoxx.
>
> A great number of issues for decoupling EJB features (meaning,
> providing CDI based replacements) have already been created as spec
> issues:
>
> * Decoupling the @Schedule annotation from the EJB component model
> (EJB_SPEC-1)
> * Decoupling the TimerService API from the EJB component model
> (EJB_SPEC-2)
> * Decoupling the @Asynchronous annotation from the EJB component model
> (EJB_SPEC-3)
> * Decoupling the @Lock/@AccessTimeout annotations from the EJB
> component model (EJB_SPEC-4)
> * Decoupling the @Startup/@DependsOn annotations from the EJB
> component model (EJB_SPEC-19)
> * Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113)
> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
> * Standardize Abstractions for Common Message Processing Patterns
> (JMS_SPEC-154)
> * Allow Java EE components other than MDBs to consume messages
> asynchronously (JMS_SPEC-100)
> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
> * Support for "self" injection (CDI-414)
> * Allow access-control related JSR-250 security annotations on managed
> beans (JAVASERVERFACES_SPEC_PUBLIC-495)
> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
>
>
> There are some additional features that may not yet have been covered
> (but maybe I missed them), such as:
>
> * Control over passivation
> * Support for the extended persistence context
> * Destroying a bean whenever an exception occurs (I was just working
> on this the other week)
> * Logging the exception thrown by a bean (yes, trivial, but part of EJB)
> * The concept where every method call on a proxy is routed to another
> bean instance, which is then automatically unavailable for other calls
> as long as it doesn't return (related to the "Standardize Pooling"
> issue)
> * Binary remoting without all the explicit mapping that's needed for
> say JAX-RS (yes, thorny issue which we may not wish to support
> anymore?)
> * General support for @RolesAllowed/@RunAs etc (often mentioned, and
> two issues for JSF managed beans resp Servlets were created, but no
> general issue)
>
> The question is perhaps where all this functionality should live.
>
> TimerService and @Asynchronous in the concurrency spec?
> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?
> @RolesAllowed etc in the security spec (if that spec will actually happen)
> @Startup in the CDI spec itself?
> Destroying bean on exception in CDI spec?
>
> But where should e.g. pooling belong?
>
> Kind regards,
> Arjan Tijms
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org/> | Twitter
<http://twitter.com/agoncal> | LinkedIn
<http://www.linkedin.com/in/agoncal> | Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>
|
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
2:55 p.m.
2014-11-17 21:53 GMT+01:00 Antonio Goncalves <antonio.goncalves(a)gmail.com>:
Would you like to see @Inject in JSR 250 ? I don't think it's
a good idea to
put everything in Commons Annotations. It makes sense to have @Startup,
@Pooling, @Scedule, @Asynchronous where it fits better.
Why not keeping in EJBs (even if it needs to be renamed for historical
reasons)? ie a spec on top of CDI, not <= CDI.
Antonio
On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand
<antoine(a)sabot-durand.net> wrote:
>
> Guys, don’t forget the commons annotation specification since we’re going
> to ask for a MR for it. It could be a convenient solution to share
> annotation without having a huge dependency to have it (think of SE).
>
> Antoine
>
>
> Le 17 nov. 2014 à 16:53, Antonio Goncalves <antonio.goncalves(a)gmail.com> a
> écrit :
>
> @Startup could also make sense in Concurrency in Java EE, like @Pooling
> (there's thread pools behind). BTW I was talking to the Oracle guys and it
> looks like the Concurrency spec will be updated in EE 8... I don't know how
> far the update will go.
>
> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB
> replacement going to where it belongs : the JMS spec
>
> Antonio
>
> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms(a)gmail.com>
> wrote:
>>
>> Hi,
>>
>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
>> <antoine(a)sabot-durand.net> wrote:
>> > Just to give you a small feedback of my Devoxx week regarding CDI and
>> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
>> >
>> > 1) Great expectations:
>> > [...] (the question of total EJB replacement came more than once)
>>
>> I heard this a number of times as well, both before and during Devoxx.
>>
>> A great number of issues for decoupling EJB features (meaning,
>> providing CDI based replacements) have already been created as spec
>> issues:
>>
>> * Decoupling the @Schedule annotation from the EJB component model
>> (EJB_SPEC-1)
>> * Decoupling the TimerService API from the EJB component model
>> (EJB_SPEC-2)
>> * Decoupling the @Asynchronous annotation from the EJB component model
>> (EJB_SPEC-3)
>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB
>> component model (EJB_SPEC-4)
>> * Decoupling the @Startup/@DependsOn annotations from the EJB
>> component model (EJB_SPEC-19)
>> * Standardize Pooling and Decouple from EJB Component Model
>> (EJB_SPEC-113)
>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
>> * Standardize Abstractions for Common Message Processing Patterns
>> (JMS_SPEC-154)
>> * Allow Java EE components other than MDBs to consume messages
>> asynchronously (JMS_SPEC-100)
>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
>> * Support for "self" injection (CDI-414)
>> * Allow access-control related JSR-250 security annotations on managed
>> beans (JAVASERVERFACES_SPEC_PUBLIC-495)
>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
>>
>>
>> There are some additional features that may not yet have been covered
>> (but maybe I missed them), such as:
>>
>> * Control over passivation
>> * Support for the extended persistence context
>> * Destroying a bean whenever an exception occurs (I was just working
>> on this the other week)
>> * Logging the exception thrown by a bean (yes, trivial, but part of EJB)
>> * The concept where every method call on a proxy is routed to another
>> bean instance, which is then automatically unavailable for other calls
>> as long as it doesn't return (related to the "Standardize Pooling"
>> issue)
>> * Binary remoting without all the explicit mapping that's needed for
>> say JAX-RS (yes, thorny issue which we may not wish to support
>> anymore?)
>> * General support for @RolesAllowed/@RunAs etc (often mentioned, and
>> two issues for JSF managed beans resp Servlets were created, but no
>> general issue)
>>
>> The question is perhaps where all this functionality should live.
>>
>> TimerService and @Asynchronous in the concurrency spec?
>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?
>> @RolesAllowed etc in the security spec (if that spec will actually
>> happen)
>> @Startup in the CDI spec itself?
>> Destroying bean on exception in CDI spec?
>>
>> But where should e.g. pooling belong?
>>
>> Kind regards,
>> Arjan Tijms
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
>
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code
under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
3:04 p.m.
Like @dblevins once said "EJB was a super hype spec with all the cool
features... and became blotted throughout the years". If we are not
careful, CDI (the super hype spec at the moment) will become blotted too.
Context and Dependency Injection should not deal with pooling, scheduling,
security.... but yes, allow the other specs to implement such concerns. I
can easily see most of these concerns implemented with interceptor bindings
or extensions.
When we talked to Nigel (JMS spec lead) he was really enthousiast to learn
more about CDI and use it to help develop JMS internals. Manfred (JSF /
MVC) who has already implemented most of the JSF stuff with CDI
(@ViewScoped and so on) was really encouraging.
I think that part of the job this CDI 2.0 expert group has is to evangelize
current specs leads to use CDI in their internals.
Antonio
On Mon, Nov 17, 2014 at 9:55 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com>
wrote:
2014-11-17 21:53 GMT+01:00 Antonio Goncalves
<antonio.goncalves(a)gmail.com
>:
> Would you like to see @Inject in JSR 250 ? I don't think it's a good
idea to
> put everything in Commons Annotations. It makes sense to have @Startup,
> @Pooling, @Scedule, @Asynchronous where it fits better.
>
Why not keeping in EJBs (even if it needs to be renamed for historical
reasons)? ie a spec on top of CDI, not <= CDI.
> Antonio
>
> On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand
> <antoine(a)sabot-durand.net> wrote:
>>
>> Guys, don’t forget the commons annotation specification since we’re
going
>> to ask for a MR for it. It could be a convenient solution to share
>> annotation without having a huge dependency to have it (think of SE).
>>
>> Antoine
>>
>>
>> Le 17 nov. 2014 à 16:53, Antonio Goncalves <antonio.goncalves(a)gmail.com>
a
>> écrit :
>>
>> @Startup could also make sense in Concurrency in Java EE, like @Pooling
>> (there's thread pools behind). BTW I was talking to the Oracle guys
and it
>> looks like the Concurrency spec will be updated in EE 8... I don't know
how
>> far the update will go.
>>
>> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB
>> replacement going to where it belongs : the JMS spec
>>
>> Antonio
>>
>> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms(a)gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
>>> <antoine(a)sabot-durand.net> wrote:
>>> > Just to give you a small feedback of my Devoxx week regarding CDI and
>>> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
>>> >
>>> > 1) Great expectations:
>>> > [...] (the question of total EJB replacement came more than once)
>>>
>>> I heard this a number of times as well, both before and during Devoxx.
>>>
>>> A great number of issues for decoupling EJB features (meaning,
>>> providing CDI based replacements) have already been created as spec
>>> issues:
>>>
>>> * Decoupling the @Schedule annotation from the EJB component model
>>> (EJB_SPEC-1)
>>> * Decoupling the TimerService API from the EJB component model
>>> (EJB_SPEC-2)
>>> * Decoupling the @Asynchronous annotation from the EJB component model
>>> (EJB_SPEC-3)
>>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB
>>> component model (EJB_SPEC-4)
>>> * Decoupling the @Startup/@DependsOn annotations from the EJB
>>> component model (EJB_SPEC-19)
>>> * Standardize Pooling and Decouple from EJB Component Model
>>> (EJB_SPEC-113)
>>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
>>> * Standardize Abstractions for Common Message Processing Patterns
>>> (JMS_SPEC-154)
>>> * Allow Java EE components other than MDBs to consume messages
>>> asynchronously (JMS_SPEC-100)
>>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
>>> * Support for "self" injection (CDI-414)
>>> * Allow access-control related JSR-250 security annotations on managed
>>> beans (JAVASERVERFACES_SPEC_PUBLIC-495)
>>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
>>>
>>>
>>> There are some additional features that may not yet have been covered
>>> (but maybe I missed them), such as:
>>>
>>> * Control over passivation
>>> * Support for the extended persistence context
>>> * Destroying a bean whenever an exception occurs (I was just working
>>> on this the other week)
>>> * Logging the exception thrown by a bean (yes, trivial, but part of
EJB)
>>> * The concept where every method call on a proxy is routed to another
>>> bean instance, which is then automatically unavailable for other calls
>>> as long as it doesn't return (related to the "Standardize
Pooling"
>>> issue)
>>> * Binary remoting without all the explicit mapping that's needed for
>>> say JAX-RS (yes, thorny issue which we may not wish to support
>>> anymore?)
>>> * General support for @RolesAllowed/@RunAs etc (often mentioned, and
>>> two issues for JSF managed beans resp Servlets were created, but no
>>> general issue)
>>>
>>> The question is perhaps where all this functionality should live.
>>>
>>> TimerService and @Asynchronous in the concurrency spec?
>>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS
spec?
>>> @RolesAllowed etc in the security spec (if that spec will actually
>>> happen)
>>> @Startup in the CDI spec itself?
>>> Destroying bean on exception in CDI spec?
>>>
>>> But where should e.g. pooling belong?
>>>
>>> Kind regards,
>>> Arjan Tijms
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other
intellectual
>>> property rights inherent in such information.
>>
>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect, Java Champion and Pluralsight author
>>
>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>>
>>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
intellectual
> property rights inherent in such information.
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>
|
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
3:10 p.m.
Actually it makes sense, we already have @Transactional so only
security part is really missing from EJB spec - sorry for the noise.
Is there a place with all asked features (JavaSE, @Pooling, easier
SPI, config, ...)? then people could maybe vote?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-11-17 22:04 GMT+01:00 Antonio Goncalves <antonio.goncalves(a)gmail.com>:
Like @dblevins once said "EJB was a super hype spec with all the
cool
features... and became blotted throughout the years". If we are not careful,
CDI (the super hype spec at the moment) will become blotted too.
Context and Dependency Injection should not deal with pooling, scheduling,
security.... but yes, allow the other specs to implement such concerns. I
can easily see most of these concerns implemented with interceptor bindings
or extensions.
When we talked to Nigel (JMS spec lead) he was really enthousiast to learn
more about CDI and use it to help develop JMS internals. Manfred (JSF / MVC)
who has already implemented most of the JSF stuff with CDI (@ViewScoped and
so on) was really encouraging.
I think that part of the job this CDI 2.0 expert group has is to evangelize
current specs leads to use CDI in their internals.
Antonio
On Mon, Nov 17, 2014 at 9:55 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com>
wrote:
>
> 2014-11-17 21:53 GMT+01:00 Antonio Goncalves
> <antonio.goncalves(a)gmail.com>:
> > Would you like to see @Inject in JSR 250 ? I don't think it's a good
> > idea to
> > put everything in Commons Annotations. It makes sense to have @Startup,
> > @Pooling, @Scedule, @Asynchronous where it fits better.
> >
>
> Why not keeping in EJBs (even if it needs to be renamed for historical
> reasons)? ie a spec on top of CDI, not <= CDI.
>
> > Antonio
> >
> > On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand
> > <antoine(a)sabot-durand.net> wrote:
> >>
> >> Guys, don’t forget the commons annotation specification since we’re
> >> going
> >> to ask for a MR for it. It could be a convenient solution to share
> >> annotation without having a huge dependency to have it (think of SE).
> >>
> >> Antoine
> >>
> >>
> >> Le 17 nov. 2014 à 16:53, Antonio Goncalves
> >> <antonio.goncalves(a)gmail.com> a
> >> écrit :
> >>
> >> @Startup could also make sense in Concurrency in Java EE, like @Pooling
> >> (there's thread pools behind). BTW I was talking to the Oracle guys
> >> and it
> >> looks like the Concurrency spec will be updated in EE 8... I don't know
> >> how
> >> far the update will go.
> >>
> >> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB
> >> replacement going to where it belongs : the JMS spec
> >>
> >> Antonio
> >>
> >> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms(a)gmail.com>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
> >>> <antoine(a)sabot-durand.net> wrote:
> >>> > Just to give you a small feedback of my Devoxx week regarding CDI
> >>> > and
> >>> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
> >>> >
> >>> > 1) Great expectations:
> >>> > [...] (the question of total EJB replacement came more than once)
> >>>
> >>> I heard this a number of times as well, both before and during Devoxx.
> >>>
> >>> A great number of issues for decoupling EJB features (meaning,
> >>> providing CDI based replacements) have already been created as spec
> >>> issues:
> >>>
> >>> * Decoupling the @Schedule annotation from the EJB component model
> >>> (EJB_SPEC-1)
> >>> * Decoupling the TimerService API from the EJB component model
> >>> (EJB_SPEC-2)
> >>> * Decoupling the @Asynchronous annotation from the EJB component model
> >>> (EJB_SPEC-3)
> >>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB
> >>> component model (EJB_SPEC-4)
> >>> * Decoupling the @Startup/@DependsOn annotations from the EJB
> >>> component model (EJB_SPEC-19)
> >>> * Standardize Pooling and Decouple from EJB Component Model
> >>> (EJB_SPEC-113)
> >>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
> >>> * Standardize Abstractions for Common Message Processing Patterns
> >>> (JMS_SPEC-154)
> >>> * Allow Java EE components other than MDBs to consume messages
> >>> asynchronously (JMS_SPEC-100)
> >>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
> >>> * Support for "self" injection (CDI-414)
> >>> * Allow access-control related JSR-250 security annotations on managed
> >>> beans (JAVASERVERFACES_SPEC_PUBLIC-495)
> >>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
> >>>
> >>>
> >>> There are some additional features that may not yet have been covered
> >>> (but maybe I missed them), such as:
> >>>
> >>> * Control over passivation
> >>> * Support for the extended persistence context
> >>> * Destroying a bean whenever an exception occurs (I was just working
> >>> on this the other week)
> >>> * Logging the exception thrown by a bean (yes, trivial, but part of
> >>> EJB)
> >>> * The concept where every method call on a proxy is routed to another
> >>> bean instance, which is then automatically unavailable for other calls
> >>> as long as it doesn't return (related to the "Standardize
Pooling"
> >>> issue)
> >>> * Binary remoting without all the explicit mapping that's needed
for
> >>> say JAX-RS (yes, thorny issue which we may not wish to support
> >>> anymore?)
> >>> * General support for @RolesAllowed/@RunAs etc (often mentioned, and
> >>> two issues for JSF managed beans resp Servlets were created, but no
> >>> general issue)
> >>>
> >>> The question is perhaps where all this functionality should live.
> >>>
> >>> TimerService and @Asynchronous in the concurrency spec?
> >>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS
> >>> spec?
> >>> @RolesAllowed etc in the security spec (if that spec will actually
> >>> happen)
> >>> @Startup in the CDI spec itself?
> >>> Destroying bean on exception in CDI spec?
> >>>
> >>> But where should e.g. pooling belong?
> >>>
> >>> Kind regards,
> >>> Arjan Tijms
> >>> _______________________________________________
> >>> cdi-dev mailing list
> >>> cdi-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>
> >>> Note that for all code provided on this list, the provider licenses
> >>> the
> >>> code under the Apache License, Version 2
> >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >>> provided on this list, the provider waives all patent and other
> >>> intellectual
> >>> property rights inherent in such information.
> >>
> >>
> >>
> >>
> >> --
> >> Antonio Goncalves
> >> Software architect, Java Champion and Pluralsight author
> >>
> >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >>
> >>
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> > code
> > under the Apache License, Version 2
> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual
> > property rights inherent in such information.
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
3:15 p.m.
That's something that has to be discussed in the EE expert group (@arjan
pointed at the JIRAs) because, let's face it, nobody really wants to open
up the EJB spec (let's leave it quiet, so let's not bring this to the
former EJB expert group... which I'm part of ;o)
Antonio
On Mon, Nov 17, 2014 at 10:10 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com>
wrote:
Actually it makes sense, we already have @Transactional so only
security part is really missing from EJB spec - sorry for the noise.
Is there a place with all asked features (JavaSE, @Pooling, easier
SPI, config, ...)? then people could maybe vote?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-11-17 22:04 GMT+01:00 Antonio Goncalves <antonio.goncalves(a)gmail.com
>:
> Like @dblevins once said "EJB was a super hype spec with all the cool
> features... and became blotted throughout the years". If we are not
careful,
> CDI (the super hype spec at the moment) will become blotted too.
>
> Context and Dependency Injection should not deal with pooling,
scheduling,
> security.... but yes, allow the other specs to implement such concerns. I
> can easily see most of these concerns implemented with interceptor
bindings
> or extensions.
>
> When we talked to Nigel (JMS spec lead) he was really enthousiast to
learn
> more about CDI and use it to help develop JMS internals. Manfred (JSF /
MVC)
> who has already implemented most of the JSF stuff with CDI (@ViewScoped
and
> so on) was really encouraging.
>
> I think that part of the job this CDI 2.0 expert group has is to
evangelize
> current specs leads to use CDI in their internals.
>
> Antonio
>
> On Mon, Nov 17, 2014 at 9:55 PM, Romain Manni-Bucau <
rmannibucau(a)gmail.com>
> wrote:
>>
>> 2014-11-17 21:53 GMT+01:00 Antonio Goncalves
>> <antonio.goncalves(a)gmail.com>:
>> > Would you like to see @Inject in JSR 250 ? I don't think it's a
good
>> > idea to
>> > put everything in Commons Annotations. It makes sense to have
@Startup,
>> > @Pooling, @Scedule, @Asynchronous where it fits better.
>> >
>>
>> Why not keeping in EJBs (even if it needs to be renamed for historical
>> reasons)? ie a spec on top of CDI, not <= CDI.
>>
>> > Antonio
>> >
>> > On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand
>> > <antoine(a)sabot-durand.net> wrote:
>> >>
>> >> Guys, don’t forget the commons annotation specification since we’re
>> >> going
>> >> to ask for a MR for it. It could be a convenient solution to share
>> >> annotation without having a huge dependency to have it (think of SE).
>> >>
>> >> Antoine
>> >>
>> >>
>> >> Le 17 nov. 2014 à 16:53, Antonio Goncalves
>> >> <antonio.goncalves(a)gmail.com> a
>> >> écrit :
>> >>
>> >> @Startup could also make sense in Concurrency in Java EE, like
@Pooling
>> >> (there's thread pools behind). BTW I was talking to the Oracle
guys
>> >> and it
>> >> looks like the Concurrency spec will be updated in EE 8... I don't
know
>> >> how
>> >> far the update will go.
>> >>
>> >> As for the JMS stuff, we talked with Nigel and he likes the idea of
MDB
>> >> replacement going to where it belongs : the JMS spec
>> >>
>> >> Antonio
>> >>
>> >> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms
<arjan.tijms(a)gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
>> >>> <antoine(a)sabot-durand.net> wrote:
>> >>> > Just to give you a small feedback of my Devoxx week regarding
CDI
>> >>> > and
>> >>> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx
;) )
>> >>> >
>> >>> > 1) Great expectations:
>> >>> > [...] (the question of total EJB replacement came more than
once)
>> >>>
>> >>> I heard this a number of times as well, both before and during
Devoxx.
>> >>>
>> >>> A great number of issues for decoupling EJB features (meaning,
>> >>> providing CDI based replacements) have already been created as
spec
>> >>> issues:
>> >>>
>> >>> * Decoupling the @Schedule annotation from the EJB component model
>> >>> (EJB_SPEC-1)
>> >>> * Decoupling the TimerService API from the EJB component model
>> >>> (EJB_SPEC-2)
>> >>> * Decoupling the @Asynchronous annotation from the EJB component
model
>> >>> (EJB_SPEC-3)
>> >>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB
>> >>> component model (EJB_SPEC-4)
>> >>> * Decoupling the @Startup/@DependsOn annotations from the EJB
>> >>> component model (EJB_SPEC-19)
>> >>> * Standardize Pooling and Decouple from EJB Component Model
>> >>> (EJB_SPEC-113)
>> >>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
>> >>> * Standardize Abstractions for Common Message Processing Patterns
>> >>> (JMS_SPEC-154)
>> >>> * Allow Java EE components other than MDBs to consume messages
>> >>> asynchronously (JMS_SPEC-100)
>> >>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
>> >>> * Support for "self" injection (CDI-414)
>> >>> * Allow access-control related JSR-250 security annotations on
managed
>> >>> beans (JAVASERVERFACES_SPEC_PUBLIC-495)
>> >>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
>> >>>
>> >>>
>> >>> There are some additional features that may not yet have been
covered
>> >>> (but maybe I missed them), such as:
>> >>>
>> >>> * Control over passivation
>> >>> * Support for the extended persistence context
>> >>> * Destroying a bean whenever an exception occurs (I was just
working
>> >>> on this the other week)
>> >>> * Logging the exception thrown by a bean (yes, trivial, but part
of
>> >>> EJB)
>> >>> * The concept where every method call on a proxy is routed to
another
>> >>> bean instance, which is then automatically unavailable for other
calls
>> >>> as long as it doesn't return (related to the "Standardize
Pooling"
>> >>> issue)
>> >>> * Binary remoting without all the explicit mapping that's
needed for
>> >>> say JAX-RS (yes, thorny issue which we may not wish to support
>> >>> anymore?)
>> >>> * General support for @RolesAllowed/@RunAs etc (often mentioned,
and
>> >>> two issues for JSF managed beans resp Servlets were created, but
no
>> >>> general issue)
>> >>>
>> >>> The question is perhaps where all this functionality should live.
>> >>>
>> >>> TimerService and @Asynchronous in the concurrency spec?
>> >>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS
>> >>> spec?
>> >>> @RolesAllowed etc in the security spec (if that spec will actually
>> >>> happen)
>> >>> @Startup in the CDI spec itself?
>> >>> Destroying bean on exception in CDI spec?
>> >>>
>> >>> But where should e.g. pooling belong?
>> >>>
>> >>> Kind regards,
>> >>> Arjan Tijms
>> >>> _______________________________________________
>> >>> cdi-dev mailing list
>> >>> cdi-dev(a)lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >>>
>> >>> Note that for all code provided on this list, the provider
licenses
>> >>> the
>> >>> code under the Apache License, Version 2
>> >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas
>> >>> provided on this list, the provider waives all patent and other
>> >>> intellectual
>> >>> property rights inherent in such information.
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Antonio Goncalves
>> >> Software architect, Java Champion and Pluralsight author
>> >>
>> >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
France
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Antonio Goncalves
>> > Software architect, Java Champion and Pluralsight author
>> >
>> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
France
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > cdi-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses
the
>> > code
>> > under the Apache License, Version 2
>> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas
>> > provided on this list, the provider waives all patent and other
>> > intellectual
>> > property rights inherent in such information.
>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>
|
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
3:23 p.m.
Hi,
On Mon, Nov 17, 2014 at 10:04 PM, Antonio Goncalves
<antonio.goncalves(a)gmail.com> wrote:
Like @dblevins once said "EJB was a super hype spec with all the
cool
features... and became blotted throughout the years". If we are not careful,
CDI (the super hype spec at the moment) will become blotted too
I strongly support that!
IMHO as little as possible of these higher level features should be
implemented within CDI itself, so that CDI itself can completely focus
on being the contextual DI spec on which all other specs can build.
I think it's already problematic that CDI 1.1 provided producers for
Servlet artifacts, instead of letting the Servlet spec itself define
those producers. If/when Servlet starts depending on CDI there will be
a rather awkward circular dependency.
Kind regards,
Arjan
3:39 p.m.
Yes, we talked about this topic with Manfried and Antoine : CDI should not
mention servlet or JSF nor depend on them. I think a little refactoring of
the spec would be needed in 2.0 so that CDI doesn't depend on anything
(except @Inject) and all the specs would, hopefully, depend on it.
On Mon, Nov 17, 2014 at 10:23 PM, arjan tijms <arjan.tijms(a)gmail.com> wrote:
Hi,
On Mon, Nov 17, 2014 at 10:04 PM, Antonio Goncalves
<antonio.goncalves(a)gmail.com> wrote:
> Like @dblevins once said "EJB was a super hype spec with all the cool
> features... and became blotted throughout the years". If we are not
careful,
> CDI (the super hype spec at the moment) will become blotted too
I strongly support that!
IMHO as little as possible of these higher level features should be
implemented within CDI itself, so that CDI itself can completely focus
on being the contextual DI spec on which all other specs can build.
I think it's already problematic that CDI 1.1 provided producers for
Servlet artifacts, instead of letting the Servlet spec itself define
those producers. If/when Servlet starts depending on CDI there will be
a rather awkward circular dependency.
Kind regards,
Arjan
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>
|
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
4:11 a.m.
Arjan,
This very topic has been discussed with Ed Burns (Servlet Spec lead) and he agreed to work
on moving these feature from CDI to his spec. Ideally CDI shouldn’t have dependency to
front specs (servlet, jsf, jax-rs). We’ll try to work in that direction for version 2.0.
Antoine
Le 17 nov. 2014 à 22:23, arjan tijms <arjan.tijms(a)gmail.com> a
écrit :
Hi,
On Mon, Nov 17, 2014 at 10:04 PM, Antonio Goncalves
<antonio.goncalves(a)gmail.com> wrote:
> Like @dblevins once said "EJB was a super hype spec with all the cool
> features... and became blotted throughout the years". If we are not careful,
> CDI (the super hype spec at the moment) will become blotted too
I strongly support that!
IMHO as little as possible of these higher level features should be
implemented within CDI itself, so that CDI itself can completely focus
on being the contextual DI spec on which all other specs can build.
I think it's already problematic that CDI 1.1 provided producers for
Servlet artifacts, instead of letting the Servlet spec itself define
those producers. If/when Servlet starts depending on CDI there will be
a rather awkward circular dependency.
Kind regards,
Arjan
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
5:33 a.m.
On Tue, Nov 18, 2014 at 11:11 AM, Antoine Sabot-Durand
<antoine(a)sabot-durand.net> wrote:
This very topic has been discussed with Ed Burns (Servlet Spec lead)
and he agreed to work on moving these feature from CDI to his spec. Ideally CDI shouldn’t
have dependency to front specs (servlet, jsf, jax-rs). We’ll try to work in that direction
for version 2.0.
That's great to hear really. I brought the subject up at the servlet
mailing list (see
https://java.net/projects/servlet-spec/lists/users/archive/2014-11/messag...)
but there wasn't a follow up there about that discussion.
There's btw also a producer for the UserPrincipal, which I think
should ideally go to either the new security spec (again if/when it
happens) or JASPIC, and a producer for a JTA UserTransaction, which I
guess would be best off just being in JTA.
Kind regards,
Arjan
Antoine
> Le 17 nov. 2014 à 22:23, arjan tijms <arjan.tijms(a)gmail.com> a écrit :
>
> Hi,
>
> On Mon, Nov 17, 2014 at 10:04 PM, Antonio Goncalves
> <antonio.goncalves(a)gmail.com> wrote:
>> Like @dblevins once said "EJB was a super hype spec with all the cool
>> features... and became blotted throughout the years". If we are not
careful,
>> CDI (the super hype spec at the moment) will become blotted too
>
> I strongly support that!
>
> IMHO as little as possible of these higher level features should be
> implemented within CDI itself, so that CDI itself can completely focus
> on being the contextual DI spec on which all other specs can build.
>
> I think it's already problematic that CDI 1.1 provided producers for
> Servlet artifacts, instead of letting the Servlet spec itself define
> those producers. If/when Servlet starts depending on CDI there will be
> a rather awkward circular dependency.
>
> Kind regards,
> Arjan
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under
the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all
other ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
3:15 p.m.
Hi,
On Mon, Nov 17, 2014 at 9:55 PM, Romain Manni-Bucau
<rmannibucau(a)gmail.com> wrote:
2014-11-17 21:53 GMT+01:00 Antonio Goncalves
<antonio.goncalves(a)gmail.com>:
> Would you like to see @Inject in JSR 250 ? I don't think it's a good idea to
> put everything in Commons Annotations. It makes sense to have @Startup,
> @Pooling, @Scedule, @Asynchronous where it fits better.
>
Why not keeping in EJBs (even if it needs to be renamed for historical
reasons)? ie a spec on top of CDI, not <= CDI.
It could theoretically be an option to have the EJB spec define many
of its key features as CDI based functionality.
For the crucial backwards compatibility concern it should not replace
its existing implementation by those, but just offer the CDI ones next
to the existing EJB-native ones. E.g. just like JSF offers an
@ViewScoped for usage with its native managed beans and a second
@ViewScoped for use with CDI beans.
A counter argument is that EJB has always been about the following concerns:
* A component bean model
* DI capabilities
* Remoting (the initial key EJB feature)
* Transactions
* Security
* Concurrency control
* Asynchronous execution
* Scheduling
* Messaging integration (not messaging itself)
DI and the component bean model are now provided in a more universal
way by CDI. Remoting is now mostly done by JAX-RS. Transactions was
always JTA, EJB just offered an ease of use facility on top of it. The
security annotations already are not EJB annotations, they're
curiously enough only implemented/supported by EJB at the moment.
Concurrency now has its own spec, so my feeling is that concurrency
control (i.e. the fact that calls to a single bean instance will be
serialized) and asynchronous execution should be in that spec.
Scheduling and messaging integration are open questions. Scheduling
kinda feels like it may belong with concurrency as well, but messaging
integration is more difficult. In the MDB/connector architecture JMS
was always just one of many messaging options. JMS was simply the only
one that is included with Java EE.
Kind regards,
Arjan Tijms
> Antonio
>
> On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand
> <antoine(a)sabot-durand.net> wrote:
>>
>> Guys, don’t forget the commons annotation specification since we’re going
>> to ask for a MR for it. It could be a convenient solution to share
>> annotation without having a huge dependency to have it (think of SE).
>>
>> Antoine
>>
>>
>> Le 17 nov. 2014 à 16:53, Antonio Goncalves <antonio.goncalves(a)gmail.com> a
>> écrit :
>>
>> @Startup could also make sense in Concurrency in Java EE, like @Pooling
>> (there's thread pools behind). BTW I was talking to the Oracle guys and it
>> looks like the Concurrency spec will be updated in EE 8... I don't know how
>> far the update will go.
>>
>> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB
>> replacement going to where it belongs : the JMS spec
>>
>> Antonio
>>
>> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms(a)gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
>>> <antoine(a)sabot-durand.net> wrote:
>>> > Just to give you a small feedback of my Devoxx week regarding CDI and
>>> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
>>> >
>>> > 1) Great expectations:
>>> > [...] (the question of total EJB replacement came more than once)
>>>
>>> I heard this a number of times as well, both before and during Devoxx.
>>>
>>> A great number of issues for decoupling EJB features (meaning,
>>> providing CDI based replacements) have already been created as spec
>>> issues:
>>>
>>> * Decoupling the @Schedule annotation from the EJB component model
>>> (EJB_SPEC-1)
>>> * Decoupling the TimerService API from the EJB component model
>>> (EJB_SPEC-2)
>>> * Decoupling the @Asynchronous annotation from the EJB component model
>>> (EJB_SPEC-3)
>>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB
>>> component model (EJB_SPEC-4)
>>> * Decoupling the @Startup/@DependsOn annotations from the EJB
>>> component model (EJB_SPEC-19)
>>> * Standardize Pooling and Decouple from EJB Component Model
>>> (EJB_SPEC-113)
>>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
>>> * Standardize Abstractions for Common Message Processing Patterns
>>> (JMS_SPEC-154)
>>> * Allow Java EE components other than MDBs to consume messages
>>> asynchronously (JMS_SPEC-100)
>>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
>>> * Support for "self" injection (CDI-414)
>>> * Allow access-control related JSR-250 security annotations on managed
>>> beans (JAVASERVERFACES_SPEC_PUBLIC-495)
>>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
>>>
>>>
>>> There are some additional features that may not yet have been covered
>>> (but maybe I missed them), such as:
>>>
>>> * Control over passivation
>>> * Support for the extended persistence context
>>> * Destroying a bean whenever an exception occurs (I was just working
>>> on this the other week)
>>> * Logging the exception thrown by a bean (yes, trivial, but part of EJB)
>>> * The concept where every method call on a proxy is routed to another
>>> bean instance, which is then automatically unavailable for other calls
>>> as long as it doesn't return (related to the "Standardize
Pooling"
>>> issue)
>>> * Binary remoting without all the explicit mapping that's needed for
>>> say JAX-RS (yes, thorny issue which we may not wish to support
>>> anymore?)
>>> * General support for @RolesAllowed/@RunAs etc (often mentioned, and
>>> two issues for JSF managed beans resp Servlets were created, but no
>>> general issue)
>>>
>>> The question is perhaps where all this functionality should live.
>>>
>>> TimerService and @Asynchronous in the concurrency spec?
>>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?
>>> @RolesAllowed etc in the security spec (if that spec will actually
>>> happen)
>>> @Startup in the CDI spec itself?
>>> Destroying bean on exception in CDI spec?
>>>
>>> But where should e.g. pooling belong?
>>>
>>> Kind regards,
>>> Arjan Tijms
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other intellectual
>>> property rights inherent in such information.
>>
>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect, Java Champion and Pluralsight author
>>
>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>>
>>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
4:06 a.m.
Le 17 nov. 2014 à 21:53, Antonio Goncalves
<antonio.goncalves(a)gmail.com> a écrit :
Would you like to see @Inject in JSR 250 ?
No, but in the end it’s a good thing that it is not in CDI (in a far lighter spec), so it
can be used by other DI solution for the sake of end users.
I don't think it's a good idea to put everything in Commons
Annotations. It makes sense to have @Startup, @Pooling, @Scedule, @Asynchronous where it
fits better.
Again, it’s a only Java EE pov, having such dependencies in Java SE can be a real
handicap. Take @Startup for instance. Its purpose is to make sure that a bean is
instantiated at startup. Why in the hell would I want to drag all the concurrency spec to
only have this annotation ?
I don’t say that it’s the case for all annotations, but we should really consider having
this multiple purpose annotation in light spec. For instance I’m not against having our
@Produces moved to AtInject (and perhaps renamed to @Provides to end the mix with JAX-RX
Produces) to share this concept with all other implementations.
Antonio
On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand <antoine(a)sabot-durand.net
<mailto:antoine@sabot-durand.net>> wrote:
Guys, don’t forget the commons annotation specification since we’re going to ask for a MR
for it. It could be a convenient solution to share annotation without having a huge
dependency to have it (think of SE).
Antoine
> Le 17 nov. 2014 à 16:53, Antonio Goncalves <antonio.goncalves(a)gmail.com
<mailto:antonio.goncalves@gmail.com>> a écrit :
>
> @Startup could also make sense in Concurrency in Java EE, like @Pooling (there's
thread pools behind). BTW I was talking to the Oracle guys and it looks like the
Concurrency spec will be updated in EE 8... I don't know how far the update will go.
>
> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB replacement
going to where it belongs : the JMS spec
>
> Antonio
>
> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms(a)gmail.com
<mailto:arjan.tijms@gmail.com>> wrote:
> Hi,
>
> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
> <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote:
> > Just to give you a small feedback of my Devoxx week regarding CDI and CDI 2.0
(for the rest, what happens in Devoxx stays in Devoxx ;) )
> >
> > 1) Great expectations:
> > [...] (the question of total EJB replacement came more than once)
>
> I heard this a number of times as well, both before and during Devoxx.
>
> A great number of issues for decoupling EJB features (meaning,
> providing CDI based replacements) have already been created as spec
> issues:
>
> * Decoupling the @Schedule annotation from the EJB component model (EJB_SPEC-1)
> * Decoupling the TimerService API from the EJB component model (EJB_SPEC-2)
> * Decoupling the @Asynchronous annotation from the EJB component model
> (EJB_SPEC-3)
> * Decoupling the @Lock/@AccessTimeout annotations from the EJB
> component model (EJB_SPEC-4)
> * Decoupling the @Startup/@DependsOn annotations from the EJB
> component model (EJB_SPEC-19)
> * Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113)
> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
> * Standardize Abstractions for Common Message Processing Patterns (JMS_SPEC-154)
> * Allow Java EE components other than MDBs to consume messages
> asynchronously (JMS_SPEC-100)
> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
> * Support for "self" injection (CDI-414)
> * Allow access-control related JSR-250 security annotations on managed
> beans (JAVASERVERFACES_SPEC_PUBLIC-495)
> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
>
>
> There are some additional features that may not yet have been covered
> (but maybe I missed them), such as:
>
> * Control over passivation
> * Support for the extended persistence context
> * Destroying a bean whenever an exception occurs (I was just working
> on this the other week)
> * Logging the exception thrown by a bean (yes, trivial, but part of EJB)
> * The concept where every method call on a proxy is routed to another
> bean instance, which is then automatically unavailable for other calls
> as long as it doesn't return (related to the "Standardize Pooling"
> issue)
> * Binary remoting without all the explicit mapping that's needed for
> say JAX-RS (yes, thorny issue which we may not wish to support
> anymore?)
> * General support for @RolesAllowed/@RunAs etc (often mentioned, and
> two issues for JSF managed beans resp Servlets were created, but no
> general issue)
>
> The question is perhaps where all this functionality should live.
>
> TimerService and @Asynchronous in the concurrency spec?
> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?
> @RolesAllowed etc in the security spec (if that spec will actually happen)
> @Startup in the CDI spec itself?
> Destroying bean on exception in CDI spec?
>
> But where should e.g. pooling belong?
>
> Kind regards,
> Arjan Tijms
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev
<https://lists.jboss.org/mailman/listinfo/cdi-dev>
>
> Note that for all code provided on this list, the provider licenses the code under
the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html
<http://www.apache.org/licenses/LICENSE-2.0.html>). For all other ideas provided on
this list, the provider waives all patent and other intellectual property rights inherent
in such information.
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org/> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
Paris JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org/> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
Paris JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
4:07 a.m.
And what if the Concurrency spec is splitted in several parts ? We could
@Schedule or @Startup a servlet with just a subset of Concurrency for
example.
On Tue, Nov 18, 2014 at 11:06 AM, Antoine Sabot-Durand <
antoine(a)sabot-durand.net> wrote:
Le 17 nov. 2014 à 21:53, Antonio Goncalves <antonio.goncalves(a)gmail.com>
a écrit :
Would you like to see @Inject in JSR 250 ?
No, but in the end it’s a good thing that it is not in CDI (in a far
lighter spec), so it can be used by other DI solution for the sake of end
users.
I don't think it's a good idea to put everything in Commons Annotations.
It makes sense to have @Startup, @Pooling, @Scedule, @Asynchronous where it
fits better.
Again, it’s a only Java EE pov, having such dependencies in Java SE can be
a real handicap. Take @Startup for instance. Its purpose is to make sure
that a bean is instantiated at startup. Why in the hell would I want to
drag all the concurrency spec to only have this annotation ?
I don’t say that it’s the case for all annotations, but we should really
consider having this multiple purpose annotation in light spec. For
instance I’m not against having our @Produces moved to AtInject (and
perhaps renamed to @Provides to end the mix with JAX-RX Produces) to share
this concept with all other implementations.
Antonio
On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand <
antoine(a)sabot-durand.net> wrote:
> Guys, don’t forget the commons annotation specification since we’re going
> to ask for a MR for it. It could be a convenient solution to share
> annotation without having a huge dependency to have it (think of SE).
>
> Antoine
>
>
> Le 17 nov. 2014 à 16:53, Antonio Goncalves <antonio.goncalves(a)gmail.com>
> a écrit :
>
> @Startup could also make sense in Concurrency in Java EE, like @Pooling
> (there's thread pools behind). BTW I was talking to the Oracle guys and
> it looks like the Concurrency spec will be updated in EE 8... I don't know
> how far the update will go.
>
> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB
> replacement going to where it belongs : the JMS spec
>
> Antonio
>
> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms(a)gmail.com>
> wrote:
>
>> Hi,
>>
>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
>> <antoine(a)sabot-durand.net> wrote:
>> > Just to give you a small feedback of my Devoxx week regarding CDI and
>> CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
>> >
>> > 1) Great expectations:
>> > [...] (the question of total EJB replacement came more than once)
>>
>> I heard this a number of times as well, both before and during Devoxx.
>>
>> A great number of issues for decoupling EJB features (meaning,
>> providing CDI based replacements) have already been created as spec
>> issues:
>>
>> * Decoupling the @Schedule annotation from the EJB component model
>> (EJB_SPEC-1)
>> * Decoupling the TimerService API from the EJB component model
>> (EJB_SPEC-2)
>> * Decoupling the @Asynchronous annotation from the EJB component model
>> (EJB_SPEC-3)
>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB
>> component model (EJB_SPEC-4)
>> * Decoupling the @Startup/@DependsOn annotations from the EJB
>> component model (EJB_SPEC-19)
>> * Standardize Pooling and Decouple from EJB Component Model
>> (EJB_SPEC-113)
>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
>> * Standardize Abstractions for Common Message Processing Patterns
>> (JMS_SPEC-154)
>> * Allow Java EE components other than MDBs to consume messages
>> asynchronously (JMS_SPEC-100)
>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
>> * Support for "self" injection (CDI-414)
>> * Allow access-control related JSR-250 security annotations on managed
>> beans (JAVASERVERFACES_SPEC_PUBLIC-495)
>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
>>
>>
>> There are some additional features that may not yet have been covered
>> (but maybe I missed them), such as:
>>
>> * Control over passivation
>> * Support for the extended persistence context
>> * Destroying a bean whenever an exception occurs (I was just working
>> on this the other week)
>> * Logging the exception thrown by a bean (yes, trivial, but part of EJB)
>> * The concept where every method call on a proxy is routed to another
>> bean instance, which is then automatically unavailable for other calls
>> as long as it doesn't return (related to the "Standardize Pooling"
>> issue)
>> * Binary remoting without all the explicit mapping that's needed for
>> say JAX-RS (yes, thorny issue which we may not wish to support
>> anymore?)
>> * General support for @RolesAllowed/@RunAs etc (often mentioned, and
>> two issues for JSF managed beans resp Servlets were created, but no
>> general issue)
>>
>> The question is perhaps where all this functionality should live.
>>
>> TimerService and @Asynchronous in the concurrency spec?
>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?
>> @RolesAllowed etc in the security spec (if that spec will actually
>> happen)
>> @Startup in the CDI spec itself?
>> Destroying bean on exception in CDI spec?
>>
>> But where should e.g. pooling belong?
>>
>> Kind regards,
>> Arjan Tijms
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org/> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
> JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
>
>
>
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org/> | Twitter
<http://twitter.com/agoncal> | LinkedIn
<http://www.linkedin.com/in/agoncal> | Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>
|
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
1 a.m.
BTW, looks like Bob Lee is active because I can see he is planned to be in
the expert group of Java Platform Module System
https://jcp.org/en/jsr/detail?id=376
Antonio
On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand <
antoine(a)sabot-durand.net> wrote:
Hi all,
Just to give you a small feedback of my Devoxx week regarding CDI and CDI
2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
1) Great expectations:
I’m not going to state the obvious, but end user and other specs are
watching us and expect a lot from CDI 2.0 (the question of total EJB
replacement came more than once)
2) Antonin Stefanutti and myself delivered a very valuable content in our
CDI advanced university. I don’t remember being so proud of a talk material
I released before. I encourage you to give it an eye and use it if you
want. you can watch it on Slideshare [1] or grab the source slides on
Antonin’s Github repo [2]
3) Other spec are really willing to have a better integration.
I met JMS, Servlet, JSF and MVC spec leaders, they all are looking for a
better integration with CDI and are ok to take CDI specific part related to
their spec back in their spec (Servlet and JSF mostly). Working with them
will bring a more consistent Java EE and will reduce extra code from the
spec.
4) After months of discussion I finally met Jurgen Hoeller (Spring
Framework) and Christian Gruber (Dagger and Guice) and we all agreed on a
new version or MR of AtInject spec. Juergen will probably be the spec lead
and we hope to have the big work done before mid 2015 (cross finger) to met
our various agenda. That will probably add extra work for CDI 2.0 but will
bring clarity and a good signal to the community. Thanks to Antonio who
helped me on this.
For those who remember the history of JSR 330 and JSR 299 the following
picture will be nearly an historical one ;) [3]
Antoine
[1] http://www.slideshare.net/antoinesd/going-further-with-cdi-41411812
[2] https://github.com/astefanutti/further-cdi
[3] http://twitter.com/antoine_sd/status/533710069255667712/photo/1
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>
|
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
3469
days inactive
3479
days old
19 comments
4 participants
participants (4)
-
Antoine Sabot-Durand -
Antonio Goncalves -
arjan tijms -
Romain Manni-Bucau