commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCI-64) ReloadingClassLoader extend URLClassLoader vs. ClassLoader
Date Fri, 13 May 2011 07:50:47 GMT

    [ 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

Mime
View raw message