Camunda Wildfly subsystem's context switch making resources invisible to plugin

Environment (Required on creation):

Camunda 7.13 on Wildfly 19, but should apply to later versions as well.

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):

We have a custom process engine plugin (extension of org.camunda.bpm.engine.impl.cfg.AbstractProcessEnginePlugin) that attempts to load a configuration resource that's on the plugin module's classpath (part of the jar itself). The plugin module is visible from the camunda-wildfly-subsystem module.

To be precise, it concerns a JPA mapping file (ironically, as it turns out) that Hibernate attempts to load through the current thread's classloader. This process is initiated in the plugin's postProcessEngineBuild, resulting in an exception that the resource cannot be found.

Steps to reproduce (Required on creation):

Attempt to load a resource from AbstractProcessEnginePlugin.postProcessEngineBuild.

Observed Behavior (Required on creation):

The configuration file cannot be found. See root cause for more info.

Expected behavior (Required on creation):

Process engine plugins can see resources in their own module (and dependent modules).

Root Cause (Required on prioritization):

The reason that this goes wrong is that the current thread's classloader is set to that of the camunda-engine module by the Wildfly subsystem when initializing the process engine. Initializing process engine plugins is part of this logic, so that classloader is still active when postProcessEngineBuild is called.

The context switch is located in MscManagedProcessEngineController.startInternal:

    // setting the TCCL to the Classloader of this module.
    // this exploits a hack in MyBatis allowing it to use the TCCL to load the
    // mapping files from the process engine module
    Tccl.runUnderClassloader(new Operation<Void>() {
      public Void run() {
        startProcessEngine();
        return null;
      }

    }, ProcessEngine.class.getClassLoader());

I can see from the git history that this code has been part of the wildfly-subsystem from the very beginning. Apparently there was a problem with the specific versions of MyBatis and Wildfly (or more likely: its predecessor JBoss AS) that prevented the MyBatis mapping files to be loaded. However, since module camunda-wildfly-subsystem depends on module org.camunda.bpm.camunda-engine it should see those resources. If you remove the context switch you can confirm that, indeed, MyBatis happily loads those files and Camunda boots succesfully.

Solution Ideas (Optional):

Remove the class loader switch entirely, because it should not (and doesn't seem to) be needed.

Hints (Optional):

-