[
https://issues.apache.org/jira/browse/OFBIZ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068936#comment-13068936
]
Martin Kreidenweis commented on OFBIZ-4335:
-------------------------------------------
I have an alternate, very simple patch:
{code}
Index: framework/base/src/org/ofbiz/base/concurrent/ExecutionPool.java
===================================================================
--- framework/base/src/org/ofbiz/base/concurrent/ExecutionPool.java
(Revision 1144132)
+++ framework/base/src/org/ofbiz/base/concurrent/ExecutionPool.java
(Arbeitskopie)
@@ -39,7 +39,7 @@
@SourceMonitored
public final class ExecutionPool {
public static final String module = ExecutionPool.class.getName();
- public static final ScheduledExecutorService GLOBAL_EXECUTOR =
getExecutor(null, "ofbiz-config", -1, true);
+ public static final ScheduledExecutorService GLOBAL_EXECUTOR =
getExecutor(null, "ofbiz-config", -1, false);
protected static class ExecutionPoolThreadFactory implements ThreadFactory
{
private final ThreadGroup group;
{code}
The problem is indeed that the wrong class loader is used for the
"ofbiz-config-*" threads ({{NativeLibClassLoader}} instead of
{{CachedClassLoader}}). This happens when the threads are created by the static
code in {{ExecutionPool.java}} when it is executed before the
{{ClassLoaderContainer.init()}} initializes the {{CachedClassLoader}}.
This also causes other problems like: The local resolution of XML Schema files
won't work any more because it's also using the wrong classloader, which can't
find the XSD files:
{code}
[java] 2011-07-21 12:21:45,333 (ofbiz-config-0) [
UtilXml:1022:WARN ] [UtilXml.LocalResolver.resolveEntity] could not find LOCAL
DTD/Schema with publicId [null] and the file/resource is [service-eca.xsd]
{code}
You can trigger this behavior in current ofbiz trunk by setting an expire time
for the properties cache in {{cache.properties}}
{code}
properties.UtilPropertiesResourceCache.expireTime=10000
{code}
The {{Debug.log()}} statements in the {{ContainerLoader}} then load the logging
configuration properties file and cache it. If an expire time is set, the
{{ExecutionPool}} is used and creates the "ofbiz-config-*" threads too early.
By not pre-starting the "ofbiz-config-*" threads in the static code (patch
above), the threads are then created later on, when the "main" thread
classloader has become the {{CachedClassLoader}} and everythings starts working
again. :-)
> Delegator creation fails with new ExecutionPool on trunk
> --------------------------------------------------------
>
> Key: OFBIZ-4335
> URL: https://issues.apache.org/jira/browse/OFBIZ-4335
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: SVN trunk
> Reporter: Alexander Reelsen
> Assignee: Adam Heath
> Attachments: FixExecutionPoolThreadClassLoader.patch
>
>
> he creation of the delegator done in GenericDelegator fails for me, when
> starting ofbiz or running run-install-exttest. This is the exception I am
> getting for each delegator
> [java] 2011-07-08 10:15:17,691 (ofbiz-config-2) [
> GenericHelperFactory:62 :WARN ]
> [java] ---- exception report
> ----------------------------------------------------------
> [java] Exception: java.lang.ClassNotFoundException
> [java] Message: org.ofbiz.entity.datasource.GenericHelperDAO
> [java] ---- stack trace
> ---------------------------------------------------------------
> [java] java.lang.ClassNotFoundException:
> org.ofbiz.entity.datasource.GenericHelperDAO
> [java] java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> [java] java.security.AccessController.doPrivileged(Native Method)
> [java] java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> [java] java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> [java] java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> [java]
> org.ofbiz.entity.datasource.GenericHelperFactory.getHelper(GenericHelperFactory.java:60)
> [java]
> org.ofbiz.entity.GenericDelegator.initializeOneGenericHelper(GenericDelegator.java:268)
> [java]
> org.ofbiz.entity.GenericDelegator.access$000(GenericDelegator.java:89)
> [java] org.ofbiz.entity.GenericDelegator$1.call(GenericDelegator.java:287)
> [java] org.ofbiz.entity.GenericDelegator$1.call(GenericDelegator.java:285)
> [java] java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> [java] java.util.concurrent.FutureTask.run(FutureTask.java:138)
> [java]
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
> [java]
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
> [java]
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> [java]
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> [java] java.lang.Thread.run(Thread.java:680)
> [java]
> --------------------------------------------------------------------------------
> When removing the ExecutionPool specific code which returns the Callable
> stuff from the GenericDelegator everything gets back to work, so there might
> be some problem.
> Reply from doogie:
> It's the Thread.currentThread().getContextClassLoader() call in
> GenericHelperFactory that is broken.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
