This issue is a follow up on the developer discussion at https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/topic/use.20of.20data.20directory.20for.20WildFly.20S2I.20image

The initial issue was observed when the WildFly Operator is used to deploy an application image built with the wildfly-maven-plugin (tracked by https://github.com/wildfly/wildfly-operator/issues/249)

The standalone data dir is filled in the application image with the deployment bits (in standalone/data/content).
However, to handle tx recovery, we want to persist some state (stored in subdirectories of standalone/data, such as tx-object-store, ejb-xa-recovery, and kernel) outside of the image in a persistent volume.

It is not maintainable to ask cloud integration (through the operator or other tooling) to explicit mount individual subdirs of the standalone data dir to be able to have persistent storage outside of the application image.

As Brian proposed in the Zulip chat, we should enhance the standalone data dir to clarify the semantics of what is stored in it, what is intrinsic to the server (such as the content repository) and what can be shared (such as transaction log, messaging logs, etc.)

With this information, WildFly could be able to split the data dir into 2 subdirectories:

• local (ie local to the server and not meant to be shared)
• shared (anything that could be mounted in a separate volume for persistence purposes)

For example:

standalone/data
  local/
    content
    ...
  shared/
    kernel
    tx-object-store
    ...

From an external perspective, this would allow cloud integrator to mount a persistent volume for the standalone/data/shared subdirectories (and keep the standalone/data/local be read from the application image)

This API could be opt-in (the default value would be to be in the shared bucket) and we would make sure that the content repository opts in to be in the local bucket.