[JBoss JIRA] (DROOLS-4064) Improve keyboard usability in Test Scenario
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4064?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4064:
--------------------------------
Labels: ScenarioSimulation drools-tools (was: ScenarioSimulation)
> Improve keyboard usability in Test Scenario
> -------------------------------------------
>
> Key: DROOLS-4064
> URL: https://issues.jboss.org/browse/DROOLS-4064
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Daniele Zonca
> Priority: Major
> Labels: ScenarioSimulation, drools-tools
>
> Implement additional keyboard navigation's path to cover this use case:
> "When I use TAB the next cell is highlighted but it's not in edit mode, so I have to press enter to enter in edit mode. If I press TAB twice, I lose the cell focus (my browser bring the focus on the address bar!) I expect the same behavior of google sheet." ([~dmarrazzo])
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-4060) CSS bug in Test Scenario setting panel when namespace is long
by Sarah Rambacher (Jira)
[ https://issues.jboss.org/browse/DROOLS-4060?page=com.atlassian.jira.plugi... ]
Sarah Rambacher commented on DROOLS-4060:
-----------------------------------------
The overflow happens because there is a fixed height on a .form-control. However, the best fix is to use {{<input type="text" readonly>}} for fields that are readonly rather than making them a {{<span class="form-control">}} to simulate it.
> CSS bug in Test Scenario setting panel when namespace is long
> -------------------------------------------------------------
>
> Key: DROOLS-4060
> URL: https://issues.jboss.org/browse/DROOLS-4060
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Sarah Rambacher
> Priority: Minor
> Labels: ScenarioSimulation, UXTeam
> Attachments: Screenshot from 2019-05-21 18-10-29.png, dmn-simple.dmn
>
>
> In DMN Test scenario, if namespace is long there is a minor visual bug (see screenshot attached).
> Use attached dmn file to reproduce it
--
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 Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ]
Flavia Rainone commented on WFLY-12090:
---------------------------------------
Btw, for reference, the discussion with of the possible solutions is in ZulipChat, wildfly-developer stream, "WFLY-12090" topic.
> 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 Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ]
Flavia Rainone edited comment on WFLY-12090 at 5/22/19 9:57 AM:
----------------------------------------------------------------
Btw, for reference, the discussion with Brian about the possible solutions is in ZulipChat, wildfly-developer stream, "WFLY-12090" topic.
was (Author: flavia.rainone):
Btw, for reference, the discussion with of the possible solutions is in ZulipChat, wildfly-developer stream, "WFLY-12090" topic.
> 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 Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ]
Flavia Rainone edited comment on WFLY-12090 at 5/22/19 9:54 AM:
----------------------------------------------------------------
[~tomjenkinson] The explanation is that EJB deployment triggers EJBRemote startup and triggers RemotingTransactionServiceService startup (those services are lazy). Any of them will satisfy the recovery in the sense that they will trigger registration of "ejb" and "txn" as remote service (notice that these remote services are another type of service, they are not MSC services nor are related with capabilities, but they will leave Remoting in a satisfactory state so it can be used for communications with the other server).
Once those EJB components are missing, the RemotingTransacctionServiceService is installed but, given it is lazy, it does not start. The EJB themselves are not registered with the transactions, it is just a matter of dependency of MSC services in the server.
The only way to reproduce this bug is having pending XaSubordinateResources in the file system to be recovered without any app installed. The only way of having that is having a previous instance of the server gone bad and having the original application undeployed before the server restarts.
[~ochaloup] I'm not talking about WFTC-62. It appears that this bug does not exist, on a discussion in our weekly call with [~tomekadamski] I explained to him that the resources were supposed to not be removed unless there was the recovery afterwards, and he told me he didn't wait long enough to certify that, so he is going to review that Jira at some point to see if it was a misunderstanding of the algorithm or if there is really a bug. I'm talking about the files not being removed because there is no actual recovery being performed, i.e., those files represent a non-existent resource in the other server. I'm investigating to see what to do with that.
I'm submitting a patch soon for this, after a discussion with [~bstansberry2] the conclusion was that we should make RemotingTransactionServiceService active, vs keeping it lazy and adding a mechanism in wildfly-transaction-client that would create a service dependent on that service every time we needed to recover subordinate resources from the file system.
was (Author: flavia.rainone):
[~tomjenkinson] The explanation is that EJB deployment triggers EJBRemote startup and triggers RemotingTransactionServiceService startup (those services are lazy). Any of them will satisfy the recovery in the sense that they will trigger registration of "ejb" and "txn" as remote service (notice that these remote services are another type of service, they are not MSC services nor are related with capabilities, but they will leave Remoting in a satisfactory state so it can be used for communications with the other server).
Once those EJB components are missing, the RemotingTransacctionServiceService is installed but, given it is lazy, it does not start. The EJB themselves are not registered with the transactions, it is just a matter of dependency of MSC services in the server.
The only way to reproduce this bug is having pending XaSubordinateResources in the file system to be recovered without any app installed. The only way of having that is having a previous instance of the server gone bad and having the original application undeployed before the server restarts.
[~ochaloup] I'm not talking about WFTC-62. It appears that this bug does not exist, on a discussion in our weekly call with [~tomekadamski] I explained to him that the resources were supposed to not be removed unless there was the recovery afterwards, and he told me he didn't wait long enough to certify that, so he is going to review that Jira at some point to see if it was a misunderstanding of the algorithm or if there is really a bug. I'm talking about the files not being removed because there is no actual recovery being performed, i.e., those files represent a non-existent resource in the other server. I'm investigating to see what to do with that.
I'm submitting a patch soon for this, after a discussion with [~bstansberry2] the conclusion was that we should make RemotingServiceService active, vs keeping it lazy and adding a mechanism in wildfly-transaction-client that would create a service dependent on that service every time we needed to recover subordinate resources from the file system.
> 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