[Red Hat JIRA] (WFWIP-366) MicroProfileMetricsSecuredEndpointTestCase,MicroProfileVendorMetricsBootTestCase failing in bootable jar run
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-366?page=com.atlassian.jira.plugin... ]
Martin Choma edited comment on WFWIP-366 at 12/9/20 5:40 AM:
-------------------------------------------------------------
> Are you sure these tests ever pass with -Dts.bootable on nightly runs?
You are right. I was tricked by green ball, but did not checked if test was really run. Now I did and test is really not run in nightly. Sorry for that false statement. Yesterday when I was reviewing MR I came to similar conclusion as you did. Thanks for fixing it.
was (Author: mchoma):
> Are you sure these tests ever pass with -Dts.bootable on nightly runs?
You are right. I was tricked by green ball, but did not checked if test was really run. Now I did and test is really not run in nightly. Sorry for that false statement. Yesterday when I was reviewing MR I came to similar conclusion as you did.
> MicroProfileMetricsSecuredEndpointTestCase,MicroProfileVendorMetricsBootTestCase failing in bootable jar run
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-366
> URL: https://issues.redhat.com/browse/WFWIP-366
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
>
> {code}
> cd testsuite/integration/microprofile
> mvn test -Dts.bootable -Dtestsuite.ee.galleon.pack.version=22.0.0.Beta1-SNAPSHOT -Dtestsuite.ee.galleon.pack.artifactId=wildfly-galleon-pack -Dtestsuite.ee.galleon.pack.groupId=org.wildfly -Dversion.org.wildfly.jar.plugin=2.0.2.Final -Dtest=MicroProfileMetricsSecuredEndpointTestCase
> ...
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MicroProfileMetricsSecuredEndpointTestCase.securedHTTPEndpoint:89 expected:<200> but was:<401>
> [ERROR] MicroProfileVendorMetricsBootTestCase.testVendorMetricsDeployAfterBoot:159->checkResponse:188 connected=true
> cleanInit=true
> overallResponseCode=401
> overallSawVendor=false
> scopedResponseCode=401
> scopedSawVendor=false
> expected:<[200]> but was:<[401]>
> [INFO]
> [ERROR] Tests run: 3, Failures: 2, Errors: 0, Skipped: 0
> {code}
> Looking into tested bootable jar It seems strange I still see security-enabled="false"
> {code}
> <subsystem xmlns="urn:wildfly:microprofile-metrics-smallrye:2.0" security-enabled="false" exposed-subsystems="*" prefix="${wildfly.metrics.prefix:wildfly}"/>
> {code}
> Management interface is secured
> {code}
> <management-interfaces>
> <http-interface http-authentication-factory="management-http-authentication">
> <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
> <socket-binding http="management-http"/>
> </http-interface>
> </management-interfaces>
> {code}
> But mgmt-users.properties is empty no user expected by test "testSuite", "testSuitePassword"
> Same test is passing in WF22 nightly runs.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFCORE-5041) The public elytron module exports private API
by Moulali Shikalwadi (Jira)
[ https://issues.redhat.com/browse/WFCORE-5041?page=com.atlassian.jira.plug... ]
Moulali Shikalwadi commented on WFCORE-5041:
--------------------------------------------
[~dlofthouse] could you please provide some details about this issue.
> The public elytron module exports private API
> ---------------------------------------------
>
> Key: WFCORE-5041
> URL: https://issues.redhat.com/browse/WFCORE-5041
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Darran Lofthouse
> Priority: Major
>
> The public elytron module is defined as:
> {code:xml}
> <module name="org.wildfly.security.elytron-private" services="export" export="true">
> <exports>
> <include-set>
> <path name="org/wildfly/security"/>
> {code}
> The issue is export="true" exports everything including the private API.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFWIP-366) MicroProfileMetricsSecuredEndpointTestCase,MicroProfileVendorMetricsBootTestCase failing in bootable jar run
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFWIP-366?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFWIP-366:
-----------------------------------
[~mchoma] Are you sure these tests ever pass with -Dts.bootable on nightly runs?
In master branch, they are located in the testsuite/integration/basic and are specifically excluded from the ts.bootable run as they require security: https://github.com/wildfly/wildfly/blob/2095d398152d31c43f14f4200683fd1f6...
In the dev branch, they are now in the testsuite/integration/microprofile and can be run with Elytron.
However, the ts.bootable profile was missing the additional content (including the mgmt-users.properties) to make the test pass.
https://github.com/wildfly/wildfly/pull/13756/files?file-filters%5B%5D=.x...
I have amended the dev branch with that changes and was able to pass the tests:
{code}
$ mvn test -Dts.bootable -Dtestsuite.ee.galleon.pack.version=22.0.0.Beta1-SNAPSHOT -Dtestsuite.ee.galleon.pack.artifactId=wildfly-galleon-pack -Dtestsuite.ee.galleon.pack.groupId=org.wildfly -Dversion.org.wildfly.jar.plugin=2.0.2.Final -Dtest=MicroProfileMetricsSecuredEndpointTestCase
...
Running org.wildfly.test.integration.microprofile.metrics.secured.MicroProfileMetricsSecuredEndpointTestCase
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.98 s - in org.wildfly.test.integration.microprofile.metrics.secured.MicroProfileMetricsSecuredEndpointTestCase
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
{code}
> MicroProfileMetricsSecuredEndpointTestCase,MicroProfileVendorMetricsBootTestCase failing in bootable jar run
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-366
> URL: https://issues.redhat.com/browse/WFWIP-366
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
>
> {code}
> cd testsuite/integration/microprofile
> mvn test -Dts.bootable -Dtestsuite.ee.galleon.pack.version=22.0.0.Beta1-SNAPSHOT -Dtestsuite.ee.galleon.pack.artifactId=wildfly-galleon-pack -Dtestsuite.ee.galleon.pack.groupId=org.wildfly -Dversion.org.wildfly.jar.plugin=2.0.2.Final -Dtest=MicroProfileMetricsSecuredEndpointTestCase
> ...
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MicroProfileMetricsSecuredEndpointTestCase.securedHTTPEndpoint:89 expected:<200> but was:<401>
> [ERROR] MicroProfileVendorMetricsBootTestCase.testVendorMetricsDeployAfterBoot:159->checkResponse:188 connected=true
> cleanInit=true
> overallResponseCode=401
> overallSawVendor=false
> scopedResponseCode=401
> scopedSawVendor=false
> expected:<[200]> but was:<[401]>
> [INFO]
> [ERROR] Tests run: 3, Failures: 2, Errors: 0, Skipped: 0
> {code}
> Looking into tested bootable jar It seems strange I still see security-enabled="false"
> {code}
> <subsystem xmlns="urn:wildfly:microprofile-metrics-smallrye:2.0" security-enabled="false" exposed-subsystems="*" prefix="${wildfly.metrics.prefix:wildfly}"/>
> {code}
> Management interface is secured
> {code}
> <management-interfaces>
> <http-interface http-authentication-factory="management-http-authentication">
> <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
> <socket-binding http="management-http"/>
> </http-interface>
> </management-interfaces>
> {code}
> But mgmt-users.properties is empty no user expected by test "testSuite", "testSuitePassword"
> Same test is passing in WF22 nightly runs.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14196) Some remote EJB invocations are slower when one of the initial cluster nodes is down
by Jarosław Przygódzki (Jira)
[ https://issues.redhat.com/browse/WFLY-14196?page=com.atlassian.jira.plugi... ]
Jarosław Przygódzki updated WFLY-14196:
---------------------------------------
Attachment: WFLY-14196-stacktrace.txt
> Some remote EJB invocations are slower when one of the initial cluster nodes is down
> ------------------------------------------------------------------------------------
>
> Key: WFLY-14196
> URL: https://issues.redhat.com/browse/WFLY-14196
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 21.0.1.Final
> Reporter: Jarosław Przygódzki
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: WFLY-14196-stacktrace.txt
>
>
> When one of the initial cluster nodes becomes unavailable, every 5 seconds one of the remote invocations takes few seconds longer.
> It seems that the delay is introduced by _DiscoveryEJBClientInterceptor_ that tries to connect to node that's not available and blocks until connection attempt fails.
> From what I've gathered, it looks like an unintended consequence of EJBCLIENT-309, because the slower call happens exactly when failed destination in RemotingEJBDiscoveryProvider expires, and increasing _org.jboss.ejb.client.destination-recheck-interval_ makes slower invocations to happen less frequently, matching _destination-recheck-interval_ value.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14196) Some remote EJB invocations are slower when one of the initial cluster nodes is down
by Jarosław Przygódzki (Jira)
Jarosław Przygódzki created WFLY-14196:
------------------------------------------
Summary: Some remote EJB invocations are slower when one of the initial cluster nodes is down
Key: WFLY-14196
URL: https://issues.redhat.com/browse/WFLY-14196
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 21.0.1.Final
Reporter: Jarosław Przygódzki
Assignee: Paul Ferraro
When one of the initial cluster nodes becomes unavailable, every 5 seconds one of the remote invocations takes few seconds longer.
It seems that the delay is introduced by _DiscoveryEJBClientInterceptor_ that tries to connect to node that's not available and blocks until connection attempt fails.
From what I've gathered, it looks like an unintended consequence of EJBCLIENT-309, because the slower call happens exactly when failed destination in RemotingEJBDiscoveryProvider expires, and increasing _org.jboss.ejb.client.destination-recheck-interval_ makes slower invocations to happen less frequently, matching _destination-recheck-interval_ value.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (DROOLS-5887) The enhanced "for" (foreach) statement causes compilation error in executable models.
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5887?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5887:
---------------------------------
Sprint: 2020 Week 49-51 (from Nov 30)
> The enhanced "for" (foreach) statement causes compilation error in executable models.
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-5887
> URL: https://issues.redhat.com/browse/DROOLS-5887
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
> Attachments: reproducer_02801729_1a.zip
>
>
> Compiling a rule like (*1) which is described in MVEL dialect and contains the enhanced "for" (foreach) statement in the action part with executable rule models enabled, compilation error like (*2) occurs at the enhanced "for" statement.
> (*1)
> {noformat}
> package com.example.reproducer
> import java.util.ArrayList
> import com.example.reproducer.Bus
> dialect "mvel"
> rule "bus1"
> when
> $buses : ArrayList() from collect ( Bus() )
> then
> for (Bus : $buses ) {
> System.out.println("bus: " + bus);
> }
> end
> {noformat}
> (*2)
> {noformat}
> [ERROR] Unable to build KieBaseModel:rules
> CompilationProblemErrorResult: org.drools.mvelcompiler.MvelCompilerException: Type check of for (Bus bus : $buses) {
> System.out.println("bus: " + bus);
> } failed.
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (DROOLS-5887) The enhanced "for" (foreach) statement causes compilation error in executable models.
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5887?page=com.atlassian.jira.plug... ]
Luca Molteni moved RHDM-1525 to DROOLS-5887:
--------------------------------------------
Project: Drools (was: Red Hat Decision Manager)
Key: DROOLS-5887 (was: RHDM-1525)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: executable model
(was: BRE)
Environment: (was: RHDM 7.9.0.)
Affects Version/s: (was: 7.9.0.GA)
QE Status: NEW
> The enhanced "for" (foreach) statement causes compilation error in executable models.
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-5887
> URL: https://issues.redhat.com/browse/DROOLS-5887
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
> Attachments: reproducer_02801729_1a.zip
>
>
> Compiling a rule like (*1) which is described in MVEL dialect and contains the enhanced "for" (foreach) statement in the action part with executable rule models enabled, compilation error like (*2) occurs at the enhanced "for" statement.
> (*1)
> {noformat}
> package com.example.reproducer
> import java.util.ArrayList
> import com.example.reproducer.Bus
> dialect "mvel"
> rule "bus1"
> when
> $buses : ArrayList() from collect ( Bus() )
> then
> for (Bus : $buses ) {
> System.out.println("bus: " + bus);
> }
> end
> {noformat}
> (*2)
> {noformat}
> [ERROR] Unable to build KieBaseModel:rules
> CompilationProblemErrorResult: org.drools.mvelcompiler.MvelCompilerException: Type check of for (Bus bus : $buses) {
> System.out.println("bus: " + bus);
> } failed.
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (DROOLS-5867) Update ApplyPmmlModelCommand to manage both PMML implementations
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5867?page=com.atlassian.jira.plug... ]
Gabriele Cardosi closed DROOLS-5867.
------------------------------------
> Update ApplyPmmlModelCommand to manage both PMML implementations
> -----------------------------------------------------------------
>
> Key: DROOLS-5867
> URL: https://issues.redhat.com/browse/DROOLS-5867
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: TrustyAI
>
> Currently, ApplyPmmlModelCommand (inside drools) invoke directly the legacy PMML delegate (ApplyPmmlModelCommandExecutorImpl).
> # move Command newApplyPmmlModel(PMMLRequestData request); from ExtendedKieCommands to KieCommands
> # define PMMLCommandExecutor interface inside kie-internal (droolsjbpm-knowledge)
> # define PMMLCommandExecutorFactory interface inside kie-internal (droolsjbpm-knowledge)
> # write PMMLCommandExecutor implementation (inside kie-pmml-trusty )
> # write PMMLCommandExecutorFactory implementation (inside kie-pmml-trusty )
> # write kie.konf in the same module as PMMLCommandExecutorFactory implementation to bind the implementation to the interface
> # create a static method "isToEnable()" to be used by PMMLAssemblerService(s) and ApplyPmmlModelCommand to retrieve which implementation is to be enabled - it will replace the ones in PMMLAssemblerService(s) (inside kie-api)
> # modify ApplyPmmlModelCommand to switch between factories/implementations (using the above method to choose the implementation to enable)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months