After spending some more time on stepping through the OfBiz code and trying to get the entity engine running outside of the OfBiz framework I found that while you can run the entity engine like that, but it still requires a single entityengine.xml from the classpath and will maintain that in some static cache. I think I saw the same pattern applied for other configurations.
In my understanding that means that one instance of the entity engine code can be used for exactly one configuration per VM and in particular, for the multi-tenant use-case, all data sources for all tenants have to be pre-defined in that one configuration file. If I understood Marc correctly, that's also what he does. So the entity engine can be configured exactly once and it will not forget until the VM stops. However, it seems that all you need to process a request for a tenant is its delegator and subsequently a service dispatcher. Both, it seems, could be created based on some tenant specific configuration and still work correctly, if it wasn't for the static cache. Also, it seems that the ResourceLoader supports separation per class loader, so that you could have different entityengine.xml files in different deployable (assuming these use different classloaders at runtime) and the one to be the first one to ask for a delegator would actually provide the entity engine config. Unfortunately any other code would then share that configuration. Plus... GenericDelegator, EntityConfigUtil etc. would not know about different classloaders still. Currently I have the impression that trying to change all those places could be an endless endeavour and I better start looking into a solution that - at runtime - has duplicate deployments of OfBiz. Any thoughts? Thanks, Henning
