May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9288) EJB session auto-creation is not working

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9288?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-9288: ------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/11187 (was: https://github.com/wildfly/wildfly/pull/10466) > EJB session auto-creation is not working > ---------------------------------------- > > Key: WFLY-9288 > URL: https://issues.jboss.org/browse/WFLY-9288 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: David Lloyd > Assignee: David Lloyd > > In {{org.jboss.as.ejb3.remote.AssociationImpl#receiveInvocationRequest}}, when the EJB component is being looked up, two things need to happen which are not happening: > * The incoming locator should be examined; if it is a stateful locator and the physical EJB is stateless, then {{Request#writeNotStateful()}} should be called and processing should be aborted. > * If the incoming locator is a stateless locator and the physical EJB is stateful, then {{component#createSessionRemote()}} should be called and the resultant session ID should be set using {{Request#convertToStateful()}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8542) StatefulSessionSynchronizationInterceptor fails weirdly if the transaction is in ROLLBACK_ONLY

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-8542?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-8542: ----------------------------------- Excellent, then the fix for this issue is to simply not register the synchronization during rollback-only mode. > StatefulSessionSynchronizationInterceptor fails weirdly if the transaction is in ROLLBACK_ONLY > ---------------------------------------------------------------------------------------------- > > Key: WFLY-8542 > URL: https://issues.jboss.org/browse/WFLY-8542 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: David Lloyd > > It's not really clear what the correct behavior is, but it definitely isn't this: > {noformat} > 2017-04-07 14:53:09 javax.ejb.EJBTransactionRolledbackException: WFLYTX0029: Syncs are not allowed to be registered when the tx is in state 1 > 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:160) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:257) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:334) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327) > 2017-04-07 14:53:09 at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) > 2017-04-07 14:53:09 at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:84) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256) > 2017-04-07 14:53:09 at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > 2017-04-07 14:53:09 at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > 2017-04-07 14:53:09 at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > 2017-04-07 14:53:09 at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:457) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:452) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:164) > 2017-04-07 14:53:09 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > 2017-04-07 14:53:09 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > 2017-04-07 14:53:09 at java.lang.Thread.run(Thread.java:745) > 2017-04-07 14:53:09 Caused by: java.lang.IllegalStateException: WFLYTX0029: Syncs are not allowed to be registered when the tx is in state 1 > 2017-04-07 14:53:09 at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.registerInterposedSynchronization(JCAOrderedLastSynchronizationList.java:76) > 2017-04-07 14:53:09 at org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.registerInterposedSynchronization(TransactionSynchronizationRegistryWrapper.java:78) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:118) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > 2017-04-07 14:53:09 at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59) > 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:255) > 2017-04-07 14:53:09 ... 42 more > {noformat} > If the transaction is in ROLLBACK_ONLY, then any of these might possibly be correct behavior: > * Reject the invocation with a specific exception explaining that the method cannot be invoked when the transaction is in ROLLBACK_ONLY (preferably with a spec citation) > * Allow the invocation to proceed without registering the synchronization (this probably isn't correct but might be) > * Allow the invocation to proceed and use a "backdoor" to register the user synchronization anyway -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10338) Discovery subsystem is missing from the domain profiles

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-10338?page=com.atlassian.jira.plugin... ] David Lloyd commented on WFLY-10338: ------------------------------------ I think that is correct. > Discovery subsystem is missing from the domain profiles > ------------------------------------------------------- > > Key: WFLY-10338 > URL: https://issues.jboss.org/browse/WFLY-10338 > Project: WildFly > Issue Type: Bug > Components: Build System, Management > Reporter: Brian Stansberry > Assignee: Yeray Borges > Fix For: 13.0.0.Beta1 > > > Same problem as WFCORE-3784 except in the full feature-pack. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-169) Restructure Python automation framework - it is fetching data very slowly

by Jeeva Kandasamy (JIRA)

