February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2315) Remoting client from older WildFly can't authenticate against latest WildFly Core

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2315?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2315: ------------------------------------- Description: Using dependencies from older WildFly release, clients are unable to connect to latest WildFly using DIGEST-MD5 mechanism: {noformat} java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: DIGEST-MD5: Server rejected authentication {noformat} JBOSS-LOCAL-USER method works. I'm talking about latest WildFly with legacy security realms. We are supposed to maintain backward compatibility with older clients but in this case older client won't work against newer server. was: Using dependencies from EAP 7.0.0, clients are unable to connect to EAP 7.1.0.DR8 using DIGEST-MD5 mechanism: {noformat} java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: DIGEST-MD5: Server rejected authentication {noformat} JBOSS-LOCAL-USER method works. I'm talking about 7.1.0.DR8 with legacy security realms. We are supposed to maintain backward compatibility with older clients but in this case older client won't work against newer server. > Remoting client from older WildFly can't authenticate against latest WildFly Core > --------------------------------------------------------------------------------- > > Key: WFCORE-2315 > URL: https://issues.jboss.org/browse/WFCORE-2315 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Affects Versions: 3.0.0.Beta3 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Labels: authentication, eap71_alpha, regression, remoting, sasl > > Using dependencies from older WildFly release, clients are unable to connect to latest WildFly using DIGEST-MD5 mechanism: > {noformat} > java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: > DIGEST-MD5: Server rejected authentication > {noformat} > JBOSS-LOCAL-USER method works. I'm talking about latest WildFly with legacy security realms. > We are supposed to maintain backward compatibility with older clients but in this case older client won't work against newer server. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2315) Remoting client from older WildFly can't authenticate against latest WildFly Core

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2315?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2315: ------------------------------------- Summary: Remoting client from older WildFly can't authenticate against latest WildFly Core (was: Remoting client from EAP 7.0.0 can't authenticate against EAP 7.1.0.DR8) > Remoting client from older WildFly can't authenticate against latest WildFly Core > --------------------------------------------------------------------------------- > > Key: WFCORE-2315 > URL: https://issues.jboss.org/browse/WFCORE-2315 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Affects Versions: 3.0.0.Beta3 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Labels: authentication, eap71_alpha, regression, remoting, sasl > > Using dependencies from EAP 7.0.0, clients are unable to connect to EAP 7.1.0.DR8 using DIGEST-MD5 mechanism: > {noformat} > java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: > DIGEST-MD5: Server rejected authentication > {noformat} > JBOSS-LOCAL-USER method works. I'm talking about 7.1.0.DR8 with legacy security realms. > We are supposed to maintain backward compatibility with older clients but in this case older client won't work against newer server. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2315) Remoting client from EAP 7.0.0 can't authenticate against EAP 7.1.0.DR8

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2315?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved JBEAP-8995 to WFCORE-2315: ------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2315 (was: JBEAP-8995) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Remoting Security (was: EJB) (was: Remoting) (was: Security) Affects Version/s: 3.0.0.Beta3 (was: 7.1.0.DR8) Affects Testing: (was: Regression) > Remoting client from EAP 7.0.0 can't authenticate against EAP 7.1.0.DR8 > ----------------------------------------------------------------------- > > Key: WFCORE-2315 > URL: https://issues.jboss.org/browse/WFCORE-2315 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Affects Versions: 3.0.0.Beta3 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Labels: authentication, eap71_alpha, regression, remoting, sasl > > Using dependencies from EAP 7.0.0, clients are unable to connect to EAP 7.1.0.DR8 using DIGEST-MD5 mechanism: > {noformat} > java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: > DIGEST-MD5: Server rejected authentication > {noformat} > JBOSS-LOCAL-USER method works. I'm talking about 7.1.0.DR8 with legacy security realms. > We are supposed to maintain backward compatibility with older clients but in this case older client won't work against newer server. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-974) Digest uses property starting org.jboss convert to wildfly.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-974?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-974: --------------------------------- Summary: Digest uses property starting org.jboss convert to wildfly. (was: Digest uses some properties starting com.sun and org.jboss convert to wildfly.) > Digest uses property starting org.jboss convert to wildfly. > ----------------------------------------------------------- > > Key: ELY-974 > URL: https://issues.jboss.org/browse/ELY-974 > Project: WildFly Elytron > Issue Type: Enhancement > Components: SASL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta28 > > > Old properties should remain supported but deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-43) Hawkular Agent for EAP 6.4

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-43?page=com.atlassian.jira.plu... ] Hayk Hovsepyan resolved HAWKULARQE-43. -------------------------------------- Resolution: Done Manual smoke test of discovering EAP6 standalone sever is done. EAP6 domain mode is not supported. > Hawkular Agent for EAP 6.4 > -------------------------- > > Key: HAWKULARQE-43 > URL: https://issues.jboss.org/browse/HAWKULARQE-43 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > > Smoke test based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testr... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-43) Hawkular Agent for EAP 6.4

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-43?page=com.atlassian.jira.plu... ] Hayk Hovsepyan commented on HAWKULARQE-43: ------------------------------------------ Manual testcase execution is done https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testr... No regression is found. > Hawkular Agent for EAP 6.4 > -------------------------- > > Key: HAWKULARQE-43 > URL: https://issues.jboss.org/browse/HAWKULARQE-43 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > > Smoke test based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testr... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8175) mvnw wrapper shouldn't deppend on .m2/wrapper location

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/WFLY-8175?page=com.atlassian.jira.plugin.... ] Peter Palaga moved JBEAP-8985 to WFLY-8175: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8175 (was: JBEAP-8985) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Build System Test Suite (was: Build System) (was: Test Suite) Affects Version/s: (was: 7.1.0.DR12) Affects Testing: (was: Regression) > mvnw wrapper shouldn't deppend on .m2/wrapper location > ------------------------------------------------------ > > Key: WFLY-8175 > URL: https://issues.jboss.org/browse/WFLY-8175 > Project: WildFly > Issue Type: Bug > Components: Build System, Test Suite > Reporter: Peter Palaga > Assignee: Peter Palaga > Priority: Critical > > mvnw stores maven to ~/.m2/wrapper directory. But customers could have denied access to .m2 folder. They could have allowed access only to .m2/repository, because they want to protect settings.xml file. > Our mvnw script should download maven to project directory. > Possible solution could be adding these two lines to .mvn/wrapper/maven-wrapper.properties: > {noformat} > distributionBase=PROJECT > zipStoreBase=PROJECT > {noformat} > This issue is regression against EAP 7.0.0 and EAP 7.1.0.DR11. > FYI: unfortunately, [distributionBase|https://github.com/takari/maven-wrapper/blob/master/src/...] and [zipStoreBase|https://github.com/takari/maven-wrapper/blob/master/src/main...] properties are not documented. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-974) Digest uses some properties starting com.sun and org.jboss convert to wildfly.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-974: ------------------------------------ Summary: Digest uses some properties starting com.sun and org.jboss convert to wildfly. Key: ELY-974 URL: https://issues.jboss.org/browse/ELY-974 Project: WildFly Elytron Issue Type: Enhancement Components: SASL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta28 Old properties should remain supported but deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7352) XNIO bridge for Artemis doesn't work with newer versions of Netty and Artemis.

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-7352?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFLY-7352. ------------------------------- Fix Version/s: 11.0.0.Alpha1 Resolution: Done netty-xnio-transport has been upgrade to 0.1.2.Final and Netty to 4.1.5.Final > XNIO bridge for Artemis doesn't work with newer versions of Netty and Artemis. > ------------------------------------------------------------------------------ > > Key: WFLY-7352 > URL: https://issues.jboss.org/browse/WFLY-7352 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > > Test scenario: > 1. Start server EAP 7.1.0.DR6 (with Artemis 1.4.0) with queue InQueue and OutQueue. Configure non-exclusive divert from InQueue to OutQueue. > 2. Send large message to InQueue with scheduled delivery 10 seconds > 3. Start consumer on OutQueue with receive timeout 1000ms and check that NO message was received > 4. Start consumer on InQueue with receive timeout 1000ms and check that NO message was received > 5. Start consumer on InQueue with receive timeout 11000ms and check that message is received > 6. Start consumer on OutQueue with receive timeout 11000ms and check that message is received > Result: > Sometimes happens that consumer in step 3. receives a message. By checking trace logs, consumer in step 3. was receiving message 9664ms instead of ~1000ms. > In attachment is trace log from client and server and test log with client thread dump during ~10s receive. > Investigation: > In the moment when client tries to receive a message there is send SessionForceConsumerDelivery packet by client: > {code} > 15:07:07,589 Thread-11 INFO [org.jboss.qa.artemis.test.messages.JmsMessagesTestCase$ReceiveThread:474] Start message comsumption from original queue with receive timeout 1000ms > 15:07:07,590 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:386] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl@332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}:: receive(1000) > 15:07:07,590 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:191] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl@332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}::receive(1000, false) > 15:07:08,591 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:370] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl@332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}::Returning null > 15:07:08,591 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:392] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl@332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}:: receive(1000) -> null, trying again with receive(0) > 15:07:08,591 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:191] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl@332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}::receive(0, true) > 15:07:08,592 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:301] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl@332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}::Forcing delivery > 15:07:08,593 Thread-11 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl:248] Sending packet nonblocking PACKET(SessionForceConsumerDelivery)[type=78, channelID=11, packetObject=SessionForceConsumerDelivery, consumerID=0, sequence=0] on channeID=11 > 15:07:08,604 Thread-11 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl:286] Writing buffer for channelID=11 > {code} > Response from server comes ~10s later - it's packet SessionReceiveMessage: > {code} > 15:07:17,250 Thread-0 (ActiveMQ-client-netty-threads-1138697171) TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl:354] handling packet PACKET(SessionReceiveMessage)[type=75, chan > nelID=11, packetObject=SessionReceiveMessage, message=ClientMessageImpl[messageID=44, durable=false, address=jms.queue.OutQueue,userID=null,properties=TypedProperties[_hornetq.forced.delivery.seq=0]], consumerID > =0, deliveryCount=0] > {code} > in the mean time client is waiting on - ---org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:261): > {noformat} > wait(Long.MAX_VALUE); > {noformat} > and is waiting for notify. From server log I can see that SessionReceiveMessage was send at: > {code} > 15:07:08,621 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-18 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@39cb2b3a-1512482465)) Sending packet nonblocking PACKET(SessionReceiveMessage)[type=75, channelID=11, packetObject=SessionReceiveMessage, message=ServerMessage[messageID=44,durable=false,userID=null,priority=0, bodySize=50, timestamp=0,expiration=0, durable=false, address=jms.queue.OutQueue,properties=TypedProperties[_hornetq.forced.delivery.seq=0]]@1525441837, consumerID=0, deliveryCount=0] on channeID=11 > 15:07:08,633 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-18 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@39cb2b3a-1512482465)) Writing buffer for channelID=11 > {code} > but it wasn't flushed and for some reason is actually send ~10s later with the large message: > {code} > 15:07:17,236 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-27 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@39cb2b3a-1512482465)) Sending pa > cket nonblocking PACKET(SessionReceiveLargeMessage)[type=76, channelID=11, packetObject=SessionReceiveLargeMessage, consumerID=0, deliveryCount=1, largeMessageSize=409605, message=LargeServerMessage[messageID=40 > ,durable=true,userID=1befe4c2-920f-11e6-9ae8-3ca9f4349bfc,priority=4, timestamp=Fri Oct 14 15:07:07 CEST 2016,expiration=0, durable=true, address=jms.queue.OutQueue,properties=TypedProperties[__AMQ_CID=1bdc35af- > 920f-11e6-9ae8-3ca9f4349bfc,_AMQ_SCHED_DELIVERY=1476450437224,_AMQ_ORIG_ADDRESS=jms.queue.InQueue,_AMQ_ORIG_MESSAGE_ID=36,counter=0,_AMQ_DUPL_ID=16c2be09-573a-4e02-a369-6a36c2f32fbd,_AMQ_LARGE_SIZE=409605]]@1994 > 218683] on channeID=11 > 15:07:17,246 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-27 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@39cb2b3a-1512482465)) Writing bu > ffer for channelID=11 > 15:07:17,247 TRACE [org.xnio.nio.selector] (default I/O-1) Selected on sun.nio.ch.EPollSelectorImpl@61ea580a > 15:07:17,247 TRACE [org.xnio.nio] (default I/O-1) Running task io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask@5c93c5d7 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8174) broadcast-group capability must include the messaging server name

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-8174: --------------------------------- Summary: broadcast-group capability must include the messaging server name Key: WFLY-8174 URL: https://issues.jboss.org/browse/WFLY-8174 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.1.0.Final Reporter: Jeff Mesnil Assignee: Jeff Mesnil Capabilities registered by the messaging-server's broadcast-group resources are using the pattern: org.wildfly.messaging.activemq.broadcast-group.channel-factory.<broadcast-group name> This prevents having 2 broadcast-groups belonging to different ActiveMQ servers using the same name configured in the same profile. Instead, the ActiveMQ server name should be part of the capability name, e.g. org.wildfly.messaging.activemq.broadcast-group.channel-factory.<server name>.<broadcast-group name> -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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 February 2017