[JBoss JIRA] (CDI-676) Clarify missing class behavior
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-676?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-676:
-------------------------------------
Fix Version/s: 2.1 (Discussion)
> Clarify missing class behavior
> ------------------------------
>
> Key: CDI-676
> URL: https://issues.jboss.org/browse/CDI-676
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: John Ament
> Fix For: 2.1 (Discussion)
>
>
> The spec needs to clarify missing class behavior. Say that I have an extension that is purposely dependent on a class being present (or not present). In Weld, that extension will be ignored due to classloader error. OWB on the other hand throws a TypeNotPresentException.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (CDI-677) Specify the default scope for beans created from BeanConfigurator
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-677?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-677:
----------------------------------------
Assignee: Antoine Sabot-Durand
> Specify the default scope for beans created from BeanConfigurator
> -----------------------------------------------------------------
>
> Key: CDI-677
> URL: https://issues.jboss.org/browse/CDI-677
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0 .Final
>
>
> Right now, this is undefined. However, it might me useful to specify that the scope is defaulted if not set by {{BeanConfigurator.scope(Class<? extends Annotation>)}}. The default scope could be either {{@Dependent}} or determined by the rules from "2.4.4. Default scope" (i.e. including default scopes from stereotypes).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (CDI-673) Revisit manipulation with InjectionPoint(s) in ProducerConfigurator
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-673?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-673:
----------------------------------------
Assignee: Antoine Sabot-Durand
> Revisit manipulation with InjectionPoint(s) in ProducerConfigurator
> -------------------------------------------------------------------
>
> Key: CDI-673
> URL: https://issues.jboss.org/browse/CDI-673
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 2.0.Beta1
> Reporter: Matej Novotny
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0 .Final
>
>
> Currently, {{ProducerConfigurator}} allows to add or replace injection points.
> Firstly, {{addInjectionPoints}} - if you think about this, it does not really make sense. You already have producer method defined, it has some body and uses its parameter within that method body. So if you add any IP, the method would not make use of it anyway.
> Secondly, replacing IP with {{injectionPoints}} - now this seems useful, but in fact it won't work. As it stands, replacing them in Weld only affects validation phase, not the injection itself. This means that if you have following producer:
> {code}
> @Produces public Foo produceIt (@Default Bar) { //do stuff}
> {code}
> and meant to replace the parameter with, say, {{@MyCustom Bar}}, you would in the end still end up with {{@Default Bar}}.
> The problem here is that [spec|http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#injectiontarget] states the following:
> bq. Implementations of Producer and InjectionTarget must ensure that the set of injection points returned by getInjectionPoints() are injected by produce() or inject().
> However, spec says nothing about what should happen when you change implementation's set on IPs later.
> Note: I think we bumped into similar issue with {{BeanConfigurator}} (or some other configurator as well). I will try to dig up that discussion.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (CDI-671) SPI element related to Instance are missing info about their qualifier
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-671?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-671:
----------------------------------------
Assignee: Antoine Sabot-Durand
> SPI element related to Instance are missing info about their qualifier
> ----------------------------------------------------------------------
>
> Key: CDI-671
> URL: https://issues.jboss.org/browse/CDI-671
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Javadoc and API
> Affects Versions: 2.0.Beta1
> Reporter: Antoine Sabot-Durand
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0 .Final
>
>
> Following elements are related to {{Instance}} interface:
> * {{CDI}} class implements {{Instance}}
> * {{SeContainer}} extends {{Instance}}
> * {{BeanManager.createInstance()}} returns and {{Instance}} object
> If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier.
> We should state in Javadoc and spec that these Instance behaves like an injected instance with {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (CDI-674) Non-deterministic behavior of CDI.current()
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-674?page=com.atlassian.jira.plugin.sy... ]
John Ament closed CDI-674.
--------------------------
Resolution: Duplicate Issue
Already fixed, tag was out of date.
> Non-deterministic behavior of CDI.current()
> -------------------------------------------
>
> Key: CDI-674
> URL: https://issues.jboss.org/browse/CDI-674
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 2.0.Beta1
> Reporter: John Ament
>
> The behavior of CDI.current() is not deterministic. It uses {{findAny()}}. It should use {{findFirst()}}
> {{.findAny().orElseThrow(() -> new IllegalStateException("Unable to access CDI"));}}
> This also seems to go against what the javadocs say
> bq. otherwise the first provider which can access the container is used.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
Regression issue with CDI.current
by John Ament
It seems that CDI.current is failing in places where it used to succeed.
The scenarios seem to all be the same - JAR files that don't contain a beans.xml when used in SE mode can no longer invoke CDI.current. In the past they could.
Caused by: java.lang.IllegalStateException: Unable to access CDI
at javax.enterprise.inject.spi.CDI.lambda$getCDIProvider$1(CDI.java:75)
at java.util.Optional.orElseThrow(Optional.java:290)
at javax.enterprise.inject.spi.CDI.getCDIProvider(CDI.java:75)
at javax.enterprise.inject.spi.CDI.current(CDI.java:51)
at ws.ament.hammock.rest.resteasy.Cdi11InjectorFactory.lookupBeanManager(Cdi11InjectorFactory.java:32)
I'll raise an issue, but not sure since this was something not specified previously.
John
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
7 years, 11 months
Meeting on today?
by John Ament
All,
Is today's meeting on?
John
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
7 years, 11 months