fix(trait): nil pointer dereference when applying traits during kit building

[tadayosi]

Fix #3205

Release Note

fix(trait): nil pointer dereference when some traits are enabled at IntegrationPlatform

[tadayosi]

I found that the impact of the bug is much broader than Tracing trait. In essence, every trait that is naively implemented assuming e.Integration is always present can throw the nil pointer and kill the operator when it is enabled at IntegrationPlatform...

I'm trying to create a better fix that solves the issue altogether.

[tadayosi]

@squakez @oscerd @astefanutti

The last commit might be a bit controversial but I find it necessary for the fix. I think Camel trait has actually been influential to kits but hasn't been explicitly specified so.

I'd like to make sure I'm not doing something completely wrong, so please review this again.

[squakez]

Thanks @tadayosi . I think it partially influences the kits. Ie, if the runtime version is changed, then, it makes sense to build a new kit. However, if a property change (a runtime property, as build time property are specified in the builder trait), we probably don't want to rebuild the kit. I'm not sure how to tackle this, maybe we should split the trait?

[tadayosi]

However, if a property change (a runtime property, as build time property are specified in the builder trait), we probably don't want to rebuild the kit. I'm not sure how to tackle this, maybe we should split the trait?

Thanks. That's very valid point. It also looks not so easy to split the trait and at the same time keep backward compatibility. And some common E2E tests still failing may suggest there are a few more traits that would implicitly influence kits...

I think there's a bit of mess in traits about what actually influence kits and what do not and their relationship with the return value of the InfluencesKit() methods that should be sorted out. But I'm a bit intimidated to try to address it within v1. We can rather tackle it in Camel K v2.

I'll explore another approach that checks possibility of nil integration in every trait, instead of making Camel trait explicitly influencing kits and applying traits that influence kits during kit building.

[tadayosi]

Applied the 2nd approach of thorough nil checking.

Good news is that most of the traits are bug free, as they are already guarded with the Integration Phase checking methods which means if Integration is absent they simply return false instead of crashing.

Nonetheless I made it explicit by checking e.Integration == nil at the beginning of every trait's Configure() method so that we can easily distinguish if it's a trait targeted for Integration or not.