October 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4584) Scrolling during editing mode move cell in new position on the screen

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4584?page=com.atlassian.jira.plugi... ] Jozef Marko commented on DROOLS-4584: ------------------------------------- [~manstis][~karreiro] I guess this issue could happen also for DMN, what do you think? > Scrolling during editing mode move cell in new position on the screen > --------------------------------------------------------------------- > > Key: DROOLS-4584 > URL: https://issues.jboss.org/browse/DROOLS-4584 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.28.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Major > Labels: CustomerFocus > Attachments: image-2019-10-01-11-24-36-774.png > > > !image-2019-10-01-11-24-36-774.png|thumbnail! > Cell moves unexpectedly in editing mode > {color:red}*Failure*{color} > If you start edit any cell of a big grid and then scroll the input would move not in the right cell. > *Expected* > Input element moves with entire table -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-218) server scale down sometimes keeps data in client's data/ejb-xa-recovery

by Martin Simka (Jira)

[ https://issues.jboss.org/browse/WFWIP-218?page=com.atlassian.jira.plugin.... ] Martin Simka updated WFWIP-218: ------------------------------- Description: this follows up on WFWIP-206 While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful Scenario: *ejb client* (app tx-client, pod tx-client-0): * EJB business method ** lookup remote EJB ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ** call remote EJB *ejb server* (app tx-server, pod tx-server-0): * EJB business method ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client {noformat} /opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 {noformat} was: this follows up on WFWIP-206 While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful Scenario: *ejb client* (app tx-client, pod tx-client-0): * EJB business method ** lookup remote EJB ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ** call remote EJB *ejb server* (app tx-server, pod tx-server-0): * EJB business method ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} {noformat} /opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 {noformat} > server scale down sometimes keeps data in client's data/ejb-xa-recovery > ----------------------------------------------------------------------- > > Key: WFWIP-218 > URL: https://issues.jboss.org/browse/WFWIP-218 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Blocker > > this follows up on WFWIP-206 > While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful > Scenario: > *ejb client* (app tx-client, pod tx-client-0): > * EJB business method > ** lookup remote EJB > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ** call remote EJB > *ejb server* (app tx-server, pod tx-server-0): > * EJB business method > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} > Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client > {noformat} > /opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-218) server scale down sometimes keeps data in client's data/ejb-xa-recovery

by Martin Simka (Jira)

Martin Simka created WFWIP-218: ---------------------------------- Summary: server scale down sometimes keeps data in client's data/ejb-xa-recovery Key: WFWIP-218 URL: https://issues.jboss.org/browse/WFWIP-218 Project: WildFly WIP Issue Type: Bug Components: OpenShift Reporter: Martin Simka Assignee: Ondrej Chaloupka this follows up on WFWIP-206 While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful Scenario: *ejb client* (app tx-client, pod tx-client-0): * EJB business method ** lookup remote EJB ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ** call remote EJB *ejb server* (app tx-server, pod tx-server-0): * EJB business method ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} {noformat} /opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-198) EAP Operator long-term strategy

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFWIP-198?page=com.atlassian.jira.plugin.... ] Martin Choma closed WFWIP-198. ------------------------------ Resolution: Explained We have discussed with [~jmesnil] and strategy will be something along lines: Operator will expose just most useful options. If new option needs to be exposed user has to create RFE. If RFE will be not accepted he has to "turn off" operator and to be on his own. Loosing scale down transaction support provided by EAP7-1192. > EAP Operator long-term strategy > ------------------------------- > > Key: WFWIP-198 > URL: https://issues.jboss.org/browse/WFWIP-198 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > Labels: operator > > Facts: > # Operator creates and manges internaly several kubernetes objects; StatefulSet, Pod, Service, Routes. By rough estimation these kubernetes objects expose approximately 50 options[2]. Operator now expose approximately 10 options [1]. > # EAP7-1192 is currently designed in way operator is integral part of solution. You can not turn off operator to EAP7-1192 properly work. > # User cant touch internal Kubernetes objects. Operator manages them and can overwrite changes anytime. > So given these facts question is what is long-term strategy with Operator? > # Operator will provide all options of internal objects. Everything I am able to configure directly with Kubernetes objects I will be able to configure with Operator > # Operator will expose just most useful options. If user wants to make something special he has to "turn off" operator and to be on his own. (Loosing transaction support provided by EAP7-1192) > # Operator will expose just most useful options. If user wants to make something special he can and Operator won't overwritten his changes. (I dont know if it is feasible?) > [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#wil... > [2] > https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#pods... > https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#stat... > https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#serv... > https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#ingr... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4585) Focus doesn't moves after the selected cell

by Yeser Amer (Jira)

