August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3153) Upgrade to jboss-marshalling 2.0.0.Final

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3153?page=com.atlassian.jira.plugi... ] Kabir Khan moved JBEAP-12579 to WFCORE-3153: -------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-3153 (was: JBEAP-12579) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Remoting (was: Remoting) > Upgrade to jboss-marshalling 2.0.0.Final > ---------------------------------------- > > Key: WFCORE-3153 > URL: https://issues.jboss.org/browse/WFCORE-3153 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Remoting > Reporter: Kabir Khan > Assignee: David Lloyd > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3152) Upgrade to jboss-invocation 1.5.0.Final

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3152?page=com.atlassian.jira.plugi... ] Kabir Khan moved JBEAP-12577 to WFCORE-3152: -------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-3152 (was: JBEAP-12577) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: EJB) > Upgrade to jboss-invocation 1.5.0.Final > --------------------------------------- > > Key: WFCORE-3152 > URL: https://issues.jboss.org/browse/WFCORE-3152 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Kabir Khan > Assignee: David Lloyd > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2208) FlowControlUnitTest.testNonBlockingFlowControlWithMessageQueueBlocking() sometimes blocks

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2208?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2208: -------------------------------- {{UFC_NB}} and {{MFC_NB}} don't seem to request credits when they go into blocking on the message queue. If a receiver sent credits shortly _before_ a sender blocks, then neither will the receiver send any more credits (until more messages from the sender have been received), nor will the sender ask for credits. > FlowControlUnitTest.testNonBlockingFlowControlWithMessageQueueBlocking() sometimes blocks > ----------------------------------------------------------------------------------------- > > Key: JGRP-2208 > URL: https://issues.jboss.org/browse/JGRP-2208 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.5 > > > Possibly because the full (blocking) message queue is not cleared on stop()? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2031) GMS: replace ViewHandler.queue with BlockingQueue

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2031?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2031 at 8/7/17 7:03 AM: -------------------------------------------------------- {{GMS}}, {{VERIFY_SUSPECT}} and {{JChannel}} / {{MessageDispatcher}} are able to handle both {{Event.SUSPECT(Address)}} and {{Event.SUSPECT(Collection<Address>)}}. The former will be removed in 4.1. This was done to prevent CCEs for protocols (outside of JGroups) which still emit {{Address}} instead of {{Collection<Address>}} for {{SUSPECT}} args. was (Author: belaban): {{GMS}}, {{VERIFY_SUSPECT}} and {{JChannel}} / {{MessageDispatcher}} are able to handle both {{Event.SUSPECT(Address)}} and {{Event.SUSPECT(Collection<Address>)}}. The former will be removed in 4.1. > GMS: replace ViewHandler.queue with BlockingQueue > ------------------------------------------------- > > Key: JGRP-2031 > URL: https://issues.jboss.org/browse/JGRP-2031 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.5 > > > Replace {{GMS$ViewHandler.Queue}} with {{LinkedBlockingQueue}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2031) GMS: replace ViewHandler.queue with BlockingQueue

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2031?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2031. ---------------------------- Resolution: Done > GMS: replace ViewHandler.queue with BlockingQueue > ------------------------------------------------- > > Key: JGRP-2031 > URL: https://issues.jboss.org/browse/JGRP-2031 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.5 > > > Replace {{GMS$ViewHandler.Queue}} with {{LinkedBlockingQueue}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2031) GMS: replace ViewHandler.queue with BlockingQueue

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2031?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2031: -------------------------------- {{GMS}}, {{VERIFY_SUSPECT}} and {{JChannel}} / {{MessageDispatcher}} are able to handle both {{Event.SUSPECT(Address)}} and {{Event.SUSPECT(Collection<Address>)}}. The former will be removed in 4.1. > GMS: replace ViewHandler.queue with BlockingQueue > ------------------------------------------------- > > Key: JGRP-2031 > URL: https://issues.jboss.org/browse/JGRP-2031 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.5 > > > Replace {{GMS$ViewHandler.Queue}} with {{LinkedBlockingQueue}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8548) Annotations on overloaded methods are sometimes mixed up

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFLY-8548?page=com.atlassian.jira.plugin.... ] jaikiran pai updated WFLY-8548: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9922, https://github.com/wildfly/wildfly/pull/10403, https://github.com/wildfly/wildfly/pull/10404 (was: https://github.com/wildfly/wildfly/pull/9922, https://github.com/wildfly/wildfly/pull/10403) > Annotations on overloaded methods are sometimes mixed up > -------------------------------------------------------- > > Key: WFLY-8548 > URL: https://issues.jboss.org/browse/WFLY-8548 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final, 11.0.0.Beta1 > Reporter: Olaf Fricke > Priority: Critical > Attachments: ApplicableMethodInformationTest.java > > > If a stateless session bean contains overloaded methods the annotations on these methods are sometimes mixed up. This happens for example, if two methods with the same name, the same return type and the same number of arguments exists. If both methods have different annotations or annotation values the values of the 'first' method are used. > To make things more complicated, the 'first' method depends on the JVM in use. > The bug lives in the class org.jboss.as.ejb3.deployment.ApplicableMethodInformation. I have already create a pull request to fix the issue: https://github.com/wildfly/wildfly/pull/9922 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1314) Elytron, make scope of SPNEGO authentication configurable

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1314?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1314. ----------------------------------- Fix Version/s: 1.1.0.CR5 Resolution: Duplicate Issue > Elytron, make scope of SPNEGO authentication configurable > --------------------------------------------------------- > > Key: ELY-1314 > URL: https://issues.jboss.org/browse/ELY-1314 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.CR5 > > > Currently Elytron SPNEGO authnetication is tcp connection scoped, whereas legacy SPNEGO for applications is http-session scoped. > This different approach can bring these behaviour differences after migration from legacy to Elytron: > - if deployment is behind reverse proxy it can lead to user "cross talk" (different http session, but same TCP connection) [1] > - more frequent kerberos negotiation cycles > - load balancer switches to another node (same http session, but new TCP connection) > - new tab in browser (same http session, but new TCP connection) [2] > [1] JBEAP-11882 - (7.1) Using a proxy and spnego on the EAP 7 management console leads to user "cross talk" > [2] https://superuser.com/questions/1055281/do-web-browsers-use-different-out... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1312) Further Scoping and Caching Enhancements to the SpnegoAuthenticationMechanism

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1312?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1312: ---------------------------------- Priority: Blocker (was: Major) > Further Scoping and Caching Enhancements to the SpnegoAuthenticationMechanism > ----------------------------------------------------------------------------- > > Key: ELY-1312 > URL: https://issues.jboss.org/browse/ELY-1312 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Environment: # > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.CR5 > > > Currently the SpnegoAuthenticationMechanism caches against the connection scope and uses the cached GssContext to recreate the identity. > We should consider the following: - > # Using the same cached identity mechanism as is used by FORM authentication. > # Adding configuration to specify which scope to cache against. > # Add an option to disable caching entirely, this would need to take into account cases where continuation is required as that would become unsupported. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1696) Events that are already expired at insert time, doesn't always produce activations

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1696?page=com.atlassian.jira.plugi... ] Tibor Zimányi commented on DROOLS-1696: --------------------------------------- Tried with 6.5.x, 7.2.x and master. It fails with 7.2.x and master and works in 6.5.x. > Events that are already expired at insert time, doesn't always produce activations > ---------------------------------------------------------------------------------- > > Key: DROOLS-1696 > URL: https://issues.jboss.org/browse/DROOLS-1696 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.1.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Fix For: 7.2.0.Final > > > When inserting events that have timestamp in the past and don't have expiration defined (@expires), the events don't always produce activations. See a test example [1]. This test fails "randomly". > I will create a PR with a reproducer. > [1] https://gist.github.com/baldimir/fb9808ce1e6d49c83dc24570b3cb6093 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 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 August 2017