[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)
7 years, 6 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)
7 years, 6 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)
7 years, 6 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)
7 years, 6 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)
7 years, 6 months