[JBoss JIRA] (WFWIP-24) [Artemis 2.x Upgrade] Last value queues do not work
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/WFWIP-24?page=com.atlassian.jira.plugin.s... ]
Jiri Ondrusek reassigned WFWIP-24:
----------------------------------
Assignee: Jiri Ondrusek (was: Martyn Taylor)
> [Artemis 2.x Upgrade] Last value queues do not work
> ---------------------------------------------------
>
> Key: WFWIP-24
> URL: https://issues.jboss.org/browse/WFWIP-24
> Project: WildFly WIP
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Jiri Ondrusek
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> Last value queues are not working as expected.
> # Set {{last-value-queue="true"}} for an address settings {{#}}
> # Send 10 messages with {{message.setStringProperty("_AMQ_LVQ_NAME", "myProperty");}}
> # Receiver receives 10 messages. (it is expected to receive the single message)
> This looks like broker related regression against Artemis 1.5.
> Wildfly: {{https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_with_prefix}} (c692e8327023f9bc40699a6863b4197cc7c1b3c8)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 11 months
[JBoss JIRA] (WFCORE-1723) OperationRequestCompleter ignores CommandArgument#canAppearNext in choosing ValueCompleter when there's more then one indexed arguments
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1723?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1723:
----------------------------------------------
[~spyrkob], I think this one can be closed, the CommandArgument#canAppearNext is not the right choice to develop CLI commands, aesh API is the way to go.
> OperationRequestCompleter ignores CommandArgument#canAppearNext in choosing ValueCompleter when there's more then one indexed arguments
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1723
> URL: https://issues.jboss.org/browse/WFCORE-1723
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha5
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Bartosz Spyrko-Śmietanko
>
> If there are two or more indexed CommandArguments that can be used to complete user entry at the same index, the first one will always be chosen - even if it clashes with previous arguments.
> For example:
> {{patch rollback ..<TAB>}}
> produces a list of directories - this is because PatchHandler registers multiple CommandArguments with index 1 and in this case a completer for patch apply is the first one matched.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 11 months
[JBoss JIRA] (WFCORE-418) Input/Output Formats Should Be Standard Formats (json/yaml/etc)
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-418?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise commented on WFCORE-418:
---------------------------------------------
[~cpitman], output can be json now. We don't plan to support json as input. Can we close this one?
> Input/Output Formats Should Be Standard Formats (json/yaml/etc)
> ---------------------------------------------------------------
>
> Key: WFCORE-418
> URL: https://issues.jboss.org/browse/WFCORE-418
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Environment: RHEL 6.4, x86_64
> Reporter: Chris Pitman
> Assignee: Jean-Francois Denise
> Labels: automation, cli, configuration_management, json
>
> The purpose of the CLI is to improve automation for administrators, but the format used for data is a non-standard format that cannot be easily parsed or generated by any language.
> The format is *really* close to json, but with enough deviation to make munging it a pain: replace hash rockets (=>) with colons, undefined with null, and key value pairs ("(a => b)") with hashes ("{a : b}"). Going in the opposite direction requires some sort of cleverness to determine what is a key-value pair, which is not fun.
> The CLI should support both output and input in a standard format, so that the above hoops do not have to be jumped through.
> Steps to Reproduce:
> 1. Connect to the jboss cli
> 2. Execute "/:whoami"
> Actual results:
> {
> "outcome" => "success",
> "result" => {"identity" => {
> "username" => "$local",
> "realm" => "ManagementRealm"
> }},
> "response-headers" => {"process-state" => "reload-required"}
> }
> Expected results:
> {
> "outcome": "success",
> "result": {"identity": {
> "username": "$local",
> "realm": "ManagementRealm"
> }},
> "response-headers": {"process-state": "reload-required"}
> }
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 11 months
[JBoss JIRA] (WFCORE-1840) patch rollback should suggest installed patch ids
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1840?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1840:
----------------------------------------------
[~spyrkob], this one should be marked resolved.
> patch rollback should suggest installed patch ids
> -------------------------------------------------
>
> Key: WFCORE-1840
> URL: https://issues.jboss.org/browse/WFCORE-1840
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Affects Versions: 3.0.0.Alpha8
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Bartosz Spyrko-Śmietanko
> Labels: downstream_dependency
>
> patch rollback <TAB> currently suggests named parameters, but it doesn't give user a clue that a patch id is needed. eg:
> {noformat}
> [disconnected /] patch rollback --
> --override-all --override-modules --override= --preserve= --reset-configuration= --rollback-to
> {noformat}
> A list of installed patches should be added to the suggestions. If there are no patches installed on the system, 'rollback' action should not be suggested on patch <TAB>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 11 months
[JBoss JIRA] (WFCORE-427) CLI doesn't read alias from .jbossclirc
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-427?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise resolved WFCORE-427.
-----------------------------------------
Fix Version/s: 4.0.0.Final
Resolution: Done
> CLI doesn't read alias from .jbossclirc
> ---------------------------------------
>
> Key: WFCORE-427
> URL: https://issues.jboss.org/browse/WFCORE-427
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Osamu Nagano
> Assignee: Jean-Francois Denise
> Fix For: 4.0.0.Final
>
>
> By WFLY-1063, a variable can be defined in .jbossclirc and preloaded by CLI. But aliases are not able to define with {{org.jboss.as.cli.CliInitializationException}}.
> {code}
> $ cat .jbossclirc
> set prod_db=/subsystem=datasources/data-source=ExampleDS
> alias ll=ls -l
> $ $JBOSS_HOME/bin/jboss-cli.sh -c
> Unexpected command 'alias ll=ls -l'. Type 'help --commands' for the list of supported commands.
> org.jboss.as.cli.CliInitializationException: Failed to process /home/onagano/cases/01180422/wf810/.jbossclirc
> at org.jboss.as.cli.impl.CliLauncher.runcom(CliLauncher.java:352)
> at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:305)
> at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:273)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> {code}
> Enclosing by single quote or double quote won't help.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 11 months
[JBoss JIRA] (WFCORE-1613) Merge Parsers and Completers
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1613?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-1613:
-----------------------------------------
Priority: Minor (was: Major)
> Merge Parsers and Completers
> ----------------------------
>
> Key: WFCORE-1613
> URL: https://issues.jboss.org/browse/WFCORE-1613
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Priority: Minor
>
> Today we have multiple parsers and completers for the same kind of syntax. It implies that any evolution done at the syntax level, needs to be duplicated in multiple places. We would have a big maintainability gain if they were merged them all together. That would also be a big effort.
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 11 months
[JBoss JIRA] (WFCORE-3222) CLI commands management
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3222?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-3222:
----------------------------------------------
There are no plans to discover third party commands.
> CLI commands management
> -----------------------
>
> Key: WFCORE-3222
> URL: https://issues.jboss.org/browse/WFCORE-3222
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> With the evolution of CLI to support aesh 1.0 commands, we have new use cases that CLI needs to handle. For example, to take benefit of third-party aesh commands (eg: aesh-extensions), the CLI must be able to load commands dynamically.
> Currently it is difficult or impossible to achieve the following use cases:
> List all commands
> List enabled commands
> List disabled commands
> List deprecated commands
> List commands that are loaded from extensions
> Display errors that occurred loading commands
> List commands loaded from ServiceLoader
> Load commands dynamically from a jar
> Load commands dynamically from a module
> A dedicated command should be designed to help achieve these use cases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 11 months
[JBoss JIRA] (WFCORE-3222) CLI commands management
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3222?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise closed WFCORE-3222.
----------------------------------------
Resolution: Rejected
> CLI commands management
> -----------------------
>
> Key: WFCORE-3222
> URL: https://issues.jboss.org/browse/WFCORE-3222
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> With the evolution of CLI to support aesh 1.0 commands, we have new use cases that CLI needs to handle. For example, to take benefit of third-party aesh commands (eg: aesh-extensions), the CLI must be able to load commands dynamically.
> Currently it is difficult or impossible to achieve the following use cases:
> List all commands
> List enabled commands
> List disabled commands
> List deprecated commands
> List commands that are loaded from extensions
> Display errors that occurred loading commands
> List commands loaded from ServiceLoader
> Load commands dynamically from a jar
> Load commands dynamically from a module
> A dedicated command should be designed to help achieve these use cases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 11 months