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

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(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 >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>> >>> > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >