January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13019) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13019?page=com.atlassian.jira.plugi... ] Brian Stansberry reopened WFLY-13019: ------------------------------------- > Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN) > ---------------------------------------------------------------------------------- > > Key: WFLY-13019 > URL: https://issues.redhat.com/browse/WFLY-13019 > Project: WildFly > Issue Type: Bug > Reporter: Mark Sanchez > Assignee: Brian Stansberry > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13019) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)

by Mark Sanchez (Jira)

Mark Sanchez created WFLY-13019: ----------------------------------- Summary: Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN) Key: WFLY-13019 URL: https://issues.redhat.com/browse/WFLY-13019 Project: WildFly Issue Type: Bug Reporter: Mark Sanchez Assignee: Brian Stansberry -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13020) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)

by Mark Sanchez (Jira)

Mark Sanchez created WFLY-13020: ----------------------------------- Summary: Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN) Key: WFLY-13020 URL: https://issues.redhat.com/browse/WFLY-13020 Project: WildFly Issue Type: Bug Reporter: Mark Sanchez Assignee: Brian Stansberry -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13019) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)

by Mark Sanchez (Jira)

[ https://issues.redhat.com/browse/WFLY-13019?page=com.atlassian.jira.plugi... ] Mark Sanchez closed WFLY-13019. ------------------------------- Resolution: Done > Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN) > ---------------------------------------------------------------------------------- > > Key: WFLY-13019 > URL: https://issues.redhat.com/browse/WFLY-13019 > Project: WildFly > Issue Type: Bug > Reporter: Mark Sanchez > Assignee: Brian Stansberry > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13018) Multiple CallbackHandlerServices for the same mechanism (PLAIN)

by Mark Sanchez (Jira)

[ https://issues.redhat.com/browse/WFLY-13018?page=com.atlassian.jira.plugi... ] Mark Sanchez closed WFLY-13018. ------------------------------- Resolution: Done > Multiple CallbackHandlerServices for the same mechanism (PLAIN) > --------------------------------------------------------------- > > Key: WFLY-13018 > URL: https://issues.redhat.com/browse/WFLY-13018 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 18.0.1.Final > Reporter: Mark Sanchez > Assignee: Brian Stansberry > Priority: Major > Fix For: 17.0.1.Final > > > Error: > WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN) > We get an error with the following ldap configuration. This works for version 17. > > <security-realm name="ldap_security_realm"> > <server-identities> > <ssl> > <engine enabled-protocols="TLSv1.2"/> > <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/> > </ssl> > </server-identities> > <authentication> > <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true"> > <username-filter attribute="samaccountname"/> > </ldap> > </authentication> > </security-realm> > </security-realms> > <outbound-connections> > <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/> > </outbound-connections> > <management-interfaces> > <http-interface security-realm="ldap_security_realm"> > <http-upgrade enabled="true"/> > <socket interface="management" port="${jboss.management.http.port:9990}"/> > </http-interface> > </management-interfaces> -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13018) Multiple CallbackHandlerServices for the same mechanism (PLAIN)

by Mark Sanchez (Jira)

Mark Sanchez created WFLY-13018: ----------------------------------- Summary: Multiple CallbackHandlerServices for the same mechanism (PLAIN) Key: WFLY-13018 URL: https://issues.redhat.com/browse/WFLY-13018 Project: WildFly Issue Type: Bug Components: Build System Affects Versions: 18.0.1.Final Reporter: Mark Sanchez Assignee: Brian Stansberry Fix For: 17.0.1.Final Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN) We get an error with the following ldap configuration. This works for version 17. <security-realm name="ldap_security_realm"> <server-identities> <ssl> <engine enabled-protocols="TLSv1.2"/> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/> </ssl> </server-identities> <authentication> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true"> <username-filter attribute="samaccountname"/> </ldap> </authentication> </security-realm> </security-realms> <outbound-connections> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/> </outbound-connections> <management-interfaces> <http-interface security-realm="ldap_security_realm"> <http-upgrade enabled="true"/> <socket interface="management" port="${jboss.management.http.port:9990}"/> </http-interface> </management-interfaces> -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4985) A Spreadsheet decision tables does not convert to a DRL file correctly when a Function is being used in the RuleTable constraints

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-4985?page=com.atlassian.jira.plug... ] Toni Rikkola updated DROOLS-4985: --------------------------------- Sprint: 2020 Week 04-06 (from Jan 20) > A Spreadsheet decision tables does not convert to a DRL file correctly when a Function is being used in the RuleTable constraints > --------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-4985 > URL: https://issues.redhat.com/browse/DROOLS-4985 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor, XLS Score Card Editor > Reporter: Oscar Molina > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools, support > > The attached "test_functions.xlsx" spreadsheet which is being used for creating a “Spreadsheet decision tables” asset. This spreadsheet contains a “Function” and has some rules. These rules use the “Function” in the constraints. When this XLSX Decision Table is converted to a “Guided Decision Table”, the constraints are missing the “Function” calls. Surprisingly if the “Function” call is used in a System.out.println statement, the generated DRL correctly contains it. > A wrongly generated DRL rule > {code} > rule "Row 3 Hello RuleTable" > dialect "mvel" > when > $person : Person( gender == "Female" , married == true ) > then > $person.setHelloMsg( "Miss" ); > System.out.println(hello($person.getName(), "Miss", "how are you doing")); > end > {code} > Expected correct DRL rule > {code} > rule "Row 3 Hello RuleTable DRL" > dialect "mvel" > when > $person : Person( gender == "Female" , married == true ) > then > $person.setHelloMsg( hello($person.getName(), "Miss", "how are you doing") ); > System.out.println(hello($person.getName(), "Miss", "how are you doing")); > end > {code} > Regards, > Oscar. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4985) A Spreadsheet decision tables does not convert to a DRL file correctly when a Function is being used in the RuleTable constraints

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-4985?page=com.atlassian.jira.plug... ] Toni Rikkola moved RHDM-1211 to DROOLS-4985: -------------------------------------------- Project: Drools (was: Red Hat Decision Manager) Key: DROOLS-4985 (was: RHDM-1211) Workflow: GIT Pull Request workflow (was: CDW with docs v1) Docs QE Status: NEW Component/s: Guided Decision Table Editor XLS Score Card Editor (was: Decision Central) Affects Version/s: (was: 7.5.0.GA) (was: 7.5.1.GA) QE Status: NEW > A Spreadsheet decision tables does not convert to a DRL file correctly when a Function is being used in the RuleTable constraints > --------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-4985 > URL: https://issues.redhat.com/browse/DROOLS-4985 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor, XLS Score Card Editor > Reporter: Oscar Molina > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools, support > > The attached "test_functions.xlsx" spreadsheet which is being used for creating a “Spreadsheet decision tables” asset. This spreadsheet contains a “Function” and has some rules. These rules use the “Function” in the constraints. When this XLSX Decision Table is converted to a “Guided Decision Table”, the constraints are missing the “Function” calls. Surprisingly if the “Function” call is used in a System.out.println statement, the generated DRL correctly contains it. > A wrongly generated DRL rule > {code} > rule "Row 3 Hello RuleTable" > dialect "mvel" > when > $person : Person( gender == "Female" , married == true ) > then > $person.setHelloMsg( "Miss" ); > System.out.println(hello($person.getName(), "Miss", "how are you doing")); > end > {code} > Expected correct DRL rule > {code} > rule "Row 3 Hello RuleTable DRL" > dialect "mvel" > when > $person : Person( gender == "Female" , married == true ) > then > $person.setHelloMsg( hello($person.getName(), "Miss", "how are you doing") ); > System.out.println(hello($person.getName(), "Miss", "how are you doing")); > end > {code} > Regards, > Oscar. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4984) Enable the executable model in Optaplanner

by Luca Molteni (Jira)

Luca Molteni created DROOLS-4984: ------------------------------------ Summary: Enable the executable model in Optaplanner Key: DROOLS-4984 URL: https://issues.redhat.com/browse/DROOLS-4984 Project: Drools Issue Type: Bug Components: executable model Reporter: Luca Molteni Assignee: Luca Molteni Currently it's disabled -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1927) Release WildFly Elytron 1.11.2.Final

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1927?page=com.atlassian.jira.plugin.... ] Farah Juma resolved ELY-1927. ----------------------------- Resolution: Done > Release WildFly Elytron 1.11.2.Final > ------------------------------------ > > Key: ELY-1927 > URL: https://issues.redhat.com/browse/ELY-1927 > Project: WildFly Elytron > Issue Type: Release > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.11.2.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13017) cloud-server layer to extend jaxrs-server layer

by Jean Francois Denise (Jira)

Jean Francois Denise created WFLY-13017: ------------------------------------------- Summary: cloud-server layer to extend jaxrs-server layer Key: WFLY-13017 URL: https://issues.redhat.com/browse/WFLY-13017 Project: WildFly Issue Type: Bug Components: Build System Reporter: Jean Francois Denise Assignee: Jean Francois Denise cloud-server depends on cloud-profile although we want it to be an extension of jaxrs-server layer. This fix an internal refactoring that doesn't change the capabilities provisioned by the cloud-server layer. The benefit of this refactoring is that core layers datasources-web-server, jaxrs-server and cloud-server are designed the same way with consistent dependency tree. As an example, a provisioned cloud-server or jaxrs-server server with jpa excluded allows to use datasources support in both cases. The change imply: * Make jaxrs optional in jaxrs-server (was optional in cloud-profile). * Make cloud-server to depend on jaxrs-server. * Update community documentation. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4819) Add OperationDefinition generated by default SimpleResourceDefinition logic never contains parameters

by Paul Ferraro (Jira)

Paul Ferraro created WFCORE-4819: ------------------------------------ Summary: Add OperationDefinition generated by default SimpleResourceDefinition logic never contains parameters Key: WFCORE-4819 URL: https://issues.redhat.com/browse/WFCORE-4819 Project: WildFly Core Issue Type: Bug Components: Management Affects Versions: 11.0.0.Beta7 Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4920) Scenario simulation for DMN with collections throws en error

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-4920?page=com.atlassian.jira.plug... ] Yeser Amer commented on DROOLS-4920: ------------------------------------ [~danielezonca] To solve it, we need to evaluate how to modify (or remove) this statement in DMNScenarioValidation:85 {code:java} // error if direct mapping (= simple type) but it is a composite // NOTE: context is a special case so it is composite even if no fields are declared Type rootType = getRootType((BaseDMNTypeImpl) rootDMNType); if (!CONTEXT.equals(rootType) && steps.isEmpty() && rootDMNType.isComposite()) { {code} > Scenario simulation for DMN with collections throws en error > ------------------------------------------------------------ > > Key: DROOLS-4920 > URL: https://issues.redhat.com/browse/DROOLS-4920 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.31.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, urgent.dmn > > > If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time. > [1] > !Screenshot from 2020-01-08 14-14-05.png|thumbnail! > h3. Acceptance criteria > https://github.com/jboss-integration/bxms-qe-tests/pull/3048 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ] Matteo Mortari commented on DROOLS-4973: ---------------------------------------- I can confirm that in FEEL, like in most (common sense) programming languages, List is an (ordered) list of elements. Also comparing FEEL list with another FEEL list: !screenshot-1.png|thumbnail! which is consistent, expects the same elements, in the same order. > Defined DMN collection unary checks do not pass > ----------------------------------------------- > > Key: DROOLS-4973 > URL: https://issues.redhat.com/browse/DROOLS-4973 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Critical > Labels: drools-tools > Attachments: MySpace_eshop.zip, screenshot-1.png > > > Import the attached project and click Build, then Test. > The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-4973: ----------------------------------- Attachment: screenshot-1.png > Defined DMN collection unary checks do not pass > ----------------------------------------------- > > Key: DROOLS-4973 > URL: https://issues.redhat.com/browse/DROOLS-4973 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Critical > Labels: drools-tools > Attachments: MySpace_eshop.zip, screenshot-1.png > > > Import the attached project and click Build, then Test. > The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4975) Defined Rule collection unary checks do not pass

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-4975?page=com.atlassian.jira.plug... ] Yeser Amer commented on DROOLS-4975: ------------------------------------ [~jomarko] In this case the cause of the issue is exactly the same explained by [~danielezonca] in https://issues.redhat.com/browse/DROOLS-4950. Guided editor and collection defined by expression can't be considered semantically the same functionality. The second case simply uses the java.equals() to compare the objects (in this case the list) and for this reason the test fails in this case. Guided editor apply a more complex way to compare. Considering that, I propose to close this ticket and mark it as DUPLICATED of https://issues.redhat.com/browse/DROOLS-4950 > Defined Rule collection unary checks do not pass > ------------------------------------------------ > > Key: DROOLS-4975 > URL: https://issues.redhat.com/browse/DROOLS-4975 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Critical > Labels: drools-tools > Attachments: MySpace_filtering.zip > > > Import the attached project and click Build, then Test. > The re are defined equivalent tests. One test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor does not pass. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass

