[cdi-dev] Feedback from Devoxx

Antonio Goncalves antonio.goncalves at gmail.com
Mon Nov 17 15:53:22 EST 2014


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 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 <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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141117/3d454f67/attachment.html 


More information about the cdi-dev mailing list