You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on #5488 I realized we have certain limitations/assumptions in the way we require to execute the jvm from the Camel application container Pod. It turns out that, due to the usage of Joor and its limitations (see [1]) we cannot make a reliable usage of the fast-jar (and eventually fat-jar if/when we move to managed Springboot).
I think the root cause is coming from the fact that we're loading the routes dynamically, ie, we create a generic project, and at runtime we inject the route into the Camel context and start it (please, @lburgazzoli correct me if this is wrong). This was a cornerstone of the reusability of an IntegrationKit which spared some time to build a new project. However, I wonder if this is a design we still want to maintain as it gives us certain limitations, and, remove the parity between a normal Camel (Quarkus) development and Camel K.
If we instead let the build to consider the route at runtime, we should be able to use the fa(s)t-jar and leverage the default Camel mechanism to load a route. Of course, the trade off is that we would be losing the possibility to reuse the same IntegrationKit for different Integrations as, each of them would be including the route into the build. We should understand if this design can still be compatible with incremental image [2] (I think it does, since the route would be contained in the built dependency which is going to be replaced in the new Kit created).
This is something to address in a major release, as it would break existing Integrations compatibility, but I think that it is a good opportunity to collect feedback to be ready when this is coming.
The redesign of this part would probably gives us the possibility to move to a jre (and distroless) base image, reducing the CVE surface area and the size of each image (see also #3743)
This looks like an interesting move to me also. Currently when we update the kamelets we have issues with inconsistency between the kamelets' definitions and the dependencies already contained in the images (Explained in this forum's post).
Having all routes and dependencies inside the image would definitely avoid this issue.
While working on #5488 I realized we have certain limitations/assumptions in the way we require to execute the jvm from the Camel application container Pod. It turns out that, due to the usage of Joor and its limitations (see [1]) we cannot make a reliable usage of the fast-jar (and eventually fat-jar if/when we move to managed Springboot).
I think the root cause is coming from the fact that we're loading the routes dynamically, ie, we create a generic project, and at runtime we inject the route into the Camel context and start it (please, @lburgazzoli correct me if this is wrong). This was a cornerstone of the reusability of an IntegrationKit which spared some time to build a new project. However, I wonder if this is a design we still want to maintain as it gives us certain limitations, and, remove the parity between a normal Camel (Quarkus) development and Camel K.
If we instead let the build to consider the route at runtime, we should be able to use the fa(s)t-jar and leverage the default Camel mechanism to load a route. Of course, the trade off is that we would be losing the possibility to reuse the same IntegrationKit for different Integrations as, each of them would be including the route into the build. We should understand if this design can still be compatible with incremental image [2] (I think it does, since the route would be contained in the built dependency which is going to be replaced in the new Kit created).
This is something to address in a major release, as it would break existing Integrations compatibility, but I think that it is a good opportunity to collect feedback to be ready when this is coming.
[1] jOOQ/jOOR#69
[2] https://camel.apache.org/camel-k/next/architecture/incremental-image.html
The text was updated successfully, but these errors were encountered: