January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2081) IronJacamarResourceCreator Throws ConcurrentModificationException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2081?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2081: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 981093|https://bugzilla.redhat.com/show_bug.cgi?id=981093] from VERIFIED to CLOSED > IronJacamarResourceCreator Throws ConcurrentModificationException > ----------------------------------------------------------------- > > Key: WFLY-2081 > URL: https://issues.jboss.org/browse/WFLY-2081 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1 > Reporter: James Olsen > Assignee: Ivo Studensky > Fix For: 9.0.0.Beta1 > > > Recent wildfly-8.0.0.Beta1-SNAPSHOT (IronJacamar 1.1.0.Final) throws following error intermittently when there are multiple RARs in an EAR: > 13:12:34,710 ERROR [org.jboss.msc.service] (MSC service thread 1-10) MSC000002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1@e7b3aee" failed: java.util.ConcurrentModificationException > at java.util.HashMap$HashIterator.nextEntry(HashMap.java:894) [rt.jar:1.7.0_25] > at java.util.HashMap$KeyIterator.next(HashMap.java:928) [rt.jar:1.7.0_25] > at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.getIronJacamarResource(IronJacamarResourceCreator.java:335) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.execute(IronJacamarResourceCreator.java:350) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:145) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:244) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2095) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > Older versions had a similar problem as detailed in JBJCA-933 (which also shows interleaving example with 3 RARs). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1869) TP.registerProbeHandler not thread safe

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1869?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1869: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1336088|https://bugzilla.redhat.com/show_bug.cgi?id=1336088] from VERIFIED to CLOSED > TP.registerProbeHandler not thread safe > --------------------------------------- > > Key: JGRP-1869 > URL: https://issues.jboss.org/browse/JGRP-1869 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.12 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > TP.registerProbeHandlers is not thread safe since it modifies preregistered_probe_handlers outside of any synchronization. > If a thread calls this method while another thread is inside startDiagnostics (which can happen easily with a shared transport), it can cause a NullPointerException when startDiagnostics is looping through preregistered_probe_handlers. > Access to preregistered_probe_handlers should be synchronized. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7898) Upgrade JGroups to 3.6.12.Final

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7898: ---------------------------------- Summary: Upgrade JGroups to 3.6.12.Final Key: WFLY-7898 URL: https://issues.jboss.org/browse/WFLY-7898 Project: WildFly Issue Type: Component Upgrade Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 Release notes: https://issues.jboss.org/projects/JGRP/versions/12331586 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7899) Upgrade JGroups to 3.6.12.Final

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7899: ---------------------------------- Summary: Upgrade JGroups to 3.6.12.Final Key: WFLY-7899 URL: https://issues.jboss.org/browse/WFLY-7899 Project: WildFly Issue Type: Component Upgrade Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 Release notes: https://issues.jboss.org/projects/JGRP/versions/12331586 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-883) Rename GSSCredentialCredential to GSSKerberosCredential

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-883: ------------------------------------ Summary: Rename GSSCredentialCredential to GSSKerberosCredential Key: ELY-883 URL: https://issues.jboss.org/browse/ELY-883 Project: WildFly Elytron Issue Type: Task Components: Credentials Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta20 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5189) Eliminate "discarding discovery request for cluster=X from Y; our cluster name is Z" WARN messages

by Daniele Pirola (JIRA)