[ https://issues.jboss.org/browse/DROOLS-4585?page=com.atlassian.jira.plugi... ] Yeser Amer commented on DROOLS-4585: ------------------------------------ I confirm, it's present. Not a regression anyway. > Focus doesn't moves after the selected cell > ------------------------------------------- > > Key: DROOLS-4585 > URL: https://issues.jboss.org/browse/DROOLS-4585 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.28.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Major > Labels: CustomerFocus > > {color:red}*Failure*{color} > If you navigate cell that is obscured by the right panel in header then it dosen't automatically scrolls to it as it done for grid body. > *Expected* > Viewed part of grid follows the selected cell -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4585) Focus doesn't moves after the selected cell

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4585?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-4585: -------------------------------- Affects Version/s: 7.28.0.Final > Focus doesn't moves after the selected cell > ------------------------------------------- > > Key: DROOLS-4585 > URL: https://issues.jboss.org/browse/DROOLS-4585 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.28.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Major > Labels: CustomerFocus > > {color:red}*Failure*{color} > If you navigate cell that is obscured by the right panel in header then it dosen't automatically scrolls to it as it done for grid body. > *Expected* > Viewed part of grid follows the selected cell -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4586) Editing mode do not moves displayed part of grid to view the entire scenario description cell

by Anna Dupliak (Jira)

Anna Dupliak created DROOLS-4586: ------------------------------------ Summary: Editing mode do not moves displayed part of grid to view the entire scenario description cell Key: DROOLS-4586 URL: https://issues.jboss.org/browse/DROOLS-4586 Project: Drools Issue Type: Enhancement Components: Scenario Simulation and Testing Affects Versions: 7.28.0.Final Reporter: Anna Dupliak Assignee: Yeser Amer Attachments: image-2019-10-01-12-18-19-311.png !image-2019-10-01-12-18-19-311.png|thumbnail! Failure The input text is hidden by the panel even if it is currently in edit mode, so edited text is hidden -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4692) Upgrade WildFly Common to 1.5.2.Final

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-4692: ---------------------------------------- Summary: Upgrade WildFly Common to 1.5.2.Final Key: WFCORE-4692 URL: https://issues.jboss.org/browse/WFCORE-4692 Project: WildFly Core Issue Type: Component Upgrade Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4584) Scrolling during editing mode move cell in new position on the screen

by Anna Dupliak (Jira)

[ https://issues.jboss.org/browse/DROOLS-4584?page=com.atlassian.jira.plugi... ] Anna Dupliak updated DROOLS-4584: --------------------------------- Steps to Reproduce: # Go to Test Scenario Designer # Fill up the grid by right click clicking on *property* header and choose *Duplicate instance* # Repeat step 3 10 times to activate the ability of horizontal scrolling # Double click on cell to enable edit mode # Scroll horizontally was: # Go to Test Scenario Designer # Fill up the grid by right click clicking on *property* header and choose *Insert Colomn Left* # Repeat step 3 10 times to activate the ability of horizontal scrolling # Double click on cell to enable edit mode # Scroll horizontally > Scrolling during editing mode move cell in new position on the screen > --------------------------------------------------------------------- > > Key: DROOLS-4584 > URL: https://issues.jboss.org/browse/DROOLS-4584 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.28.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Major > Labels: CustomerFocus > Attachments: image-2019-10-01-11-24-36-774.png > > > !image-2019-10-01-11-24-36-774.png|thumbnail! > Cell moves unexpectedly in editing mode > {color:red}*Failure*{color} > If you start edit any cell of a big grid and then scroll the input would move not in the right cell. > *Expected* > Input element moves with entire table -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3460) KIE Server REST Command GetObjects with ObjectFilter not working

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3460?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-3460: -------------------------------- Sprint: 2019 Week 41-43 (from Okt 7) > KIE Server REST Command GetObjects with ObjectFilter not working > ---------------------------------------------------------------- > > Key: DROOLS-3460 > URL: https://issues.jboss.org/browse/DROOLS-3460 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 7.15.0.Final > Environment: RHEL 7.5, EAP 7.1.0, Drools 7.15.0.Final > Reporter: Balakrishnan Balasubramanian > Assignee: Mario Fusco > Priority: Major > > Filtering the facts in the GetObjectsCommand doesn't do any object filtering!. > Here are the two code pieces that were used to set the ObjectFilter into GetObjectsCommand, but didn't produce the expected filtered results. > *+Trial 1:+* > {code:java} > ObjectFilter filter = new ObjectFilter() { > @Override > public boolean accept(Object object) { > return object.getClass().getName().equals("a.b.c.PotentialFraudFact"); > } > }; > Command<?> getObjects = commandsFactory.newGetObjects(filter, "out"); > {code} > *+Trial 2:+* > > {code:java} > ClassObjectSerializationFilter filter = new ClassObjectSerializationFilter(PotentialFraudFact.class); > Command<?> getObjects = commandsFactory.newGetObjects(filter, "out"); > {code} > In the response, the "out" identifier has *all* facts, not just the ones matching the given filter. It's as if it ignores the filter. Also, no error messages appear in the console. > When a ClassObjectFilter is used instead of the aforementioned implementations, a ClassNotFoundException (_shown below_) for the a.b.c.PotentialFraudFact.class occurs. This is incorrect as the deployed container/KJAR has this class!. > > {code:java} > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.ClassNotFoundException: a.b.c.PotentialFraudFact from [Module "deployment.kie-server.war" from Service Module Loader] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at org.drools.core.ClassObjectSerializationFilter.accept(ClassObjectSerializationFilter.java:50) > ... 73 more > {code} > The issue is with this line https://github.com/kiegroup/drools/blob/4c6856223b8be47b4fc52c35423be8b50... where the class loader used to find the class couldn't find the class that corresponds to the given Fact. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2019