[ 
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

        

Reply via email to