Thread safety of SeContainer and SeContainerInitializer
by Laird Nelson
Are SeContainer and SeContainerInitializer safe for concurrent use by
multiple threads? The string "concurren" shows up only four times in the
2.0 specification but not in this context.
I'm most interested in whether it is guaranteed that one thread may call
SeContainer::initialize and another may call SeContainer::close.
I'm assuming that this is *not* guaranteed.
Best,
Laird
9 years
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.
9 years
Clarification of Any qualifier
by John Ament
Hi,
So an issue came up with OWB and programmatic look up.
In OWB, when you use CDI.current() the instance you get back includes an any qualifier. I do a programmatic look up of a custom bean that is registered with just a single qualifier - @Database. OWB looks up an instance that has qualifiers Any and Database, but cannot find any because my bean doesn't declare it.
My interpretation of http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#builtin_qualifiers is that the container (OWB) should be adding @Any to my custom bean even if I don't specify it. Is that the proper interpretation? Or am I required to add @Any to my bean?
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.
9 years
BeanConfigurator and ProducerConfigurator consistency
by Antonin Stefanutti
Hi all,
Is there any reason I’m missing it is possible to get an Instance in BeanConfigurator produceWith (resp. disposeWith) while it’s not in ProducerConfigurator produceWith (resp. disposeWith)?
BeanConfigurator:
<U extends T> BeanConfigurator<U> produceWith(Function<Instance<Object>, U> callback);
BeanConfigurator<T> disposeWith(BiConsumer<T, Instance<Object>> callback);
ProducerConfigurator:
<U extends T> ProducerConfigurator<T> produceWith(Function<CreationalContext<U>, U> callback);
ProducerConfigurator<T> disposeWith(Consumer<T> callback);
Besides, wouldn’t that be more concise in most use cases to provide the equivalent without the Instance parameter in BeanConfigurator (as it was before CDI 2.0.Beta1)?
Thanks,
Antonin
9 years
[JBoss JIRA] (CDI-676) Clarify missing class behavior
by John Ament (JIRA)
John Ament created CDI-676:
------------------------------
Summary: 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
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)
9 years
[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 updated CDI-674:
---------------------------
Description:
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.
was:
The behavior of CDI.current() is not deterministic. It uses {{findAny()}}. It should use {{findFirst()}}
{{.findAny().orElseThrow(() -> new IllegalStateException("Unable to access CDI"));}}
> 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)
9 years
[JBoss JIRA] (CDI-675) Clarify exception thrown when CDI could not be looked up
by John Ament (JIRA)
John Ament created CDI-675:
------------------------------
Summary: Clarify exception thrown when CDI could not be looked up
Key: CDI-675
URL: https://issues.jboss.org/browse/CDI-675
Project: CDI Specification Issues
Issue Type: Bug
Reporter: John Ament
If you are unable to look up CDI the exception thrown is {{Unable to access CDI}}. A more correct exception would be {{Unable to locate a CDIProvider for the current bean archive}} (or something along those lines)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (CDI-674) Non-deterministic behavior of CDI.current()
by John Ament (JIRA)
John Ament created CDI-674:
------------------------------
Summary: Non-deterministic behavior of CDI.current()
Key: CDI-674
URL: https://issues.jboss.org/browse/CDI-674
Project: CDI Specification Issues
Issue Type: Bug
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 message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
