[cdi-dev] Feedback from Devoxx

Mon Nov 17 16:15:53 EST 2014

Hi,

On Mon, Nov 17, 2014 at 9:55 PM, Romain Manni-Bucau
<rmannibucau at gmail.com> wrote:
> 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.

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 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.
>
> _______________________________________________
> 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.