Inside Efesto, currently if a resource (FRI) is already present inside "IndexFile", it is not add again and it is not loaded it the current classloader.
The issue may happen on an on-the-fly compilation context:
1) execution "A" compile and execute resource XYZ with classloader "CA"; the entry is add inside IndexFile and lodaded inside classloader CA; the runtime "A" finds it inside classloader CA, and successfully executes
2) execution "B" compile and execute resource XYZ with classloader "CB"; the entry is already present inside IndexFile, so it is not compiled nor add inside classloader CB; the runtime "B" does not find it in classloader CB and throws ClassNotFoundException.

Another possible scenario is on JVM restart
1) during execution, the context submit a new resource/model to the compilation manager
2) the compilation manager create the classes, write the IndexFile, and load the classes on classloader
3) the jvm crashes/stop (whatever reason)
4) the application restarts, loading the previously generated IndexFile
5) the current classloader does not have knowledge of the previously generated bytecode

To deal with it:
1) this specific use-case rely on some way to actually retrieve the bytecode, so it must be available/stored somewhere
2) write a specific test (slight variation of `evaluateWithKieSessionLocalCompilationOnTheFly`) to verify that behavior

//
It currently blocks PMML integration because this code path is executed in DMN-> PMML integration - e.g. `DMNRegressionTrustyPMMLTest`