September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9372) NullpointerException in artemis-server-1.1.0.wildfly-017 (and artemis-server-1.5.5.jbossorg-007.jar) when using MQTT

by Thomas Houtekier (JIRA)

Thomas Houtekier created WFLY-9372: -------------------------------------- Summary: NullpointerException in artemis-server-1.1.0.wildfly-017 (and artemis-server-1.5.5.jbossorg-007.jar) when using MQTT Key: WFLY-9372 URL: https://issues.jboss.org/browse/WFLY-9372 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.1.0.Final Environment: java8 Reporter: Thomas Houtekier Assignee: Jeff Mesnil Attachments: screenshot.png, server.log, standalone-full-ha.xml When connecting a MQTT-client to a wildfly-10.1.0.Final (with embedded artemis 1.1.0), the following NPE is thrown. {code} Sep:12,15:57:48,464 WARNING (:Thread-2 (activemq-netty-threads-345981593):) [io.netty.channel.DefaultChannelPipeline] An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.: io.netty.handler.codec.DecoderException: java.lang.NullPointerException at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:391) [netty-all-4.0.33.Final.jar:4.0.33.Final] at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:311) [netty-all-4.0.33.Final.jar:4.0.33.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:218) [netty-all-4.0.33.Final.jar:4.0.33.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:204) [netty-all-4.0.33.Final.jar:4.0.33.Final] at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:828) [netty-all-4.0.33.Final.jar:4.0.33.Final] at io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:625) [netty-all-4.0.33.Final.jar:4.0.33.Final] at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358) [netty-all-4.0.33.Final.jar:4.0.33.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357) [netty-all-4.0.33.Final.jar:4.0.33.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) [netty-all-4.0.33.Final.jar:4.0.33.Final] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_112] Caused by: java.lang.NullPointerException at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:171) [artemis-server-1.1.0.wildfly-017.jar:] at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:360) [netty-all-4.0.33.Final.jar:4.0.33.Final] ... 9 more {code} for more info, see https://developer.jboss.org/message/976007 Reproducing in straightforward, see 'steps to reproduce'. I'm not sure if this is related to the integration of artemis into wildfly, or to the artemis server itself. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9371) Fix failing RemoteEJBTwoClusterTestCase

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-9371: ------------------------------------ Summary: Fix failing RemoteEJBTwoClusterTestCase Key: WFLY-9371 URL: https://issues.jboss.org/browse/WFLY-9371 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar The problem is that this test is not run as part of regular CI execution thus is destined to be broken. The test should be run as part of regular CI set of tests; if intermittently failing then it should be @Ignore-d in the way intermittently failing tests are. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-175) Do not use the StandardOutputStreams for the ConsoleHandler

by James Perkins (JIRA)

James Perkins created LOGMGR-175: ------------------------------------ Summary: Do not use the StandardOutputStreams for the ConsoleHandler Key: LOGMGR-175 URL: https://issues.jboss.org/browse/LOGMGR-175 Project: JBoss Log Manager Issue Type: Bug Reporter: James Perkins Assignee: James Perkins The {{ConsoleHandler}} was changed to use the {{StandardOutputStreams.stdout}} and {{StandardOutputStreams.stderr}} streams. The {{StandardOutputStreams}} are initiated early to ensure that stdout and stderr are captured. However the {{ConsoleHandler}} may need an overridden stdout and/or stderr. A specific use case is the embedded server in WildFly. For the reasons above we should revert the changes on the {{ConsoleHandler}}. The standard output streams should only be captured after the {{ConsoleHandler}} is initialized. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3313) Upgrade jboss-logmanager from 2.1.0.Alpha4 to 2.1.0.Alpha5

by James Perkins (JIRA)

