January 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (ELY-2073) Upgrade org.apache.directory.api to version 2.0.1

by Sonia Zaldana (Jira)

Sonia Zaldana created ELY-2073: ---------------------------------- Summary: Upgrade org.apache.directory.api to version 2.0.1 Key: ELY-2073 URL: https://issues.redhat.com/browse/ELY-2073 Project: WildFly Elytron Issue Type: Bug Reporter: Sonia Zaldana Assignee: Darran Lofthouse -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2071) Upgrade Apache DS to version AM26

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/ELY-2071?page=com.atlassian.jira.plugin.... ] Sonia Zaldana updated ELY-2071: ------------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/1482 > Upgrade Apache DS to version AM26 > --------------------------------- > > Key: ELY-2071 > URL: https://issues.redhat.com/browse/ELY-2071 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Sonia Zaldana > Assignee: Sonia Zaldana > Priority: Major > > We are currently using version M24. We should upgrade to version AM26. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2072) Release WildFly Elytron 1.10.11.Final

by Farah Juma (Jira)

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

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ] Ondrej Chaloupka commented on WFLY-14284: ----------------------------------------- hi [~adrianots]. I checked the behaviour of the {{http-remoting}} with [~tomekadamski] and he considers it as an issue. I created a jira for it: https://issues.redhat.com/browse/WEJBHTTP-53 To your questions ad 1. yes, agree. With use of {{remote+http}} the container should not be stopped hanging endlessly. ad 2. that depends on your application and I would really **not** recommend it as a generic rule of thumb. The heuristic error means there was some unexpected error in the transaction processing (ie. 2PC protocol can't proceed in deterministic way). The reason should be verified first and then you can proceed with the deletion. You may take a look e.g. on guidance at https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... , something about troubleshooting here https://docs.wildfly.org/19.1/Developer_Guide.html#in-ejbs ad 3. it depends on configuration but I assume it should be possible. E.g. if the app works that the connection is opened, be directed to one of the server, is established and retained until finished then the ejb client recovery will point to that particular server and recovery will probably not be touching the loadbalancer. From transaction perspective is important that the server behind the loadbalancer keeps the ip and the transaction log. But I'm not able to say how exactly this works in your environment. ad 4. Here I'm really not sure. In general every next WFLY release should contain fixes on top of the previous one. It's a generic question which may depend on your workload. I would suggest to place this type of question at https://groups.google.com/g/wildfly. > WildFly doesn't stop while waiting for PeriodicRecovery > ------------------------------------------------------- > > Key: WFLY-14284 > URL: https://issues.redhat.com/browse/WFLY-14284 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Affects Versions: 18.0.1.Final, 20.0.1.Final > Reporter: Adriano Teixeira de Souza > Assignee: Michael Musgrove > Priority: Major > Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt > > > I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10. > it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS. > It sounds like a dead look. > I attatch the thread dump on this. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5911) It's not possible to save arrow edits on DMN Editor

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5911?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-5911: -------------------------------- Tester: Jozef Marko > It's not possible to save arrow edits on DMN Editor > --------------------------------------------------- > > Key: DROOLS-5911 > URL: https://issues.redhat.com/browse/DROOLS-5911 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.48.0.Final > Reporter: Wagner Lemos > Assignee: Wagner Lemos > Priority: Major > Labels: Stunner, kogito, kogito-tooling > > On the DMN Editor, making a change on the arrow that connects two nodes isn't being saved. An example of change is moving the rear or tip of the arrow to another side of the node -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2072) Release WildFly Elytron 1.10.11.Final

