commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SANDBOX-42) JCI: random race conditions
Date Wed, 05 Jul 2006 03:57:32 GMT
     [ http://issues.apache.org/jira/browse/SANDBOX-42?page=all ]

Henri Yandell updated SANDBOX-42:
---------------------------------

    Component: JCI

> JCI: random race conditions
> ---------------------------
>
>          Key: SANDBOX-42
>          URL: http://issues.apache.org/jira/browse/SANDBOX-42
>      Project: Commons Sandbox
>         Type: Bug

>   Components: JCI
>  Environment: Operating System: other
> Platform: Other
>     Reporter: Patrick Lightbody

>
> I'm using Jetty and configuring a custom classloader to allow for rapid
> application development. I have a File[] that is ordered in the correct
> dependency order. The code to construct the ClassLoader for Jetty is:
>             ClassLoader parent = Thread.currentThread().getContextClassLoader();
>             for (int i = 0; i < files.length; i++) {
>                 File file = files[i];
>                 parent = new CompilingClassLoader(parent, file, new
> EclipseJavaCompiler());
>                 Field famField = parent.getClass().getDeclaredField("fam");
>                 famField.setAccessible(true);
>                 FilesystemAlterationMonitor fam = (FilesystemAlterationMonitor)
> famField.get(parent);
>                 fam.doRun();
>                 Thread.sleep(500);
>             }
>             URLClassLoader url = new MyURLClassLoader(urls, parent);
> Note the fam hack -- that has been reported in another issue. The
> MyURLClassLoader is required for two reasons:
> 1) Jetty (actually Jasper) requires a URLClassLoader
> 2) The MyURLClassLoader loads classes in the standard web-app method, rather
> than the standard Java way (parent last, not first)
> Generally, this stuff works great. But about 30% of the time, some classes don't
> get loaded by the CompilingClassLoader and manage to get loaded by the original
> parent classloader (context classloader). This causes serious problems
> (ClassCastExceptions, etc). 
> It is clear there are some funky race conditions going on wit the way JCI kicks
> off threads to do work. I think generally the code is fine, but the "first pass"
> that the threads do need to be done synchrounously, rather than in the
> background. I attempted to do this with "fam.doRun()", but I guess I didn't
> catch everything.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message