February 2017 - jboss-jira - Jboss List Archives

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

9 years, 3 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)

9 years, 3 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)

9 years, 3 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)

9 years, 3 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)

9 years, 3 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)

9 years, 3 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)

9 years, 3 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)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2255) Upgrade to WildFly Common 1.2.0.Beta5

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-2255: ---------------------------------------- Summary: Upgrade to WildFly Common 1.2.0.Beta5 Key: WFCORE-2255 URL: https://issues.jboss.org/browse/WFCORE-2255 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha23 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1855) Possible NPE on controller service start

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1855?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1855: ------------------------------------------ https://github.com/bstansberry/wildfly-core/tree/WFCORE-1855 is WIP on this. Kind of a workaround. I opened up a PR for it but I think I'll withdraw it for now as it's a bit out of date and I don't feel urgency to get this particular solution in. > Possible NPE on controller service start > ---------------------------------------- > > Key: WFCORE-1855 > URL: https://issues.jboss.org/browse/WFCORE-1855 > Project: WildFly Core > Issue Type: Bug > Reporter: David Lloyd > Assignee: Brian Stansberry > > In {{org.jboss.as.controller.AbstractControllerService}}, the {{start}} method starts up a background thread which performs a certain amount of the boot process. Before this thread is started, a volatile field {{controller}} is initialized with the controller reported by the {{start()}} method. > Inside this thread, some work is performed, and at the end of a certain amount of work, the {{finishBoot()}} method is invoked. This method calls {{controller.finishBoot()}}, referencing the field that was set in the {{start()}} method. > The problem arises when the service itself is stopped before the boot thread completes. This causes the {{controller}} field to be nulled out, resulting in an NPE. > I think we need to look at: > * Why are we using a background thread for this? > * Why are we _not_ using the asynchronous startup feature? > I think we must do one of these two things in order to make this code "safe". -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 February 2017