[wildfly-dev] Customizing a provisioned server

[Brian Stansberry]

On 9/3/14, 11:16 PM, Stuart Douglas wrote:
> Hi everyone,
>
> Work on the provisioning tool is now well underway, so I would like to
> revisit something I mentioned in my original email, which is allowing
> the provisioning tool to customize a provisioned server.
>
> I think there are a few options here, some more palatable than others.
> In no particular order:
>
> 1) Customize the XML directly
>
> Using this approach we would just directly customize the XML
> configuration files. This would basically require the use of XSLT
> (yuck), or require us to basically invent our own version of XSLT (even
> more yuck). Even though this approach will work, and will be fairly easy
> to implement, I think it would really suck from an end-user point of
> view, and I think we should discount it.
>

I can't see this as workable at all for generic customization. I could 
see it for a setup where a user provides a list of capabilities, and we 
produce a tailored xml that provides those capabilities. The xml is 
still some standard config, just mildly customizable by listing 
capabilities. Implemented perhaps using something like the templating 
thing we've used in the past.

But if the idea is to support arbitrary config changes, no way xml is an 
option.

> 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 think
> 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.
>
>
> I think 2 is by far the best approach, however it does open up the
> question of how and when to execute the operations. I think the easiest
> way to do this would be to just start the server in admin only mode on a
> custom port (so it will not interfere with any existing running Wildfly
> instances), and just execute the CLI commands in admin only mode.
>

If we are going to use the management API, we need to start an embedded 
process with no ports open. Otherwise people should just use one of our 
existing management tools.

> Does this all sound reasonable?
>
> Stuart
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat