June 2016 - jboss-jira - Jboss List Archives

[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, 10 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, 10 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, 10 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, 10 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 resolved JGRP-2085. ---------------------------- Resolution: Done > 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, 10 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: 3.6.11 4.0 > 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, 4.0 > > > 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, 10 months

1
0
0 / 0

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

by Radim Vansa (JIRA)

Radim Vansa created JGRP-2085: --------------------------------- Summary: 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 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, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1220) Native Java compiler should use specified compiler configuration

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1220?page=com.atlassian.jira.plugi... ] Petr Široký updated DROOLS-1220: -------------------------------- Summary: Native Java compiler should use specified compiler configuration (was: Native compiler should use specified compiler configuration) > Native Java compiler should use specified compiler configuration > ---------------------------------------------------------------- > > Key: DROOLS-1220 > URL: https://issues.jboss.org/browse/DROOLS-1220 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.4.0.Final > Reporter: Petr Široký > Assignee: Petr Široký > Priority: Minor > > The native compiler ({{org.drools.compiler.commons.jci.compilers.NativeJavaCompiler}} currently ignores the provided {{JavaCompilerSettings}}. It should take them into account, the same way the Eclipse compiler does. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6787) WebSockets compression should be allowed by default

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-6787?page=com.atlassian.jira.plugin.... ] Ingo Weiss moved JBEAP-5137 to WFLY-6787: ----------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6787 (was: JBEAP-5137) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Web (Undertow) (was: Web (Undertow)) Target Release: (was: 7.backlog.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.GA) (was: 7.0.1.CR1) > WebSockets compression should be allowed by default > --------------------------------------------------- > > Key: WFLY-6787 > URL: https://issues.jboss.org/browse/WFLY-6787 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Ingo Weiss > Assignee: Ingo Weiss > > In EAP 6.4 there was allowed WebSockets compression by default if requested by client. In EAP 7 it is not. I believe it should be also allowed by default in EAP 7. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6787) WebSockets compression should be allowed by default

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-6787?page=com.atlassian.jira.plugin.... ] Ingo Weiss reassigned WFLY-6787: -------------------------------- Assignee: Stuart Douglas (was: Ingo Weiss) > WebSockets compression should be allowed by default > --------------------------------------------------- > > Key: WFLY-6787 > URL: https://issues.jboss.org/browse/WFLY-6787 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Ingo Weiss > Assignee: Stuart Douglas > > In EAP 6.4 there was allowed WebSockets compression by default if requested by client. In EAP 7 it is not. I believe it should be also allowed by default in EAP 7. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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 June 2016