by Daniele Zonca (Jira)

[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ] Daniele Zonca commented on DROOLS-4973: --------------------------------------- [~tari_manga] Can you please confirm {{"?=[{Price:2000,Name:"PC"},{Price:3300,Name:"CAR"}]"}} is a list comparison that consider order too? > Defined DMN collection unary checks do not pass > ----------------------------------------------- > > Key: DROOLS-4973 > URL: https://issues.redhat.com/browse/DROOLS-4973 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Critical > Labels: drools-tools > Attachments: MySpace_eshop.zip > > > Import the attached project and click Build, then Test. > The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass

by Daniele Zonca (Jira)

[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ] Daniele Zonca edited comment on DROOLS-4973 at 1/27/20 10:48 AM: ----------------------------------------------------------------- [~tari_manga] Can you please confirm {code:java} "?=[{Price:3300,Name:"CAR"}, {Price:2000,Name:"PC"}]" {code} is a list comparison that consider order too? was (Author: danielezonca): [~tari_manga] Can you please confirm {{"?=[{Price:2000,Name:"PC"},{Price:3300,Name:"CAR"}]"}} is a list comparison that consider order too? > Defined DMN collection unary checks do not pass > ----------------------------------------------- > > Key: DROOLS-4973 > URL: https://issues.redhat.com/browse/DROOLS-4973 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Critical > Labels: drools-tools > Attachments: MySpace_eshop.zip > > > Import the attached project and click Build, then Test. > The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ] Yeser Amer edited comment on DROOLS-4973 at 1/27/20 10:45 AM: -------------------------------------------------------------- [~jomarko] [~danielezonca] The cause of the issue can be explained with the current logic used by FEEL evaluator to compare two collections. According to this logic, 2 collections are equals if they contain the same elements IN THE SAME ORDER. You can find this logic in {code:java} EvalHelper.java {code} class, line 651. Then, to solve the first failed test in the reported case, simply change {code:java} "?=[{Price:3300,Name:"CAR"}, {Price:2000,Name:"PC"}]" {code} to {code:java} "?=[{Price:2000,Name:"PC"},{Price:3300,Name:"CAR"}]" {code} and the test will pass with success. Don't know the reason of this logic in FEEL, if is expected or not. was (Author: yamer): [~jomarko] [~danielezonca] The cause of the issue can be explained with the current logic used by FEEL evaluator to compare two collections. According to this logic, 2 collections are equals if they contain the same elements IN THE SAME ORDER. You can find this logic in EvalHelper.java class, line 651. Then, to solve the first failed test in the reported case, simply change {code:java} "?=[{Price:3300,Name:"CAR"}, {Price:2000,Name:"PC"}]" {code} to {code:java} "?=[{Price:2000,Name:"PC"},{Price:3300,Name:"CAR"}]" {code} and the test will pass with success. Don't know the reason of this logic in FEEL, if is expected or not. > Defined DMN collection unary checks do not pass > ----------------------------------------------- > > Key: DROOLS-4973 > URL: https://issues.redhat.com/browse/DROOLS-4973 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Critical > Labels: drools-tools > Attachments: MySpace_eshop.zip > > > Import the attached project and click Build, then Test. > The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ] Yeser Amer edited comment on DROOLS-4973 at 1/27/20 10:44 AM: -------------------------------------------------------------- [~jomarko] [~danielezonca] The cause of the issue can be explained with the current logic used by FEEL evaluator to compare two collections. According to this logic, 2 collections are equals if they contain the same elements IN THE SAME ORDER. You can find this logic in EvalHelper.java class, line 651. Then, to solve the first failed test in the reported case, simply change {code:java} "?=[{Price:3300,Name:"CAR"}, {Price:2000,Name:"PC"}]" {code} to {code:java} "?=[{Price:2000,Name:"PC"},{Price:3300,Name:"CAR"}]" {code} and the test will pass with success. Don't know the reason of this logic in FEEL, if is expected or not. was (Author: yamer): [~jomarko] [~danielezonca] The cause of the issue can be explained with the current logic used by FEEL evaluator to compare two collections. According to this logic, 2 collections are equals if they contain the same elements IN THE SAME ORDER. You can find this logic in EvalHelper.java class, line 651. Then, to solve the first failed test in the reported case, simply change "?=[{Price:3300,Name:"CAR"}, {Price:2000,Name:"PC"}]" to "?=[{Price:2000,Name:"PC"},{Price:3300,Name:"CAR"}]" and the test will pass with success. Don't know the reason of this logic in FEEL, if is expected or not. > Defined DMN collection unary checks do not pass > ----------------------------------------------- > > Key: DROOLS-4973 > URL: https://issues.redhat.com/browse/DROOLS-4973 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Critical > Labels: drools-tools > Attachments: MySpace_eshop.zip > > > Import the attached project and click Build, then Test. > The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ] Yeser Amer commented on DROOLS-4973: ------------------------------------ [~jomarko] [~danielezonca] The cause of the issue can be explained with the current logic used by FEEL evaluator to compare two collections. According to this logic, 2 collections are equals if they contain the same elements IN THE SAME ORDER. You can find this logic in EvalHelper.java class, line 651. Then, to solve the first failed test in the reported case, simply change "?=[{Price:3300,Name:"CAR"}, {Price:2000,Name:"PC"}]" to "?=[{Price:2000,Name:"PC"},{Price:3300,Name:"CAR"}]" and the test will pass with success. Don't know the reason of this logic in FEEL, if is expected or not. > Defined DMN collection unary checks do not pass > ----------------------------------------------- > > Key: DROOLS-4973 > URL: https://issues.redhat.com/browse/DROOLS-4973 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Critical > Labels: drools-tools > Attachments: MySpace_eshop.zip > > > Import the attached project and click Build, then Test. > The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4818) Upgrade WildFly Elytron to 1.11.2.Final

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFCORE-4818?page=com.atlassian.jira.plug... ] Farah Juma updated WFCORE-4818: ------------------------------- Fix Version/s: 11.0.0.Beta8 > Upgrade WildFly Elytron to 1.11.2.Final > --------------------------------------- > > Key: WFCORE-4818 > URL: https://issues.redhat.com/browse/WFCORE-4818 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 11.0.0.Beta8 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4818) Upgrade WildFly Elytron to 1.11.2.Final

by Farah Juma (Jira)

Farah Juma created WFCORE-4818: ---------------------------------- Summary: Upgrade WildFly Elytron to 1.11.2.Final Key: WFCORE-4818 URL: https://issues.redhat.com/browse/WFCORE-4818 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1860) Custom classloader in RpcDispatcher

by Todd Sandor (Jira)

[ https://issues.redhat.com/browse/JGRP-1860?page=com.atlassian.jira.plugin... ] Todd Sandor commented on JGRP-1860: ----------------------------------- Thanks Bela. I had a couple other porting questions, I sent them to " Porting-Guide/Release-Notes between 3.6.14 and 4.0.15" here javagroups-users(a)lists.sourceforge.net as they are not appropriate here. I did try to start a new "help" discussion here https://sourceforge.net/p/javagroups/discussion/18795/ but when I hit the "Send email to create a new topic" nothing seemed to occur ... Cheers > Custom classloader in RpcDispatcher > ----------------------------------- > > Key: JGRP-1860 > URL: https://issues.redhat.com/browse/JGRP-1860 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.2.13 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Major > Fix For: 3.4.5, 3.5 > > > RpcDispatcher is hard-coded to use JGroups' classloader when marshalling the users's custom objects over RPC. > RpcDispatcher uses Util.objectFromByteBuffer to unmarshall, which uses an ObjectInputStream. ObjectInputStream uses the classloader of its caller's class (Util). > RpcDispatcher does allow a custom marshaller to be used (implementing RpcDispatcher.Marshaller), but since Util.objectFromByteBuffer hard-codes the use of ObjectInputStream, a custom marshaller cannot simply set the classloader and then delegate back to the default JGroups code. > Util.objectFromBuffer should be enhanced to use a custom ObjectInputStream implementation that overrides resolveClass to use a custom classloader, and an API should be added to RpcDispatcher to pass in the classloader to use. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13009) moduleAvailability message is sent before module has started

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13009?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on WFLY-13009: -------------------------------------------- Just to note that there can be a significant difference between the time that deploymentAdded is called versus deploymentStarted in the case of @Singleton beans with the @Startup annotation. In this case, the bean with @Startup is asked to perform eager initialization (i.e. the bean is initialized before the deployment starts receiving requests) and there is a mechanism involving StartupCountdown which delays the firing of the deploymentStarted method until the eager initialization completes. This emphasises the fact that the moduleAvailable message really should be sent out on deploymentStarted and not deploymentAvailable. > moduleAvailability message is sent before module has started > ------------------------------------------------------------ > > Key: WFLY-13009 > URL: https://issues.redhat.com/browse/WFLY-13009 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 19.0.0.Beta1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > > When EJBs are deployed in a clustered server environment, moduleAvailability messages are sent from the server to all connected EJB client applications in order to inform the client that the module is available on that node. > The sending of moduleAvailability messages involves the DeploymentRepository, which records which modules are deployed, and the ModuleAvailabilityListener, which is a DeploymentRepositoryListener which gets called at various stages of module deployment (adding, starting, stopping). > It looks as though moduleAvailability message are being sent earlier than they should be; in other words, sent when the module is added to the repository and not when the module is later started. This can cause client invocations on the module to return a NoSuchEJBException even after the moduleAvailability message has been sent to the client, causing what is seen in EJBCLIENT-362. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12851) Upgrade PicketLink bindings from 2.5.5.SP12-redhat-00010 to 2.5.5.SP12-redhat-00012

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-12851?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFLY-12851: --------------------------------- Summary: Upgrade PicketLink bindings from 2.5.5.SP12-redhat-00010 to 2.5.5.SP12-redhat-00012 (was: Upgrade PicketLink bindings from 2.5.5.SP12-redhat-00010 to 2.5.5.SP12-redhat-00011) > Upgrade PicketLink bindings from 2.5.5.SP12-redhat-00010 to 2.5.5.SP12-redhat-00012 > ----------------------------------------------------------------------------------- > > Key: WFLY-12851 > URL: https://issues.redhat.com/browse/WFLY-12851 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Bartosz Spyrko > Assignee: Ilia Vassilev > Priority: Major > Labels: downstream_dependency > > Branch: https://github.com/jbossas/redhat-picketlink-bindings/tree/2.5.5.SP > Diff: > Commit hash: -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1927) Release WildFly Elytron 1.11.2.Final

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1927?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1927: ---------------------------- Fix Version/s: 1.11.2.CR1 > Release WildFly Elytron 1.11.2.Final > ------------------------------------ > > Key: ELY-1927 > URL: https://issues.redhat.com/browse/ELY-1927 > Project: WildFly Elytron > Issue Type: Release > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.11.2.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4983) Support java.util.Date and Character in engine

by Daniel José dos Santos (Jira)

Daniel José dos Santos created DROOLS-4983: ---------------------------------------------- Summary: Support java.util.Date and Character in engine Key: DROOLS-4983 URL: https://issues.redhat.com/browse/DROOLS-4983 Project: Drools Issue Type: Enhancement Components: core engine, DMN Editor Reporter: Daniel José dos Santos Assignee: Matteo Mortari Engine doesn't support Character as String and java.util.Date. See: PR: https://github.com/kiegroup/drools/pull/2733 RHDM-1145: https://issues.redhat.com/browse/RHDM-1145 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1057) Update pr jobs to use upstream-istio-pipeline

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1057?page=com.atlassian.jira.plugi... ] Filip Brychta commented on SWSQE-1057: -------------------------------------- Updated all https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/view/pr-jobs/ Now it runs correct job based on target branch of the PR. Missing part is maistra 1.1 builds, jobs are expecting it in quay.io/maistra with latest-1.1-qe tag. If it's going to be something different we have to change it. > Update pr jobs to use upstream-istio-pipeline > --------------------------------------------- > > Key: SWSQE-1057 > URL: https://issues.redhat.com/browse/SWSQE-1057 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > PR jobs are running upstream-pipeline job which is using downstream maistra builds. > We need to use upstream-istio-pipeline for PRs targeting master branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1057) Update pr jobs to use upstream-istio-pipeline

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1057?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1057. ---------------------------------- Resolution: Done > Update pr jobs to use upstream-istio-pipeline > --------------------------------------------- > > Key: SWSQE-1057 > URL: https://issues.redhat.com/browse/SWSQE-1057 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > PR jobs are running upstream-pipeline job which is using downstream maistra builds. > We need to use upstream-istio-pipeline for PRs targeting master branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1927) Release WildFly Elytron 1.11.2.Final

