[
https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin...
]
Laird Nelson edited comment on WFLY-11858 at 3/20/19 1:34 PM:
--------------------------------------------------------------
Yes, the scope of any given {{JNDIBean}} should continue to be {{Singleton}}. But the
{{AbstractBean<InitialContext>}} subclass instance's scope should be
{{Dependent}}, I think.
My guess (I don't really know, as I'm not up on the sophisticated classloading
involved in .ear files here) is that any solution that allows the {{InitialContext}} to be
created at the point that the {{lookup}} call is made will work. So it would seem that in
general it is not OK to have a single instance of {{InitialContext}} floating around, i.e.
I believe that the scope of the {{AbstractBean<InitialContext>}} subclass should be
{{Dependent}}, not {{Singleton}}. I've updated this in my other (approved so far)
[
PR|https://github.com/jbosstm/narayana/pull/1403].
Making the {{JNDIBean}} "use directly the initial context with {{new
InitialContext().lookup(this.name)}}" is exactly the same as placing the
{{AbstractBean<InitialContext>}} in {{Dependent}} scope. I personally prefer going
through the bean here as it allows user-supplied {{InitialContext}} bean implementations.
was (Author: ljnelson):
My guess (I don't really know, as I'm not up on the sophisticated classloading
involved in .ear files here) is that any solution that allows the {{InitialContext}} to be
created at the point that the {{lookup}} call is made will work. So it would seem that in
general it is not OK to have a single instance of {{InitialContext}} floating around, i.e.
I believe that the scope of the {{AbstractBean<InitialContext>}} subclass should be
{{Dependent}}, not {{Singleton}}. I've updated this in my other (approved so far)
[
PR|https://github.com/jbosstm/narayana/pull/1403].
Making the {{JNDIBean}} "use directly the initial context with {{new
InitialContext().lookup(this.name)}}" is exactly the same as placing the
{{AbstractBean<InitialContext>}} in {{Dependent}} scope. I personally prefer going
through the bean here as it allows user-supplied {{InitialContext}} bean implementations.
[Wildfly16] CDI fails to inject InitialContext during startup
-------------------------------------------------------------
Key: WFLY-11858
URL:
https://issues.jboss.org/browse/WFLY-11858
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, Transactions
Affects Versions: 16.0.0.Final
Reporter: Rakesh K. Cherukuri
Assignee: Matej Novotny
Priority: Major
Attachments: stacktrace.log
We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine,
16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
_WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
In our application, a bootstrap servlet startsup services (Stateless EJBs) during server
startup. During this process the server fails to start with above error.
Basically CDI is not able to find the appropriate InitialContext bean *intermittently*.
This is not failing in our application code but in the wildfly libraries itself.
Any pointers on this will be helpful. Don't want to end up with startup issues in
stage/production :)
Unfortunately my efforts to come up with a simplified maven module to showcase the error
didn't succeed. So, please let me know if any further information is required and i
will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)