[
https://issues.apache.org/jira/browse/CAMEL-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067625#comment-13067625
]
Claus Ibsen commented on CAMEL-4244:
------------------------------------
The SPI interface should be kept as is IMHO.
I dont see a problem either that the default implementation uses an util class
for some of the JDK stuff related to thread pools. Neither that the default
implementation uses CamelContext which many implemtantors does. If you really
wanted then you remove the CamelContext dependency and add dependency to
Registry which it uses to lookup existing thread pools by id.
Is your goal to allow 3rd party to extend some XXX class in Camel and then not
have to implement as much logic to fully implement the ExecutorServiceStrategy
interface?
> Refactor ExecutorService classes into a InstanceManagerPattern
> --------------------------------------------------------------
>
> Key: CAMEL-4244
> URL: https://issues.apache.org/jira/browse/CAMEL-4244
> Project: Camel
> Issue Type: Improvement
> Affects Versions: 2.8.0
> Reporter: Christian Schneider
> Assignee: Christian Schneider
> Fix For: 2.9.0
>
>
> Currently the management of ExecutorSevices is scattered of several classes.
> I would like to refactor this to the
> http://c2.com/cgi/wiki?InstanceManagerPattern
> So there simply is one instance manager where ExecutorServices can be looked
> up and created on demand. This would replace :
> - org.apache.camel.impl.DefaultExecutorServiceStrategy
> - org.apache.camel.spi.ExecutorServiceStrategy
> - org.apache.camel.util.concurrent.ExecutorServiceHelper
> The complete configuration should be in the manager so it does not have a
> reference to CamelContext. An instance of the manager can be retrieved or set
> on the camel context.
> Currently a class that needs an executorService asks the
> ExecutorServiceHelper if there is already a suitable service. If there is
> none it creates it. This should be changed so the class that needs the
> ExecutorService just asks the ExecutorServiceManager for a suitable service
> and it will be created on the fly if none is available. So the whole
> management is concentrated in one class.
> The disadvantage is that there is no strategy anymore. So someone who wants
> to implement a new manager has to do the whole job. I think that this is not
> such a big problem though and we can reintroduce a strategy if it is really
> needed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