by Farah Juma (Jira)

Farah Juma created ELY-1927: ------------------------------- Summary: Release WildFly Elytron 1.11.2.Final Key: ELY-1927 URL: https://issues.redhat.com/browse/ELY-1927 Project: WildFly Elytron Issue Type: Release Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1926) Move wildfly-elytron-password-impl dependency in client from test scope to compile scope

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1926?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1926: ---------------------------- Fix Version/s: 1.11.2.CR1 > Move wildfly-elytron-password-impl dependency in client from test scope to compile scope > ---------------------------------------------------------------------------------------- > > Key: ELY-1926 > URL: https://issues.redhat.com/browse/ELY-1926 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Diana Vilkolakova > Assignee: Diana Vilkolakova > Priority: Major > Fix For: 1.11.2.CR1 > > > When using WebServicesClientConfigProviderImpl class from wildfly-elytron-client exception is thrown: > class configured for PasswordFactory (provider: WildFlyElytronPasswordProvider) cannot be found. org.wildfly.security.password.impl.PasswordFactorySpiImpl > This issue is to fix this. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2419) Update manual

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2419?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2419. ---------------------------- Resolution: Done > Update manual > ------------- > > Key: JGRP-2419 > URL: https://issues.redhat.com/browse/JGRP-2419 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0 > > > Update the manual to 5.0; add sections on {{Message}} implementations and {{MessageFactory}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4817) CliArgumentsTestCase fails if _JAVA_OPTIONS environment variable defined

by Paul Ferraro (Jira)

Paul Ferraro created WFCORE-4817: ------------------------------------ Summary: CliArgumentsTestCase fails if _JAVA_OPTIONS environment variable defined Key: WFCORE-4817 URL: https://issues.redhat.com/browse/WFCORE-4817 Project: WildFly Core Issue Type: Bug Components: Management Reporter: Paul Ferraro Assignee: Jeff Mesnil If the user has a _JAVA_OPTIONS environment variable defined, this test consistently fails - as it does not account for the fact that stuff may already have been written to stdout. e.g. {noformat} <failure message="expected:<[]Unknown argument: --...> but was:<[Picked up _JAVA_OPTIONS: -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel -Dswing.crossplatformlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel -Dawt.useSystemAAFontSettings=gasp -Djdk.gtk.version=3 -Dsun.java2d.opengl=true
]Unknown argument: --...>" type="org.junit.ComparisonFailure"><![CDATA[org.junit.ComparisonFailure: expected:<[]Unknown argument: --...> but was:<[Picked up _JAVA_OPTIONS: -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel -Dswing.crossplatformlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel -Dawt.useSystemAAFontSettings=gasp -Djdk.gtk.version=3 -Dsun.java2d.opengl=true ]Unknown argument: --...> {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter

by Guillaume Smet (Jira)

[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ] Guillaume Smet commented on WFLY-11566: --------------------------------------- [~tomekadamski] OK thanks. Just to be sure, the test you're talking about properly tests that the constraints defined are correctly enforced? > ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter > ---------------------------------------------------------------------------------- > > Key: WFLY-11566 > URL: https://issues.redhat.com/browse/WFLY-11566 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, EJB, REST > Affects Versions: 14.0.0.Final, 15.0.1.Final > Reporter: Alexander Wagner > Assignee: Tomasz Adamski > Priority: Critical > Labels: downstream_dependency > Attachments: WFLY-11566-3.tar > > > You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters. > As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine. > This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...] > Steps to reproduce: > {code:java} > @Stateless > @Path("/") > public class Resource { > @POST > @Path("put/list") > @Consumes(MediaType.APPLICATION_JSON) > public String putList(@NotEmpty List<String> a) { > return "Hello bars " + a.stream().collect(Collectors.joining(", ")); > } > } > {code} > {noformat} > [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list > javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List). > [mkopecky@dhcp-10-40-5-71 bin]$ > {noformat} > {noformat} > javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List). > at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24) > at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461) > at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377) > at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788) > at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648) > at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192) > at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160) > at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324) > at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159) > at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619) > at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254) > at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224) > at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177) > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118) > at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509) > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399) > at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363) > at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355) > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439) > at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229) > at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135) > at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355) > at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:791) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > {noformat} > Links: > * [forum|https://developer.jboss.org/thread/278822] > * WFLY-11566 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4979) Support static method invocation in accumulate

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4979?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-4979: -------------------------------- Description: {code:java} @Test public void testAccumulateOfDurationBetweenDateTime() { final String drl = "import java.time.Duration\n" + "import " + Interval.class.getCanonicalName() + ";\n" + "global java.util.List result; \n" + "\n" + "rule \"Rule1\"\n" + "when\n" + " $count : Number() from accumulate(\n" + " Interval($start : start, $end : end), " + " sum(Duration.between($start, $end).toMinutes()) " + " ) " + "then\n" + " result.add($count);\n" + "end\n"; List<Long> result = new ArrayList<>(); KieSession ksession = getKieSession(drl); ksession.setGlobal("result", result); ksession.insert(new Interval( LocalDateTime.of(2020, 1, 22, 11, 43), LocalDateTime.of(2020, 1, 22, 12, 43) )); ksession.fireAllRules(); assertEquals(60, result.iterator().next().longValue()); } {code} was: {code:java} @Test public void testAccumulateOfDurationBetweenDateTime() { final String drl = "import java.time.Duration\n" + "import " + Interval.class.getCanonicalName() + ";\n" + "global java.util.List result; \n" + "\n" + "rule \"Rule1\"\n" + "when\n" + " $count : Number() from accumulate(\n" + " Interval($start : start, $end : end), " + " sum(Duration.between($start, $end).toMinutes()) " + " ) " + "then\n" + " result.add($count);\n" + "end\n"; List<Long> result = new ArrayList<>(); KieSession ksession = getKieSession(drl); ksession.setGlobal("result", result); ksession.insert(new Interval( LocalDateTime.of(2020, 1, 22, 11, 43), LocalDateTime.of(2020, 1, 22, 12, 43) )); ksession.fireAllRules(); assertEquals(60, result.iterator().next().longValue()); } {code} Sprint: 2020 Week 04-06 (from Jan 20) > Support static method invocation in accumulate > ---------------------------------------------- > > Key: DROOLS-4979 > URL: https://issues.redhat.com/browse/DROOLS-4979 > Project: Drools > Issue Type: Bug > Reporter: Luca Molteni > Assignee: Mario Fusco > Priority: Major > > {code:java} > @Test > public void testAccumulateOfDurationBetweenDateTime() { > final String drl = > "import java.time.Duration\n" + > "import " + Interval.class.getCanonicalName() + ";\n" + > "global java.util.List result; \n" + > "\n" + > "rule \"Rule1\"\n" + > "when\n" + > " $count : Number() from accumulate(\n" + > " Interval($start : start, $end : end), " + > " sum(Duration.between($start, $end).toMinutes()) " + > " ) " + > "then\n" + > " result.add($count);\n" + > "end\n"; > List<Long> result = new ArrayList<>(); > KieSession ksession = getKieSession(drl); > ksession.setGlobal("result", result); > ksession.insert(new Interval( > LocalDateTime.of(2020, 1, 22, 11, 43), > LocalDateTime.of(2020, 1, 22, 12, 43) > )); > ksession.fireAllRules(); > assertEquals(60, result.iterator().next().longValue()); > } > {code} > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13016) Windows default install of wildfly as a service starts the service in an inconsistent directory JBOSS_HOME/bin

by Wild Fly (Jira)

