[jboss-jira] [JBoss JIRA] (WFLY-1396) File upload/manipulation through management API

[Ondrej Zizka (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Zizka updated WFLY-1396:
-------------------------------

    Description: 
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/ .

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(attachment-ref=myFile1, ifExists=fail|skip|overwrite|...)
{code}

File transfer
=============

The same principle could be used as for deployments.
But here's an alternative idea:

On the client side, the File to upload would be specified through a new API construct, let's call it Attachment.
(It would be impractical to stuff it into the text of the operations, IMO).
{{Attachment}} would be stored under a name, which would then be refered to in the operation's attrib {{attachment-ref}}.
Not sure how would that behave for batch operations.

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?

  was:
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/ .

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(attachment-ref=myFile1, ifExists=fail|skip|overwrite|...)
{code}

On the client side, the File to upload would be specified through a new API construct, let's call it Attachment.
(It would be impractical to stuff it into the text of the operations, IMO).
{{Attachment}} would be stored under a name, which would then be refered to in the operation's attrib {{attachment-ref}}.
Not sure how would that behave for batch operations.

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?


    
> File upload/manipulation through management API
> -----------------------------------------------
>
>                 Key: WFLY-1396
>                 URL: https://issues.jboss.org/browse/WFLY-1396
>             Project: WildFly
>          Issue Type: Feature Request
>            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/ .
> 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(attachment-ref=myFile1, ifExists=fail|skip|overwrite|...)
> {code}
> File transfer
> =============
> The same principle could be used as for deployments.
> But here's an alternative idea:
> On the client side, the File to upload would be specified through a new API construct, let's call it Attachment.
> (It would be impractical to stuff it into the text of the operations, IMO).
> {{Attachment}} would be stored under a name, which would then be refered to in the operation's attrib {{attachment-ref}}.
> Not sure how would that behave for batch operations.
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira