June 2018 - jboss-jira - Jboss List Archives

[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, 11 months

1
0
0 / 0

[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, 11 months

1
0
0 / 0

[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, 11 months

1
0
0 / 0

[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, 11 months

1
0
0 / 0

[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, 11 months

1
0
0 / 0

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

7 years, 11 months

1
0
0 / 0

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

7 years, 11 months

1
0
0 / 0

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

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3263) add i18n to the CLI

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3263?page=com.atlassian.jira.plugi... ] Jean-Francois Denise closed WFCORE-3263. ---------------------------------------- Resolution: Rejected There are no plans to add i18n to CLI. > add i18n to the CLI > ------------------- > > Key: WFCORE-3263 > URL: https://issues.jboss.org/browse/WFCORE-3263 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Affects Versions: 3.0.1.Final > Reporter: Martin Stefanko > Assignee: Jean-Francois Denise > Priority: Optional > > Introduce i18n in the CLI subsystem. This could possibly include messages printed by the console and help description. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3450) CLI - avoid required attributes to be hard to see when using tab completion

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3450?page=com.atlassian.jira.plugi... ] Jean-Francois Denise resolved WFCORE-3450. ------------------------------------------ Resolution: Done We have colouring of required attributes. > CLI - avoid required attributes to be hard to see when using tab completion > ---------------------------------------------------------------------------- > > Key: WFCORE-3450 > URL: https://issues.jboss.org/browse/WFCORE-3450 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Miroslav Novak > Assignee: Ingo Weiss > > This is follow up for WFCORE-2283 which marked required attributes by "*" when using tab completion. Still if there are many attributes, it's hard to see all required attributes, for example in: > {code} > [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:add( > ! check-period connector-name* max-retry-interval notification-interval retry-interval-multiplier > allow-direct-connections-only cluster-connection-address* discovery-group* message-load-balancing-type producer-window-size static-connectors* > call-failover-timeout confirmation-window-size initial-connect-attempts min-large-message-size reconnect-attempts use-duplicate-detection > call-timeout connection-ttl max-hops notification-attempts retry-interval > {code} > it's not clear at the first look how many required attributes there are. > Suggestion is to group required attributes together and then provide list of other attributes, for example on the next line. Another options might be considered as well. For example to show required attributes when double pressing <tab>. > Discussed on https://developer.jboss.org/wiki/CLI-BetterCompletionForArguments?et=watc... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 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 June 2018