[ https://issues.redhat.com/browse/WFLY-13016?page=com.atlassian.jira.plugi... ] Wild Fly closed WFLY-13016. --------------------------- Resolution: Rejected Does not belong to this issue tracker. > Windows default install of wildfly as a service starts the service in an inconsistent directory JBOSS_HOME/bin > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13016 > URL: https://issues.redhat.com/browse/WFLY-13016 > Project: WildFly > Issue Type: Enhancement > Components: Build System, Server > Affects Versions: 10.0.0.Final > Reporter: Wild Fly > Assignee: Brian Stansberry > Priority: Major > > Hi there, > Thanks for the amazing work on Wildfly so far! > I just ran into some configuration issue where I had to migrate a windows jboss server install to a linux one, with the files included at the root of the server working directory (java "user.dir" property). > The issue I had was that my linux wildfly server was not finding my files in its working directory although they were exactly at the same location relative to JBOSS_HOME and my code was not using absolute path. > After some research concerning the install scripts, I found that when installing wildfly as a service (ie. in background), each script (common.ps1, wildfly-init*.sh or service.bat) was specifying the working folder for that service. > And the issue is that it is not consistent across all scripts... well, in fact it is almost consistent, except for the .bat script which starts the service in JBOSS_HOME/bin as its working directory whereas the others scripts starts the service in JBOSS_HOME as its working directory. > I already located the bug at https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... > (the others two configurations are here : > https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... > and there : > https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... > ) > Thanks for taking this remark into account for enhanced cross-platform configuration! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13016) Windows default install of wildfly as a service starts the service in an inconsistent directory JBOSS_HOME/bin

by Wild Fly (Jira)

[ https://issues.redhat.com/browse/WFLY-13016?page=com.atlassian.jira.plugi... ] Wild Fly commented on WFLY-13016: --------------------------------- Sorry, I found after opening this issue that the wildfly-core project had its own issue tracker. > Windows default install of wildfly as a service starts the service in an inconsistent directory JBOSS_HOME/bin > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13016 > URL: https://issues.redhat.com/browse/WFLY-13016 > Project: WildFly > Issue Type: Enhancement > Components: Build System, Server > Affects Versions: 10.0.0.Final > Reporter: Wild Fly > Assignee: Brian Stansberry > Priority: Major > > Hi there, > Thanks for the amazing work on Wildfly so far! > I just ran into some configuration issue where I had to migrate a windows jboss server install to a linux one, with the files included at the root of the server working directory (java "user.dir" property). > The issue I had was that my linux wildfly server was not finding my files in its working directory although they were exactly at the same location relative to JBOSS_HOME and my code was not using absolute path. > After some research concerning the install scripts, I found that when installing wildfly as a service (ie. in background), each script (common.ps1, wildfly-init*.sh or service.bat) was specifying the working folder for that service. > And the issue is that it is not consistent across all scripts... well, in fact it is almost consistent, except for the .bat script which starts the service in JBOSS_HOME/bin as its working directory whereas the others scripts starts the service in JBOSS_HOME as its working directory. > I already located the bug at https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... > (the others two configurations are here : > https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... > and there : > https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... > ) > Thanks for taking this remark into account for enhanced cross-platform configuration! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4816) Windows default install of wildfly as a service starts the service in an inconsistent directory JBOSS_HOME/bin

by Wild Fly (Jira)

Wild Fly created WFCORE-4816: -------------------------------- Summary: Windows default install of wildfly as a service starts the service in an inconsistent directory JBOSS_HOME/bin Key: WFCORE-4816 URL: https://issues.redhat.com/browse/WFCORE-4816 Project: WildFly Core Issue Type: Enhancement Components: Build System, Scripts, Server Affects Versions: 10.0.0.Final Reporter: Wild Fly Assignee: Jeff Mesnil Hi there, Thanks for the amazing work on Wildfly so far! I just ran into some configuration issue where I had to migrate a windows jboss server install to a linux one, with the files included at the root of the server working directory (java "user.dir" property). The issue I had was that my linux wildfly server was not finding my files in its working directory although they were exactly at the same location relative to JBOSS_HOME and my code was not using absolute path. After some research concerning the install scripts, I found that when installing wildfly as a service (ie. in background), each script (common.ps1, wildfly-init*.sh or service.bat) was specifying the working folder for that service. And the issue is that it is not consistent across all scripts... well, in fact it is almost consistent, except for the .bat script which starts the service in JBOSS_HOME/bin as its working directory whereas the others scripts starts the service in JBOSS_HOME as its working directory. I already located the bug at https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... (the others two configurations are here : https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... and there : https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... ) Thanks for taking this remark into account for enhanced cross-platform configuration! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4974) Introduce KafkaStream API into HACep

by Massimiliano Dessi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4974?page=com.atlassian.jira.plug... ] Massimiliano Dessi updated DROOLS-4974: --------------------------------------- Sprint: 2020 Week 07-09 (from Feb 10) > Introduce KafkaStream API into HACep > ------------------------------------ > > Key: DROOLS-4974 > URL: https://issues.redhat.com/browse/DROOLS-4974 > Project: Drools > Issue Type: Feature Request > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4974) Introduce KafkaStream API into HACep

by Massimiliano Dessi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4974?page=com.atlassian.jira.plug... ] Massimiliano Dessi updated DROOLS-4974: --------------------------------------- Sprint: 2020 Week 04-06 (from Jan 20) (was: 2020 Week 07-09 (from Feb 10)) > Introduce KafkaStream API into HACep > ------------------------------------ > > Key: DROOLS-4974 > URL: https://issues.redhat.com/browse/DROOLS-4974 > Project: Drools > Issue Type: Feature Request > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1860) Custom classloader in RpcDispatcher

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-1860?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-1860: -------------------------------- Are you using JGroups directly? It shouldn't be difficult to port your app from 3.6 to 4.x. {{Marshaller}} was moved out of {{RpcDispatcher}} into its own interface. {{UUID}} may not be backwards-compatible, but it should be trivial to change your subclass... Note that running 3.6 and 4.x instances in the same cluster is not supported. You have to resort to an external package to make this happen: [1]. [1] https://github.com/jgroups-extras/RollingUpgrades > Custom classloader in RpcDispatcher > ----------------------------------- > > Key: JGRP-1860 > URL: https://issues.redhat.com/browse/JGRP-1860 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.2.13 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Major > Fix For: 3.4.5, 3.5 > > > RpcDispatcher is hard-coded to use JGroups' classloader when marshalling the users's custom objects over RPC. > RpcDispatcher uses Util.objectFromByteBuffer to unmarshall, which uses an ObjectInputStream. ObjectInputStream uses the classloader of its caller's class (Util). > RpcDispatcher does allow a custom marshaller to be used (implementing RpcDispatcher.Marshaller), but since Util.objectFromByteBuffer hard-codes the use of ObjectInputStream, a custom marshaller cannot simply set the classloader and then delegate back to the default JGroups code. > Util.objectFromBuffer should be enhanced to use a custom ObjectInputStream implementation that overrides resolveClass to use a custom classloader, and an API should be added to RpcDispatcher to pass in the classloader to use. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13016) Windows default install of wildfly as a service starts the service in an inconsistent directory JBOSS_HOME/bin

by Wild Fly (Jira)

Wild Fly created WFLY-13016: ------------------------------- Summary: Windows default install of wildfly as a service starts the service in an inconsistent directory JBOSS_HOME/bin Key: WFLY-13016 URL: https://issues.redhat.com/browse/WFLY-13016 Project: WildFly Issue Type: Enhancement Components: Build System, Server Affects Versions: 10.0.0.Final Reporter: Wild Fly Assignee: Brian Stansberry Hi there, Thanks for the amazing work on Wildfly so far! I just ran into some configuration issue where I had to migrate a windows jboss server install to a linux one, with the files included at the root of the server working directory (java "user.dir" property). The issue I had was that my linux wildfly server was not finding my files in its working directory although they were exactly at the same location relative to JBOSS_HOME and my code was not using absolute path. After some research concerning the install scripts, I found that when installing wildfly as a service (ie. in background), each script (common.ps1, wildfly-init*.sh or service.bat) was specifying the working folder for that service. And the issue is that it is not consistent across all scripts... well, in fact it is almost consistent, except for the .bat script which starts the service in JBOSS_HOME/bin as its working directory whereas the others scripts starts the service in JBOSS_HOME as its working directory. I already located the bug at https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... (the others two configurations are here : https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... and there : https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... ) Thanks for taking this remark into account for enhanced cross-platform configuration! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4980) Parameter content type in swagger doc for /server/containers/{containerId}/scesim is application/json

by Anna Dupliak (Jira)

