February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8007) Replace WorkManager elytron-enabled atttribute by elytron-security-domain

by Flavia Rainone (JIRA)

[ https://issues.jboss.org/browse/WFLY-8007?page=com.atlassian.jira.plugin.... ] Flavia Rainone reassigned WFLY-8007: ------------------------------------ Assignee: James Perkins (was: Stefano Maestri) [~jamezp], do you think you will have time to look into this other Capability-related issue before the next release? Let me know if that's not the case, either I or [~maeste] will work on this Jira. Thanks a lot! > Replace WorkManager elytron-enabled atttribute by elytron-security-domain > ------------------------------------------------------------------------- > > Key: WFLY-8007 > URL: https://issues.jboss.org/browse/WFLY-8007 > Project: WildFly > Issue Type: Enhancement > Components: JCA > Reporter: Flavia Rainone > Assignee: James Perkins > > Right now the elytron-enabled attribute does not allow the dependency on the security domain capability. We need to replace it by elytron-security-domain and have the capability dependency sorted out. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1620) Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1620?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1620: ------------------------------------- Fix Version/s: 2.2.1.Final > Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22 > ----------------------------------------------------- > > Key: WFCORE-1620 > URL: https://issues.jboss.org/browse/WFCORE-1620 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: James Perkins > Assignee: Frank Langelage > Fix For: 3.0.0.Alpha18, 2.2.1.Final > > > There should no longer be a need for the forked version. The fix for [SLF4J-167|http://jira.qos.ch/browse/SLF4J-167] should be in version 1.7.14 with some additional fixes for replaying the previously lost logs. > [Quote from comment on JIRA|http://jira.qos.ch/browse/SLF4J-167?focusedCommentId=17048&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17048] > {quote} > The problem of lost logs during initialization in a multi-threaded application is solved by storing and replaying the logs which would be otherwise lost. Fix available in SLF4J version 1.7.15. > {quote} > Analysis will need to be done to ensure this works as expected before the fork is no longer required. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8009) Write a test for Resource Adapters using Elytron

by Flavia Rainone (JIRA)

Flavia Rainone created WFLY-8009: ------------------------------------ Summary: Write a test for Resource Adapters using Elytron Key: WFLY-8009 URL: https://issues.jboss.org/browse/WFLY-8009 Project: WildFly Issue Type: Enhancement Components: JCA Reporter: Flavia Rainone Write a basic test case to make sure everything needed to make Resource Adapters + Elytron work is in place. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2256) Undertow 1.4.10.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2256?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2256: ---------------------------------------- Fix Version/s: 3.0.0.Alpha23 Assignee: Stuart Douglas Resolution: Done > Undertow 1.4.10.Final > --------------------- > > Key: WFCORE-2256 > URL: https://issues.jboss.org/browse/WFCORE-2256 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 3.0.0.Alpha23 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1987) Create request/response reporting mechanism

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1987?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1987: ------------------------------------------ I would expect getDomainResults to return an undefined node for a write-attribute call. The key thing is it's concerned with the *result* child of the response that goes to the user, not the complete response. The result of a write-attribute is 'undefined': {code} { "outcome" => "success", "result" => undefined } {code} Does the A2 node have the warnings you expect? If so you'll need to propagate those to A1 by reading them from A2 and calling context.addWarning, similarly to how it currently reads the result from A2 and passes it to A1 by calling context.getResult().set(...) What needs thought is how to deal with warnings that come from slave HCs and from the servers as part of domain rollout. My impression from your comments is that in the case of servers, the 'server-results' structure is showing the warnings from the servers, as part of each server's response. Correct? If so, that sounds ok. For these domain rollout ops, I think it's fine to ignore warnings from the slave HCs. They should be redundant, same as what the master generated in your A2 response. All this is about ops that result in a domain-wide rollout (i.e. that go the OperationCoordinatorStepHandler.executeTwoPhaseOperation path). This feature also needs to deal with ops that go the executeDirect path or that are proxied steps in a composite that goes the executeTwoPhaseOperation. That is /host=slave:do-something-that-generates-a-warn or /host=slave/server=a:do-something-that-generates-a-warn or /host=master/server=a:do-something-that-generates-a-warn Aha! It looks like that is largely handled. See ProxyStepHandler L199-201 -- any headers from the proxied process are copied into the local response. This will all need to be verified via tests. > Create request/response reporting mechanism > ------------------------------------------- > > Key: WFCORE-1987 > URL: https://issues.jboss.org/browse/WFCORE-1987 > Project: WildFly Core > Issue Type: Enhancement > Components: Remoting > Reporter: Radim Hatlapatka > Assignee: Bartosz Baranowski > Labels: downstream_dependency > > In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance JBEAP-7284. > Scope of this enhancement are: > a) way to send back information > b) control level of "information" - just like in case of loggers > a) Information will be sent in response headers, under "warnings" key. Each entry, "warning" will contain operation, address, level/severity and i18n string with proper ID. > b) default level threshold would be "WARNING", if user requires more detailed information, he can request it via operation-headers->warninig-level > Example: > {noformat} > { > "outcome" => "success", > "response-headers" => { > "warnings" => [ > { > "warning" => "WFLYCTL0436: Couldn't convert 'XXX' into proper warning level, threshold falling back to 'ALL'. Possible values: SEVERE,WARNING,INFO,CONFIG,FINE,FINER,FINEST", > "level" => "ALL", > "operation" => { > "address" => [ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ], > "operation" => "write-attribute" > } > }, > { > "warning" => "WFLYUT0090: Worker used in http-listener: 'puppet-master', must be used in remoting subsystem.", > "level" => "WARNING", > "operation" => { > "address" => [ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ], > "operation" => "write-attribute" > } > } > ], > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2238) Drop the inflowed security domains attribute from access=identity

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2238?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2238: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2143 (was: https://github.com/wildfly/wildfly-core/pull/2134) > Drop the inflowed security domains attribute from access=identity > ----------------------------------------------------------------- > > Key: WFCORE-2238 > URL: https://issues.jboss.org/browse/WFCORE-2238 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Alpha23 > > > We may restore it later so don't remove the code that uses it but remove it from the management model. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2089) Infinite wildfly boot on StartException in service start

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2089?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2089: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2143 (was: https://github.com/wildfly/wildfly-core/pull/2053) > Infinite wildfly boot on StartException in service start > -------------------------------------------------------- > > Key: WFCORE-2089 > URL: https://issues.jboss.org/browse/WFCORE-2089 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Jan Kalina > Assignee: ehsavoie Hugonnet > Priority: Blocker > Attachments: threads-2.txt, threads.txt > > > Following exception (and probably similar too) will cause wildfly frozing during start. Visible especially during integration tests (which will never ends), but reproducible directly too (see steps). > {code:java} > 15:59:37,252 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in password property file > at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:185) > at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:164) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} > *Update:* This problem with infinite boot will occure everytime the start() method of some service throws StartException(). Not an Elytron problem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2256) Undertow 1.4.10.Final

by Stuart Douglas (JIRA)

Stuart Douglas created WFCORE-2256: -------------------------------------- Summary: Undertow 1.4.10.Final Key: WFCORE-2256 URL: https://issues.jboss.org/browse/WFCORE-2256 Project: WildFly Core Issue Type: Component Upgrade Reporter: Stuart Douglas -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2216) CLI fails to reload when connection upgrades from http to https

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2216?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2216: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2126 (was: https://github.com/wildfly/wildfly-core/pull/2113) > CLI fails to reload when connection upgrades from http to https > --------------------------------------------------------------- > > Key: WFCORE-2216 > URL: https://issues.jboss.org/browse/WFCORE-2216 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Alpha23 > > > reload command should manage to reconnect to a server reconfigured with https management interface. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2223) Setting JBOSS_MODULEPATH is lost for second start of embed-server

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2223?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2223: ---------------------------------------- Fix Version/s: 3.0.0.Alpha23 Assignee: Brian Stansberry (was: Jean-Francois Denise) Resolution: Done > Setting JBOSS_MODULEPATH is lost for second start of embed-server > ----------------------------------------------------------------- > > Key: WFCORE-2223 > URL: https://issues.jboss.org/browse/WFCORE-2223 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Server > Reporter: Josef Cacek > Assignee: Brian Stansberry > Priority: Critical > Fix For: 3.0.0.Alpha23 > > > When {{embed-server}} command is used more times in the CLI and a custom {{JBOSS_MODULEPATH}} is configured, then only the first server start uses the correct module path. > The subsequent `embed-server` call results in error: > {code} > Cannot start embedded server: WFLYEMB0022: Cannot invoke 'start' on embedded process: WFLYSRV0118: Determined modules directory does not exist: /tmp/jboss-eap-7.0-no-modules/modules > {code} > Using the {{JBOSS_MODULEPATH}} environment variable is documented in https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2017