February 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (DROOLS-1939) [DMN Editor] Toolbar reacts on the Enter key

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-1939?page=com.atlassian.jira.plug... ] Jozef Marko resolved DROOLS-1939. --------------------------------- Resolution: Out of Date > [DMN Editor] Toolbar reacts on the Enter key > -------------------------------------------- > > Key: DROOLS-1939 > URL: https://issues.redhat.com/browse/DROOLS-1939 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.1.0.Beta2 > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Trivial > Labels: reported-by-qe > Attachments: 1.png, 2.png, 3.png, 4.png > > -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-1829) Guided Decision Table Editor: Individual BRL Variable Columns cannot be movable

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-1829?page=com.atlassian.jira.plug... ] Jozef Marko closed DROOLS-1829. ------------------------------- Resolution: Out of Date > Guided Decision Table Editor: Individual BRL Variable Columns cannot be movable > ------------------------------------------------------------------------------- > > Key: DROOLS-1829 > URL: https://issues.redhat.com/browse/DROOLS-1829 > Project: Drools > Issue Type: Enhancement > Components: Guided Decision Table Editor > Affects Versions: 7.0.0.Beta6 > Reporter: Michael Anstis > Priority: Major > > It is possible to drag and drop columns in a Guided Decision Table to re-order them; however it is currently impossible (and arguably should remain impossible) to re-order individual "BRL Variable Columns" because their order is determined by the underlying BRL definition, which is based on {{RuleModel}}. For example > {code} > Person( age == @{age} ) > Income( bonus > @{bonus} ) > {code} > It should not be possible to re-order "age" and "bonus" since the {{IPattern}} objects would need re-ordering in the {{RuleModel}}. Obviously the scenario gets more complicated with more complex BRL definitions. > This all said and done; when hovering over a "BRL Variable Column" header the mouse pointer still changes to a "hand" suggesting the column can be moved. The flag for "movable" columns exists at the column-level whereas it needs to be moved to the column header meta-data. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14348) Unhelpful failure message 'WFLYJCA0032: Unable to start the ds because it generated more than one cf'

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-14348?page=com.atlassian.jira.plugi... ] Bartosz Baranowski edited comment on WFLY-14348 at 2/11/21 3:58 AM: -------------------------------------------------------------------- Welp its tad complicated. Does not matter if its deployed directly or as module. Thing is it IJ silently logs error and carries on when there is no connection URL, thrown from [AbstractDsDeployer.java#L312|https://github.com/ironjacamar/ironjacamar/b...] --> [LocalManagedConnectionFactory.java#L105 |https://github.com/ironjacamar/ironjacamar/blob/1.4/adapters/src/main/java/org/jboss/jca/adapters/jdbc/local/LocalManagedConnectionFactory.java#L105 ]and logged at [AbstractDsDeployer.java#L328|https://github.com/ironjacamar/ironjacamar/b...] : {quote}javax.resource.ResourceException: IJ031081: ConnectionURL is undefined{quote} Im still trying to figure out why its silently dropped. > Unhelpful failure message 'WFLYJCA0032: Unable to start the ds because it generated more than one cf' > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-14348 > URL: https://issues.redhat.com/browse/WFLY-14348 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Brian Stansberry > Assignee: Bartosz Baranowski > Priority: Major > > Playing with driver and DS installation I ended up with this in the server log: > {code} > 10:54:11,424 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "datasources"), > ("data-source" => "Postgres") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.data-source.Postgres" => "WFLYJCA0033: Error during the deployment of Postgres > Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}} > {code} > That was quite cryptic. > 1) The 'ds' and 'cf' abbreviations should be replaced with full words. To me this is the minimum resolution of this issue. > 2) If it is possible to make a reasonably likely guess at what would lead to this situation and provide that info in the message, that would be nice. > Context: > I tried deploying a JDBC driver and then adding a datasource using a CLI command: > {code} > data-source add --name=Postgres --driver-name=postgresql-42.2.18.jar --jndi-name=java:jboss/datasources/Postgres > {code} > The 3 params are the required ones. I wasn't surprised that wasn't sufficient and I understand that what's required beyond that can vary from driver to driver. But those are the required ones, so users experimenting with WildFly are liable to do what I did. (If any other params *should be* required, someone please file a separate issue.) > Adding a connection-url param allowed the command to work. If that param shouldn't be required, but not providing it is a likely cause of this problem, perhaps the WFLYJCA0032 message should note that as a hint? -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14421) Too many open file Descriptors in Wildfly-18

by Manas Panda (Jira)

Manas Panda created WFLY-14421: ---------------------------------- Summary: Too many open file Descriptors in Wildfly-18 Key: WFLY-14421 URL: https://issues.redhat.com/browse/WFLY-14421 Project: WildFly Issue Type: Task Reporter: Manas Panda Assignee: Brian Stansberry In the application code deployed in wildfly10, if the fileinputstream is not closed programmatically (its a miss in the code), during the GC (G1GC) cycle, the orphan references of the opened file input streams are closed, so the number of open file descriptor is not growing. However, after the upgrade of the wildfly10 to wildfly18, the file input streams which are not closed programmatically are not getting closed during the GC (G1GC) cycle due to which the number of open file descriptors are growing. We agree that the input streams have to be closed programmatically in the application code which we did now, but would like to understand the reason behind this behavior change in wildfly18. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (SWSQE-1202) UI Automations - Overview Filters Apply

by Praneeth Bajjuri (Jira)

[ https://issues.redhat.com/browse/SWSQE-1202?page=com.atlassian.jira.plugi... ] Praneeth Bajjuri closed SWSQE-1202. ----------------------------------- Resolution: Done > UI Automations - Overview Filters Apply > --------------------------------------- > > Key: SWSQE-1202 > URL: https://issues.redhat.com/browse/SWSQE-1202 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Praneeth Bajjuri > Priority: Major > Labels: automation > > Overview page contains Filter options. > We need to automate all filter types apply and result checking. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (SWSQE-1202) UI Automations - Overview Filters Apply

by Praneeth Bajjuri (Jira)

[ https://issues.redhat.com/browse/SWSQE-1202?page=com.atlassian.jira.plugi... ] Praneeth Bajjuri reassigned SWSQE-1202: --------------------------------------- Assignee: Praneeth Bajjuri (was: Sunil Kondkar) > UI Automations - Overview Filters Apply > --------------------------------------- > > Key: SWSQE-1202 > URL: https://issues.redhat.com/browse/SWSQE-1202 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Praneeth Bajjuri > Priority: Major > Labels: automation > > Overview page contains Filter options. > We need to automate all filter types apply and result checking. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (SWSQE-1269) Add Applications Filter tests

by Praneeth Bajjuri (Jira)

[ https://issues.redhat.com/browse/SWSQE-1269?page=com.atlassian.jira.plugi... ] Praneeth Bajjuri resolved SWSQE-1269. ------------------------------------- Resolution: Done > Add Applications Filter tests > ----------------------------- > > Key: SWSQE-1269 > URL: https://issues.redhat.com/browse/SWSQE-1269 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Praneeth Bajjuri > Priority: Major > Labels: automation > > Add missing filters for applications by: > 1. Istio Sidecar > 2. Health -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14420) Automatic credential store update not triggered when enabling single-sign-on using a credential-reference

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFLY-14420?page=com.atlassian.jira.plugi... ] Farah Juma commented on WFLY-14420: ----------------------------------- Thanks very much, [~pferraro]! > Automatic credential store update not triggered when enabling single-sign-on using a credential-reference > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-14420 > URL: https://issues.redhat.com/browse/WFLY-14420 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Farah Juma > Assignee: Paul Ferraro > Priority: Major > > When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps: > > {code:xml} > ### Pre-requisite steps > /subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true) > /subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain) > /subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS) > ### Enable single-sign-on > /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword}) > # At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code} > > This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered. > As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14420) Automatic credential store update not triggered when enabling single-sign-on using a credential-reference

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-14420?page=com.atlassian.jira.plugi... ] Paul Ferraro reassigned WFLY-14420: ----------------------------------- Assignee: Paul Ferraro > Automatic credential store update not triggered when enabling single-sign-on using a credential-reference > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-14420 > URL: https://issues.redhat.com/browse/WFLY-14420 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Farah Juma > Assignee: Paul Ferraro > Priority: Major > > When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps: > > {code:xml} > ### Pre-requisite steps > /subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true) > /subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain) > /subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS) > ### Enable single-sign-on > /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword}) > # At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code} > > This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered. > As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14420) Automatic credential store update not triggered when enabling single-sign-on using a credential-reference

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-14420?page=com.atlassian.jira.plugi... ] Paul Ferraro commented on WFLY-14420: ------------------------------------- [~fjuma] I'll have a look at this tomorrow. > Automatic credential store update not triggered when enabling single-sign-on using a credential-reference > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-14420 > URL: https://issues.redhat.com/browse/WFLY-14420 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Farah Juma > Priority: Major > > When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps: > > {code:xml} > ### Pre-requisite steps > /subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true) > /subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain) > /subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS) > ### Enable single-sign-on > /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword}) > # At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code} > > This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered. > As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2021