[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)
11 years, 7 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)
11 years, 7 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)
11 years, 7 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)
11 years, 7 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)
11 years, 7 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)
11 years, 7 months
[JBoss JIRA] (WFCORE-295) Add unit tests for Default*DescriptionProvider
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-295?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3504 to WFCORE-295:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-295 (was: WFLY-3504)
Component/s: Domain Management
(was: Domain Management)
> Add unit tests for Default*DescriptionProvider
> ----------------------------------------------
>
> Key: WFCORE-295
> URL: https://issues.jboss.org/browse/WFCORE-295
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Tomaz Cerar
>
> We need proper tests for at least
> - DefaultResourceAddDescriptionProvider
> - DefaultResourceDescriptionProvider
> - DefaultOperationDescriptionProvider
> as they are now tested as part of subsystem tests but they themselfs don't have any proper tests.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFCORE-294) support a form of modular XML configuration file
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-294?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3510 to WFCORE-294:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-294 (was: WFLY-3510)
Component/s: Domain Management
(was: Domain Management)
> support a form of modular XML configuration file
> ------------------------------------------------
>
> Key: WFCORE-294
> URL: https://issues.jboss.org/browse/WFCORE-294
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
> Priority: Minor
>
> I realise the history of wildfly & that things used to use many XML files and there was a move to unify things. But some modularity of configuration can be a good thing ;)
> With layered products it would be handy to allow separate XML configuration files to configure separate layers/features/parts. e.g. one for web, one for FSW, one for Infinispan/JDG, one for Portal and so forth. e.g. a layered product could release its own XML configuration file by default.
> Rather than it being subsystem specific (e.g. each layer may need to define a database) its more a way of grouping parts of the XML into a separate underlying source XML file.
> e.g. so folks could combine any of the (say) 4 XML files for web / FSW / JDG / Portal to make a configuration for a new wildfly container with different pieces depending on how folks want to map features to JVMs.
> e.g. rather than specifying a single XML file to startup, we'd allow specifying N different XML files with 1 configuration file being the default file used for adding new subsystems; otherwise the configuration system would remember which file a particular bit of configuration comes from; so if its changed, it knows which configuration needs to be written to which file.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFCORE-294) support a form of modular XML configuration file
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-294?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-294:
------------------------------------
Assignee: Alexey Loubyansky (was: Jason Greene)
> support a form of modular XML configuration file
> ------------------------------------------------
>
> Key: WFCORE-294
> URL: https://issues.jboss.org/browse/WFCORE-294
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> I realise the history of wildfly & that things used to use many XML files and there was a move to unify things. But some modularity of configuration can be a good thing ;)
> With layered products it would be handy to allow separate XML configuration files to configure separate layers/features/parts. e.g. one for web, one for FSW, one for Infinispan/JDG, one for Portal and so forth. e.g. a layered product could release its own XML configuration file by default.
> Rather than it being subsystem specific (e.g. each layer may need to define a database) its more a way of grouping parts of the XML into a separate underlying source XML file.
> e.g. so folks could combine any of the (say) 4 XML files for web / FSW / JDG / Portal to make a configuration for a new wildfly container with different pieces depending on how folks want to map features to JVMs.
> e.g. rather than specifying a single XML file to startup, we'd allow specifying N different XML files with 1 configuration file being the default file used for adding new subsystems; otherwise the configuration system would remember which file a particular bit of configuration comes from; so if its changed, it knows which configuration needs to be written to which file.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months