June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6780) could not spécify version 3 for ldap connection

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6780?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6780: ------------------------------ Component/s: Security > could not spécify version 3 for ldap connection > ----------------------------------------------- > > Key: WFLY-6780 > URL: https://issues.jboss.org/browse/WFLY-6780 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: cyril leclerc > Assignee: Jason Greene > > HI, > in case of using LDAPExtLoginModule and ldap realm if in active directory there is more than 1000 groups it returns an error : > Caused by: javax.naming.SizeLimitExceededException: [LDAP: error code 4 - Sizelimit Exceeded]; remaining name 'CN=Users,DC=realad,DC=ad' > i can't change in AD the MAXPAGESIZE parameter and i can't specify the module to use version 3 of ldap how i can do ? > it is a big issue for me -) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-580) Add the ability to filter out unavailable mechanisms using the MechanismConfigurationSelector once the host name and protocol name are known

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-580?page=com.atlassian.jira.plugin.sy... ] Farah Juma updated ELY-580: --------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/457, https://github.com/wildfly-security/wildfly-elytron/pull/460 (was: https://github.com/wildfly-security/wildfly-elytron/pull/457) > Add the ability to filter out unavailable mechanisms using the MechanismConfigurationSelector once the host name and protocol name are known > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-580 > URL: https://issues.jboss.org/browse/ELY-580 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Mechanisms, HTTP > Reporter: Farah Juma > Assignee: Farah Juma > > We could modify the {{HttpServerAuthenticationMechanism}} mechanism supplier to take an {{HttpServerRequest}} parameter in order to filter out unavailable mechanisms. (For HTTP auth, the host name and protocol name are obtained using the {{HttpServerRequest}}). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2645) SFSB containing injected DataSource fails to passivate/serialize

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2645?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2645: ----------------------------------------------- Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 901300|https://bugzilla.redhat.com/show_bug.cgi?id=901300] from ON_QA to VERIFIED > SFSB containing injected DataSource fails to passivate/serialize > ---------------------------------------------------------------- > > Key: WFLY-2645 > URL: https://issues.jboss.org/browse/WFLY-2645 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Stefano Maestri > Priority: Critical > > See JBPAPP6-1762 for details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected

by Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla commented on WFLY-6781: ---------------------------------------- To answer to your question about our using the old version of wildfly, we have this already in production and at that time we used the version that was available. We are considering to upgrade to new version in near future. > Wildfly cluster's failover functionality doesn't work as expected > ----------------------------------------------------------------- > > Key: WFLY-6781 > URL: https://issues.jboss.org/browse/WFLY-6781 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.2.0.Final > Reporter: Preeta Kuruvilla > Assignee: Paul Ferraro > Priority: Blocker > > Following are the testing scenarios we did and the outcome:- > 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment. > 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment. > 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment > 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment. > Jgroups subsystem configuration in domain.xml we have is below:- > <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp"> > <stack name="udp"> > <transport type="UDP" socket-binding="jgroups-udp"/> > <protocol type="PING"/> > <protocol type="MERGE3"/> > <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/> > <protocol type="FD_ALL"/> > <protocol type="VERIFY_SUSPECT"/> > <protocol type="pbcast.NAKACK2"/> > <protocol type="UNICAST3"/> > <protocol type="pbcast.STABLE"/> > <protocol type="pbcast.GMS"/> > <protocol type="UFC"/> > <protocol type="MFC"/> > <protocol type="FRAG2"/> > <protocol type="RSVP"/> > </stack> > <stack name="tcp"> > <transport type="TCP" socket-binding="jgroups-tcp"/> > <protocol type="MPING" socket-binding="jgroups-mping"/> > <protocol type="MERGE2"/> > <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/> > <protocol type="FD"/> > <protocol type="VERIFY_SUSPECT"/> > <protocol type="pbcast.NAKACK2"/> > <protocol type="UNICAST3"/> > <protocol type="pbcast.STABLE"/> > <protocol type="pbcast.GMS"/> > <protocol type="MFC"/> > <protocol type="FRAG2"/> > <protocol type="RSVP"/> > </stack> > </subsystem> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected

by Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla commented on WFLY-6781: ---------------------------------------- That was a good explanation. Thanks Paul. Never knew about the loopback interface before while I was configuring. We have this configuration in our domain.xml <interfaces> <interface name="management"> <inet-address value="${jboss.bind.address.management:10.76.82.121}"/> </interface> <interface name="public"> <inet-address value="${jboss.bind.address:10.76.82.121}"/> </interface> <interface name="unsecure"> <inet-address value="${jboss.bind.address.unsecure:10.76.82.121}"/> </interface> </interfaces> where the bind-address is the ip-address of the VM. Thanks, Preeta > Wildfly cluster's failover functionality doesn't work as expected > ----------------------------------------------------------------- > > Key: WFLY-6781 > URL: https://issues.jboss.org/browse/WFLY-6781 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.2.0.Final > Reporter: Preeta Kuruvilla > Assignee: Paul Ferraro > Priority: Blocker > > Following are the testing scenarios we did and the outcome:- > 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment. > 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment. > 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment > 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment. > Jgroups subsystem configuration in domain.xml we have is below:- > <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp"> > <stack name="udp"> > <transport type="UDP" socket-binding="jgroups-udp"/> > <protocol type="PING"/> > <protocol type="MERGE3"/> > <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/> > <protocol type="FD_ALL"/> > <protocol type="VERIFY_SUSPECT"/> > <protocol type="pbcast.NAKACK2"/> > <protocol type="UNICAST3"/> > <protocol type="pbcast.STABLE"/> > <protocol type="pbcast.GMS"/> > <protocol type="UFC"/> > <protocol type="MFC"/> > <protocol type="FRAG2"/> > <protocol type="RSVP"/> > </stack> > <stack name="tcp"> > <transport type="TCP" socket-binding="jgroups-tcp"/> > <protocol type="MPING" socket-binding="jgroups-mping"/> > <protocol type="MERGE2"/> > <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/> > <protocol type="FD"/> > <protocol type="VERIFY_SUSPECT"/> > <protocol type="pbcast.NAKACK2"/> > <protocol type="UNICAST3"/> > <protocol type="pbcast.STABLE"/> > <protocol type="pbcast.GMS"/> > <protocol type="MFC"/> > <protocol type="FRAG2"/> > <protocol type="RSVP"/> > </stack> > </subsystem> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6680) :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-6680: -------------------------------- Labels: downstream_dependency (was: ) > :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-6680 > URL: https://issues.jboss.org/browse/WFLY-6680 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Environment: RHEL 6, EAP 6.1.0, mod_cluster-1.2.4-1.Final_redhat_1.ep6.el6.noarch, > Reporter: Kristina Clair > Assignee: Radoslav Husar > Labels: downstream_dependency > Fix For: 10.1.0.Final > > > When the modcluster subsystem is unable to connect to a proxy, the jboss-cli commands :read-proxies-configuration and :read-proxies-info fail with an unhelpful error. > On both the domain controller and application host, :read-proxies-info and :read-proxies-configuration fail with the same error. This is the output from the application host: > {noformat} > [domain@localhost:9999 subsystem=modcluster] pwd > /host=localhost/server=cluster2/subsystem=modcluster > [domain@localhost:9999 subsystem=modcluster] :list-proxies > { > "outcome" => "success", > "result" => [ > "web02:8009", > "web01:8009" > ] > } > [domain@localhost:9999 subsystem=modcluster] :read-proxies-configuration > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "JBAS014749: Operation handler failed: newValue is null", > "rolled-back" => true > } > [domain@localhost:9999 subsystem=modcluster] :read-proxies-info > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "JBAS014749: Operation handler failed: newValue is null", > "rolled-back" => true > } > {noformat} > In the above example, modcluster was not able to connect to the proxies due to an ssl misconfiguration in the modcluster subsystem in domain.xml. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-583) Add ability for outbound clients to directly consume IdentityCredentials

by David Lloyd (JIRA)

David Lloyd created ELY-583: ------------------------------- Summary: Add ability for outbound clients to directly consume IdentityCredentials Key: ELY-583 URL: https://issues.jboss.org/browse/ELY-583 Project: WildFly Elytron Issue Type: Enhancement Components: Authentication Client Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.1.0.Beta7 Outbound clients can gain substantial flexibility by being able to use {{IdentityCredentials}} directly. This allows a non-type-specific object like a {{byte[]}} to be interpreted as many different types of credentials. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-582) Logic error in functional cast methods in Credential, Evidence, Password

