[JBoss JIRA] (WFLY-3659) DIGEST authentication method throws javax.security.auth.callback.UnsupportedCallbackException
by Carolina Contiu (JIRA)
[ https://issues.jboss.org/browse/WFLY-3659?page=com.atlassian.jira.plugin.... ]
Carolina Contiu commented on WFLY-3659:
---------------------------------------
Should I expect this bug to reproduce for the "UsersRoles" login module as well, wildfy 9.0.1 final version?
I set up a similar DIGEST authentication, the single difference being the fact that I'm using the UsersRoles login-module, instead of the Database one.
I get the same exception
18:19:40,798 DEBUG [JBossCachedAuthenticationManager] (default task-2) PBOX00206: Login failure: javax.security.auth.login.LoginException: PBOX00055: Failed to invoke CallbackHandler
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:446) [picketbox-4.9.2.Final.jar:4.9.2.Final]
...
Caused by: javax.security.auth.callback.UnsupportedCallbackException: PBOX00014: org.jboss.security.auth.callback.JBossCallbackHandler does not handle a callback of type org.jboss.security.auth.callback.MapCallback
and 2 additional ones:
PBOX00287: Failed to open properties file from URL: java.net.MalformedURLException: no protocol: defaultUsers.properties
PBOX00287: Failed to open properties file from URL: java.net.MalformedURLException: no protocol: defaultRoles.properties
Just wanted to know if this bug affected UsersRoles login-module as well.
> DIGEST authentication method throws javax.security.auth.callback.UnsupportedCallbackException
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-3659
> URL: https://issues.jboss.org/browse/WFLY-3659
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 8.1.0.Final, 9.0.1.Final, 10.0.0.CR1
> Reporter: Joseph Hwang
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.CR2
>
>
> Password encryption in database login module with wildfly digest login config throws {{javax.security.auth.callback.UnsupportedCallbackException}}. These are sources.
> {code:xml|title=web.xml|borderStyle=solid}
> <security-role>
> <role-name>administrator</role-name>
> </security-role>
> <login-config>
> <auth-method>DIGEST</auth-method>
> <realm-name>WildFly8DigestRealm</realm-name>
> </login-config>
> {code}
> {code:xml|title=jboss-web.xml|borderStyle=solid}
> <jboss-web>
> <security-domain>java:/jaas/my_secure_domain</security-domain>
> </jboss-web>
> {code}
> {code:xml|title=standalone.xml|borderStyle=solid}
> <security-domain name="my_secure_domain" cache-type="default">
> <authentication>
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
> <module-option name="principalsQuery" value="select password from credential where uid=?"/>
> <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
> <module-option name="hashAlgorithm" value="MD5"/>
> <module-option name="hashEncoding" value="RFC2617"/>
> <module-option name="hashUserPassword" value="false"/>
> <module-option name="hashStorePassword" value="true"/>
> <module-option name="passwordIsA1Hash" value="true"/>
> <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
> <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
> Password is encrypted with below codes
> {code:java|title=EncryptPassword.java|borderStyle=solid}
> package com.aaa.encrypt;
> import org.jboss.crypto.CryptoUtil;
> public class EncryptPassword {
> public static void main(String[] args) {
> // TODO Auto-generated method stub
> String userName="admin";
> String realmName="WildFly8DigestRealm";
> String password="passwd123";
> String clearTextPassword=userName+":"+realmName+":"+password;
> String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword);
> System.out.println("clearTextPassword: "+clearTextPassword);
> System.out.println("hashedPassword: "+hashedPassword);
> }
> }
> {code}
> But login failed! The log shows the folowing exceptions :
> {code}
> 2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
> 2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
> 2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
> 2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
> 2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
> at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> Caused by: javax.security.auth.callback.UnsupportedCallbackException
> at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> ... 49 more
> {code}
> This cofiguration worked well in JBoss AS 7.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2041) Getting Socketexception during cluster communication
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2041?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2041.
----------------------------
Resolution: Cannot Reproduce Bug
> Getting Socketexception during cluster communication
> ----------------------------------------------------
>
> Key: JGRP-2041
> URL: https://issues.jboss.org/browse/JGRP-2041
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.5.2
> Environment: RHEL
> Reporter: Rohit Singh
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: jetty.log.D20160315.T074324.zip, jgroups_cluster.properties
>
>
> We faced issues during our cluster communication which is based on JGroup implementation.
> We got below errors in logs. JGroup does not even put full stacktrace of the SocketException.
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2038) RpcDipatcher: calls with CompletableFuture don't respect timeout
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2038?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2038:
--------------------------------
This is because the timeout defined in {{RequestOptions}} doesn't come into play with an RPC-with-future which returns immediately. To use a timeout, {{CompletableFuture.get(long timeout, TimeUnit unit)}} has to be used on the returned future.
> RpcDipatcher: calls with CompletableFuture don't respect timeout
> ----------------------------------------------------------------
>
> Key: JGRP-2038
> URL: https://issues.jboss.org/browse/JGRP-2038
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> When calling {{RpsDispatcher.callRemoteMethodsWithFuture()}}, a timeout passed via RequestOptions is not respected; calls don't timeout out if any of the members doesn't reply.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2088) ArrayIndexOutOfBoundsException on ClassConfigurator.get()
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2088?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2088:
--------------------------------
Try configuring AUTH and SYM_ENCRYPT according to the config listed in [1].
Also note that NAKACK is deprecated.
[1] https://github.com/belaban/JGroups/blob/3.6/conf/sym-encrypt.xml
> ArrayIndexOutOfBoundsException on ClassConfigurator.get()
> ---------------------------------------------------------
>
> Key: JGRP-2088
> URL: https://issues.jboss.org/browse/JGRP-2088
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Manuel Dominguez Sarmiento
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.xml
>
>
> See the following stack trace:
> [ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
> java.lang.ArrayIndexOutOfBoundsException: -1
> at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
> at org.jgroups.Message.readHeader(Message.java:936)
> at org.jgroups.Message.readFrom(Message.java:811)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
> at org.jgroups.protocols.TP.receive(TP.java:1654)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:745)
> Stepping through the code with the debugger shows that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
> return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
> See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2088) ArrayIndexOutOfBoundsException on ClassConfigurator.get()
by Manuel Dominguez Sarmiento (JIRA)
[ https://issues.jboss.org/browse/JGRP-2088?page=com.atlassian.jira.plugin.... ]
Manuel Dominguez Sarmiento edited comment on JGRP-2088 at 7/11/16 10:50 AM:
----------------------------------------------------------------------------
I can now confirm that this issue is somehow caused by JGRP-2055. By removing the AUTH and ENCRYPT protocols from the stack (see attached jgroups.xml), the cluster now works fine using 3.6.10
Possibly caused by an incomplete backport of JGRP-2021
Bela can you please reopen this issue? Thanks.
was (Author: mads1980):
I can now confirm that this issue is somehow caused by JGRP-2055. By removing the AUTH and ENCRYPT protocols from the stack (see attached jgroups.xml), the cluster now works fine using 3.6.10
Possibly caused by an incomplete backport of JGRP-2021
> ArrayIndexOutOfBoundsException on ClassConfigurator.get()
> ---------------------------------------------------------
>
> Key: JGRP-2088
> URL: https://issues.jboss.org/browse/JGRP-2088
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Manuel Dominguez Sarmiento
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.xml
>
>
> See the following stack trace:
> [ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
> java.lang.ArrayIndexOutOfBoundsException: -1
> at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
> at org.jgroups.Message.readHeader(Message.java:936)
> at org.jgroups.Message.readFrom(Message.java:811)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
> at org.jgroups.protocols.TP.receive(TP.java:1654)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:745)
> Stepping through the code with the debugger shows that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
> return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
> See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2088) ArrayIndexOutOfBoundsException on ClassConfigurator.get()
by Manuel Dominguez Sarmiento (JIRA)
[ https://issues.jboss.org/browse/JGRP-2088?page=com.atlassian.jira.plugin.... ]
Manuel Dominguez Sarmiento edited comment on JGRP-2088 at 7/11/16 10:48 AM:
----------------------------------------------------------------------------
I can now confirm that this issue is somehow caused by JGRP-2055. By removing the AUTH and ENCRYPT protocols from the stack (see attached jgroups.xml), the cluster now works fine using 3.6.10
Possibly caused by an incomplete backport of JGRP-2021
was (Author: mads1980):
I can now confirm that this issue is somehow caused by JGRP-2055. By removing the AUTH and ENCRYPT protocols from the stack (see attached jgroups.xml), the cluster now works fine using 3.6.10
> ArrayIndexOutOfBoundsException on ClassConfigurator.get()
> ---------------------------------------------------------
>
> Key: JGRP-2088
> URL: https://issues.jboss.org/browse/JGRP-2088
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Manuel Dominguez Sarmiento
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.xml
>
>
> See the following stack trace:
> [ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
> java.lang.ArrayIndexOutOfBoundsException: -1
> at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
> at org.jgroups.Message.readHeader(Message.java:936)
> at org.jgroups.Message.readFrom(Message.java:811)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
> at org.jgroups.protocols.TP.receive(TP.java:1654)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:745)
> Stepping through the code with the debugger shows that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
> return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
> See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2088) ArrayIndexOutOfBoundsException on ClassConfigurator.get()
by Manuel Dominguez Sarmiento (JIRA)
[ https://issues.jboss.org/browse/JGRP-2088?page=com.atlassian.jira.plugin.... ]
Manuel Dominguez Sarmiento commented on JGRP-2088:
--------------------------------------------------
I can now confirm that this issue is somehow caused by JGRP-2055. By removing the AUTH and ENCRYPT protocols from the stack (see attached jgroups.xml), the cluster now works fine using 3.6.10
> ArrayIndexOutOfBoundsException on ClassConfigurator.get()
> ---------------------------------------------------------
>
> Key: JGRP-2088
> URL: https://issues.jboss.org/browse/JGRP-2088
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Manuel Dominguez Sarmiento
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.xml
>
>
> See the following stack trace:
> [ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
> java.lang.ArrayIndexOutOfBoundsException: -1
> at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
> at org.jgroups.Message.readHeader(Message.java:936)
> at org.jgroups.Message.readFrom(Message.java:811)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
> at org.jgroups.protocols.TP.receive(TP.java:1654)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:745)
> Stepping through the code with the debugger shows that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
> return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
> See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6815) JDOM cannot create default parser
by Thomas Diesler (JIRA)
Thomas Diesler created WFLY-6815:
------------------------------------
Summary: JDOM cannot create default parser
Key: WFLY-6815
URL: https://issues.jboss.org/browse/WFLY-6815
Project: WildFly
Issue Type: Sub-task
Reporter: Thomas Diesler
Assignee: Thomas Diesler
Fix For: 10.1.0.Final
{code}
org.jdom.JDOMException: Could not load default SAX parser: org.apache.xerces.parsers.SAXParser: SAX2 driver class org.apache.xerces.parsers.SAXParser not found: org.apache.xerces.parsers.SAXParser from [Module "org.wildfly.extras.config:main" from local module loader @a3d8174 (finder: local module finder @1ba9117e (roots: /Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/fuse,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/base))]
at org.jdom.input.SAXBuilder.createParser(SAXBuilder.java:649)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:489)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:905)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months