[ https://issues.redhat.com/browse/DROOLS-4980?page=com.atlassian.jira.plug... ] Anna Dupliak updated DROOLS-4980: --------------------------------- Priority: Trivial (was: Minor) > Parameter content type in swagger doc for /server/containers/{containerId}/scesim is application/json > ----------------------------------------------------------------------------------------------------- > > Key: DROOLS-4980 > URL: https://issues.redhat.com/browse/DROOLS-4980 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.33.0.Final > Reporter: Anna Dupliak > Assignee: Daniele Zonca > Priority: Trivial > Labels: swagger > Attachments: image-2020-01-27-10-09-23-636.png > > > Parameter content type in swagger doc for */server/containers/{containerId}/scesim* is only *application/json* but the expected body content that is *application/xml* > !image-2020-01-27-10-09-23-636.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4980) Parameter content type in swagger doc for /server/containers/{containerId}/scesim is application/json

by Anna Dupliak (Jira)

Anna Dupliak created DROOLS-4980: ------------------------------------ Summary: Parameter content type in swagger doc for /server/containers/{containerId}/scesim is application/json Key: DROOLS-4980 URL: https://issues.redhat.com/browse/DROOLS-4980 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing Affects Versions: 7.33.0.Final Reporter: Anna Dupliak Assignee: Daniele Zonca Attachments: image-2020-01-27-10-09-23-636.png Parameter content type in swagger doc for */server/containers/{containerId}/scesim* is only *application/json* but the expected body content that is *application/xml* !image-2020-01-27-10-09-23-636.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4979) Support static method invocation in accumulate

by Luca Molteni (Jira)

Luca Molteni created DROOLS-4979: ------------------------------------ Summary: Support static method invocation in accumulate Key: DROOLS-4979 URL: https://issues.redhat.com/browse/DROOLS-4979 Project: Drools Issue Type: Bug Reporter: Luca Molteni Assignee: Mario Fusco {code:java} @Test public void testAccumulateOfDurationBetweenDateTime() { final String drl = "import java.time.Duration\n" + "import " + Interval.class.getCanonicalName() + ";\n" + "global java.util.List result; \n" + "\n" + "rule \"Rule1\"\n" + "when\n" + " $count : Number() from accumulate(\n" + " Interval($start : start, $end : end), " + " sum(Duration.between($start, $end).toMinutes()) " + " ) " + "then\n" + " result.add($count);\n" + "end\n"; List<Long> result = new ArrayList<>(); KieSession ksession = getKieSession(drl); ksession.setGlobal("result", result); ksession.insert(new Interval( LocalDateTime.of(2020, 1, 22, 11, 43), LocalDateTime.of(2020, 1, 22, 12, 43) )); ksession.fireAllRules(); assertEquals(60, result.iterator().next().longValue()); } {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1057) Update pr jobs to use upstream-istio-pipeline

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1057: ------------------------------------ Summary: Update pr jobs to use upstream-istio-pipeline Key: SWSQE-1057 URL: https://issues.redhat.com/browse/SWSQE-1057 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta PR jobs are running upstream-pipeline job which is using downstream maistra builds. We need to use upstream-istio-pipeline for PRs targeting master branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-91) Upgrade WildFly Elytron to 1.11.1.Final

by Darran Lofthouse (Jira)

Darran Lofthouse created ELYWEB-91: -------------------------------------- Summary: Upgrade WildFly Elytron to 1.11.1.Final Key: ELYWEB-91 URL: https://issues.redhat.com/browse/ELYWEB-91 Project: Elytron Web Issue Type: Component Upgrade Components: Parent Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.7.1.CR1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1926) Move wildfly-elytron-password-impl dependency in client from test scope to compile scope

by Diana Vilkolakova (Jira)

Diana Vilkolakova created ELY-1926: -------------------------------------- Summary: Move wildfly-elytron-password-impl dependency in client from test scope to compile scope Key: ELY-1926 URL: https://issues.redhat.com/browse/ELY-1926 Project: WildFly Elytron Issue Type: Bug Reporter: Diana Vilkolakova Assignee: Diana Vilkolakova When using WebServicesClientConfigProviderImpl class from wildfly-elytron-client exception is thrown: class configured for PasswordFactory (provider: WildFlyElytronPasswordProvider) cannot be found. org.wildfly.security.password.impl.PasswordFactorySpiImpl This issue is to fix this. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4978) Improve test coverage for PMML integration

by Jiri Petrlik (Jira)

Jiri Petrlik created DROOLS-4978: ------------------------------------ Summary: Improve test coverage for PMML integration Key: DROOLS-4978 URL: https://issues.redhat.com/browse/DROOLS-4978 Project: Drools Issue Type: Task Components: core engine Affects Versions: 7.33.0.Final Reporter: Jiri Petrlik Assignee: Jiri Petrlik Fix For: 7.33.0.Final Improve test coverage by testing more machine learning models: * Naive Bayes * Neural networks * k-Nearest Neighbors -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4959) Package name does not changes on copying of an existing package

by Nikos Tsekouras (Jira)

[ https://issues.redhat.com/browse/DROOLS-4959?page=com.atlassian.jira.plug... ] Nikos Tsekouras commented on DROOLS-4959: ----------------------------------------- Hi [~manstis]/[~Rikkola], Please be aware that same behavioral happens on project duplication. You can click on "duplicate" of a project but the inclusion remains the same as the original project. > Package name does not changes on copying of an existing package > --------------------------------------------------------------- > > Key: DROOLS-4959 > URL: https://issues.redhat.com/browse/DROOLS-4959 > Project: Drools > Issue Type: Bug > Affects Versions: 7.31.0.Final > Reporter: Nikos Tsekouras > Assignee: Toni Rikkola > Priority: Major > Attachments: step1.PNG, step2.PNG, step3.PNG, step4.PNG > > > After copying a package to a new one, all copied resources will remain referencing the existing one. > This becomes a bigger issue once you use guided rules, which their source cannot be edited. > Due to that, duplication alerts will be raised. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11963) ejb3 thread-pool thread-factory should be shown deprecated in management api

by Moulali Shikalwadi (Jira)

[ https://issues.redhat.com/browse/WFLY-11963?page=com.atlassian.jira.plugi... ] Moulali Shikalwadi reassigned WFLY-11963: ----------------------------------------- Assignee: Moulali Shikalwadi > ejb3 thread-pool thread-factory should be shown deprecated in management api > ---------------------------------------------------------------------------- > > Key: WFLY-11963 > URL: https://issues.redhat.com/browse/WFLY-11963 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 16.0.0.Final > Reporter: Chao Wang > Assignee: Moulali Shikalwadi > Priority: Major > > ejb3 thread-pool thread-factory should be shown deprecated in management api > The threads subsystem was deprecated and is not in the EAP 7.x configurations, so the thread-factory attribute on the ejb3 thread-pool configuration should indicate it is deprecated and should not be used. > {code} > /subsystem=ejb3/thread-pool=default:read-resource-description( > "thread-factory" => { > "type" => STRING, > "description" => "Specifies the name of a specific thread factory to use to create worker threads. If not defined an appropriate default thread factory will be used.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11963) ejb3 thread-pool thread-factory should be shown deprecated in management api

by Moulali Shikalwadi (Jira)

[ https://issues.redhat.com/browse/WFLY-11963?page=com.atlassian.jira.plugi... ] Moulali Shikalwadi commented on WFLY-11963: ------------------------------------------- Thanks [~soul2zimate] > ejb3 thread-pool thread-factory should be shown deprecated in management api > ---------------------------------------------------------------------------- > > Key: WFLY-11963 > URL: https://issues.redhat.com/browse/WFLY-11963 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 16.0.0.Final > Reporter: Chao Wang > Assignee: Moulali Shikalwadi > Priority: Major > > ejb3 thread-pool thread-factory should be shown deprecated in management api > The threads subsystem was deprecated and is not in the EAP 7.x configurations, so the thread-factory attribute on the ejb3 thread-pool configuration should indicate it is deprecated and should not be used. > {code} > /subsystem=ejb3/thread-pool=default:read-resource-description( > "thread-factory" => { > "type" => STRING, > "description" => "Specifies the name of a specific thread factory to use to create worker threads. If not defined an appropriate default thread factory will be used.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12733) EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment

by Rhuan Rocha (Jira)

[ https://issues.redhat.com/browse/WFLY-12733?page=com.atlassian.jira.plugi... ] Rhuan Rocha commented on WFLY-12733: ------------------------------------ Hi, I think the option said by [~cfang] is a good option "The other option is to have getTimers() method always refresh internally before returning results." . I think it can be done, but it should provides a way to enable and disable this behavior via configuration file (domain.xml/standalone.xml) and CLI. What do you think [~brian.stansberry]? > EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment > -------------------------------------------------------------------------------------- > > Key: WFLY-12733 > URL: https://issues.redhat.com/browse/WFLY-12733 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Rhuan Rocha > Assignee: Cheng Fang > Priority: Major > Fix For: 20.0.0.Beta1 > > > The EJB Timer has a way to persist timers in a database using datasources. It is described [here|https://docs.jboss.org/author/display/WFLY10/EJB3+Clustered+Database...]. The database-data-store has an attribute called refresh-interval that define a time in milliseconds to refresh the timers reading the timers from database. Look this sample of configuration. > > {code:java} > <data-stores> > <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/> > <database-data-store name="clustered-store" datasource-jndi-name="java:/jdbc/MyDataSource" partition="timer" refresh-interval="60000" allow-execution="true"/> > </data-stores> > {code} > The RFE is to Wildfly provide a way to force the refresh programmatically. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11963) ejb3 thread-pool thread-factory should be shown deprecated in management api

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFLY-11963?page=com.atlassian.jira.plugi... ] Chao Wang commented on WFLY-11963: ---------------------------------- [~mshikalw] No, I am not. You can take it. Thanks. > ejb3 thread-pool thread-factory should be shown deprecated in management api > ---------------------------------------------------------------------------- > > Key: WFLY-11963 > URL: https://issues.redhat.com/browse/WFLY-11963 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 16.0.0.Final > Reporter: Chao Wang > Priority: Major > > ejb3 thread-pool thread-factory should be shown deprecated in management api > The threads subsystem was deprecated and is not in the EAP 7.x configurations, so the thread-factory attribute on the ejb3 thread-pool configuration should indicate it is deprecated and should not be used. > {code} > /subsystem=ejb3/thread-pool=default:read-resource-description( > "thread-factory" => { > "type" => STRING, > "description" => "Specifies the name of a specific thread factory to use to create worker threads. If not defined an appropriate default thread factory will be used.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13015) Consolidate common instances of DiscardAttributeChecker that discard an attribute set to the default value

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13015?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13015: -------------------------------- Description: Follows up on WFCORE-4814. Replace DiscardAttributeChecker instances that discard an attribute whose value is the attribute's default value with a singleton instance. (was: Follows up on This common implementation can be implemented more concisely, such that a single instance can be used for any attribute.) > Consolidate common instances of DiscardAttributeChecker that discard an attribute set to the default value > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-13015 > URL: https://issues.redhat.com/browse/WFLY-13015 > Project: WildFly > Issue Type: Enhancement > Components: Management > Affects Versions: 19.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Follows up on WFCORE-4814. Replace DiscardAttributeChecker instances that discard an attribute whose value is the attribute's default value with a singleton instance. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13015) Consolidate common instances of DiscardAttributeChecker that discard an attribute set to the default value

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13015?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13015: -------------------------------- Description: Follows up on This common implementation can be implemented more concisely, such that a single instance can be used for any attribute. was: A common transformer pattern for newly added attributes is to discard the attribute if the value is the default value, and reject if otherwise defined. e.g. {code:java} builder.getAttributeBuilder() .setDiscard(new DiscardAttributeChecker.DiscardAttributeValueChecker(ATTRIBUTE.getDefaultValue()), ATTRIBUTE); .addRejectCheck(RejectAttributeChecker.DEFINED) ; {code} This common implementation can be implemented more concisely, such that a single instance can be used for any attribute. > Consolidate common instances of DiscardAttributeChecker that discard an attribute set to the default value > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-13015 > URL: https://issues.redhat.com/browse/WFLY-13015 > Project: WildFly > Issue Type: Enhancement > Components: Management > Affects Versions: 19.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Follows up on > This common implementation can be implemented more concisely, such that a single instance can be used for any attribute. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4814) Consolidate common instances of DiscardAttributeChecker that discard an attribute set to the default value

by Paul Ferraro (Jira)

Paul Ferraro created WFCORE-4814: ------------------------------------ Summary: Consolidate common instances of DiscardAttributeChecker that discard an attribute set to the default value Key: WFCORE-4814 URL: https://issues.redhat.com/browse/WFCORE-4814 Project: WildFly Core Issue Type: Enhancement Components: Management Affects Versions: 11.0.0.Beta7 Reporter: Paul Ferraro Assignee: Paul Ferraro A common transformer pattern for newly added attributes is to discard the attribute if the value is the default value, and reject if otherwise defined. e.g. {code:java} builder.getAttributeBuilder() .setDiscard(new DiscardAttributeChecker.DiscardAttributeValueChecker(ATTRIBUTE.getDefaultValue()), ATTRIBUTE); .addRejectCheck(RejectAttributeChecker.DEFINED) ; {code} This common implementation can be implemented more concisely, such that a single instance can be used for any attribute. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4815) Consolidate common instances of DiscardAttributeChecker that discard an attribute set to the default value

by Paul Ferraro (Jira)

Paul Ferraro created WFCORE-4815: ------------------------------------ Summary: Consolidate common instances of DiscardAttributeChecker that discard an attribute set to the default value Key: WFCORE-4815 URL: https://issues.redhat.com/browse/WFCORE-4815 Project: WildFly Core Issue Type: Enhancement Components: Management Affects Versions: 11.0.0.Beta7 Reporter: Paul Ferraro Assignee: Paul Ferraro A common transformer pattern for newly added attributes is to discard the attribute if the value is the default value, and reject if otherwise defined. e.g. {code:java} builder.getAttributeBuilder() .setDiscard(new DiscardAttributeChecker.DiscardAttributeValueChecker(ATTRIBUTE.getDefaultValue()), ATTRIBUTE); .addRejectCheck(RejectAttributeChecker.DEFINED) ; {code} This common implementation can be implemented more concisely, such that a single instance can be used for any attribute. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13015) Consolidate common instances of DiscardAttributeChecker that discard an attribute set to the default value

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13015?page=com.atlassian.jira.plugi... ] Paul Ferraro moved WFCORE-4815 to WFLY-13015: --------------------------------------------- Project: WildFly (was: WildFly Core) Key: WFLY-13015 (was: WFCORE-4815) Component/s: Management (was: Management) Affects Version/s: 19.0.0.Beta1 (was: 11.0.0.Beta7) > Consolidate common instances of DiscardAttributeChecker that discard an attribute set to the default value > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-13015 > URL: https://issues.redhat.com/browse/WFLY-13015 > Project: WildFly > Issue Type: Enhancement > Components: Management > Affects Versions: 19.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > A common transformer pattern for newly added attributes is to discard the attribute if the value is the default value, and reject if otherwise defined. > e.g. > {code:java} > builder.getAttributeBuilder() > .setDiscard(new DiscardAttributeChecker.DiscardAttributeValueChecker(ATTRIBUTE.getDefaultValue()), ATTRIBUTE); > .addRejectCheck(RejectAttributeChecker.DEFINED) > ; > {code} > This common implementation can be implemented more concisely, such that a single instance can be used for any attribute. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4812) Consolidate instances of DefaultValueAttributeConverter

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFCORE-4812?page=com.atlassian.jira.plug... ] Paul Ferraro updated WFCORE-4812: --------------------------------- Description: DefaultValueAttributeConverter is perhaps the most commonly used attribute converter, used when the default value of a given attribute changes. The implementation in WFCORE uses a separate instance for each attribute. The default implementation can be implemented more concisely, such that a single instance can be used for any attribute. (was: DefaultValueAttributeConverter is perhaps the most common attribute converter, used when the default value of a given attribute changes. The implementation in WFCORE uses a separate instance for each attribute. The default implementation can be implemented more concisely, such that a single instance can be used for any attribute.) > Consolidate instances of DefaultValueAttributeConverter > ------------------------------------------------------- > > Key: WFCORE-4812 > URL: https://issues.redhat.com/browse/WFCORE-4812 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Affects Versions: 11.0.0.Beta7 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > DefaultValueAttributeConverter is perhaps the most commonly used attribute converter, used when the default value of a given attribute changes. The implementation in WFCORE uses a separate instance for each attribute. The default implementation can be implemented more concisely, such that a single instance can be used for any attribute. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13014) Consolidate instances of DefaultValueAttributeConverter

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13014?page=com.atlassian.jira.plugi... ] Paul Ferraro moved WFCORE-4813 to WFLY-13014: --------------------------------------------- Project: WildFly (was: WildFly Core) Key: WFLY-13014 (was: WFCORE-4813) Component/s: Management (was: Management) Affects Version/s: 19.0.0.Beta1 (was: 11.0.0.Beta7) > Consolidate instances of DefaultValueAttributeConverter > ------------------------------------------------------- > > Key: WFLY-13014 > URL: https://issues.redhat.com/browse/WFLY-13014 > Project: WildFly > Issue Type: Enhancement > Components: Management > Affects Versions: 19.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > DefaultValueAttributeConverter is perhaps the most common attribute converter, used when the default value of a given attribute changes. The implementation in WFCORE uses a separate instance for each attribute. The default implementation can be implemented more concisely, such that a single instance can be used for any attribute. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13014) Consolidate instances of DefaultValueAttributeConverter

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13014?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13014: -------------------------------- Description: Follows up on WFCORE-4812. Update instances of (was: DefaultValueAttributeConverter is perhaps the most common attribute converter, used when the default value of a given attribute changes. The implementation in WFCORE uses a separate instance for each attribute. The default implementation can be implemented more concisely, such that a single instance can be used for any attribute.) > Consolidate instances of DefaultValueAttributeConverter > ------------------------------------------------------- > > Key: WFLY-13014 > URL: https://issues.redhat.com/browse/WFLY-13014 > Project: WildFly > Issue Type: Enhancement > Components: Management > Affects Versions: 19.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Follows up on WFCORE-4812. Update instances of -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13014) Consolidate instances of DefaultValueAttributeConverter

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13014?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13014: -------------------------------- Description: Follows up on WFCORE-4812. Update individual instances of DefaultValueAttributeConverter to use a singleton instance. (was: Follows up on WFCORE-4812. Update instances of ) > Consolidate instances of DefaultValueAttributeConverter > ------------------------------------------------------- > > Key: WFLY-13014 > URL: https://issues.redhat.com/browse/WFLY-13014 > Project: WildFly > Issue Type: Enhancement > Components: Management > Affects Versions: 19.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Follows up on WFCORE-4812. Update individual instances of DefaultValueAttributeConverter to use a singleton instance. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4812) Consolidate instances of DefaultValueAttributeConverter

