You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Jochen Kemnade (JIRA)" <ji...@apache.org> on 2014/05/13 15:23:23 UTC

[jira] [Closed] (TAP5-1301) Allow changing the ClassLoader Tapestry uses for loading classes and resources

     [ 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)