July 2016 - jboss-jira - Jboss List Archives

[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)

8 years, 6 months

1
0
0 / 0

[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)

8 years, 6 months

1
0
0 / 0

[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)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1646) Wildcard for redeployments through CLI when using ADMIN_ONLY mode

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1646?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-1646: -------------------------------------------- Assignee: Jean-Francois Denise (was: Alexey Loubyansky) > Wildcard for redeployments through CLI when using ADMIN_ONLY mode > ----------------------------------------------------------------- > > Key: WFCORE-1646 > URL: https://issues.jboss.org/browse/WFCORE-1646 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1646) Wildcard for redeployments through CLI when using ADMIN_ONLY mode

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1646: -------------------------------------------- Summary: Wildcard for redeployments through CLI when using ADMIN_ONLY mode Key: WFCORE-1646 URL: https://issues.jboss.org/browse/WFCORE-1646 Project: WildFly Core Issue Type: Feature Request Components: CLI Reporter: Jean-Francois Denise Assignee: Alexey Loubyansky -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[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: -------------------------------------------------- All instances in the same cluster are using exclusively 3.6.10 Furthermore, the cluster has become unusable since we attempted to upgrade (messages timeout) so we had to rollback to 3.6.8 This is not an isolated error. It happens continuously on our cluster when attempting to use 3.6.10. We tried different environments (local, testing, production) and the same thing happened on all of them. I see that some changes were applied in 3.6.9 and 3.6.10 regarding AUTH / ENCRYPT and we use both protocols (see attached jgroups.xml). I will try to run some tests without these protocols to see whether the cluster works in that case. I will report back later today. > 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)

8 years, 6 months

1
0
0 / 0

[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: -------------------------------- Are you running 3.6.8, 3.6.9 and 3.6.10 instances in the same cluster? That might actually cause the issues you're seeing. > 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)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5739) Subject not populated with groups/roles when authenticated via JASPIC

by Guillermo González de Agüero (JIRA)

[ https://issues.jboss.org/browse/WFLY-5739?page=com.atlassian.jira.plugin.... ] Guillermo González de Agüero commented on WFLY-5739: ---------------------------------------------------- Hi [~stoty2]. I don't know too much about WildFly Security internals. I checked my example application again and it now works as expected. From what I can see, it seems like a valid approach, but maybe [~atijms] could provide some more insight. Anyway, I propose you to send the pull request since WF10.1 is around the corner, and this is our last opportunity to make it into the next release. > Subject not populated with groups/roles when authenticated via JASPIC > --------------------------------------------------------------------- > > Key: WFLY-5739 > URL: https://issues.jboss.org/browse/WFLY-5739 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.CR4 > Reporter: Arjan t > Assignee: Darran Lofthouse > Labels: jacc, jaspic > Attachments: CustomAuth.zip, picketbox.zip > > > After having authenticated via JASPIC, requesting the current {{Subject}} via JACC and then using that for permission checks fails. > For instance the following code will always set {{hasAccess}} to false given that "/protected/*" requires a role and the authenticated user is in that role: > {code:java} > Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container"); > > boolean hasAccess = Policy.getPolicy().implies( > new ProtectionDomain( > new CodeSource(null, (Certificate[]) null), > null, null, > subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()]) > ), > new WebResourcePermission("/protected/Servlet", "GET")) > ; > {code} > As it appears, the problem originates from the fact that {{subject.getPrincipals()}} does not contain the roles. > This can be traced back to {{org.jboss.security.auth.callback.JASPICallbackHandler.handleCallBack}}, where it becomes clear that the roles are only put into the "util", but not in the "authenticatedSubject": > {code:java} > String[] rolesArray = groupPrincipalCallback.getGroups(); > int sizeOfRoles = rolesArray != null ? rolesArray.length : 0; > > if( sizeOfRoles > 0 ) > { > List<Role> rolesList = new ArrayList<Role>(); > for( int i = 0; i < sizeOfRoles ; i++ ) > { > Role role = new SimpleRole( rolesArray[ i ] ); > rolesList.add( role ); > } > RoleGroup roles = new SimpleRoleGroup( SecurityConstants.ROLES_IDENTIFIER, rolesList ); > // if the current security context already has roles, we merge them with the incoming roles. > RoleGroup currentRoles = currentSC.getUtil().getRoles(); > // *** ROLES ARE ONLY SET HERE *** > if (currentRoles != null) { > currentRoles.addAll(roles.getRoles()); > } > else { > currentSC.getUtil().setRoles( roles ); > } > } > // *** BELOW THIS LINE ROLES ARE NOT REFERENCED ANYMORE > // *** SUBJECT IS NOT POPULATED WITH ANY ROLE INFO > Subject subject = groupPrincipalCallback.getSubject(); > if( subject != null ) > { > // if the current security context already has an associated subject, we merge it with the incoming subject. > Subject currentSubject = currentSC.getSubjectInfo().getAuthenticatedSubject(); > if (currentSubject != null) { > subject.getPrincipals().addAll(currentSubject.getPrincipals()); > subject.getPublicCredentials().addAll(currentSubject.getPublicCredentials()); > subject.getPrivateCredentials().addAll(currentSubject.getPrivateCredentials()); > } > currentSC.getSubjectInfo().setAuthenticatedSubject(subject); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1636) --<description-property> are no more supported by ls command

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1636?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1636: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1671 > --<description-property> are no more supported by ls command > ------------------------------------------------------------ > > Key: WFCORE-1636 > URL: https://issues.jboss.org/browse/WFCORE-1636 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > - ls -l --storage will make the CLI to throw an exception. storage being not known by the Command runtime. > - Furthermore completion is not offered for these options. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2441) Make Servlet container the default in Arquillian WildFly

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2441?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-2441. ------------------------------- Fix Version/s: 8.0.0.Final Resolution: Done > Make Servlet container the default in Arquillian WildFly > -------------------------------------------------------- > > Key: WFLY-2441 > URL: https://issues.jboss.org/browse/WFLY-2441 > Project: WildFly > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 8.0.0.Beta1 > Reporter: Karel Piwko > Assignee: Karel Piwko > Priority: Critical > Fix For: 8.0.0.Final > > > Current setting of jmx-as7 as default protocol complicated setup for consumers of Arquillian platform. > JMX-AS7 protocol should be used for testing container implementation, not for testing applications deployed on WildFly. > For that reason, WildFly testsuite should be the place where protocol is overridden to jmx-as7, not the other way around. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 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 July 2016