camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schneider (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-4244) Refactor ExecutorService classes into a InstanceManagerPattern
Date Tue, 19 Jul 2011 10:07:57 GMT

     [ https://issues.apache.org/jira/browse/CAMEL-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Christian Schneider updated CAMEL-4244:
---------------------------------------

    Description: 
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.



  was:
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.



> 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

        

Mime
View raw message