January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12941) , Count metrics in wildfly17 does not increase

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-12941?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-12941: ----------------------------------------- [~alireza.alallah] Can you be more specific? There are many different subsystems in WildFly that provide their own metrics so knowing which are a problem will help. Also, many subsystems have a 'statistics-enabled' configuration attribute with a default value of 'false'. (It's false by default because collection metrics has a perf impact so we want users to opt into it.) If that attribute is 'false' for a subsystem it may look like some metrics don't move from 0. > ,Count metrics in wildfly17 does not increase > --------------------------------------------- > > Key: WFLY-12941 > URL: https://issues.redhat.com/browse/WFLY-12941 > Project: WildFly > Issue Type: Bug > Reporter: alireza alallah > Assignee: Brian Stansberry > Priority: Major > > Count metrics in wildfly17 does not increase -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1084) kjar maven dependencies are downloaded even if scope is set to provided or test

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-1084?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-1084. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/70e5b2be5db1b610db41e2cecc9b0ea... > kjar maven dependencies are downloaded even if scope is set to provided or test > ------------------------------------------------------------------------------- > > Key: DROOLS-1084 > URL: https://issues.redhat.com/browse/DROOLS-1084 > Project: Drools > Issue Type: Bug > Affects Versions: 6.3.0.Final > Reporter: Lindsay Thurmond > Assignee: Mario Fusco > Priority: Major > Attachments: debug1.png, debug2.png, debug3.png > > > The creation of a new kbase triggers the specified rules kjar to be downloaded from the remote Maven repository. This works as expected but has the side effect of also downloading the Maven dependencies for the kjar. The problem is that it is downloading ALL the Maven dependencies even if they are specified as provided or test scope. This shouldn't happen since provided dependencies are expected to already be on the classpath and we should never need test dependencies at all during runtime at all. > I did some digging into the Drools source to and found out that > {{KieRepositoryImpl#getKieModule()}} > contains logic to check the classpath for the KieModule and if it can't find it to load everything from the Maven repo which includes downloading all the dependencies (and dependencies of dependencies and so on). > Unfortunately the code for checking the classpath is not actually implemented and looks like this: > {code} > private KieModule checkClasspathForKieModule(ReleaseId releaseId) { > // TODO > // ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); > // URL url = classLoader.getResource( ((ReleaseIdImpl)releaseId).getPomPropertiesPath() ); > return null; > } > {code} > After nothing is found on the classpath everything is downloaded from Maven. You can see all the stuff that is going to be downloaded (if it's not already in your Maven repo) in > {{DefaultProjectDependenciesResolver#resolve() //line 159}} > You can even see here that the dependencies have been marked as provided, but regardless they are going to be downloaded. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4794) Upgrade Elytron Web to 1.7.0.CR4

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFCORE-4794?page=com.atlassian.jira.plug... ] Farah Juma updated WFCORE-4794: ------------------------------- Fix Version/s: 11.0.0.Beta6 (was: 11.0.0.Beta7) > Upgrade Elytron Web to 1.7.0.CR4 > -------------------------------- > > Key: WFCORE-4794 > URL: https://issues.redhat.com/browse/WFCORE-4794 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 11.0.0.Beta6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4793) Upgrade WildFly Elytron to 1.11.0.CR5

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFCORE-4793?page=com.atlassian.jira.plug... ] Farah Juma updated WFCORE-4793: ------------------------------- Fix Version/s: 11.0.0.Beta6 (was: 11.0.0.Beta7) > Upgrade WildFly Elytron to 1.11.0.CR5 > ------------------------------------- > > Key: WFCORE-4793 > URL: https://issues.redhat.com/browse/WFCORE-4793 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 11.0.0.Beta6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3376) Modules may create loggers on a deployments log context

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-3376?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-3376: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Modules may create loggers on a deployments log context > ------------------------------------------------------- > > Key: WFCORE-3376 > URL: https://issues.redhat.com/browse/WFCORE-3376 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Fix For: 11.0.0.Beta7 > > > Currently WildFly uses a {{ClassLoaderLogContextSelector}} to determine the log context to use when creating loggers. If a deployment has it's own log context, via logging-profile or per-deployment logging, and a dependency on a module, that module may create loggers on the deployments log context. This is due to the fact the the call stack is walked until it finds a log context associated with a class loader. > What is needed is a way to short-circuit once a non-logging API class loader is found and determine if there is an associated log context with the callers class loader. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4482) Out of the box SSL with Wildfly Elytron

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4482?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4482: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Out of the box SSL with Wildfly Elytron > --------------------------------------- > > Key: WFCORE-4482 > URL: https://issues.redhat.com/browse/WFCORE-4482 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Labels: EAP-CD19 > Fix For: 11.0.0.Beta7 > > > The details of this RFE will be explored within the analysis, presently Undertow depends on a security-realm that generates a self signed cert on start up so we will require an Elytron equivalent. > There may be opportunities to tie this in in some way with the new CA integration support but that can be explored in the analysis. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-944?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-944: ------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > truststore path is ignored if provider is not JKS > ------------------------------------------------- > > Key: WFCORE-944 > URL: https://issues.redhat.com/browse/WFCORE-944 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Arto Huusko > Priority: Major > Fix For: 11.0.0.Beta7 > > > truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS. > This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working. > We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured. > Even standard java supports PKCS12 truststores, where the same problem would occur. > So I would suggest that > - if provider is JKS, path is mandatory > - if provider is not JKS, but path is specified, it is passed to the provider -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4485) Support for multiple security realms - Distributed Identities

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4485?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4485: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Support for multiple security realms - Distributed Identities > ------------------------------------------------------------- > > Key: WFCORE-4485 > URL: https://issues.redhat.com/browse/WFCORE-4485 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Priority: Major > Labels: CD17-Deferred, EAP-CD19, Previous_RFE > Fix For: 11.0.0.Beta7 > > > By stacking LoginModules it was possible using PicketBox to attempt to authenticate using one remote store and if that failed try the next store in the list. > This RFE is to consider the use case where identities could be located across multiple stores and how they are aggregated together. > Additionally this use case should consider how the authorization information could be loaded from multiple sources and merged. > This RFE is not about fail over in the event of a realm being unavailable although it may be related. > This RFE is created as a result of comparing the differences between the PicketBox JAAS architecture and the Elytron architecture so I would not recommend this proceeds without some real world use cases identified. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4670) Upgrade JBoss MSC to 1.4.12.Final

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4670?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4670: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Upgrade JBoss MSC to 1.4.12.Final > --------------------------------- > > Key: WFCORE-4670 > URL: https://issues.redhat.com/browse/WFCORE-4670 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Reporter: Katarina Hermanova > Assignee: Richard Opalka > Priority: Major > Fix For: 11.0.0.Beta7 > > -- 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 Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4791?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4791: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > 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.Beta7 > > 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

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