preferred way to use environment variable for configuring domain.xml

[rlfnb]

Im pretty happy to have a place where official glassfish docker images being published. However I was surprised to find no idea how to add environment properties for replacing domain.xml values. So basically, I cannot use the image without heavy lifting to make it work as a container with any kind of database for example. Maybe you can give me hint how to solve it in an intended way?

[OndroMih]

Hi, at the current state, GlassFish Docker just runs the GlassFish server, with minimal customization. Since GlassFish doesn’t support configuration using environment variables, what you describe is not possible.

The next version of the Docker image will improve this a bit, it will be possible to configure the server with asadmin commands in a file: #22

This still doesn’t allow configuration using environment variables, but you can mount a directory with an asadmin script that configures a database connection pool or anything else.

[rlfnb]

Thank you for your your quick reply. maybe the preboot / postboot file introduced in payara maybe a good start for backporting into this image? This mechanism would allow already the customization of the glassfish domain?
Final step is to resolve ${ENV=...} properties?

[OndroMih]

We don't want backport features from Payara to GlassFish if we can find a better solution. But we at OmniFish are working on something similar, which would allow using references to environment variables in domain.xml, and even amend configuration using environment variables without variable references in domain.xml, and thus without any change in the Docker image. Basically exposing all config options as environment variables. We don't know when it will be ready. If you use GlassFish on a commercial project, we can offer you our services and deliver these improvements ASAP for you, and much more. You can contact us at https://omnifish.ee/contact-us/.

Meanwhile, we released the Docker image for 7.0.21, which allows running asadmin commands or a bash script from file before GlassFish is started. Here's the documentation: Execute asadmin commands before server startup. There's still a catch, GlassFish needs to be started, then commands executed, the GlassFish needs to be stopped, and then it will be started again as the main Docker process. There's a way to avoid it to speed up the container start, but it's not straightforward - from a bash script, start another bash script in background, which would wait until GlassFish is started and then would run the commands against the running server. This would not need a restart of GlassFish, as GlassFish would already be the main process.