@tijs I updated my example to flowable 6.4.1 but the problem is stell present
@tijs When I change the classloading behaviour in org.flowable.common.engine.impl.javax.el.ExpressionFactory (line 112) from
classLoader = Thread.currentThread().getContextClassLoader();
to
classLoader = ExpressionFactory.class.getClassLoader();
everthing works as expected. Is there any chance to get rid of the ContextClassLoader?
I came around this issue by setting the ContextClassloader in a CommandInterceptor:
Ideally, the org.flowable.osgi.blueprint.ProcessEngineFactory.init() Method would do this, so this issue would be solved for everybody using OSGi
1 Like
As I encountered classloading problems again when using flowable 6.5.0 with Karaf, I tried a different approach and got it running by embedding the flowable libraries in one fat jar.
Otherwise, flowable is complaining, that resources (ibatis xml config files) can not be loaded.
Interesting. Is there any change in 6.5.0 that caused the classloading problems? Maybe we can amend them.
Yes, it’s very likely, that a change in 6.5.0 causes this error (bundle import statements, so that resources from bundle B can be seen by bundle A).
So, if you say, that flowable should support an OSGi environment like Apache Karaf, it would be helpful, that flowable maintains a “karaf-feature” module and ensures, that a processEngine can be bootstrapped with the flowable bundles provided by this feature.
I know, that spring boot is very popular and fits perfect for most people, but I think, Apache Karaf is also a great runtime environment, espacially if workflows rely on many different modules in one runtime.