January 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFLY-14337) Upgrade wildfly-naming-client to 1.0.14.Final

by Tomas Hofman (Jira)

[ https://issues.redhat.com/browse/WFLY-14337?page=com.atlassian.jira.plugi... ] Tomas Hofman updated WFLY-14337: -------------------------------- Fix Version/s: (was: 20.0.0.Final) > Upgrade wildfly-naming-client to 1.0.14.Final > --------------------------------------------- > > Key: WFLY-14337 > URL: https://issues.redhat.com/browse/WFLY-14337 > Project: WildFly > Issue Type: Component Upgrade > Components: Naming > Reporter: Tomas Hofman > Assignee: Brian Stansberry > Priority: Major > Labels: downstream_dependency > > https://github.com/wildfly/wildfly-naming-client/compare/1.0.13.Final...1... -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14337) Upgrade wildfly-naming-client to 1.0.14.Final

by Tomas Hofman (Jira)

[ https://issues.redhat.com/browse/WFLY-14337?page=com.atlassian.jira.plugi... ] Tomas Hofman updated WFLY-14337: -------------------------------- Description: https://github.com/wildfly/wildfly-naming-client/compare/1.0.13.Final...1... (was: Pick up https://issues.redhat.com/browse/WFNC-57 https://github.com/wildfly/wildfly-naming-client/compare/1.0.12.Final...1...) > Upgrade wildfly-naming-client to 1.0.14.Final > --------------------------------------------- > > Key: WFLY-14337 > URL: https://issues.redhat.com/browse/WFLY-14337 > Project: WildFly > Issue Type: Component Upgrade > Components: Naming > Reporter: Tomas Hofman > Assignee: Brian Stansberry > Priority: Major > Labels: downstream_dependency > Fix For: 20.0.0.Final > > > https://github.com/wildfly/wildfly-naming-client/compare/1.0.13.Final...1... -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14337) Upgrade wildfly-naming-client to 1.0.14.Final

by Tomas Hofman (Jira)

Tomas Hofman created WFLY-14337: ----------------------------------- Summary: Upgrade wildfly-naming-client to 1.0.14.Final Key: WFLY-14337 URL: https://issues.redhat.com/browse/WFLY-14337 Project: WildFly Issue Type: Component Upgrade Components: Naming Reporter: Tomas Hofman Assignee: Brian Stansberry Fix For: 20.0.0.Final Pick up https://issues.redhat.com/browse/WFNC-57 https://github.com/wildfly/wildfly-naming-client/compare/1.0.12.Final...1... -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14336) Upgrade Apache Artemis to 2.17

by Tomas Hofman (Jira)

[ https://issues.redhat.com/browse/WFLY-14336?page=com.atlassian.jira.plugi... ] Tomas Hofman updated WFLY-14336: -------------------------------- Summary: Upgrade Apache Artemis to 2.17 (was: Upgrade Apache Artemis to 2.16.1) > Upgrade Apache Artemis to 2.17 > ------------------------------ > > Key: WFLY-14336 > URL: https://issues.redhat.com/browse/WFLY-14336 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Tomas Hofman > Assignee: Emmanuel Hugonnet > Priority: Major > Labels: downstream_dependency > Fix For: 22.0.0.Beta1, 22.0.0.Final > > > Upgrade apache Artemis to 2.16.0 -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5251) Upgrade Undertow to 2.2.4.Final

by Tomas Hofman (Jira)

[ https://issues.redhat.com/browse/WFCORE-5251?page=com.atlassian.jira.plug... ] Tomas Hofman updated WFCORE-5251: --------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly-core/pull/4422) > Upgrade Undertow to 2.2.4.Final > ------------------------------- > > Key: WFCORE-5251 > URL: https://issues.redhat.com/browse/WFCORE-5251 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Tomas Hofman > Assignee: Flavia Rainone > Priority: Major > Labels: downstream_dependency > Fix For: 14.0.0.Beta4, 14.0.0.Final > > > [2.2.2.Final vs. 2.2.3.Final diff|https://github.com/undertow-io/undertow/compare/2.2.2.Final...2.2.3....] -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5251) Upgrade Undertow to 2.2.4.Final

by Tomas Hofman (Jira)

[ https://issues.redhat.com/browse/WFCORE-5251?page=com.atlassian.jira.plug... ] Tomas Hofman updated WFCORE-5251: --------------------------------- Description: [2.2.3.Final vs. 2.2.4.Final diff|https://github.com/undertow-io/undertow/compare/2.2.3.Final...2.2.4....] (was: [2.2.2.Final vs. 2.2.3.Final diff|https://github.com/undertow-io/undertow/compare/2.2.2.Final...2.2.3....]) > Upgrade Undertow to 2.2.4.Final > ------------------------------- > > Key: WFCORE-5251 > URL: https://issues.redhat.com/browse/WFCORE-5251 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Tomas Hofman > Assignee: Flavia Rainone > Priority: Major > Labels: downstream_dependency > > [2.2.3.Final vs. 2.2.4.Final diff|https://github.com/undertow-io/undertow/compare/2.2.3.Final...2.2.4....] -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5251) Upgrade Undertow to 2.2.4.Final

by Tomas Hofman (Jira)

[ https://issues.redhat.com/browse/WFCORE-5251?page=com.atlassian.jira.plug... ] Tomas Hofman updated WFCORE-5251: --------------------------------- Fix Version/s: (was: 14.0.0.Beta4) (was: 14.0.0.Final) > Upgrade Undertow to 2.2.4.Final > ------------------------------- > > Key: WFCORE-5251 > URL: https://issues.redhat.com/browse/WFCORE-5251 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Tomas Hofman > Assignee: Flavia Rainone > Priority: Major > Labels: downstream_dependency > > [2.2.2.Final vs. 2.2.3.Final diff|https://github.com/undertow-io/undertow/compare/2.2.2.Final...2.2.3....] -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5251) Upgrade Undertow to 2.2.4.Final

by Tomas Hofman (Jira)

Tomas Hofman created WFCORE-5251: ------------------------------------ Summary: Upgrade Undertow to 2.2.4.Final Key: WFCORE-5251 URL: https://issues.redhat.com/browse/WFCORE-5251 Project: WildFly Core Issue Type: Component Upgrade Reporter: Tomas Hofman Assignee: Flavia Rainone Fix For: 14.0.0.Beta4, 14.0.0.Final [2.2.2.Final vs. 2.2.3.Final diff|https://github.com/undertow-io/undertow/compare/2.2.2.Final...2.2.3....] -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

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

by Adriano Teixeira de Souza (Jira)

[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ] Adriano Teixeira de Souza edited comment on WFLY-14284 at 1/22/21 8:24 AM: --------------------------------------------------------------------------- Hi [~ochaloup] The $local authentication is not disabled according to what I can see. If it's this. {code:java} <security-realms> <security-realm name="ManagementRealm"> <server-identities> <secret value="YWRtaW5AYWxmYQo="/> </server-identities> <authentication> <local default-user="$local" skip-group-loading="true"/> <properties path="mgmt-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> <authorization map-groups-to-roles="false"> <properties path="mgmt-groups.properties" relative-to="jboss.domain.config.dir"/> </authorization> </security-realm> <security-realm name="ApplicationRealm"> <server-identities> <ssl> <keystore path="application.keystore" relative-to="jboss.domain.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/> </ssl> </server-identities> <authentication> <local default-user="$local" allowed-users="*" skip-group-loading="true"/> <properties path="application-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> <authorization> <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/> </authorization> </security-realm> <security-realm name="remote-ejb-security-realm"> <server-identities> <secret value="ZWpi"/> </server-identities> </security-realm> </security-realms> {code} Our lookup in almost of case is like this {code:java} Properties props = new Properties(); props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); Context context = new InitialContext(props); StringBuilder jndiName = new StringBuilder(); jndiName.append("ejb:"); jndiName.append(module.getApplicationName()); jndiName.append("/"); jndiName.append(module.getModuleName()); jndiName.append("/"); jndiName.append(ejbName); jndiName.append("!"); jndiName.append(intefaceName); Object bean = context.lookup(jndiName.toString()); {code} I'll configure to remote+http instead of http-remoting (it commes from Wildfly 10 configuration) and -Dwildfly.config.url with wildfly-config.xml and I will observe the server logs and behavior on the stoping operations On error scenario we have a wildfly domain with our applications and four servers working behind a haproxy load balance I'll set jboss.tx.node.id on server instances in order to get a better scenario too. Some information about your point: 1 - We are a software development providing to many companies and we are configuring ejb as remote call because we have three modules that can be deployed together on the same instance or on different instance according to our client needs. It's just by convenience. 2 - On this scenario we don't using @EJB or java:app with local lookup because we have a large software ecosystem and we need to normalize all development activities to a standard ways (in this case using Context lookup) in order to get more easy and flexible development activities and get more predictable thing to solve problems. There are many places we are using local lookup but in this case is where are sure there is no remote call. 3 - Becouse our company directives we don't use nom specification annotation like @ClientTransaction I'll bring some more information about our tests after do it. By the time I say thanks was (Author: JIRAUSER147207): Hi [~ochaloup] The $local authentication is not disabled according to what I can see. If it's this. {code:java} <security-realms> <security-realm name="ManagementRealm"> <server-identities> <secret value="YWRtaW5AYWxmYQo="/> </server-identities> <authentication> <local default-user="$local" skip-group-loading="true"/> <properties path="mgmt-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> <authorization map-groups-to-roles="false"> <properties path="mgmt-groups.properties" relative-to="jboss.domain.config.dir"/> </authorization> </security-realm> <security-realm name="ApplicationRealm"> <server-identities> <ssl> <keystore path="application.keystore" relative-to="jboss.domain.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/> </ssl> </server-identities> <authentication> <local default-user="$local" allowed-users="*" skip-group-loading="true"/> <properties path="application-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> <authorization> <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/> </authorization> </security-realm> <security-realm name="remote-ejb-security-realm"> <server-identities> <secret value="ZWpi"/> </server-identities> </security-realm> </security-realms> {code} I'll configure to remote+http instead of http-remoting (it commes from Wildfly 10 configuration) and -Dwildfly.config.url with wildfly-config.xml and I will observe the server logs and behavior on the stoping operations On error scenario we have a wildfly domain with our applications and four servers working behind a haproxy load balance I'll set jboss.tx.node.id on server instances in order to get a better scenario too. Some information about your point: 1 - We are a software development providing to many companies and we are configuring ejb as remote call because we have three modules that can be deployed together on the same instance or on different instance according to our client needs. It's just by convenience. 2 - On this scenario we don't using @EJB or java:app with local lookup because we have a large software ecosystem and we need to normalize all development activities to a standard ways (in this case using Context lookup) in order to get more easy and flexible development activities and get more predictable thing to solve problems. There are many places we are using local lookup but in this case is where are sure there is no remote call. 3 - Becouse our company directives we don't use nom specification annotation like @ClientTransaction I'll bring some more information about our tests after do it. By the time I say thanks > 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)

5 years, 2 months

1
0
0 / 0

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

by Adriano Teixeira de Souza (Jira)

[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ] Adriano Teixeira de Souza commented on WFLY-14284: -------------------------------------------------- Hi [~ochaloup] The $local authentication is not disabled according to what I can see. If it's this. {code:java} <security-realms> <security-realm name="ManagementRealm"> <server-identities> <secret value="YWRtaW5AYWxmYQo="/> </server-identities> <authentication> <local default-user="$local" skip-group-loading="true"/> <properties path="mgmt-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> <authorization map-groups-to-roles="false"> <properties path="mgmt-groups.properties" relative-to="jboss.domain.config.dir"/> </authorization> </security-realm> <security-realm name="ApplicationRealm"> <server-identities> <ssl> <keystore path="application.keystore" relative-to="jboss.domain.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/> </ssl> </server-identities> <authentication> <local default-user="$local" allowed-users="*" skip-group-loading="true"/> <properties path="application-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> <authorization> <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/> </authorization> </security-realm> <security-realm name="remote-ejb-security-realm"> <server-identities> <secret value="ZWpi"/> </server-identities> </security-realm> </security-realms> {code} I'll configure to remote+http instead of http-remoting (it commes from Wildfly 10 configuration) and -Dwildfly.config.url with wildfly-config.xml and I will observe the server logs and behavior on the stoping operations On error scenario we have a wildfly domain with our applications and four servers working behind a haproxy load balance I'll set jboss.tx.node.id on server instances in order to get a better scenario too. Some information about your point: 1 - We are a software development providing to many companies and we are configuring ejb as remote call because we have three modules that can be deployed together on the same instance or on different instance according to our client needs. It's just by convenience. 2 - On this scenario we don't using @EJB or java:app with local lookup because we have a large software ecosystem and we need to normalize all development activities to a standard ways (in this case using Context lookup) in order to get more easy and flexible development activities and get more predictable thing to solve problems. There are many places we are using local lookup but in this case is where are sure there is no remote call. 3 - Becouse our company directives we don't use nom specification annotation like @ClientTransaction I'll bring some more information about our tests after do it. By the time I say thanks > 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)

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 January 2021