[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
[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
[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
[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
[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
[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
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