September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-5118) Cannot get resources from ContextClassLoader with Server Lifecycle Events

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/WFCORE-5118?page=com.atlassian.jira.plug... ] Ricardo Martin Camarero updated WFCORE-5118: -------------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/4320 (was: https://github.com/keycloak/keycloak/pull/7396) > Cannot get resources from ContextClassLoader with Server Lifecycle Events > ------------------------------------------------------------------------- > > Key: WFCORE-5118 > URL: https://issues.redhat.com/browse/WFCORE-5118 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 13.0.0.Beta5 > Reporter: Ricardo Martin Camarero > Assignee: Ricardo Martin Camarero > Priority: Major > Attachments: reproduce.zip > > > Listener application cannot refer to their own resources from ContextClassLoader. In general the TCCL is not assigned to the module of the {{ProcessStateListener}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined with JDK8 now

by Jan Stourac (Jira)

[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ] Jan Stourac commented on WFWIP-339: ----------------------------------- [~fjuma], I missed your comment here. JFYI - I have marked EAP7-1414 as prechecked already and added some results from my basic performance tests of the feature. They don't fulfill our original expectations though. > OpenSSL security provider seems to be used when not defined with JDK8 now > ------------------------------------------------------------------------- > > Key: WFWIP-339 > URL: https://issues.redhat.com/browse/WFWIP-339 > Project: WildFly WIP > Issue Type: Bug > Components: Security > Reporter: Jan Stourac > Assignee: Farah Juma > Priority: Major > Attachments: client.jks, server.jks, standalone-full.xml > > > It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. I also see this change of behavior only with JDK8. JDK11 works as expected! > Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: > {quote} > 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 > {quote} > This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8: > {code} > <server-ssl-contexts> > <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/> > </server-ssl-contexts> > <client-ssl-contexts> > <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/> > </client-ssl-contexts> > {code} > There are two questions from this: > # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected? > # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Not to mention that we don't want to behave differently for JDK8 and JDK11. > Hope I don't have any misconfiguration in the configuration itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined with JDK8 now

by Jan Stourac (Jira)

[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ] Jan Stourac edited comment on WFWIP-339 at 9/7/20 8:03 AM: ----------------------------------------------------------- [~fjuma], I missed your comment here. JFYI - I have marked EAP7-1414 as pre-checked already and added some results from my basic performance tests of the feature. They don't fulfill our original expectations though. was (Author: jstourac): [~fjuma], I missed your comment here. JFYI - I have marked EAP7-1414 as prechecked already and added some results from my basic performance tests of the feature. They don't fulfill our original expectations though. > OpenSSL security provider seems to be used when not defined with JDK8 now > ------------------------------------------------------------------------- > > Key: WFWIP-339 > URL: https://issues.redhat.com/browse/WFWIP-339 > Project: WildFly WIP > Issue Type: Bug > Components: Security > Reporter: Jan Stourac > Assignee: Farah Juma > Priority: Major > Attachments: client.jks, server.jks, standalone-full.xml > > > It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. I also see this change of behavior only with JDK8. JDK11 works as expected! > Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: > {quote} > 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 > {quote} > This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8: > {code} > <server-ssl-contexts> > <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/> > </server-ssl-contexts> > <client-ssl-contexts> > <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/> > </client-ssl-contexts> > {code} > There are two questions from this: > # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected? > # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Not to mention that we don't want to behave differently for JDK8 and JDK11. > Hope I don't have any misconfiguration in the configuration itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5620) SerializedPackageMergeTwoSteps2Test random failure

by Daniel Rosa (Jira)

[ https://issues.redhat.com/browse/DROOLS-5620?page=com.atlassian.jira.plug... ] Daniel Rosa commented on DROOLS-5620: ------------------------------------- We came to the conclusion that this was a random failure. After a few e-mails with Engineering, the suggestion is to mark these tests as @Ignore: * the original issue demands two different JVMs to reproduce * it still can be tested manually Pull request sent: https://github.com/kiegroup/drools/pull/3082 > SerializedPackageMergeTwoSteps2Test random failure > -------------------------------------------------- > > Key: DROOLS-5620 > URL: https://issues.redhat.com/browse/DROOLS-5620 > Project: Drools > Issue Type: Bug > Reporter: Daniel Rosa > Assignee: Daniel Rosa > Priority: Minor > > org.drools.compiler.integrationtests. > SerializedPackageMergeTwoSteps2Test.testBuildAndSerializePackagesInTwoSteps2 > Failed on [7.39.x daily build #74|https://rhba-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/KIE/job/7.39.x/job/daily-build-prod/job/daily-build-prod-pipeline-7.39.x/74/testReport/junit/org.drools.compiler.integrationtests/SerializedPackageMergeTwoSteps2Test/testBuildAndSerializePackagesInTwoSteps2/] with java.io.EOFException. > The EOFException is raised when the resource files provided by the first step class (SerializedPackageMergeTwoSteps1Test) are not ready for the second class (SerializedPackageMergeTwoSteps2Test) to consume them. > It happened on #74 build that the second class tried to consume the files faster than the first class was able to finish writing them on disk. > The QE community test jobs ([this one for instance|https://rhba-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/BxMS...]) passed for 7.8.1 build. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5620) SerializedPackageMergeTwoSteps2Test random failure

by Daniel Rosa (Jira)

[ https://issues.redhat.com/browse/DROOLS-5620?page=com.atlassian.jira.plug... ] Daniel Rosa edited comment on DROOLS-5620 at 9/7/20 7:57 AM: ------------------------------------------------------------- We came to the conclusion that this was a random failure. After a few e-mails with Engineering, our suggestion is to mark these tests as @Ignore: * the original issue demands two different JVMs to reproduce * it still can be tested manually Pull request sent: [https://github.com/kiegroup/drools/pull/3082] was (Author: drosabrno): We came to the conclusion that this was a random failure. After a few e-mails with Engineering, the suggestion is to mark these tests as @Ignore: * the original issue demands two different JVMs to reproduce * it still can be tested manually Pull request sent: https://github.com/kiegroup/drools/pull/3082 > SerializedPackageMergeTwoSteps2Test random failure > -------------------------------------------------- > > Key: DROOLS-5620 > URL: https://issues.redhat.com/browse/DROOLS-5620 > Project: Drools > Issue Type: Bug > Reporter: Daniel Rosa > Assignee: Daniel Rosa > Priority: Minor > > org.drools.compiler.integrationtests. > SerializedPackageMergeTwoSteps2Test.testBuildAndSerializePackagesInTwoSteps2 > Failed on [7.39.x daily build #74|https://rhba-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/KIE/job/7.39.x/job/daily-build-prod/job/daily-build-prod-pipeline-7.39.x/74/testReport/junit/org.drools.compiler.integrationtests/SerializedPackageMergeTwoSteps2Test/testBuildAndSerializePackagesInTwoSteps2/] with java.io.EOFException. > The EOFException is raised when the resource files provided by the first step class (SerializedPackageMergeTwoSteps1Test) are not ready for the second class (SerializedPackageMergeTwoSteps2Test) to consume them. > It happened on #74 build that the second class tried to consume the files faster than the first class was able to finish writing them on disk. > The QE community test jobs ([this one for instance|https://rhba-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/BxMS...]) passed for 7.8.1 build. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5612) DMN integrate test example from DMN spec not listed in ADOC

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5612?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5612: ----------------------------------- Sprint: 2020 Week 34-36 (from Aug 17), 2020 Week 37-39 (from Sep 7) (was: 2020 Week 34-36 (from Aug 17)) > DMN integrate test example from DMN spec not listed in ADOC > ----------------------------------------------------------- > > Key: DROOLS-5612 > URL: https://issues.redhat.com/browse/DROOLS-5612 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > Follows up [BXMSDOC-6058] and [DROOLS-5440] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4606) DMN alpha network POC

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-4606?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-4606: ----------------------------------- Sprint: 2019 Week 41-43 (from Okt 7), 2019 Week 44-46 (from Okt 28), 2019 Week 47-49 (from Nov 18), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17), 2020 Week 37-39 (from Sep 7) (was: 2019 Week 41-43 (from Okt 7), 2019 Week 44-46 (from Okt 28), 2019 Week 47-49 (from Nov 18), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17)) > DMN alpha network POC > --------------------- > > Key: DROOLS-4606 > URL: https://issues.redhat.com/browse/DROOLS-4606 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Luca Molteni > Priority: Major > > Start refactoring work to support alpha network -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5378) Alpha Node ordering

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5378?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5378: ----------------------------------- Sprint: 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17), 2020 Week 37-39 (from Sep 7) (was: 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17)) > Alpha Node ordering > ------------------- > > Key: DROOLS-5378 > URL: https://issues.redhat.com/browse/DROOLS-5378 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.38.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Re-order Alpha Node based on some strategies: > - Expression usage count > - Other strategies : Chapter 9 "Ordering Conditions" in http://i.stanford.edu/pub/cstr/reports/cs/tr/86/1124/CS-TR-86-1124.pdf > It would contribute to maximise sharing and minimise the number of evaluations. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5193) Implement Listener mechanism to trace execution

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5193?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5193: ----------------------------------- Sprint: 2020 Week 13-15 (from Mar 23), 2020 Week 16-18 (from Apr 13), 2020 Week 19-21 (from May 4), 2020 Week 22-24 (from May 25), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17), 2020 Week 37-39 (from Sep 7) (was: 2020 Week 13-15 (from Mar 23), 2020 Week 16-18 (from Apr 13), 2020 Week 19-21 (from May 4), 2020 Week 22-24 (from May 25), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17)) > Implement Listener mechanism to trace execution > ----------------------------------------------- > > Key: DROOLS-5193 > URL: https://issues.redhat.com/browse/DROOLS-5193 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Implement Listener architecture so that model-implementation may "publish" execution step detail to be read by "listening" code. > Implementation should not be mandatory, i.e. model should not be forced to implement it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5389) Create single abstract class for integration tests in new PMML implementation

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5389?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5389: ----------------------------------- Sprint: 2020 Week 22-24 (from May 25), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17), 2020 Week 37-39 (from Sep 7) (was: 2020 Week 22-24 (from May 25), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17)) > Create single abstract class for integration tests in new PMML implementation > ----------------------------------------------------------------------------- > > Key: DROOLS-5389 > URL: https://issues.redhat.com/browse/DROOLS-5389 > Project: Drools > Issue Type: Task > Reporter: Jiri Petrlik > Assignee: Jiri Petrlik > Priority: Major > Labels: TrustyAI > > Currently there are multiple abstract classes for PMML integration tests such as AbstractPMMLTreeTest, AbstractPMMLRegressionTest etc. The goal of this JIRA is to unify them and create one single abstract class. -- This message was sent by Atlassian Jira (v7.13.8#713008)

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