[wildfly-dev] Embedding a WF instance in the CLI

Wed May 14 10:53:40 EDT 2014

How topical :) The RHQ installer could use this - just this very second I'm debugging and trying to figure out why the RHQ installer can't connect to the running app server instance to do its initial config setup - having to try to figure out what port its running on and why I can't connect is a pain.

----- Original Message -----
> Moving a thread to the dev list.
> 
> This is about some prototyping I've been doing on weekends 'cause I'm
> bored with my regular tasks. I've been playing with direct local
> administration of a WF installation via the CLI without requiring a
> socket-based connection. The general use case is initial setup type
> activities where the user doesn't want to have to launch a WF server or
> HC process and potentially have it be visible on the network.
> https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a
> desire some folks have expressed in being able to do configuration
> without first having to edit any xml to avoid port conflicts on 9990 or
> 9999.
> 
> This isn't a major initiative or big priority or anything at this point.
> Just something I find interesting and perhaps you will too.
> 
> On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
> > Neat :) Yes, figuring out the module path is biting everywhere.
> > For file system path command line arguments there is a specialized
> > FileSystemPathArgument.
> >
> 
> Thanks; I'll switch to that.
> 
> >
> > On 05/13/2014 10:54 PM, Brian Stansberry wrote:
> >> Copying Heiko Braun as he expressed some interest in the topic.
> >>
> >> BTW, I played with this a bit more last weekend and was able to start an
> >> embedded server inside the CLI easily enough. See [1] for very raw
> >> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
> >>
> >> [disconnected/] embed-server
> >>
> >> There are a couple issues I see, besides the HC stuff I mentioned in my
> >> last message.
> >>
> >> 1) If the CLI is started in a non-modular environment via java -jar
> >> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into
> >> the jar. And then the embed-server command would need params specifying
> >> the location of JBOSS_HOME, possibly module path etc. But it could embed
> >> a server installed in any accessible filesystem location.
> >>
> >> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
> >> running from a WF dist in a modular environment and the embedded server
> >> modules are coming from the CLI's own module path. It would be more
> >> effort to support embedding a server based on some other module path.
> >> Maybe it's no big deal; maybe it's really hard. :)
> >>
> >> 2) The console logging from the embedded server goes to stdout mixed in
> >> with the CLI output. Maybe that's good, maybe it's bad.
> >>
> >> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
> >>
> >> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
> >>> I was poking around at this for an hour or so over the weekend.
> >>>
> >>> The standalone case seems pretty straightforward. Seems the existing
> >>> embedded server API could work readily enough. The
> >>> org.jboss.as.embedded.StandaloneServer interface already provides a
> >>> ModelControllerClient.
> >>>
> >>> The domain case is much harder, as the CLI wants a HostController, not a
> >>> ProcessController. I'd really like this to use an in-VM client, not a
> >>> remote one, so I don't like having the CLI embed a PC and then the HC is
> >>> an external process. My thoughts of the morning are to allow inverting
> >>> the HC/PC relationship for this kind of usage. That is, remove
> >>> controlling the HC lifecycle from the charge of the PC component. CLI
> >>> launches HC, and then the HC creates an in-process PC-ish component (not
> >>> a separate process) to manage the server lifecycles. There could be all
> >>> sorts of problems with that; it's just the thought for the morning.
> >>>
> >>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
> >>>> Embedding the AS is the best starting point to achieve that! And more
> >>>> fun, I agree :)
> >>>>
> >>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
> >>>>> And to think my reason for opening the Jira was just for a common
> >>>>> way to
> >>>>> mask password inputs where java.io.Console is not available ;-)
> >>>>>
> >>>>> On 25/04/14 17:09, Brian Stansberry wrote:
> >>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
> >>>>>>> Wow! Indeed :)
> >>>>>>>
> >>>>>>> There could be an embedded scope - true, i.e. commands available
> >>>>>>> only
> >>>>>>> this mode, like add-user, module mgmt related stuff, etc.
> >>>>>>
> >>>>>> Those commands wouldn't need to be only in that mode though. The
> >>>>>> implementation of all of them would be based in the server; the
> >>>>>> "client"
> >>>>>> aspect of the CLI would just use the management interface. The
> >>>>>> difference between an embedded mode and what we have now would
> >>>>>> just be
> >>>>>> in how the "client" side gets its ModelControllerClient -- what we
> >>>>>> have
> >>>>>> now vs starting an embedded server and getting some sort of in-vm
> >>>>>> client.
> >>>>>>
> >>>>>>> But it would still mean the server/controller would have to actually
> >>>>>>> provide implementations of that functionality and expose it to the
> >>>>>>> management tools like the CLI in the embedded mode.
> >>>>>>
> >>>>>> Yep.
> >>>>>>
> >>>>>>> I like this idea as a concept - direct local management. W/o any
> >>>>>>> remote
> >>>>>>> connect/re-connect/disconnect burden.
> >>>>>>>
> >>>>>>> Extending the CLI with custom modules is on the list too. It's
> >>>>>>> probably
> >>>>>>> easier to implement at this point.
> >>>>>>>
> >>>>>>
> >>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
> >>>>>> thread
> >>>>>> where I briefly get into this general area too.
> >>>>>>
> >>>>>>> Alexey
> >>>>>>>
> >>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
> >>>>>>>> Hi Alexey,
> >>>>>>>>
> >>>>>>>> Wanted to point the discussion on this JIRA out to you as it gets
> >>>>>>>> into
> >>>>>>>> some fairly fundamental brainstorming that you may find
> >>>>>>>> interesting.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -------- Original Message --------
> >>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or
> >>>>>>>> move it
> >>>>>>>> into the CLI
> >>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
> >>>>>>>> From: Darran Lofthouse (JIRA) <issues at jboss.org>
> >>>>>>>> To: brian.stansberry at redhat.com
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>      [
> >>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963854#comment-12963854
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ]
> >>>>>>>>
> >>>>>>>> Darran Lofthouse commented on WFLY-3288:
> >>>>>>>> ----------------------------------------
> >>>>>>>>
> >>>>>>>> That could be very interested, won't go into too much detail in
> >>>>>>>> this
> >>>>>>>> Jira as it is not directly related shortly I am switching to the
> >>>>>>>> SSL
> >>>>>>>> related tasks we have outstanding including the out of the box
> >>>>>>>> enablement we talked about in Brno - managing an embedded instance
> >>>>>>>> could
> >>>>>>>> be useful there as well to get it all op based.
> >>>>>>>>
> >>>>>>>> I can see this task may end up coming back my way combined with the
> >>>>>>>> other stuff ;-)
> >>>>>>>>
> >>>>>>>>> Update add-user to use AESH or move it into the CLI
> >>>>>>>>> ---------------------------------------------------
> >>>>>>>>>
> >>>>>>>>>                 Key: WFLY-3288
> >>>>>>>>>                 URL: https://issues.jboss.org/browse/WFLY-3288
> >>>>>>>>>             Project: WildFly
> >>>>>>>>>          Issue Type: Feature Request
> >>>>>>>>>      Security Level: Public(Everyone can see)
> >>>>>>>>>          Components: Domain Management, Scripts
> >>>>>>>>>            Reporter: Darran Lofthouse
> >>>>>>>>>             Fix For: Awaiting Volunteers
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Within the add-user utility it is difficult to handle situations
> >>>>>>>>> where
> >>>>>>>>> we do not have access to a java.io.Console which is the easiest
> >>>>>>>>> way to
> >>>>>>>>> handle password reading without an echo to the user e.g. in Cygwin
> >>>>>>>>> Switching to AESH would allow us to use the implementation
> >>>>>>>>> there to
> >>>>>>>>> handle this.
> >>>>>>>>> Alternatively it may actually make sense to make add-user a
> >>>>>>>>> special
> >>>>>>>>> mode of the CLI, we may at some point want to switch to runtime
> >>>>>>>>> operations being executed on the server so porting to the CLI
> >>>>>>>>> could be
> >>>>>>>>> the first step to make this possible.
> >>>>>>>>> Overall this is going to require further discussion so the
> >>>>>>>>> comments
> >>>>>>>>> here are just a starting point.
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> 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
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >>
> >>
> 
> 
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 