by Farah Juma (Jira)

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

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (ELY-1976) Elytron provider not being used with credential store and SASL authentication on the Client Side

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1976?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1976: ---------------------------- Fix Version/s: 1.10.11.Final > Elytron provider not being used with credential store and SASL authentication on the Client Side > ------------------------------------------------------------------------------------------------ > > Key: ELY-1976 > URL: https://issues.redhat.com/browse/ELY-1976 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Sonia Zaldana > Assignee: Sonia Zaldana > Priority: Major > Fix For: 1.10.11.Final, 1.13.0.CR1 > > > Trying to configure an ejb client with Sasl authentication using a credential store causes an "Invalid algorithm clear" error as follows: > {code:java} > Suppressed: javax.security.sasl.SaslException: ELY05053: Callback handler failed for unknown reason [Caused by java.io.IOException: ELY01030: Unable to read credential] > at org.wildfly.security.mechanism._private.MechanismUtil.handleCallbacks(MechanismUtil.java:160) > at org.wildfly.security.mechanism._private.MechanismUtil.getPasswordCredential(MechanismUtil.java:102) > at org.wildfly.security.mechanism.scram.ScramClient.handleInitialChallenge(ScramClient.java:245) > at org.wildfly.security.sasl.scram.ScramSaslClient.evaluateMessage(ScramSaslClient.java:75) > at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:219) > at org.wildfly.security.sasl.util.AbstractSaslClient.evaluateChallenge(AbstractSaslClient.java:98) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54) > at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.lambda$handleEvent$0(ClientConnectionOpenListener.java:649) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.io.IOException: ELY01030: Unable to read credential > at org.wildfly.security.credential.source.impl.CredentialStoreCredentialSource.getCredential(CredentialStoreCredentialSource.java:92) > at org.wildfly.security.credential.source.CredentialSource$1.getCredential(CredentialSource.java:207) > at org.wildfly.security.auth.client.AuthenticationConfiguration$ClientCallbackHandler.handle(AuthenticationConfiguration.java:1841) > at org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory$ClientPrincipalQueryCallbackHandler.handle(LocalPrincipalSaslClientFactory.java:93) > at org.wildfly.security.mechanism._private.MechanismUtil.handleCallbacks(MechanismUtil.java:156) > ... 16 more > Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:683) > at org.wildfly.security.credential.store.CredentialStore.retrieve(CredentialStore.java:303) > at org.wildfly.security.credential.store.CredentialStore.retrieve(CredentialStore.java:287) > at org.wildfly.security.credential.source.impl.CredentialStoreCredentialSource.getCredential(CredentialStoreCredentialSource.java:88) > ... 20 more > Caused by: java.security.NoSuchAlgorithmException: ELY08028: Invalid algorithm "clear" > at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:122) > at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:76) > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:679) > ... 23 more > {code} > Here is my wildfly-config.xml where the credential-store-reference has been configured. > {code:java} > <configuration> > <authentication-client xmlns="urn:elytron:client:1.5"> > <credential-stores> > <credential-store name="mycredstore"> > <attributes> > <attribute name="keyStoreType" value="JCEKS"/> > <attribute name="location" value="/home/szcalles/Wildfly/wildfly/build/target/wildfly-20.0.0.Final-SNAPSHOT/standalone/configuration/mycredstore.cs"></attribute> > </attributes> > <protection-parameter-credentials> > <clear-password password="StorePassword"/> > </protection-parameter-credentials> > </credential-store> > </credential-stores> > <authentication-rules> > <rule use-configuration="default-config"/> > </authentication-rules> > <authentication-configurations> > <configuration name="default-config"> > <set-user-name name="quickstartUser"/> > <credentials> > <credential-store-reference store="mycredstore" alias="quickstartUser"/> > </credentials> > <sasl-mechanism-selector selector="SCRAM-SHA-512"/> > <providers> > <use-service-loader /> > </providers> > </configuration> > </authentication-configurations> > </authentication-client> > </configuration> > {code} > The provider configuration in wildfly-config.xml is specified correctly: > {code:java} > <providers> > <use-service-loader /> > </providers> > {code} > The problem seems to be in PasswordFactory.getInstance() in KeyStoreCredentialStore where we aren't setting the providers we have configured. Instead, it seems to use INSTALLED_PROVIDERS which does not have the Elytron providers. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2072) Release WildFly Elytron 1.10.11.Final

by Farah Juma (Jira)

Farah Juma created ELY-2072: ------------------------------- Summary: Release WildFly Elytron 1.10.11.Final Key: ELY-2072 URL: https://issues.redhat.com/browse/ELY-2072 Project: WildFly Elytron Issue Type: Release Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (SWSQE-1260) Run Istio Tests on OpenShift

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1260?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1260: ---------------------------------- Sprint: Kiali Sprint #51, Kiali Sprint #52 (was: Kiali Sprint #51) > Run Istio Tests on OpenShift > ---------------------------- > > Key: SWSQE-1260 > URL: https://issues.redhat.com/browse/SWSQE-1260 > Project: Kiali QE > Issue Type: Story > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (SWSQE-1235) How to colaborate better between teams

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1235?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1235: ---------------------------------- Sprint: Kiali Sprint #47, Kiali Sprint #48, Kiali Sprint #49, Kiali Sprint #50, Kiali Sprint #51, Kiali Sprint #52 (was: Kiali Sprint #47, Kiali Sprint #48, Kiali Sprint #49, Kiali Sprint #50, Kiali Sprint #51) > How to colaborate better between teams > -------------------------------------- > > Key: SWSQE-1235 > URL: https://issues.redhat.com/browse/SWSQE-1235 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Minor > Labels: infrastructure > > We would like to share tasks between teams better. > e.g. infra tasks with Leonardo > Also common jenkins libs would be a good idea. > etc. > We should also take a look at https://gitlab.sat.engineering.redhat.com/rhprod/rhprod-jenkins-library -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2021