[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
[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
[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
[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
[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
[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