December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-429) Incremental redeployment (single file update) over management API

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-2765 to WFCORE-429: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-429 (was: WFLY-2765) Affects Version/s: (was: 8.0.0.CR1) Component/s: CLI Domain Management (was: CLI) (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Incremental redeployment (single file update) over management API > ----------------------------------------------------------------- > > Key: WFCORE-429 > URL: https://issues.jboss.org/browse/WFCORE-429 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Ondrej Zizka > Labels: deploy, deployment, incremental, redeployment > Fix For: 1.0.0.Beta1 > > > (Based on JBDS use case - see EAP6-1) > See also https://mojo.redhat.com/docs/DOC-934058 for notes > By incremental redeployment, we mean the situation when something is deployed, and after changes (in IDE e.g.), only that single file (.jsp, .xml, .class) would be re-deployed to the server, *over management API* - which is, you'd give it a stream and a path where it belongs in the deployment, and the operation would accept that file and put it to the right place in VFS, clear caches etc. > Use cases: > Big .war's, mainly on remote > Cloud deployments > Also, you loose sessions etc. > "JSP recompile on file update" - mgmt API operation - added in WildFly 8? > Not expected to work in domain mode. > Stuart said that session persistence is implemented in WFly 8, but not the incremental redeployment. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-430) CLI command to list/view AS modules

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-430?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1128 to WFCORE-430: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-430 (was: WFLY-1128) Component/s: CLI (was: CLI) > CLI command to list/view AS modules > ----------------------------------- > > Key: WFCORE-430 > URL: https://issues.jboss.org/browse/WFCORE-430 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Akram Ben Aissi > Assignee: Alexey Loubyansky > > For the same reason as AS7-4265, it would be useful to have command to list and view modules and their configuration. > For example: > modules list --name=org.jboss.* > or simply > modules list > will display a list of all available/installed modules in the AS. > The same way, > modules view --name=org.jboss.as.security --slot=name > will display details for the specified module, include its related resources and classes, and so on -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-424) .jar's on "current runtime classpath"

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-424?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-2766 to WFCORE-424: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-424 (was: WFLY-2766) Affects Version/s: (was: 8.0.0.CR1) Component/s: Modules CLI (was: Class Loading) (was: CLI) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > .jar's on "current runtime classpath" > ------------------------------------- > > Key: WFCORE-424 > URL: https://issues.jboss.org/browse/WFCORE-424 > Project: WildFly Core > Issue Type: Feature Request > Components: Modules, CLI > Reporter: Ondrej Zizka > Assignee: David Lloyd > Fix For: 1.0.0.Beta1 > > > (Based on JBDS use case - see EAP6-1) > In certain scenarios, JBDS needs to know the classpath. (Compilation of non-maven project, against a remote server, ...(?) ) > The classpath would be: > * for the deployment after deployed > * for a generic deployment if it was deployed right now - what would WildFly use? > * for the deployment before deployed - sounds a bit advanced but technically possible > We (David, Stuart, Jason, Max, Ondra) have discussed this on EAP F2F 2014. > The output was that we don't need exact classpath / list of jars which would probably end up being almost all modules; rather we need the direct deps. As someone said - "just to get rid of the red lines in the IDE". > The non-maven compilation use case is that the user has a server in a directory, and the jars to build against should all be in there. So the IDE should be able to ask WildFly for a list of .jar's to build the application against, and just use that instead of forcing the user to gather them manually. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-425) CLI: include option to specify credentials from file

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-425?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-707 to WFCORE-425: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-425 (was: WFLY-707) Component/s: CLI (was: CLI) Fix Version/s: (was: Awaiting Volunteers) > CLI: include option to specify credentials from file > ---------------------------------------------------- > > Key: WFCORE-425 > URL: https://issues.jboss.org/browse/WFCORE-425 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Radoslav Husar > Priority: Minor > Labels: eap6-ux > > More of a wish-list Jira (hence marked as minor priority and open to community) related to AS7-2036: provide option to specify credentials from file rather than command line, but both are insecure. Users should look into other ways of authenticating against the instance. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-426) Auto more/less in CLI for multi-page output

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-426?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-3388 to WFCORE-426: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-426 (was: WFLY-3388) Component/s: CLI (was: CLI) > Auto more/less in CLI for multi-page output > ------------------------------------------- > > Key: WFCORE-426 > URL: https://issues.jboss.org/browse/WFCORE-426 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Darran Lofthouse > Assignee: Alexey Loubyansky > > Where the result of a management operation in the CLI returns multiple screens of output it would be nice if this could be automatically wrapped in a more/less type behaviour. > Similar to how git handles git log compared to how svn handles svn log. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-421) cli tab-completion: filtering out operations not applicable to a resource

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-421?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1116 to WFCORE-421: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-421 (was: WFLY-1116) Component/s: CLI (was: CLI) > cli tab-completion: filtering out operations not applicable to a resource > ------------------------------------------------------------------------- > > Key: WFCORE-421 > URL: https://issues.jboss.org/browse/WFCORE-421 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Environment: JBoss AS 7.0.1 > Reporter: Bill Meyer > Assignee: Alexey Loubyansky > Priority: Minor > > In this example, no Data Sources already exist (clean config). > If I enter the following into the CLI and hit <tab>: > /subsystem=datasources/data-source=:<tab> > I get no operation hints. If I use a bogus resource name that doesn't exist and hit <tab>: > [standalone@localhost:9999 /] /subsystem=datasources/data-source=DoesNotExistDS:<tab> > add disable enable flush-all-connection-in-pool > flush-idle-connection-in-pool read-attribute read-children-names read-children-resources > read-children-types read-operation-description read-operation-names read-resource > read-resource-description remove test-connection-in-pool validate-address > write-attribute > I get all the operations available. This should be made more consistent. The preference, IMO, would be to not have to specify a bogus name and still get the operations list: > [standalone@localhost:9999 /] /subsystem=datasources/data-source=:<tab> > or simpler yet: > [standalone@localhost:9999 /] /subsystem=datasources/data-source:<tab> > (no empty equal sign). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-422) File upload/manipulation through management API - modules, config files

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-422?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1396 to WFCORE-422: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-422 (was: WFLY-1396) Component/s: CLI (was: CLI) > File upload/manipulation through management API - modules, config files > ----------------------------------------------------------------------- > > Key: WFCORE-422 > URL: https://issues.jboss.org/browse/WFCORE-422 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Ondrej Zizka > > It would be nice to have a possibility to upload certain files. Namely: > - create modules (e.g. JDBC drivers) > - copy .properties files - logging, security etc. > - ssh keys, certificates etc. > Could be limited to the examples above - i.e. one operation for creating/removing a module, another for copying a file to configuration/ . > {code} > /:add-config-file(file=foo.properties, ifExists=fail|skip|overwrite|...) > /:add-module(file=foo.jar, name=org.jboss.foo, version=main, dependencies=["org.jboss.bar"], imports=[...] exports=[...] ifExists=fail|skip|overwrite|...) > {code} > To avoid the complexity of distributing such file amongst managed domain, the op could be scoped to just a single host, like > {code} > /host=host1:add-config-file(...) > {code} > File transfer > ============= > The same principle could be used as for deployments (--{{ModelNode.readExternal()}}-- ?) > CLI's DeployHander#execute(): > {code} > OperationBuilder op = new OperationBuilder(request); > op.addFileAsAttachment(f); > request.get(Util.CONTENT).get(0).get(Util.INPUT_STREAM_INDEX).set(0); > Operation operation = op.build(); > result = ctx.getModelControllerClient().execute(operation); > operation.close(); > {code} > Specifics > ========= > The file manipulation in add-module would be performed by JBoss Modules through an appropriate API. > The file manipulation in add-config-file would be performed by the part of AS which knows where the config is actually read from (in case it is variable) - MSC? -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-423) No way to grep/more or find a line in the CLI

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-423?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1123 to WFCORE-423: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-423 (was: WFLY-1123) Component/s: CLI (was: CLI) > No way to grep/more or find a line in the CLI > --------------------------------------------- > > Key: WFCORE-423 > URL: https://issues.jboss.org/browse/WFCORE-423 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jim Tyrrell > Assignee: Alexey Loubyansky > Labels: eap6-ux > > In the CLI I should be able to page through the pages of information that are presenting using | more or equivalent. By the same token I should be able to grep to find the one line that I am looking for, when I know what it is I am looking for. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-417) jboss-cli should set -Djava.awt.headless=true

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-417?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-2144 to WFCORE-417: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-417 (was: WFLY-2144) Component/s: CLI (was: CLI) > jboss-cli should set -Djava.awt.headless=true > --------------------------------------------- > > Key: WFCORE-417 > URL: https://issues.jboss.org/browse/WFCORE-417 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Robin Rosenberg > Assignee: Alexey Loubyansky > Priority: Minor > > On OS X using jboss-cli.sh will cause focus to shift making it very inconvenient to do other things while scripts that talk to jboss execute. > There is a workaround: export JAVA_OPTS=-Djava.awt.headless=true before invoking the cli, but I see no reason for the CLI not do this itself. This also applied to the adduser.sh script. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-418) Input/Output Formats Should Be Standard Formats (json/yaml/etc)

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-418?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-3339 to WFCORE-418: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-418 (was: WFLY-3339) Affects Version/s: (was: JBoss AS7 7.1.1.Final) Component/s: CLI (was: CLI) > 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: Alexey Loubyansky > 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 (v6.3.8#6338)

11 years, 7 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 December 2014