[
https://issues.apache.org/jira/browse/TAP5-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-1301.
--------------------------------
Resolution: Not a Problem
Another year has passed since the last comment. Therefore, we assume this issue
has either been resolved in the meantime or it is no longer relevant to you.
If recent versions of Tapestry (i.e. 5.4 betas and 5.3.7) are still affected,
please reopen the issue and adjust the "Affected Version/s" property.
> Allow changing the ClassLoader Tapestry uses for loading classes and resources
> ------------------------------------------------------------------------------
>
> Key: TAP5-1301
> URL: https://issues.apache.org/jira/browse/TAP5-1301
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-ioc
> Affects Versions: 5.1.0.4
> Reporter: Dan Adams
> Priority: Minor
> Labels: bulk-close-candidate
>
> I have a situation where we want to extend the classloader used for the
> application with additional classes in a non-container-specfic way.
> TapestryFilter.provideExtraModuleDefs() appears to support this at first
> except that there are many references throughout Tapestry to
> Thread.currentThread().getContextClassLoader() which bypasses any classloader
> you provide when creating the ModuleDef. Furthermore, there is a constructor
> to RegistryBuilder that allows providing your own root classloader but even
> if you can get that to work the above call make it's moot as it won't find
> any of your page templates and such. This could be quite simple if:
> - TapestryFilter and it's related classes allowed extending the ClassLoader
> (by wrapping it in a URLClassLoader) for instance
> - Using a definitive ClassLoader rather than
> Thread.currentThread().getContextClassLoader() to get resources.
> May affect more recent versions but I have not checked.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
