[cdi-dev] [PROPOSAL] further align CDI and EJB

Wed Nov 18 16:47:49 EST 2015

I think it would be better to integrate concurrency handling into CDI, to
avoid further ambiguities that will arise when dealing with separate
specifications.

Introduction of @Lock would allow concurrency control on contextual beans.
This would make life a lot easier especially when dealing with AJAX
applications, which often fire concurrent requests. Such as in the case of
JSF AJAX applications, at the moment concurrent access is handled by the
JSF implementation, easier immediately throwing a BusyConversationException
or waiting for a couple of milliseconds before retrying.

Stephan

On Tue, 17 Nov 2015 at 15:42 Werner Keil <werner.keil at gmail.com> wrote:

> Guess that isn't too different from touchpoints and possible needs to
> actually make minor changes to that spec with JSR 330 (aka @Inject ;-)
>
> If either for 330 or 236 changes to that actual spec are minimal, then it
> could be an overkill to file a new JSR just for the sake of it, a MR might
> be more than enough.
>
> Otherwise, maybe others including e.g. candidates for current EC seats
> could feel motivated enough to give it a try and offer themselves for such
> Spec Lead role.
>
> This year's JCP Award were since 2010 the first time that only Individuals
> (Adam Bien) and JSRs where at least Oracle isn't even in the EG
> (354/Anatole and 363 as well as JUG Chennai) won all awards. Maybe that
> could encourage Independent or smaller members, too?;-)
>
> Werner
>
> On Tue, Nov 17, 2015 at 1:58 PM, <cdi-dev-request at lists.jboss.org> wrote:
>
>> Send cdi-dev mailing list submissions to
>>         cdi-dev at lists.jboss.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>> or, via email, send a message with subject or body 'help' to
>>         cdi-dev-request at lists.jboss.org
>>
>> You can reach the person managing the list at
>>         cdi-dev-owner at lists.jboss.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of cdi-dev digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: [PROPOSAL] further align CDI and EJB (Reza Rahman)
>>
>    2. Re: [PROPOSAL] further align CDI and EJB (Werner Keil)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 17 Nov 2015 09:24:31 -0500
>
>
>> From: Reza Rahman <reza.rahman at oracle.com>
>> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
>> To: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
>>
> Message-ID: <39F78EFC-0E6D-4AAA-B81B-BF00DF9FBD74 at oracle.com>
>> Content-Type: text/plain; charset="utf-8"
>
>
>>
>> I would encourage finding a way to contribute this work to a Java EE
>> specification (CDI or otherwise) while being aware of the resource
>> realities.
>>
>> It does not necessarily need to be done in the short term since Java EE
>> does have something after all from a purely functional standpoint.
>>
>> Adding completable future to @Asynchronous is definitely an obvious
>> improvement at this stage. I am trying to get that done for EJB if I at all
>> can. I think a contribution in the GF 5 branch accomplishing that in EJB
>> would be incredibly beneficial if time permits. I could then take care of
>> the TCK and spec text portions.
>>
>> > On Nov 17, 2015, at 9:03 AM, arjan tijms <arjan.tijms at gmail.com> wrote:
>> >
>>
> > Hi,
>> >
>> >> On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves <
>> antonio.goncalves at gmail.com> wrote:
>> >> @Schedule should go to Java EE Concurrency (implemented as a CDI
>> interceptor) but not in CDI as this would be just moving more stuff inside
>> CDI (which will end up as big as EJBs). Same for @Asynchronous.
>> >
>> > 100% agree with this. It's almost better not to do things if absolutely
>> needed, then burden CDI with some concerns it perhaps should not be
>> concerned with. It's already problematic that CDI crossed this bridge once
>> with providing a Bean<T> for Servlet and other artifacts it doesn't own.
>> >
>> > As for @Asynchronous, a basic prototype implementation has already been
>> created by several parties. I did one here:
>> http://jdevelopment.nl/cdi-based-asynchronous-alternative and the Weld
>> team did one here:
>> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
>> >
>> > Also interesting would be to go a little beyond what the EJB vesion
>> offers and add support for a completable feature and optionally named
>> thread pools.
>> >
>> > Kind regards,
>> > Arjan Tijms
>> >
>> >
>> >
>> >>
>> >> So what could be doable in CDI 2.1 is having @Startup and @Shutdown
>> implemented... but the annotations would be in JSR 250.
>> >>
>> >> Antonio
>> >>
>> >>
>> >>> On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman <reza.rahman at oracle.com>
>> wrote:
>> >>> One good thing is that Oracle has not yet filed a JSR for Java EE
>> concurrency utilities targeting Java EE 8. That means any interested
>> parties could do so and perhaps that could be better for the community in
>> the end anyway.
>> >>>
>> >>> Certainly starting prototyping some of these things will make it
>> clearer where they belong or could be contributed to in the end.
>> >>>
>> >>> > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau <
>> rmannibucau at gmail.com> wrote:
>> >>> >
>> >>> > 2015-11-16 14:54 GMT-08:00 Reza Rahman <reza.rahman at oracle.com>:
>> >>> >> Responses in-line:
>> >>> >>
>> >>> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau <
>> rmannibucau at gmail.com> wrote:
>> >>> >>>
>> >>> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman <reza.rahman at oracle.com>:
>> >>> >>>> In terms of CDI and EJB alignment, I think these would have the
>> most
>> >>> >>>> value to the community going forward:
>> >>> >>>>
>> >>> >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core
>> has
>> >>> >>>> similarly nice syntax to handle eager loading).
>> >>> >>>
>> >>> >>> @Startup is there with @Initialized(ApplicationScoped) event
>> >>> >>> @DependsOn is less important than for EJB IMO cause all CDI is
>> lazy
>> >>> >>> and full of proxies so not sure it would bring much to the game
>> >>> >>> without bringing really much more like @Schedule etc...
>> >>> >>
>> >>> >> Yes, I know but eager loading is a common enough case to warrant
>> better syntax/usability.
>> >>> >
>> >>> > fair enough
>> >>> >
>> >>> >>>
>> >>> >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout
>> for CDI.
>> >>> >>>> These are very useful bits of functionality that should be
>> available to
>> >>> >>>> plain CDI beans without EJB. A similar @MaxConcurrency could
>> also be
>> >>> >>>> extremely useful. EJB @Schedule is similarly useful but likely
>> not right
>> >>> >>>> for CDI proper as it does not have that much to do with component
>> >>> >>>> life-cycle/bean access management. The others I think are quite
>> natural
>> >>> >>>> fits for the core of a DI framework (in fact it may be awkward
>> to have
>> >>> >>>> them elsewhere).
>> >>> >>>
>> >>> >>>
>> >>> >>> Think concurrency utilities can have a CDI integration rather than
>> >>> >>> putting everything in CDI. It is globally all interceptors - at
>> least
>> >>> >>> in term of design - so would make sense to have them outside IMO
>> - but
>> >>> >>> a big +1 to get them cleanly added on top of CDI.
>> >>> >>
>> >>> >> Keep in mind, Java EE concurrency utilities is also minimally
>> resourced and that's unlikely to change in the future. I would say if we
>> think these features would help community/CDI adoption, it's likely wisest
>> to find a way to do it in CDI proper. As I alluded to, these are also a bit
>> easier to implement at the core DI container level than via interceptors.
>> Things like @Transcational, @Schedule are easier as interceptors since they
>> don't have as much to do with the internals of the component life-cycle and
>> instance access control.
>> >>> >
>> >>> > well yes and not, it would be awesome to control where the
>> concurrency
>> >>> > is exactly in the stack and it would mean being able to change
>> >>> > @Priority for instance.
>> >>> >
>> >>> > Overall point being that if we put features only where resources are
>> >>> > instead of trying to put them where they fit and try to help these
>> >>> > specs CDI will likely handle javascript integration soon ;).
>> >>> >
>> >>> > Concurrency and throttling have a potential spec which would be
>> >>> > welcomed in these very distributed days, we just need to find people
>> >>> > motivated enough to make it moving forward IMO.
>> >>> >
>> >>> >>>
>> >>> >>>>
>> >>> >>>> As to doing more work in EJB, honestly it's likely best to leave
>> EJB be
>> >>> >>>> at this stage. If there is a compelling reason that helps the
>> platform
>> >>> >>>> and CDI generally we can see if it can be done. By default, EJB
>> is
>> >>> >>>> pretty minimally resourced for Java EE 8 and that's pretty hard
>> to
>> >>> >>>> change at this stage. In the community I have mostly seen
>> requests for
>> >>> >>>> moving functionality out of EJB into CDI rather than the other
>> way around...
>> >>> >>>>
>> >>> >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote:
>> >>> >>>>> Hi!
>> >>> >>>>>
>> >>> >>>>> We already do a decent amount of ?side-by-side? handling in EJB
>> and CDI. But there are still many aready where we could really move
>> together much closer.
>> >>> >>>>>
>> >>> >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get
>> accounted by the EJB container. But what happens with
>> ProcessAnnotatedType#veto(). This one is not defined that clearly I fear.
>> >>> >>>>>
>> >>> >>>>> What if we (of course together with the EJB spec group) define
>> that the EJB container must create the EJBs according to the effective
>> AnnotatedType coming out after ProcessAnnotatedType? This would define that
>> EJBs can also get modified via CDI Extensions. Some container do that
>> already.
>> >>> >>>>> The benefit of explicitly writing this down would obviously be
>> that we would allow EJB to fully utilize the power of CDI Extensions in a
>> portable way.
>> >>> >>>>>
>> >>> >>>>> Any objections, any ideas, any howtos?
>> >>> >>>>>
>> >>> >>>>> Let the ideas roll ;)
>> >>> >>>>>
>> >>> >>>>> LieGrue,
>> >>> >>>>> strub
>> >>> >>>>> _______________________________________________
>> >>> >>>>> 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.
>> >>>
>>
> >>> _______________________________________________
>> >>> 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
>
>
>> >>
>> >> _______________________________________________
>> >> 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.
>> >
>>
> -------------- next part --------------
>> An HTML attachment was scrubbed...
>>
> URL:
>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/98382c30/attachment-0001.html
>>
>> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151118/55bfbf0f/attachment-0001.html 