[JBoss JIRA] (CDI-586) Add spec text for new Literals
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-586:
----------------------------------------
Summary: Add spec text for new Literals
Key: CDI-586
URL: https://issues.jboss.org/browse/CDI-586
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Antoine Sabot-Durand
CDI-485 introduced literals in the API. We should add some information about them in the spec as well
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (CDI-519) Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-519?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-519:
----------------------------------
I've sent a pull request with solution (1).
> Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object
> ------------------------------------------------------------------------------------------------------
>
> Key: CDI-519
> URL: https://issues.jboss.org/browse/CDI-519
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Fix For: 2.0 (discussion)
>
>
> 5.6.1. The Instance interface:
> {quote}
> The method destroy() instructs the container to destroy the instance. The bean instance passed to destroy() should be *a dependent scoped bean instance*, or...
> {quote}
> I think this should be more obvious. E.g. this wouldn't work correctly even though it doesn't violate the spec:
> {code:java}
> @Dependent
> class Bar {
> }
> class Foo {
> @Inject
> Instance<Bar> instance;
> void ping() {
> instance.destroy(CDI.current().select(Bar.class).get());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
CompletableFuture vs. CompletionStage
by Reza Rahman
I have forwarded this issue to the Java EE platform EG for review. My inclination now is to simply leave this alone with a final earnest request to kindly think carefully about this before finalizing and getting this into the real world. Please keep in mind that the average developer is not that skilled and looks to resources on the web routinely for answers. All those resources are going to immediately point to CompletableFuture, not some obscure superclass.
All I am trying to do is help design an API that is not going to immediately become difficult for the average end developer to understand and use. It's rather unfortunate that I am already feeling fed up in that simple effort to provide feedback.
Anyway I am now basically done with this. Unfortunately I have far more urgent matters for Java EE 7 and Java EE 8 to deal with. If I have time I'll look at some more of the CDI 2 work and provide feedback if I can manage time.
> On Mar 7, 2016, at 2:53 PM, Reza Rahman <reza_rahman(a)lycos.com> wrote:
> Argue
> Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API.
>
> As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures?
>
> Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API.
>
>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com> wrote:
>>
>>
>> 2016-03-07 20:35 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com>:
>>> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors.
>>>
>>> Basically this means CompletableFutures are already pretty Java EE ready.
>>>
>>> If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected?
>>
>> Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*.
>>
>>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman <reza_rahman(a)lycos.com> wrote:
>>>>
>>>> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API.
>>>>
>>>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau <rmannibucau(a)gmail.com> wrote:
>>>>>
>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba <mkouba(a)redhat.com>:
>>>>>>
>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a):
>>>>>>>
>>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" <mkouba(a)redhat.com
>>>>>>> <mailto:mkouba@redhat.com>> a écrit :
>>>>>>> >
>>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a):
>>>>>>> >
>>>>>>> >> Hi guys,
>>>>>>> >>
>>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities,
>>>>>>> >> can we move back to CompletionFuture?
>>>>>>> >>
>>>>>>> >> It would allow for instance:
>>>>>>> >>
>>>>>>> >> // doesn't work with CompletionStage
>>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...))
>>>>>>> >> .then(...)
>>>>>>> >
>>>>>>> >
>>>>>>> > Well, this should work if the underlying CompletionStage impl
>>>>>>> supports toCompletableFuture(), i.e. in Weld 3:
>>>>>>> >
>>>>>>>
>>>>>>> Yes but it is not natural to convert it IMO = we can do better
>>>>>>>
>>>>>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(),
>>>>>>> event2.fireAsync(...).toCompletableFuture())
>>>>>>> >
>>>>>>> > AFAIK the default async execution facility of CompletableFuture is
>>>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the
>>>>>>> CompletionStage interface allows us to wrap the async calls without the
>>>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function<? super
>>>>>>> T, ? extends U>)) and supply a default one provided by the impl.
>>>>>>> >
>>>>>>>
>>>>>>> Should use the pool in which the evznt is fired then "then step" is
>>>>>>> synchronous is my sample so all is decided at fire time
>>>>>>
>>>>>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist).
>>>>>
>>>>> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;).
>>>>>
>>>>> That said I agree on the state switching the pool is better but with these 2 notes:
>>>>>
>>>>> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools
>>>>> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml)
>>>>>
>>>>>>>
>>>>>>> >
>>>>>>> >>
>>>>>>> >> Romain Manni-Bucau
>>>>>>> >> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>>>>>> >> <http://rmannibucau.wordpress.com> | Github
>>>>>>> >> <https://github.com/rmannibucau> | LinkedIn
>>>>>>> >> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>>>>> >> <http://www.tomitribe.com>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> _______________________________________________
>>>>>>> >> cdi-dev mailing list
>>>>>>> >> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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.
>>>>>>> >>
>>>>>>> >
>>>>>>> > --
>>>>>>> > Martin Kouba
>>>>>>> > Software Engineer
>>>>>>> > Red Hat, Czech Republic
>>>>>>
>>>>>> --
>>>>>> Martin Kouba
>>>>>> Software Engineer
>>>>>> Red Hat, Czech Republic
>>>>>
>>>>> _______________________________________________
>>>>> 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.
>>
8 years, 9 months
[JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.sy... ]
arjan tijms commented on CDI-580:
---------------------------------
What about extensions adding {{Bean<T>}} instances via {{AfterBeanDiscovery.addBean}}? The above proposal looks like it could work for them, but not sure.
Is there any existing way really to add interceptors to manually created {{Bean<T>}} instances?
> Allow interceptors and decorators to be applied to the return value of a producer method
> ----------------------------------------------------------------------------------------
>
> Key: CDI-580
> URL: https://issues.jboss.org/browse/CDI-580
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 2.0-EDR1
> Reporter: Mark Struberg
>
> Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods.
> if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object.
> We should explore ways to allow this somehow.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
