September 2017 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-194) Allow AnnotatedType for a given Bean to be obtained

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.sy... ] Matej Novotny updated CDI-194: ------------------------------ Affects Version/s: 2.0 .Final > Allow AnnotatedType for a given Bean to be obtained > --------------------------------------------------- > > Key: CDI-194 > URL: https://issues.jboss.org/browse/CDI-194 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0, 2.0 .Final > Reporter: Jozef Hartinger > Fix For: 2.1 (Discussion) > > > See Stuart's comment on CDI-83. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-194) Allow AnnotatedType for a given Bean to be obtained

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.sy... ] Matej Novotny updated CDI-194: ------------------------------ Fix Version/s: 2.1 (Discussion) (was: TBD) > Allow AnnotatedType for a given Bean to be obtained > --------------------------------------------------- > > Key: CDI-194 > URL: https://issues.jboss.org/browse/CDI-194 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Jozef Hartinger > Fix For: 2.1 (Discussion) > > > See Stuart's comment on CDI-83. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-194) Allow AnnotatedType for a given Bean to be obtained

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.sy... ] Matej Novotny edited comment on CDI-194 at 9/4/17 8:05 AM: ----------------------------------------------------------- I think we should re-open discussion on this issue for 2.1 The use case Stuart explained still makes sense and remains unresolved in CDI. Also, with CDI-716 we would be able to tell custom beans from "normal" ones, hence making this a bit cleaner. was (Author: manovotn): I think we should re-open discussion on this issue for 2.1 The use case Stuart explained still makes sense and is a lackluster in CDI. Also, with CDI-716 we would be able to tell custom beans from "normal" ones, hence making this a bit cleaner. > Allow AnnotatedType for a given Bean to be obtained > --------------------------------------------------- > > Key: CDI-194 > URL: https://issues.jboss.org/browse/CDI-194 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Jozef Hartinger > Fix For: TBD > > > See Stuart's comment on CDI-83. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-194) Allow AnnotatedType for a given Bean to be obtained

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.sy... ] Matej Novotny commented on CDI-194: ----------------------------------- I think we should re-open discussion on this issue for 2.1 The use case Stuart explained still makes sense and is a lackluster in CDI. Also, with CDI-716 we would be able to tell custom beans from "normal" ones, hence making this a bit cleaner. > Allow AnnotatedType for a given Bean to be obtained > --------------------------------------------------- > > Key: CDI-194 > URL: https://issues.jboss.org/browse/CDI-194 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Jozef Hartinger > Fix For: TBD > > > See Stuart's comment on CDI-83. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-716) Allow to recognize custom Bean at runtime

by Matej Novotny (JIRA)

Matej Novotny created CDI-716: --------------------------------- Summary: Allow to recognize custom Bean at runtime Key: CDI-716 URL: https://issues.jboss.org/browse/CDI-716 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans Affects Versions: 2.0 .Final Reporter: Matej Novotny At the moment, they only way to tell custom bean (created via {{BeanConfigurator}} or class implementing {{javax.enterprise.inject.spi.Bean}}) from "standard" one is to have an extension and listen to {{ProcessSyntheticBean}}. This is good enough if it's sufficient to tell the difference at bootstrap time. However, at runtime, there is no way to do this. We could add a method to {{javax.enterprise.inject.spi.Bean}} which would allow to tell the difference. The name of the method could be {{isCustom()}} or {{getKind()}}. Generally, there should be no need to differentiate between custom/standard beans, but when digging deeper, it doesn't hurt to know. Putting this into {{Bean}} interface keeps it deep enough while still giving the information. One of the use cases for this would be CDI-194, which could be "nicely" implemented (avoiding {{null}} values), if there was a way to recognize custom bean. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-715) Transitive stereotype declarations - clarify conflicting default scopes

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-715?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-715: ----------------------------- Summary: Transitive stereotype declarations - clarify conflicting default scopes (was: Transitive stereotype declarations - clarify conflicting scopes) > Transitive stereotype declarations - clarify conflicting default scopes > ----------------------------------------------------------------------- > > Key: CDI-715 > URL: https://issues.jboss.org/browse/CDI-715 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Priority: Minor > > Stereotype declarations are transitive. However, the spec is not clear what happens if a stereotype declares a default scope and also a second stereotype which also declares a default scope. Only _"If a stereotype declares more than one scope, the container automatically detects the problem and treats it as a definition error."_ is defined. > > Weld currently does merge the stereotypes and throws {{DefinitionException}} if NOT all stereotypes specify the same scope _and_ the bean does NOT declare a scope (this makes sense imho). > Note that this is not a problem for {{@Named}}, {{@Alternative}} and interceptor bindings. > Any {{@Alternative}} makes a bean an alternative. Any {{@Named}} means the name is defaulted. All bindings are added to the set. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-715) Transitive stereotype declarations - clarify conflicting scopes

by Martin Kouba (JIRA)

