[jira] [Commented] (JCI-64) ReloadingClassLoader extend URLClassLoader vs. ClassLoader

["Torsten Curdt (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCI-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032881#comment-13032881 ] 

Torsten Curdt commented on JCI-64:
----------------------------------

Indeed the ClassLoader needs the same classpath management methods as an URLClassLoader. IIRC extending an URLClassLoader was not really an option though. Cannot remember why exactly from the top of my head.

> ReloadingClassLoader extend URLClassLoader vs. ClassLoader
> ----------------------------------------------------------
>
>                 Key: JCI-64
>                 URL: https://issues.apache.org/jira/browse/JCI-64
>             Project: Commons JCI
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 1.0
>            Reporter: Dave Marion
>            Assignee: Torsten Curdt
>             Fix For: 2.0
>
>
> Working on a project where the application starts, creates a new URLClassLoader for a thread (set via Thread.setContextClassLoader()) and starts the Thread. The Thread's classpath is different that the application that started it because resources are added via URLClassLoader.addURL(). I am trying to implement ReloadingClassLoader in this environment and I don't see how. Currently, the ReloadingClassLoader only knows about the resources on the SystemClassLoader's classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira