[wildfly-dev] Customizing a provisioned server
Tomaž Cerar
tomaz.cerar at gmail.com
Fri Sep 5 06:22:26 EDT 2014
You are right. I was mixing the two.
And when doing some client last time I was indeed using CLI api for that.
Looking at the code, there is only one method we would really need to use
CommandContext#buildRequest(String)
https://github.com/wildfly/wildfly-core/blob/master/cli/src/main/java/org/jboss/as/cli/CommandContext.java#L278
Which translates CLI command to DMR one.
So in any case, CLI is a way to go. how that is different question.
On Fri, Sep 5, 2014 at 11:22 AM, Kabir Khan <kabir.khan at jboss.com> wrote:
>
> On 5 Sep 2014, at 09:59, Tomaž Cerar <tomaz.cerar at gmail.com> wrote:
>
> >
> > On Thu, Sep 4, 2014 at 11:17 PM, Stuart Douglas <
> stuart.w.douglas at gmail.com> wrote:
> > The problem with 3 is that for the most part users do not use DMR
> directly, they use the CLI, and all our documentation reflects this. If we
> use DMR directly for this it just one more thing that we require our users
> to learn.
> >
> >
> > 90%+ of what users do in CLI is direct DMR.
> > Things that CLI adds that are not part of native DMR are handlers like:
> >
> > - ls (instead of :read-resource),
> > - reload (instead of :reload)
> > - try,catch
> > - batch*
> > - if, else
> > - clear, quit
> > + some others
> >
> > but in general most of the commands people write are direct DMR.
> > CLI only adds lots of usability features on top of them like tab
> completion.
> >
> > for example
> > /subsystem=io/worker=new-worker:add()
> > is 100% dmr operation.
> Yes, but isn’t the issue that it is nicer for end users, who are used to
> the CLI to write this rather than either using the serialized forms of the
> the DMR representation, e.g. either (raw DMR)
> {
> "address" => [
> ("subsystem" => "io"),
> ("worker" => "new-worker")
> ],
> "operation" => “add”
> }
> or (JSON)
> {
> "address" : [
> {
> "subsystem" : "io"
> },
> {
> "worker" : "new-worker"
> }
> ],
> "operation" : "add"
> }
> is is a lot more usable to just be able to say
> /subsystem=io/worker=new-worker:add()
>
>
> >
> > In any case if we go with WildFly embedded in CLI mode all this
> discussion is non issue.
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140905/b55f6e19/attachment-0001.html
More information about the wildfly-dev
mailing list