[JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...)
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-558:
---------------------------------
Wrt {{AnnotatedTypeBuilder}} what do you mean by "from outside CDI"? What about to introduce {{AnnotatedTypeBuilder}} as a built-in bean?
> Standardize the Meta-Data builders API (BeanBuilder, etc...)
> ------------------------------------------------------------
>
> Key: CDI-558
> URL: https://issues.jboss.org/browse/CDI-558
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 (discussion)
>
>
> The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspi...] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration).
> * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment...
> * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment...
> * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/ja...]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
- 1
- 0
[JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...)
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-558:
------------------------------------------
Here's the table:
||Builder||Access||
|{{AnnotatedTypeBuilder}}|Should be accessible everywhere (even from outside CDI). We should avoid adding it as a class and find a way to easily get an instance from the implementation|
|{{BeanAttributesBuilder}}|{{ProcessBeanAttributes}}|
|{{InjectionPointBuilder}}|{{ProcessInjectionPoint}}|
|{{ObserverMethodBuilder}}|{{ProcessObserverMethod}},{{AfterBeandiscovery}}|
|{{BeanBuilder}}|{{AfterBeanDiscovery}}|
> Standardize the Meta-Data builders API (BeanBuilder, etc...)
> ------------------------------------------------------------
>
> Key: CDI-558
> URL: https://issues.jboss.org/browse/CDI-558
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 (discussion)
>
>
> The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspi...] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration).
> * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment...
> * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment...
> * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/ja...]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
- 1
- 0
Clarification on 4.3 Specialization
by Emily Jiang
I have an application containing two wars.
testDiffBDA.war
testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
@Inject CounterProducerConsumerModified2 bean;
beans-xml-modified2.jar
containing one bean and an empty-ish beans.xml :
@Inject@CounterModifiedQualifier String modifiedProducer;
beans-xml-modified.jar.jar
CounterModifiedQualifier (the interface)
CounterProducerModified (the bean implementing that interface)
AlternativeCounterProducerModified (an alternative specialized bean)
beans.xml
<alternatives>
<class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
</alternatives>
My application failed deployment with the error on Weld but worked on
OpenWebBeans
[ERROR ] CWWKZ0004E: An exception occurred while starting the application
testDiffBDA. The exception message was:
com.ibm.ws.container.service.state.StateChangeException:
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied
dependencies for type String with qualifiers @CounterModifiedQualifier
at injection point [BackedAnnotatedField] @Inject
@CounterModifiedQualifier
com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
at
com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
--
After further investigation and talking to Martin from Weld, the error was
caused due to the fact of AlternativeCounterProducerModified disabling the
CounterProducerModified bean but itself is not enabled in the jar of
beans-xml-modified2.jar. Therefore, no producer is active to produce a bean
with the qualifier CounterModifiedQualifier.
>From Weld's perspective, any bean annotated with @Specialized disables a
second bean regardless whether itself is active or not.
My understanding is that the specialized should only take effect if itself
is enabled. Otherwise, we run into the situation of where the specialized
bean is not enabled but it disabled another bean. To me, it is wrong.
I also checked the spec:
@Alternative @Specializes
public class MockAsynchronousService extends AsynchronousService {
...
}
When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled
beans”, specializes
a second bean, we can be certain that the second bean is never instantiated
or called by the
container. Even if the second bean defines a producer or observer method,
the method will never
be called.
The spec says only an enabled bean can specialize a second bean. I would
like to know what other people think.
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
8 years, 5 months
- 4
- 8
[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Antoine Sabot-Durand commented on CDI-10:
-----------------------------------------
I think there are mixed needs here. And as we have tickets exposing similar needs (CDI-562, CDI-561and CDI-515), I think interesting to start from use cases. I see 2 of them (please add others if I missed one):
# Getting class of the bean to "read" meta-data. IMO in this case accessing the class is not the best solution: meta-data may have been overridden and as section 11.4 states : {quote}The container must use the operations of Annotated and its subinterfaces to discover program element types and annotations. The container must not directly call the Java Reflection API{quote}
# Getting the actual unwrap instance to have an unmanaged version of the instance (as described in CDI-561). But the use case are less obvious and the fact that other proxies may be injected in the instance make this rather hard to specify.
If we focus on 1st use case (having a way to read meta-data). We have to provide a way to retrieve the {{Bean}} from the instance and add a way to easily discover the nature of a given {{Bean}} (managed bean, session, bean, producer, custom). Having this info will help user to know where to find meta-data...
Regarding second point, every body interested should describe a user case from user POV to see if it's worth digging in that direction.
> Add ability to access a bean instance from a proxy
> --------------------------------------------------
>
> Key: CDI-10
> URL: https://issues.jboss.org/browse/CDI-10
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Fix For: 2.0 (discussion)
>
>
> There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method.
> Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required.
> This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
- 1
- 0
Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
by Werner Keil
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(a)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(a)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(a)lists.jboss.org> wrote:
>>
>>> Send cdi-dev mailing list submissions to
>>> cdi-dev(a)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(a)lists.jboss.org
>>>
>>> You can reach the person managing the list at
>>> cdi-dev-owner(a)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(a)oracle.com>
>>> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
>>> To: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
>>>
>> Message-ID: <39F78EFC-0E6D-4AAA-B81B-BF00DF9FBD74(a)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(a)gmail.com>
>>> wrote:
>>> >
>>>
>> > Hi,
>>> >
>>> >> On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves <
>>> antonio.goncalves(a)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/o...
>>> >
>>> > 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(a)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(a)gmail.com> wrote:
>>> >>> >
>>> >>> > 2015-11-16 14:54 GMT-08:00 Reza Rahman <reza.rahman(a)oracle.com>:
>>> >>> >> Responses in-line:
>>> >>> >>
>>> >>> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau <
>>> rmannibucau(a)gmail.com> wrote:
>>> >>> >>>
>>> >>> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman <reza.rahman(a)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(a)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(a)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(a)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(a)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/at...
>>>
>>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)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.
>
>
8 years, 5 months
- 1
- 0
Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
by Werner Keil
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(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)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(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)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(a)oracle.com>
> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
> To: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID: <39F78EFC-0E6D-4AAA-B81B-BF00DF9FBD74(a)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(a)gmail.com> wrote:
> >
> > Hi,
> >
> >> On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves <
> antonio.goncalves(a)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/o...
> >
> > 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(a)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(a)gmail.com> wrote:
> >>> >
> >>> > 2015-11-16 14:54 GMT-08:00 Reza Rahman <reza.rahman(a)oracle.com>:
> >>> >> Responses in-line:
> >>> >>
> >>> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau <
> rmannibucau(a)gmail.com> wrote:
> >>> >>>
> >>> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman <reza.rahman(a)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(a)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(a)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(a)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(a)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/at...
>
>
8 years, 5 months
- 2
- 1
Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
by Werner Keil
Looking at the EG of JSR 236 however, other than 2 JCP Award winners in the
member category (Doug Lea and Adam Bien, the latter did however admit when
he picked his award, he wasn't sure who nominated him, and that at least
when it comes to active involvement in JSRs he was far from active in any
of them;-) there are pretty much the "Big 3" IBM, Oracle Red Hat (in
alphabetical order) only in that EG.
So should Oracle prefer someone took the Spec Lead role for Java EE
Concurrency.next, who other than those Big 3 would be a suitable Spec Lead
or Co Spec Lead?
I know what it means, since I am also Spec Lead of an active JSR, but that
is more than enough until that's gone final. Sure, there are other
Individual or corporate members in this and other EE EGs who might be a
good fit for that aside from say the obvious Doug Lea;-)
Werner
On Tue, Nov 17, 2015 at 1:51 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)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(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)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 (Werner Keil)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 17 Nov 2015 15:17:58 +0100
> From: Werner Keil <werner.keil(a)gmail.com>
> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAAGawe1FFg7bJazj67gpXXEKBJ8Qu+v9yAxECaEdmgoTr2-hHQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Reza/all,
>
> Do you suggest, others could/should take over as Spec Lead of a new Java EE
> Concurrency JSR or just gather ideas and do brainstorming, similar to e.g.
> what happens in JSR 375?
>
> Werner
>
>
>
> On Tue, Nov 17, 2015 at 1:37 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
>
> > Send cdi-dev mailing list submissions to
> > cdi-dev(a)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(a)lists.jboss.org
> >
> > You can reach the person managing the list at
> > cdi-dev-owner(a)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 (Antonio Goncalves)
> > 3. Re: [PROPOSAL] further align CDI and EJB (arjan tijms)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Mon, 16 Nov 2015 18:55:04 -0500
> > From: Reza Rahman <reza.rahman(a)oracle.com>
> > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
> > To: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> > Message-ID: <ECA2AF54-612C-4495-A8D2-04092A0110BB(a)oracle.com>
> > Content-Type: text/plain; charset=utf-8
> >
> > 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(a)gmail.com
> >
> > wrote:
> > >
> > > 2015-11-16 14:54 GMT-08:00 Reza Rahman <reza.rahman(a)oracle.com>:
> > >> Responses in-line:
> > >>
> > >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau <
> rmannibucau(a)gmail.com>
> > wrote:
> > >>>
> > >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman <reza.rahman(a)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(a)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(a)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.
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 17 Nov 2015 14:44:35 +0100
> > From: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
> > To: Reza Rahman <reza.rahman(a)oracle.com>
> > Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> > Message-ID:
> > <
> > CA+ZZq98nGkMYUj5uEt7UuGHFcttdoi7zTiH_mWK5n_9zy2EaNQ(a)mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > HI all,
> >
> > This discussion comes back on and off.
> >
> > At the last F2F meeting, we talked about having @Startup and @Shutdown in
> > JSR 250. Talking to Bill and Linda, they don't seem reluctant to update
> the
> > spec. No need to have @DependsOn as we will use @Priority with @Startup.
> >
> > @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.
> >
> > 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(a)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(a)gmail.com
> > >
> > > wrote:
> > > >
> > > > 2015-11-16 14:54 GMT-08:00 Reza Rahman <reza.rahman(a)oracle.com>:
> > > >> Responses in-line:
> > > >>
> > > >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau <
> > rmannibucau(a)gmail.com>
> > > wrote:
> > > >>>
> > > >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman <reza.rahman(a)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(a)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(a)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(a)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>
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> >
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/3399b142/at...
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Tue, 17 Nov 2015 15:03:32 +0100
> > From: arjan tijms <arjan.tijms(a)gmail.com>
> > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
> > To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> > Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> > Message-ID:
> > <CAE=-
> > AhAhn2W-yvJgGHQdv7PNS2jjGbJouxNirYOKyekuy9s3mQ(a)mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Hi,
> >
> > On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves <
> > antonio.goncalves(a)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/o...
> >
> > 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(a)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(a)gmail.com>
> > >> wrote:
> > >> >
> > >> > 2015-11-16 14:54 GMT-08:00 Reza Rahman <reza.rahman(a)oracle.com>:
> > >> >> Responses in-line:
> > >> >>
> > >> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau <
> > >> rmannibucau(a)gmail.com> wrote:
> > >> >>>
> > >> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman <reza.rahman(a)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(a)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(a)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(a)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>
> > >
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev(a)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/c074f5ae/at...
> >
> > ------------------------------
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)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.
> >
> > End of cdi-dev Digest, Vol 60, Issue 13
> > ***************************************
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/b1fb79c2/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.
>
> End of cdi-dev Digest, Vol 60, Issue 14
> ***************************************
>
8 years, 5 months
- 2
- 1
Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
by Werner Keil
Reza/all,
Do you suggest, others could/should take over as Spec Lead of a new Java EE
Concurrency JSR or just gather ideas and do brainstorming, similar to e.g.
what happens in JSR 375?
Werner
On Tue, Nov 17, 2015 at 1:37 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)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(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)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 (Antonio Goncalves)
> 3. Re: [PROPOSAL] further align CDI and EJB (arjan tijms)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 16 Nov 2015 18:55:04 -0500
> From: Reza Rahman <reza.rahman(a)oracle.com>
> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
> To: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID: <ECA2AF54-612C-4495-A8D2-04092A0110BB(a)oracle.com>
> Content-Type: text/plain; charset=utf-8
>
> 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(a)gmail.com>
> wrote:
> >
> > 2015-11-16 14:54 GMT-08:00 Reza Rahman <reza.rahman(a)oracle.com>:
> >> Responses in-line:
> >>
> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com>
> wrote:
> >>>
> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman <reza.rahman(a)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(a)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(a)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.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 17 Nov 2015 14:44:35 +0100
> From: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
> To: Reza Rahman <reza.rahman(a)oracle.com>
> Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CA+ZZq98nGkMYUj5uEt7UuGHFcttdoi7zTiH_mWK5n_9zy2EaNQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> HI all,
>
> This discussion comes back on and off.
>
> At the last F2F meeting, we talked about having @Startup and @Shutdown in
> JSR 250. Talking to Bill and Linda, they don't seem reluctant to update the
> spec. No need to have @DependsOn as we will use @Priority with @Startup.
>
> @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.
>
> 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(a)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(a)gmail.com
> >
> > wrote:
> > >
> > > 2015-11-16 14:54 GMT-08:00 Reza Rahman <reza.rahman(a)oracle.com>:
> > >> Responses in-line:
> > >>
> > >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau <
> rmannibucau(a)gmail.com>
> > wrote:
> > >>>
> > >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman <reza.rahman(a)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(a)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(a)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(a)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>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/3399b142/at...
>
> ------------------------------
>
> Message: 3
> Date: Tue, 17 Nov 2015 15:03:32 +0100
> From: arjan tijms <arjan.tijms(a)gmail.com>
> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
> To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAE=-
> AhAhn2W-yvJgGHQdv7PNS2jjGbJouxNirYOKyekuy9s3mQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves <
> antonio.goncalves(a)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/o...
>
> 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(a)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(a)gmail.com>
> >> wrote:
> >> >
> >> > 2015-11-16 14:54 GMT-08:00 Reza Rahman <reza.rahman(a)oracle.com>:
> >> >> Responses in-line:
> >> >>
> >> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau <
> >> rmannibucau(a)gmail.com> wrote:
> >> >>>
> >> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman <reza.rahman(a)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(a)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(a)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(a)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>
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)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/c074f5ae/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.
>
> End of cdi-dev Digest, Vol 60, Issue 13
> ***************************************
>
8 years, 5 months
- 2
- 1
[PROPOSAL] further align CDI and EJB
by Mark Struberg
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
8 years, 5 months
- 9
- 17
[JBoss JIRA] (CDI-572) support JSR-303 bean validation in CDI beans
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-572?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-572:
----------------------------------------
Cdi-bval current integration is in bval. -1 to have a cycle in term of dependency.
Also would look like cdi would become the new ejb taking ee integration . We should move forward letting the integration in bval and adding the needed API IMHO.
> support JSR-303 bean validation in CDI beans
> --------------------------------------------
>
> Key: CDI-572
> URL: https://issues.jboss.org/browse/CDI-572
> Project: CDI Specification Issues
> Issue Type: Epic
> Reporter: Mark Struberg
>
> Consider a bean like
> {code}
> @SessionScoped
> public class CurrentUser {
> @javax.validation.constraint.NotNull
> @javax.validation.constraint.Length(10)
> private String userId;
> ...
> }
> {code}
> We could easily check this and invoke JSR-303 (if available) in the Producer<T>. Please note that for a custom Producer they have to care for it themselves.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
- 1
- 0