Hi
Firstly I am not sure if there is some separate way developers discuss potential changes to the flowable distribution, so posting this here.
I have been looking at replacing the idm app with a different implementation. In the process I wanted a smooth upgrade path for merging future changes from flowable master, so I came up with an approach to “plugging” in a different implementation.
It basically involves using Spring @Profile annotations on targeted classes such as SecurityConfiguration.java in the webapps. For the standard configuration one can use the @Profile(“default”) which is loaded by Spring by default, eg.
The next problem is that component scanning in the ApplicationConfiguration only supports scanning internal packages. I couldn’t find a way to add additional ones at runtime through std Spring mechanisms (if someone knows of one, awesome!). My approach is to allow plugging in an additional @Configuration class at runtime as follows using a system property:
So one could create a @Configuration that does additional classpath scanning:
Put the external implementation in the classpath and add these two -D arguments to resolve it at runtime:
-Dspring.profiles.active=example -Dflowable.app.modeler.external_spring_config_class=org.example.flowable.app.security.ExampleConfiguration
There are a few other odd changes, but this is the core of it. This would not change the default way the apps work, are run or configured. Would you be interested in this contribution? Or any other ideas to achieve the same result?
ps. I noticed that someone added a feature request for OAuth support for the REST api and this could be potentially implemented in a pluggable fashion using @Profile as well.