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

Wed Nov 18 16:55:17 EST 2015

Where it doesn't duplicate or reinvent something already defined in another
spec there should be no problem with that.

Werner

On Wed, Nov 18, 2015 at 10:47 PM, Stephan Knitelius <stephan at knitelius.com>
wrote:

> 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/045df69e/attachment-0001.html 