January 2020 - jboss-jira - Jboss List Archives

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

by Massimiliano Dessi (Jira)

Massimiliano Dessi created DROOLS-4974: ------------------------------------------ Summary: 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 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4473) Testing DefaultKafkaConsumer

by Massimiliano Dessi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4473?page=com.atlassian.jira.plug... ] Massimiliano Dessi closed DROOLS-4473. -------------------------------------- Resolution: Won't Fix > Testing DefaultKafkaConsumer > ----------------------------- > > Key: DROOLS-4473 > URL: https://issues.redhat.com/browse/DROOLS-4473 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > Labels: HADrools > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-4956: -------------------------------------- Description: Having a constraint like {code:java} Person($customer == name) {code} is not really the same thing as {code:java} Person(name == $customer) {code} In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. was: Having a constraint like {code:java} Person( name == "Toshiya" ) {code} is not really the same thing as {code:java} Person( "Toshiya" == name ) {code} In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. > Normarize rule constraints for property reactivity and indexing > --------------------------------------------------------------- > > Key: DROOLS-4956 > URL: https://issues.redhat.com/browse/DROOLS-4956 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Affects Versions: 7.31.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Having a constraint like > {code:java} > Person($customer == name) > {code} > is not really the same thing as > {code:java} > Person(name == $customer) > {code} > In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ] Toshiya Kobayashi edited comment on DROOLS-4956 at 1/24/20 5:01 AM: -------------------------------------------------------------------- Note: {code:java} Person( "Toshiya" == name ) {code} works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). was (Author: tkobayashi): Note: {code:java} Person( "Toshiya" == name ) {code} works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). {code:java} Person($customer == name) {code} This can cause a property reactivity issue. > Normarize rule constraints for property reactivity and indexing > --------------------------------------------------------------- > > Key: DROOLS-4956 > URL: https://issues.redhat.com/browse/DROOLS-4956 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Affects Versions: 7.31.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Having a constraint like > {code:java} > Person($customer == name) > {code} > is not really the same thing as > {code:java} > Person(name == $customer) > {code} > In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-4956: -------------------------------------- Description: Having a constraint like {code:java} Person(name == $customer) {code} is not really the same thing as {code:java} Person($customer == name) {code} In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. was: Having a constraint like {code:java} Person($customer == name) {code} is not really the same thing as {code:java} Person(name == $customer) {code} In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. > Normarize rule constraints for property reactivity and indexing > --------------------------------------------------------------- > > Key: DROOLS-4956 > URL: https://issues.redhat.com/browse/DROOLS-4956 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Affects Versions: 7.31.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Having a constraint like > {code:java} > Person(name == $customer) > {code} > is not really the same thing as > {code:java} > Person($customer == name) > {code} > In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ] Toshiya Kobayashi edited comment on DROOLS-4956 at 1/24/20 4:59 AM: -------------------------------------------------------------------- Note: {code:java} Person( "Toshiya" == name ) {code:java} works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). {code:java} Person($customer == name) {code:java} This can cause a property reactivity issue. was (Author: tkobayashi): Note: Person( "Toshiya" == name ) works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). > Normarize rule constraints for property reactivity and indexing > --------------------------------------------------------------- > > Key: DROOLS-4956 > URL: https://issues.redhat.com/browse/DROOLS-4956 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Affects Versions: 7.31.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Having a constraint like > {code:java} > Person( name == "Toshiya" ) > {code} > is not really the same thing as > {code:java} > Person( "Toshiya" == name ) > {code} > In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ] Toshiya Kobayashi edited comment on DROOLS-4956 at 1/24/20 5:00 AM: -------------------------------------------------------------------- Note: {code:java} Person( "Toshiya" == name ) {code} works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). {code:java} Person($customer == name) {code} This can cause a property reactivity issue. was (Author: tkobayashi): Note: {code:java} Person( "Toshiya" == name ) {code:java} works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). {code:java} Person($customer == name) {code:java} This can cause a property reactivity issue. > Normarize rule constraints for property reactivity and indexing > --------------------------------------------------------------- > > Key: DROOLS-4956 > URL: https://issues.redhat.com/browse/DROOLS-4956 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Affects Versions: 7.31.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Having a constraint like > {code:java} > Person( name == "Toshiya" ) > {code} > is not really the same thing as > {code:java} > Person( "Toshiya" == name ) > {code} > In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ] Toshiya Kobayashi commented on DROOLS-4956: ------------------------------------------- Note: Person( "Toshiya" == name ) works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). > Normarize rule constraints for property reactivity and indexing > --------------------------------------------------------------- > > Key: DROOLS-4956 > URL: https://issues.redhat.com/browse/DROOLS-4956 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Affects Versions: 7.31.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Having a constraint like > {code:java} > Person( name == "Toshiya" ) > {code} > is not really the same thing as > {code:java} > Person( "Toshiya" == name ) > {code} > In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Jozef Marko (Jira)

Jozef Marko created DROOLS-4973: ----------------------------------- Summary: Defined 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 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, 6 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-4973 > 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, 6 months

1
0
0 / 0

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

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4972?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4972: -------------------------------- Tester: Jozef Marko > 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, 6 months

1
0
0 / 0

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

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4972?page=com.atlassian.jira.plug... ] Jozef Marko reassigned DROOLS-4972: ----------------------------------- Assignee: Yeser Amer (was: Mario Fusco) > 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, 6 months

1
0
0 / 0

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

by Jozef Marko (Jira)

Jozef Marko created DROOLS-4972: ----------------------------------- Summary: 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 Affects Versions: 7.32.0.Final Reporter: Jozef Marko Assignee: Mario Fusco 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, 6 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-4972 > 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, 6 months

1
0
0 / 0

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

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4972?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4972: -------------------------------- Priority: Minor (was: Major) > 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 > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Mario Fusco > 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, 6 months

1
0
0 / 0

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

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4972?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4972: -------------------------------- Component/s: Scenario Simulation and Testing > 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: Mario Fusco > 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, 6 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: ------------------------------------------- Hi [~soul2zimate], Are you working on this? Can I take it on me. > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11548) RemoteExceptions and subclasses treated as ApplicationExceptions

by Moulali Shikalwadi (Jira)

