April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3854) DMN: Add a nested row to a new Structured data type by default

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3854?page=com.atlassian.jira.plugi... ] Elizabeth Clayton commented on DROOLS-3854: ------------------------------------------- [~dmarrazzo] [~karreiro] I'm breaking down the Epic into smaller jiras. * Concerning the adding a new structured data type scenario, could part of the resolution of this issue be: When creating a structured data type, the UI should start with a nested child row, by default? !Screen Shot 2019-04-03 at 4.15.11 PM.png|thumbnail! > DMN: Add a nested row to a new Structured data type by default > -------------------------------------------------------------- > > Key: DROOLS-3854 > URL: https://issues.jboss.org/browse/DROOLS-3854 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Elizabeth Clayton > Priority: Major > Labels: UX, UXTeam > Attachments: Screen Shot 2019-04-03 at 4.15.11 PM.png > > > Usability: Reduce the number of clicks / actions to add a nested element. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3854) DMN: Add a nested row to a new Structured data type by default

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3854?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-3854: -------------------------------------- Attachment: Screen Shot 2019-04-03 at 4.15.11 PM.png > DMN: Add a nested row to a new Structured data type by default > -------------------------------------------------------------- > > Key: DROOLS-3854 > URL: https://issues.jboss.org/browse/DROOLS-3854 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Elizabeth Clayton > Priority: Major > Labels: UX, UXTeam > Attachments: Screen Shot 2019-04-03 at 4.15.11 PM.png > > > Usability: Reduce the number of clicks / actions to add a nested element. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3854) DMN: Add a nested row to a new Structured data type by default

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3854?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-3854: -------------------------------------- Description: Usability: Reduce the number of clicks / actions to add a nested element. (was: When creating a structured data type, the UI should start with a nested child row, by default. ) > DMN: Add a nested row to a new Structured data type by default > -------------------------------------------------------------- > > Key: DROOLS-3854 > URL: https://issues.jboss.org/browse/DROOLS-3854 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Elizabeth Clayton > Priority: Major > Labels: UX, UXTeam > > Usability: Reduce the number of clicks / actions to add a nested element. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3854) DMN: Add a nested row to a new Structured data type by default

by Elizabeth Clayton (Jira)

Elizabeth Clayton created DROOLS-3854: ----------------------------------------- Summary: DMN: Add a nested row to a new Structured data type by default Key: DROOLS-3854 URL: https://issues.jboss.org/browse/DROOLS-3854 Project: Drools Issue Type: Task Components: DMN Editor Reporter: Elizabeth Clayton Assignee: Elizabeth Clayton When creating a structured data type, the UI should start with a nested child row, by default. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11940) [GSS](7.2.z) Default Value of local-receiver-pass-by-value in jboss-ejb-client Descriptor is Not Respected

by Brad Maxwell (Jira)

