February 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1935) Backport new MicroProfile JWT module

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1935?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved ELY-1935. ----------------------------------- Resolution: Done > Backport new MicroProfile JWT module > ------------------------------------ > > Key: ELY-1935 > URL: https://issues.redhat.com/browse/ELY-1935 > Project: WildFly Elytron > Issue Type: Bug > Components: MicroProfile > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.10.5.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-98) Update WildFly Elytron to 1.10.5.Final

by Darran Lofthouse (Jira)

Darran Lofthouse created ELYWEB-98: -------------------------------------- Summary: Update WildFly Elytron to 1.10.5.Final Key: ELYWEB-98 URL: https://issues.redhat.com/browse/ELYWEB-98 Project: Elytron Web Issue Type: Component Upgrade Components: Parent Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.6.1.CR1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13124) Upgrade RESTEasy to 3.11.0.Final

by Alessio Soldano (Jira)

Alessio Soldano created WFLY-13124: -------------------------------------- Summary: Upgrade RESTEasy to 3.11.0.Final Key: WFLY-13124 URL: https://issues.redhat.com/browse/WFLY-13124 Project: WildFly Issue Type: Component Upgrade Components: MP REST Client, REST Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 19.0.0.Beta3 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1890) Keep file permissions when modifying an existing credential store

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1890?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1890: ---------------------------------- Fix Version/s: 1.10.5.CR1 > Keep file permissions when modifying an existing credential store > ----------------------------------------------------------------- > > Key: ELY-1890 > URL: https://issues.redhat.com/browse/ELY-1890 > Project: WildFly Elytron > Issue Type: Bug > Components: Command-Line Tool > Affects Versions: 1.11.0.CR1 > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Priority: Major > Fix For: 1.10.5.CR1 > > > Using the offline elytron.sh tool, after creating the credential store I changed the mode to 600. Using the elytron.sh tool to add credentials changes the mode back to 644. Is that intentional for it to automatically do that? I would either expect it to not change and update or not change and error out. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13123) Server stopping at RemoteEJBClientStatefulBeanFailoverTestCase needs to be guarded with timeout otherwise the server stop may stuck further test processing

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/WFLY-13123?page=com.atlassian.jira.plugi... ] Ondrej Chaloupka updated WFLY-13123: ------------------------------------ Description: The clustering test {{RemoteEJBClientStatefulBeanFailoverTestCase/RemoteEJBClientStatefulFailoverTestBase}} works with stopping WildFly server to check how clustering and balancing of ejb client works. The call of the management operation {{stop}} is not guarded with timeout option currently. That could make a trouble (and at Narayana CI) of long standing stopping server which is waiting to be stopped. The {{stop}} operation should be guarded with timeout option to not being infinite. was: The clustering test {{RemoteEJBClientStatefulFailoverTestBase}} works with stopping WildFly server to check how clustering and balancing of ejb client works. The call of the management operation {{stop}} is not guarded with timeout option currently. That could make a trouble (and at Narayana CI) of long standing stopping server which is waiting to be stopped. The {{stop}} operation should be guarded with timeout option to not being infinite. > Server stopping at RemoteEJBClientStatefulBeanFailoverTestCase needs to be guarded with timeout otherwise the server stop may stuck further test processing > ----------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13123 > URL: https://issues.redhat.com/browse/WFLY-13123 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 19.0.0.Beta2 > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > The clustering test {{RemoteEJBClientStatefulBeanFailoverTestCase/RemoteEJBClientStatefulFailoverTestBase}} works with stopping WildFly server to check how clustering and balancing of ejb client works. > The call of the management operation {{stop}} is not guarded with timeout option currently. > That could make a trouble (and at Narayana CI) of long standing stopping server which is waiting to be stopped. > The {{stop}} operation should be guarded with timeout option to not being infinite. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13123) Server stopping at RemoteEJBClientStatefulBeanFailoverTestCase needs to be guarded with timeout otherwise the server stop may stuck further test processing

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/WFLY-13123?page=com.atlassian.jira.plugi... ] Ondrej Chaloupka updated WFLY-13123: ------------------------------------ Summary: Server stopping at RemoteEJBClientStatefulBeanFailoverTestCase needs to be guarded with timeout otherwise the server stop may stuck further test processing (was: Server stopping at RemoteEJBClientStatefulFailoverTestBase needs to be guarded with timeout otherwise the server stop may stuck further test processing) > Server stopping at RemoteEJBClientStatefulBeanFailoverTestCase needs to be guarded with timeout otherwise the server stop may stuck further test processing > ----------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13123 > URL: https://issues.redhat.com/browse/WFLY-13123 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 19.0.0.Beta2 > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > The clustering test {{RemoteEJBClientStatefulFailoverTestBase}} works with stopping WildFly server to check how clustering and balancing of ejb client works. > The call of the management operation {{stop}} is not guarded with timeout option currently. > That could make a trouble (and at Narayana CI) of long standing stopping server which is waiting to be stopped. > The {{stop}} operation should be guarded with timeout option to not being infinite. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13123) Server stopping at RemoteEJBClientStatefulFailoverTestBase needs to be guarded with timeout otherwise the server stop may stuck further test processing

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created WFLY-13123: --------------------------------------- Summary: Server stopping at RemoteEJBClientStatefulFailoverTestBase needs to be guarded with timeout otherwise the server stop may stuck further test processing Key: WFLY-13123 URL: https://issues.redhat.com/browse/WFLY-13123 Project: WildFly Issue Type: Bug Components: Test Suite Affects Versions: 19.0.0.Beta2 Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka The clustering test {{RemoteEJBClientStatefulFailoverTestBase}} works with stopping WildFly server to check how clustering and balancing of ejb client works. The call of the management operation {{stop}} is not guarded with timeout option currently. That could make a trouble (and at Narayana CI) of long standing stopping server which is waiting to be stopped. The {{stop}} operation should be guarded with timeout option to not being infinite. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12681) Provide a 'microprofile' Galleon layer

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12681?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-12681: ---------------------------------- Component/s: MP Config MP Fault Tolerance MP Health MP JWT MP Metrics MP OpenAPI MP OpenTracing > Provide a 'microprofile' Galleon layer > -------------------------------------- > > Key: WFLY-12681 > URL: https://issues.redhat.com/browse/WFLY-12681 > Project: WildFly > Issue Type: Feature Request > Components: Build System, MP Config, MP Fault Tolerance, MP Health, MP JWT, MP Metrics, MP OpenAPI, MP OpenTracing > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Labels: Microprofile > > We used to have a 'microprofile' layer spec aggregating all MP specs which at the moment only contained config, health and metrics which got renamed to 'observability' by WFLY-11774. > With the introduction of new specs fault tolerance, openapi, etc. we should reintroduce the 'microprofile' layer spec which contains all of the MP specs. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13101) Tests for MicroProfile Health 2.2

