March 2019 - jboss-jira - Jboss List Archives

[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. Laird Nelson I personally like what Martin Kouba affirmed. I understand the idea of the "user-supplied InitialContext bean implementations" but I don't think there is some reasonable demand for it. OK, I'll remove it in my other PR. > [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 Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2299: -------------------------------- I don't know. To know, I'd have to look into this. The compareTo() method should definitely *not* throw an NPE, but I don't know if this is related to the overall issue... Once I get to 4.1.1 (after releasing 4.1.0 as port to GraalVM), I can release relatively quickly. I don't mind if there's just 1 issue in a release... > 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.1.1 > > 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-11883) Incorrect product name used in readmes for ha-singleton-* QS

by Eduardo Martins (Jira)

[ https://issues.jboss.org/browse/WFLY-11883?page=com.atlassian.jira.plugin... ] Eduardo Martins reopened WFLY-11883: ------------------------------------ > Incorrect product name used in readmes for ha-singleton-* QS > ------------------------------------------------------------ > > Key: WFLY-11883 > URL: https://issues.jboss.org/browse/WFLY-11883 > Project: WildFly > Issue Type: Bug > Components: Documentation, Quickstarts > Affects Versions: 16.0.0.Final > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Major > Fix For: 17.0.0.Beta1 > > > The readmes say {{red_hat_jboss_enterprise_application_platform}} instead of {{Red Hat JBoss Enterprise Application Platform}} or simply {{JBoss EAP}}: > * ha-singleton-service: > ** For more information about clustered singleton services, see HA Singleton Service in the Development Guide for red_hat_jboss_enterprise_application_platform located on the Red Hat Customer Portal. > * ha-singleton-deployment: > ** For more information about singleton deployments, see HA Singleton Deployments in the Development Guide for red_hat_jboss_enterprise_application_platform located on the Red Hat Customer Portal. > It's caused by incorrectly defined doc attribute {{DocInfoProductName}} in {{attributes.adoc}}: > {code} > :DocInfoProductName: red_hat_jboss_enterprise_application_platform > :DocInfoProductNameURL: red_hat_jboss_enterprise_application_platform > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-648) Adding Puller Support to Openshift 3.11

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-648?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo resolved SWSQE-648. ------------------------------------------- Release Notes Text: Added support for OCP 3.11 on Puller Resolution: Done > Adding Puller Support to Openshift 3.11 > --------------------------------------- > > Key: SWSQE-648 > URL: https://issues.jboss.org/browse/SWSQE-648 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > Priority: Major > Labels: infrastructure > > Registry puller needs to be added to install OS_VERSION 3.11 -- 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 edited comment on JGRP-2299 at 3/21/19 10:28 AM: ------------------------------------------------------------- Bela - Do you think the fix is truly just adding a null check, or would that be hiding the "real" problem? Should there potentially be null values when the comparison is made? Is there a scheduled date for the release of 4.1.1? Thanks. was (Author: dwhitejazz): Bela - Do you think the fix is truly just adding a null check, or would that be hiding the "real" problem. Should there potentially be null values when then comparison is made? Is there a scheduled date for the release of 4.1.1? Thanks. > 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.1.1 > > 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] (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: ----------------------------------- Bela - Do you think the fix is truly just adding a null check, or would that be hiding the "real" problem. Should there potentially be null values when then comparison is made? Is there a scheduled date for the release of 4.1.1? Thanks. > 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.1.1 > > 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] (DROOLS-3784) Increase the advanced user productivity when he creates a new Data Type

by Liz Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3784?page=com.atlassian.jira.plugi... ] Liz Clayton commented on DROOLS-3784: ------------------------------------- [~dmarrazzo] [~karreiro] WRT 1) The explicit Save is used to support an Edit mode for the rows. It is intended to align with PatternFly guidelines for inline editing: https://www.patternfly.org/pattern-library/forms-and-controls/inline-edit/ > Increase the advanced user productivity when he creates a new Data Type > ----------------------------------------------------------------------- > > Key: DROOLS-3784 > URL: https://issues.jboss.org/browse/DROOLS-3784 > Project: Drools > Issue Type: Epic > Components: DMN Editor > Affects Versions: 7.18.0.Final > Reporter: Donato Marrazzo > Assignee: Guilherme Carreiro > Priority: Minor > Labels: drools-tools > Attachments: type-selector.png > > > The Data Type editor could be improved in terms of productivity and usability. > Ideally, the user should be able to create a complex type minimizing the mouse usage. > 1) Saving the node is an overhead for basic data type (e.g. age: number) > 2) Some actions in the kebab menu should be more visible and available even before saving the type (as standalone icon / buttons). Especially, insert nested, delete. > 3) Select type in the selector by typing the name of the type (see screenshot): it already works but it consider just the first letter typed. Since, by convention, all custom types starts with `t` letter, it would be better consider at least 2 letters. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11890) Upgrade JGroups to 4.1.1.Final

by Radoslav Husar (Jira)

Radoslav Husar created WFLY-11890: ------------------------------------- Summary: Upgrade JGroups to 4.1.1.Final Key: WFLY-11890 URL: https://issues.jboss.org/browse/WFLY-11890 Project: WildFly Issue Type: Component Upgrade Components: Clustering Affects Versions: 16.0.0.Final Reporter: Radoslav Husar Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-648) Adding Puller Support to Openshift 3.11

by Guilherme Baufaker Rêgo (Jira)

Guilherme Baufaker Rêgo created SWSQE-648: --------------------------------------------- Summary: Adding Puller Support to Openshift 3.11 Key: SWSQE-648 URL: https://issues.jboss.org/browse/SWSQE-648 Project: Kiali QE Issue Type: Sub-task Reporter: Guilherme Baufaker Rêgo Registry puller needs to be added to install OS_VERSION 3.11 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-648) Adding Puller Support to Openshift 3.11

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-648?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo reassigned SWSQE-648: --------------------------------------------- Assignee: Guilherme Baufaker Rêgo > Adding Puller Support to Openshift 3.11 > --------------------------------------- > > Key: SWSQE-648 > URL: https://issues.jboss.org/browse/SWSQE-648 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > Priority: Major > Labels: infrastructure > > Registry puller needs to be added to install OS_VERSION 3.11 -- 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