Martin Kouba created CDI-715: -------------------------------- Summary: Transitive stereotype declarations - clarify conflicting scopes Key: CDI-715 URL: https://issues.jboss.org/browse/CDI-715 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba Priority: Minor Stereotype declarations are transitive. However, the spec is not clear what happens if a stereotype declares a default scope and also a second stereotype which also declares a default scope. Only _"If a stereotype declares more than one scope, the container automatically detects the problem and treats it as a definition error."_ is defined. Weld currently does merge the stereotypes and throws {{DefinitionException}} if NOT all stereotypes specify the same scope _and_ the bean does NOT declare a scope (this makes sense imho). Note that this is not a problem for {{@Named}}, {{@Alternative}} and interceptor bindings. Any {{@Alternative}} makes a bean an alternative. Any {{@Named}} means the name is defaulted. All bindings are added to the set. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-714) No way to access the underlying bean in a producer when using BeanConfigurator

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-714?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-714: ---------------------------------- That's a good point. However, note that configurators were not designed to completely replace the original methods and to cover every possible case but to help with most common tasks. In this case, it seems the only way to use the {{getInjectableReference()}} workaround would be to lookup the bean inside the callback function. > No way to access the underlying bean in a producer when using BeanConfigurator > ------------------------------------------------------------------------------ > > Key: CDI-714 > URL: https://issues.jboss.org/browse/CDI-714 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > I was reusing an example the Weld guys pointed me at. > {code} > InjectionPoint ip = (InjectionPoint)bm.getInjectableReference(new EmptyInjectionPoint(be...), cc); > {code} > The problem is that I'm using the configurator to create the bean, and the resulting function for the producer doesn't have access to the bean that was created. > {code} > abd.addBean() > .addQualifiers(new ClaimLiteral("", Claims.UNKNOWN)) > .addType(type) > .scope(Dependent.class) > .createWith(ClaimProducer.INSTANCE); > {code} > So because of this, I have no way to get the injection point. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-714) No way to access the underlying bean in a producer when using BeanConfigurator

by John Ament (JIRA)

John Ament created CDI-714: ------------------------------ Summary: No way to access the underlying bean in a producer when using BeanConfigurator Key: CDI-714 URL: https://issues.jboss.org/browse/CDI-714 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament I was reusing an example the Weld guys pointed me at. {code} InjectionPoint ip = (InjectionPoint)bm.getInjectableReference(new EmptyInjectionPoint(be...), cc); {code} The problem is that I'm using the configurator to create the bean, and the resulting function for the producer doesn't have access to the bean that was created. {code} abd.addBean() .addQualifiers(new ClaimLiteral("", Claims.UNKNOWN)) .addType(type) .scope(Dependent.class) .createWith(ClaimProducer.INSTANCE); {code} So because of this, I have no way to get the injection point. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

Re: [cdi-dev] Attributes on scope annotations

by Matej Novotny

Let's keep this conversation on CDI-dev list, please (adding back to CC). Hmm, I think it is not forbidden to add another plain java annotation. However, having it working as scope and cdi qualifier in the same time won't work. Matej ----- Original Message ----- > From: "Todor Boev" <rinsvind(a)gmail.com> > To: "Matej Novotny" <manovotn(a)redhat.com> > Sent: Friday, September 1, 2017 12:33:54 PM > Subject: Re: [cdi-dev] Attributes on scope annotations > > Thank you for the timely replay, > > I need portable behavior, so the other option I am considering is to > meta-annotate the scope annotation with the additional information I need. > The issues are now: is this allowed, can in principle my custom > meta-annotation be a qualifier. Probably a plain annotation will be > sufficient, but I may need to have it do double-duty as a qualifier as well. > > Thanks in advance, > Todor > > On Fri, Sep 1, 2017 at 11:49 AM, Matej Novotny <manovotn(a)redhat.com> wrote: > > > Hello Todor, > > > > From CDI specification 2.0 section 2.4.2 Defining new scopes[1]: > > > > "A scope type must not have any attributes. If a scope type has attributes > > non-portable behavior results." > > > > Matej > > > > ____________________________________________________________ > > _______________- > > [1] http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html# > > defining_new_scope_type > > > > > > > > ----- Original Message ----- > > > From: "Todor Boev" <rinsvind(a)gmail.com> > > > To: cdi-dev(a)lists.jboss.org > > > Sent: Friday, September 1, 2017 9:51:47 AM > > > Subject: [cdi-dev] Attributes on scope annotations > > > > > > Hello, > > > > > > Is it against the CDI 2.0 specification to have attributes on a scope > > > annotation? If not is this a corner case that may become forbidden or > > simply > > > not be taken into account in future versions of the specification? > > > > > > E.g. @ComponentScoped("my-component") > > > > > > With Weld 3.0.0 I was able to successfully use such annotations. > > > > > > Regards, > > > Todor > > > > > > > > > _______________________________________________ > > > 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. > > >

7 years, 1 month

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2017