[wildfly-dev] Customizing a provisioned server

[Brian Stansberry]

Are we going to do anything related to the "Provisioning" stuff on [1] 
here? That's an intermediate level of granularity than saying "I want 
xyz feature pack" (and perhaps tweaking the module set a bit) and doing 
a bunch of detailed config like 
"/subsystem=elytron/elytron-thingy=foo:write-attribute(name=bar,value=true). 
It's more for stuff like saying "I want jts, I want remote ejb, I want 
JSR-160" all of which are optional capabilities provided by various 
extensions.


[1] https://developer.jboss.org/docs/DOC-52712
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.
>
> 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.
>
> 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