April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5263) [Test Scenario Editor] List does not initializing

by Anna Dupliak (Jira)

[ https://issues.redhat.com/browse/DROOLS-5263?page=com.atlassian.jira.plug... ] Anna Dupliak updated DROOLS-5263: --------------------------------- Description: Defect: If user create a list - typed fact and puts it to the Test Scenario, and use it in guided rule see [^PAM Issue with New Test Scenarios and lists.docx] Then test passes but rules are not getting fired. This feature implemented other way in legacy test scenario see the example: [^Legacy works with Lists.docx] Root case : We removed initialization of the list by default . Previously when you have been adding a fact to test scenario - it was automatically initializing so in the end you got in GIVEN list with one empty element Now If you add a list fact you are free to left it empty or initialize it with at least one element. Workaround: put in GIVEN section for the list at least one empty element Customer case details: https://gss.my.salesforce.com/5002K00000mr7eFQAQ#comment_a0a2K00000UQOQ2QAP was: Defect: If user create a list - typed fact and puts it to the Test Scenario, and use it in guided rule see [^PAM Issue with New Test Scenarios and lists.docx] Then test passes but rules are not getting fired. This feature implemented other way in legacy test scenario see the example: [^Legacy works with Lists.docx] Root case : We removed initialization of the list by default . Previously when you have been adding a fact to test scenario - it was automatically initializing so in the end you got in GIVEN list with one empty element Now If you add a list fact you are free to left it empty or initialize it with at least one element. Workaround: put in GIVEN section for the list at least one empty element > [Test Scenario Editor] List does not initializing > ------------------------------------------------- > > Key: DROOLS-5263 > URL: https://issues.redhat.com/browse/DROOLS-5263 > Project: Drools > Issue Type: Bug > Components: Test Scenarios Editor > Affects Versions: 7.36.0.Final > Reporter: Anna Dupliak > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > Attachments: Legacy works with Lists.docx, MySpace_List.zip, PAM Issue with New Test Scenarios and lists.docx, medPartBDate-NotOnRequest-MarketingNo.rdrl > > > Defect: If user create a list - typed fact and puts it to the Test Scenario, and use it in guided rule see [^PAM Issue with New Test Scenarios and lists.docx] > Then test passes but rules are not getting fired. > This feature implemented other way in legacy test scenario see the example: [^Legacy works with Lists.docx] > Root case : > We removed initialization of the list by default . > Previously when you have been adding a fact to test scenario - it was automatically initializing so in the end you got in GIVEN list with one empty element > Now If you add a list fact you are free to left it empty or initialize it with at least one element. > Workaround: put in GIVEN section for the list at least one empty element > Customer case details: > https://gss.my.salesforce.com/5002K00000mr7eFQAQ#comment_a0a2K00000UQOQ2QAP -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5263) [Test Scenario Editor] List does not initializing

by Anna Dupliak (Jira)

Anna Dupliak created DROOLS-5263: ------------------------------------ Summary: [Test Scenario Editor] List does not initializing Key: DROOLS-5263 URL: https://issues.redhat.com/browse/DROOLS-5263 Project: Drools Issue Type: Bug Components: Test Scenarios Editor Affects Versions: 7.36.0.Final Reporter: Anna Dupliak Assignee: Toni Rikkola Attachments: Legacy works with Lists.docx, MySpace_List.zip, PAM Issue with New Test Scenarios and lists.docx, medPartBDate-NotOnRequest-MarketingNo.rdrl Defect: If user create a list - typed fact and puts it to the Test Scenario, and use it in guided rule see [^PAM Issue with New Test Scenarios and lists.docx] Then test passes but rules are not getting fired. This feature implemented other way in legacy test scenario see the example: [^Legacy works with Lists.docx] Root case : We removed initialization of the list by default . Previously when you have been adding a fact to test scenario - it was automatically initializing so in the end you got in GIVEN list with one empty element Now If you add a list fact you are free to left it empty or initialize it with at least one element. Workaround: put in GIVEN section for the list at least one empty element -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13396) Tests for RESTEasy integration with WildFly Elytron - AuthenticationClient for Authentication / SSL

by Diana Vilkolakova (Jira)

Diana Vilkolakova created WFLY-13396: ---------------------------------------- Summary: Tests for RESTEasy integration with WildFly Elytron - AuthenticationClient for Authentication / SSL Key: WFLY-13396 URL: https://issues.redhat.com/browse/WFLY-13396 Project: WildFly Issue Type: Feature Request Components: Security Reporter: Diana Vilkolakova Assignee: Diana Vilkolakova This issue is for adding tests that test functionality of EAP7-1219, which is about making use of authentication configuration for Elytron in the RESTEasy client. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10388) Persistent EJB timer timed_object_id naming discrepancy

by Radovan Stancel (Jira)

[ https://issues.redhat.com/browse/WFLY-10388?page=com.atlassian.jira.plugi... ] Radovan Stancel resolved WFLY-10388. ------------------------------------ Resolution: Cannot Reproduce Closing as we are not able to reproduce it and we have no input from reporter > Persistent EJB timer timed_object_id naming discrepancy > ------------------------------------------------------- > > Key: WFLY-10388 > URL: https://issues.redhat.com/browse/WFLY-10388 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 12.0.0.Final > Reporter: Boris Pran > Assignee: Lukas Vydra > Priority: Major > > Persistent EJB timers created declaratively (with @Schedule) create timed_object_id without version information while timers created using TimerService API include version info from deployment unit. > This way after version upgrade @Schedule timers survive but TimerService API created ones are lost and need to be created again. > I also seems that old timers remain created or at least their definitions can be seen in jboss_ejb_timer table. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2471) Parse version from POM

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2471?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2471: -------------------------------- Hmm, cumbersome to read directly from pom.xml: the file may be missing from the classpath, e.g. IntelliJ does *not* by default copy it unless the POM is marked as resource... Perhaps it's better to copy {{JGROUPS_VERSION.properties}} to {{./classes}} (or {{target/classes}}) and replace placeholders with real values. This is already done in maven, and can be done in ant, too. > Parse version from POM > ---------------------- > > Key: JGRP-2471 > URL: https://issues.redhat.com/browse/JGRP-2471 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0.0.Alpha6 > > > Currently, the version is set in the POM (maven), but also in {{conf/JGROUPS_VERSION.properties}}. This is cumbersome, as we have to update both files on a release (and change the version back to {{XXX-SNAPSHOT}} after the release). > With the introduction of maven release-plugin, modifying the file is manual work that's unwanted. > Therefore get rid of {{JGROUPS-VERSION.properties}} and read the version directly from the POM. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5262) java.lang.Number import remains in the list of imports after deletion

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5262?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-5262: -------------------------------- Labels: drools-tools (was: ) > java.lang.Number import remains in the list of imports after deletion > --------------------------------------------------------------------- > > Key: DROOLS-5262 > URL: https://issues.redhat.com/browse/DROOLS-5262 > Project: Drools > Issue Type: Bug > Affects Versions: 7.37.0.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > Priority: Optional > Labels: drools-tools > Attachments: Screenshot from 2018-01-09 12-56-56.png > > > When you delete java.lang.Number from project's imports in the business central and you create some asset in this project, java.lang.Number is still present in External imports of the created asset. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5262) java.lang.Number import remains in the list of imports after deletion

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5262?page=com.atlassian.jira.plug... ] Jozef Marko moved RHDM-1324 to DROOLS-5262: ------------------------------------------- Project: Drools (was: Red Hat Decision Manager) Key: DROOLS-5262 (was: RHDM-1324) Workflow: GIT Pull Request workflow (was: CDW with docs v1) Docs QE Status: NEW Component/s: (was: Decision Central) Environment: (was: Firefox 52esr) Affects Build: (was: ER1) Affects Version/s: 7.37.0.Final (was: 7.0.0.GA) QE Status: NEW > java.lang.Number import remains in the list of imports after deletion > --------------------------------------------------------------------- > > Key: DROOLS-5262 > URL: https://issues.redhat.com/browse/DROOLS-5262 > Project: Drools > Issue Type: Bug > Affects Versions: 7.37.0.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > Priority: Optional > Attachments: Screenshot from 2018-01-09 12-56-56.png > > > When you delete java.lang.Number from project's imports in the business central and you create some asset in this project, java.lang.Number is still present in External imports of the created asset. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5262) java.lang.Number import remains in the list of imports after deletion

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5262?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-5262: -------------------------------- Sprint: 2020 Week 16-18 (from Apr 13) > java.lang.Number import remains in the list of imports after deletion > --------------------------------------------------------------------- > > Key: DROOLS-5262 > URL: https://issues.redhat.com/browse/DROOLS-5262 > Project: Drools > Issue Type: Bug > Affects Versions: 7.37.0.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > Priority: Optional > Attachments: Screenshot from 2018-01-09 12-56-56.png > > > When you delete java.lang.Number from project's imports in the business central and you create some asset in this project, java.lang.Number is still present in External imports of the created asset. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2471) Parse version from POM

by Bela Ban (Jira)

Bela Ban created JGRP-2471: ------------------------------ Summary: Parse version from POM Key: JGRP-2471 URL: https://issues.redhat.com/browse/JGRP-2471 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0.0.Alpha6 Currently, the version is set in the POM (maven), but also in {{conf/JGROUPS_VERSION.properties}}. This is cumbersome, as we have to update both files on a release (and change the version back to {{XXX-SNAPSHOT}} after the release). With the introduction of maven release-plugin, modifying the file is manual work that's unwanted. Therefore get rid of {{JGROUPS-VERSION.properties}} and read the version directly from the POM. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2457) Make time and byte values more legible

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2457?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2457: --------------------------- Fix Version/s: 5.0.0.Alpha6 (was: 5.0.0.Alpha5) > Make time and byte values more legible > -------------------------------------- > > Key: JGRP-2457 > URL: https://issues.redhat.com/browse/JGRP-2457 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0.0.Alpha6 > > > In an XML configuration, we can already define {{send_buf_size=20M}}, but when printing protocol attribute values, we'll print {{20000000}} instead. > Change this to print time and bytes values in a more readable format, for all protocol attributes. > Examples: > * {{max_credits=3000000}} -> {{max_credits=3m}} // bytes > * {{time=45000}} -> {{time=45s}} // time > * {{avg_delivery_time=250.09us}} (note the suffix) // time > * {{number_of_blockings=234986}} -> {{number_of_blockings=234'986}} // scalar -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 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 April 2020