[
https://issues.apache.org/jira/browse/CAMEL-12833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627278#comment-16627278
]
ASF GitHub Bot commented on CAMEL-12833:
----------------------------------------
astefanutti edited a comment on issue #2532: CAMEL-12833: Provide a method of
customizing Camel CDI context creation
URL: https://github.com/apache/camel/pull/2532#issuecomment-424328642
> 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 prevents 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.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Provide a method of customizing Camel CDI context creation
> ----------------------------------------------------------
>
> Key: CAMEL-12833
> URL: https://issues.apache.org/jira/browse/CAMEL-12833
> Project: Camel
> Issue Type: Improvement
> Components: camel-cdi
> Reporter: James Netherton
> Assignee: James Netherton
> Priority: Major
>
> For some platforms it'd be useful if Camel CDI had some way of customizing
> the way in which a {{CamelContext}} was created. E.g for controlling which
> ClassLoader is used during instantiation.
> I propose to introduce a {{ContextCreateStrategy}} which users can provide
> custom instances of in their deployments. The default implementation will do
> {{CamelContext}} creation as per normal.
> Some more background for the motivation here:
> https://github.com/wildfly-extras/wildfly-camel/issues/2497
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