by Paul Ferraro (Jira)

Paul Ferraro created WFCORE-4812: ------------------------------------ Summary: Consolidate instances of DefaultValueAttributeConverter Key: WFCORE-4812 URL: https://issues.redhat.com/browse/WFCORE-4812 Project: WildFly Core Issue Type: Enhancement Components: Management Affects Versions: 11.0.0.Beta7 Reporter: Paul Ferraro Assignee: Paul Ferraro DefaultValueAttributeConverter is perhaps the most common attribute converter, used when the default value of a given attribute changes. The implementation in WFCORE uses a separate instance for each attribute. The default implementation can be implemented more concisely, such that a single instance can be used for any attribute. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4813) Consolidate instances of DefaultValueAttributeConverter

by Paul Ferraro (Jira)

Paul Ferraro created WFCORE-4813: ------------------------------------ Summary: Consolidate instances of DefaultValueAttributeConverter Key: WFCORE-4813 URL: https://issues.redhat.com/browse/WFCORE-4813 Project: WildFly Core Issue Type: Enhancement Components: Management Affects Versions: 11.0.0.Beta7 Reporter: Paul Ferraro Assignee: Paul Ferraro DefaultValueAttributeConverter is perhaps the most common attribute converter, used when the default value of a given attribute changes. The implementation in WFCORE uses a separate instance for each attribute. The default implementation can be implemented more concisely, such that a single instance can be used for any attribute. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13013) Elytron LDAP can't set-password in Active Directory or react to external changes

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13013?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFLY-13013: --------------------------------------- Assignee: (was: Darran Lofthouse) > Elytron LDAP can't set-password in Active Directory or react to external changes > -------------------------------------------------------------------------------- > > Key: WFLY-13013 > URL: https://issues.redhat.com/browse/WFLY-13013 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 18.0.1.Final, 19.0.0.Beta1 > Reporter: David Guthrie > Priority: Major > Labels: active-directory, cache, elytron, ldap > > The caching realm seems to work as advertised with open ldap and Red Hat Directory Server when I add a user-password-mapper after setting: > <user-password-mapper from="userPassword" writable="true" verifiable="true" /> > When I change the password in LDAP, the caching realm reacts, and I can login with the new password. Also when I call `set-password`: > /subsystem=elytron/ldap-realm=ldap-realm:set-password(identity=testUser, clear= > {password="1A3b6w"} > ) > It changes the password correctly in LDAP. > Neither of these work in Active Directory. Active Directory stores the password, by default using the field "UnicodePwd" rather than "userPassword", so I tried having them map the user password to that field: > /subsystem=elytron/ldap-realm=ldap-realm:write-attribute(name=identity-mapping.user-password-mapper.from, value=UnicodePwd) > But it it can't set the password because the password code needs to write it with a different character set when writing to active directory. See the different between the code in ldap/UserPasswordCredentialLoader.java and in the special case for Active Directory in Keycloak[1] > It can't react to external changes to the directory because Active Directory doesn't support the listening mechanism used. > There is a potential to be able to change the active directory settings so "userPassword" runs in compatibility mode[2], but that's not a normal thing to be able to do is most environments. > [1] Keycloak - AD UnicodePWD https://github.com/keycloak/keycloak/blob/e12c245355f5fcbabab4a6807a9975f... > [2] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/f3ad... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter

by Tomasz Adamski (Jira)

[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ] Tomasz Adamski commented on WFLY-11566: --------------------------------------- [~guillaume.smet] I have made the updates that you mentioned and a fix to make integration tests pass. Now I can see that the reproducer above works correctly and our integration tests are passing. From my side it's OK to push it to upstream. > ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter > ---------------------------------------------------------------------------------- > > Key: WFLY-11566 > URL: https://issues.redhat.com/browse/WFLY-11566 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, EJB, REST > Affects Versions: 14.0.0.Final, 15.0.1.Final > Reporter: Alexander Wagner > Assignee: Tomasz Adamski > Priority: Critical > Labels: downstream_dependency > Attachments: WFLY-11566-3.tar > > > You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters. > As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine. > This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...] > Steps to reproduce: > {code:java} > @Stateless > @Path("/") > public class Resource { > @POST > @Path("put/list") > @Consumes(MediaType.APPLICATION_JSON) > public String putList(@NotEmpty List<String> a) { > return "Hello bars " + a.stream().collect(Collectors.joining(", ")); > } > } > {code} > {noformat} > [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list > javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List). > [mkopecky@dhcp-10-40-5-71 bin]$ > {noformat} > {noformat} > javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List). > at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24) > at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461) > at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377) > at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788) > at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648) > at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192) > at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160) > at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324) > at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159) > at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619) > at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254) > at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224) > at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177) > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118) > at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509) > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399) > at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363) > at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355) > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439) > at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229) > at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135) > at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355) > at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:791) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > {noformat} > Links: > * [forum|https://developer.jboss.org/thread/278822] > * WFLY-11566 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13013) Elytron LDAP can't set-password in Active Directory or react to external changes

by David Guthrie (Jira)

David Guthrie created WFLY-13013: ------------------------------------ Summary: Elytron LDAP can't set-password in Active Directory or react to external changes Key: WFLY-13013 URL: https://issues.redhat.com/browse/WFLY-13013 Project: WildFly Issue Type: Feature Request Components: Security Affects Versions: 19.0.0.Beta1, 18.0.1.Final Reporter: David Guthrie Assignee: Darran Lofthouse The caching realm seems to work as advertised with open ldap and Red Hat Directory Server when I add a user-password-mapper after setting: <user-password-mapper from="userPassword" writable="true" verifiable="true" /> When I change the password in LDAP, the caching realm reacts, and I can login with the new password. Also when I call `set-password`: /subsystem=elytron/ldap-realm=ldap-realm:set-password(identity=testUser, clear= {password="1A3b6w"} ) It changes the password correctly in LDAP. Neither of these work in Active Directory. Active Directory stores the password, by default using the field "UnicodePwd" rather than "userPassword", so I tried having them map the user password to that field: /subsystem=elytron/ldap-realm=ldap-realm:write-attribute(name=identity-mapping.user-password-mapper.from, value=UnicodePwd) But it it can't set the password because the password code needs to write it with a different character set when writing to active directory. See the different between the code in ldap/UserPasswordCredentialLoader.java and in the special case for Active Directory in Keycloak[1] It can't react to external changes to the directory because Active Directory doesn't support the listening mechanism used. There is a potential to be able to change the active directory settings so "userPassword" runs in compatibility mode[2], but that's not a normal thing to be able to do is most environments. [1] Keycloak - AD UnicodePWD https://github.com/keycloak/keycloak/blob/e12c245355f5fcbabab4a6807a9975f... [2] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/f3ad... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13012) Update clustering integration tests to use Infinispan Server 10.1.x

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13012: ----------------------------------- Summary: Update clustering integration tests to use Infinispan Server 10.1.x Key: WFLY-13012 URL: https://issues.redhat.com/browse/WFLY-13012 Project: WildFly Issue Type: Task Components: Clustering, Test Suite Affects Versions: 19.0.0.Beta1 Reporter: Paul Ferraro Assignee: Radoslav Husar Infinispan 10 introduced a new Netty-based server. The testsuite will need to be updated to correctly provision it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12881) Cannot customize split behavior and merge policy for Infinispan partition handling

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-12881?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-12881: -------------------------------- Summary: Cannot customize split behavior and merge policy for Infinispan partition handling (was: Cannot customize split detection and merge policy for Infinispan partition handling) > Cannot customize split behavior and merge policy for Infinispan partition handling > ---------------------------------------------------------------------------------- > > Key: WFLY-12881 > URL: https://issues.redhat.com/browse/WFLY-12881 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.1.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Priority: Critical > Fix For: 20.0.0.Beta1 > > > Currently, partition handling of an Infinispan cache is hard coded. When enabled, both reads and writes are denied on minority partitions (of a given segment) and, more critically, upon partition merge, no reconciliation of any data conflicts occurs. > Users need to be able to configure this, at least to support the built in read/write on split policy and the built-in merge policies. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4919) Long running query at kie-server startup

by Cristiano Nicolai (Jira)

