You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by bu...@apache.org on 2005/08/08 08:12:10 UTC

DO NOT REPLY [Bug 36069] New: - JCI: CompilingClassLoader race conditions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36069>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36069

           Summary: JCI: CompilingClassLoader race conditions
           Product: Commons
           Version: unspecified
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Sandbox
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: plightbo@gmail.com


Right now, when you create a new classloader, the FilesystemAlterationMonitor
kicks off. However, it may not get done loading classes before the application
using the CL requests one of those classes. Currently, the parent CL will be
used, and from that point on everything gets goofed.

I suggest changing the CLs such that when they are created, they block until
they have made an initial pass through the directories. I was able to hack this
by taking the FilesystemAlterationMonitor.run() method (the part inside the
loop) and refactoring it to doRun() and then calling that right after creating
the class. Ghetto, but it seemed to help.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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