[JBoss JIRA] (DROOLS-4049) PMML files are not listed in Library only in Project Explorer
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4049?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4049:
--------------------------------
Description:
As title I upload a .pmml file
!image-2019-05-17-15-43-45-741.png|thumbnail!
it does not appear in asset view despite refresh and multiple time waiting:
!image-2019-05-17-15-44-06-544.png|thumbnail!
the only way to check if the file is there is to open another editor at random and check in file explorer:
!image-2019-05-17-15-44-30-629.png|thumbnail!
h2. Acceptance test
- Import (/)
- Change and reopen
- Remove
- Rename
- Filter
- View in Project view (/)
- View in repository view (/)
- Build project
was:
As title I upload a .pmml file
!image-2019-05-17-15-43-45-741.png|thumbnail!
it does not appear in asset view despite refresh and multiple time waiting:
!image-2019-05-17-15-44-06-544.png|thumbnail!
the only way to check if the file is there is to open another editor at random and check in file explorer:
!image-2019-05-17-15-44-30-629.png|thumbnail!
h2. Acceptance test
- Import (/)
- Change and reopen
- Remove
- Rename
- Filter
- View in Project view
- View in repository view
- Build project
> PMML files are not listed in Library only in Project Explorer
> -------------------------------------------------------------
>
> Key: DROOLS-4049
> URL: https://issues.jboss.org/browse/DROOLS-4049
> Project: Drools
> Issue Type: Enhancement
> Components: PMML
> Affects Versions: 7.21.0.Final
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Attachments: image-2019-05-17-15-43-45-741.png, image-2019-05-17-15-44-06-544.png, image-2019-05-17-15-44-30-629.png, test_scorecard.pmml
>
>
> As title I upload a .pmml file
> !image-2019-05-17-15-43-45-741.png|thumbnail!
> it does not appear in asset view despite refresh and multiple time waiting:
> !image-2019-05-17-15-44-06-544.png|thumbnail!
> the only way to check if the file is there is to open another editor at random and check in file explorer:
> !image-2019-05-17-15-44-30-629.png|thumbnail!
> h2. Acceptance test
> - Import (/)
> - Change and reopen
> - Remove
> - Rename
> - Filter
> - View in Project view (/)
> - View in repository view (/)
> - Build project
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-4049) PMML files are not listed in Library only in Project Explorer
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4049?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4049:
--------------------------------
Description:
As title I upload a .pmml file
!image-2019-05-17-15-43-45-741.png|thumbnail!
it does not appear in asset view despite refresh and multiple time waiting:
!image-2019-05-17-15-44-06-544.png|thumbnail!
the only way to check if the file is there is to open another editor at random and check in file explorer:
!image-2019-05-17-15-44-30-629.png|thumbnail!
h2. Acceptance test
- Import (/)
- Change and reopen
- Remove
- Rename
- Filter
- View in Project view
- View in repository view
- Build project
was:
As title I upload a .pmml file
!image-2019-05-17-15-43-45-741.png|thumbnail!
it does not appear in asset view despite refresh and multiple time waiting:
!image-2019-05-17-15-44-06-544.png|thumbnail!
the only way to check if the file is there is to open another editor at random and check in file explorer:
!image-2019-05-17-15-44-30-629.png|thumbnail!
> PMML files are not listed in Library only in Project Explorer
> -------------------------------------------------------------
>
> Key: DROOLS-4049
> URL: https://issues.jboss.org/browse/DROOLS-4049
> Project: Drools
> Issue Type: Enhancement
> Components: PMML
> Affects Versions: 7.21.0.Final
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Attachments: image-2019-05-17-15-43-45-741.png, image-2019-05-17-15-44-06-544.png, image-2019-05-17-15-44-30-629.png, test_scorecard.pmml
>
>
> As title I upload a .pmml file
> !image-2019-05-17-15-43-45-741.png|thumbnail!
> it does not appear in asset view despite refresh and multiple time waiting:
> !image-2019-05-17-15-44-06-544.png|thumbnail!
> the only way to check if the file is there is to open another editor at random and check in file explorer:
> !image-2019-05-17-15-44-30-629.png|thumbnail!
> h2. Acceptance test
> - Import (/)
> - Change and reopen
> - Remove
> - Rename
> - Filter
> - View in Project view
> - View in repository view
> - Build project
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12077) Transaction could not handle remote EJB invocation even if the transaction is not used remote
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12077?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka commented on WFLY-12077:
-----------------------------------------
[~tomekadamski] I'm assigning this to me as I did research on this last week and I worked on test reproducer as well (https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/tests-transactions/m...). Please, feel free to reassign that to you in case of some clash (and for not duplicating the work) or let me know if there is something I should know.
> Transaction could not handle remote EJB invocation even if the transaction is not used remote
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-12077
> URL: https://issues.jboss.org/browse/WFLY-12077
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Ondrej Chaloupka
> Priority: Critical
> Labels: Regression
> Attachments: reproducer.zip
>
>
> An EJB marked as BMT which start a Tx and invoke a CMT managed Bean annotated with REQUIRES_NEW will fail if the BMT bean will show unexpected Arjuna WARN messages and the Tx seems not finished correctly.
> The same works in former releases.
> WARN [com.arjuna.ats.jta] (default task-2) ARJUNA016129: Could not end XA resource Subordinate XAResource at http-remoting://localhost:8180: javax.transaction.xa.XAException: WFTXN0029: The peer threw an XA exception
> at org.wildfly.transaction.client.provider.remoting.TransactionClientChannel.setRollbackOnly(TransactionClientChannel.java:167)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer$1.end(RemotingRemoteTransactionPeer.java:158)
> at org.wildfly.transaction.client.SubordinateXAResource.end(SubordinateXAResource.java:138)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.doEnd(TransactionImple.java:1088)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.endAssociation(TransactionImple.java:1059)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.endAssociation(XAResourceRecord.java:1286)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:313)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3023)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3002)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1674)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:124)
> at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1370)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.rollback(BaseTransactionManagerDelegate.java:134)
> at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:109)
> at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:83)
> at org.wildfly.transaction.client.LocalUserTransaction.rollback(LocalUserTransaction.java:58)
> at xa.transaction.BeanA.testRemoteCMTxnFailure(BeanA.java:44)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:89)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:102)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> 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:1348)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: Remote exception javax.transaction.xa.XAException
> Public fields:
> errorCode=-4
> at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel.lambda$handleXaTxnRollbackOnly$3(TransactionServerChannel.java:398)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsObjIntConsumer(SecurityIdentity.java:381)
> at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel.handleXaTxnRollbackOnly(TransactionServerChannel.java:394)
> at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel$ReceiverImpl.handleMessage(TransactionServerChannel.java:132)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:942)
> 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)
> ... 1 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12077) Transaction could not handle remote EJB invocation even if the transaction is not used remote
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12077?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka reassigned WFLY-12077:
---------------------------------------
Assignee: Ondrej Chaloupka (was: Tomasz Adamski)
> Transaction could not handle remote EJB invocation even if the transaction is not used remote
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-12077
> URL: https://issues.jboss.org/browse/WFLY-12077
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Ondrej Chaloupka
> Priority: Critical
> Labels: Regression
> Attachments: reproducer.zip
>
>
> An EJB marked as BMT which start a Tx and invoke a CMT managed Bean annotated with REQUIRES_NEW will fail if the BMT bean will show unexpected Arjuna WARN messages and the Tx seems not finished correctly.
> The same works in former releases.
> WARN [com.arjuna.ats.jta] (default task-2) ARJUNA016129: Could not end XA resource Subordinate XAResource at http-remoting://localhost:8180: javax.transaction.xa.XAException: WFTXN0029: The peer threw an XA exception
> at org.wildfly.transaction.client.provider.remoting.TransactionClientChannel.setRollbackOnly(TransactionClientChannel.java:167)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer$1.end(RemotingRemoteTransactionPeer.java:158)
> at org.wildfly.transaction.client.SubordinateXAResource.end(SubordinateXAResource.java:138)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.doEnd(TransactionImple.java:1088)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.endAssociation(TransactionImple.java:1059)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.endAssociation(XAResourceRecord.java:1286)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:313)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3023)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3002)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1674)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:124)
> at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1370)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.rollback(BaseTransactionManagerDelegate.java:134)
> at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:109)
> at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:83)
> at org.wildfly.transaction.client.LocalUserTransaction.rollback(LocalUserTransaction.java:58)
> at xa.transaction.BeanA.testRemoteCMTxnFailure(BeanA.java:44)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:89)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:102)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> 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:1348)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: Remote exception javax.transaction.xa.XAException
> Public fields:
> errorCode=-4
> at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel.lambda$handleXaTxnRollbackOnly$3(TransactionServerChannel.java:398)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsObjIntConsumer(SecurityIdentity.java:381)
> at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel.handleXaTxnRollbackOnly(TransactionServerChannel.java:394)
> at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel$ReceiverImpl.handleMessage(TransactionServerChannel.java:132)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:942)
> 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)
> ... 1 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn
by Thomas Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson commented on WFLY-12090:
-----------------------------------------
According to what we know now, we can't wait for EJB service to start as it only starts when the app is deployed that uses EJB. If app is undeployed EJB remoting recovery would never happen. [~flavia.rainone]is looking to start the EJB service is recovery resource is required.
> Unknown service name jboss.ejb and txn
> --------------------------------------
>
> Key: WFLY-12090
> URL: https://issues.jboss.org/browse/WFLY-12090
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 17.0.0.Alpha1
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Priority: Major
> Fix For: 17.0.0.Beta1
>
>
> When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have the following sort of error:
> {code}
> 16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171)
> at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb
> at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429)
> at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46)
> at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn
> ... 6 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka edited comment on WFLY-12090 at 5/21/19 7:10 AM:
------------------------------------------------------------------
[~tomjenkinson] yes, I think both option are possible but maybe not so easy to implement. If there is a way to define a service dependency tree then IMHO it's easier. But it depends on if it's possible.
[~flavia.rainone] I'm searching the code a bit (the dependencies are a bit complex thus I could be missing details) but the EJBRemotingService depends on the txn remote service but not on the recovery service, doesn't it? I mean having the dependency tree like
{code}
+----------+
| |
+ v
EJB service TXN Service
^ ^
| | (R.S. depends on TXN S.)
+ +
Recovery Service
{code}
in case you appreciate it I can try to research on this a bit more?
was (Author: ochaloup):
[~tomjenkinson] yes, I think both option are possible but maybe not so easy to implement. If there is a way to define a service dependency tree then IMHO it's easier. But it depends on if it's possible.
[~flavia.rainone] I'm searching the code a bit (the dependencies are a bit complex thus I could be missing details) but the EJBRemotingService depends on the txn remote service but not on the recovery service, doesn't it? I mean having the dependency tree like
{code}
+----------+
| |
+ v
EJB service TXN Service
^ ^
| |
+ +
Recovery Service
{code}
in case you appreciate it I can try to research on this a bit more?
> Unknown service name jboss.ejb and txn
> --------------------------------------
>
> Key: WFLY-12090
> URL: https://issues.jboss.org/browse/WFLY-12090
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 17.0.0.Alpha1
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Priority: Major
> Fix For: 17.0.0.Beta1
>
>
> When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have the following sort of error:
> {code}
> 16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171)
> at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb
> at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429)
> at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46)
> at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn
> ... 6 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka edited comment on WFLY-12090 at 5/21/19 7:10 AM:
------------------------------------------------------------------
[~tomjenkinson] yes, I think both option are possible but maybe not so easy to implement. If there is a way to define a service dependency tree then IMHO it's easier. But it depends on if it's possible.
[~flavia.rainone] I'm searching the code a bit (the dependencies are a bit complex thus I could be missing details) but the EJBRemotingService depends on the txn remote service but not on the recovery service, doesn't it? I mean having the dependency tree like
{code}
+----------+
| |
+ v
EJB service TXN Service
^ ^
| | (R.S. is depending on TXN S.)
+ +
Recovery Service
{code}
in case you appreciate it I can try to research on this a bit more?
was (Author: ochaloup):
[~tomjenkinson] yes, I think both option are possible but maybe not so easy to implement. If there is a way to define a service dependency tree then IMHO it's easier. But it depends on if it's possible.
[~flavia.rainone] I'm searching the code a bit (the dependencies are a bit complex thus I could be missing details) but the EJBRemotingService depends on the txn remote service but not on the recovery service, doesn't it? I mean having the dependency tree like
{code}
+----------+
| |
+ v
EJB service TXN Service
^ ^
| | (R.S. depends on TXN S.)
+ +
Recovery Service
{code}
in case you appreciate it I can try to research on this a bit more?
> Unknown service name jboss.ejb and txn
> --------------------------------------
>
> Key: WFLY-12090
> URL: https://issues.jboss.org/browse/WFLY-12090
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 17.0.0.Alpha1
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Priority: Major
> Fix For: 17.0.0.Beta1
>
>
> When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have the following sort of error:
> {code}
> 16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171)
> at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb
> at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429)
> at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46)
> at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn
> ... 6 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka commented on WFLY-12090:
-----------------------------------------
[~tomjenkinson] yes, I think both option are possible but maybe not so easy to implement. If there is a way to define a service dependency tree then IMHO it's easier. But it depends on if it's possible.
[~flavia.rainone] I'm searching the code a bit (the dependencies are a bit complex thus I could be missing details) but the EJBRemotingService depends on the txn remote service but not on the recovery service, doesn't it? I mean having the dependency tree like
{code}
+----------+
| |
+ v
EJB service TXN Service
^ ^
| |
+ +
Recovery Service
{code}
in case you appreciate it I can try to research on this a bit more?
> Unknown service name jboss.ejb and txn
> --------------------------------------
>
> Key: WFLY-12090
> URL: https://issues.jboss.org/browse/WFLY-12090
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 17.0.0.Alpha1
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Priority: Major
> Fix For: 17.0.0.Beta1
>
>
> When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have the following sort of error:
> {code}
> 16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171)
> at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb
> at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429)
> at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46)
> at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn
> ... 6 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-4059) Unable to test dmn context
by Daniele Zonca (Jira)
[ https://issues.jboss.org/browse/DROOLS-4059?page=com.atlassian.jira.plugi... ]
Daniele Zonca updated DROOLS-4059:
----------------------------------
Sprint: 2019 Week 20-22
> Unable to test dmn context
> --------------------------
>
> Key: DROOLS-4059
> URL: https://issues.jboss.org/browse/DROOLS-4059
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.22.0.Final
> Reporter: Jozef Marko
> Assignee: Daniele Zonca
> Priority: Major
> Labels: ScenarioSimulation
> Attachments: Screenshot from 2019-05-21 10-37-01.png, Screenshot from 2019-05-21 10-37-22.png, dmn.zip
>
>
> There is issue with scenario, that verifies dmn context. The attached scenario was created in the way shown in the picture. From the dialog with expected and actual value I clicked *Apply* button to fix scenarios. However after rerun, there is exception that value can not be parsed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-4059) Unable to test dmn context
by Daniele Zonca (Jira)
[ https://issues.jboss.org/browse/DROOLS-4059?page=com.atlassian.jira.plugi... ]
Daniele Zonca updated DROOLS-4059:
----------------------------------
Story Points: 2
> Unable to test dmn context
> --------------------------
>
> Key: DROOLS-4059
> URL: https://issues.jboss.org/browse/DROOLS-4059
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.22.0.Final
> Reporter: Jozef Marko
> Assignee: Daniele Zonca
> Priority: Major
> Labels: ScenarioSimulation
> Attachments: Screenshot from 2019-05-21 10-37-01.png, Screenshot from 2019-05-21 10-37-22.png, dmn.zip
>
>
> There is issue with scenario, that verifies dmn context. The attached scenario was created in the way shown in the picture. From the dialog with expected and actual value I clicked *Apply* button to fix scenarios. However after rerun, there is exception that value can not be parsed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months