February 2015 - 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 updated WFLY-4376: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=996897 > Incorrect callback handler used during authentication (SASL) > ------------------------------------------------------------- > > Key: WFLY-4376 > URL: https://issues.jboss.org/browse/WFLY-4376 > Project: WildFly > Issue Type: Bug > Reporter: Enrique González Martínez > Assignee: Enrique González Martínez > > 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.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4368) Remove usage of jboss-common-core in appclient

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4368?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-4368. ------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done > Remove usage of jboss-common-core in appclient > ---------------------------------------------- > > Key: WFLY-4368 > URL: https://issues.jboss.org/browse/WFLY-4368 > Project: WildFly > Issue Type: Sub-task > Components: Application Client > Reporter: Tomaz Cerar > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > jboss-common-core usage should be reviewed and if possible eliminated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[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 updated WFLY-4376: ------------------------------------------ Bugzilla Update: (was: Perform) Bugzilla References: (was: https://bugzilla.redhat.com/show_bug.cgi?id=901248) > Incorrect callback handler used during authentication (SASL) > ------------------------------------------------------------- > > Key: WFLY-4376 > URL: https://issues.jboss.org/browse/WFLY-4376 > Project: WildFly > Issue Type: Bug > Reporter: Enrique González Martínez > Assignee: Enrique González Martínez > > 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.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-707) NullPointer when changing order of the rules

