March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2299: -------------------------------- Hi [~dwhitejazz]. I'm afraid I don't have time to look into this right now as I'm working on JGRP-2332. I should be done in 2-3 weeks' time, then I'll process the remaining JIRAs in 4.0.(21) in priority order. > LockService does not work correctly if unlock/lock is called in immediate succession > ------------------------------------------------------------------------------------ > > Key: JGRP-2299 > URL: https://issues.jboss.org/browse/JGRP-2299 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Environment: Windows 10 Oracle JDK 1.8 131 > AIX IBM Java 8 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.20 > > Attachments: JGroupsExample.java, udp+lock.xml > > > In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected. > This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded. > If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock(). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1766) Review relevence of webauth with Elytron authentication

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1766?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1766: ---------------------------------- Fix Version/s: 1.9.0.CR2 (was: 1.9.0.CR1) > Review relevence of webauth with Elytron authentication > ------------------------------------------------------- > > Key: ELY-1766 > URL: https://issues.jboss.org/browse/ELY-1766 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.9.0.CR2 > > > Does this just make sense in IDM / SSO environments or does it make sense for direct authentication to a server. > https://www.w3.org/TR/webauthn/ -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1765) Review authentication client dependencies on credential sources

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1765?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1765: ---------------------------------- Fix Version/s: 1.9.0.CR2 (was: 1.9.0.CR1) > Review authentication client dependencies on credential sources > --------------------------------------------------------------- > > Key: ELY-1765 > URL: https://issues.jboss.org/browse/ELY-1765 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.9.0.CR2 > > > Could these credential sources be discoverable from java.security.Provider with a more generic configuration API? This could help break any dependency from authentication client to the implementation. > _In the opposite direction I think it is Ok for the impl to depend on the client._ -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1772) Release WildFly Elytron 2.0.0.Alpha2

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1772?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1772. ----------------------------------- Resolution: Done > Release WildFly Elytron 2.0.0.Alpha2 > ------------------------------------ > > Key: ELY-1772 > URL: https://issues.jboss.org/browse/ELY-1772 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 2.0.0.Alpha2 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1771) Release WildFly Elytron 1.9.0.CR1

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1771?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1771. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.9.0.CR1 > --------------------------------- > > Key: ELY-1771 > URL: https://issues.jboss.org/browse/ELY-1771 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.9.0.CR1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup

by Laird Nelson (Jira)

[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ] Laird Nelson commented on WFLY-11858: ------------------------------------- {{AbstractBean}} instances are [in {{Dependent}} scope by default|https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/cd...]. Therefore {{JNDIBean}} instances are also in {{Dependent}} scope by default, unless they override the {{getScope()}} method. Indeed, the {{AbstractBean}} subclass created for {{InitialContext}} [overrides the scope to be {{Singleton}}|https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/TransactionExtension.java#L95-L98]. This means that anyone can {{@Inject}} an {{InitialContext}}, for example, and will receive a singleton at the injection point, and multiple creations of {{InitialContext}} will not happen. If for some reason that is illegal or not desired or anything else, you can change this line: https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/cdi/classe... If you eliminate the line, then the scope will be {{Dependent}} once again and a new {{InitialContext}} will be created for each injection point referencing {{InitialContext}}. That obviously has pros and cons. I have [another pull request open|https://github.com/jbosstm/narayana/pull/1403] where I could roll in any change that anyone wants here. > [Wildfly16] CDI fails to inject InitialContext during startup > ------------------------------------------------------------- > > Key: WFLY-11858 > URL: https://issues.jboss.org/browse/WFLY-11858 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Transactions > Affects Versions: 16.0.0.Final > Reporter: Rakesh K. Cherukuri > Assignee: Matej Novotny > Priority: Major > Attachments: stacktrace.log > > > We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error > _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_ > In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error. > Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself. > Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :) > Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession

by David White (Jira)

[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ] David White commented on JGRP-2299: ----------------------------------- Sorry, I am not setup yet to do that. I would appreciate you making the appropriate changes to the method(s). Do you know the reason for the null value? A race condition? The last version I tested with was 4.0.9. This week we started tested with 4.0.13 because that version contains the fix for the locking state transfer issue. It looks like the changes to the Owner class and the introduction of the compareTo method was made specifically to address that issue (see JGRP-2249 and JGRP-2234). > LockService does not work correctly if unlock/lock is called in immediate succession > ------------------------------------------------------------------------------------ > > Key: JGRP-2299 > URL: https://issues.jboss.org/browse/JGRP-2299 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Environment: Windows 10 Oracle JDK 1.8 131 > AIX IBM Java 8 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.20 > > Attachments: JGroupsExample.java, udp+lock.xml > > > In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected. > This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded. > If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock(). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ] Ondra Chaloupka commented on WFLY-11858: ---------------------------------------- [~ljnelson] oh, I got it. My wrong in understanding. [~manovotn][~mkouba] then it's Narayana CDI extension producing the bean :) [~ljnelson] I haven't followed all the details, so the JNDI bean (https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/cdi/classe...) uses the InitialContext created in the extension (https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/cdi/classe...), is the issue of using {{IntialContext}} directly without binding it to the bean? (https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/cdi/classe...) > [Wildfly16] CDI fails to inject InitialContext during startup > ------------------------------------------------------------- > > Key: WFLY-11858 > URL: https://issues.jboss.org/browse/WFLY-11858 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Transactions > Affects Versions: 16.0.0.Final > Reporter: Rakesh K. Cherukuri > Assignee: Matej Novotny > Priority: Major > Attachments: stacktrace.log > > > We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error > _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_ > In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error. > Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself. > Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :) > Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4378) Upgrade WildFly Elytron to 1.9.0.CR1

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-4378: ---------------------------------------- Summary: Upgrade WildFly Elytron to 1.9.0.CR1 Key: WFCORE-4378 URL: https://issues.jboss.org/browse/WFCORE-4378 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 9.0.0.Beta2 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup

by Laird Nelson (Jira)

[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ] Laird Nelson commented on WFLY-11858: ------------------------------------- bq. Hm, who should be producing a bean for the required type javax.naming.InitialContext consumed by https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/cdi/classe... The fact that {{InitialContext}} is being sought as a bean comes from this (approved, merged) PR: https://github.com/jbosstm/narayana/pull/1346 It can be found here: https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/cdi/classe... It is then used here: https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/cdi/classe... So if {{CDI.current()}} doesn't in fact work in all places it can legally be called from then it's possible that that line in {{JNDIBean}} will have to be changed somehow. > [Wildfly16] CDI fails to inject InitialContext during startup > ------------------------------------------------------------- > > Key: WFLY-11858 > URL: https://issues.jboss.org/browse/WFLY-11858 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Transactions > Affects Versions: 16.0.0.Final > Reporter: Rakesh K. Cherukuri > Assignee: Matej Novotny > Priority: Major > Attachments: stacktrace.log > > > We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error > _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_ > In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error. > Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself. > Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :) > Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 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 March 2019