[JBoss JIRA] (WFCORE-309) system properties are trim()'d and loose whitespace
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-309?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-309:
---------------------------------------
Assignee: Tom Fonteyne (was: Brian Stansberry)
Tom, you mentioned sending up a PR for this. Do you still intend to do that? If not, please reassign back to me.
We should do this soon if we want it in WF 9.
> system properties are trim()'d and loose whitespace
> ---------------------------------------------------
>
> Key: WFCORE-309
> URL: https://issues.jboss.org/browse/WFCORE-309
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Tom Fonteyne
> Assignee: Tom Fonteyne
> Fix For: 1.0.0.Beta1
>
>
> When a system property was defined as:
> /system-property=foo:add(value=" spaces ");
> it gets written with the correct spaces around it to the configuration file.
> When the configuration is read the value gets trimmed and the prefix/suffix of spaces is lost.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (WFCORE-309) system properties are trim()'d and loose whitespace
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-309?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3170 to WFCORE-309:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-309 (was: WFLY-3170)
Affects Version/s: (was: 8.1.0.CR1)
Component/s: Domain Management
(was: Domain Management)
> system properties are trim()'d and loose whitespace
> ---------------------------------------------------
>
> Key: WFCORE-309
> URL: https://issues.jboss.org/browse/WFCORE-309
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
>
> When a system property was defined as:
> /system-property=foo:add(value=" spaces ");
> it gets written with the correct spaces around it to the configuration file.
> When the configuration is read the value gets trimmed and the prefix/suffix of spaces is lost.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (WFCORE-308) Switch default of skip-group-loading to 'true' for local auth.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-308?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3216 to WFCORE-308:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-308 (was: WFLY-3216)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Beta1
(was: 9.0.0.Beta1)
> Switch default of skip-group-loading to 'true' for local auth.
> --------------------------------------------------------------
>
> Key: WFCORE-308
> URL: https://issues.jboss.org/browse/WFCORE-308
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> The new attribute skip-group-loading was added to the local authentication definition by WFLY-3048 this needed to have a default of false for backwards compatibility purposes however in reality most would probably assume a default of true.
> For WildFly 9 switch the default to true. This change in default should probably only occur if the schema version is 3 or above.
> A transformer should not be required as this is not configuration that is propagated around a domain.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (WFCORE-307) When Wildfly fails with JBAS015810: failed to resolve interface management, it should terminate.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-307?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3264 to WFCORE-307:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-307 (was: WFLY-3264)
Affects Version/s: (was: 8.1.0.CR1)
Component/s: Domain Management
(was: Domain Management)
> When Wildfly fails with JBAS015810: failed to resolve interface management, it should terminate.
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-307
> URL: https://issues.jboss.org/browse/WFCORE-307
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Jay Kumar SenSharma
>
> - When Wildfly fails with **JBAS015810: failed to resolve interface management**, it should terminate rather than dangling.
> - When starting the Wildfly with an IP address which is non-existent, you get the error 'JBAS015810: failed to resolve interface management'.
> -The server starts, but with the error message :
> {code}
> 10:41:15,390 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.network.public: org.jboss.msc.service.StartException in service jboss.network.public: JBAS015810: failed to resolve interface public
> at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:96) [wildfly-server-8.1.0.CR1.jar:8.1.0.CR1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 10:41:15,390 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.network.management: org.jboss.msc.service.StartException in service jboss.network.management: JBAS015810: failed to resolve interface management
> at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:96) [wildfly-server-8.1.0.CR1.jar:8.1.0.CR1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {code}
> - Since the server could not bind to the given address and port, and neither the cli nor the admin console are enabled, the server is as good as dead. The server should exit instead of starting up with errors when this of error is seen .
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3288 to WFCORE-306:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-306 (was: WFLY-3288)
Component/s: Domain Management
Scripts
(was: Domain Management)
(was: Scripts)
Fix Version/s: (was: Awaiting Volunteers)
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFCORE-306
> URL: https://issues.jboss.org/browse/WFCORE-306
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (WFCORE-305) Future returned by ModelControllerClient executeAsync does not provide reliable return value from "cancel"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-305?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3363 to WFCORE-305:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-305 (was: WFLY-3363)
Affects Version/s: (was: 8.1.0.CR2)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: (was: 9.0.0.Beta1)
> Future returned by ModelControllerClient executeAsync does not provide reliable return value from "cancel"
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-305
> URL: https://issues.jboss.org/browse/WFCORE-305
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emanuel Muckenhuber
>
> DelegatingCancellableAsyncFuture.asyncCancel does not block waiting for the response to the cancel request. As result it is a race whether the status is not reliably set to CANCELLED before that value is tested to determine whether to return true/false.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (WFCORE-299) HTTP Management Interface Configuration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-299?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-2635 to WFCORE-299:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-299 (was: WFLY-2635)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Beta1
(was: 9.0.0.Beta1)
> HTTP Management Interface Configuration
> ---------------------------------------
>
> Key: WFCORE-299
> URL: https://issues.jboss.org/browse/WFCORE-299
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: management_security,, management_sso
> Fix For: 1.0.0.Beta1
>
>
> Various configuration items are required for the HTTP Management interface, this is a parent task to combine them.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (WFCORE-298) Provide configuration to define when config changes are pushed to servers in a domain
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-298?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3390 to WFCORE-298:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-298 (was: WFLY-3390)
Component/s: Domain Management
(was: Domain Management)
> Provide configuration to define when config changes are pushed to servers in a domain
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-298
> URL: https://issues.jboss.org/browse/WFCORE-298
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Labels: EAP
>
> An EAP customer request:
> Right now, any changes done via the CLI to an active profile are pushed to all instances immediately. Some go life, some at reload only
> While batch mode can be used to bundle a number of changes in one go, there is currently no way to tell individual servers or server-groups when to accept updates or not.
> This proposal is to allow a config switch on servergroup level and on individual server level to accept a configuration change selectively:
> 1. immediate, the current situation, being the default
> 2. at restart only
> 3. at explicit being told so, e.g. when a "reload" is ordered
> Example:
> <server name="server-three" group="other-server-group" updates="immediate">
> the default when the attribute is absent
> <server name="server-three" group="other-server-group" updates="start">
> <server name="server-three" group="other-server-group" updates="explicit">
> The latter could then be triggered with:
> /host=master/server-config=server1:reload
> Similar option could be set on servergroup level, with a similar reload command on that level
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (WFCORE-297) HC should remember the 'run' state of the server instances after crash or shutdown
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-297?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3428 to WFCORE-297:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-297 (was: WFLY-3428)
Component/s: Domain Management
(was: Domain Management)
> HC should remember the 'run' state of the server instances after crash or shutdown
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-297
> URL: https://issues.jboss.org/browse/WFCORE-297
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Wolf-Dieter Fink
> Assignee: Brian Stansberry
> Labels: EAP, todo
>
> The host controller should save which server is currently up and running. This would allow the host controller to bring up all previously running instances on a restart.
> The idea is to support the same behavior that other application server (i.e WebLogic) supports.
> If a server is started or stopped during the lifetime of the DC/HC it should be in the same state after shutdown the DC/HC or a system crash.
> This can be achieved by an optional flag 'set-auto-start-on-start-stop' where the default is false which is the current behaviour.
> If set to true, a start of the server instance will set auto-start=true and a stop auto-start=false.
> If the server should not be started after a crash for any reason, this can be simple done by setting auto-start=false within the configuration, after starting the server the flag will be set b/c of the 'set-auto-start-on-start-stop' flag.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (WFCORE-296) Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-296?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3433 to WFCORE-296:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-296 (was: WFLY-3433)
Component/s: CLI
Domain Management
(was: CLI)
(was: Domain Management)
Fix Version/s: 1.0.0.Beta1
(was: 9.0.0.Beta1)
> Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-296
> URL: https://issues.jboss.org/browse/WFCORE-296
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI, Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> From [~dmlloyd]
> {quote}
> When we have multi-layer protocol going on, the URI scheme we should use
> is like this:
> outer+middle+inner://
> {quote}
> Switch URI schemes from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://
> The existing schemes will be needed for backwards compatibility but somehow deprecated.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months