[ https://issues.redhat.com/browse/DROOLS-4919?page=com.atlassian.jira.plug... ] Cristiano Nicolai commented on DROOLS-4919: ------------------------------------------- [~swiderski.maciej] correct, that was done as part of JBPM-8559. > Long running query at kie-server startup > ---------------------------------------- > > Key: DROOLS-4919 > URL: https://issues.redhat.com/browse/DROOLS-4919 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 7.28.0.Final > Reporter: Danny Rucker > Assignee: Maciej Swiderski > Priority: Major > > The following query is executed at start up of kie-server > ``` > select vil.processInstanceId, vil.processId, vil.id, vil.variableId, vil.value from VariableInstanceLog vil where vil.id in (select MAX(v.id) from VariableInstanceLog v group by v.variableId, v.processInstanceId) > ``` > This is causing some issues with getting kie-server to start up. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1860) Custom classloader in RpcDispatcher

by Todd Sandor (Jira)

[ https://issues.redhat.com/browse/JGRP-1860?page=com.atlassian.jira.plugin... ] Todd Sandor commented on JGRP-1860: ----------------------------------- We are a Redhat customer - this issue was raised on our behalf. We are not in the process of upgrading from JBoss EAP7.1 to 7.2 and the Groups version was changed from jgroups-3.6.14.Final-redhat-1.jar to jgroups-4.0.15.Final-redhat-00001.jar and at this point can not compile our application code (JGRP-1860). These changes do not seem to have been ported to JGroups 4 (7.2.0 uses 4.0.15.Final-redhat-00001.jar). Is it possible to get these ported to JGroups 4? I have raised case Redhat https://access.redhat.com/support/cases/#/case/02568685 for this. We have also found that org.jgroups.util.UUID is not backwards compatible between the above releases ...but it is not related to JGRP-1860 .. The issues are described in the above case. Cheers > Custom classloader in RpcDispatcher > ----------------------------------- > > Key: JGRP-1860 > URL: https://issues.redhat.com/browse/JGRP-1860 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.2.13 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Major > Fix For: 3.4.5, 3.5 > > > RpcDispatcher is hard-coded to use JGroups' classloader when marshalling the users's custom objects over RPC. > RpcDispatcher uses Util.objectFromByteBuffer to unmarshall, which uses an ObjectInputStream. ObjectInputStream uses the classloader of its caller's class (Util). > RpcDispatcher does allow a custom marshaller to be used (implementing RpcDispatcher.Marshaller), but since Util.objectFromByteBuffer hard-codes the use of ObjectInputStream, a custom marshaller cannot simply set the classloader and then delegate back to the default JGroups code. > Util.objectFromBuffer should be enhanced to use a custom ObjectInputStream implementation that overrides resolveClass to use a custom classloader, and an API should be added to RpcDispatcher to pass in the classloader to use. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4955) [DMN Designer] Blog post - DMN Elements suggestions for FEEL code completion

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4955?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4955: ------------------------------------ Sprint: 2020 Week 04-06 (from Jan 20) > [DMN Designer] Blog post - DMN Elements suggestions for FEEL code completion > ---------------------------------------------------------------------------- > > Key: DROOLS-4955 > URL: https://issues.redhat.com/browse/DROOLS-4955 > Project: Drools > Issue Type: Task > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > > Create a blog post for https://issues.redhat.com/browse/BAPL-1480 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4781) Ability to enable shutdown operation for EmbeddedServer

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFCORE-4781?page=com.atlassian.jira.plug... ] Jean Francois Denise commented on WFCORE-4781: ---------------------------------------------- An embedded server can't be shutdown. Would be needed by the maven-plugin to kill a server started in background. Would be needed in general to implement termination strategy using CLI. > Ability to enable shutdown operation for EmbeddedServer > ------------------------------------------------------- > > Key: WFCORE-4781 > URL: https://issues.redhat.com/browse/WFCORE-4781 > Project: WildFly Core > Issue Type: Enhancement > Components: Embedded > Affects Versions: 11.0.0.Beta5 > Reporter: Jean Francois Denise > Assignee: James Perkins > Priority: Major > > Having the shutdown operation available for embedded is needed when the embedder process and embedded server shutdown phase are bound. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4485) Support for multiple security realms - Distributed Identities

by Carl Walker (Jira)

[ https://issues.redhat.com/browse/WFCORE-4485?page=com.atlassian.jira.plug... ] Carl Walker commented on WFCORE-4485: ------------------------------------- I have two use cases. In both cases, authentication and authorization info is kept in multiple places. (This isn't the "authenticate here / authorize there" scenario supported with aggregate.) 1) End users and admins credentials are located in different datastores (tables) but access the same resources. End users hit the first query. If that passes, they're authenticated and authorized. Admins fail on the first query, but succeed on the second. Business logic keeps the usernames unique across both stores. 2) Customer-maintained Active Directory and RDBMS-oriented "system accounts". Authentication is done against Active Directory for end users who have an identity in the enterprise system. System accounts will fail the AD check but will be picked up in a second RDBMS module. > Support for multiple security realms - Distributed Identities > ------------------------------------------------------------- > > Key: WFCORE-4485 > URL: https://issues.redhat.com/browse/WFCORE-4485 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Priority: Major > Labels: CD17-Deferred, EAP-CD19, Previous_RFE > Fix For: 11.0.0.Beta8 > > > By stacking LoginModules it was possible using PicketBox to attempt to authenticate using one remote store and if that failed try the next store in the list. > This RFE is to consider the use case where identities could be located across multiple stores and how they are aggregated together. > Additionally this use case should consider how the authorization information could be loaded from multiple sources and merged. > This RFE is not about fail over in the event of a realm being unavailable although it may be related. > This RFE is created as a result of comparing the differences between the PicketBox JAAS architecture and the Elytron architecture so I would not recommend this proceeds without some real world use cases identified. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12996) Upgrade Narayana to 5.10.3.Final

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/WFLY-12996?page=com.atlassian.jira.plugi... ] Michael Musgrove closed WFLY-12996. ----------------------------------- Release Notes Text: We only did a partial release so I will close this one an open another for when we do the next one (5.10.4.Final). Resolution: Won't Do > Upgrade Narayana to 5.10.3.Final > -------------------------------- > > Key: WFLY-12996 > URL: https://issues.redhat.com/browse/WFLY-12996 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Affects Versions: 19.0.0.Beta1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 19.0.0.Beta2 > > > Transactions component upgrade > https://issues.redhat.com/projects/JBTM/versions/12343377 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4977) [DMN Designer] Refactor DataObjectsServiceImpl to not duplicate logic from ParseHelper

by Daniel José dos Santos (Jira)

Daniel José dos Santos created DROOLS-4977: ---------------------------------------------- Summary: [DMN Designer] Refactor DataObjectsServiceImpl to not duplicate logic from ParseHelper Key: DROOLS-4977 URL: https://issues.redhat.com/browse/DROOLS-4977 Project: Drools Issue Type: Enhancement Components: DMN Editor Reporter: Daniel José dos Santos Assignee: Daniel José dos Santos Currently we have logic from [ParserHelper|https://github.com/kiegroup/drools/blob/master/kie-dmn/kie-d...] duplicated in [DataObjectsServiceImpl|https://github.com/kiegroup/kie-wb-common/blob/969...] which may lead to some inconsistencies. `DataObjectsServiceImpl` should use `ParserHelper` and convert the result to a type that can be used by UI. This JIRA is derived from [RHDM-1145|https://issues.redhat.com/browse/RHDM-1145]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4976) Guided Decision Table Graphs do not work

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-4976?page=com.atlassian.jira.plug... ] Toni Rikkola updated DROOLS-4976: --------------------------------- Sprint: 2020 Week 04-06 (from Jan 20) > Guided Decision Table Graphs do not work > ---------------------------------------- > > Key: DROOLS-4976 > URL: https://issues.redhat.com/browse/DROOLS-4976 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 7.32.0.Final > Reporter: Michael Anstis > Assignee: Toni Rikkola > Priority: Critical > Labels: drools-tools > > Users are no longer able to create Guided Decision Table Graphs. > A {{Parameter named 'analysisReportScreen' should be not null!}} error is thrown when trying to "open" an existing Guided Decision Table to the graph. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4976) Guided Decision Table Graphs do not work

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-4976?page=com.atlassian.jira.plug... ] Toni Rikkola updated DROOLS-4976: --------------------------------- Priority: Critical (was: Major) > Guided Decision Table Graphs do not work > ---------------------------------------- > > Key: DROOLS-4976 > URL: https://issues.redhat.com/browse/DROOLS-4976 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 7.32.0.Final > Reporter: Michael Anstis > Assignee: Toni Rikkola > Priority: Critical > Labels: drools-tools > > Users are no longer able to create Guided Decision Table Graphs. > A {{Parameter named 'analysisReportScreen' should be not null!}} error is thrown when trying to "open" an existing Guided Decision Table to the graph. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4972) Buttons stay disabled when switching to textual collection editor

by Elizabeth Clayton (Jira)

[ https://issues.redhat.com/browse/DROOLS-4972?page=com.atlassian.jira.plug... ] Elizabeth Clayton commented on DROOLS-4972: ------------------------------------------- [~yamer] [~jomarko] When there's an opportunity, I think the Add interaction could be cleaned up a bit. I didn't work on it, so there are probably constraints/requirements that I'm not aware of. At minimum it would be great to move that Add link, I question why it's hanging out at the bottom of the screen like that? > Buttons stay disabled when switching to textual collection editor > ----------------------------------------------------------------- > > Key: DROOLS-4972 > URL: https://issues.redhat.com/browse/DROOLS-4972 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Minor > Labels: drools-tools > Attachments: define-list-and-save.webm > > > If user starts to create list using UI editor, then he decides to switch to textual editor - define list as expression, the buttons are disabled if user didn't canceled items 'in progress' in the UI editor. See the attached video. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4688) [DMN Designer] Basic Code Completion for DMN Literal Expressions (7.6)

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4688?page=com.atlassian.jira.plug... ] Guilherme Gomes resolved DROOLS-4688. ------------------------------------- Resolution: Done > [DMN Designer] Basic Code Completion for DMN Literal Expressions (7.6) > ---------------------------------------------------------------------- > > Key: DROOLS-4688 > URL: https://issues.redhat.com/browse/DROOLS-4688 > Project: Drools > Issue Type: Epic > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > Users must have a basic code completion for DMN Literal Expressions. > This task is a MVP, and don't have any backend logic. The code completion is powered by a simple autocompleted of FEEL functions and a simple code highlight. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2441) Changes to MembershipListener, StateListener, MessageListener

by Bela Ban (Jira)

Bela Ban created JGRP-2441: ------------------------------ Summary: Changes to MembershipListener,StateListener,MessageListener Key: JGRP-2441 URL: https://issues.redhat.com/browse/JGRP-2441 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0 Investigate * Why is MessageListener still needed? Can't we just use {{Receiver}}? * Why does {{MessageListener}} subclass {{StateListener}}? * Are callbacks {{block()}}, {{unblock()}} and {{suspect()}} still needed? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4919) Long running query at kie-server startup

by Maciej Swiderski (Jira)

