camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schneider (JIRA)" <>
Subject [jira] [Resolved] (CAMEL-4244) Refactor ExecutorService classes into a InstanceManagerPattern
Date Tue, 02 Aug 2011 07:10:27 GMT


Christian Schneider resolved CAMEL-4244.

    Resolution: Fixed

> Refactor ExecutorService classes into a InstanceManagerPattern
> --------------------------------------------------------------
>                 Key: CAMEL-4244
>                 URL:
>             Project: Camel
>          Issue Type: Improvement
>    Affects Versions: 2.8.0
>            Reporter: Christian Schneider
>            Assignee: Christian Schneider
>             Fix For: 2.9.0
>         Attachments: CAMEL-4244.patch
> Currently the management of ExecutorSevices is scattered of several classes. 
> I would like to refactor this to the
> 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:


View raw message