Yes, the CLI can be used as a library. But it works via remote
communication, which IMHO is not something we should be doing here.
Running the server embedded in the tool with no ports open is fine though.
I think if people want to configure the server remotely they should
launch it and use one of the existing tools.
On 9/4/14, 4:14 PM, Stuart Douglas wrote:
I thought that it was already possible to use the CLI in library
The tool will have access to a full server at the point it needs to do
this (as the server has already been provisioned), so it could
potentially just load the CLI lib from the provisioned server and use that.
Brian Stansberry wrote:
> Not necessarily. Everything in the end speaks the underlying management
> API. But that doesn't mean the syntax needs to be the raw dmr or json
> This is primarily about UX and parsing. If we supported CLI syntax
> there's no requirement to also parse basic DMR. The CLI itself doesn't.
> If we support CLI syntax though it seems logical to use the CLI libs
> themselves to do it. Otherwise we are maintaining two code bases for the
> same thing. (I doubt the CLI parsing code can easily be extracted out
> for reuse, although I may be wrong.)
> On 9/4/14, 2:05 AM, Heiko Braun wrote:
>> 2) builds on 3), right?
>> On 04 Sep 2014, at 06:16, Stuart Douglas<sdouglas(a)redhat.com
>> <mailto:firstname.lastname@example.org>> wrote:
>>> 2) Allow the user to provide CLI commands to customise the server
>>> This is by far my favorite approach. The provisioning file would just
>>> contain a list of CLI commands, and would execute them in order. I
>>> this is by far the most intuitive, and the CLI is well documented.
>>> 3) Allow the user to provide DMR operations to customize the server
>>> Similar to 2, but allow the user to provide DMR or JSON operations to
>>> customize the server. I think this is not nearly as nice as 2, as users
>>> are much more likely to be familiar with the CLI rather than DMR.
>> wildfly-dev mailing list
Senior Principal Software Engineer
JBoss by Red Hat