[ https://issues.jboss.org/browse/WFLY-5189?page=com.atlassian.jira.plugin.... ] Daniele Pirola commented on WFLY-5189: -------------------------------------- I found a solution: inside {{discovery-group}} and {{broadcast-group}} instead of specify {{jgroups channel}} I specify {{socket-binding}}, binded to default {{jgroups-mping}} binding. Inside {{tcp}} stack I use {{TCPPING}} instead of {{MPING}} protocol so this binding wasn't in use anymore inside my configuration. > Eliminate "discarding discovery request for cluster=X from Y; our cluster name is Z" WARN messages > -------------------------------------------------------------------------------------------------- > > Key: WFLY-5189 > URL: https://issues.jboss.org/browse/WFLY-5189 > Project: WildFly > Issue Type: Bug > Components: Clustering, JMS > Affects Versions: 10.0.0.Beta2 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 10.0.0.CR3 > > > These WARN messages are due to the fact that WF no longer uses a shared transport for its jgroups channels (JGroups recently deprecated shared transport in favor of fork channels). While these messages are harmless - they are quite annoying - and are the subject of several forum posts. > Currently, the messaging-activemq subsystem uses JChannels configured from a specific protocol stack. We should modify the default configuration to use a ChannelFactory from the default channel, which will use a new fork of the default "ee" channel. In xml/dmr terms, this corresponds not providing a value for jgroups-stack. > N.B. At the moment, this change will introduce new annoying WARN log messages until JGroups is upgraded to 3.6.5.Final, hence the jira dependency. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-788) Elytron SASL factories don't follow contract from corresponding Java interfaces

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-788?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-788: --------------------------------- Fix Version/s: 1.1.0.Beta19 > Elytron SASL factories don't follow contract from corresponding Java interfaces > ------------------------------------------------------------------------------- > > Key: ELY-788 > URL: https://issues.jboss.org/browse/ELY-788 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > Labels: sasl > Fix For: 1.1.0.Beta19 > > > Java [SaslClientFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] and [SaslServerFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] interfaces define where {{null}} parameters or {{null}} return values are allowed and which Exception types can be used in methods. Elytron implementation of SASL mechanisms doesn't follow this contract, which results in NullPointerExceptions. > E.g. > {code} > java.lang.NullPointerException > at org.wildfly.security.sasl.scram.ScramSaslClientFactory.getMechanismNames(ScramSaslClientFactory.java:119) > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-797) Ldap security realm does not close DirContext properly

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-797?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-797: --------------------------------- Fix Version/s: 1.1.0.Beta17 > Ldap security realm does not close DirContext properly > ------------------------------------------------------ > > Key: ELY-797 > URL: https://issues.jboss.org/browse/ELY-797 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta17 > > > There are methods in Elytron {{LdapSecurityRealm}} class which create/get DirContext, but does not close him in finally block. > In some circumstances could cause context resource leak. > * LdapSecurityRealm > ** getEvidenceVerifySupport > ** getCredentialAcquireSupport > ** getCredential > ** setCredentials > * LdapRealmIdentity > ** setCredentials > In same class there are examples of properly closed contexts: > * LdapRealmIdentity > ** getCredential > ** getEvidenceVerifySupport > ** verifyEvidence > ** getIdentity > ** create > ** setAttributes -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-756) Elytron ldap-realm does not support recursive role search

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-756?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-756: --------------------------------- Fix Version/s: 1.1.0.Beta17 > Elytron ldap-realm does not support recursive role search > --------------------------------------------------------- > > Key: ELY-756 > URL: https://issues.jboss.org/browse/ELY-756 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms > Affects Versions: 1.1.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta17 > > > Scenario: > LDAP can include some roles which are members of other roles. I try to assigned also these "nested roles" to user during authentication/authorization process. > In EAP 7.0 (with PicketBox) I am able to set configuration, which allows to assign these roles to user. LdapExtLoginModule with module option {{roleRecursion}} serves for this. It uses int value which determines how many levels should be searched and assigned to user. I am not able to achieve this scenario with Elytron and its ldap-realm. > Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron. > See example of LDIF for LDAP server: > {code} > dn: ou=People,dc=jboss,dc=org > objectclass: top > objectclass: organizationalUnit > ou: People > dn: uid=jduke,ou=People,dc=jboss,dc=org > objectclass: top > objectclass: person > objectclass: inetOrgPerson > uid: jduke > cn: Java Duke > sn: Duke > userPassword: Password1 > dn: ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: organizationalUnit > ou: Roles > dn: cn=R1,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R1 > member: uid=jduke,ou=People,dc=jboss,dc=org > description: the R1 group > dn: cn=R2,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R2 > member: cn=R1,ou=Roles,dc=jboss,dc=org > description: the R2 group > dn: cn=R3,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R3 > member: cn=R2,ou=Roles,dc=jboss,dc=org > description: the R3 group > {code} > In Elytron I am able to assigned only {{R1}} role to user jduke. Legacy solution is able to use for example {{roleRecursion=1}} which results to assign roles {{R1}} and {{R2}} to user jduke. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2022) XSD schemas do not properly validate

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2022?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2022. ---------------------------- Resolution: Won't Do Command completion works for me in IntelliJ IDEA. Since I'm not an XSD expert, I posted to the ML but nobody seemed to be interested in tackling this. Radim did take a shot, but his PR did only half the job, and looking further into it, he found there were quite a few changes to be made, especially to the generator (we generate the schema). I don't have time and (to be honest) interest to look into this, as it works for me. If you submit a fix or find someone who's willing to look into it, I can always reopen this issue. Hope you understand, > XSD schemas do not properly validate > ------------------------------------ > > Key: JGRP-2022 > URL: https://issues.jboss.org/browse/JGRP-2022 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.8 > Reporter: Manuel Dominguez Sarmiento > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > Attachments: fork-stacks.xsd, jgroups.xsd, relay.xsd > > > Affected resources: > - jgroups.xsd > - relay.xsd > - fork-stacks.xsd > Paste these files into an Eclipse project, or run them through Oxygen XML or any other XML / XSD validator, you will get errors relating to src-resolve.4.1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 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 January 2017