by Francesco Peloi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-707?page=com.atlassian.jira.plugin... ] Francesco Peloi commented on DROOLS-707: ---------------------------------------- Thanks [~mfusco] for the quick feedback. Totally agree on both points: 1) I wasn't completely sure this was related to the same problem of this ticket, I prefered to start with a comment and see what you think. 2) I thought the DRLs were invalid but since in some cases were passing and some throwing NPE and some throwing duplicate variable error I got confused :) > NullPointer when changing order of the rules > -------------------------------------------- > > Key: DROOLS-707 > URL: https://issues.jboss.org/browse/DROOLS-707 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4 > Reporter: Francesco Peloi > Assignee: Mario Fusco > Fix For: 6.2.0.Final > > > Hi there, > we are having some serious issues with some rules, they are throwing a NullPointerException and we don't understand why. I have tried to narrow down the problem to the smallest rule possible, now this rule doesn't really make much sense put like this but the real rule is more complex with more constraints. At the end the result is the same: a NPE. > I have tried it with many Drools versions from 5.x to latest 6.3.0-SNAPSHOT. > I tested this in isolation with the minimum amount of code possible, and attached it as well if someone wants to try it quickly. > Note that if line 2 of the when: > $a : Integer() > is moved as first line, the rule runs ok. > Please find the reproducer here: https://groups.google.com/forum/#!topic/drools-usage/-oNqu3l4cqE -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4369) Remove usage of jboss-common-core in connector

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4369?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-4369. ------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done > Remove usage of jboss-common-core in connector > ---------------------------------------------- > > Key: WFLY-4369 > URL: https://issues.jboss.org/browse/WFLY-4369 > Project: WildFly > Issue Type: Sub-task > Components: JCA > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > jboss-common-core usage should be reviewed and if possible eliminated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4371) Remove usage of jboss-common-core in pojo subsystem

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4371?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-4371. ------------------------------- Assignee: Tomaz Cerar (was: Ales Justin) Fix Version/s: 9.0.0.Beta1 Resolution: Done > Remove usage of jboss-common-core in pojo subsystem > --------------------------------------------------- > > Key: WFLY-4371 > URL: https://issues.jboss.org/browse/WFLY-4371 > Project: WildFly > Issue Type: Sub-task > Components: POJO > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > jboss-common-core usage should be reviewed and if possible eliminated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4324) While starting Jboss AS getting IllegalStateException.

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4324?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-4324: ----------------------------------- Looking at stacktrace this is EAP 6.3 there was discussion about this on forums https://developer.jboss.org/thread/239009 on semi related note, I hope that "tools.jar" you have in your deployment is not from JDK.... > While starting Jboss AS getting IllegalStateException. > ------------------------------------------------------ > > Key: WFLY-4324 > URL: https://issues.jboss.org/browse/WFLY-4324 > Project: WildFly > Issue Type: Bug > Environment: Java with 1.8 v and JBOS 7 > Reporter: ANKUSH NIKHAR > > Hi, > I am facing issue when I am trying to deploy web service on Jboss 7 and using jdk 1.8 version. Below are the sample log : > This issue does not impact the processing of my code execution. Is this just warning or will it harm in future. > I am migrating my project from jdk1.7 to 1.8. > When I try to deploy WS with jdk1.7, I didn't get such error. > 18:56:01,032 WARN [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015852: Could not index class sun/applet/AppletPanel.class at /D:/Test Eclipse/Migration Eclipse/Mig Workspace/CDLibrary/CDLibrary-test/content/InMemory.war/WEB-INF/lib/tools.jar: java.lang.IllegalStateException: Unknown tag! pos=1006 poolCount = 1018 > at org.jboss.jandex.Indexer.processConstantPool(Indexer.java:606) [jandex-1.0.3.Final-redhat-2.jar:1.0.3.Final-redhat-2] > at org.jboss.jandex.Indexer.index(Indexer.java:640) [jandex-1.0.3.Final-redhat-2.jar:1.0.3.Final-redhat-2] > at org.jboss.as.server.deployment.annotation.ResourceRootIndexer.indexResourceRoot(ResourceRootIndexer.java:100) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.server.deployment.annotation.AnnotationIndexProcessor.deploy(AnnotationIndexProcessor.java:51) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_31] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31] -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-707) NullPointer when changing order of the rules

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-707?page=com.atlassian.jira.plugin... ] Mario Fusco commented on DROOLS-707: ------------------------------------ Francesco, I'm giving a look at the other test cases in your pull request and for now I just have 2 comments: 1. Those test cases are totally unrelated with the issue originally reported in this ticket (that was caused by the presence of an or that wasn't correctly desugared) so I won't reopen the ticket (eventually I'll create a different one). 2. All the new test cases actually contain an invalid drl (the variable $list is always defined twice) so the expected outcome from all of them is a compilation failure saying "Duplicate declaration for variable '$list'" as at the moment happens only for the 3rd of them. Please confirm you agree with what I wrote above, especially with point 2. > NullPointer when changing order of the rules > -------------------------------------------- > > Key: DROOLS-707 > URL: https://issues.jboss.org/browse/DROOLS-707 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4 > Reporter: Francesco Peloi > Assignee: Mario Fusco > Fix For: 6.2.0.Final > > > Hi there, > we are having some serious issues with some rules, they are throwing a NullPointerException and we don't understand why. I have tried to narrow down the problem to the smallest rule possible, now this rule doesn't really make much sense put like this but the real rule is more complex with more constraints. At the end the result is the same: a NPE. > I have tried it with many Drools versions from 5.x to latest 6.3.0-SNAPSHOT. > I tested this in isolation with the minimum amount of code possible, and attached it as well if someone wants to try it quickly. > Note that if line 2 of the when: > $a : Integer() > is moved as first line, the rule runs ok. > Please find the reproducer here: https://groups.google.com/forum/#!topic/drools-usage/-oNqu3l4cqE -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-726) MVEL named consequences don't get rewired

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-726?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-726. -------------------------------- Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/6604b3548 > MVEL named consequences don't get rewired > ----------------------------------------- > > Key: DROOLS-726 > URL: https://issues.jboss.org/browse/DROOLS-726 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > > MVEL named consequences don't get rewired, so if for example the named consequence inserts an instance of a declared type that instance will belong to an old (not rewired) class. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-726) MVEL named consequences don't get rewired

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-726: ---------------------------------- Summary: MVEL named consequences don't get rewired Key: DROOLS-726 URL: https://issues.jboss.org/browse/DROOLS-726 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco MVEL named consequences don't get rewired, so if for example the named consequence inserts an instance of a declared type that instance will belong to an old (not rewired) class. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 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 2015