December 2020 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (ELY-2045) Widespread test failures on Fedora 33 with Fedora distribution of OpenJDK 11

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-2045?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-2045: ---------------------------------- Fix Version/s: 1.14.0.CR1 (was: 1.13.3.CR1) > Widespread test failures on Fedora 33 with Fedora distribution of OpenJDK 11 > ---------------------------------------------------------------------------- > > Key: ELY-2045 > URL: https://issues.redhat.com/browse/ELY-2045 > Project: WildFly Elytron > Issue Type: Bug > Components: Testsuite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.10.11.CR1, 1.14.0.CR1, 2.0.0.Alpha10 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2042) ElytronXMLParser is not configuring maximum-cert-path in X509RevocationTrustManager

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-2042?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved ELY-2042. ----------------------------------- Fix Version/s: 1.14.0.CR1 Resolution: Done > ElytronXMLParser is not configuring maximum-cert-path in X509RevocationTrustManager > ----------------------------------------------------------------------------------- > > Key: ELY-2042 > URL: https://issues.redhat.com/browse/ELY-2042 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Sonia Zaldana > Assignee: Sonia Zaldana > Priority: Major > Fix For: 1.14.0.CR1 > > > The ElytronXMLParser is parsing the maximum-cert-path attribute corresponding to a trust-manager resource, but it is not propagating that value to the X509RevocationTrustManager. As a result, a trust manager configured on the client side always has the default value of 5. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5208) Upgrade WildFly OpenSSL to 2.1.2.Final

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-5208: ---------------------------------------- Summary: Upgrade WildFly OpenSSL to 2.1.2.Final Key: WFCORE-5208 URL: https://issues.redhat.com/browse/WFCORE-5208 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 14.0.0.Beta3 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14160) Logging documentation needs attention and updates

by James Perkins (Jira)

James Perkins created WFLY-14160: ------------------------------------ Summary: Logging documentation needs attention and updates Key: WFLY-14160 URL: https://issues.redhat.com/browse/WFLY-14160 Project: WildFly Issue Type: Task Components: Documentation, Logging Reporter: James Perkins Assignee: James Perkins While working on an RFE that required some documentation I noticed there are several broken links in the logging documentation. While it would be simple to just fix the links I feel the logging documentation needs an overhaul and should be updated in general. For this reason I've created this issue as critical. h2. Links Several links that referred to inner-documentation links were broken long ago in the conversion to asciidoc. These need to be fixed. An example is the implicit dependencies link needs to be: {code} link:Developer_Guide.html#which-are-the-implicit-module-dependencies[implicit] {code} h2. Logging API's The logging API's should have some information on how they work. Possibly which implementation is used and if the user wants to use their own implementation which module dependencies need to be excluded. In some cases too, log4j2 is an example, there could special permissions required if a security manager is enabled. For log4j2 these are the required permissions: {code} // The getClassLoader permissions is required for the org.apache.logging.log4j.util.ProviderUtil. new RuntimePermission("getClassLoader"), // The FilePermissions is also for the org.apache.logging.log4j.util.ProviderUtil as it needs to read the JAR // for the service loader. new FilePermission("<<ALL FILES>>", "read"), // Required for the EnvironmentPropertySource System.getenv(). new RuntimePermission("getenv.*"), // Required for the SystemPropertiesPropertySource System.getProperties(). new PropertyPermission("*", "read,write"), {code} h2. How To's The How To section likely doesn't make much sense. This same documentation could be achieved in each logging API section. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14009) Download log file from Widfly Console forbidden with Keycloak setup

by Michal Petrov (Jira)

