September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4376) Incorrect callback handler used during authentication (SASL)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4376?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4376: ----------------------------------------------- Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 901248|https://bugzilla.redhat.com/show_bug.cgi?id=901248] from ASSIGNED to POST > Incorrect callback handler used during authentication (SASL) > ------------------------------------------------------------- > > Key: WFLY-4376 > URL: https://issues.jboss.org/browse/WFLY-4376 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Reporter: Enrique González Martínez > Assignee: Enrique González Martínez > Fix For: 10.0.0.CR5 > > > Cluster topology messages are not using the proper callbackhandler when the connection is being established. > {code} > 06:59:44,609 ERROR [org.jboss.remoting.remote.connection] (Remoting "config-based-ejb-client-endpoint" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > 06:59:44,611 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (ejb-client-cluster-node-connection-creation-2-thread-2) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='perf18', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='10.16.90.54', destinationPort=4447}], resolvedDestination=[Destination address=10.16.90.54, destination port=4447]} in cluster ejb > java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91) > at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:406) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:380) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:382) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:225) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.nio.NioHandle.run(NioHandle.java:90) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:187) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:386) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:151) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:132) > at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:87) > ... 7 more > {code} > Before that, this log is produced: > {code} > DEBUG: Client authentication failed for mechanism DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire realm, authentication ID or password [Caused by javax.security.auth.callback.UnsupportedCallbackException] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7023) appclient.sh script should have better help message

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-7023?page=com.atlassian.jira.plugin.... ] Ilia Vassilev updated WFLY-7023: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9167 > appclient.sh script should have better help message > --------------------------------------------------- > > Key: WFLY-7023 > URL: https://issues.jboss.org/browse/WFLY-7023 > Project: WildFly > Issue Type: Bug > Components: Application Client > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > > appclient.sh script should have better help message. There is no general description about this script. There is only list of attributes. > {code:bash} > ./appclient.sh -h > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1692) Upgrade to JBoss Modules 1.6.0.Beta2

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1692?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1692: ------------------------------------- Summary: Upgrade to JBoss Modules 1.6.0.Beta2 (was: Upgrade to JBoss Modules 1.6.0.Beta1) > Upgrade to JBoss Modules 1.6.0.Beta2 > ------------------------------------ > > Key: WFCORE-1692 > URL: https://issues.jboss.org/browse/WFCORE-1692 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Modules > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7030) WildFly don't include the license file

by gil cattaneo (JIRA)