by David Lloyd (JIRA)

David Lloyd created ELY-582: ------------------------------- Summary: Logic error in functional cast methods in Credential, Evidence, Password Key: ELY-582 URL: https://issues.jboss.org/browse/ELY-582 Project: WildFly Elytron Issue Type: Bug Components: API / SPI Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.1.0.Beta7 There's a bug in algorithm handling in the Credential, Evidence, and Password type hierarchies. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-6781: ------------------------------------ [~kpreeta12] More confusion. A loopback interface is a virtual network interface that your host uses to communicate with itself. When you "disable your host network", you are not actually disabling this interface, but rather your actual network interface (e.g. eth0). WildFly's default configuration uses this interface for all of its socket bindings. For example, in your configuration, the socket-binding used by the FD_SOCK protocol uses the "jgroups-udp-fd" socket binding. In WF 8.2 (OT: I have to wonder why you have chosen to use an old release), this socket binding uses the default "public" interface, which is defined as: {code:xml} <interface name="public"> <inet-address value="${jboss.bind.address:127.0.0.1}"/> </interface> {code} So, unless you have started your server using a specific "jboss.bind.address" property, it will use 127.0.0.1, which is the IPv4 loopback address of your host. > Wildfly cluster's failover functionality doesn't work as expected > ----------------------------------------------------------------- > > Key: WFLY-6781 > URL: https://issues.jboss.org/browse/WFLY-6781 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.2.0.Final > Reporter: Preeta Kuruvilla > Assignee: Paul Ferraro > Priority: Blocker > > Following are the testing scenarios we did and the outcome:- > 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment. > 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment. > 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment > 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment. > Jgroups subsystem configuration in domain.xml we have is below:- > <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp"> > <stack name="udp"> > <transport type="UDP" socket-binding="jgroups-udp"/> > <protocol type="PING"/> > <protocol type="MERGE3"/> > <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/> > <protocol type="FD_ALL"/> > <protocol type="VERIFY_SUSPECT"/> > <protocol type="pbcast.NAKACK2"/> > <protocol type="UNICAST3"/> > <protocol type="pbcast.STABLE"/> > <protocol type="pbcast.GMS"/> > <protocol type="UFC"/> > <protocol type="MFC"/> > <protocol type="FRAG2"/> > <protocol type="RSVP"/> > </stack> > <stack name="tcp"> > <transport type="TCP" socket-binding="jgroups-tcp"/> > <protocol type="MPING" socket-binding="jgroups-mping"/> > <protocol type="MERGE2"/> > <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/> > <protocol type="FD"/> > <protocol type="VERIFY_SUSPECT"/> > <protocol type="pbcast.NAKACK2"/> > <protocol type="UNICAST3"/> > <protocol type="pbcast.STABLE"/> > <protocol type="pbcast.GMS"/> > <protocol type="MFC"/> > <protocol type="FRAG2"/> > <protocol type="RSVP"/> > </stack> > </subsystem> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2085) IndexOutOfBoundsException when trace logging

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2085?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2085: --------------------------- Fix Version/s: (was: 4.0) 4.0 doesn't have the issue as size() is not cached in the log stmt > IndexOutOfBoundsException when trace logging > -------------------------------------------- > > Key: JGRP-2085 > URL: https://issues.jboss.org/browse/JGRP-2085 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.9 > Reporter: Radim Vansa > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.11 > > > When running with trace logging, I got couple of these STs: > {code} > Exception in thread "OOB-1,test-NodeE-13479" java.lang.IndexOutOfBoundsException: Index: 4, Size: 2 > at java.util.ArrayList.rangeCheck(ArrayList.java:653) > at java.util.ArrayList.get(ArrayList.java:429) > at org.jgroups.protocols.pbcast.NAKACK2.handleMessages(NAKACK2.java:868) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:705) > at org.jgroups.stack.Protocol.up(Protocol.java:425) > at org.jgroups.protocols.TP.passBatchUp(TP.java:1600) > at org.jgroups.protocols.TP$BatchHandler.run(TP.java:1820) > 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) > {code} > Seems that part of the list of received messages is removed in handleMessages:864 in > {code} > boolean added=loopback || buf.add(msgs, oob, oob? DUMMY_OOB_MSG : null); > {code} > But the {{size}} is not recomputed afterwards. -- 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 June 2016