After a long time working on other things, I finally could go back on this problem and I solved it using remote EJBs.
Please find below some more details for future references.
The architecture that I adopted on top of the Camunda 7.6 wildfly 8 distribution is the following:
My JavaEE application containing all the business logic that can be executed by service tasks. This business logic is also exposed via remote EJBs.
This application (as I was already mentioning in the other posts) gives the functionality to the end users to "hot-deploy" new process definitions at runtime.
A JavaSE module containing a client to the remote EJBs exposed by "my-application".
This is deployed as a Wildfly module, together with the "camunda-engine" Wildfly modules. This way, the Classloader used by the "camunda-engine" module at runtime will always have access to the classes inside "my-application-client".
When a user deploys a process using the API exposed on "my-application", under the hood I use the Camunda java API to deploy a process definition: this (as I was mentioning in the other posts) will deploy only the process definition, but unfortunately not the classes.
But with the architecture that I described above (and that I put in place and tested with success) this is not a problem anymore, as long as all java classes referenced in the process definition (java delegates, listeners, etc.) are pointing to classes contained inside "my-application-client". This will now always work at runtime since the client is deployed as a dependency of the "camunda-engine".
This way you can invoke all "my-application" business logic (exposed via remote EJB) also from hot-deployed processes, using "my-application-client" as entry point.
I hope this could help somebody.
I am not having problems so far with this architecture, but please let me know if you see something wrong about it or maybe something I haven't considered.