[ https://issues.jboss.org/browse/SWSQE-169?page=com.atlassian.jira.plugin.... ] Jeeva Kandasamy updated SWSQE-169: ---------------------------------- Team: Automation (was: Automation) Sprint: Kiali QE Sprint 4, Kiali QE Sprint 5 (was: Kiali QE Sprint 4) > Restructure Python automation framework - it is fetching data very slowly > ------------------------------------------------------------------------- > > Key: SWSQE-169 > URL: https://issues.jboss.org/browse/SWSQE-169 > Project: Kiali QE > Issue Type: QE Task > Reporter: Jeeva Kandasamy > Assignee: Jeeva Kandasamy > > https://github.com/Kiali-QE/kiali-qe-python fetching data from slowly and needs some improvements in the overall structure. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3809) Use Delegating MSC classes

by Richard Opalka (JIRA)

Richard Opalka created WFCORE-3809: -------------------------------------- Summary: Use Delegating MSC classes Key: WFCORE-3809 URL: https://issues.jboss.org/browse/WFCORE-3809 Project: WildFly Core Issue Type: Enhancement Components: Server Reporter: Richard Opalka Assignee: Richard Opalka Fix For: 5.0.0.Beta1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2589) Eliminate MSC OPTIONAL dependencies usage

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2589?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFCORE-2589: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2282, https://github.com/wildfly/wildfly-core/pull/3262 (was: https://github.com/wildfly/wildfly-core/pull/2282) > Eliminate MSC OPTIONAL dependencies usage > ----------------------------------------- > > Key: WFCORE-2589 > URL: https://issues.jboss.org/browse/WFCORE-2589 > Project: WildFly Core > Issue Type: Task > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 5.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2589) Eliminate MSC OPTIONAL dependencies usage

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2589?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFCORE-2589: ----------------------------------- Fix Version/s: 5.0.0.Beta1 (was: 5.0.0.Alpha4) > Eliminate MSC OPTIONAL dependencies usage > ----------------------------------------- > > Key: WFCORE-2589 > URL: https://issues.jboss.org/browse/WFCORE-2589 > Project: WildFly Core > Issue Type: Task > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 5.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2589) Eliminate MSC OPTIONAL dependencies usage

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2589?page=com.atlassian.jira.plugi... ] Richard Opalka reopened WFCORE-2589: ------------------------------------ > Eliminate MSC OPTIONAL dependencies usage > ----------------------------------------- > > Key: WFCORE-2589 > URL: https://issues.jboss.org/browse/WFCORE-2589 > Project: WildFly Core > Issue Type: Task > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 5.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10338) Discovery subsystem is missing from the domain profiles

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-10338?page=com.atlassian.jira.plugin... ] Yeray Borges commented on WFLY-10338: ------------------------------------- I clear it up to myself, ha contains the exact same subsystems as the default profile plus clustering capabilities, so, discovery must be added there. If I'm not missing something: all profiles except load-balancer have to have the discovery subsystem. > Discovery subsystem is missing from the domain profiles > ------------------------------------------------------- > > Key: WFLY-10338 > URL: https://issues.jboss.org/browse/WFLY-10338 > Project: WildFly > Issue Type: Bug > Components: Build System, Management > Reporter: Brian Stansberry > Assignee: Yeray Borges > Fix For: 13.0.0.Beta1 > > > Same problem as WFCORE-3784 except in the full feature-pack. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10020) Custom Hibernate slot and second level cache with Wildfly 12 causes NullPointer Exception

by Alessandro Moscatelli (JIRA)

[ https://issues.jboss.org/browse/WFLY-10020?page=com.atlassian.jira.plugin... ] Alessandro Moscatelli commented on WFLY-10020: ---------------------------------------------- We are not in production. I'll wait for Wildfly 13 to test the combination you suggested. I am forced to use Hibernate 5.2.x to fix several issues with the CriteriaBuilder :( Yea having Hibernate 5.2 as default in Wildfly 13 would be sweet, without extra slot or configuration. Thank you > Custom Hibernate slot and second level cache with Wildfly 12 causes NullPointer Exception > ----------------------------------------------------------------------------------------- > > Key: WFLY-10020 > URL: https://issues.jboss.org/browse/WFLY-10020 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 12.0.0.Final > Reporter: Alessandro Moscatelli > Assignee: Scott Marlow > > Migrating to 12 with Hibernate Custom slot causes NullPointer Exception. > https://mvnrepository.com/artifact/org.hibernate/hibernate-orm-modules > <property name="jboss.as.jpa.providerModule" value="org.hibernate:5.2.13.Final" /> > 16:12:28,868 INFO [org.jboss.as.jpa] (MSC service thread 1-1) WFLYJPA0002: Read persistence.xml for optoplus > 16:12:29,142 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."optoplus-services-ear-1.0.18-SNAPSHOT.ear".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."optoplus-services-ear-1.0.18-SNAPSHOT.ear".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "optoplus-services-ear-1.0.18-SNAPSHOT.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:151) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.NullPointerException > at org.jboss.as.jpa.processor.secondLevelCache.InfinispanCacheDeploymentListener.addCacheDependencies(InfinispanCacheDeploymentListener.java:129) > at org.jboss.as.jpa.processor.secondLevelCache.CacheDeploymentListener.addCacheDependencies(CacheDeploymentListener.java:111) > at org.jipijapa.event.impl.internal.Notification.addCacheDependencies(Notification.java:95) > at org.jboss.as.jpa.hibernate5.HibernateSecondLevelCache.addSecondLevelCacheDependencies(HibernateSecondLevelCache.java:125) > at org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.addProviderDependencies(HibernatePersistenceProviderAdaptor.java:107) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseOne(PersistenceUnitServiceHandler.java:538) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:273) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleEarDeployment(PersistenceUnitServiceHandler.java:228) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:135) > at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144) > ... 8 more > 16:12:29,155 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"optoplus-services-ear-1.0.18-SNAPSHOT.ear\".FIRST_MODULE_USE" => "WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment \"optoplus-services-ear-1.0.18-SNAPSHOT.ear\" > Caused by: java.lang.NullPointerException"}} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

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 2018