[camel k] inconsistent libs for webhook and api provider

[nicolaferraro]

This is a...

[ ] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Documentation issue or request

Description

Both webhook and api provider are based on the Camel servlet component which expects that the runtime will provide a server. This is true for spring-boot based integrations where we add spring-boot-web by default, but Camel K integrations are no more spring-boot based.

[heiko-braun]

We could overcome some of these issues when Camel-K is enabled, by introducing a strategy pattern that allows to fallback to the current means of creating integrations for cases that don't work (i.e. blacklisted in meta data)

[zregvart]

The only dependency in API provider on the Servlet API that I can see is SpecificationContentTypeFilter, which we can remove by using api.specification.contentType.json and api.specification.contentType.yaml Camel REST properties here:

https://github.com/syndesisio/syndesis/blob/ba937b8043a18a90019b5b354f19ff3b10ae033b/app/integration/project-generator/src/main/resources/io/syndesis/integration/project/generator/templates/RestRouteConfiguration.java.mustache#L19

We can add:

diff --git a/app/integration/project-generator/src/test/resources/io/syndesis/integration/project/generator/testGenerateApplicationWithRestDSL/RestRouteConfiguration.java b/app/integration/project-generator/src/test/resources/io/syndesis/integration/project/generator/testGenerateApplicationWithRestDSL/RestRouteConfiguration.java
index 5b2da2572..18afdf45a 100644
--- a/app/integration/project-generator/src/test/resources/io/syndesis/integration/project/generator/testGenerateApplicationWithRestDSL/RestRouteConfiguration.java
+++ b/app/integration/project-generator/src/test/resources/io/syndesis/integration/project/generator/testGenerateApplicationWithRestDSL/RestRouteConfiguration.java
@@ -16,6 +16,8 @@ public class RestRouteConfiguration {
                 restConfiguration()
                     .contextPath("/")
                     .component("servlet")
+                    .apiProperty("api.specification.contentType.json", "application/vnd.oai.openapi+json;version=2.0")
+                    .apiProperty("api.specification.contentType.yaml", "application/vnd.oai.openapi;version=2.0")
                     .endpointProperty("headerFilterStrategy", "syndesisHeaderStrategy");

                 rest()

For the Webook, I think we can also configure it not via ServletRegistrationBean but with REST DSL API.

These changes in the end will allow us to use any component that supports Camel REST DSL. I see Camel-K has an example with Restlet, but we can (probably) use Netty, Jetty or Undertow.

[lburgazzoli]

The problem is that the components are based on the servlet component and they are supposed to use the one that spring provides, so also the customizer we have do not work in a non spring world (afaik)

[zregvart]

We currently have a great deal of connectors using the customizers (find . -name '*Customizer.java'|cut -d '/' -f 2|sort -u):

• api-provider
• aws-s3
• fhir
• gmail
• google-calendar
• google-sheets
• kudu
• odata
• rest-swagger
• salesforce
• servicenow
• slack
• sql
• telegram
• webhook

Seems to me we need to provide support for loading these in Camel-K, perhaps some form of service loading, we can then generate the META-INF/service for Camel-K and leave the current spring.factories for Spring Boot based integration publish.

[lburgazzoli]

sorry it is not the customizers it is this: https://github.com/syndesisio/syndesis/blob/master/app/connector/api-provider/src/main/resources/spring.factories

we do not have yet a generic support in this for camel-k

[zregvart]

We can push SyndesisHeaderStrategy to the customizers in most cases I think. We can also register it via Camel's registry.

[heiko-braun]

Lowering the priority after talking to Gary