You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Henri Yandell (JIRA)" <ji...@apache.org> on 2006/07/05 05:57:32 UTC
[jira] Updated: (SANDBOX-42) JCI: random race conditions
[ 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