[jboss-jira] [JBoss JIRA] (WFCORE-4666) Implement a non-user standalone.sh extension mechanism

[James Perkins (Jira)]

    [ https://issues.jboss.org/browse/WFCORE-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13784937#comment-13784937 ] 

James Perkins edited comment on WFCORE-4666 at 9/16/19 2:56 PM:
----------------------------------------------------------------

A bit off topic, but I'd still love to have some kind of other entry point where hooks like this would be easier to insert. I think I've been talking about that for a number of years now and I'm not sure if this is a good excuse to explore it more or not :)

My assumption here is this is something that would be executed just before the {{java}} command not after it's been launched in the background correct?



> Implement a non-user standalone.sh extension mechanism
> ------------------------------------------------------
>
>                 Key: WFCORE-4666
>                 URL: https://issues.jboss.org/browse/WFCORE-4666
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Scripts
>            Reporter: Brian Stansberry
>            Priority: Major
>
> We have a reasonable architecture for how standalone.sh works: standalone.sh itself is not meant to be touched and has a lot of complex logic, and then standalone.conf is for users to manipulate as they wish to set up env vars. The standalone.conf is sourced early in the standalone.sh execution.
> What's missing is a hook for non-user extensions to the standalone.conf concept. Primary use case being cloud containers where the container developers also don't want to maintain their own variant of standalone.sh but need to do env var manipulation before the main script logic runs. Right now images are handling this by shipping their own standalone.conf with a bunch of content appended, but that has the effect of making the file no longer a 'user' file.
> A possible simple way to improve this is to have standalone.sh look for a 'standalone.conf.post' file and, if present, source it after standalone.conf.  Perhaps a standalone.conf.pre as well.
> (Tangent: I think our stock standalone.conf/bat etc should have a leading comment section explaining the "API" of standalone.sh, i.e. what are the env vars that standalone.sh will process that the user may wish to manipulate in standalone.sh.
> [~luck3y] FYI and input. Whether this is a good idea in our images is a good thing to discuss; i.e. whether easing end-user manipulation is something desirable. The basic design is users should not do that, and instead they should use the various cloud-specific env vars processed by the image logic to manipulate the server launch. And I think that's fine/correct. I just don't like the way that image logic is implemented by having the image build append logic to standalone.conf. That's conceptually unclean.
> [~jamezp] [~jmesnil] FYI.
> This is not urgent; just something I was thinking about after helping with some user issues with our image launch.



--
This message was sent by Atlassian Jira
(v7.13.5#713005)