[ https://issues.redhat.com/browse/WFLY-11548?page=com.atlassian.jira.plugi... ] Moulali Shikalwadi reassigned WFLY-11548: ----------------------------------------- Assignee: Moulali Shikalwadi > RemoteExceptions and subclasses treated as ApplicationExceptions > ---------------------------------------------------------------- > > Key: WFLY-11548 > URL: https://issues.redhat.com/browse/WFLY-11548 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 13.0.0.Final > Environment: - Windows > - Wildfly 13 final > - Java sdk 1.8 > Reporter: Omar Hefnawi > Assignee: Moulali Shikalwadi > Priority: Major > > Remote Exceptions should be treated as if they are System Exceptions > So in very old projects where they used to extend RemoteException for their own exceptions, code was written under the assumption that when one of these is caught in the container, the transaction should be rolled back as per the spec (system exceptions cause a rollback). > Currently if an ejb method throws a remote exception, this will be translated to be an Application Exception (on line 275 in EJBComponent.java) and transactions that are currently happening will no longer be rolled back; which was against the old spec, I'm unsure of what ejb 3.X says about this, but currently I felt it would make sense to mimic what happened in older application containers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11548) RemoteExceptions and subclasses treated as ApplicationExceptions

by Moulali Shikalwadi (Jira)

[ https://issues.redhat.com/browse/WFLY-11548?page=com.atlassian.jira.plugi... ] Moulali Shikalwadi commented on WFLY-11548: ------------------------------------------- Looking into it. > RemoteExceptions and subclasses treated as ApplicationExceptions > ---------------------------------------------------------------- > > Key: WFLY-11548 > URL: https://issues.redhat.com/browse/WFLY-11548 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 13.0.0.Final > Environment: - Windows > - Wildfly 13 final > - Java sdk 1.8 > Reporter: Omar Hefnawi > Assignee: Moulali Shikalwadi > Priority: Major > > Remote Exceptions should be treated as if they are System Exceptions > So in very old projects where they used to extend RemoteException for their own exceptions, code was written under the assumption that when one of these is caught in the container, the transaction should be rolled back as per the spec (system exceptions cause a rollback). > Currently if an ejb method throws a remote exception, this will be translated to be an Application Exception (on line 275 in EJBComponent.java) and transactions that are currently happening will no longer be rolled back; which was against the old spec, I'm unsure of what ejb 3.X says about this, but currently I felt it would make sense to mimic what happened in older application containers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4971?page=com.atlassian.jira.plug... ] Michael Anstis reassigned DROOLS-4971: -------------------------------------- Assignee: Guilherme Gomes (was: Michael Anstis) > [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, 6 months

1
0
0 / 0

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

by Joerg Baesner (Jira)

Joerg Baesner created WFLY-13010: ------------------------------------ Summary: [WFLY-13009] moduleAvailability message is sent before module has started Key: WFLY-13010 URL: https://issues.redhat.com/browse/WFLY-13010 Project: WildFly Issue Type: Bug Components: Clustering, EJB Affects Versions: 19.0.0.Beta1 Reporter: Joerg Baesner Assignee: Richard Achmatowicz 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4764) Availability of web console during the startup of the Domain Controller

by Yeray Borges (Jira)

[ https://issues.redhat.com/browse/WFCORE-4764?page=com.atlassian.jira.plug... ] Yeray Borges commented on WFCORE-4764: -------------------------------------- Hello [~harald.pehl], just for your info, if you start testing WFCORE-4764 in HAL, it would be nice if you include WFCORE-4809 in the mix. WFCORE-4809 will allow HAL to execute composite operations to read the runtime and topology when there are servers starting in the Domain Controller. HAL could get unresponsive is you not include it in the mix. > Availability of web console during the startup of the Domain Controller > ----------------------------------------------------------------------- > > Key: WFCORE-4764 > URL: https://issues.redhat.com/browse/WFCORE-4764 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Affects Versions: 11.0.0.Beta3 > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Minor > > The customer asking why the web console is only available after all servers are registered in the Domain. > If the customer starts a domain controller using the host.xml file for example and enables all servers to auto-start="true" the web console is not available until all servers are registered and the browser prompts to add a new interface. > In the log file, the HTTP management interface is enable in the end of the events: > ~~~ > [Host Controller] 18:41:29,247 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: JBoss EAP 7.1.0.GA (WildFly Core 3.0.10.Final-redhat-1) starting > [Host Controller] 18:41:30,208 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/host=master/core-service=management/management-interface=native-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > [Host Controller] 18:41:30,210 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/host=master/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > [Host Controller] 18:41:30,284 INFO [org.wildfly.security] (Controller Boot Thread) ELY00001: WildFly Elytron version 1.1.7.Final-redhat-1 > [Host Controller] 18:41:30,342 INFO [org.xnio] (MSC service thread 1-6) XNIO version 3.5.4.Final-redhat-1 > [Host Controller] 18:41:30,356 INFO [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0003: Creating http management service using network interface (management) port (9990) securePort (-1) > [Host Controller] 18:41:30,383 INFO [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.5.4.Final-redhat-1 > [Host Controller] 18:41:30,478 INFO [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 5.0.5.Final-redhat-1 > [Host Controller] 18:41:30,603 INFO [org.jboss.as.patching] (MSC service thread 1-8) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > [Host Controller] 18:41:30,647 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /opt/jboss-eap-7.1/domain/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > [Host Controller] 18:41:30,705 INFO [org.jboss.as.remoting] (MSC service thread 1-8) WFLYRMT0001: Listening on 127.0.0.1:9999 > [Host Controller] 18:41:32,922 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/profile=default/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > [Host Controller] 18:41:32,990 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/profile=ha/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > [Host Controller] 18:41:33,046 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/profile=full/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > [Host Controller] 18:41:33,112 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/profile=full-ha/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > [Host Controller] 18:41:33,612 INFO [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0023: Starting server server-one > 18:41:33,665 INFO [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 3) WFLYPC0018: Starting process 'Server:server-one' > [Host Controller] 18:41:35,496 INFO [org.jboss.as.host.controller] (management task-1) WFLYHC0021: Server [Server:server-one] connected using connection [Channel ID 348b688d (inbound) of Remoting connection 0f97728d to localhost/127.0.0.1:53171 of endpoint "master:MANAGEMENT" <46167ef2>] > [Host Controller] 18:41:35,562 INFO [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0023: Starting server server-two > [Host Controller] 18:41:35,582 INFO [org.jboss.as.host.controller] (server-registration-threads - 1) WFLYHC0020: Registering server server-one > 18:41:35,606 INFO [org.jboss.as.process.Server:server-two.status] (ProcessController-threads - 3) WFLYPC0018: Starting process 'Server:server-two' > [Host Controller] 18:41:38,901 INFO [org.jboss.as.host.controller] (management task-5) WFLYHC0021: Server [Server:server-two] connected using connection [Channel ID 114e3864 (inbound) of Remoting connection 30f65708 to localhost/127.0.0.1:42083 of endpoint "master:MANAGEMENT" <46167ef2>] > [Host Controller] 18:41:38,969 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0062: Http management interface listening on http://127.0.0.1:9990/management and https://127.0.0.1:-1/management > [Host Controller] 18:41:38,969 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0053: Admin console listening on http://127.0.0.1:9990 and https://127.0.0.1:-1 > [Host Controller] 18:41:38,970 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.GA (WildFly Core 3.0.10.Final-redhat-1) (Host Controller) started in 10487ms - Started 77 of 79 services (23 services are lazy, passive or on-demand) > ~~~ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Jozef Marko (Jira)

Jozef Marko created DROOLS-4971: ----------------------------------- Summary: [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: Michael Anstis 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9542) Iron JAC Amar is being told to create more KeyConnectionAssociation under CachedConnectionManagerImpl then actual JTA transactions open (Reproducible with NESTED EJB calls)

by James Ostrowick (Jira)

[ https://issues.redhat.com/browse/WFLY-9542?page=com.atlassian.jira.plugin... ] James Ostrowick commented on WFLY-9542: --------------------------------------- Had exactly the same problem with Wildfly 18.0.1 final - suddenly started getting the error when executing updates / deletes. I masked the issue by adding the following to my standalone*.xml config: <logger category="org.jboss.jca.core.connectionmanager" use-parent-handlers="true"> <level name="OFF"/> </logger> I've also tested the issue with my code with Wildfly 19.0 beta, it also appears. > Iron JAC Amar is being told to create more KeyConnectionAssociation under CachedConnectionManagerImpl then actual JTA transactions open (Reproducible with NESTED EJB calls) > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9542 > URL: https://issues.redhat.com/browse/WFLY-9542 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final > Reporter: NUNO GODINHO DE MATOS > Priority: Major > Labels: Arjuna, IronJacamar, JTA > Attachments: deploy.log > > > I have been trying to understand for what reason we sometimes are seing the exception: > {panel} > IJ000311: Throwable from unregister connection: java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@2021ff6. > {panel} > I have now created a sample application that allows the exception to be reproduced: > https://github.com/99sono/wildlfly-ironjacamar-unregisterconnection/ > To summarize: > If we start a JTA transaction T1 by invoking an @EJB with TransacitonAttirbute RequiresNew. > And then this EJB calls a second EJB with TransacitonAttirbute Supports. > Then we will have the problem that if the First JDBC access is done on the nested EJB, the connection handed over to the JPA layer (eclipselink) will be popped out of the > org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.currentObjects > As soon as we come out of the Nested EJB call. > I do not know how serious this is. > If somehow the popped out connection continues in fact locked to the ongoing JTA transaction or if might be going back to the connection pool and potentially be up for grabs. > This I do not know how... I lack the knowledge to say how crucial it is to have a good synchrinization between the connections being managed under the: > org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl > And the JPA layer. > But intuitively, I would say: quite important. > So whenever a Stack gets popped with connections being managed, I would intuitively say: one of the parties has done something wrong. Either: > (a) ARJUNA is asking JAC AMAR to open stacks when the JTA transaction is the same and it shouldn't, or > (b) It does not really matter that the conneciton is popped out - somehow JAC AMAR still knows that the connection it popped out is still bound to the JTA transaction and the problem is logically strange but of low impact... > What appears to be true, is that eclipselink is doing something logicla, in the sense that it is only asking for the conneciton to be closed/unregistered at the end of the JTA transaction. > NOTE: > In fact the error that we see when we get the stack trace, could also happen and no stack trance be logged by jac AMAR. > This is the scenario when JAC leaves the unregister conneciton via: > org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl would be going out via the: > {panel} > CopyOnWriteArrayList<ConnectionRecord> conns = cmToConnectionsMap.get(cm); > // Can happen if connections are "passed" between contexts > if (conns == null) > return; > {panel} > But in my oppinion this exit path deserves the exact same stack trace. > The sample application is to be found here: > https://github.com/99sono/wildlfly-ironjacamar-unregisterconnection/ > This sample application is not as simple to deploy because one needs to hava a data source configured. > In any case the sample application has in src/test/resources my standalone.xml. > It should be realtively easy to fix the JDBC drivers configured in the atnadlone.xml. > And it should be relatively simple to fix the persistence.xml to search for eclipselink in the appropriate moduel. > I will no copy paste bellow the LOG of the exception of the sample application. > {panel} > 2017-11-09 10:20:00,918 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) > -------------------------------------- > -- STARTING TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING >: observing the CDI event StartupEventToTryToReproduceIJ000311Issue > -------------------------------------- > 2017-11-09 10:20:00,919 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Doing a fetch ALL query. just to bind the connection manager to the KEY of stack level 1. > 2017-11-09 10:20:01,033 FINE [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) Eclipselink connected (jndiName: java:/jdbc/SAMPLE_DS)- obtaining connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@1d5b3a43. Eclipselink Server session is: ServerSession( > DatabaseAccessor(connected) > PostgreSQLPlatform) > 2017-11-09 10:20:01,057 FINE [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) EclipseLink - Closing connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@1d5b3a43 > 2017-11-09 10:20:01,063 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) At this point the org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl will have registered on stack1 the connection used by eclipselink, and unregistered as well. > However, this temporary register/de-register is sufficient to add to the current key.getCMToConnectionsMap() and entry for the JDBC connection manger. > This is fundamental, because without this step the exception that we will later see would be hidden away - even though the logical problem would be there no exception would be logged. By taking this magical step here, we have ensured that we will be able to reproduce the excpetion later. > To summarize what has happend so far. > 1. We have forced eclipselink to register and unregister a connection due to are fetch id query > 2. The JTA transaction ID TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING > continues healthy and running without any problem 3. Meanwhile internally, our CachedConnectionManagerImpl, for this thread, has a single task of keys in its currentObjects field > 4. The leading key on this stack does not hold any connectionrecords (eclipselink returned the connecton to the pool) but it does have a KEY for the JDBC connection manager 5. Point 4 is the magical step to allow us to see the stack trace but not the core of the issue - just the core of seing the stack trace > 2017-11-09 10:20:01,066 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) START: executoreSynchronousSameJta > 2017-11-09 10:20:01,066 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Right now we are within the same JTA transaction. But on a NESTED EJB call. > What technically has happened at this point is that IRON JAC AMAR now has a second stack (keyAssociation) > in the currentObjects. We add in stacks each time we go through an EJB evne if we keep the JTA transaction > and this is the BUG. But we will see more about this later. > > 2017-11-09 10:20:01,066 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) STARTING 3: observing the CDI event StartupEventToTryToReproduceIJ000311Issue - The current transaction id is: TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING > > 2017-11-09 10:20:01,066 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Going to create 50 entities on the database > 2017-11-09 10:20:01,067 FINE [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) Eclipselink connected (jndiName: jdbc/SAMPLE_NON_JTA_DS)- obtaining connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@4be2573e. Eclipselink Server session is: ClientSession({}) > 2017-11-09 10:20:01,073 FINE [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) EclipseLink - Closing connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@4be2573e > 2017-11-09 10:20:01,078 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) 50 entities should have been created: > 2017-11-09 10:20:01,078 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Now we want to flush - we want to force eclipselink to have to acquire the java:/jdbc/SAMPLE_DS and not be allowed to close the connection yet. > 2017-11-09 10:20:01,085 FINE [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) Eclipselink connected (jndiName: java:/jdbc/SAMPLE_DS)- obtaining connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@2021ff6. Eclipselink Server session is: ClientSession({default=DatabaseAccessor(connected)}) > 2017-11-09 10:20:01,101 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) The flush has been done. We expec that the log now shows us that java:/jdbc/SAMPLE_DS connection was acquired but not yet closed by eclipselink. > 2017-11-09 10:20:01,101 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) ENDING TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING >: finishing to observer. The current transaction id is: {} > 2017-11-09 10:20:01,101 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) OK. Now we are about to leave our nested EJB call. What is happening now is very important. > 1. We will leave a nested EJB call but not the JTA transaction 2. Wildfly will go to the cachedConnectonManagerImpl and tell it to pop a stack (BUG) 3. The stack that goes away is actually holding the JDBC connection thta has been given to ECLIPSELINK and thta eclipselink will later try to close 4. When we leave this call we go back to STACK 1, where no connections are being managed > 2017-11-09 10:20:01,102 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) FINISH: executoreSynchronousSameJta: > > 2017-11-09 10:20:01,102 WARN [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) NOW we are out of our nested EJB call. We are bout to leave the main EJB transaction call. > In short we are about to reproduce the stack trace. > What will now happen is the following. > 1. Wildfly will tell eclipselink that the transaction is at an end and it should commit if it can > 2. Eclipselink does its job of committing the changes and takes the JTA connection it was given and tries to close it > 3. IRON JAC AMAR will log the stack trace we wanted to reproduce saying it has not idea what connection we are trying to return to the pool. > 4. The reason the CachedConnectionManagerImpl does not know about the connection is because it was managed under STACK 2 but was popped out of existence after the nested transaction > 5. Now it is very important to keep in mind that even if we were not seing the stack trace the error would be there (the moment we popped a key stack that had still connections) 6. Keep in mind that if we were to modify the source code and disable our reproduceBugService.fetchAlIds() call we would see no stack trace but the same issue would be present.7. The difference that doing the reproduceBugService.fetchAlIds() does is whether or not CachedConnectionManagerImpl during unregister connection leaves via the if conns == null return null or if goes further into the if (!ignoreConnections) > 8. OK - Now that we understand what is happening behind the scenes we can let eclipselink try to close the JDBC connection at the end of the JTA transaction > > 2017-11-09 10:20:01,106 FINE [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) EclipseLink - Closing connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@2021ff6 > 2017-11-09 10:20:01,107 INFO [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (ServerService Thread Pool -- 73) IJ000311: Throwable from unregister connection: java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@2021ff6 > at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.unregisterConnection(CachedConnectionManagerImpl.java:408) > at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.connectionClosed(TxConnectionListener.java:645) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.returnHandle(BaseWrapperManagedConnection.java:596) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:541) > at org.jboss.jca.adapters.jdbc.WrappedConnection.returnConnection(WrappedConnection.java:298) > at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:256) > at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.closeDatasourceConnection(DatabaseAccessor.java:522) > at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.closeConnection(DatasourceAccessor.java:537) > at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.closeConnection(DatabaseAccessor.java:545) > at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.closeJTSConnection(DatasourceAccessor.java:188) > at org.eclipse.persistence.sessions.server.ClientSession.releaseJTSConnection(ClientSession.java:171) > at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:175) > at org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:68) > at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:116) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:368) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:91) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:349) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:241) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb$$$view9.observeStartupEventToTryToReproduceIJ000311Issue(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128) > at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb$Proxy$_$$_Weld$EnterpriseProxy$.observeStartupEventToTryToReproduceIJ000311Issue(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:302) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:291) > at org.jboss.weld.event.EventImpl.fire(EventImpl.java:89) > at startupconnectionproblem.event.FireStartupEventsServiceImpl.fireStartupCDIEvents(FireStartupEventsServiceImpl.java:41) > at startupconnectionproblem.event.FireStartupEventsServiceImpl$Proxy$_$$_WeldClientProxy.fireStartupCDIEvents(Unknown Source) > at startupconnectionproblem.event.StartupSingletonLocalEjb.postConstrcut(StartupSingletonLocalEjb.java:38) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:114) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:103) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) > at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.notSupported(LifecycleCMTTxInterceptor.java:87) > at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.singleton.StartupCountDownInterceptor.processInvocation(StartupCountDownInterceptor.java:25) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) > at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124) > at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138) > at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 2017-11-09 10:20:01,114 INFO [startupconnectionproblem.event.FireStartupEventsServiceImpl] (ServerService Thread Pool -- 73) FIINSH: StartupEventToTryToReproduceIJ000311Issue > 2017-11-09 10:20:01,114 INFO [startupconnectionproblem.event.StartupSingletonLocalEjb] (ServerService Thread Pool -- 73) ENDING 1: Post construct of startup bean singleton ending > 2017-11-09 10:20:01,240 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 73) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '/app' > 2017-11-09 10:20:02,098 INFO [org.primefaces.webapp.PostConstructA > {panel} > Thanks for considering this issue. > I do not know how much impact this issue can actually have. > We have many hundred different types of JTA business transactions, and we see this sample application happening on system tests and stress tests relatively often. > Now that I have better understand of the issue, I can in some cases rework the code to dodge this problem to avoid nested calls of EJBS on the same transaciton - but this will not always be possible. > And I would be quite afraid of this issue, if means that our connectons still in the hands of ElcipseLInk are going back to the pool. > This would explain some strange errors we have had only on stress test application, that we do not see when using a different app server. > I must say it was extremelly difficult to be able to make the stack trace reproducible. > There are many tricky points to be able to lead the code to go precisely through the code path that leads to the excpetion. > But it is relatively trivial to make the code leave through the "silent bug iron jac amar code path". > Many thanks for all the help on this. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 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 updated DROOLS-4698: -------------------------------- Tester: Jozef Marko (was: Anna Dupliak) > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4936) Unsaved changes dialog appears even if it just have been saved

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4936?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4936: -------------------------------- Fix Version/s: 7.33.0.Final > Unsaved changes dialog appears even if it just have been saved > -------------------------------------------------------------- > > Key: DROOLS-4936 > URL: https://issues.redhat.com/browse/DROOLS-4936 > Project: Drools > Issue Type: Bug > Components: Guided Rule Editor > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > Fix For: 7.33.0.Final > > > Open a GRE file. Add a fact pattern. Save. > Close and the editor still thinks it has not been saved. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4811) Bump logging subsystem model version and schema

by James Perkins (Jira)

James Perkins created WFCORE-4811: ------------------------------------- Summary: Bump logging subsystem model version and schema Key: WFCORE-4811 URL: https://issues.redhat.com/browse/WFCORE-4811 Project: WildFly Core Issue Type: Task Components: Logging Reporter: James Perkins Assignee: James Perkins The logging subsystem schema needs to be bumped from 8.0 to 9.0. The logging subsystem model version needs to be bumped from 9.0.0 to 10.0.0. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13004) Upgrade jgroups-kubernetes to 1.0.14.Final

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13004?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13004: ------------------------------------ Description: No functional changes. https://github.com/jgroups-extras/jgroups-kubernetes/compare/1.0.13.Final... was: No functional changes. https://github.com/jgroups-extras/jgroups-kubernetes/compare/1.0.14.Final... > Upgrade jgroups-kubernetes to 1.0.14.Final > ------------------------------------------ > > Key: WFLY-13004 > URL: https://issues.redhat.com/browse/WFLY-13004 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Optional > > No functional changes. > https://github.com/jgroups-extras/jgroups-kubernetes/compare/1.0.13.Final... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12801) Upgrade JGroups to 4.1.8.Final

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12801?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-12801: ---------------------------------- Affects Version/s: 19.0.0.Beta1 > Upgrade JGroups to 4.1.8.Final > ------------------------------ > > Key: WFLY-12801 > URL: https://issues.redhat.com/browse/WFLY-12801 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 18.0.1.Final, 19.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > 4.1.7 changelog: > https://issues.jboss.org/projects/JGRP/versions/12343002 > 4.1.8 changelog: > https://issues.jboss.org/projects/JGRP/versions/12343108 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13008) TCPPING is unreliable with default num_discovery_runs="1"

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13008?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13008: ---------------------------------- Priority: Critical (was: Major) > TCPPING is unreliable with default num_discovery_runs="1" > --------------------------------------------------------- > > Key: WFLY-13008 > URL: https://issues.redhat.com/browse/WFLY-13008 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 19.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > > It appears that {{TCPPING}} is unreliable with default {{num_discovery_runs="1"}} and results in singleton clusters and subsequent merging as can be seen when running the clustering testsuite using TCPPING instead of MPING. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12900) Clustering TS: Default to non-multicast discovery protocol

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12900?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-12900: ---------------------------------- Affects Version/s: 19.0.0.Beta1 > Clustering TS: Default to non-multicast discovery protocol > ---------------------------------------------------------- > > Key: WFLY-12900 > URL: https://issues.redhat.com/browse/WFLY-12900 > Project: WildFly > Issue Type: Task > Components: Clustering, Test Suite > Affects Versions: 18.0.1.Final, 19.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > > We have been slowly making progress on reducing reliance on multicast to run the clustering test suite by default given the complexity of system configuration (e.g. multicast on {{::1}} workarounds). The goal is to use a default non-multicast-based protocol by defaut. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12845) Upgrade JGroups to 4.1.9.Final

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12845?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-12845: ---------------------------------- Affects Version/s: 19.0.0.Beta1 > Upgrade JGroups to 4.1.9.Final > ------------------------------ > > Key: WFLY-12845 > URL: https://issues.redhat.com/browse/WFLY-12845 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 18.0.1.Final, 19.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > Just a tracker for now. > Changelog > https://issues.jboss.org/projects/JGRP/versions/12343163 > The fix for JGRP-2409 has caused compilation failure thus updating the https://github.com/wildfly-clustering/wildfly/tree/jgroups-master branch with the fix from which PR will be opened. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4830) Add a Docker composer to connect BC and Kie Server images

by Michael Biarnes Kiefer (Jira)

[ https://issues.redhat.com/browse/DROOLS-4830?page=com.atlassian.jira.plug... ] Michael Biarnes Kiefer updated DROOLS-4830: ------------------------------------------- Fix Version/s: 7.33.0.Final (was: 7.32.0.Final) > Add a Docker composer to connect BC and Kie Server images > --------------------------------------------------------- > > Key: DROOLS-4830 > URL: https://issues.redhat.com/browse/DROOLS-4830 > Project: Drools > Issue Type: Feature Request > Components: docker images > Affects Versions: 7.30.0.Final > Reporter: Ricardo Zanini Fernandes > Assignee: Ricardo Zanini Fernandes > Priority: Major > Fix For: 7.33.0.Final > > > It's natural to have BC and KIE servers working together. Would be nice to have a Docker composer file that fires up the two instances at once. This will support use cases such authoring on BC and deploying in the connected KIE Server. > References: https://www.drools.org/download/download.html -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3160) adapt kie upstream reps for Thorntail 2.2 (ex WildFly Swarm)

by Michael Biarnes Kiefer (Jira)

[ https://issues.redhat.com/browse/DROOLS-3160?page=com.atlassian.jira.plug... ] Michael Biarnes Kiefer updated DROOLS-3160: ------------------------------------------- Fix Version/s: 7.33.0.Final (was: 7.32.0.Final) > adapt kie upstream reps for Thorntail 2.2 (ex WildFly Swarm) > ------------------------------------------------------------ > > Key: DROOLS-3160 > URL: https://issues.redhat.com/browse/DROOLS-3160 > Project: Drools > Issue Type: Feature Request > Reporter: Michael Biarnes Kiefer > Assignee: Toni Rikkola > Priority: Major > Fix For: 7.33.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2254) Automate .proto files rebuild in pom.xml

by Michael Biarnes Kiefer (Jira)

[ https://issues.redhat.com/browse/DROOLS-2254?page=com.atlassian.jira.plug... ] Michael Biarnes Kiefer updated DROOLS-2254: ------------------------------------------- Fix Version/s: 7.33.0.Final (was: 7.32.0.Final) > Automate .proto files rebuild in pom.xml > ---------------------------------------- > > Key: DROOLS-2254 > URL: https://issues.redhat.com/browse/DROOLS-2254 > Project: Drools > Issue Type: Task > Components: tools > Affects Versions: 7.5.0.Final > Reporter: Dmitry Volodin > Assignee: Dmitry Volodin > Priority: Minor > Fix For: 7.33.0.Final > > > According to contribution guide, any .proto file or protobuf version changes it's necessary to download protoc utility and regenerate Java classes based on .proto files. > This will add automation for downloading protoc utility and Java classes generation based on Maven Protocol Buffers Plugin. There is no timestamps and other build related info inside generated Java files and no changes will be added on each new build. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4810) Upgrade WildFly Elytron to 1.11.1.Final

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFCORE-4810?page=com.atlassian.jira.plug... ] Farah Juma updated WFCORE-4810: ------------------------------- Fix Version/s: 11.0.0.Beta8 > Upgrade WildFly Elytron to 1.11.1.Final > --------------------------------------- > > Key: WFCORE-4810 > URL: https://issues.redhat.com/browse/WFCORE-4810 > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1925) Release WildFly Elytron 1.11.1.Final

by Farah Juma (Jira)

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

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1925) Release WildFly Elytron 1.11.1.Final

by Farah Juma (Jira)

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

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1925) Release WildFly Elytron 1.11.1.Final

by Farah Juma (Jira)

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

6 years, 6 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 updated WFLY-13009: --------------------------------------- Description: 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. was: 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. > 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: Paul Ferraro > 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, 6 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 reassigned WFLY-13009: ------------------------------------------ Assignee: Richard Achmatowicz (was: Paul Ferraro) > 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, 6 months

1
0
0 / 0

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

by Richard Achmatowicz (Jira)

Richard Achmatowicz created WFLY-13009: ------------------------------------------ Summary: 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: Paul Ferraro 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4810) Upgrade WildFly Elytron to 1.11.1.Final

by Farah Juma (Jira)

Farah Juma created WFCORE-4810: ---------------------------------- Summary: Upgrade WildFly Elytron to 1.11.1.Final Key: WFCORE-4810 URL: https://issues.redhat.com/browse/WFCORE-4810 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1921) [GSS][7.2.2] HTTP External Security Not Supported by Elytron

by Ashley Abdel-Sayed (Jira)

[ https://issues.redhat.com/browse/ELY-1921?page=com.atlassian.jira.plugin.... ] Ashley Abdel-Sayed updated ELY-1921: ------------------------------------ Issue Type: Feature Request (was: Requirement) > [GSS][7.2.2] HTTP External Security Not Supported by Elytron > ------------------------------------------------------------ > > Key: ELY-1921 > URL: https://issues.redhat.com/browse/ELY-1921 > Project: WildFly Elytron > Issue Type: Feature Request > Affects Versions: 1.11.0.Final > Reporter: Ashley Abdel-Sayed > Assignee: Ashley Abdel-Sayed > Priority: Major > > For legacy security, there's an EXTERNAL HTTP authentication mechanism (io.undertow.security.impl.ExternalAuthenticationMechanism) which performs no verification and simply uses the principal that was passed from the REMOTE_USER attribute by the AJP protocol. There is a "ClientLoginModule" in legacy security used as such: https://access.redhat.com/solutions/3465231. It is a requirement to add an equivalent of this EXTERNAL mechanism available in legacy and Elytron-SASL for Elytron-HTTP in order to migrate away from legacy security. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13003) Support the SameSite cookie attribute

by Masafumi Miura (Jira)

[ https://issues.redhat.com/browse/WFLY-13003?page=com.atlassian.jira.plugi... ] Masafumi Miura edited comment on WFLY-13003 at 1/23/20 10:32 AM: ----------------------------------------------------------------- I've already raised UNDERTOW-1600 which is related to this feature. I've just updated a PR for UNDERTOW-1600 https://github.com/undertow-io/undertow/pull/816 which contains the following changes: - Add support for the SameSite=None attribute - Add SameSiteCookieHandler that can set the SameSite attribute on all cookies or the cookie which matches the specified name - Add a utility class SameSiteNoneIncompatibleClientChecker to detect user agents which are incompatible with the SameSite=None attribute. The regex is based on https://www.chromium.org/updates/same-site/incompatible-clients The SameSiteCookieHandler can be enabled with the predicate name "samesite-cookie" through expression-filter in the undertow subsystem. For example: {code:xml} <subsystem xmlns="urn:jboss:domain:undertow:7.0" ...> ... <server name="default-server"> ... <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <http-invoker security-realm="ApplicationRealm"/>  <filter-ref name="samesite-cookie"/>  </host> </server> ...(snip)... <filters>  <expression-filter name="samesite-cookie" expression="samesite-cookie(mode=strict)"/>       </filters> </subsystem> {code} was (Author: mmiura): I've already raised UNDERTOW-1600 which is related to this feature. I've just updated a PR for UNDERTOW-1600 https://github.com/undertow-io/undertow/pull/816 which contains the following changes: - Add support for the SameSite=None attribute - Add SameSiteCookieHandler that can set the SameSite attribute on all cookies - Add a utility class SameSiteNoneIncompatibleClientChecker to detect user agents which are incompatible with the SameSite=None attribute. The regex is based on https://www.chromium.org/updates/same-site/incompatible-clients The SameSiteCookieHandler can be enabled with the predicate name "samesite-cookie" through expression-filter in the undertow subsystem. For example: {code:xml} <subsystem xmlns="urn:jboss:domain:undertow:7.0" ...> ... <server name="default-server"> ... <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <http-invoker security-realm="ApplicationRealm"/>  <filter-ref name="samesite-cookie"/>  </host> </server> ...(snip)... <filters>  <expression-filter name="samesite-cookie" expression="samesite-cookie(mode=strict)"/>    <expression-filter name="samesite-cookie" expression="samesite-cookie(mode=none)"/> </filters> </subsystem> {code} > Support the SameSite cookie attribute > ------------------------------------- > > Key: WFLY-13003 > URL: https://issues.redhat.com/browse/WFLY-13003 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Flavia Rainone > Priority: Major > > Chrome 80 is going to significantly change how cookies are handled, as per this notice at [1], with a bit of an explanation of what the same site attribute means at [2]. > At the moment the Servlet specification has no way of setting this particular attribute, and it is not possible to configure it via container specific configuration in WildFly at present (it can only be done by writing some Undertow specific code). > I propose we add a same-site-cookie-attribute predicated handler to undertow, which takes an optional cookie name regex, and the value for the attribute to set. > This would allow users to configure the SameSite attribute based on cookie name, and also potentially based on any other attributes including user agent, as it sounds like some browsers may have bugs that means this might need to be set on a per user agent basis. > [1] https://www.chromestatus.com/feature/5088147346030592 > [2] https://web.dev/samesite-cookies-explained/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4961) User / Role Permissions on package level

by Alexandre Bakos (Jira)

[ https://issues.redhat.com/browse/DROOLS-4961?page=com.atlassian.jira.plug... ] Alexandre Bakos edited comment on DROOLS-4961 at 1/23/20 10:29 AM: ------------------------------------------------------------------- I see your point, although this is an organizational issue as the technical best practice would be split the project anyway, think about monolith vs. MSA. And, as I pointed in my previous comment, even if we could consider this... the results would be flawed as Git doesn't provide such a feature. > User / Role Permissions on package level > ---------------------------------------- > > Key: DROOLS-4961 > URL: https://issues.redhat.com/browse/DROOLS-4961 > Project: Drools > Issue Type: Feature Request > Affects Versions: 7.31.0.Final > Reporter: Nikos Tsekouras > Assignee: David Gutierrez > Priority: Major > Labels: drools-tools > > It will be amazingly helpful to have the ability to minimize the access / permissions of a user / group on package level. > Within a project you can define several packages - for different purposes - and you need each team to be able to work on / view a specific package. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1925) Release WildFly Elytron 1.11.1.Final

by Farah Juma (Jira)

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

6 years, 6 months

1
0
0 / 0

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

by Jonathan Fisher (Jira)

[ https://issues.redhat.com/browse/DROOLS-4919?page=com.atlassian.jira.plug... ] Jonathan Fisher commented on DROOLS-4919: ----------------------------------------- Any reason why that SQL is being executed? It seems to want to read _the entire_ VariableInstanceLog table which can be quite large (we have a couple hundred thousand rows on it). Could the query be more optimized? > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2440) CompositeMessage: add iteration

by Bela Ban (Jira)

Bela Ban created JGRP-2440: ------------------------------ Summary: CompositeMessage: add iteration Key: JGRP-2440 URL: https://issues.redhat.com/browse/JGRP-2440 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0 Make {{CompositeMessage}} implement {{Iterable<Message>}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2439) LongMessage

by Bela Ban (Jira)

Bela Ban created JGRP-2439: ------------------------------ Summary: LongMessage Key: JGRP-2439 URL: https://issues.redhat.com/browse/JGRP-2439 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0 Message with a long as payload. This can for example be used to send/request credits in flow control -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1923) NPE in AuthenticationConfiguration.toString()

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1923?page=com.atlassian.jira.plugin.... ] Farah Juma resolved ELY-1923. ----------------------------- Resolution: Done > NPE in AuthenticationConfiguration.toString() > --------------------------------------------- > > Key: ELY-1923 > URL: https://issues.redhat.com/browse/ELY-1923 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.11.1.CR1 > > > {noformat} > LogManager error of type FORMAT_FAILURE: Formatting error > java.lang.NullPointerException > at org.wildfly.security.auth.client.AuthenticationConfiguration.toString(AuthenticationConfiguration.java:1654) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/WFLY-12996?page=com.atlassian.jira.plugi... ] Thomas Jenkinson updated WFLY-12996: ------------------------------------ Description: Transactions component upgrade https://issues.redhat.com/projects/JBTM/versions/12343377 was:Transactions component upgrade > 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, 6 months

1
0
0 / 0

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

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/WFLY-12996?page=com.atlassian.jira.plugi... ] Thomas Jenkinson updated WFLY-12996: ------------------------------------ Summary: Upgrade Narayana to 5.10.3.Final (was: Upgrade Narayana to 5.10.2.Final) > 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 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times

by Petr Kremensky (Jira)

[ https://issues.redhat.com/browse/WFWIP-276?page=com.atlassian.jira.plugin... ] Petr Kremensky updated WFWIP-276: --------------------------------- Description: # As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration. This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc): ||17.0-6||pod time||EAP boot||config time |#1 | 8283|6128|2155 |#2 | 9446|7548|1898 |#3 | 8767|6871| 1896 |#4 | 8568|6272| 2296 |#5 | 8000 |6362|1638 ||average ||8613ms||6636ms||1977ms ||18.0-7||pod time||EAP boot||config time |#1 |13769|5716|8053 |#2 |13362|5952|7410 |#3 |14261|6093|8168 |#4 |14322|6135|8187 |#5 |13921|6326|7595 ||average||13927ms||6044ms||7883ms pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}}) EAP boot = time of boot EAP itself == {{started in ..}} config time = the difference of previou timess = anything before EAP boot begins Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images. This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime. The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start. was: As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration. This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc): ||17.0-6||pod time||EAP boot||config time |#1 | 8283|6128|2155 |#2 | 9446|7548|1898 |#3 | 8767|6871| 1896 |#4 | 8568|6272| 2296 |#5 | 8000 |6362|1638 ||average ||8613ms||6636ms||1977ms ||18.0-7||pod time||EAP boot||config time |#1 |13769|5716|8053 |#2 |13362|5952|7410 |#3 |14261|6093|8168 |#4 |14322|6135|8187 |#5 |13921|6326|7595 ||average||13927ms||6044ms||7883ms pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}}) EAP boot = time of boot EAP itself == {{started in ..}} config time = the difference of previou timess = anything before EAP boot begins Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images. This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime. The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start. > Boot time of application built via S2I is much longer than in before-Galleon times > ---------------------------------------------------------------------------------- > > Key: WFWIP-276 > URL: https://issues.redhat.com/browse/WFWIP-276 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Jean Francois Denise > Priority: Critical > Attachments: test-app.zip > > > # As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration. > This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc): > ||17.0-6||pod time||EAP boot||config time > |#1 | 8283|6128|2155 > |#2 | 9446|7548|1898 > |#3 | 8767|6871| 1896 > |#4 | 8568|6272| 2296 > |#5 | 8000 |6362|1638 > ||average ||8613ms||6636ms||1977ms > ||18.0-7||pod time||EAP boot||config time > |#1 |13769|5716|8053 > |#2 |13362|5952|7410 > |#3 |14261|6093|8168 > |#4 |14322|6135|8187 > |#5 |13921|6326|7595 > ||average||13927ms||6044ms||7883ms > pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}}) > EAP boot = time of boot EAP itself == {{started in ..}} > config time = the difference of previou timess = anything before EAP boot begins > Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images. > This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime. > The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11214) Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/WFLY-11214?page=com.atlassian.jira.plugi... ] Michael Musgrove updated WFLY-11214: ------------------------------------ Priority: Major (was: Critical) > Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used > ------------------------------------------------------------------------------------------- > > Key: WFLY-11214 > URL: https://issues.redhat.com/browse/WFLY-11214 > Project: WildFly > Issue Type: Bug > Components: Agroal, Transactions > Reporter: Ivan Straka > Assignee: Luis Barreiro > Priority: Major > Attachments: JPACrashRecoveryTestCase_commitHaltSecond_jta_server.log, JPACrashRecoveryTestCase_commitHaltSecond_jts_server.log > > > Scenario: > Halts server at commit phase ... > # enlist TestXA resource > # enlist XA resource > # prepare TestXA resource > # prepare XA resource > # commit Test XA resource > # JVM crash > # recovery started > # commit XA resource > Periodic recovery does not recover xa resource. It looks like agroal subsystem does not register xa resource to xa recovery module. > Test outcome: > {code:java} > Running org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 109.002 sec <<< FAILURE! - in org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase > commitHaltSecond(org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase) Time elapsed: 102.976 sec <<< FAILURE! > java.lang.AssertionError: Incorrect data in database after crash recovery. expected:<2> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.test.JPABaseCrashRecoveryTestCase.checkAfterTestExecution(JPABaseCrashRecoveryTestCase.java:150) > at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltTest(TestBaseCrashRecovery.java:485) > at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltSecond(TestBaseCrashRecovery.java:418) > at org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase.commitHaltSecond(JPACrashRecoveryTestCase.java:76) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Daniele Zonca (Jira)

[ https://issues.redhat.com/browse/DROOLS-4878?page=com.atlassian.jira.plug... ] Daniele Zonca updated DROOLS-4878: ---------------------------------- Description: 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 was: 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 > 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, 6 months

1
0
0 / 0

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

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4959?page=com.atlassian.jira.plug... ] Michael Anstis commented on DROOLS-4959: ---------------------------------------- Our {{CopyHelper}} class and related infrastructure works OK for individual assets (and they can only be copied to the _same_ package). So it seems we're missing the bits to handle copying/renaming an entire {{package}}.... :-( > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4960) Reference a data object from one project to another one.

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4960?page=com.atlassian.jira.plug... ] Michael Anstis commented on DROOLS-4960: ---------------------------------------- If you've _built_ a project in BRMS it should have been installed in the server's local Maven .m2 repository AFAIK the local .m2 should be used by Maven to resolve dependencies even in offline mode. > Reference a data object from one project to another one. > -------------------------------------------------------- > > Key: DROOLS-4960 > URL: https://issues.redhat.com/browse/DROOLS-4960 > Project: Drools > Issue Type: Feature Request > Affects Versions: 7.31.0.Final > Reporter: Nikos Tsekouras > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > Currently, nothing can be referenced from one project to another one. > Using a common area to create the Data Objects etc. and reference them on several projects will be very helpful. > Java-wise is like we are creating two projects and we reference the first one in the second one, in order to use some classes in our code. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4961) User / Role Permissions on package level

by Nikos Tsekouras (Jira)

[ https://issues.redhat.com/browse/DROOLS-4961?page=com.atlassian.jira.plug... ] Nikos Tsekouras commented on DROOLS-4961: ----------------------------------------- Hi [~Rikkola], Think that there is an organization consisting of 5 departments. It's easier to have 1 Project for the whole organization (= 1 jar) and each department will have permissions on its package. > User / Role Permissions on package level > ---------------------------------------- > > Key: DROOLS-4961 > URL: https://issues.redhat.com/browse/DROOLS-4961 > Project: Drools > Issue Type: Feature Request > Affects Versions: 7.31.0.Final > Reporter: Nikos Tsekouras > Assignee: David Gutierrez > Priority: Major > Labels: drools-tools > > It will be amazingly helpful to have the ability to minimize the access / permissions of a user / group on package level. > Within a project you can define several packages - for different purposes - and you need each team to be able to work on / view a specific package. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4961) User / Role Permissions on package level

by Nikos Tsekouras (Jira)

[ https://issues.redhat.com/browse/DROOLS-4961?page=com.atlassian.jira.plug... ] Nikos Tsekouras edited comment on DROOLS-4961 at 1/23/20 7:39 AM: ------------------------------------------------------------------ Hi [~Rikkola], Think that there is an organization consisting of 5 departments. It's easier to have 1 Project for the whole organization (= 1 jar to maintain) and each department to have permissions on its package. was (Author: nicktsek): Hi [~Rikkola], Think that there is an organization consisting of 5 departments. It's easier to have 1 Project for the whole organization (= 1 jar) and each department will have permissions on its package. > User / Role Permissions on package level > ---------------------------------------- > > Key: DROOLS-4961 > URL: https://issues.redhat.com/browse/DROOLS-4961 > Project: Drools > Issue Type: Feature Request > Affects Versions: 7.31.0.Final > Reporter: Nikos Tsekouras > Assignee: David Gutierrez > Priority: Major > Labels: drools-tools > > It will be amazingly helpful to have the ability to minimize the access / permissions of a user / group on package level. > Within a project you can define several packages - for different purposes - and you need each team to be able to work on / view a specific package. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4960) Reference a data object from one project to another one.

by Nikos Tsekouras (Jira)

[ https://issues.redhat.com/browse/DROOLS-4960?page=com.atlassian.jira.plug... ] Nikos Tsekouras commented on DROOLS-4960: ----------------------------------------- Hi [~manstis] / [~Rikkola], Thanks but I configured MVN offline in BRMS. So, maybe that's the reason I cannot use Michael's solution. Is there any way to use the same in "MVN offline" version? > Reference a data object from one project to another one. > -------------------------------------------------------- > > Key: DROOLS-4960 > URL: https://issues.redhat.com/browse/DROOLS-4960 > Project: Drools > Issue Type: Feature Request > Affects Versions: 7.31.0.Final > Reporter: Nikos Tsekouras > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > Currently, nothing can be referenced from one project to another one. > Using a common area to create the Data Objects etc. and reference them on several projects will be very helpful. > Java-wise is like we are creating two projects and we reference the first one in the second one, in order to use some classes in our code. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 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 updated DROOLS-4959: ------------------------------------ Attachment: step1.PNG step2.PNG step3.PNG step4.PNG > 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, 6 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 [~Rikkola], Please find attached the process I used to reproduce this. > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1347) NullPointerException in SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:441

by Piotr Krokowski (Jira)

[ https://issues.redhat.com/browse/JBJCA-1347?page=com.atlassian.jira.plugi... ] Piotr Krokowski commented on JBJCA-1347: ---------------------------------------- Looks like a duplicate. It might be helpful to someone in the future to find this relation - took me a while :) BTW. It's fixed in 1.3.3 (this piece of information is missing here). > NullPointerException in SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:441 > ------------------------------------------------------------------------------------ > > Key: JBJCA-1347 > URL: https://issues.redhat.com/browse/JBJCA-1347 > Project: IronJacamar > Issue Type: Bug > Affects Versions: WildFly/IronJacamar 1.3.2.Final > Environment: CentOS 6 > Wildfly 10.0.0.Final (Iron Jacamar 1.3.2.Final) > PostgreSQL Server 9.5.5 > PostgreSQL JDBC driver 9.4.1208 and tried with 42.0.0 > Oracle Java version "1.8.0_112" > Java(TM) SE Runtime Environment (build 1.8.0_112-b15) > Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode) > Reporter: Brett Delle Grazie > Assignee: Flavia Rainone > Priority: Major > > Using a PostgreSQL XA datasource with statistics enabled we get a NullPointerException if the connection fails temporarily. > With JDBC driver 9.4.1208 Wildfly never reconnects to the PostgreSQL server with the next request and Wildfly must be restarted. With JDBC driver 42.0.0 it does reconnect on next request. > If statistics are disabled, the NPE does not occur and both drivers reconnect on the next request as expected. > Specific location of NPE: > https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.2.Final/c... > Note there is similar code on line 461 of the same class (in the exception handler) > Example configuration follows > With a PostgreSQL datasource configured in Wildfly as: > {code:xml} > <xa-datasource jndi-name="java:/DS.people" pool-name="DS.people" enabled="true" spy="true" statistics-enabled="true" use-java-context="true" use-ccm="true"> > <driver>postgresql</driver> > <xa-datasource-property name="ServerName">localhost</xa-datasource-property> > <xa-datasource-property name="PortNumber">5432</xa-datasource-property> > <xa-datasource-property name="DatabaseName">peopleviewstore</xa-datasource-property> > <xa-datasource-property name="ApplicationName">people</xa-datasource-property> > <xa-datasource-property name="assumeMinServerVersion">9.5</xa-datasource-property> > <xa-datasource-property name="connectTimeout">10</xa-datasource-property> > <xa-datasource-property name="currentSchema">public</xa-datasource-property> > <xa-datasource-property name="hostRecheckSeconds">10</xa-datasource-property> > <xa-datasource-property name="loginTimeout">10</xa-datasource-property> > <xa-datasource-property name="logUnclosedConnections">true</xa-datasource-property> > <xa-datasource-property name="socketTimeout">30</xa-datasource-property> > <xa-datasource-property name="targetServerType">master</xa-datasource-property> > <xa-datasource-property name="tcpKeepAlive">true</xa-datasource-property> > <xa-pool> > <min-pool-size>0</min-pool-size> > <initial-pool-size>0</initial-pool-size> > <max-pool-size>10</max-pool-size> > <allow-multiple-users>false</allow-multiple-users> > </xa-pool> > <timeout> > <xa-resource-timeout>0</xa-resource-timeout> > </timeout> > <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation> > <statement> > <track-statements>true</track-statements> > </statement> > <security> > <user-name></user-name> > <password></password> > </security> > <validation> > <validate-on-match>true</validate-on-match> > <use-fast-fail>true</use-fast-fail> > <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/> > <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/> > </validation> > </xa-datasource> > {code} > And corresponding driver configuration: > {code:xml} > <driver name="postgresql" module="org.postgresql"> > <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> > </driver> > {code} > we have deployed the JDBC driver as a module, module.xml looks like: > {code:xml} > <?xml version="1.0" ?> > <module xmlns="urn:jboss:module:1.3" name="org.postgresql" slot="main"> > <resources> > <resource-root path="postgresql-42.0.0.jar"/> > </resources> > <dependencies> > <module name="javax.api"/> > <module name="javax.transaction.api"/> > </dependencies> > </module> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-300) Boot time of application built via S2I is much longer than in before-Galleon times

by Petr Kremensky (Jira)

Petr Kremensky created WFWIP-300: ------------------------------------ Summary: Boot time of application built via S2I is much longer than in before-Galleon times Key: WFWIP-300 URL: https://issues.redhat.com/browse/WFWIP-300 Project: WildFly WIP Issue Type: Bug Components: OpenShift Reporter: Petr Kremensky Assignee: Jean Francois Denise Attachments: test-app.zip As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration. This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc): ||17.0-6||pod time||EAP boot||config time |#1 | 8283|6128|2155 |#2 | 9446|7548|1898 |#3 | 8767|6871| 1896 |#4 | 8568|6272| 2296 |#5 | 8000 |6362|1638 ||average ||8613ms||6636ms||1977ms ||18.0-7||pod time||EAP boot||config time |#1 |13769|5716|8053 |#2 |13362|5952|7410 |#3 |14261|6093|8168 |#4 |14322|6135|8187 |#5 |13921|6326|7595 ||average||13927ms||6044ms||7883ms pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}}) EAP boot = time of boot EAP itself == {{started in ..}} config time = the difference of previou timess = anything before EAP boot begins Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images. This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime. The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-989) Get time with seconds from tooltip in UI tests

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-989?page=com.atlassian.jira.plugin... ] Hayk Hovsepyan updated SWSQE-989: --------------------------------- Sprint: Kiali Sprint #32 > Get time with seconds from tooltip in UI tests > ---------------------------------------------- > > Key: SWSQE-989 > URL: https://issues.redhat.com/browse/SWSQE-989 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Hayk Hovsepyan > Priority: Minor > Labels: automation > > Date is displayed in different format in PF4: Oct 30, 8:21 am and full date is displayed in tooltip. We don't have solution for getting text from tooltip yet so we are ignoring seconds for now. We need to fix that to be able to compare with date received via REST which contains seconds. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-989) Get time with seconds from tooltip in UI tests

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-989?page=com.atlassian.jira.plugin... ] Hayk Hovsepyan reassigned SWSQE-989: ------------------------------------ Assignee: Hayk Hovsepyan > Get time with seconds from tooltip in UI tests > ---------------------------------------------- > > Key: SWSQE-989 > URL: https://issues.redhat.com/browse/SWSQE-989 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Hayk Hovsepyan > Priority: Minor > Labels: automation > > Date is displayed in different format in PF4: Oct 30, 8:21 am and full date is displayed in tooltip. We don't have solution for getting text from tooltip yet so we are ignoring seconds for now. We need to fix that to be able to compare with date received via REST which contains seconds. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Yeser Amer (Jira)

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

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13003) Support the SameSite cookie attribute

by Masafumi Miura (Jira)

[ https://issues.redhat.com/browse/WFLY-13003?page=com.atlassian.jira.plugi... ] Masafumi Miura edited comment on WFLY-13003 at 1/23/20 5:53 AM: ---------------------------------------------------------------- I've already raised UNDERTOW-1600 which is related to this feature. I've just updated a PR for UNDERTOW-1600 https://github.com/undertow-io/undertow/pull/816 which contains the following changes: - Add support for the SameSite=None attribute - Add SameSiteCookieHandler that can set the SameSite attribute on all cookies - Add a utility class SameSiteNoneIncompatibleClientChecker to detect user agents which are incompatible with the SameSite=None attribute. The regex is based on https://www.chromium.org/updates/same-site/incompatible-clients The SameSiteCookieHandler can be enabled with the predicate name "samesite-cookie" through expression-filter in the undertow subsystem. For example: {code:xml} <subsystem xmlns="urn:jboss:domain:undertow:7.0" ...> ... <server name="default-server"> ... <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <http-invoker security-realm="ApplicationRealm"/>  <filter-ref name="samesite-cookie"/>  </host> </server> ...(snip)... <filters>  <expression-filter name="samesite-cookie" expression="samesite-cookie(mode=strict)"/>    <expression-filter name="samesite-cookie" expression="samesite-cookie(mode=none)"/> </filters> </subsystem> {code} was (Author: mmiura): I've already raised UNDERTOW-1600 which is related to this feature. I've just updated a PR for UNDERTOW-1600 https://github.com/undertow-io/undertow/pull/816 which contains the following changes: - Add support for the SameSite=None attribute - Add SameSiteCookieHandler that can set the SameSite attribute on all cookies - Add a utility class SameSiteNoneIncompatibleClientChecker to detect user agents which are incompatible with the SameSite=None attribute The SameSiteCookieHandler can be enabled with the predicate name "samesite-cookie" through expression-filter in the undertow subsystem. For example: {code:xml} <subsystem xmlns="urn:jboss:domain:undertow:7.0" ...> ... <server name="default-server"> ... <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <http-invoker security-realm="ApplicationRealm"/>  <filter-ref name="samesite-cookie"/>  </host> </server> ...(snip)... <filters>  <expression-filter name="samesite-cookie" expression="samesite-cookie(mode=strict)"/>    <expression-filter name="samesite-cookie" expression="samesite-cookie(mode=none)"/> </filters> </subsystem> {code} > Support the SameSite cookie attribute > ------------------------------------- > > Key: WFLY-13003 > URL: https://issues.redhat.com/browse/WFLY-13003 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Flavia Rainone > Priority: Major > > Chrome 80 is going to significantly change how cookies are handled, as per this notice at [1], with a bit of an explanation of what the same site attribute means at [2]. > At the moment the Servlet specification has no way of setting this particular attribute, and it is not possible to configure it via container specific configuration in WildFly at present (it can only be done by writing some Undertow specific code). > I propose we add a same-site-cookie-attribute predicated handler to undertow, which takes an optional cookie name regex, and the value for the attribute to set. > This would allow users to configure the SameSite attribute based on cookie name, and also potentially based on any other attributes including user agent, as it sounds like some browsers may have bugs that means this might need to be set on a per user agent basis. > [1] https://www.chromestatus.com/feature/5088147346030592 > [2] https://web.dev/samesite-cookies-explained/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13003) Support the SameSite cookie attribute

by Masafumi Miura (Jira)

[ https://issues.redhat.com/browse/WFLY-13003?page=com.atlassian.jira.plugi... ] Masafumi Miura edited comment on WFLY-13003 at 1/23/20 5:38 AM: ---------------------------------------------------------------- I've already raised UNDERTOW-1600 which is related to this feature. I've just updated a PR for UNDERTOW-1600 https://github.com/undertow-io/undertow/pull/816 which contains the following changes: - Add support for the SameSite=None attribute - Add SameSiteCookieHandler that can set the SameSite attribute on all cookies - Add a utility class SameSiteNoneIncompatibleClientChecker to detect user agents which are incompatible with the SameSite=None attribute The SameSiteCookieHandler can be enabled with the predicate name "samesite-cookie" through expression-filter in the undertow subsystem. For example: {code:xml} <subsystem xmlns="urn:jboss:domain:undertow:7.0" ...> ... <server name="default-server"> ... <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <http-invoker security-realm="ApplicationRealm"/>  <filter-ref name="samesite-cookie"/>  </host> </server> ...(snip)... <filters>  <expression-filter name="samesite-cookie" expression="samesite-cookie(mode=strict)"/>    <expression-filter name="samesite-cookie" expression="samesite-cookie(mode=none)"/> </filters> </subsystem> {code} was (Author: mmiura): I've already raised UNDERTOW-1600 which is related to this feature. I've just updated a PR for UNDERTOW-1600 https://github.com/undertow-io/undertow/pull/816 which contains the following changes: - Add support for the SameSite=None attribute - Add SameSiteCookieHandler that can set the SameSite attribute on all cookies - Add a utility class SameSiteNoneIncompatibleClientChecker to detect user agents which are incompatible with the SameSite=None attribute > Support the SameSite cookie attribute > ------------------------------------- > > Key: WFLY-13003 > URL: https://issues.redhat.com/browse/WFLY-13003 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Flavia Rainone > Priority: Major > > Chrome 80 is going to significantly change how cookies are handled, as per this notice at [1], with a bit of an explanation of what the same site attribute means at [2]. > At the moment the Servlet specification has no way of setting this particular attribute, and it is not possible to configure it via container specific configuration in WildFly at present (it can only be done by writing some Undertow specific code). > I propose we add a same-site-cookie-attribute predicated handler to undertow, which takes an optional cookie name regex, and the value for the attribute to set. > This would allow users to configure the SameSite attribute based on cookie name, and also potentially based on any other attributes including user agent, as it sounds like some browsers may have bugs that means this might need to be set on a per user agent basis. > [1] https://www.chromestatus.com/feature/5088147346030592 > [2] https://web.dev/samesite-cookies-explained/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13003) Support the SameSite cookie attribute

by Masafumi Miura (Jira)

[ https://issues.redhat.com/browse/WFLY-13003?page=com.atlassian.jira.plugi... ] Masafumi Miura commented on WFLY-13003: --------------------------------------- I've already raised UNDERTOW-1600 which is related to this feature. I've just updated a PR for UNDERTOW-1600 https://github.com/undertow-io/undertow/pull/816 which contains the following changes: - Add support for the SameSite=None attribute - Add SameSiteCookieHandler that can set the SameSite attribute on all cookies - Add a utility class SameSiteNoneIncompatibleClientChecker to detect user agents which are incompatible with the SameSite=None attribute > Support the SameSite cookie attribute > ------------------------------------- > > Key: WFLY-13003 > URL: https://issues.redhat.com/browse/WFLY-13003 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Flavia Rainone > Priority: Major > > Chrome 80 is going to significantly change how cookies are handled, as per this notice at [1], with a bit of an explanation of what the same site attribute means at [2]. > At the moment the Servlet specification has no way of setting this particular attribute, and it is not possible to configure it via container specific configuration in WildFly at present (it can only be done by writing some Undertow specific code). > I propose we add a same-site-cookie-attribute predicated handler to undertow, which takes an optional cookie name regex, and the value for the attribute to set. > This would allow users to configure the SameSite attribute based on cookie name, and also potentially based on any other attributes including user agent, as it sounds like some browsers may have bugs that means this might need to be set on a per user agent basis. > [1] https://www.chromestatus.com/feature/5088147346030592 > [2] https://web.dev/samesite-cookies-explained/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12845) Upgrade JGroups to 4.1.9.Final

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12845?page=com.atlassian.jira.plugi... ] Radoslav Husar reassigned WFLY-12845: ------------------------------------- Assignee: Radoslav Husar (was: Paul Ferraro) > Upgrade JGroups to 4.1.9.Final > ------------------------------ > > Key: WFLY-12845 > URL: https://issues.redhat.com/browse/WFLY-12845 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 18.0.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > Just a tracker for now. > Changelog > https://issues.jboss.org/projects/JGRP/versions/12343163 > The fix for JGRP-2409 has caused compilation failure thus updating the https://github.com/wildfly-clustering/wildfly/tree/jgroups-master branch with the fix from which PR will be opened. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 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] Yoann pushed his work here: https://github.com/hibernate/hibernate-validator/pull/1059 . Be careful, we add to fix a few things in your bean implementation. See https://github.com/hibernate/hibernate-validator/pull/1059#issuecomment-5... and https://github.com/hibernate/hibernate-validator/pull/1059/files#diff-824... for an example. We have added some tests in HV. Could you adjust your PR and test that using this HV PR + your updated bean fixes the original issue? Note that this PR is for the 6.1 branch, I will backport it to 6.0 for WildFly consumption as soon as we all agree everything works OK. Thanks. > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13008) TCPPING is unreliable with default num_discovery_runs="1"

by Radoslav Husar (Jira)

Radoslav Husar created WFLY-13008: ------------------------------------- Summary: TCPPING is unreliable with default num_discovery_runs="1" Key: WFLY-13008 URL: https://issues.redhat.com/browse/WFLY-13008 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 19.0.0.Beta1 Reporter: Radoslav Husar Assignee: Paul Ferraro It appears that {{TCPPING}} is unreliable with default {{num_discovery_runs="1"}} and results in singleton clusters and subsequent merging as can be seen when running the clustering testsuite using TCPPING instead of MPING. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13008) TCPPING is unreliable with default num_discovery_runs="1"

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13008?page=com.atlassian.jira.plugi... ] Radoslav Husar reassigned WFLY-13008: ------------------------------------- Assignee: Radoslav Husar (was: Paul Ferraro) > TCPPING is unreliable with default num_discovery_runs="1" > --------------------------------------------------------- > > Key: WFLY-13008 > URL: https://issues.redhat.com/browse/WFLY-13008 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 19.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > It appears that {{TCPPING}} is unreliable with default {{num_discovery_runs="1"}} and results in singleton clusters and subsequent merging as can be seen when running the clustering testsuite using TCPPING instead of MPING. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4965) [DMN Designer] Dragged structure fields nest in a counterintuitive way

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4965?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4965: ------------------------------------- [~evacchi] sorry, I would like to clarify what is the expected fix from your side to be 100% percent sure all parties understand. Do you require just movement of the drag handle icon or also some change in handlers? > [DMN Designer] Dragged structure fields nest in a counterintuitive way > ---------------------------------------------------------------------- > > Key: DROOLS-4965 > URL: https://issues.redhat.com/browse/DROOLS-4965 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: drag-1.gif > > > Because the handle is aligned leftmost, I tend to keep it aligned to the left; > but this causes the field to be "unnested" and moved to toplevel. > I suggest to draw the handle aligned to label, instead of the border, suggesting that drag has to start from that point > !drag-1.gif! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4950) Different behavior of collection unary checks

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4950?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4950: ------------------------------------- [~danielezonca] Thank you for your comment. From my point of view we need to clarify the difference directly in UI. Just the fact your explanation is non trivial text is for me an evidence it is needed. > Different behavior of collection unary checks > --------------------------------------------- > > Key: DROOLS-4950 > URL: https://issues.redhat.com/browse/DROOLS-4950 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Critical > Labels: drools-tools > Attachments: MySpace_simplenumbers.zip, Screenshot from 2020-01-17 13-56-02.png, Screenshot from 2020-01-17 13-56-10.png > > > Issue was spotted during DROOLS-4698 review. However it can be handled separately. > There is issue that user can define collection unary test with UI editor [1] but also as plain text [2]. The problem is the result is different. > [1] > !Screenshot from 2020-01-17 13-56-02.png|thumbnail! > [2] > !Screenshot from 2020-01-17 13-56-10.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4600) Embedded Camel endpoints don't work with executable model

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4600?page=com.atlassian.jira.plug... ] Toshiya Kobayashi commented on DROOLS-4600: ------------------------------------------- {code:java} KieBuilder kieBuilder = ks.newKieBuilder(kfs).buildAll(ExecutableModelProject.class); {code} {noformat} [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.657 s <<< FAILURE! - in org.kie.camel.embedded.camel.component.KieEmbeddedEndpointChannelTest [ERROR] testChannelSupport(org.kie.camel.embedded.camel.component.KieEmbeddedEndpointChannelTest) Time elapsed: 3.296 s <<< ERROR! java.lang.RuntimeException: This doesn't work on arrayAccessExpr convert them to a method call at org.drools.modelcompiler.builder.generator.DrlxParseUtil.findRootNodeViaScopeRec(DrlxParseUtil.java:374) at org.drools.modelcompiler.builder.generator.DrlxParseUtil.lambda$findRootNodeViaScopeRec$4(DrlxParseUtil.java:385) at java.util.Optional.map(Optional.java:215) at org.drools.modelcompiler.builder.generator.DrlxParseUtil.findRootNodeViaScopeRec(DrlxParseUtil.java:382) at org.drools.modelcompiler.builder.generator.DrlxParseUtil.findRemoveRootNodeViaScope(DrlxParseUtil.java:360) at org.drools.modelcompiler.builder.generator.DrlxParseUtil.findRootNodeViaScope(DrlxParseUtil.java:364) at org.drools.modelcompiler.builder.generator.Consequence.isDroolsMethod(Consequence.java:398) at org.drools.modelcompiler.builder.generator.Consequence.rewriteRHS(Consequence.java:300) at org.drools.modelcompiler.builder.generator.Consequence.executeCall(Consequence.java:250) at org.drools.modelcompiler.builder.generator.Consequence.createCall(Consequence.java:152) at org.drools.modelcompiler.builder.generator.ModelGenerator.processRule(ModelGenerator.java:219) at org.drools.modelcompiler.builder.generator.ModelGenerator.generateModel(ModelGenerator.java:159) at org.drools.modelcompiler.builder.ModelBuilderImpl.compileKnowledgePackages(ModelBuilderImpl.java:182) at org.drools.modelcompiler.builder.ModelBuilderImpl.buildRules(ModelBuilderImpl.java:126) at org.drools.modelcompiler.builder.ModelBuilderImpl.buildPackages(ModelBuilderImpl.java:76) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:108) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:100) at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:261) at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:75) at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:271) at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:239) at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:200) at org.kie.camel.embedded.camel.component.KieCamelTestSupport.registerKnowledgeRuntime(KieCamelTestSupport.java:100) at org.kie.camel.embedded.camel.component.KieEmbeddedEndpointChannelTest.configureDroolsContext(KieEmbeddedEndpointChannelTest.java:99) at org.kie.camel.embedded.camel.component.KieCamelTestSupport.createJndiContext(KieCamelTestSupport.java:85) at org.apache.camel.test.junit4.CamelTestSupport.createRegistry(CamelTestSupport.java:776) at org.apache.camel.test.junit4.CamelTestSupport.createCamelContext(CamelTestSupport.java:770) at org.apache.camel.test.junit4.CamelTestSupport.doSetUp(CamelTestSupport.java:325) at org.apache.camel.test.junit4.CamelTestSupport.setUp(CamelTestSupport.java:281) at org.kie.camel.embedded.camel.component.KieCamelTestSupport.setUp(KieCamelTestSupport.java:69) {noformat} > Embedded Camel endpoints don't work with executable model > --------------------------------------------------------- > > Key: DROOLS-4600 > URL: https://issues.redhat.com/browse/DROOLS-4600 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.27.0.Final > Reporter: Tibor Zimanyi > Assignee: Toshiya Kobayashi > Priority: Major > Labels: good-first-issue > > When having and embedded Camel endpoint it DRL, it doesn't work with executable model. Reproducer can be found here [1]. For the test to reproduce the issue, it is needed to use executable model project in the buildAll() call here [2]. > [1] https://github.com/kiegroup/droolsjbpm-integration/blob/5f95febee0c081310... > [2] https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-camel/... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4968) Guided Rule Editor removes matches statement from rule

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4968?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4968: -------------------------------- Release Notes Text: The fix assumes just operator 'matches'. It means if user will import a rdrl of the same format, but using different operator than 'matches', the rdrl will be not auto corrected to currently supported format. Affects: Release Notes > Guided Rule Editor removes matches statement from rule > ------------------------------------------------------ > > Key: DROOLS-4968 > URL: https://issues.redhat.com/browse/DROOLS-4968 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 7.31.0.Final > Reporter: Daniel José dos Santos > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools, support > > A rdrl file containing the following constraint is changed after being opened with the Guided Rule Editor in business central: > * before: > {code} > FactA(type == "A", (symbol != null && matches "P.*") || (symbol != null && matches "p.*") ) > {code} > * after: > {code} > FactA(type == "A", (symbol != null && ) || (symbol != null && ) ) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-264) Allow logger nodes to be used on different log contexts

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-264?page=com.atlassian.jira.plugi... ] James Perkins updated LOGMGR-264: --------------------------------- Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/288 > Allow logger nodes to be used on different log contexts > ------------------------------------------------------- > > Key: LOGMGR-264 > URL: https://issues.redhat.com/browse/LOGMGR-264 > Project: JBoss Log Manager > Issue Type: Enhancement > Components: core > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > Fix For: 2.2.0.Final, 3.0.0.Final > > > Currently logger nodes belong to a single log context. This means that shared classes with static loggers are created on the log context that initializes the class. It would be useful if static loggers on shared classes could log to different log contexts. > The concept would be something of a switchable log context for a logger. This would be based on the TCCL and the class loader needs to be registered in order to enable this functionality. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-264) Allow logger nodes to be used on different log contexts

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-264?page=com.atlassian.jira.plugi... ] James Perkins updated LOGMGR-264: --------------------------------- Fix Version/s: 2.2.0.Final 3.0.0.Final > Allow logger nodes to be used on different log contexts > ------------------------------------------------------- > > Key: LOGMGR-264 > URL: https://issues.redhat.com/browse/LOGMGR-264 > Project: JBoss Log Manager > Issue Type: Enhancement > Components: core > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > Fix For: 2.2.0.Final, 3.0.0.Final > > > Currently logger nodes belong to a single log context. This means that shared classes with static loggers are created on the log context that initializes the class. It would be useful if static loggers on shared classes could log to different log contexts. > The concept would be something of a switchable log context for a logger. This would be based on the TCCL and the class loader needs to be registered in order to enable this functionality. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-264) Allow logger nodes to be used on different log contexts

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-264?page=com.atlassian.jira.plugi... ] James Perkins updated LOGMGR-264: --------------------------------- Issue Type: Feature Request (was: Enhancement) > Allow logger nodes to be used on different log contexts > ------------------------------------------------------- > > Key: LOGMGR-264 > URL: https://issues.redhat.com/browse/LOGMGR-264 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > Fix For: 2.2.0.Final, 3.0.0.Final > > > Currently logger nodes belong to a single log context. This means that shared classes with static loggers are created on the log context that initializes the class. It would be useful if static loggers on shared classes could log to different log contexts. > The concept would be something of a switchable log context for a logger. This would be based on the TCCL and the class loader needs to be registered in order to enable this functionality. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4791) HttpManagementConstantHeadersTestCase causes tests failures

by Richard Opalka (Jira)

[ https://issues.redhat.com/browse/WFCORE-4791?page=com.atlassian.jira.plug... ] Richard Opalka commented on WFCORE-4791: ---------------------------------------- With the PR applied I was not able to reproduce the problem locally [~tterem] > HttpManagementConstantHeadersTestCase causes tests failures > ----------------------------------------------------------- > > Key: WFCORE-4791 > URL: https://issues.redhat.com/browse/WFCORE-4791 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Richard Opalka > Assignee: Tomas Terem > Priority: Major > Fix For: 11.0.0.Beta8 > > Attachments: testsuite.log > > > Commit 68928b0b in WildFly-Core introduced new regression. > High probably test doesn't do proper test environment clean up > and some tests following it are thus failing. The issue isn't visible > in our CI environment so it probably depends on actual tests ordering. > I am able to reproduce this issue on my laptop always. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4964) [DMN Designer] Type designer scrolls up to the top when any element of the table is clicked

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4964?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-4964: ----------------------------------- Tester: Jozef Marko > [DMN Designer] Type designer scrolls up to the top when any element of the table is clicked > ------------------------------------------------------------------------------------------- > > Key: DROOLS-4964 > URL: https://issues.redhat.com/browse/DROOLS-4964 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: scroll-up.gif > > > - scroll down > - click on a non-active part of the table (i.e. not a button) > result: the viewport scrolls up to the top > !scroll-up.gif! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4963) [DMN Designer] Type designer does not show save/cancel when many constraints are presents and the inspector is open

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4963?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-4963: ----------------------------------- Tester: Jozef Marko > [DMN Designer] Type designer does not show save/cancel when many constraints are presents and the inspector is open > ------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-4963 > URL: https://issues.redhat.com/browse/DROOLS-4963 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-22 16-16-29.png, Screenshot from 2020-01-22 16-16-29.png > > > hiding the inspector on the right-hand side uncovers the save/cancel buttons > !Screenshot from 2020-01-22 16-16-29.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4966) [DMN Designer] Dragging a field at the bottom of type designer

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4966?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-4966: ----------------------------------- Tester: Jozef Marko > [DMN Designer] Dragging a field at the bottom of type designer > --------------------------------------------------------------- > > Key: DROOLS-4966 > URL: https://issues.redhat.com/browse/DROOLS-4966 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: drag-2.gif > > > - add several fields/structures so that the list exceeds the viewport > - scroll down to the bottom of the editor > - try dragging the bottom field > - the view does not scroll, but the field will jump "up" at seemingly random positions at the top > it's nearly impossible to reorder a field when it's at the bottom -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4965) [DMN Designer] Dragged structure fields nest in a counterintuitive way

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4965?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-4965: ----------------------------------- Tester: Jozef Marko > [DMN Designer] Dragged structure fields nest in a counterintuitive way > ---------------------------------------------------------------------- > > Key: DROOLS-4965 > URL: https://issues.redhat.com/browse/DROOLS-4965 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: drag-1.gif > > > Because the handle is aligned leftmost, I tend to keep it aligned to the left; > but this causes the field to be "unnested" and moved to toplevel. > I suggest to draw the handle aligned to label, instead of the border, suggesting that drag has to start from that point > !drag-1.gif! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4965) [DMN Designer] Dragged structure fields nest in a counterintuitive way

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4965?page=com.atlassian.jira.plug... ] Michael Anstis reassigned DROOLS-4965: -------------------------------------- Assignee: Guilherme Gomes (was: Michael Anstis) > [DMN Designer] Dragged structure fields nest in a counterintuitive way > ---------------------------------------------------------------------- > > Key: DROOLS-4965 > URL: https://issues.redhat.com/browse/DROOLS-4965 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: drag-1.gif > > > Because the handle is aligned leftmost, I tend to keep it aligned to the left; > but this causes the field to be "unnested" and moved to toplevel. > I suggest to draw the handle aligned to label, instead of the border, suggesting that drag has to start from that point > !drag-1.gif! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4966) [DMN Designer] Dragging a field at the bottom of type designer

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4966?page=com.atlassian.jira.plug... ] Michael Anstis reassigned DROOLS-4966: -------------------------------------- Assignee: Guilherme Gomes (was: Michael Anstis) > [DMN Designer] Dragging a field at the bottom of type designer > --------------------------------------------------------------- > > Key: DROOLS-4966 > URL: https://issues.redhat.com/browse/DROOLS-4966 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: drag-2.gif > > > - add several fields/structures so that the list exceeds the viewport > - scroll down to the bottom of the editor > - try dragging the bottom field > - the view does not scroll, but the field will jump "up" at seemingly random positions at the top > it's nearly impossible to reorder a field when it's at the bottom -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4963) [DMN Designer] Type designer does not show save/cancel when many constraints are presents and the inspector is open

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4963?page=com.atlassian.jira.plug... ] Michael Anstis commented on DROOLS-4963: ---------------------------------------- [~evacchi] Both your screenshots seem identical!!? Or I am missing some detail? I tried to replicate something, any strange behaviour, but was unable to see any save/cancel buttons appearing/disappearing. Could you please provide a (corrected) second screenshot or more narrative? > [DMN Designer] Type designer does not show save/cancel when many constraints are presents and the inspector is open > ------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-4963 > URL: https://issues.redhat.com/browse/DROOLS-4963 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-22 16-16-29.png, Screenshot from 2020-01-22 16-16-29.png > > > hiding the inspector on the right-hand side uncovers the save/cancel buttons > !Screenshot from 2020-01-22 16-16-29.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4963) [DMN Designer] Type designer does not show save/cancel when many constraints are presents and the inspector is open

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4963?page=com.atlassian.jira.plug... ] Michael Anstis reassigned DROOLS-4963: -------------------------------------- Assignee: Guilherme Gomes (was: Michael Anstis) > [DMN Designer] Type designer does not show save/cancel when many constraints are presents and the inspector is open > ------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-4963 > URL: https://issues.redhat.com/browse/DROOLS-4963 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-22 16-16-29.png, Screenshot from 2020-01-22 16-16-29.png > > > hiding the inspector on the right-hand side uncovers the save/cancel buttons > !Screenshot from 2020-01-22 16-16-29.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4964) [DMN Designer] Type designer scrolls up to the top when any element of the table is clicked

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4964?page=com.atlassian.jira.plug... ] Michael Anstis reassigned DROOLS-4964: -------------------------------------- Assignee: Guilherme Gomes (was: Michael Anstis) > [DMN Designer] Type designer scrolls up to the top when any element of the table is clicked > ------------------------------------------------------------------------------------------- > > Key: DROOLS-4964 > URL: https://issues.redhat.com/browse/DROOLS-4964 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: scroll-up.gif > > > - scroll down > - click on a non-active part of the table (i.e. not a button) > result: the viewport scrolls up to the top > !scroll-up.gif! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4964) [DMN Designer] Type designer scrolls up to the top when any element of the table is clicked

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4964?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-4964: ----------------------------------- Labels: drools-tools (was: ) > [DMN Designer] Type designer scrolls up to the top when any element of the table is clicked > ------------------------------------------------------------------------------------------- > > Key: DROOLS-4964 > URL: https://issues.redhat.com/browse/DROOLS-4964 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: scroll-up.gif > > > - scroll down > - click on a non-active part of the table (i.e. not a button) > result: the viewport scrolls up to the top > !scroll-up.gif! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4965) [DMN Designer] Dragged structure fields nest in a counterintuitive way

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4965?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-4965: ----------------------------------- Labels: drools-tools (was: ) > [DMN Designer] Dragged structure fields nest in a counterintuitive way > ---------------------------------------------------------------------- > > Key: DROOLS-4965 > URL: https://issues.redhat.com/browse/DROOLS-4965 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: drag-1.gif > > > Because the handle is aligned leftmost, I tend to keep it aligned to the left; > but this causes the field to be "unnested" and moved to toplevel. > I suggest to draw the handle aligned to label, instead of the border, suggesting that drag has to start from that point > !drag-1.gif! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4966) [DMN Designer] Dragging a field at the bottom of type designer

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4966?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-4966: ----------------------------------- Labels: drools-tools (was: ) > [DMN Designer] Dragging a field at the bottom of type designer > --------------------------------------------------------------- > > Key: DROOLS-4966 > URL: https://issues.redhat.com/browse/DROOLS-4966 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: drag-2.gif > > > - add several fields/structures so that the list exceeds the viewport > - scroll down to the bottom of the editor > - try dragging the bottom field > - the view does not scroll, but the field will jump "up" at seemingly random positions at the top > it's nearly impossible to reorder a field when it's at the bottom -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4963) [DMN Designer] Type designer does not show save/cancel when many constraints are presents and the inspector is open

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4963?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-4963: ----------------------------------- Labels: drools-tools (was: ) > [DMN Designer] Type designer does not show save/cancel when many constraints are presents and the inspector is open > ------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-4963 > URL: https://issues.redhat.com/browse/DROOLS-4963 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Edoardo Vacchi > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-22 16-16-29.png, Screenshot from 2020-01-22 16-16-29.png > > > hiding the inspector on the right-hand side uncovers the save/cancel buttons > !Screenshot from 2020-01-22 16-16-29.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4968) Guided Rule Editor removes matches statement from rule

by Daniel José dos Santos (Jira)

[ https://issues.redhat.com/browse/DROOLS-4968?page=com.atlassian.jira.plug... ] Daniel José dos Santos updated DROOLS-4968: ------------------------------------------- Tester: Jozef Marko (was: Anna Dupliak) > Guided Rule Editor removes matches statement from rule > ------------------------------------------------------ > > Key: DROOLS-4968 > URL: https://issues.redhat.com/browse/DROOLS-4968 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 7.31.0.Final > Reporter: Daniel José dos Santos > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools, support > > A rdrl file containing the following constraint is changed after being opened with the Guided Rule Editor in business central: > * before: > {code} > FactA(type == "A", (symbol != null && matches "P.*") || (symbol != null && matches "p.*") ) > {code} > * after: > {code} > FactA(type == "A", (symbol != null && ) || (symbol != null && ) ) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4968) Guided Rule Editor removes matches statement from rule

by Daniel José dos Santos (Jira)

[ https://issues.redhat.com/browse/DROOLS-4968?page=com.atlassian.jira.plug... ] Daniel José dos Santos moved RHPAM-2652 to DROOLS-4968: ------------------------------------------------------- Project: Drools (was: Red Hat Process Automation Manager) Key: DROOLS-4968 (was: RHPAM-2652) Workflow: GIT Pull Request workflow (was: CDW with docs v1) Docs QE Status: NEW Component/s: Guided Decision Table Editor (was: Business Central) Affects Version/s: 7.31.0.Final (was: 7.5.1.GA) QE Status: NEW > Guided Rule Editor removes matches statement from rule > ------------------------------------------------------ > > Key: DROOLS-4968 > URL: https://issues.redhat.com/browse/DROOLS-4968 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 7.31.0.Final > Reporter: Daniel José dos Santos > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools, support > > A rdrl file containing the following constraint is changed after being opened with the Guided Rule Editor in business central: > * before: > {code} > FactA(type == "A", (symbol != null && matches "P.*") || (symbol != null && matches "p.*") ) > {code} > * after: > {code} > FactA(type == "A", (symbol != null && ) || (symbol != null && ) ) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-4959?page=com.atlassian.jira.plug... ] Toni Rikkola updated DROOLS-4959: --------------------------------- Labels: (was: drools-tools) > 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 > > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4967) decision table rules are not loaded into kiebase

by Volodymyr Shymkiv (Jira)

Volodymyr Shymkiv created DROOLS-4967: ----------------------------------------- Summary: decision table rules are not loaded into kiebase Key: DROOLS-4967 URL: https://issues.redhat.com/browse/DROOLS-4967 Project: Drools Issue Type: Bug Components: decision tables Affects Versions: 7.31.0.Final, 7.30.0.Final, 7.29.0.Final, 7.28.0.Final, 7.27.0.Final, 7.26.0.Final, 7.25.0.Final, 7.24.0.Final, 7.23.0.Final, 7.22.0.Final, 7.21.0.Final Reporter: Volodymyr Shymkiv Assignee: Mario Fusco When compiling xls decision table, wrong ruleset name is parsed from the xls file. This can lead to multiple issues, like rules being filtered out by kmodule.xml configuration. According to documentation, decision table begins with a cell at second or third column, having value RuleSet. The cell on the right of this one contains the name of the rule set, which we want to use as a package name. The problem lies in naive approach to parsing the package name from the xls file. As you can see in project drools-compiler, class org.drools.compiler.kie.builder.impl.KieBuilderImpl method packageNameFromDtable, it execute as follows: # find "RuleSet" string in the binary data # find and return the nearest string which can act as a valid java package name The problem is, the string returned from packageNameFromDtable is NOT the value of the cell next to the RuleSet. It is actually a value of a random cell. To understand the problem, we need to understand the binary content of the actual xls file. Every cell is presented as a few bytes, containing cell's value, position, and other information. The "problematic" thing here is, the _order_ of the cells in the binary data is NOT constant. BUT the code really just reads the cell _binary_ next to the "RuleSet" cell. Problem is present since version 7.21 as it is caused by a fix for DROOLS-3888 - commit 9a179b6e6b955889200b0258ccd18cd1a5f14b46 In our case, this results in rules not being loaded, as they are filtered out by kmodule.xml configuration. We have a lot of decision tables we want to migrate from an older drools version, and most of them are now ignored due to this bug. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2020