[ https://issues.apache.org/jira/browse/FELIX-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet resolved FELIX-4988. ------------------------------------ Resolution: Fixed Assignee: Guillaume Nodet Fix Version/s: resolver-1.6.0 Committing to https://svn.apache.org/repos/asf/felix/trunk ... M resolver/src/main/java/org/apache/felix/resolver/ResolverImpl.java Committed r1696530 > ResolverImpl uses an internal ExecutorService > --------------------------------------------- > > Key: FELIX-4988 > URL: https://issues.apache.org/jira/browse/FELIX-4988 > Project: Felix > Issue Type: Bug > Components: Resolver > Environment: All > Reporter: Thomas Watson > Assignee: Guillaume Nodet > Fix For: resolver-1.6.0 > > > Latest code in trunk for org.apache.felix.resolver.ResolverImpl.ResolverImpl > constructor will create an internal ExecutorService based on the results of > Runtime.getRuntime().availableProcessors(). > I would much rather be able to pass in my own ExecutorService so I can > control the behavior and lifecycle of the executor myself. The current > implementation will create a new ExecutorService using > java.util.concurrent.Executors.newFixedThreadPool(int) and shuts it down each > resolve() operation. It would be much better to be able to control the > ExecutorService from outside of the ResolveImpl. > The code in its current form will force me to use > org.apache.felix.resolver.ResolverImpl.ResolverImpl(Logger, int) and passing > in 1 for parallelism to prevent extraneous thread creation for each framework > resolve operation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)