by Fabio Burzigotti (Jira)

[ https://issues.redhat.com/browse/WFLY-13101?page=com.atlassian.jira.plugi... ] Fabio Burzigotti closed WFLY-13101. ----------------------------------- Resolution: Won't Do > Tests for MicroProfile Health 2.2 > --------------------------------- > > Key: WFLY-13101 > URL: https://issues.redhat.com/browse/WFLY-13101 > Project: WildFly > Issue Type: Task > Components: Test Suite > Affects Versions: 19.0.0.Beta2 > Reporter: Fabio Burzigotti > Assignee: Fabio Burzigotti > Priority: Major > Fix For: 19.0.0.Beta3 > > > Providing missing test coverage following the upgrade of MicroProfile Health to 2.2 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-482?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-482: -------------------------------------- Thanks for the feedback [~marlowa42]. WildFly itself uses jboss-logging as it's logging facade. This is akin to slf4j as it's just a facade so that part shouldn't be an issue. None of WildFly Core or WildFly itself uses log4j. With the minor exception of the logging subsystem, but that is only used to configure a deployment which uses a log4j configuration file. The issue is more with the log manager itself. For the log manager WildFly uses the JBoss Log Manager which is an extension of JUL. Both log4j is a log manager. With log4j2 it's somewhat separated where they have a logging facade, log4j-api, and a log manager implementation. What this JIRA would solve is having a log4j2 API implementation that can write to the jboss-logmanager. What I mean by this is that the reason log4j2 is not currently supported is that there is not log4j-api -> JUL library or log4j-api -> jboss-logmanager library. Currently, at least as far as I know, the only log4j-api implementation is log4j-core which is it's own log manager and you can't really have two log managers being used. I've got a project that does handle this, but I'm experimenting a bit with what could happen when a user does provide log4j-core in their deployment as they may be wanting to use some of the features, like async-loggers, for their deployment. > Add log4j2 support for WildFly > ------------------------------ > > Key: WFCORE-482 > URL: https://issues.redhat.com/browse/WFCORE-482 > Project: WildFly Core > Issue Type: Task > Components: Logging > Environment: Spring 3, Hibernate, Wicket, JBoss AS7 > Reporter: Amarkanth Ranganamayna > Assignee: James Perkins > Priority: Major > > I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2. > Looks like Jboss AS7 by default use log4j 1.x > Are you guys already working on using log4j2 ? > If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging. > Thanks, > Amar -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 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 February 2020