[ https://issues.jboss.org/browse/WFLY-7030?page=com.atlassian.jira.plugin.... ] gil cattaneo commented on WFLY-7030: ------------------------------------ Found @ testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/LICENSE-2.0.txt servlet-feature-pack/src/main/resources/content/copyright.txt servlet-feature-pack/src/main/resources/content/LICENSE.txt servlet-feature-pack/src/main/resources/content/README.txt Sorry for the noise Regards > WildFly don't include the license file > --------------------------------------- > > Key: WFLY-7030 > URL: https://issues.jboss.org/browse/WFLY-7030 > Project: WildFly > Issue Type: Feature Request > Reporter: gil cattaneo > Assignee: Jason Greene > > Hi > Not available LICENSE file in source directory structure > Please. Added license and copyright notice. > the fedora pakaging guideline is very strictly precise about this problem > https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging... > Thanks in advance > Regards -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7030) WildFly don't include the license file

by gil cattaneo (JIRA)

[ https://issues.jboss.org/browse/WFLY-7030?page=com.atlassian.jira.plugin.... ] gil cattaneo edited comment on WFLY-7030 at 9/1/16 8:08 AM: ------------------------------------------------------------ Found @ testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/LICENSE-2.0.txt servlet-feature-pack/src/main/resources/content/copyright.txt servlet-feature-pack/src/main/resources/content/LICENSE.txt Sorry for the noise Regards was (Author: puntogil): Found @ testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/LICENSE-2.0.txt servlet-feature-pack/src/main/resources/content/copyright.txt servlet-feature-pack/src/main/resources/content/LICENSE.txt servlet-feature-pack/src/main/resources/content/README.txt Sorry for the noise Regards > WildFly don't include the license file > --------------------------------------- > > Key: WFLY-7030 > URL: https://issues.jboss.org/browse/WFLY-7030 > Project: WildFly > Issue Type: Feature Request > Reporter: gil cattaneo > Assignee: Jason Greene > > Hi > Not available LICENSE file in source directory structure > Please. Added license and copyright notice. > the fedora pakaging guideline is very strictly precise about this problem > https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging... > Thanks in advance > Regards -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7030) WildFly don't include the license file

by gil cattaneo (JIRA)

[ https://issues.jboss.org/browse/WFLY-7030?page=com.atlassian.jira.plugin.... ] gil cattaneo closed WFLY-7030. ------------------------------ Resolution: Done > WildFly don't include the license file > --------------------------------------- > > Key: WFLY-7030 > URL: https://issues.jboss.org/browse/WFLY-7030 > Project: WildFly > Issue Type: Feature Request > Reporter: gil cattaneo > Assignee: Jason Greene > > Hi > Not available LICENSE file in source directory structure > Please. Added license and copyright notice. > the fedora pakaging guideline is very strictly precise about this problem > https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging... > Thanks in advance > Regards -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1127) SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1127?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1127: ------------------------------------------------- Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1282532|https://bugzilla.redhat.com/show_bug.cgi?id=1282532] from ASSIGNED to NEW > SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets > ---------------------------------------------------------------------------------- > > Key: WFCORE-1127 > URL: https://issues.jboss.org/browse/WFCORE-1127 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.2.Final > > > A failure like this isn't necessary: > {code} > 08:02:23,475 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector: java.lang.IllegalStateException > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalStateException > at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.unregisterBinding(SocketBindingManagerImpl.java:501) > at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73) > at org.jboss.as.clustering.jgroups.ManagedSocketFactory.close(ManagedSocketFactory.java:148) > at org.jgroups.protocols.UDP.closeUnicastSocket(UDP.java:577) > at org.jgroups.protocols.UDP.destroySockets(UDP.java:429) > at org.jgroups.protocols.UDP.start(UDP.java:274) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965) > at org.jgroups.JChannel.startStack(JChannel.java:890) > at org.jgroups.JChannel._preConnect(JChannel.java:553) > at org.jgroups.JChannel.connect(JChannel.java:288) > at org.jgroups.JChannel.connect(JChannel.java:279) > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94) > ... 5 more > {code} > If there's no socket address, it should just move on. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7030) WildFly don't include the license file

by gil cattaneo (JIRA)

gil cattaneo created WFLY-7030: ---------------------------------- Summary: WildFly don't include the license file Key: WFLY-7030 URL: https://issues.jboss.org/browse/WFLY-7030 Project: WildFly Issue Type: Feature Request Reporter: gil cattaneo Assignee: Jason Greene Hi Not available LICENSE file in source directory structure Please. Added license and copyright notice. the fedora pakaging guideline is very strictly precise about this problem https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging... Thanks in advance Regards -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1726) CLI support for response attachments

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1726: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1763 > CLI support for response attachments > ------------------------------------ > > Key: WFCORE-1726 > URL: https://issues.jboss.org/browse/WFCORE-1726 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream. > The following operations are returning streams: > /subsystem=logging/log-file=server.log:read-attribute(name=stream) > /subsystem=logging/log-file=server.log:read-resource(include-runtime) > /deployment=toto:read-content(path=index.html) > As we can see, streams can be located in attributes, as operation response, inside a resource. > The CLI offers 2 way to approach the problem: > 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow. > 2) Define a new high level command that would cope with any operation. > Such command would look like: > attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file > attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) > - No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command. > - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file. > - No more prompting, the user knows ahead of time what he wants to do. > - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-1351: ------------------------------------- Are there updated stack traces? I think at this point the remaining problems will be in the application server code rather than in the libraries. > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Critical > Fix For: 3.0.0.Alpha7 > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2016