Brad Maxwell created WFLY-11940: ----------------------------------- Summary: [GSS](7.2.z) Default Value of local-receiver-pass-by-value in jboss-ejb-client Descriptor is Not Respected Key: WFLY-11940 URL: https://issues.jboss.org/browse/WFLY-11940 Project: WildFly Issue Type: Bug Components: EE, EJB Affects Versions: 11.0.0.Final, 12.0.0.Final, 13.0.0.Final Reporter: Brad Maxwell Assignee: Bartosz Baranowski Fix For: 16.0.0.Beta1, 16.0.0.Final Attachments: TestWAR.war The jboss-ejb-client.xml deployment descriptor file can be used to configure the pass semantics of the local EJB receiver using the local-receiver-pass-by-value attribute. As per the EJB spec, the default behaviour should be to pass by value, and this is appropriately reflected in the jboss-ejb-client XSD. As of Wildfly 11, the *omission* of the local-receiver-pass-by-value attribute in a jboss-ejb-client deployment descriptor actually results in remote EJB parameters and the return value being passed by reference as opposed to the documented default of being passed by value. It appears that this bug is a result of changes made for WFLY-5403. The root cause is that the EJBClientDescriptorMetaDataProcessor.java class only uses the pass-by-value receiver if the local-receiver-pass-by-value attribute is Boolean.TRUE (line 177 in 13.0.0.Final), but EJBClientDescriptor10Parser.java defaults the value to null if it is not included in the jboss-ejb-client.xml (line 132 in 13.0.0.Final). The old and working behaviour was to fallback to the value configured at the ejb subsystem level if the jboss-ejb-client.xml excluded the attribute. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3843) DMN Editor Decision Navigator differentiate icons for DRGElement

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3843?page=com.atlassian.jira.plugi... ] Elizabeth Clayton commented on DROOLS-3843: ------------------------------------------- [~manstis] Perfect, glad I'm on the same page. :) WRT the expression types, I defer to you and [~tirelli]. My concern is that the tree might become a little visually busy. > DMN Editor Decision Navigator differentiate icons for DRGElement > ---------------------------------------------------------------- > > Key: DROOLS-3843 > URL: https://issues.jboss.org/browse/DROOLS-3843 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Matteo Mortari > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools, ux_needed > Attachments: dmn-icons.png, image-2019-04-03-10-38-39-270.png > > > In this example: > !image-2019-04-03-10-38-39-270.png|thumbnail! > The 1st one is a Decision, the other are Input Data. > Experienced DMN practitioner may know that a decision logic can only happen to Decision or BKM node, hence one could distinguish potential Input data node by not having decision logic (context in the example). But also what about Decision or BKM for which you didn't write the decision logic yet? > PLease consider distinguished icon for DRG Elements. > For example > leave Input Data with the filled circle > Decision: filled square > BKM: filled trapezoid. > Thanks -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3843) DMN Editor Decision Navigator differentiate icons for DRGElement

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-3843?page=com.atlassian.jira.plugi... ] Michael Anstis commented on DROOLS-3843: ---------------------------------------- [~uxdlc] That's almost exactly what I was saying too "We could just use mini versions of the images we use in the palette?"! I however prefer preserving the different icons we have for the different expression types (rows 31-37 in the spreadsheet). > DMN Editor Decision Navigator differentiate icons for DRGElement > ---------------------------------------------------------------- > > Key: DROOLS-3843 > URL: https://issues.jboss.org/browse/DROOLS-3843 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Matteo Mortari > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools, ux_needed > Attachments: dmn-icons.png, image-2019-04-03-10-38-39-270.png > > > In this example: > !image-2019-04-03-10-38-39-270.png|thumbnail! > The 1st one is a Decision, the other are Input Data. > Experienced DMN practitioner may know that a decision logic can only happen to Decision or BKM node, hence one could distinguish potential Input data node by not having decision logic (context in the example). But also what about Decision or BKM for which you didn't write the decision logic yet? > PLease consider distinguished icon for DRG Elements. > For example > leave Input Data with the filled circle > Decision: filled square > BKM: filled trapezoid. > Thanks -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11939) FineDatabasePersistenceWebFailoverTestCase fails intermittently

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-11939?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-11939: ---------------------------------- Affects Version/s: 16.0.0.Final > FineDatabasePersistenceWebFailoverTestCase fails intermittently > --------------------------------------------------------------- > > Key: WFLY-11939 > URL: https://issues.jboss.org/browse/WFLY-11939 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 16.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11920) A degraded mode cache cannot be made available again

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11920?page=com.atlassian.jira.plugin... ] Paul Ferraro closed WFLY-11920. ------------------------------- Resolution: Duplicate Issue Oops - this logic exists already. > A degraded mode cache cannot be made available again > ---------------------------------------------------- > > Key: WFLY-11920 > URL: https://issues.jboss.org/browse/WFLY-11920 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 16.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Needs new runtime operation that calls AdvancedCache.setAvailabilityMode(...) for a specific cache. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11937) WF transaction client returns XAER_RMERR during abort after server with subordinate transaction fails

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/WFLY-11937?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on WFLY-11937: ----------------------------------------- I do agree that RMERR seems wrong as the client side cannot know what happened on the server side. I am trying to read the steps to reproduce but it's not clear to me at what point server 1 tries to talk to server 2, is it during the commit? In other words what method is returning XAER_RMERR - is it in the log, do you have a link to the code where it is raised? I am thinking it is in the implementation of xa_prepare in WFTC? > WF transaction client returns XAER_RMERR during abort after server with subordinate transaction fails > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-11937 > URL: https://issues.jboss.org/browse/WFLY-11937 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 10.1.0.Final, 14.0.0.Final, 15.0.0.Final, 16.0.0.Final > Reporter: Ivan Straka > Assignee: Ondrej Chaloupka > Priority: Major > > *Scenario* > # Server1 enlists dummy XA resource and make JPA call > # Server1 calls a EJB on Server2 > # Server2 enlists dummy XA resource and make JPA call > # Server2 is halted at the beginning of dummy XA resource > # Transaction is supposed to be rolled back > We can see following lines in the log of Server1 > {code:java} > 2019-04-02 21:22:41,707 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.topLevelAbort for XAResourceRecord < resource:Subordinate XAResource at http-remoting://127.0.0.1:8180, txid:< formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff7f000001:-70ba203e:5ca3d272:2f, node_name=TWkA, branch_uid=0:ffff7f000001:-70ba203e:5ca3d272:35, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@531d7d94 >, record id=0:ffff7f000001:-70ba203e:5ca3d272:36 > 2019-04-02 21:22:41,708 WARN [com.arjuna.ats.jta] (default task-2) ARJUNA016045: attempted rollback of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff7f000001:-70ba203e:5ca3d272:2f, node_name=TWkA, branch_uid=0:ffff7f000001:-70ba203e:5ca3d272:35, subordinatenodename=null, eis_name=unknown eis name > (Subordinate XAResource at http-remoting://127.0.0.1:8180) failed with exception code XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0026: Failed to send protocol message to remote peer > at org.wildfly.transaction.client.provider.remoting.TransactionClientChannel.rollback(TransactionClientChannel.java:98) > at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer$1.rollback(RemotingRemoteTransactionPeer.java:149) > at org.wildfly.transaction.client.SubordinateXAResource.rollback(SubordinateXAResource.java:174) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:362) > 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.phase2Abort(BasicAction.java:1981) > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1519) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:75) > at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:88) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:261) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:362) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144) > 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.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:80) > 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:1377) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.jboss.remoting3.NotOpenException: Writes closed > at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:106) > at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:291) > at org.jboss.remoting3.util.MessageTracker.openMessage(MessageTracker.java:64) > at org.jboss.remoting3.util.InvocationTracker.allocateMessage(InvocationTracker.java:189) > at org.jboss.remoting3.util.InvocationTracker.allocateMessage(InvocationTracker.java:205) > at org.wildfly.transaction.client.provider.remoting.TransactionClientChannel.rollback(TransactionClientChannel.java:91) > ... 58 more > 2019-04-02 21:22:41,709 WARN [com.arjuna.ats.arjuna] (default task-2) ARJUNA012089: Top-level abort of action 0:ffff7f000001:-70ba203e:5ca3d272:2f received heuristic decision: TwoPhaseOutcome.HEURISTIC_HAZARD > {code} > *TLDR;* > Server2 is halted and Server1 gets XAER_RMERR. During abort/rollback Server2 is still down and Server1 gets XAER_RMERR. Result of this is that the transaction is in heuristic state and not rolled back. > Based of the XA spec (http://pubs.opengroup.org/onlinepubs/009680699/toc.pdf) the XAER_RMFAIL (or XA_RETRY) is the correct XAException error code. > _XAER_RMERR_ > a resource manager error occurred in the transaction branch > _XAER_RMFAIL_ > resource manager unavailable > _XA_RETRY_ > routine returned with no effect and may be reissued -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 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 April 2019