camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Commented] (CAMEL-4244) Refactor ExecutorService classes into a InstanceManagerPattern
Date Tue, 19 Jul 2011 11:27:58 GMT


Claus Ibsen commented on CAMEL-4244:

Christian I am not against any API changes. But I think we should refrain from bigger API
changes in the 2.x codebase. Camel 2.x is almost 2 year old now, and the API is becoming more

Yes there may not be so many people using ExecutorServiceStrategy, but the important point
is that there is always a SPI for any of the Camel core "features" where end users can customize
and plugin whatever they need. This is in fact what I hear often from Camel end users is that
they love its so flexible and customizable that they are confort using it as they wont be
trapped in a corner.

> 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
> 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