May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13503) [GSS](7.3.z) Websphere MQ Resource Adapter Configuration Does Not Take Effect Until Reboot

by Parul Sharma (Jira)

[ https://issues.redhat.com/browse/WFLY-13503?page=com.atlassian.jira.plugi... ] Parul Sharma moved JBEAP-19528 to WFLY-13503: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-13503 (was: JBEAP-19528) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Affects Version/s: (was: 7.3.1.GA) Fix Version/s: (was: 7.3.2.GA) > [GSS](7.3.z) Websphere MQ Resource Adapter Configuration Does Not Take Effect Until Reboot > ------------------------------------------------------------------------------------------ > > Key: WFLY-13503 > URL: https://issues.redhat.com/browse/WFLY-13503 > Project: WildFly > Issue Type: Bug > Reporter: Parul Sharma > Assignee: Parul Sharma > Priority: Major > Labels: downstream_dependency > > When configuring the IBM Websphere Resource Adapter in JBoss 7.2.4 via the jboss-cli according to the directions in: > {code} > https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... > {code} > No JNDI entries are created for the connection factory and destination objects until the container is restarted. The documentation does not mention a restart being required to initialize the adapter and associated objects. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13498) @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16

by Matěj Novotný (Jira)

[ https://issues.redhat.com/browse/WFLY-13498?page=com.atlassian.jira.plugi... ] Matěj Novotný commented on WFLY-13498: -------------------------------------- [~fearghalom] so I tried to reproduce this within Weld testsuite; [here is the test|https://github.com/manovotn/core/blob/wfly13498/tests-arquillian/src...] (I can provide info on how to execute that on wfly if needed). As you can see from the {{@Deployment}} section of the test, it is a simple WAR with a library and observers listening for {{(a)Initialized(ApplicationScoped.class)}} in both. That should be exactly your case. What I am seeing is that both, WAR and its lib, *are receiving event notifications* for {{Object}} and even for {{ServletContext}}. I was apparently wrong there and in this scenario, even the lib will receive the {{ServletContext}} event (with a context path from the web app itself). Either way, I am unable to reproduce your scenario, can you put together some reproducer/test where this would manifest? > @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16 > -------------------------------------------------------------- > > Key: WFLY-13498 > URL: https://issues.redhat.com/browse/WFLY-13498 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 16.0.0.Final > Reporter: Fearghal O Maolcatha > Assignee: Matěj Novotný > Priority: Major > > I have an @ApplicationScoped bean that I want to be instantiated on application startup (see sample code below). I've registered for the servlet context initialization event but the init method is never invoked. The FactoryLocator is contained in a jar within my war's WEB-INF/lib directory. This same code was working on Wildfly 9 but no longer works after upgrading to Wildfly 16. > {code:java} > import javax.enterprise.context.ApplicationScoped; > import javax.enterprise.context.Initialized; > import javax.enterprise.event.Observes; > import javax.servlet.ServletContext; > @ApplicationScoped > public class FactoryLocator { > public FactoryLocator() { > System.out.println("In the constructor........................."); > } > private void init(@Observes @Initialized(ApplicationScoped.class) ServletContext sc) { > System.out.println("Invoking the event observer method.................."); > } > } > {code} > One workaround I discovered was to extract the contents of the jars in my war's WEB-INF/lib/ directory to my war's WEB-INF/classes directory. When I did this my FactorLocator bean was instantiated successfully. I'd prefer not to have to do this. > After debugging through the war's deployment, I noticed that the ServletContext is initialized before all the beans in the war's lib directory are processed (org.jboss.weld.bootstrap.BeanDeploymentModules:processBeanDeployments). The war's module is not aware of all observers until all the beans are processed. However, the ServletContextEvent is fired before all the observers are known. > Should this happen that ServletContext is created before all observers are known about? I've debugged one of the Wildfly QuickStart applications and the ServletContext isn't created until all bean deployments are processed and the code below is executed successfully. Is the order in which this happens supposed to be guaranteed? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13502) UT000010: Session is invalid

by Cristian VL (Jira)

[ https://issues.redhat.com/browse/WFLY-13502?page=com.atlassian.jira.plugi... ] Cristian VL updated WFLY-13502: ------------------------------- Steps to Reproduce: It happens randomly from time to time. I am using Weld with JSP/Servlets. Sessions are created and invalidate on ServletRequestListener (requestInitialized/requestDestroyed) was: It happens randomly from time to time. Sessions are created and invalidate on ServletRequestListener (requestInitialized/requestDestroyed) > UT000010: Session is invalid > ----------------------------- > > Key: WFLY-13502 > URL: https://issues.redhat.com/browse/WFLY-13502 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 14.0.0.Final, 16.0.0.Final > Reporter: Cristian VL > Assignee: Flavia Rainone > Priority: Critical > > 2020-05-21 06:00:22,239 ERROR [org.jboss.threads.errors] (default task-1145) Thread Thread[default task-1145,5,main] threw an uncaught exception: java.lang.RuntimeException: java.lang.IllegalStateException: UT000010: Session is invalid X0SZbaIu078s8ChCz8YIJON59sTmY7gV2bopjwlm > at io.undertow.servlet.spec.ServletContextImpl.invokeRunnable(ServletContextImpl.java:1029) > at io.undertow.servlet.spec.AsyncContextImpl.onAsyncComplete(AsyncContextImpl.java:614) > at io.undertow.servlet.spec.AsyncContextImpl.access$100(AsyncContextImpl.java:73) > at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:316) > at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:485) > at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:604) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalStateException: UT000010: Session is invalid X0SZbaIu078s8ChCz8YIJON59sTmY7gV2bopjwlm > at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:512) > at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:122) > at org.jboss.weld.module.web.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:37) > at org.jboss.weld.module.web.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:18) > at org.jboss.weld.contexts.AbstractConversationContext.copyConversationIdGeneratorAndConversationsToSession(AbstractConversationContext.java:179) > at org.jboss.weld.contexts.AbstractConversationContext.dissociate(AbstractConversationContext.java:157) > at org.jboss.weld.module.web.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:116) > at org.jboss.weld.module.web.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:254) > at org.jboss.weld.module.web.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152) > at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246) > at io.undertow.servlet.spec.AsyncContextImpl.setupRequestContext(AsyncContextImpl.java:706) > at io.undertow.servlet.spec.AsyncContextImpl.access$700(AsyncContextImpl.java:73) > at io.undertow.servlet.spec.AsyncContextImpl$7.run(AsyncContextImpl.java:619) > at io.undertow.servlet.spec.ServletContextImpl$2.call(ServletContextImpl.java:181) > at io.undertow.servlet.spec.ServletContextImpl$2.call(ServletContextImpl.java:178) > at io.undertow.servlet.spec.ServletContextImpl.invokeRunnable(ServletContextImpl.java:1027) > ... 10 more -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13502) UT000010: Session is invalid

by Cristian VL (Jira)

Cristian VL created WFLY-13502: ---------------------------------- Summary: UT000010: Session is invalid Key: WFLY-13502 URL: https://issues.redhat.com/browse/WFLY-13502 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 16.0.0.Final, 14.0.0.Final Reporter: Cristian VL Assignee: Flavia Rainone 2020-05-21 06:00:22,239 ERROR [org.jboss.threads.errors] (default task-1145) Thread Thread[default task-1145,5,main] threw an uncaught exception: java.lang.RuntimeException: java.lang.IllegalStateException: UT000010: Session is invalid X0SZbaIu078s8ChCz8YIJON59sTmY7gV2bopjwlm at io.undertow.servlet.spec.ServletContextImpl.invokeRunnable(ServletContextImpl.java:1029) at io.undertow.servlet.spec.AsyncContextImpl.onAsyncComplete(AsyncContextImpl.java:614) at io.undertow.servlet.spec.AsyncContextImpl.access$100(AsyncContextImpl.java:73) at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:316) at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:485) at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:604) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.IllegalStateException: UT000010: Session is invalid X0SZbaIu078s8ChCz8YIJON59sTmY7gV2bopjwlm at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:512) at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:122) at org.jboss.weld.module.web.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:37) at org.jboss.weld.module.web.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:18) at org.jboss.weld.contexts.AbstractConversationContext.copyConversationIdGeneratorAndConversationsToSession(AbstractConversationContext.java:179) at org.jboss.weld.contexts.AbstractConversationContext.dissociate(AbstractConversationContext.java:157) at org.jboss.weld.module.web.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:116) at org.jboss.weld.module.web.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:254) at org.jboss.weld.module.web.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152) at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246) at io.undertow.servlet.spec.AsyncContextImpl.setupRequestContext(AsyncContextImpl.java:706) at io.undertow.servlet.spec.AsyncContextImpl.access$700(AsyncContextImpl.java:73) at io.undertow.servlet.spec.AsyncContextImpl$7.run(AsyncContextImpl.java:619) at io.undertow.servlet.spec.ServletContextImpl$2.call(ServletContextImpl.java:181) at io.undertow.servlet.spec.ServletContextImpl$2.call(ServletContextImpl.java:178) at io.undertow.servlet.spec.ServletContextImpl.invokeRunnable(ServletContextImpl.java:1027) ... 10 more -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFWIP-301) SingleServerRuntimeTest intermittent failure in CodeReady Studio jobs

by Marek Kopecky (Jira)

[ https://issues.redhat.com/browse/WFWIP-301?page=com.atlassian.jira.plugin... ] Marek Kopecky edited comment on WFWIP-301 at 5/21/20 1:53 AM: -------------------------------------------------------------- I still see the same error, can you please double check this issue? https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view/EAP... bq. I have had 6 builds without test failures with EAP 7.3 and CRS 12.15 nightly build. Can you please share these runs? was (Author: mkopecky): I still see the same error, can you please double check this issue? https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view/EAP... > SingleServerRuntimeTest intermittent failure in CodeReady Studio jobs > --------------------------------------------------------------------- > > Key: WFWIP-301 > URL: https://issues.redhat.com/browse/WFWIP-301 > Project: WildFly WIP > Issue Type: Bug > Reporter: Marek Kopecky > Assignee: Josef Kopriva > Priority: Blocker > > [CodeReady Studio Jenkins jobs|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/vie...] is not stable. > I started this job a few times and it seems that there is intermittent failure of SingleServerRuntimeTest operate no-configuration test, see [this jenkins run|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view...] or [this run|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view...], both with EAP 7.3.0.GA.CR3. > EAP QE needs clear statement on behalf of JBDS QE Team whether "this test failure doesn't block EAP7-1128 RFE and can be ignored" or let me know when the job will be stable. Until that, I consider that the job is not ready and blocks EAP7-1128 RFE. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFWIP-301) SingleServerRuntimeTest intermittent failure in CodeReady Studio jobs

by Marek Kopecky (Jira)

[ https://issues.redhat.com/browse/WFWIP-301?page=com.atlassian.jira.plugin... ] Marek Kopecky edited comment on WFWIP-301 at 5/21/20 1:53 AM: -------------------------------------------------------------- I still see the same error, can you please double check this issue? https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view/EAP... bq. I have had 6 builds without test failures with EAP 7.3 and CRS 12.15 nightly build. Can you please share links to these jenkins runs? was (Author: mkopecky): I still see the same error, can you please double check this issue? https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view/EAP... bq. I have had 6 builds without test failures with EAP 7.3 and CRS 12.15 nightly build. Can you please share these runs? > SingleServerRuntimeTest intermittent failure in CodeReady Studio jobs > --------------------------------------------------------------------- > > Key: WFWIP-301 > URL: https://issues.redhat.com/browse/WFWIP-301 > Project: WildFly WIP > Issue Type: Bug > Reporter: Marek Kopecky > Assignee: Josef Kopriva > Priority: Blocker > > [CodeReady Studio Jenkins jobs|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/vie...] is not stable. > I started this job a few times and it seems that there is intermittent failure of SingleServerRuntimeTest operate no-configuration test, see [this jenkins run|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view...] or [this run|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view...], both with EAP 7.3.0.GA.CR3. > EAP QE needs clear statement on behalf of JBDS QE Team whether "this test failure doesn't block EAP7-1128 RFE and can be ignored" or let me know when the job will be stable. Until that, I consider that the job is not ready and blocks EAP7-1128 RFE. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFWIP-301) SingleServerRuntimeTest intermittent failure in CodeReady Studio jobs

by Marek Kopecky (Jira)

[ https://issues.redhat.com/browse/WFWIP-301?page=com.atlassian.jira.plugin... ] Marek Kopecky reopened WFWIP-301: --------------------------------- I still see the same error, can you please double check this issue? https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view/EAP... > SingleServerRuntimeTest intermittent failure in CodeReady Studio jobs > --------------------------------------------------------------------- > > Key: WFWIP-301 > URL: https://issues.redhat.com/browse/WFWIP-301 > Project: WildFly WIP > Issue Type: Bug > Reporter: Marek Kopecky > Assignee: Josef Kopriva > Priority: Blocker > > [CodeReady Studio Jenkins jobs|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/vie...] is not stable. > I started this job a few times and it seems that there is intermittent failure of SingleServerRuntimeTest operate no-configuration test, see [this jenkins run|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view...] or [this run|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view...], both with EAP 7.3.0.GA.CR3. > EAP QE needs clear statement on behalf of JBDS QE Team whether "this test failure doesn't block EAP7-1128 RFE and can be ignored" or let me know when the job will be stable. Until that, I consider that the job is not ready and blocks EAP7-1128 RFE. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13295) REST-AT inbound bridge is not activated for EJB without TransactionalManagement annotation

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/WFLY-13295?page=com.atlassian.jira.plugi... ] Ondrej Chaloupka commented on WFLY-13295: ----------------------------------------- [~brian.stansberry] yes, agree. I created PR with the WFLY part and tests here: https://github.com/wildfly/wildfly/pull/13315 > REST-AT inbound bridge is not activated for EJB without TransactionalManagement annotation > ------------------------------------------------------------------------------------------ > > Key: WFLY-13295 > URL: https://issues.redhat.com/browse/WFLY-13295 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 19.0.0.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 20.0.0.Final > > > The REST-AT inbound bridge is activated per deployment. It's activated for a deployment which contains a REST endpoint identified with `@Path` annotation where in the same class has to be included either annotation `@Transactional` or `@TransactionAttribute`. > The point is to activate the inbound bridge for deployments which contain a transactional managed method (CDI or EJB) which can receive the txn context, ie. possibly a context of REST-AT transaction as well. > The issue is that EJB beans are transactional by default. The EJB bean class does not need to specify any `@TransactionalAttribute` to be already container managed (from txn perspective) with attribute `REQUIRED`. Which means taking incoming txn context and will work with it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13295) REST-AT inbound bridge is not activated for EJB without TransactionalManagement annotation

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/WFLY-13295?page=com.atlassian.jira.plugi... ] Ondrej Chaloupka updated WFLY-13295: ------------------------------------ Git Pull Request: https://github.com/jbosstm/narayana/pull/1573, https://github.com/wildfly/wildfly/pull/13315 (was: https://github.com/jbosstm/narayana/pull/1573) > REST-AT inbound bridge is not activated for EJB without TransactionalManagement annotation > ------------------------------------------------------------------------------------------ > > Key: WFLY-13295 > URL: https://issues.redhat.com/browse/WFLY-13295 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 19.0.0.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 20.0.0.Final > > > The REST-AT inbound bridge is activated per deployment. It's activated for a deployment which contains a REST endpoint identified with `@Path` annotation where in the same class has to be included either annotation `@Transactional` or `@TransactionAttribute`. > The point is to activate the inbound bridge for deployments which contain a transactional managed method (CDI or EJB) which can receive the txn context, ie. possibly a context of REST-AT transaction as well. > The issue is that EJB beans are transactional by default. The EJB bean class does not need to specify any `@TransactionalAttribute` to be already container managed (from txn perspective) with attribute `REQUIRED`. Which means taking incoming txn context and will work with it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1404) Race condition involving Pool.fillTo

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/JBJCA-1404?page=com.atlassian.jira.plugi... ] Flavia Rainone resolved JBJCA-1404. ----------------------------------- Resolution: Done > Race condition involving Pool.fillTo > ------------------------------------ > > Key: JBJCA-1404 > URL: https://issues.redhat.com/browse/JBJCA-1404 > Project: IronJacamar > Issue Type: Bug > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Major > > The fillTo implementation of SemaphoreConcurrentLinkedDequeManagedConnectionPool suffers from the same issue we found in increase capacity: > https://github.com/ironjacamar/ironjacamar/pull/695/commits/d80c2ae7713f4... > See JBJCA-1399. > This means that when more than two threads attempt to add connections to the pool and one of them does so via fillTo, we can run into problems with pool max size. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2020