> The strategy is required to be public. Yes, the extension figures out the > correct ClassLoader, but I've left it up to users to decide what do with it. > In my use case it involves a TCCL switch, and that's not something we want in > every environment. Hence the ClassLoader is basically ignored in the default > strategy. The camel context ClassLoader setting that you saw is only for unit > testing to prove the custom strategy is being invoked.
That is my understanding. Exposing that SPI is more work, hence I want to make sure it's worth it :) Regarding the TCCL switch, I think it'd be fine to have it done for all Java SE and Java EE environments. I'm not sure what would be the consequences of doing it in OSGi. However Camel CDI on OSGi is not recommended. That being said, I understand exposing that SPI prevent from worrying about the impacts. On the other hand, we need to polish the contract. `ContextCreateStrategy` is not really a _create strategy_, it's more a classloader suggestion provider for post constructing the Camel context. > The reason I didn't opt for `CdiCamelConfiguration` is that users would have > to configure it for every application. With a bean, I can automatically make > it available to every application for my platform use case. `CdiCamelConfiguration` is an event fired by the extension that can be observed in any CDI bean. So, at the platform level, that would imply adding a bean with an observer method and provided the strategy. > If you think a bean is not the right solution, then I don't see many options > aside from some sort of static configuration, or adding the custom logic I > need to implement directly in the CDI extension. Both are sub-optimal IMO. I think a bean is the right solution, if we decide to expose an extension point. [ Full content available at: https://github.com/apache/camel/pull/2532 ] This message was relayed via gitbox.apache.org for [email protected]
