[cdi-dev] Feedback from Devoxx

[Romain Manni-Bucau]

2014-11-17 21:53 GMT+01:00 Antonio Goncalves <antonio.goncalves at 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 at 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 at 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 at gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
>>> <antoine at 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 at 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 at 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.