Connector Beans not discovered

Camunda 8 Topics
1

Maybe I’m doing something wrong, but it seems that connector beans are not discovered any more. Is this the new philosophy?

I already made a bug report (some time ago and thought it was fixed) and manually fixed older connector discovery until the new version comes (the old one worked with beans but it created an instance using the no-args constructor before checking whether it exists already, so no no-args constructor lead to errors, but with the no-args constructor (or using fixed discovery) it still worked).

Is there a good solution or do I have to make another hack? The custom JsonMapper isn’t discovered either any more, basically all my beans are ingored now and you can just have static method calls to get stuff and connectors are created with the no-args constructor. This is not acceptable for me, it either has to work or I will have to write my own discovery again.

2

I did some research:

  1. OutboundConnectorAnnotationProcessor should load the connector beans and registers them (it registers it on the DefaultOutboundConnectorFactory)

  2. When the outbound connector factory bean is created OutboundConnectorDiscovery.loadConnectorConfigurations() is passed as argument.

I think it cannot work like that. The OutboundConnectorDiscovery is calling SPIConnectorDiscovery.discoverOutbound() and this will find the connector already and tries to create an instance with the (non-existing) no-args constructor (adding one doesn’t help either, nothing will be autowired). So it fails already before it could even check if there is already a connector bean for that connector type if there is no no-args constructor and if there is one nothing is autowired.

Basically the same bug I reported for previous versions, except that it is now even worse, because adding a no-args constructor doesn’t fix the problem. I guess I have to fix it myself.

3

One ugly workaround is to “disable” SPIConnectorDiscovery by replacing it with a new class io.camunda.connector.runtime.core.discovery.SPIConnectorDiscovery in the connector runtime (it takes precedence over dependencies):

public class SPIConnectorDiscovery {

    public static List<OutboundConnectorConfiguration> discoverOutbound() {
        return new ArrayList<>();
    }

    public static List<InboundConnectorConfiguration> discoverInbound() {
        return new ArrayList<>();
    }
}

It doesn’t really fix the problem, because now the two can’t be mixed. E.g. out-of-the-box connectors and custom connectors in the same runtime. Would need a runtime for connector beans and one for the others.

4

Was indeed doing something wrong. You need to remove the io.camunda.connector.api.outbound.OutboundConnectorFunction file for connector beans. Then it works correctly. I still had this file because I started with a template for custom connectors from Camunda.

Edit: This only fixes the problem when the connector runtime is not running in a docker container, otherwise there is the same problem with the no-args constructor.

Edit 2: Even stranger is that this behavior only seems to occur on windows machines and not on linux. There it runs without problem as long as the file mentioned above is removed.

5

Please be aware that the connector discovery depends on how the Spring container is searching for beans in the classpath. If you add the jar to the classpath it needs to be in the same package hierarchy that Spring is looking at when discovering beans using classpath scanning: Classpath Scanning and Managed Components :: Spring Framework

6

Thanks for your reply. After what I found out the question is more like: Why does SPI Discovery discover my beans on dockerized connector runtimes on windows? All other scenarios worked fine. Just docker + windows finds the connector bean on SPI discovery even when the file mentioned above was removed.

I don’t know what’s going on and it is probably not a Camunda issue, but the problem could still be fixed if beans are discovered first and take precedence, so if SPI would find it too for some reason it can ignore it without creating an instance.

7

I would recommend to remove the META-INF/services descriptor if you only want to use the Spring based lookup. Does that work for you?

8

@sbuettner that’s what I did and what was working on linux (always) and on windows if the runtime was started from intelliJ but not on windows if a docker image was created from that runtime, then somehow it suddenly SPI discovers them although it shouldn’t. And I recreated that image plenty of times… it is strange.