March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1005) Remote naming client from EAP 7.0 can't authenticate against EAP 7.1

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1005?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse moved JBEAP-9584 to ELY-1005: ---------------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1005 (was: JBEAP-9584) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: SASL (was: Naming) Affects Version/s: 1.1.0.Beta29 (was: 7.1.0.DR13) Affects Testing: (was: Regression) > Remote naming client from EAP 7.0 can't authenticate against EAP 7.1 > -------------------------------------------------------------------- > > Key: ELY-1005 > URL: https://issues.jboss.org/browse/ELY-1005 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.1.0.Beta29 > Reporter: Darran Lofthouse > Assignee: Stuart Douglas > Priority: Blocker > > When using the jboss-remote-naming library from EAP 7.0 against EAP 7.1.0.DR13 the client is unable to authenticate and all lookups time out ( {{java.net.ConnectException: Operation failed with status WAITING after 5000 MILLISECONDS}} ) > The exact same client code with the same dependencies works when running against EAP 7.1. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2540) Update JACC Version property name and version to match WildFly

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-2540: ---------------------------------------- Summary: Update JACC Version property name and version to match WildFly Key: WFCORE-2540 URL: https://issues.jboss.org/browse/WFCORE-2540 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta10 (The definition in WildFly can likely be removed as well) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8370) Changing global transaction timeout requires reload to be considered for MDB

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-8370?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka edited comment on WFLY-8370 at 3/15/17 5:35 AM: ---------------------------------------------------------------- Hi [~dmlloyd], I didn't want to assign this issue to me as you have a much clearer idea of how the fixes for WFTC should look like. But I have here a proposal that works for me https://github.com/ochaloup/wildfly/commit/b5622bd8aaf22459d1262de8b10289... (https://github.com/ochaloup/wildfly/tree/WFLY-8370-propagate-change-of-tx...) In general, it's just adding WFTC update at write handler in txn subsystem. If you are fine with such fix I can reassign this issue on me and process it. Thanks for help was (Author: ochaloup): Hi [~dmlloyd], I didn't want to assign this issue to me as you have a much clearer idea of how the fixes for WFTC should look like. But I have here a proposal that works for me https://github.com/ochaloup/wildfly/commit/b5622bd8aaf22459d1262de8b10289... (https://github.com/ochaloup/wildfly/tree/WFLY-8370-propagate-change-of-tx...) In general, it's just adding WFTC update at write handler in txn subsystem. If you are fine with such fix I can reassign this issue on me and process it. Thanks a lot for help > Changing global transaction timeout requires reload to be considered for MDB > ---------------------------------------------------------------------------- > > Key: WFLY-8370 > URL: https://issues.jboss.org/browse/WFLY-8370 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondra Chaloupka > Assignee: David Lloyd > > When default transaction timeout is redefined during the server lifetime > {code} > /subsystem=transactions:write-attribute(name=default-timeout, value=60) > {"outcome" => "success"} > {code} > such change is not propagated to WFTC and for example in case of MDB the default transaction timeout is being left as it was at time of container startup. The transaction timeout is considered after server is reloaded. But it's different behavior than it was and in general for transaction timeout redefinition should not be needed container reload. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8370) Changing global transaction timeout requires reload to be considered for MDB

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-8370?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka commented on WFLY-8370: --------------------------------------- Hi [~dmlloyd], I didn't want to assign this issue to me as you have much clearer idea of how the fixes for WFTC should look like. But I have here a proposal that works for me https://github.com/ochaloup/wildfly/commit/b5622bd8aaf22459d1262de8b10289... (https://github.com/ochaloup/wildfly/tree/WFLY-8370-propagate-change-of-tx...) In general it's just adding WFTC update at write handler in txn subsystem. If you are fine with such fix I can reassign this issue on me and process it. Thanks a lot for help > Changing global transaction timeout requires reload to be considered for MDB > ---------------------------------------------------------------------------- > > Key: WFLY-8370 > URL: https://issues.jboss.org/browse/WFLY-8370 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondra Chaloupka > Assignee: David Lloyd > > When default transaction timeout is redefined during the server lifetime > {code} > /subsystem=transactions:write-attribute(name=default-timeout, value=60) > {"outcome" => "success"} > {code} > such change is not propagated to WFTC and for example in case of MDB the default transaction timeout is being left as it was at time of container startup. The transaction timeout is considered after server is reloaded. But it's different behavior than it was and in general for transaction timeout redefinition should not be needed container reload. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8370) Changing global transaction timeout requires reload to be considered for MDB

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-8370?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka edited comment on WFLY-8370 at 3/15/17 5:09 AM: ---------------------------------------------------------------- Hi [~dmlloyd], I didn't want to assign this issue to me as you have a much clearer idea of how the fixes for WFTC should look like. But I have here a proposal that works for me https://github.com/ochaloup/wildfly/commit/b5622bd8aaf22459d1262de8b10289... (https://github.com/ochaloup/wildfly/tree/WFLY-8370-propagate-change-of-tx...) In general, it's just adding WFTC update at write handler in txn subsystem. If you are fine with such fix I can reassign this issue on me and process it. Thanks a lot for help was (Author: ochaloup): Hi [~dmlloyd], I didn't want to assign this issue to me as you have much clearer idea of how the fixes for WFTC should look like. But I have here a proposal that works for me https://github.com/ochaloup/wildfly/commit/b5622bd8aaf22459d1262de8b10289... (https://github.com/ochaloup/wildfly/tree/WFLY-8370-propagate-change-of-tx...) In general it's just adding WFTC update at write handler in txn subsystem. If you are fine with such fix I can reassign this issue on me and process it. Thanks a lot for help > Changing global transaction timeout requires reload to be considered for MDB > ---------------------------------------------------------------------------- > > Key: WFLY-8370 > URL: https://issues.jboss.org/browse/WFLY-8370 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondra Chaloupka > Assignee: David Lloyd > > When default transaction timeout is redefined during the server lifetime > {code} > /subsystem=transactions:write-attribute(name=default-timeout, value=60) > {"outcome" => "success"} > {code} > such change is not propagated to WFTC and for example in case of MDB the default transaction timeout is being left as it was at time of container startup. The transaction timeout is considered after server is reloaded. But it's different behavior than it was and in general for transaction timeout redefinition should not be needed container reload. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8072) Core Bridge, Unable to authenticate using credential reference alias

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8072?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFLY-8072. ------------------------------- Fix Version/s: 11.0.0.Alpha1 Resolution: Done the fix for WFLY-8071 also fixed this issue > Core Bridge, Unable to authenticate using credential reference alias > -------------------------------------------------------------------- > > Key: WFLY-8072 > URL: https://issues.jboss.org/browse/WFLY-8072 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > > When I try to configure core bridge with credential-reference alias attribute, bridge can't authenticate to remote destination. When I use attribute password (#testUsernamePasswordCoreBridge) message transfer works OK. > Core bridge configuration: > {code:xml|title=standalone-full-ha.xml} > <credential-stores> > <credential-store name="bridge-cs001" relative-to="jboss.server.data.dir"> > <uri>cr-store://test/bridge-cs001.jceks</uri> > <credential-reference clear-text="pass123"/> > </credential-store> > </credential-stores> > <bridge name="myBridge" queue-name="jms.queue.InQueue" forwarding-address="jms.queue.OutQueue" ha="true" user="johnOut" static-connectors="bridge-connector"> > <credential-reference store="bridge-cs001" alias="john_out_alias"/> > </bridge> > {code} > Exception in log: > {code:java|title=server.log} > 10:38:17,947 ERROR [org.apache.activemq.artemis.core.server] (default I/O-11) AMQ224018: Failed to create session: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119031: Unable to validate user] > at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:144) > at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1278) > at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156) > at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81) > at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624) > at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373) > at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356) > at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621) > at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292) > at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278) > at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277) > at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292) > at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278) > at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962) > at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435) > at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.3.Final-redhat-1.jar:3.4.3.Final-redhat-1] > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.3.Final-redhat-1.jar:3.4.3.Final-redhat-1] > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.3.Final-redhat-1.jar:3.4.3.Final-redhat-1] > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.3.Final-redhat-1.jar:3.4.3.Final-redhat-1] > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8370) Changing global transaction timeout requires reload to be considered for MDB

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created WFLY-8370: ------------------------------------- Summary: Changing global transaction timeout requires reload to be considered for MDB Key: WFLY-8370 URL: https://issues.jboss.org/browse/WFLY-8370 Project: WildFly Issue Type: Bug Components: Transactions Affects Versions: 11.0.0.Alpha1 Reporter: Ondra Chaloupka Assignee: David Lloyd When default transaction timeout is redefined during the server lifetime {code} /subsystem=transactions:write-attribute(name=default-timeout, value=60) {"outcome" => "success"} {code} such change is not propagated to WFTC and for example in case of MDB the default transaction timeout is being left as it was at time of container startup. The transaction timeout is considered after server is reloaded. But it's different behavior than it was and in general for transaction timeout redefinition should not be needed container reload. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8369) jaxrs bootstrap servlet init parameters doesn't work

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8369?page=com.atlassian.jira.plugin.... ] Jim Ma reassigned WFLY-8369: ---------------------------- Issue Type: Bug (was: Enhancement) Component/s: REST Fix Version/s: 11.0.0.Alpha1 Summary: jaxrs bootstrap servlet init parameters doesn't work (was: resteasy doesn') Affects Version/s: 10.1.0.Final Assignee: Jim Ma (was: Jason Greene) resteasy.scan , resteasy.scan.provider and resteasy.scan.resources in servlet context can be set to ResteasyDeployment and it works. But these parameter values from resteasy bootstrap servlet init paramter are ignored. > jaxrs bootstrap servlet init parameters doesn't work > ---------------------------------------------------- > > Key: WFLY-8369 > URL: https://issues.jboss.org/browse/WFLY-8369 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 10.1.0.Final > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8369) jaxrs bootstrap servlet init parameters doesn't work

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8369?page=com.atlassian.jira.plugin.... ] Jim Ma updated WFLY-8369: ------------------------- Description: resteasy.scan , resteasy.scan.provider and resteasy.scan.resources in servlet context can be set to ResteasyDeployment and it works. But these parameter values from resteasy bootstrap servlet init paramter are ignored. > jaxrs bootstrap servlet init parameters doesn't work > ---------------------------------------------------- > > Key: WFLY-8369 > URL: https://issues.jboss.org/browse/WFLY-8369 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 10.1.0.Final > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: 11.0.0.Alpha1 > > > resteasy.scan , resteasy.scan.provider and resteasy.scan.resources in servlet context can be set to ResteasyDeployment and it works. But these parameter values from resteasy bootstrap servlet init paramter are ignored. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8369) jaxrs bootstrap servlet init parameters doesn't work

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8369?page=com.atlassian.jira.plugin.... ] Jim Ma updated WFLY-8369: ------------------------- Comment: was deleted (was: resteasy.scan , resteasy.scan.provider and resteasy.scan.resources in servlet context can be set to ResteasyDeployment and it works. But these parameter values from resteasy bootstrap servlet init paramter are ignored. ) > jaxrs bootstrap servlet init parameters doesn't work > ---------------------------------------------------- > > Key: WFLY-8369 > URL: https://issues.jboss.org/browse/WFLY-8369 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 10.1.0.Final > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: 11.0.0.Alpha1 > > > resteasy.scan , resteasy.scan.provider and resteasy.scan.resources in servlet context can be set to ResteasyDeployment and it works. But these parameter values from resteasy bootstrap servlet init paramter are ignored. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 March 2017