[ https://issues.redhat.com/browse/DROOLS-4919?page=com.atlassian.jira.plug... ] Maciej Swiderski commented on DROOLS-4919: ------------------------------------------ [~cristiano.nicolai] haven't we already moved the need to do the initial count for the data sets? > Long running query at kie-server startup > ---------------------------------------- > > Key: DROOLS-4919 > URL: https://issues.redhat.com/browse/DROOLS-4919 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 7.28.0.Final > Reporter: Danny Rucker > Assignee: Maciej Swiderski > Priority: Major > > The following query is executed at start up of kie-server > ``` > select vil.processInstanceId, vil.processId, vil.id, vil.variableId, vil.value from VariableInstanceLog vil where vil.id in (select MAX(v.id) from VariableInstanceLog v group by v.variableId, v.processInstanceId) > ``` > This is causing some issues with getting kie-server to start up. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4976) Guided Decision Table Graphs do not work

by Michael Anstis (Jira)

Michael Anstis created DROOLS-4976: -------------------------------------- Summary: Guided Decision Table Graphs do not work Key: DROOLS-4976 URL: https://issues.redhat.com/browse/DROOLS-4976 Project: Drools Issue Type: Bug Components: Guided Decision Table Editor Affects Versions: 7.32.0.Final Reporter: Michael Anstis Assignee: Toni Rikkola Users are no longer able to create Guided Decision Table Graphs. A {{Parameter named 'analysisReportScreen' should be not null!}} error is thrown when trying to "open" an existing Guided Decision Table to the graph. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4971) [DMN Designer] Adding entries to structure

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4971?page=com.atlassian.jira.plug... ] Guilherme Gomes edited comment on DROOLS-4971 at 1/24/20 7:01 AM: ------------------------------------------------------------------ This issue is fixed by this PR https://github.com/kiegroup/kie-wb-common/pull/3102 !demo.gif|width=800! was (Author: karreiro): This issue is fixed by this PR https://github.com/kiegroup/kie-wb-common/pull/3102 > [DMN Designer] Adding entries to structure > ------------------------------------------ > > Key: DROOLS-4971 > URL: https://issues.redhat.com/browse/DROOLS-4971 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Minor > Labels: drools-tools > Attachments: Screenshot from 2020-01-24 09-29-26.png, Screenshot from 2020-01-24 09-30-15.png, Screenshot from 2020-01-24 09-30-40.png, demo.gif, offerings-reproducer.dmn > > > There is unexpected ordering of entries in Data Type editor when user add structure into structure. See the attached dmn model and screenshots. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4878) Test Scenario: fix support for default stateless kieSession

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4878?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4878: -------------------------------- Attachment: MySpace_collect.zip > Test Scenario: fix support for default stateless kieSession > ----------------------------------------------------------- > > Key: DROOLS-4878 > URL: https://issues.redhat.com/browse/DROOLS-4878 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: drools-tools > Attachments: MySpace_collect.zip > > > How to reproduce: > - edit kmodule.xml and create only a default stateless session > {code:java} > <kmodule xmlns="http://www.drools.org/xsd/kmodule" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > <kbase name="myKieBase"> > <ksession name="mySession" type="stateless" default="true"/> > </kbase> > </kmodule> > {code} > - create a Rule test scenario and specify in Setting panel {{stateless}} > - run > Without the fix: > Test failed with this exception "Impossible to find a KieSession with name null" > With the fix: > The test should be able to run because that kmodule configuration is valid -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4971) [DMN Designer] Adding entries to structure

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4971?page=com.atlassian.jira.plug... ] Guilherme Gomes commented on DROOLS-4971: ----------------------------------------- This issue is fixed by this PR https://github.com/kiegroup/kie-wb-common/pull/3102 > [DMN Designer] Adding entries to structure > ------------------------------------------ > > Key: DROOLS-4971 > URL: https://issues.redhat.com/browse/DROOLS-4971 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Minor > Labels: drools-tools > Attachments: Screenshot from 2020-01-24 09-29-26.png, Screenshot from 2020-01-24 09-30-15.png, Screenshot from 2020-01-24 09-30-40.png, demo.gif, offerings-reproducer.dmn > > > There is unexpected ordering of entries in Data Type editor when user add structure into structure. See the attached dmn model and screenshots. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4878) Test Scenario: fix support for default stateless kieSession

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4878?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4878: ------------------------------------- Project used for verification [^MySpace_collect.zip] . To run tests successfully with stateless session, user needs to pick 'stateless' check box in test scenario settings. > Test Scenario: fix support for default stateless kieSession > ----------------------------------------------------------- > > Key: DROOLS-4878 > URL: https://issues.redhat.com/browse/DROOLS-4878 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: drools-tools > Attachments: MySpace_collect.zip > > > How to reproduce: > - edit kmodule.xml and create only a default stateless session > {code:java} > <kmodule xmlns="http://www.drools.org/xsd/kmodule" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > <kbase name="myKieBase"> > <ksession name="mySession" type="stateless" default="true"/> > </kbase> > </kmodule> > {code} > - create a Rule test scenario and specify in Setting panel {{stateless}} > - run > Without the fix: > Test failed with this exception "Impossible to find a KieSession with name null" > With the fix: > The test should be able to run because that kmodule configuration is valid -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4971) [DMN Designer] Adding entries to structure

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4971?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4971: ------------------------------------ Story Points: 1 Sprint: 2020 Week 04-06 (from Jan 20) > [DMN Designer] Adding entries to structure > ------------------------------------------ > > Key: DROOLS-4971 > URL: https://issues.redhat.com/browse/DROOLS-4971 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Minor > Labels: drools-tools > Attachments: Screenshot from 2020-01-24 09-29-26.png, Screenshot from 2020-01-24 09-30-15.png, Screenshot from 2020-01-24 09-30-40.png, offerings-reproducer.dmn > > > There is unexpected ordering of entries in Data Type editor when user add structure into structure. See the attached dmn model and screenshots. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4878) Test Scenario: fix support for default stateless kieSession

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4878?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4878: -------------------------------- Steps to Reproduce: # import the attached project into bs # Open it, click Build, Then Test Current: 3/3 will fail Expected: 2/3 will pass > Test Scenario: fix support for default stateless kieSession > ----------------------------------------------------------- > > Key: DROOLS-4878 > URL: https://issues.redhat.com/browse/DROOLS-4878 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: drools-tools > > How to reproduce: > - edit kmodule.xml and create only a default stateless session > {code:java} > <kmodule xmlns="http://www.drools.org/xsd/kmodule" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > <kbase name="myKieBase"> > <ksession name="mySession" type="stateless" default="true"/> > </kbase> > </kmodule> > {code} > - create a Rule test scenario and specify in Setting panel {{stateless}} > - run > Without the fix: > Test failed with this exception "Impossible to find a KieSession with name null" > With the fix: > The test should be able to run because that kmodule configuration is valid -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4878) Test Scenario: fix support for default stateless kieSession

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4878?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4878: -------------------------------- Steps to Reproduce: (was: # import the attached project into bs # Open it, click Build, Then Test Current: 3/3 will fail Expected: 2/3 will pass) > Test Scenario: fix support for default stateless kieSession > ----------------------------------------------------------- > > Key: DROOLS-4878 > URL: https://issues.redhat.com/browse/DROOLS-4878 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: drools-tools > > How to reproduce: > - edit kmodule.xml and create only a default stateless session > {code:java} > <kmodule xmlns="http://www.drools.org/xsd/kmodule" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > <kbase name="myKieBase"> > <ksession name="mySession" type="stateless" default="true"/> > </kbase> > </kmodule> > {code} > - create a Rule test scenario and specify in Setting panel {{stateless}} > - run > Without the fix: > Test failed with this exception "Impossible to find a KieSession with name null" > With the fix: > The test should be able to run because that kmodule configuration is valid -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4878) Test Scenario: fix support for default stateless kieSession

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4878?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4878: -------------------------------- Attachment: (was: MySpace_collect.zip) > Test Scenario: fix support for default stateless kieSession > ----------------------------------------------------------- > > Key: DROOLS-4878 > URL: https://issues.redhat.com/browse/DROOLS-4878 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: drools-tools > > How to reproduce: > - edit kmodule.xml and create only a default stateless session > {code:java} > <kmodule xmlns="http://www.drools.org/xsd/kmodule" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > <kbase name="myKieBase"> > <ksession name="mySession" type="stateless" default="true"/> > </kbase> > </kmodule> > {code} > - create a Rule test scenario and specify in Setting panel {{stateless}} > - run > Without the fix: > Test failed with this exception "Impossible to find a KieSession with name null" > With the fix: > The test should be able to run because that kmodule configuration is valid -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4878) Test Scenario: fix support for default stateless kieSession

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4878?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4878: -------------------------------- Attachment: MySpace_collect.zip > Test Scenario: fix support for default stateless kieSession > ----------------------------------------------------------- > > Key: DROOLS-4878 > URL: https://issues.redhat.com/browse/DROOLS-4878 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: drools-tools > Attachments: MySpace_collect.zip > > > How to reproduce: > - edit kmodule.xml and create only a default stateless session > {code:java} > <kmodule xmlns="http://www.drools.org/xsd/kmodule" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > <kbase name="myKieBase"> > <ksession name="mySession" type="stateless" default="true"/> > </kbase> > </kmodule> > {code} > - create a Rule test scenario and specify in Setting panel {{stateless}} > - run > Without the fix: > Test failed with this exception "Impossible to find a KieSession with name null" > With the fix: > The test should be able to run because that kmodule configuration is valid -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4698: ------------------------------------- New issue https://issues.redhat.com/browse/DROOLS-4975 > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4698 > URL: https://issues.redhat.com/browse/DROOLS-4698 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, Screenshot from 2020-01-08 14-36-33.png, Screenshot from 2020-01-08 14-36-52.png, test urgent.scesim, urgent.dmn > > > Support is about both drools/java collections and dmn collections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4975) Defined Rule collection unary checks do not pass

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4975?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4975: -------------------------------- Description: Import the attached project and click Build, then Test. The re are defined equivalent tests. One test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor does not pass. was: Import the attached project and click Build, then Test. The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass. > Defined Rule collection unary checks do not pass > ------------------------------------------------ > > Key: DROOLS-4975 > URL: https://issues.redhat.com/browse/DROOLS-4975 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Critical > Labels: drools-tools > Attachments: MySpace_filtering.zip > > > Import the attached project and click Build, then Test. > The re are defined equivalent tests. One test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor does not pass. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4973: -------------------------------- Summary: Defined DMN collection unary checks do not pass (was: Defined collection unary checks do not pass) > Defined DMN collection unary checks do not pass > ----------------------------------------------- > > Key: DROOLS-4973 > URL: https://issues.redhat.com/browse/DROOLS-4973 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Critical > Labels: drools-tools > Attachments: MySpace_eshop.zip > > > Import the attached project and click Build, then Test. > The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4975) Defined Rule collection unary checks do not pass

by Jozef Marko (Jira)

Jozef Marko created DROOLS-4975: ----------------------------------- Summary: Defined Rule collection unary checks do not pass Key: DROOLS-4975 URL: https://issues.redhat.com/browse/DROOLS-4975 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing Affects Versions: 7.32.0.Final Reporter: Jozef Marko Assignee: Daniele Zonca Attachments: MySpace_filtering.zip Import the attached project and click Build, then Test. The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4975) Defined Rule collection unary checks do not pass

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4975?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4975: -------------------------------- Attachment: MySpace_filtering.zip > Defined Rule collection unary checks do not pass > ------------------------------------------------ > > Key: DROOLS-4975 > URL: https://issues.redhat.com/browse/DROOLS-4975 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Critical > Labels: drools-tools > Attachments: MySpace_filtering.zip > > > Import the attached project and click Build, then Test. > The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13011) The quickstart template appears out of date

by Darran Lofthouse (Jira)

Darran Lofthouse created WFLY-13011: --------------------------------------- Summary: The quickstart template appears out of date Key: WFLY-13011 URL: https://issues.redhat.com/browse/WFLY-13011 Project: WildFly Issue Type: Bug Components: Quickstarts Affects Versions: 19.0.0.Beta1 Reporter: Darran Lofthouse Assignee: Eduardo Martins The quickstart template appears to be out of date based on the present requirements. One example it does not contain the technologies attribute which leads to a NullPointerException when building the docs with a new quickstart using the template. Additionally later quickstarts appear to use an abstract differently to how the template describes them to define some more values so it would be nice to see some description of how this should be used. -- This message was sent by Atlassian Jira (v7.13.8#713008)

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