[JBoss JIRA] (WFLY-13827) Manual IIOP/CORBA stub generation fails on IBM JDK when running the Galleon Layers testsuite
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-13827?page=com.atlassian.jira.plugi... ]
Yeray Borges Santana deleted WFLY-13827:
----------------------------------------
> Manual IIOP/CORBA stub generation fails on IBM JDK when running the Galleon Layers testsuite
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-13827
> URL: https://issues.redhat.com/browse/WFLY-13827
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 20.0.1.Final
> Reporter: Yeray Borges Santana
> Assignee: Yeray Borges Santana
> Priority: Major
>
> The Galleon Layers basic integration test suite fails on IBM JDK with the following error:
> {noformat}
> [INFO] --- exec-maven-plugin:1.6.0:exec (ibmjdk.iiop.stub-creation) @ wildfly-ts-integ-basic ---
> error: Class javax.ejb.EJBHome not found in interface org.jboss.as.test.integration.ejb.iiop.naming.IIOPStatefulNamingHome.
> error: Class javax.ejb.EJBHome not found.
> error: Class javax.ejb.EJBHome not found in interface org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingHome.
> error: Class javax.ejb.EJBHome not found.
> 4 errors
> [ERROR] Command execution failed.
> org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
> at org.apache.commons.exec.DefaultExecutor.executeInternal (DefaultExecutor.java:404)
> at org.apache.commons.exec.DefaultExecutor.execute (DefaultExecutor.java:166)
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:804)
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:751)
> at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:313)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {noformat}
> The reason is the ibmjdk.profile is activated independently if we are generating a slimmer server by using Galleon layers, failing in such cases.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13827) Manual IIOP/CORBA stub generation fails on IBM JDK when running the Galleon Layers testsuite
by Yeray Borges Santana (Jira)
Yeray Borges Santana created WFLY-13827:
-------------------------------------------
Summary: Manual IIOP/CORBA stub generation fails on IBM JDK when running the Galleon Layers testsuite
Key: WFLY-13827
URL: https://issues.redhat.com/browse/WFLY-13827
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 20.0.1.Final
Reporter: Yeray Borges Santana
Assignee: Yeray Borges Santana
The Galleon Layers basic integration test suite fails on IBM JDK with the following error:
{noformat}
[INFO] --- exec-maven-plugin:1.6.0:exec (ibmjdk.iiop.stub-creation) @ wildfly-ts-integ-basic ---
error: Class javax.ejb.EJBHome not found in interface org.jboss.as.test.integration.ejb.iiop.naming.IIOPStatefulNamingHome.
error: Class javax.ejb.EJBHome not found.
error: Class javax.ejb.EJBHome not found in interface org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingHome.
error: Class javax.ejb.EJBHome not found.
4 errors
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
at org.apache.commons.exec.DefaultExecutor.executeInternal (DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute (DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:804)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:751)
at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:313)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
{noformat}
The reason is the ibmjdk.profile is activated independently if we are generating a slimmer server by using Galleon layers, failing in such cases.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13793) Attribute enable-amq1-prefix doesn't work (remote artemis)
by Nicolas De Amicis (Jira)
[ https://issues.redhat.com/browse/WFLY-13793?page=com.atlassian.jira.plugi... ]
Nicolas De Amicis commented on WFLY-13793:
------------------------------------------
I located the problem in wildfly-messaging-activemq lib:
* org.wildfly.extension.messaging.activemq.jms.ExternalJMSQueueService line 54, a prefix "jms.queue." is always added to the queue name
* org.wildfly.extension.messaging.activemq.jms.ExternalJMSTopicService line 55, a prefix "jms.topic." is always added to the topic name
I think a new attribute should be define for <external-jms-queue /> and <external-jms-topic /> like enable-amq1-prefix to append or not the prefix?
What do you think?
> Attribute enable-amq1-prefix doesn't work (remote artemis)
> ----------------------------------------------------------
>
> Key: WFLY-13793
> URL: https://issues.redhat.com/browse/WFLY-13793
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Management
> Affects Versions: 20.0.1.Final
> Reporter: Nicolas De Amicis
> Assignee: Chao Wang
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> I need to connect Wildfly 17.0.1 to a remote Artemis server. I follow the doc here: [https://docs.wildfly.org/17/Admin_Guide.html#Messaging_Connect_a_pooled-c...] No problem for point 1 to 3. But when I follow the instruction for disabling the compatibility mode (enable-amq1-prefix) I have this error:
> {quote}{{[standalone@localhost:9990 /] /subsystem=messaging-activemq/pooled-connection-factory=remote-artemis:write-attribute(name="enable-amq1-prefix", value="false")}}
> \{{{}}
> \{{ "outcome" => "failed",}}
> \{{ "failure-description" => "WFLYCTL0248: Invalid value false for enable-amq1-prefix; legal values are [XA_GENERIC, GENERIC, XA_T}}
> {{OPIC, TOPIC, QUEUE, XA_QUEUE]",}}
> \{{ "rolled-back" => true}}
> {{}}}
> {quote}
> If I deploy my MDB that connects to queue myqueue, I see in artemis console my MDB is connected to jms.queue.myqueue.
> I also tried to add the attribute manually but it seems it doesn't work:
> {quote}{{<pooled-connection-factory name="remote-artemis" entries="java:/}}{{jms/remoteCF}}{{" connectors="remote-artemis" enable-amq1-prefix="false"/>}}
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[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)
4 years, 3 months
[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)
4 years, 3 months
[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)
4 years, 3 months
[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)
4 years, 3 months