January 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3517) [DMN Designer] Data Types - Constraints - Constraint property

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-3517?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-3517: ---------------------------------------- for example: {code:java} itemDefinition.getAllowedValues().getAdditionalAttributes().put(qname, "range"); {code} this should persist okay as long as {code:java} qname ~= new QName("http://...kie....", "constraintsType"); {code} > [DMN Designer] Data Types - Constraints - Constraint property > ------------------------------------------------------------- > > Key: DROOLS-3517 > URL: https://issues.jboss.org/browse/DROOLS-3517 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Carreiro > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools > > Currently the _Constraint dialog_ infers the {{Constraint type}} based on the value. > - A new property ({{kie:constraintType}}) needs to be added in the in {{itemDefinition.allowedValues}} element. See how the DMN file will look like: > {noformat} > <?xml version="1.0" ?> > <dmn:definitions ...> > <dmn:itemDefinition id="_C9B6988F-0302" name="tNum" isCollection="false"> > <dmn:typeRef>number</dmn:typeRef> > <dmn:allowedValues kie:constraintType="range" id="_F7A1878D-A464"> > <dmn:text>(1..200)</dmn:text> > </dmn:allowedValues> > </dmn:itemDefinition> > <dmndi:DMNDI> > <dmndi:DMNDiagram></dmndi:DMNDiagram> > </dmndi:DMNDI> > </dmn:definitions> > {noformat} > - Update the {{DataType}} class with the new property (from {{ItemDefinition.allowedValues}}); > - Use the new property in the {{DataTypeConstraintModal}} class to load the right component (instead of inferring the type). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3517) [DMN Designer] Data Types - Constraints - Constraint property

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-3517?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-3517: ---------------------------------------- understood thank [~karreiro]. Original pointer is valid for a custom QName: If the custom attributes are really, really, needed, this must be specified both on kie-wb but also inside the kie-dmn-model (which I would avoid due to the wide impact) similarly to what we did, in the past, here: https://github.com/kiegroup/drools/blob/7857f1886a569530e8a77f18540b6773a... but additionally, please don't modify kie-dmn-model, it should be enough as long as the `kie` namespace is managed on the root Definitions node to just add its valorization calling "getAdditionalAttributes()" and using that QName and the valorization with the String you want (must be a string as this is XML persisted) > [DMN Designer] Data Types - Constraints - Constraint property > ------------------------------------------------------------- > > Key: DROOLS-3517 > URL: https://issues.jboss.org/browse/DROOLS-3517 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Carreiro > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools > > Currently the _Constraint dialog_ infers the {{Constraint type}} based on the value. > - A new property ({{kie:constraintType}}) needs to be added in the in {{itemDefinition.allowedValues}} element. See how the DMN file will look like: > {noformat} > <?xml version="1.0" ?> > <dmn:definitions ...> > <dmn:itemDefinition id="_C9B6988F-0302" name="tNum" isCollection="false"> > <dmn:typeRef>number</dmn:typeRef> > <dmn:allowedValues kie:constraintType="range" id="_F7A1878D-A464"> > <dmn:text>(1..200)</dmn:text> > </dmn:allowedValues> > </dmn:itemDefinition> > <dmndi:DMNDI> > <dmndi:DMNDiagram></dmndi:DMNDiagram> > </dmndi:DMNDI> > </dmn:definitions> > {noformat} > - Update the {{DataType}} class with the new property (from {{ItemDefinition.allowedValues}}); > - Use the new property in the {{DataTypeConstraintModal}} class to load the right component (instead of inferring the type). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3517) [DMN Designer] Data Types - Constraints - Constraint property

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-3517?page=com.atlassian.jira.plugi... ] Matteo Mortari edited comment on DROOLS-3517 at 1/18/19 9:34 AM: ----------------------------------------------------------------- understood thank [~karreiro]. Original pointer is valid for a custom QName: https://github.com/kiegroup/drools/blob/7857f1886a569530e8a77f18540b6773a... but additionally, please don't modify kie-dmn-model, it should be enough as long as the `kie` namespace is managed on the root Definitions node to just add its valorization calling "getAdditionalAttributes()" and using that QName and the valorization with the String you want (must be a string as this is XML persisted) was (Author: tari_manga): understood thank [~karreiro]. Original pointer is valid for a custom QName: If the custom attributes are really, really, needed, this must be specified both on kie-wb but also inside the kie-dmn-model (which I would avoid due to the wide impact) similarly to what we did, in the past, here: https://github.com/kiegroup/drools/blob/7857f1886a569530e8a77f18540b6773a... but additionally, please don't modify kie-dmn-model, it should be enough as long as the `kie` namespace is managed on the root Definitions node to just add its valorization calling "getAdditionalAttributes()" and using that QName and the valorization with the String you want (must be a string as this is XML persisted) > [DMN Designer] Data Types - Constraints - Constraint property > ------------------------------------------------------------- > > Key: DROOLS-3517 > URL: https://issues.jboss.org/browse/DROOLS-3517 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Carreiro > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools > > Currently the _Constraint dialog_ infers the {{Constraint type}} based on the value. > - A new property ({{kie:constraintType}}) needs to be added in the in {{itemDefinition.allowedValues}} element. See how the DMN file will look like: > {noformat} > <?xml version="1.0" ?> > <dmn:definitions ...> > <dmn:itemDefinition id="_C9B6988F-0302" name="tNum" isCollection="false"> > <dmn:typeRef>number</dmn:typeRef> > <dmn:allowedValues kie:constraintType="range" id="_F7A1878D-A464"> > <dmn:text>(1..200)</dmn:text> > </dmn:allowedValues> > </dmn:itemDefinition> > <dmndi:DMNDI> > <dmndi:DMNDiagram></dmndi:DMNDiagram> > </dmndi:DMNDI> > </dmn:definitions> > {noformat} > - Update the {{DataType}} class with the new property (from {{ItemDefinition.allowedValues}}); > - Use the new property in the {{DataTypeConstraintModal}} class to load the right component (instead of inferring the type). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-554) Add missing Openshit API calls