James Perkins created WFCORE-3313: ------------------------------------- Summary: Upgrade jboss-logmanager from 2.1.0.Alpha4 to 2.1.0.Alpha5 Key: WFCORE-3313 URL: https://issues.jboss.org/browse/WFCORE-3313 Project: WildFly Core Issue Type: Component Upgrade Components: Logging Reporter: James Perkins Assignee: James Perkins -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9370) Fix failing SingletonTunnelTestCase(ASYNC-tunnel)#testSingletonService

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-9370: ------------------------------------ Summary: Fix failing SingletonTunnelTestCase(ASYNC-tunnel)#testSingletonService Key: WFLY-9370 URL: https://issues.jboss.org/browse/WFLY-9370 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 11.0.0.CR1 Reporter: Radoslav Husar Assignee: Radoslav Husar The problem is that this test is not run as part of regular CI execution thus is destined to be broken. The test should be moved to the right location and renamed (i.e. drop tunnel since that has nothing to do with what it is testing). {noformat} &amp#27;[0m&amp#27;[31m04:44:19,235 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "singleton.war")]) - failure description: { "WFLYCTL0412: Required services that are not installed:" => ["jboss.clustering.group.default"], "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "jboss.test1.service.default is missing [jboss.clustering.group.default]", "jboss.test2.service.default is missing [jboss.clustering.group.default]" ], "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => { "Services that were unable to start:" => [ "jboss.deployment.discovery.\"singleton.war\"", "jboss.deployment.unit.\"singleton.war\".CdiValidatorFactoryService", "jboss.deployment.unit.\"singleton.war\".WeldStartService", "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.JndiBindingsService", "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.START", "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.VIEW.\"org.jboss.as.test.clustering.TopologyChangeListener\".REMOTE", "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.WeldInstantiator", "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.WeldInterceptorBindingsService", "jboss.deployment.unit.\"singleton.war\".component.\"com.sun.faces.config.ConfigureListener\".START", "jboss.deployment.unit.\"singleton.war\".component.\"com.sun.faces.config.ConfigureListener\".WeldInstantiator", "jboss.deployment.unit.\"singleton.war\".component.\"javax.faces.webapp.FacetTag\".START", "jboss.deployment.unit.\"singleton.war\".component.\"javax.faces.webapp.FacetTag\".WeldInstantiator", "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".START", "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".WeldInstantiator", "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".START", "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".WeldInstantiator", "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.TopologyChangeListenerServlet\".START", "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.TopologyChangeListenerServlet\".WeldInstantiator", "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.NodeServiceServlet\".START", "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.NodeServiceServlet\".WeldInstantiator", "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.ValueServiceServlet\".START", "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.ValueServiceServlet\".WeldInstantiator", "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".START", "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".WeldInstantiator", "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".START", "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".WeldInstantiator", "jboss.deployment.unit.\"singleton.war\".deploymentCompleteService", "jboss.deployment.unit.\"singleton.war\".ejb3.client-context.registration-service", "jboss.deployment.unit.\"singleton.war\".jndiDependencyService", "jboss.deployment.unit.\"singleton.war\".moduleDeploymentRuntimeInformation", "jboss.deployment.unit.\"singleton.war\".moduleDeploymentRuntimeInformationStart", "jboss.naming.context.java.app.singleton.singleton.TopologyChangeListenerBean", "jboss.naming.context.java.app.singleton.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"", "jboss.naming.context.java.global.singleton.TopologyChangeListenerBean", "jboss.naming.context.java.global.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"", "jboss.naming.context.java.module.singleton.singleton.TopologyChangeListenerBean", "jboss.naming.context.java.module.singleton.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"", "jboss.undertow.deployment.default-server.default-host./singleton", "jboss.undertow.deployment.default-server.default-host./singleton.UndertowDeploymentInfoService" ], "Services that may be the cause:" => [ "jboss.clustering.group.default", "org.wildfly.network.socket-binding.undefined" ] } } {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3311) embedded server --std-out=discard still causes log output to be shown

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3311?page=com.atlassian.jira.plugi... ] James Perkins reassigned WFCORE-3311: ------------------------------------- Assignee: James Perkins (was: Ken Wills) > embedded server --std-out=discard still causes log output to be shown > --------------------------------------------------------------------- > > Key: WFCORE-3311 > URL: https://issues.jboss.org/browse/WFCORE-3311 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: James Perkins > > [disconnected /] embed-server --std-out=discard > 10:27:43,671 INFO [org.jboss.modules] (CLI command executor) JBoss Modules version 1.6.1.Final > 10:27:43,698 INFO [org.jboss.as] (MSC service thread 2-8) WFLYSRV0049: WildFly Core 4.0.0.Alpha1-SNAPSHOT "Kenny" starting > ... etc -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3312) mechanism-configuration in http/sasl authentication factory in server configuration should fail when includes some attribute

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3312?page=com.atlassian.jira.plugi... ] Brian Stansberry closed WFCORE-3312. ------------------------------------ Resolution: Duplicate Issue I just cloned this from WFCORE-3310 to do some experimenting with how JIRA works. That's done some I'm closing. > mechanism-configuration in http/sasl authentication factory in server configuration should fail when includes some attribute > ---------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3312 > URL: https://issues.jboss.org/browse/WFCORE-3312 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.3.Final > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > > Based on wildfly-elytron XSD mechanism-configuration element of http-authentication-factory or sasl-authentication-factory should not contain any attribute. However when some attribute is added for this element in standalone.xml then it does not fail during server start. In correct behavior Validation error should be thrown during starting server. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3312) mechanism-configuration in http/sasl authentication factory in server configuration should fail when includes some attribute

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3312: ---------------------------------------- Summary: mechanism-configuration in http/sasl authentication factory in server configuration should fail when includes some attribute Key: WFCORE-3312 URL: https://issues.jboss.org/browse/WFCORE-3312 Project: WildFly Core Issue Type: Bug Components: Security Affects Versions: 3.0.3.Final Reporter: Ondrej Lukas Assignee: Ilia Vassilev Based on wildfly-elytron XSD mechanism-configuration element of http-authentication-factory or sasl-authentication-factory should not contain any attribute. However when some attribute is added for this element in standalone.xml then it does not fail during server start. In correct behavior Validation error should be thrown during starting server. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1369) FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1369?page=com.atlassian.jira.plugin.s... ] Jan Kalina edited comment on ELY-1369 at 9/21/17 11:58 AM: ----------------------------------------------------------- Hmm... reading too late, but algorithm adding is trivial change - most of PR is fix of hash for defined qop=auth discovered by new related test. was (Author: honza889): Hmm... reading too late, but algorithm adding is trivial change - most of PR is fix of hash for defined qop=auth (+test coverage). > FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant > -------------------------------------------------------------------------- > > Key: ELY-1369 > URL: https://issues.jboss.org/browse/ELY-1369 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.2.0.Beta3 > Reporter: Jan Kalina > Assignee: Jan Kalina > Labels: eap7.1.0-to-prd > > Elytron HTTP DIGEST authentication comply to rfc2617 - which means MD5 is used by default (it means it is hardcode, with no way to configure another hash algorithm). But MD5 could make troubles in fips environment [5]. > {code:java|title=DigestAuthenticationMechanism.java} > String algorithm = convertToken(ALGORITHM, responseTokens.get(ALGORITHM)); > if (MD5.equals(algorithm) == false) { > throw log.mechUnsupportedAlgorithm(getMechanismName(), algorithm); > } > {code} > There exists proposed rfc7616 which makes algorithm configurable, work on new DIGEST features are covered by [1]. [~dlofthouse] is it planned for [1] to target 7.1? > [1] https://issues.jboss.org/browse/ELY-286 > [2] https://developer.jboss.org/wiki/ElytronHTTPDigestNonceHandling-Design > [3] https://tools.ietf.org/html/rfc2617 > [4] https://tools.ietf.org/html/rfc7616 > [5] https://access.redhat.com/support/cases/#/case/01761455 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1369) FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1369?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1369: ---------------------------- Need Info from: (was: Darran Lofthouse) > FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant > -------------------------------------------------------------------------- > > Key: ELY-1369 > URL: https://issues.jboss.org/browse/ELY-1369 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.2.0.Beta3 > Reporter: Jan Kalina > Assignee: Jan Kalina > Labels: eap7.1.0-to-prd > > Elytron HTTP DIGEST authentication comply to rfc2617 - which means MD5 is used by default (it means it is hardcode, with no way to configure another hash algorithm). But MD5 could make troubles in fips environment [5]. > {code:java|title=DigestAuthenticationMechanism.java} > String algorithm = convertToken(ALGORITHM, responseTokens.get(ALGORITHM)); > if (MD5.equals(algorithm) == false) { > throw log.mechUnsupportedAlgorithm(getMechanismName(), algorithm); > } > {code} > There exists proposed rfc7616 which makes algorithm configurable, work on new DIGEST features are covered by [1]. [~dlofthouse] is it planned for [1] to target 7.1? > [1] https://issues.jboss.org/browse/ELY-286 > [2] https://developer.jboss.org/wiki/ElytronHTTPDigestNonceHandling-Design > [3] https://tools.ietf.org/html/rfc2617 > [4] https://tools.ietf.org/html/rfc7616 > [5] https://access.redhat.com/support/cases/#/case/01761455 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2017