[ https://issues.redhat.com/browse/WFLY-14009?page=com.atlassian.jira.plugi... ] Michal Petrov reassigned WFLY-14009: ------------------------------------ Assignee: Michal Petrov (was: Harald Pehl) > Download log file from Widfly Console forbidden with Keycloak setup > ------------------------------------------------------------------- > > Key: WFLY-14009 > URL: https://issues.redhat.com/browse/WFLY-14009 > Project: WildFly > Issue Type: Bug > Components: Management, Web Console > Affects Versions: 17.0.1.Final > Reporter: Claudio Weiler > Assignee: Michal Petrov > Priority: Major > > We have a WildFly instance setup with KeyCloak protecting console/management interface. > > In menu 'Runtime > Log files' there is 2 places to download those. In context menu of the log entry or in toolbar of log entry viewer. > > Both options can't download log file because no bearer token is send in request. Download request is a simple link html tag like this one: > {code:java} > <a data-element="download" href="https://server.none.com/management/subsystem/logging/log-file/server.log?..." class="btn btn-default clickable" data-toggle="tooltip" data-container="body" data-placement="top" data-animation="false" title="" data-original-title="Download" download="server.log"><i class="fa fa-download"></i></a>{code} > > > Keycloak steps: https://docs.jboss.org/author/display/WFLY/Protecting%20Wildfly%20Adminst... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14159) Download log file from Widfly Console forbidden with Keycloak setup

by Michal Petrov (Jira)

Michal Petrov created WFLY-14159: ------------------------------------ Summary: Download log file from Widfly Console forbidden with Keycloak setup Key: WFLY-14159 URL: https://issues.redhat.com/browse/WFLY-14159 Project: WildFly Issue Type: Bug Components: Management, Web Console Affects Versions: 17.0.1.Final Reporter: Michal Petrov Assignee: Michal Petrov We have a WildFly instance setup with KeyCloak protecting console/management interface. In menu 'Runtime > Log files' there is 2 places to download those. In context menu of the log entry or in toolbar of log entry viewer. Both options can't download log file because no bearer token is send in request. Download request is a simple link html tag like this one: {code:java} <a data-element="download" href="https://server.none.com/management/subsystem/logging/log-file/server.log?..." class="btn btn-default clickable" data-toggle="tooltip" data-container="body" data-placement="top" data-animation="false" title="" data-original-title="Download" download="server.log"><i class="fa fa-download"></i></a>{code} Keycloak steps: https://docs.jboss.org/author/display/WFLY/Protecting%20Wildfly%20Adminst... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5172) Upgrade WildFly Elytron

by Lin Gao (Jira)

[ https://issues.redhat.com/browse/WFCORE-5172?page=com.atlassian.jira.plug... ] Lin Gao closed WFCORE-5172. --------------------------- Resolution: Duplicate Issue duplicated with WFCORE-5197, closed > Upgrade WildFly Elytron > ----------------------- > > Key: WFCORE-5172 > URL: https://issues.redhat.com/browse/WFCORE-5172 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Lin Gao > Assignee: Darran Lofthouse > Priority: Major > Labels: downstream_dependency > > [https://github.com/wildfly-security/wildfly-elytron/compare/1.13.1.Final....] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14142) Update Google guava to 30.0-jre

by Boris Unckel (Jira)

[ https://issues.redhat.com/browse/WFLY-14142?page=com.atlassian.jira.plugi... ] Boris Unckel updated WFLY-14142: -------------------------------- Attachment: 2020-12-01_04after_guava_build.txt > Update Google guava to 30.0-jre > ------------------------------- > > Key: WFLY-14142 > URL: https://issues.redhat.com/browse/WFLY-14142 > Project: WildFly > Issue Type: Component Upgrade > Components: Batch, JMS > Reporter: Boris Unckel > Assignee: Cheng Fang > Priority: Major > Attachments: 2020-12-01_04after_guava_build.txt > > > Update Google guava to [30.0-jre|https://mvnrepository.com/artifact/com.google.guava/guava/30.0-jre]. Exclude all dependencies but [failureaccess 1.0.1|https://mvnrepository.com/artifact/com.google.guava/failureaccess/1...] according to [Google Guava Important Warnings #3|https://github.com/google/guava]. > [Release Notes|https://github.com/google/guava/releases/tag/v30.0] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14114) Class loader leaks when JDBC driver as jar deployment is undeloyed

by Lin Gao (Jira)

[ https://issues.redhat.com/browse/WFLY-14114?page=com.atlassian.jira.plugi... ] Lin Gao updated WFLY-14114: --------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13752 > Class loader leaks when JDBC driver as jar deployment is undeloyed > ------------------------------------------------------------------ > > Key: WFLY-14114 > URL: https://issues.redhat.com/browse/WFLY-14114 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Lin Gao > Assignee: Tomasz Adamski > Priority: Major > Labels: downstream_dependency > > Class loader leaks when JDBC driver as jar deployment is undeloyed. It will eventually leads to Metaspace out of memory error when "-XX:MaxMetaspaceSize" option is specified. > > Normally JDBC driver is not undeloyed or redeployed by user frequently, but configuration reload command, which is regularly used, also triggers JDBC driver redeployment and cause class loader leak. > JDBC driver should be deregistered while undeloying. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14132) jboss-ejb3.xml is ignored for exploded deployments

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-14132?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-14132: ----------------------------------------- [~cfang] I think [~jgmeligmeyling] is correct. The DeploymentUnit.getName() method returns the official 'runtime-name' for the deployment. For a top level deployment that attribute can be set by the user via the management API when the deployment is added and its value should be used when making decisions like this. That runtime name must include the relevant file extension. (For a subdeployment we internally set the DeploymentUnit name, and there it will be the name of the VirtualFile representing the subdeployment root, which must have the extension. This means DeploymentUnit.getName() works for subdeployments too.) The EjbJarParsingDeploymentUnitProcessor.isWar method should also use DeploymentUnit.getName(). > jboss-ejb3.xml is ignored for exploded deployments > -------------------------------------------------- > > Key: WFLY-14132 > URL: https://issues.redhat.com/browse/WFLY-14132 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 14.0.1.Final, JBoss AS7 7.1.1.Final, 21.0.1.Final > Reporter: Jan-Willem Gmelig Meyling > Assignee: Cheng Fang > Priority: Major > Labels: ejb-jar.xml, jboss-ejb3.xml > > {{EjbJarParsingDeploymentUnitProcessor}} distinguishes between a WAR and JAR deployment based on the file extension of the name of the deployment root. For exploded deployments however, this deployment root may be a folder without any file extension. As a result the logic fails to detect either a JAR or WAR file and the {{ejb-jar.xml}} and {{jboss-ejb3.xml}} files are ignored. A better way could be to determine the extension from the name of {{DeploymentUnit}} instead. > Code from: [https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...] > {code:java} > private static VirtualFile getDescriptor(final VirtualFile deploymentRoot, final String descriptorName) { > // Locate the descriptor > final VirtualFile descriptor; > // EJB 3.1 FR 20.4 Enterprise Beans Packaged in a .war > if (isWar(deploymentRoot)) { > // it's a .war file, so look for the ejb-jar.xml in WEB-INF > descriptor = deploymentRoot.getChild(WEB_INF + "/" + descriptorName); > } else if (deploymentRoot.getName().toLowerCase(Locale.ENGLISH).endsWith(JAR_FILE_EXTENSION)) { > descriptor = deploymentRoot.getChild(META_INF + "/" + descriptorName); > } else { > // neither a .jar nor a .war. Return > return null; > } > if (descriptor == null || !descriptor.exists()) { > // no descriptor found, nothing to do! > return null; > } > return descriptor; > } > {code} > > I encountered this issue on WildFly 14.0.1.Final, but the code is also present in the current master and goes back to versions as early as 7.1. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 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 December 2020