by Hayk Hovsepyan (Jira)

[ https://issues.jboss.org/browse/SWSQE-554?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan commented on SWSQE-554: -------------------------------------- another PR merged: https://github.com/Kiali-QE/kiali-qe-python/pull/130 > Add missing Openshit API calls > ------------------------------ > > Key: SWSQE-554 > URL: https://issues.jboss.org/browse/SWSQE-554 > Project: Kiali QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > > Currently there are several areas in UI tests that do not have call to Openshift API for data comparison. > 1. Figure out which calls are missing to Openshift. > 2. Create API call. > 3. Create assertions on that results to compare with UI data. > 4. PR per area (API call). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9631) "Failed to reinstate timer" warning is shown when creating large number of EJB timers

by Bartosz Baranowski (Jira)

[ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski commented on WFLY-9631: ------------------------------------------ [~mmacik] - could you share code/conf of how JBPM handles timers? > "Failed to reinstate timer" warning is shown when creating large number of EJB timers > ------------------------------------------------------------------------------------- > > Key: WFLY-9631 > URL: https://issues.jboss.org/browse/WFLY-9631 > Project: WildFly > Issue Type: Bug > Components: EJB > Environment: EAP 7.0.8.GA > Oracle 12 c > [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27...] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema. > Reporter: Marián Macik > Assignee: Michal Jurc > Priority: Major > > Hi, [~manovotn], > as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM. > What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created: > {code:java} > WARN [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507 > at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290) > at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169) > at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235) > at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > {code} > The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance. > Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred. > So I think it has something to do with refresh interval. > Can you please have a look at it? For further configuration details, check the Environment field. > Thank you very much! > Marian Macik -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11607) WFTC-54 - Integration with Narayana fails when timeout propagation over remote call declares it as '0' causing UserTransaction timeout to not work

by Ivo Studensky (Jira)

[ https://issues.jboss.org/browse/WFLY-11607?page=com.atlassian.jira.plugin... ] Ivo Studensky moved JBEAP-16230 to WFLY-11607: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-11607 (was: JBEAP-16230) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Transactions (was: Transactions) Affects Version/s: (was: 7.2.0.GA) Fix Version/s: (was: 7.2.1.GA) > WFTC-54 - Integration with Narayana fails when timeout propagation over remote call declares it as '0' causing UserTransaction timeout to not work > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-11607 > URL: https://issues.jboss.org/browse/WFLY-11607 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Priority: Major > > If the remote call passes transaction context where timeout is set as `0` then Narayana consider that value as transaction which should never be timetouted. But the wfly txn client consider the `0` as correct timeout value which means kind of `immediate timeout`. > The Narayana AtomicAction class consider it as -1[2] (which is used for subordinate transaction[3]) while the transaction reaper consider the value of no timeout to be 0[4]. > The client decreases[1] the timeout based on how much time elapsed from the transaction was started till time the remote call is to be accomplished. That means the timeout `0` can be passes even the transaction is not meant as `to never timeout`. > [1] https://github.com/wildfly/wildfly-transaction-client/blob/1.1.2.Final/sr... > [2] https://github.com/jbosstm/narayana/blob/5.9.2.Final/ArjunaCore/arjuna/cl... > [3] https://github.com/jbosstm/narayana/blob/5.9.2.Final/ArjunaJTA/jta/classe... > [4] https://github.com/jbosstm/narayana/blob/5.9.2.Final/ArjunaCore/arjuna/cl... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11607) WFTC-54 - Integration with Narayana fails when timeout propagation over remote call declares it as '0' causing UserTransaction timeout to not work

by Ivo Studensky (Jira)

[ https://issues.jboss.org/browse/WFLY-11607?page=com.atlassian.jira.plugin... ] Ivo Studensky updated WFLY-11607: --------------------------------- Labels: downstream_dependency (was: ) > WFTC-54 - Integration with Narayana fails when timeout propagation over remote call declares it as '0' causing UserTransaction timeout to not work > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-11607 > URL: https://issues.jboss.org/browse/WFLY-11607 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Priority: Major > Labels: downstream_dependency > > If the remote call passes transaction context where timeout is set as `0` then Narayana consider that value as transaction which should never be timetouted. But the wfly txn client consider the `0` as correct timeout value which means kind of `immediate timeout`. > The Narayana AtomicAction class consider it as -1[2] (which is used for subordinate transaction[3]) while the transaction reaper consider the value of no timeout to be 0[4]. > The client decreases[1] the timeout based on how much time elapsed from the transaction was started till time the remote call is to be accomplished. That means the timeout `0` can be passes even the transaction is not meant as `to never timeout`. > [1] https://github.com/wildfly/wildfly-transaction-client/blob/1.1.2.Final/sr... > [2] https://github.com/jbosstm/narayana/blob/5.9.2.Final/ArjunaCore/arjuna/cl... > [3] https://github.com/jbosstm/narayana/blob/5.9.2.Final/ArjunaJTA/jta/classe... > [4] https://github.com/jbosstm/narayana/blob/5.9.2.Final/ArjunaCore/arjuna/cl... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11607) WFTC-54 - Integration with Narayana fails when timeout propagation over remote call declares it as '0' causing UserTransaction timeout to not work

by Ivo Studensky (Jira)

[ https://issues.jboss.org/browse/WFLY-11607?page=com.atlassian.jira.plugin... ] Ivo Studensky updated WFLY-11607: --------------------------------- Git Pull Request: (was: https://github.com/wildfly/jboss-ejb-client/pull/368, https://github.com/wildfly/wildfly-transaction-client/pull/64) > WFTC-54 - Integration with Narayana fails when timeout propagation over remote call declares it as '0' causing UserTransaction timeout to not work > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-11607 > URL: https://issues.jboss.org/browse/WFLY-11607 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Priority: Major > Labels: downstream_dependency > > If the remote call passes transaction context where timeout is set as `0` then Narayana consider that value as transaction which should never be timetouted. But the wfly txn client consider the `0` as correct timeout value which means kind of `immediate timeout`. > The Narayana AtomicAction class consider it as -1[2] (which is used for subordinate transaction[3]) while the transaction reaper consider the value of no timeout to be 0[4]. > The client decreases[1] the timeout based on how much time elapsed from the transaction was started till time the remote call is to be accomplished. That means the timeout `0` can be passes even the transaction is not meant as `to never timeout`. > [1] https://github.com/wildfly/wildfly-transaction-client/blob/1.1.2.Final/sr... > [2] https://github.com/jbosstm/narayana/blob/5.9.2.Final/ArjunaCore/arjuna/cl... > [3] https://github.com/jbosstm/narayana/blob/5.9.2.Final/ArjunaJTA/jta/classe... > [4] https://github.com/jbosstm/narayana/blob/5.9.2.Final/ArjunaCore/arjuna/cl... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11607) WFTC-54 - Integration with Narayana fails when timeout propagation over remote call declares it as '0' causing UserTransaction timeout to not work

by Ivo Studensky (Jira)

[ https://issues.jboss.org/browse/WFLY-11607?page=com.atlassian.jira.plugin... ] Ivo Studensky reassigned WFLY-11607: ------------------------------------ Assignee: Ondra Chaloupka (was: Ivo Studensky) > WFTC-54 - Integration with Narayana fails when timeout propagation over remote call declares it as '0' causing UserTransaction timeout to not work > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-11607 > URL: https://issues.jboss.org/browse/WFLY-11607 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Ivo Studensky > Assignee: Ondra Chaloupka > Priority: Major > Labels: downstream_dependency > > If the remote call passes transaction context where timeout is set as `0` then Narayana consider that value as transaction which should never be timetouted. But the wfly txn client consider the `0` as correct timeout value which means kind of `immediate timeout`. > The Narayana AtomicAction class consider it as -1[2] (which is used for subordinate transaction[3]) while the transaction reaper consider the value of no timeout to be 0[4]. > The client decreases[1] the timeout based on how much time elapsed from the transaction was started till time the remote call is to be accomplished. That means the timeout `0` can be passes even the transaction is not meant as `to never timeout`. > [1] https://github.com/wildfly/wildfly-transaction-client/blob/1.1.2.Final/sr... > [2] https://github.com/jbosstm/narayana/blob/5.9.2.Final/ArjunaCore/arjuna/cl... > [3] https://github.com/jbosstm/narayana/blob/5.9.2.Final/ArjunaJTA/jta/classe... > [4] https://github.com/jbosstm/narayana/blob/5.9.2.Final/ArjunaCore/arjuna/cl... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-562) PR Jobs To Run Only E2E API Method Tests

by Matt Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-562?page=com.atlassian.jira.plugin.... ] Matt Mahoney resolved SWSQE-562. -------------------------------- Resolution: Done > PR Jobs To Run Only E2E API Method Tests > ---------------------------------------- > > Key: SWSQE-562 > URL: https://issues.jboss.org/browse/SWSQE-562 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matt Mahoney > Assignee: Matt Mahoney > Priority: Major > > Change PR jobs to run on only the Api Method tests, and not the E2E entire suite. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2019