[JBoss JIRA] (WFLY-10783) ChannelServiceConfigurator failed to open a port while deploying kitchenskink qs on migrated server
by Petr Kremensky (JIRA)
Petr Kremensky created WFLY-10783:
-------------------------------------
Summary: ChannelServiceConfigurator failed to open a port while deploying kitchenskink qs on migrated server
Key: WFLY-10783
URL: https://issues.jboss.org/browse/WFLY-10783
Project: WildFly
Issue Type: Bug
Components: Clustering, Migration
Reporter: Petr Kremensky
Assignee: Paul Ferraro
Priority: Blocker
Attachments: jboss-kitchensink.war
Trying to deploy kitchensink quickstart on the server with configuration migrated from EAP 6.4.x fails with {{java.lang.IllegalStateException: java.lang.Exception: failed to open a port in range 55200-55200}}.
*Reproduce*
{noformat}
WORKSPACE=`pwd`
CONFIG=standalone-ha.xml
unzip -q jboss-eap-6.4.20.zip
cp -r ${WILDFLY}/dist/target/wildfly-14.0.0.Beta2-SNAPSHOT wildfly
SOURCE_HOME=${WORKSPACE}/jboss-eap-6.4
TARGET_HOME=${WORKSPACE}/wildfly
cp ${SOURCE_HOME}/standalone/configuration/${CONFIG} ${TARGET_HOME}/standalone/configuration
${TARGET_HOME}/bin/standalone.sh -c ${CONFIG} --start-mode=admin-only &
${TARGET_HOME}/bin/jboss-cli.sh --connect --controller=remote://localhost:9999
# Migrate
/subsystem=web:migrate
/subsystem=threads:remove
/extension=org.jboss.as.threads:remove
reload
deploy jboss-kitchensink.war
{noformat}
*Outcome*
{noformat}
14:44:13,799 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 56) MSC000001: Failed to start service org.wildfly.clustering.jgroups.channel.ee-ejb: org.jboss.msc.service.StartException in service org.wildfly.clustering.jgroups.channel.ee-ejb: java.lang.IllegalStateException: java.lang.Exception: failed to open a port in range 55200-55200
at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:70) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$start$0(AsyncServiceConfigurator.java:117) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
Caused by: java.lang.IllegalStateException: java.lang.Exception: failed to open a port in range 55200-55200
at org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.get(ChannelServiceConfigurator.java:116)
at org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.get(ChannelServiceConfigurator.java:58)
at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:67) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
... 7 more
Caused by: java.lang.Exception: failed to open a port in range 55200-55200
at org.jgroups.protocols.UDP.createMulticastSocketWithBindPort(UDP.java:519)
at org.jgroups.protocols.UDP.createSockets(UDP.java:357)
at org.jgroups.protocols.UDP.start(UDP.java:300)
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:861)
at org.jgroups.JChannel.startStack(JChannel.java:1023)
at org.jgroups.JChannel._preConnect(JChannel.java:886)
at org.jgroups.JChannel.connect(JChannel.java:390)
at org.jgroups.JChannel.connect(JChannel.java:384)
at org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.get(ChannelServiceConfigurator.java:112)
... 9 more
{noformat}
This works fine with EAP 7.1.3 as a TARGET_SERVER, thus marking as a blocker due to a regression.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10781) Jackson Annotations are broken
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-10781?page=com.atlassian.jira.plugin... ]
Marek Kopecký commented on WFLY-10781:
--------------------------------------
[~maio290] (cc: [~asoldano]): Can you please test this on WildFly prepared from master github branch? Some fixes of JSON were made after WF13 release, so these fixes were not released yet (RESTEASY-1911, [doc|https://github.com/resteasy/Resteasy/commit/f6ddef5accb88d924e3d14ab1...]).
I'm able to reproduce your issue on WF13, but not on WF prepared from current WF master branch.
> Jackson Annotations are broken
> ------------------------------
>
> Key: WFLY-10781
> URL: https://issues.jboss.org/browse/WFLY-10781
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 13.0.0.Final
> Environment: Windows 10 x64, WildFly 12 & 13
> Reporter: Mario-Luca Hoffmann
> Assignee: Alessio Soldano
> Labels: jackson
>
> With the switch from WildFly 12 to 13 our Jackson Annotations stopped working properly. While some of these are working (@JsonProperty) sometimes, others (@JsonIgnore) aren't working anymore. With WildFly 12 everything is fine, this issue only arises using WildFly 13 using a EE8 profile.
> However, I tried it with a pristine WildFly 13: not working, WildFly 12: works like a charme. I tried to fix it with replacing the jackson-databind library with the newest version (2.9.6) but this didn't work as well.
> Example for the attached Github Project:
> The expected output is: {"name":"Mario","attribute":"notWorking"}
> The acutal output is: {"attribute":"notWorking","name":"Mario","number":-1337}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2823) FEEL Parser: `not` breaks with `list contains`
by Edoardo Vacchi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2823?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi updated DROOLS-2823:
-----------------------------------
Story Points: 5
> FEEL Parser: `not` breaks with `list contains`
> -----------------------------------------------
>
> Key: DROOLS-2823
> URL: https://issues.jboss.org/browse/DROOLS-2823
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Edoardo Vacchi
> Assignee: Edoardo Vacchi
> Labels: Stunner
>
> *list contains([1,2,3,4,5,6], 3)* returns true
> *not(list contains([1,2,3,4,5,6], 3))* returns “list contains([1,2,3,4,5,6], 3)”, it should return false
> Most likely related to an issue with the parse tree branches
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2823) FEEL Parser: `not` breaks with `list contains`
by Edoardo Vacchi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2823?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi updated DROOLS-2823:
-----------------------------------
Sprint: 2018 Week 30-32
> FEEL Parser: `not` breaks with `list contains`
> -----------------------------------------------
>
> Key: DROOLS-2823
> URL: https://issues.jboss.org/browse/DROOLS-2823
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Edoardo Vacchi
> Assignee: Edoardo Vacchi
> Labels: Stunner
>
> *list contains([1,2,3,4,5,6], 3)* returns true
> *not(list contains([1,2,3,4,5,6], 3))* returns “list contains([1,2,3,4,5,6], 3)”, it should return false
> Most likely related to an issue with the parse tree branches
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2823) FEEL Parser: `not` breaks with `list contains`
by Edoardo Vacchi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2823?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi updated DROOLS-2823:
-----------------------------------
Labels: Stunner (was: )
> FEEL Parser: `not` breaks with `list contains`
> -----------------------------------------------
>
> Key: DROOLS-2823
> URL: https://issues.jboss.org/browse/DROOLS-2823
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Edoardo Vacchi
> Assignee: Edoardo Vacchi
> Labels: Stunner
>
> *list contains([1,2,3,4,5,6], 3)* returns true
> *not(list contains([1,2,3,4,5,6], 3))* returns “list contains([1,2,3,4,5,6], 3)”, it should return false
> Most likely related to an issue with the parse tree branches
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1621) BC FIPS with CLI: the trustAnchors parameter must be non-empty
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1621?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on ELY-1621:
---------------------------------------
Maybe this should be kept open we can double check, the server side code for trust manager initialisation is different to the client code so maybe there is a difference we can still handle.
> BC FIPS with CLI: the trustAnchors parameter must be non-empty
> --------------------------------------------------------------
>
> Key: ELY-1621
> URL: https://issues.jboss.org/browse/ELY-1621
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.5.1.Final
> Reporter: Martin Choma
> Priority: Blocker
> Attachments: cli-test-wildfly-config.xml, jboss-cli.log, keystore.bcfks
>
>
> I am trying to connect from jboss-cli.sh to EAP server. To reproduce the problem it is enough BC FIPS is used only on client side.
> {code:java|titlejboss-cli.log}
> 08:13:18,469 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: java.lang.ExceptionInInitializerError
> at org.wildfly.security.auth.client.AuthenticationContext.lambda$static$0(AuthenticationContext.java:54)
> at org.wildfly.common.context.ContextManager.getPrivileged(ContextManager.java:286)
> at org.wildfly.security.auth.client.AuthenticationContext.captureCurrent(AuthenticationContext.java:86)
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:146)
> at org.jboss.as.cli.impl.ModelControllerClientFactory$2.getClient(ModelControllerClientFactory.java:85)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1222)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:291)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> Caused by: org.wildfly.security.auth.client.InvalidAuthenticationConfigurationException: org.wildfly.client.config.ConfigXMLParseException: java.security.KeyStoreException: initialization failed
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:40)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.<clinit>(DefaultAuthenticationContextProvider.java:36)
> ... 14 more
> Caused by: org.wildfly.client.config.ConfigXMLParseException: java.security.KeyStoreException: initialization failed
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextType$10(ElytronXmlParser.java:525)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextRuleType$11(ElytronXmlParser.java:711)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$13(ElytronXmlParser.java:749)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:356)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:231)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:192)
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:38)
> ... 16 more
> Caused by: java.security.KeyStoreException: initialization failed
> at org.bouncycastle.jsse.provider.ProvTrustManagerFactorySpi.engineInit(ProvTrustManagerFactorySpi.java:150)
> at javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:250)
> at org.wildfly.security.auth.client.ElytronXmlParser$TrustManagerBuilder.build(ElytronXmlParser.java:590)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextType$10(ElytronXmlParser.java:523)
> ... 22 more
> Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
> at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
> at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:120)
> at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:104)
> at org.bouncycastle.jsse.provider.ProvX509TrustManagerImpl.<init>(ProvX509TrustManagerImpl.java:53)
> at org.bouncycastle.jsse.provider.ProvTrustManagerFactorySpi.engineInit(ProvTrustManagerFactorySpi.java:146)
> ... 25 more
> {code}
> When I use non-FIPS java with CLI I can make it work. It does occure also when connecting to default unsecured port 9990.
> I have double check truststore is there. Correct password is used. Server has permission to open the truststure. And truststore contains certificate
> When I use BCFKS truststore on server side, e.g. in 2-way http communication it works.
> So it looks to me something on client side is missing? Any hint?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1621) BC FIPS with CLI: the trustAnchors parameter must be non-empty
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1621?page=com.atlassian.jira.plugin.s... ]
Martin Choma commented on ELY-1621:
-----------------------------------
But still I dont understand why this problem pops up only on client side. Does server side / client side truststore implementation differs? [~fjuma] any idea?
> BC FIPS with CLI: the trustAnchors parameter must be non-empty
> --------------------------------------------------------------
>
> Key: ELY-1621
> URL: https://issues.jboss.org/browse/ELY-1621
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.5.1.Final
> Reporter: Martin Choma
> Priority: Blocker
> Attachments: cli-test-wildfly-config.xml, jboss-cli.log, keystore.bcfks
>
>
> I am trying to connect from jboss-cli.sh to EAP server. To reproduce the problem it is enough BC FIPS is used only on client side.
> {code:java|titlejboss-cli.log}
> 08:13:18,469 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: java.lang.ExceptionInInitializerError
> at org.wildfly.security.auth.client.AuthenticationContext.lambda$static$0(AuthenticationContext.java:54)
> at org.wildfly.common.context.ContextManager.getPrivileged(ContextManager.java:286)
> at org.wildfly.security.auth.client.AuthenticationContext.captureCurrent(AuthenticationContext.java:86)
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:146)
> at org.jboss.as.cli.impl.ModelControllerClientFactory$2.getClient(ModelControllerClientFactory.java:85)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1222)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:291)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> Caused by: org.wildfly.security.auth.client.InvalidAuthenticationConfigurationException: org.wildfly.client.config.ConfigXMLParseException: java.security.KeyStoreException: initialization failed
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:40)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.<clinit>(DefaultAuthenticationContextProvider.java:36)
> ... 14 more
> Caused by: org.wildfly.client.config.ConfigXMLParseException: java.security.KeyStoreException: initialization failed
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextType$10(ElytronXmlParser.java:525)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextRuleType$11(ElytronXmlParser.java:711)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$13(ElytronXmlParser.java:749)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:356)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:231)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:192)
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:38)
> ... 16 more
> Caused by: java.security.KeyStoreException: initialization failed
> at org.bouncycastle.jsse.provider.ProvTrustManagerFactorySpi.engineInit(ProvTrustManagerFactorySpi.java:150)
> at javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:250)
> at org.wildfly.security.auth.client.ElytronXmlParser$TrustManagerBuilder.build(ElytronXmlParser.java:590)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextType$10(ElytronXmlParser.java:523)
> ... 22 more
> Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
> at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
> at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:120)
> at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:104)
> at org.bouncycastle.jsse.provider.ProvX509TrustManagerImpl.<init>(ProvX509TrustManagerImpl.java:53)
> at org.bouncycastle.jsse.provider.ProvTrustManagerFactorySpi.engineInit(ProvTrustManagerFactorySpi.java:146)
> ... 25 more
> {code}
> When I use non-FIPS java with CLI I can make it work. It does occure also when connecting to default unsecured port 9990.
> I have double check truststore is there. Correct password is used. Server has permission to open the truststure. And truststore contains certificate
> When I use BCFKS truststore on server side, e.g. in 2-way http communication it works.
> So it looks to me something on client side is missing? Any hint?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1621) BC FIPS with CLI: the trustAnchors parameter must be non-empty
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1621?page=com.atlassian.jira.plugin.s... ]
Martin Choma commented on ELY-1621:
-----------------------------------
[~dlofthouse] My idea is to have issues filled, even I am not 100% sure if it is a bug (like in this case). Just to spread knowledge, discuss, track, help for future users troubelshouting. I will link interesting issues under RFE. Then with documentation team we can pick up interesting information to rise into documentation.
> BC FIPS with CLI: the trustAnchors parameter must be non-empty
> --------------------------------------------------------------
>
> Key: ELY-1621
> URL: https://issues.jboss.org/browse/ELY-1621
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.5.1.Final
> Reporter: Martin Choma
> Priority: Blocker
> Attachments: cli-test-wildfly-config.xml, jboss-cli.log, keystore.bcfks
>
>
> I am trying to connect from jboss-cli.sh to EAP server. To reproduce the problem it is enough BC FIPS is used only on client side.
> {code:java|titlejboss-cli.log}
> 08:13:18,469 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: java.lang.ExceptionInInitializerError
> at org.wildfly.security.auth.client.AuthenticationContext.lambda$static$0(AuthenticationContext.java:54)
> at org.wildfly.common.context.ContextManager.getPrivileged(ContextManager.java:286)
> at org.wildfly.security.auth.client.AuthenticationContext.captureCurrent(AuthenticationContext.java:86)
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:146)
> at org.jboss.as.cli.impl.ModelControllerClientFactory$2.getClient(ModelControllerClientFactory.java:85)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1222)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:291)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> Caused by: org.wildfly.security.auth.client.InvalidAuthenticationConfigurationException: org.wildfly.client.config.ConfigXMLParseException: java.security.KeyStoreException: initialization failed
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:40)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.<clinit>(DefaultAuthenticationContextProvider.java:36)
> ... 14 more
> Caused by: org.wildfly.client.config.ConfigXMLParseException: java.security.KeyStoreException: initialization failed
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextType$10(ElytronXmlParser.java:525)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextRuleType$11(ElytronXmlParser.java:711)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$13(ElytronXmlParser.java:749)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:356)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:231)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:192)
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:38)
> ... 16 more
> Caused by: java.security.KeyStoreException: initialization failed
> at org.bouncycastle.jsse.provider.ProvTrustManagerFactorySpi.engineInit(ProvTrustManagerFactorySpi.java:150)
> at javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:250)
> at org.wildfly.security.auth.client.ElytronXmlParser$TrustManagerBuilder.build(ElytronXmlParser.java:590)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextType$10(ElytronXmlParser.java:523)
> ... 22 more
> Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
> at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
> at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:120)
> at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:104)
> at org.bouncycastle.jsse.provider.ProvX509TrustManagerImpl.<init>(ProvX509TrustManagerImpl.java:53)
> at org.bouncycastle.jsse.provider.ProvTrustManagerFactorySpi.engineInit(ProvTrustManagerFactorySpi.java:146)
> ... 25 more
> {code}
> When I use non-FIPS java with CLI I can make it work. It does occure also when connecting to default unsecured port 9990.
> I have double check truststore is there. Correct password is used. Server has permission to open the truststure. And truststore contains certificate
> When I use BCFKS truststore on server side, e.g. in 2-way http communication it works.
> So it looks to me something on client side is missing? Any hint?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-78) Journal compacting doesn't work with JDK 11
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFWIP-78?page=com.atlassian.jira.plugin.s... ]
Martin Styk updated WFWIP-78:
-----------------------------
Description:
Journal compacting doesn't work with Artemis 1.5 and JDK 11
It fails with following stack trace:
{noformat}
12:34:58,017 ERROR [org.apache.activemq.artemis.journal] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$4@5483fda8)) AMQ144003: Error compacting: java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at io.netty@4.1.25.Final//io.netty.util.internal.CleanerJava9.freeDirectBuffer(CleanerJava9.java:77)
at io.netty@4.1.25.Final//io.netty.util.internal.PlatformDependent.freeDirectBuffer(PlatformDependent.java:388)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.releaseBuffer(NIOSequentialFileFactory.java:175)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.doInternalWrite(NIOSequentialFile.java:312)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:282)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:255)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.AbstractJournalUpdateTask.flush(AbstractJournalUpdateTask.java:217)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.compact(JournalImpl.java:1520)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl$14.run(JournalImpl.java:2060)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.IllegalArgumentException: duplicate or slice
at jdk.unsupported/sun.misc.Unsafe.invokeCleaner(Unsafe.java:1238)
{noformat}
This causes issues also in scenario with journal replication.
{noformat}
13:09:32,133 WARN [org.apache.activemq.artemis.core.server] (Thread-173) AMQ222013: Error when trying to start replication: java.lang.RuntimeException: Error during compact, look at the logs
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.scheduleCompactAndBlock(JournalImpl.java:1428)
at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.startReplication(JournalStorageManager.java:540)
at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation$2.run(SharedNothingLiveActivation.java:166)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
was:
Journal compacting doesn't work with Artemis 1.5 and JDK 11
It fails with following stack trace:
{noformat}
12:34:58,017 ERROR [org.apache.activemq.artemis.journal] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$4@5483fda8)) AMQ144003: Error compacting: java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at io.netty@4.1.25.Final//io.netty.util.internal.CleanerJava9.freeDirectBuffer(CleanerJava9.java:77)
at io.netty@4.1.25.Final//io.netty.util.internal.PlatformDependent.freeDirectBuffer(PlatformDependent.java:388)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.releaseBuffer(NIOSequentialFileFactory.java:175)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.doInternalWrite(NIOSequentialFile.java:312)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:282)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:255)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.AbstractJournalUpdateTask.flush(AbstractJournalUpdateTask.java:217)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.compact(JournalImpl.java:1520)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl$14.run(JournalImpl.java:2060)
at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.IllegalArgumentException: duplicate or slice
at jdk.unsupported/sun.misc.Unsafe.invokeCleaner(Unsafe.java:1238)
{noformat}
> Journal compacting doesn't work with JDK 11
> -------------------------------------------
>
> Key: WFWIP-78
> URL: https://issues.jboss.org/browse/WFWIP-78
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Environment: {noformat}
> java 11-ea 2018-09-25
> Java(TM) SE Runtime Environment 18.9 (build 11-ea+21)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {noformat}
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Critical
> Labels: jdk11
>
> Journal compacting doesn't work with Artemis 1.5 and JDK 11
> It fails with following stack trace:
> {noformat}
> 12:34:58,017 ERROR [org.apache.activemq.artemis.journal] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$4@5483fda8)) AMQ144003: Error compacting: java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at io.netty@4.1.25.Final//io.netty.util.internal.CleanerJava9.freeDirectBuffer(CleanerJava9.java:77)
> at io.netty@4.1.25.Final//io.netty.util.internal.PlatformDependent.freeDirectBuffer(PlatformDependent.java:388)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.releaseBuffer(NIOSequentialFileFactory.java:175)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.doInternalWrite(NIOSequentialFile.java:312)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:282)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:255)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.AbstractJournalUpdateTask.flush(AbstractJournalUpdateTask.java:217)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.compact(JournalImpl.java:1520)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl$14.run(JournalImpl.java:2060)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalArgumentException: duplicate or slice
> at jdk.unsupported/sun.misc.Unsafe.invokeCleaner(Unsafe.java:1238)
> {noformat}
> This causes issues also in scenario with journal replication.
> {noformat}
> 13:09:32,133 WARN [org.apache.activemq.artemis.core.server] (Thread-173) AMQ222013: Error when trying to start replication: java.lang.RuntimeException: Error during compact, look at the logs
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.scheduleCompactAndBlock(JournalImpl.java:1428)
> at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.startReplication(JournalStorageManager.java:540)
> at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation$2.run(SharedNothingLiveActivation.java:166)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1622) BC FIPS with CLI: SunX509 KeyManagerFactory not available
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1622?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1622:
------------------------------
Workaround Description: set {{ssl.KeyManagerFactory.algorithm=X509}} in java.security file
Workaround: Workaround Exists
> BC FIPS with CLI: SunX509 KeyManagerFactory not available
> ---------------------------------------------------------
>
> Key: ELY-1622
> URL: https://issues.jboss.org/browse/ELY-1622
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.5.1.Final
> Reporter: Martin Choma
> Priority: Blocker
> Attachments: cli-test-wildfly-config.xml, jboss-cli.log, truststore.bcfks
>
>
> I am trying to connect from jboss-cli.sh to EAP server. To reproduce the problem it is enough BC FIPS is used only on client side.
> {code:java|titlejboss-cli.log}
> 11:50:25,147 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:330)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:291)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> Caused by: org.jboss.as.cli.CommandLineException: Failed to resolve host 'localhost'
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1256)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328)
> ... 5 more
> Caused by: java.io.IOException: Failed to obtain SSLContext
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:156)
> at org.jboss.as.cli.impl.ModelControllerClientFactory$2.getClient(ModelControllerClientFactory.java:85)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1222)
> ... 8 more
> Caused by: java.security.KeyManagementException: java.security.NoSuchAlgorithmException: SunX509 KeyManagerFactory not available
> at org.bouncycastle.jsse.provider.ProvSSLContextSpi.selectKeyManager(ProvSSLContextSpi.java:589)
> at org.bouncycastle.jsse.provider.ProvSSLContextSpi.engineInit(ProvSSLContextSpi.java:531)
> at javax.net.ssl.SSLContext.init(SSLContext.java:282)
> at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:221)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:208)
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:153)
> ... 10 more
> Caused by: java.security.NoSuchAlgorithmException: SunX509 KeyManagerFactory not available
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
> at javax.net.ssl.KeyManagerFactory.getInstance(KeyManagerFactory.java:137)
> at org.bouncycastle.jsse.provider.ProvSSLContextSpi.selectKeyManager(ProvSSLContextSpi.java:583)
> ... 17 more
> {code}
> When I use non-FIPS java with CLI I can make it work. It does occure also when connecting to default unsecured port 9990.
> When I use BCFKS truststore on server side, e.g. in 2-way http communication it works.
> I believe problem is I cant configure algorithm for keymanager on client side in wildfly-config.xml. (At least I don't see how could I do so).
> BC provider does not know SunX509 arlgorithm, rather X509, X.509 or PKIX could be used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months