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

Neat :) Yes, figuring out the module path is biting everywhere. For file system path command line arguments there is a specialized FileSystemPathArgument.

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(a)jboss.org&gt; >>>>>>> To: brian.stansberry(a)redhat.com >>>>>>> >>>>>>> >>>>>>> [ >>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ] >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>> >>>>> >>>> >> >> > >