1
votes

I have a scenario in which I'm looking to register IntegrationFlow Spring beans based on the contents of a JPA database table.

For example, the table will look like:

@Entity
class IntegrationFlowConfig {
  private long id;
  private String local;
  private String remote;

}

and I want an IntegrationFlow registered as a Spring bean for each entry found in the above table definition. When a row is added, a new bean is registered, and when a row is deleted, the corresponding bean is destroyed.

I've considered creating an EntityListener for the above entity, in which @PostPersist and @PostRemove will create/destroy IntegrationFlow beans via IntegrationFlowContext, but this solution seemed a bit clunky, and I was wondering if there was any functionality that exists that's a bit more streamlined to solve the above problem. Perhaps some sort of row mapping functionality that can map spring beans to JPA database rows, etc?

Any help would be much appreciated!

thanks,

Monk

1

1 Answers

0
votes

Well, such an idea has crossed my mind several times in the past. But even with an XML configuration easily serialized into databased and deserialized into an Integration Flow (XML one) in its own child ApplicationContext, we still ended up with the problem that some beans have to be provided with their Java code. Even if we opted out for Groovy scripts, which could be parsed and loaded at runtime, some Java code would need to be compiled anyway. And in the end when we released some solution for the customer, it became very messy error prone how their operators wrote those dynamic flows.

You definitely can have some external configuration options and can have a conditional logic, but still the code must be compiled in advance without any way to let the logic (not data) to be seriailzed and deserialized at runtime.

Probably this is not an answer you are looking for, but there is no such a serialization solution and possibly it won't be done at all, since it is an anti-pattern (IMHO) to have dynamic application these days when we simply can deal with short and simple microservices or even functions.