[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Rakesh K. Cherukuri (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Rakesh K. Cherukuri edited comment on WFLY-11858 at 3/18/19 6:41 AM:
---------------------------------------------------------------------
Flow: During server startup,
Servlet.init() -> SingletonEjbX.serviceMethod() -> StatelessEJB.doService() -> SingletonEjbY.performActualService()
Based on stacktrace, the client call to SingletonEjbY.performActualService() fails as server is not able to construct the component/EJB. The underlying cause is that the CDI unable to find the InitialContext
Deployment:
EAR
____ WAR
____ lib/<jars-with-ejbs>
During startup, only one interceptor is called that makes sure that a transaction is associated (creates a new TX if one is not associated). The interceptor is called for SingletonEjbX.serviceMethod. It uses TransactionSynchronizationRegistry in the process.
My two cents: From stack trace its pretty clear that this interceptor has done its job properly as the failure happens between _StatelessEJB.doService() -> SingletonEjbY.performActualService()_
was (Author: rakcheru):
Flow: During server startup,
Servlet.init() -> SingletonEjbX.serviceMethod -> StatelessEJB.doService() -> SingletonEjbY.performActualService()
_________________^
____________Interceptor
Based on stacktrace, the client call to SingletonEjbY.performActualService() fails as server is not able to construct the component/EJB. The underlying cause is that the CDI unable to find the InitialContext
Deployment:
EAR
____ WAR
____ lib/<jars-with-ejbs>
During startup, only one interceptor is called that makes sure that a transaction is associated (creates a new TX if one is not associated). It uses TransactionSynchronizationRegistry in the process.
My two cents: From stack trace its pretty clear that this interceptor has done its job properly as the failure happens between _StatelessEJB.doService() -> SingletonEjbY.performActualService()_
> [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)
7 years, 4 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Rakesh K. Cherukuri (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Rakesh K. Cherukuri edited comment on WFLY-11858 at 3/18/19 6:40 AM:
---------------------------------------------------------------------
Flow: During server startup,
Servlet.init() -> SingletonEjbX.serviceMethod -> StatelessEJB.doService() -> SingletonEjbY.performActualService()
_________________^
____________Interceptor
Based on stacktrace, the client call to SingletonEjbY.performActualService() fails as server is not able to construct the component/EJB. The underlying cause is that the CDI unable to find the InitialContext
Deployment:
EAR
____ WAR
____ lib/<jars-with-ejbs>
During startup, only one interceptor is called that makes sure that a transaction is associated (creates a new TX if one is not associated). It uses TransactionSynchronizationRegistry in the process.
My two cents: From stack trace its pretty clear that this interceptor has done its job properly as the failure happens between _StatelessEJB.doService() -> SingletonEjbY.performActualService()_
was (Author: rakcheru):
Flow: During server startup,
Servlet.init() -> SingletonEjbX.serviceMethod -> StatelessEJB.doService() -> SingletonEjbY.performActualService()
_________________^
Interceptor
Based on stacktrace, the client call to SingletonEjbY.performActualService() fails as server is not able to construct the component/EJB. The underlying cause is that the CDI unable to find the InitialContext
Deployment:
EAR
____ WAR
____ lib/<jars-with-ejbs>
During startup, only one interceptor is called that makes sure that a transaction is associated (creates a new TX if one is not associated). It uses TransactionSynchronizationRegistry in the process.
My two cents: From stack trace its pretty clear that this interceptor has done its job properly as the failure happens between _StatelessEJB.doService() -> SingletonEjbY.performActualService()_
> [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)
7 years, 4 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Rakesh K. Cherukuri (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Rakesh K. Cherukuri edited comment on WFLY-11858 at 3/18/19 6:39 AM:
---------------------------------------------------------------------
Flow: During server startup,
Servlet.init() -> SingletonEjbX.serviceMethod -> StatelessEJB.doService() -> SingletonEjbY.performActualService()
_________________^
Interceptor
Based on stacktrace, the client call to SingletonEjbY.performActualService() fails as server is not able to construct the component/EJB. The underlying cause is that the CDI unable to find the InitialContext
Deployment:
EAR
____ WAR
____ lib/<jars-with-ejbs>
During startup, only one interceptor is called that makes sure that a transaction is associated (creates a new TX if one is not associated). It uses TransactionSynchronizationRegistry in the process.
My two cents: From stack trace its pretty clear that this interceptor has done its job properly as the failure happens between _StatelessEJB.doService() -> SingletonEjbY.performActualService()_
was (Author: rakcheru):
Flow: During server startup,
Servlet.init() -> SingletonEjbX.serviceMethod -> StatelessEJB.doService() -> SingletonEjbY.performActualService()
^
Interceptor
Based on stacktrace, the client call to SingletonEjbY.performActualService() fails as server is not able to construct the component/EJB. The underlying cause is that the CDI unable to find the InitialContext
Deployment:
EAR
____ WAR
____ lib/<jars-with-ejbs>
During startup, only one interceptor is called that makes sure that a transaction is associated (creates a new TX if one is not associated). It uses TransactionSynchronizationRegistry in the process.
My two cents: From stack trace its pretty clear that this interceptor has done its job properly as the failure happens between _StatelessEJB.doService() -> SingletonEjbY.performActualService()_
> [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)
7 years, 4 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Rakesh K. Cherukuri (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Rakesh K. Cherukuri edited comment on WFLY-11858 at 3/18/19 6:38 AM:
---------------------------------------------------------------------
Flow: During server startup,
Servlet.init() -> SingletonEjbX.serviceMethod -> StatelessEJB.doService() -> SingletonEjbY.performActualService()
^
Interceptor
Based on stacktrace, the client call to SingletonEjbY.performActualService() fails as server is not able to construct the component/EJB. The underlying cause is that the CDI unable to find the InitialContext
Deployment:
EAR
-- WAR
-- lib/<jars-with-ejbs>
During startup, only one interceptor is called that makes sure that a transaction is associated (creates a new TX if one is not associated). It uses TransactionSynchronizationRegistry in the process.
My two cents: From stack trace its pretty clear that this interceptor has done its job properly as the failure happens between _StatelessEJB.doService() -> SingletonEjbY.performActualService()_
was (Author: rakcheru):
Flow: During server startup,
Servlet.init() -> SingletonEjbX.serviceMethod -> StatelessEJB.doService() -> SingletonEjbY.performActualService()
^
Interceptor
Based on stacktrace, the client call to SingletonEjbY.performActualService() fails as server is not able to construct the component/EJB. The underlying cause is that the CDI unable to find the InitialContext
Deployment:
EAR
|_ WAR
|_lib/<jars-with-ejbs>
During startup, only one interceptor is called that makes sure that a transaction is associated (creates a new TX if one is not associated). It uses TransactionSynchronizationRegistry in the process.
My two cents: From stack trace its pretty clear that this interceptor has done its job properly as the failure happens between _StatelessEJB.doService() -> SingletonEjbY.performActualService()_
> [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)
7 years, 4 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Rakesh K. Cherukuri (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Rakesh K. Cherukuri edited comment on WFLY-11858 at 3/18/19 6:38 AM:
---------------------------------------------------------------------
Flow: During server startup,
Servlet.init() -> SingletonEjbX.serviceMethod -> StatelessEJB.doService() -> SingletonEjbY.performActualService()
^
Interceptor
Based on stacktrace, the client call to SingletonEjbY.performActualService() fails as server is not able to construct the component/EJB. The underlying cause is that the CDI unable to find the InitialContext
Deployment:
EAR
____ WAR
____ lib/<jars-with-ejbs>
During startup, only one interceptor is called that makes sure that a transaction is associated (creates a new TX if one is not associated). It uses TransactionSynchronizationRegistry in the process.
My two cents: From stack trace its pretty clear that this interceptor has done its job properly as the failure happens between _StatelessEJB.doService() -> SingletonEjbY.performActualService()_
was (Author: rakcheru):
Flow: During server startup,
Servlet.init() -> SingletonEjbX.serviceMethod -> StatelessEJB.doService() -> SingletonEjbY.performActualService()
^
Interceptor
Based on stacktrace, the client call to SingletonEjbY.performActualService() fails as server is not able to construct the component/EJB. The underlying cause is that the CDI unable to find the InitialContext
Deployment:
EAR
-- WAR
-- lib/<jars-with-ejbs>
During startup, only one interceptor is called that makes sure that a transaction is associated (creates a new TX if one is not associated). It uses TransactionSynchronizationRegistry in the process.
My two cents: From stack trace its pretty clear that this interceptor has done its job properly as the failure happens between _StatelessEJB.doService() -> SingletonEjbY.performActualService()_
> [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)
7 years, 4 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Rakesh K. Cherukuri (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Rakesh K. Cherukuri commented on WFLY-11858:
--------------------------------------------
Flow: During server startup,
Servlet.init() -> SingletonEjbX.serviceMethod -> StatelessEJB.doService() -> SingletonEjbY.performActualService()
^
Interceptor
Based on stacktrace, the client call to SingletonEjbY.performActualService() fails as server is not able to construct the component/EJB. The underlying cause is that the CDI unable to find the InitialContext
Deployment:
EAR
|_ WAR
|_lib/<jars-with-ejbs>
During startup, only one interceptor is called that makes sure that a transaction is associated (creates a new TX if one is not associated). It uses TransactionSynchronizationRegistry in the process.
My two cents: From stack trace its pretty clear that this interceptor has done its job properly as the failure happens between _StatelessEJB.doService() -> SingletonEjbY.performActualService()_
> [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)
7 years, 4 months
[JBoss JIRA] (DROOLS-3765) Enable the pod to act as a comsumer or producer
by Massimiliano Dessi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3765?page=com.atlassian.jira.plugi... ]
Massimiliano Dessi edited comment on DROOLS-3765 at 3/18/19 6:21 AM:
---------------------------------------------------------------------
The pods use a configmap to elect the leader, an update is sent to all the pods in the cluster the behaviour is the following:
The leader consume the user topic and in the handle event it produce a event on the master topic, the slaves consumes the events in the master topic.
If the leader is lost a new leader is elected and the slave turned into new leader change is topic to consume in 10 seconds.
https://github.com/desmax74/openshift-hacep
was (Author: mdessi):
The pods use a configmap to elect the leader, an update is sent to all the pods in the cluster the behaviour is the following:
The leader consume the user topic and in the handle event it produce a event on the master topic, the slaves consumes the events in the master topic.
If the leader is lost a new leader is elected and the slave turned into new leader change is topic to consume in 10 seconds.
> Enable the pod to act as a comsumer or producer
> ------------------------------------------------
>
> Key: DROOLS-3765
> URL: https://issues.jboss.org/browse/DROOLS-3765
> Project: Drools
> Issue Type: Sub-task
> Reporter: Massimiliano Dessi
> Assignee: Massimiliano Dessi
> Priority: Major
>
> The pod must act as a consumer or producer using the status of Master (consumer and producer) or slave (consumer)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11832) Transaction for Hibernate Interceptor is null
by Markus Chur (Jira)
[ https://issues.jboss.org/browse/WFLY-11832?page=com.atlassian.jira.plugin... ]
Markus Chur commented on WFLY-11832:
------------------------------------
Thank you! I filed a ticket in hibernate jira as well, HHH-13326.
> Transaction for Hibernate Interceptor is null
> ---------------------------------------------
>
> Key: WFLY-11832
> URL: https://issues.jboss.org/browse/WFLY-11832
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate, Transactions
> Affects Versions: 14.0.0.Final, 15.0.1.Final, 16.0.0.Final
> Reporter: Markus Chur
> Assignee: Scott Marlow
> Priority: Major
> Attachments: hibernate-interceptor-reproducer-0.0.1-SNAPSHOT.jar, src -WFLY-11832.zip
>
>
> With Wildfly 13 - javaee7 transactions in hibernate interceptors were never null.
> Since Wildfly 14 - javaee8 transactions in hibernate interceptors are always null.
> Attached sources and a jar of a minimal reproducer for Wildfly 16. This is reproducible by using a fresh unchanged Wildfly 16 and unchanged standalone.xml. Extract Wildfly 16, drop in the jar in the deployments folder and start the server.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (DROOLS-3770) Fix generic type retrieval inside SetPropertyHeaderCommand
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-3770:
----------------------------------------
Summary: Fix generic type retrieval inside SetPropertyHeaderCommand
Key: DROOLS-3770
URL: https://issues.jboss.org/browse/DROOLS-3770
Project: Drools
Issue Type: Bug
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
The property editing information for a given column (included the DOMELEmentFactory) are set inside SetPropertyHeaderColumn.
If the property is a collection, its generic type is retrieved with informations from the context.
Currently, this mechanism uses the "steps" stored inside "elements", that point to full path of the property (and a mapped entry must exists).
This is broken for top-level collection because are mapped in a different way, so a compatible method for different situations must be implemented
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months