[JBoss JIRA] (DROOLS-5458) Project broken after test scenario run with possibly a class-loading issue
by Jan Stastny (Jira)
[ https://issues.redhat.com/browse/DROOLS-5458?page=com.atlassian.jira.plug... ]
Jan Stastny updated DROOLS-5458:
--------------------------------
Steps to Reproduce:
# Download the zip
# Import the project
# Run test scenario simulation
## If not failed - go to TicketPrices.drl and validate
### If DRL validation didn't fail run the scesim again and repeat the DRL validation
### If DRL validation failed, go to scesim and run again
## if failed - go to project and press Build
## Validate the rule again - should pass.
# Run the scenario again - should pass.
was:
# Download the zip
# Import the project
# Run test scenario simulation
## If not failed - go to TicketPrices.drl and validate
### If DRL validation didn't fail run the scesim again and repeat the DRL validation
### If DRL validation failed, go to scesim and run again
## if failed - go to project and press Build
# Run the scenario again - should pass.
> Project broken after test scenario run with possibly a class-loading issue
> --------------------------------------------------------------------------
>
> Key: DROOLS-5458
> URL: https://issues.redhat.com/browse/DROOLS-5458
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.39.0.Final
> Reporter: Jan Stastny
> Assignee: Yeser Amer
> Priority: Blocker
> Attachments: bpms_scesim-tickets.zip
>
>
> For a Scenario Simulation that tests DRL rule and facts having an enum property a seemingly class-loading issue occurs in Business Central.
> The ultimate error is in the DRL file validation:
> {code:java|title=DRL file}
> package org.jboss.qa.ba.scesim;
> rule "child ticket"
> when
> t: Ticket ( type==TicketType.CHILD)
> then
> t.setPrice(5.0);
> end
> {code}
> {code:java|title=Validation error}
> [KBase: defaultKieBase]: Unable to Analyse Expression type == TicketType.CHILD:
> [Error: Comparison operation requires compatible types. Found class org.jboss.qa.ba.scesim.TicketType and class org.jboss.qa.ba.scesim.TicketType]
> [Near : {... type == TicketType.CHILD ....}]
> ^
> {code}
> The issue happens in given scenario:
> # import project
> # go to DRL file and run validation - succeeds
> # go to scenario simulation and run - succeeds
> # go back to DRL file and run validation - fails with the error above
> # go to scenario simulation and run again - fails due to the rule not being evaluated for given facts
> The issue disappears when running Build of the project in the Project perspective.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months
[JBoss JIRA] (DROOLS-5458) Project broken after test scenario run with possibly a class-loading issue
by Daniele Zonca (Jira)
[ https://issues.redhat.com/browse/DROOLS-5458?page=com.atlassian.jira.plug... ]
Daniele Zonca reassigned DROOLS-5458:
-------------------------------------
Assignee: Yeser Amer (was: Daniele Zonca)
> Project broken after test scenario run with possibly a class-loading issue
> --------------------------------------------------------------------------
>
> Key: DROOLS-5458
> URL: https://issues.redhat.com/browse/DROOLS-5458
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.39.0.Final
> Reporter: Jan Stastny
> Assignee: Yeser Amer
> Priority: Blocker
> Attachments: bpms_scesim-tickets.zip
>
>
> For a Scenario Simulation that tests DRL rule and facts having an enum property a seemingly class-loading issue occurs in Business Central.
> The ultimate error is in the DRL file validation:
> {code:java|title=DRL file}
> package org.jboss.qa.ba.scesim;
> rule "child ticket"
> when
> t: Ticket ( type==TicketType.CHILD)
> then
> t.setPrice(5.0);
> end
> {code}
> {code:java|title=Validation error}
> [KBase: defaultKieBase]: Unable to Analyse Expression type == TicketType.CHILD:
> [Error: Comparison operation requires compatible types. Found class org.jboss.qa.ba.scesim.TicketType and class org.jboss.qa.ba.scesim.TicketType]
> [Near : {... type == TicketType.CHILD ....}]
> ^
> {code}
> The issue happens in given scenario:
> # import project
> # go to DRL file and run validation - succeeds
> # go to scenario simulation and run - succeeds
> # go back to DRL file and run validation - fails with the error above
> # go to scenario simulation and run again - fails due to the rule not being evaluated for given facts
> The issue disappears when running Build of the project in the Project perspective.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months
[JBoss JIRA] (DROOLS-5458) Project broken after test scenario run with possibly a class-loading issue
by Jan Stastny (Jira)
[ https://issues.redhat.com/browse/DROOLS-5458?page=com.atlassian.jira.plug... ]
Jan Stastny updated DROOLS-5458:
--------------------------------
Description:
For a Scenario Simulation that tests DRL rule and facts having an enum property a seemingly class-loading issue occurs in Business Central.
The ultimate error is in the DRL file validation:
{code:java|title=DRL file}
package org.jboss.qa.ba.scesim;
rule "child ticket"
when
t: Ticket ( type==TicketType.CHILD)
then
t.setPrice(5.0);
end
{code}
{code:java|title=Validation error}
[KBase: defaultKieBase]: Unable to Analyse Expression type == TicketType.CHILD:
[Error: Comparison operation requires compatible types. Found class org.jboss.qa.ba.scesim.TicketType and class org.jboss.qa.ba.scesim.TicketType]
[Near : {... type == TicketType.CHILD ....}]
^
{code}
The issue happens in given scenario:
# import project
# go to DRL file and run validation - succeeds
# go to scenario simulation and run - succeeds
# go back to DRL file and run validation - fails with the error above
# go to scenario simulation and run again - fails due to the rule not being evaluated for given facts
The issue disappears when running Build of the project in the Project perspective.
was:
For a Scenario Simulation that tests DRL rule and facts having an enum property a seemingly class-loading issue occurs in Business Central.
The ultimate error is in the DRL file validation:
{code:java|title=DRL file}
package org.jboss.qa.ba.scesim;
rule "child ticket"
when
t: Ticket ( type==TicketType.CHILD)
then
t.setPrice(5.0);
end
{code}
{code:java|title=Validation error}
[KBase: defaultKieBase]: Unable to Analyse Expression type == TicketType.CHILD:
[Error: Comparison operation requires compatible types. Found class org.jboss.qa.ba.scesim.TicketType and class org.jboss.qa.ba.scesim.TicketType]
[Near : {... type == TicketType.CHILD ....}]
^
{code}
The issue happens in given scenario:
# import project
# go to DRL file and run validation - succeeds
# go to scenario simulation and run - succeeds
# go back to DRL file and run validation - fails with the error above
# go to scenario simulation and run again - fails due to the rule not being evaluated for given facts (thus Ticket.price is not set and the consecutive rules fail with NPE)
The issue disappears when running Build of the project in the Project perspective.
> Project broken after test scenario run with possibly a class-loading issue
> --------------------------------------------------------------------------
>
> Key: DROOLS-5458
> URL: https://issues.redhat.com/browse/DROOLS-5458
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.39.0.Final
> Reporter: Jan Stastny
> Assignee: Daniele Zonca
> Priority: Blocker
> Attachments: bpms_scesim-tickets.zip
>
>
> For a Scenario Simulation that tests DRL rule and facts having an enum property a seemingly class-loading issue occurs in Business Central.
> The ultimate error is in the DRL file validation:
> {code:java|title=DRL file}
> package org.jboss.qa.ba.scesim;
> rule "child ticket"
> when
> t: Ticket ( type==TicketType.CHILD)
> then
> t.setPrice(5.0);
> end
> {code}
> {code:java|title=Validation error}
> [KBase: defaultKieBase]: Unable to Analyse Expression type == TicketType.CHILD:
> [Error: Comparison operation requires compatible types. Found class org.jboss.qa.ba.scesim.TicketType and class org.jboss.qa.ba.scesim.TicketType]
> [Near : {... type == TicketType.CHILD ....}]
> ^
> {code}
> The issue happens in given scenario:
> # import project
> # go to DRL file and run validation - succeeds
> # go to scenario simulation and run - succeeds
> # go back to DRL file and run validation - fails with the error above
> # go to scenario simulation and run again - fails due to the rule not being evaluated for given facts
> The issue disappears when running Build of the project in the Project perspective.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months
[JBoss JIRA] (DROOLS-5458) Project broken after test scenario run with possibly a class-loading issue
by Jan Stastny (Jira)
Jan Stastny created DROOLS-5458:
-----------------------------------
Summary: Project broken after test scenario run with possibly a class-loading issue
Key: DROOLS-5458
URL: https://issues.redhat.com/browse/DROOLS-5458
Project: Drools
Issue Type: Bug
Components: Scenario Simulation and Testing
Affects Versions: 7.39.0.Final
Reporter: Jan Stastny
Assignee: Daniele Zonca
For a Scenario Simulation that tests DRL rule and facts having an enum property a seemingly class-loading issue occurs in Business Central.
The ultimate error is in the DRL file validation:
{code:java|title=DRL file}
package org.jboss.qa.ba.scesim;
rule "child ticket"
when
t: Ticket ( type==TicketType.CHILD)
then
t.setPrice(5.0);
end
{code}
{code:java|title=Validation error}
[KBase: defaultKieBase]: Unable to Analyse Expression type == TicketType.CHILD:
[Error: Comparison operation requires compatible types. Found class org.jboss.qa.ba.scesim.TicketType and class org.jboss.qa.ba.scesim.TicketType]
[Near : {... type == TicketType.CHILD ....}]
^
{code}
The issue happens in given scenario:
# import project
# go to DRL file and run validation - succeeds
# go to scenario simulation and run - succeeds
# go back to DRL file and run validation - fails with the error above
# go to scenario simulation and run again - fails due to the rule not being evaluated for given facts (thus Ticket.price is not set and the consecutive rules fail with NPE)
The issue disappears when running Build of the project in the Project perspective.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months
[JBoss JIRA] (DROOLS-5458) Project broken after test scenario run with possibly a class-loading issue
by Jan Stastny (Jira)
[ https://issues.redhat.com/browse/DROOLS-5458?page=com.atlassian.jira.plug... ]
Jan Stastny updated DROOLS-5458:
--------------------------------
Attachment: bpms_scesim-tickets.zip
> Project broken after test scenario run with possibly a class-loading issue
> --------------------------------------------------------------------------
>
> Key: DROOLS-5458
> URL: https://issues.redhat.com/browse/DROOLS-5458
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.39.0.Final
> Reporter: Jan Stastny
> Assignee: Daniele Zonca
> Priority: Blocker
> Attachments: bpms_scesim-tickets.zip
>
>
> For a Scenario Simulation that tests DRL rule and facts having an enum property a seemingly class-loading issue occurs in Business Central.
> The ultimate error is in the DRL file validation:
> {code:java|title=DRL file}
> package org.jboss.qa.ba.scesim;
> rule "child ticket"
> when
> t: Ticket ( type==TicketType.CHILD)
> then
> t.setPrice(5.0);
> end
> {code}
> {code:java|title=Validation error}
> [KBase: defaultKieBase]: Unable to Analyse Expression type == TicketType.CHILD:
> [Error: Comparison operation requires compatible types. Found class org.jboss.qa.ba.scesim.TicketType and class org.jboss.qa.ba.scesim.TicketType]
> [Near : {... type == TicketType.CHILD ....}]
> ^
> {code}
> The issue happens in given scenario:
> # import project
> # go to DRL file and run validation - succeeds
> # go to scenario simulation and run - succeeds
> # go back to DRL file and run validation - fails with the error above
> # go to scenario simulation and run again - fails due to the rule not being evaluated for given facts (thus Ticket.price is not set and the consecutive rules fail with NPE)
> The issue disappears when running Build of the project in the Project perspective.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by Boris Unckel (Jira)
[ https://issues.redhat.com/browse/WFCORE-482?page=com.atlassian.jira.plugi... ]
Boris Unckel commented on WFCORE-482:
-------------------------------------
I have created https://github.com/wildfly/wildfly-core/pull/4248 to adress this.
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFCORE-482
> URL: https://issues.redhat.com/browse/WFCORE-482
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Major
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months
[JBoss JIRA] (JGRP-2486) FD Monitor get stuck on TrasferQueueBundler
by lukas brandl (Jira)
lukas brandl created JGRP-2486:
----------------------------------
Summary: FD Monitor get stuck on TrasferQueueBundler
Key: JGRP-2486
URL: https://issues.redhat.com/browse/JGRP-2486
Project: JGroups
Issue Type: Bug
Affects Versions: 4.0.22
Reporter: lukas brandl
Assignee: Bela Ban
Attachments: Main.java, stack-trace.txt
Apparently there is an issue in the FD protocol. When a cluster nodes is disconnected and the disconnect isn't handled by FD_SOCK, FD stops sending heartbeats after a while. This only happens when the queue of the TrasferQueueBundler fills up before the node is suspected.
The stack trace shows that the FD$Monitor is blocked by the bundler. This is probably the reason why the heartbeat timeouts are not noticed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months
[JBoss JIRA] (WFCORE-5023) A few tests don't work using IBM JDK because of mock-server 5.9.0
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFCORE-5023?page=com.atlassian.jira.plug... ]
Ricardo Martin Camarero edited comment on WFCORE-5023 at 6/26/20 6:39 AM:
--------------------------------------------------------------------------
The mockserver seems to work this way:
* Version 5.8.1 seems to use bouncycastle for the SSL configuration.
* 5.9.0 and 5.10.0 seems to use internal openjdk for everything (and makes IBM jdk fail).
* In the future it seems that bouncycastle is going to be optional and it can be configured to be used instead of the internal openjdk (this [commit|https://github.com/mock-server/mockserver/commit/34e792f47c23bf0e9...], but it's still WIP).
For the moment the downgrade is needed and we'll upgrade it when the new version is ready and able to switch between both SSL implementations. Let's see if the downgrade does not affect any other test.
EDIT: The need for BC or internal openjdk is for X509 certificate/key-pair generation (DER encoding, certificates and so on and so forth), not for TLS/SSL communication.
was (Author: rhn-support-rmartinc):
The mockserver seems to work this way:
* Version 5.8.1 seems to use bouncycastle for the SSL configuration.
* 5.9.0 and 5.10.0 seems to use internal openjdk for everything (and makes IBM jdk fail).
* In the future it seems that bouncycastle is going to be optional and it can be configured to be used instead of the internal openjdk (this [commit|https://github.com/mock-server/mockserver/commit/34e792f47c23bf0e9...], but it's still WIP).
For the moment the downgrade is needed and we'll upgrade it when the new version is ready and able to switch between both SSL implementations. Let's see if the downgrade does not affect any other test.
EDIT: The need for BC or internal opendk is for certificate/key-pair generation (DER encoding, certificates and so on and so forth), not for TLS/SSL communication.
> A few tests don't work using IBM JDK because of mock-server 5.9.0
> -----------------------------------------------------------------
>
> Key: WFCORE-5023
> URL: https://issues.redhat.com/browse/WFCORE-5023
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 13.0.0.Beta1
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Major
>
> After JIRA WFCORE-4850 the mock-server 5.9.0 does not work with IBM JDK which makes a few tests fail with the following error:
> {code:bash}
> cd ./testsuite/standalone/
> export JAVA_HOME=/home/rmartinc/apps/ibm-java-x86_64-80/
> mvn clean test -Dtest=org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase
> ...
> [INFO] -------------------------------------------------------
> [INFO] T E S T S
> [INFO] -------------------------------------------------------
> [INFO] Running org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.005 s <<< FAILURE! - in org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase
> [ERROR] org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase Time elapsed: 0.003 s <<< ERROR!
> java.lang.NoClassDefFoundError: sun.security.x509.GeneralNameInterface
> at org.mockserver.socket.tls.jdk.JDKKeyAndCertificateFactory.<init>(JDKKeyAndCertificateFactory.java:36)
> at org.mockserver.socket.tls.NettySslContextFactory.<init>(NettySslContextFactory.java:37)
> at org.mockserver.client.MockServerClient.<init>(MockServerClient.java:57)
> at org.mockserver.integration.ClientAndServer.<init>(ClientAndServer.java:19)
> at org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase.setup(SecurityCommandsTestCase.java:358)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> Caused by: java.lang.ClassNotFoundException: sun.security.x509.GeneralNameInterface
> at java.net.URLClassLoader.findClass(URLClassLoader.java:610)
> at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:944)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:889)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:872)
> ... 36 more
> {code}
> The tests that don't work are the following three classes:
> * CertificateAuthoritiesTestCase.java (elytron)
> * KeyStoresTestCase.java (elytron)
> * SecurityCommandsTestCase.java (testsuite/standalone)
> This is explained in the mock-server [issue 750|https://github.com/mock-server/mockserver/issues/750]. For the moment the only solution is doing a downgrade to 5.8.1. Although it is expected to be fixed soon in the mock-server (maybe in the next version 5.10.1 or 5.11.0).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months
[JBoss JIRA] (WFCORE-5023) A few tests don't work using IBM JDK because of mock-server 5.9.0
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFCORE-5023?page=com.atlassian.jira.plug... ]
Ricardo Martin Camarero edited comment on WFCORE-5023 at 6/26/20 6:33 AM:
--------------------------------------------------------------------------
The mockserver seems to work this way:
* Version 5.8.1 seems to use bouncycastle for the SSL configuration.
* 5.9.0 and 5.10.0 seems to use internal openjdk for everything (and makes IBM jdk fail).
* In the future it seems that bouncycastle is going to be optional and it can be configured to be used instead of the internal openjdk (this [commit|https://github.com/mock-server/mockserver/commit/34e792f47c23bf0e9...], but it's still WIP).
For the moment the downgrade is needed and we'll upgrade it when the new version is ready and able to switch between both SSL implementations. Let's see if the downgrade does not affect any other test.
EDIT: The need for BC or internal opendk is for certificate/key-pair generation (DER encoding, certificates and so on and so forth), not for TLS/SSL communication.
was (Author: rhn-support-rmartinc):
The mockserver seems to work this way:
* Version 5.8.1 seems to use bouncycastle for all SSL configuration.
* 5.9.0 and 5.10.0 seems to use internal openjdk for everything (and makes IBM jdk fail).
* In the future it seems that bouncycastle is going to be optional and it can be configured to be used instead of the internal openjdk (this [commit|https://github.com/mock-server/mockserver/commit/34e792f47c23bf0e9...], but it's still WIP).
For the moment the downgrade is needed and we'll upgrade it when the new version is ready and able to switch between both SSL implementations. Let's see if the downgrade does not affect any other test.
> A few tests don't work using IBM JDK because of mock-server 5.9.0
> -----------------------------------------------------------------
>
> Key: WFCORE-5023
> URL: https://issues.redhat.com/browse/WFCORE-5023
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 13.0.0.Beta1
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Major
>
> After JIRA WFCORE-4850 the mock-server 5.9.0 does not work with IBM JDK which makes a few tests fail with the following error:
> {code:bash}
> cd ./testsuite/standalone/
> export JAVA_HOME=/home/rmartinc/apps/ibm-java-x86_64-80/
> mvn clean test -Dtest=org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase
> ...
> [INFO] -------------------------------------------------------
> [INFO] T E S T S
> [INFO] -------------------------------------------------------
> [INFO] Running org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.005 s <<< FAILURE! - in org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase
> [ERROR] org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase Time elapsed: 0.003 s <<< ERROR!
> java.lang.NoClassDefFoundError: sun.security.x509.GeneralNameInterface
> at org.mockserver.socket.tls.jdk.JDKKeyAndCertificateFactory.<init>(JDKKeyAndCertificateFactory.java:36)
> at org.mockserver.socket.tls.NettySslContextFactory.<init>(NettySslContextFactory.java:37)
> at org.mockserver.client.MockServerClient.<init>(MockServerClient.java:57)
> at org.mockserver.integration.ClientAndServer.<init>(ClientAndServer.java:19)
> at org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase.setup(SecurityCommandsTestCase.java:358)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> Caused by: java.lang.ClassNotFoundException: sun.security.x509.GeneralNameInterface
> at java.net.URLClassLoader.findClass(URLClassLoader.java:610)
> at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:944)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:889)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:872)
> ... 36 more
> {code}
> The tests that don't work are the following three classes:
> * CertificateAuthoritiesTestCase.java (elytron)
> * KeyStoresTestCase.java (elytron)
> * SecurityCommandsTestCase.java (testsuite/standalone)
> This is explained in the mock-server [issue 750|https://github.com/mock-server/mockserver/issues/750]. For the moment the only solution is doing a downgrade to 5.8.1. Although it is expected to be fixed soon in the mock-server (maybe in the next version 5.10.1 or 5.11.0).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months