[
https://issues.apache.org/jira/browse/CAMEL-4298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078696#comment-13078696
]
Claus Ibsen commented on CAMEL-4298:
------------------------------------
We should not pull the rug under Camel end users. We should allow them amble
time to migrate from @deprecated APIs to its replacement.
The ExecutorServiceStrategy/ExecutorServiceManagement is in fact used also by
Camel components such as:
- camel-stream
- camel-routebox
- camel-netty
- camel-mina
- camel-kestrel
- camel-jms
- camel-hdfs
- camel-hazelcast
Its not so uncommon to need a background task to run, or a scheduled task to
run every X etc. For that people would have to use the ExecutorService.
By using the Camel ExecutorServiceStrategy/Management, we tell the users, that
they get as a bonus, the thread pool enlisted/management in JMX, they get
thread names that are human readable, and Camel ensures the thread pool
lifecycle as well etc.
So if we pull the rug, then people will discourage using the API from Camel and
go back and use the Executors API from the JDK. This would be a shame, as then
end users cannot have human readable thread names, and all their threads pools
listed in JMX etc.
Besides the old API was designed to resemble the API from the JDK, such as the
Executors and ThreadPoolExecutor.
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/Executors.html
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html
With the new API that resemble is gone, and end users know need to understand
the ThreadPoolBuilder. So the API changes may in fact not be that well thought.
I frankly like when you can do a one liner (without any extra Camel imports)
{code}
this.executor =
getCamelContext().getExecutorServiceStrategy().newSingleThreadExecutor(this,
"MyTask");
{code}
That is no longer possible with the new API as you must use the
ThreadPoolBuilder and this need to add that as an import.
Likewise one of the recent developed 3rd party Camel component uses the
ExecutorServiceStrategy
http://code.google.com/p/oracle-coherence-camel-component/
And I am sure there are more components out there using that.
I suggest to put back the ExecutorServiceStrategy interface. For its
implementation you just delegate to the new ExecutorServiceManager. That would
in fact also be a testimony that the new API covers all the old uses cases.
> Add back ExecutorServiceStrategy and mark it as @deprecated
> -----------------------------------------------------------
>
> Key: CAMEL-4298
> URL: https://issues.apache.org/jira/browse/CAMEL-4298
> Project: Camel
> Issue Type: Task
> Components: camel-core
> Reporter: Claus Ibsen
> Assignee: Christian Schneider
> Fix For: 2.9.0
>
>
> The old ExecutorServiceStrategy was refacted into ExecutorServiceManager. But
> it was removed. This was a mistake as it breaks backwards compatibility, and
> people are not given a reasonable time to adjust.
> So we should add back the ExecutorServiceStrategy and have it marked as
> @deprecated. It can then just under the hood, use the ExecutorServiceManager.
> Then in a future Camel release we can removed the @deprecated
> ExecutorServiceStrategy (for example Camel 3.0, or in eg 1 year from now)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
