[
https://issues.apache.org/jira/browse/WICKET-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402216#comment-13402216
]
Carl-Eric Menzel commented on WICKET-4617:
------------------------------------------
Okay, I just put my new class in -core without moving the rest.
I found a basically broken test: org.apache.wicket.util.resource.ResourceTest
plays around with Path, but never actually tests that class. Path never finds
the resources the test wants it to find. Instead, the test is fooled by
ResourceStreamLocator always falling back on classpath loading, which finds the
resource.
This is exactly what I had in mind when I mentioned the mixed-up
responsibilities of RF and RSL :-)
This test is trying to test Path but is actually testing RSL's classpath
loading. I'm going to refactor it to actually test those two things separately
in master, and then port it over to the new resource loading.
> ResourceStreamLocator vs ResourceFinder
> ---------------------------------------
>
> Key: WICKET-4617
> URL: https://issues.apache.org/jira/browse/WICKET-4617
> Project: Wicket
> Issue Type: Bug
> Affects Versions: 6.0.0-beta2, 1.5.7
> Reporter: Carl-Eric Menzel
> Assignee: Carl-Eric Menzel
>
> I'm a bit confused by the responsibilities of ResourceFinder vs
> ResourceStreamLocator. Looking around in the code, I found the following:
> - IResourceFinder is apparently only implemented via its extension interface
> IResourcePath. Its two implementations Path and WebApplicationPath look
> through a list of filesystem folders for files.
> - ResourceStreamLocator does two things:
> - it loads resources, either via an IResourceFinder (which only finds
> filesystem resources) or via the classloader (it does this itself).
> - it uses a ResourceNameIterator to generate all possible filename
> variations based on locale and style and then tries to load one of them via
> the above mechanisms.
> Is this correct?
> If so, I think we have some mixed-up responsibilities here. I propose the
> following:
> - add a third IResourcePath implementation (e.g. ClassloaderPath) that
> handles loading of resources in classpaths. It should be able to try multiple
> paths (e.g. "/", "META-INF/resources" etc).
> - Instead of a single ResourceFinder, Application should have a list of them,
> by default containing WebApplicationPath (today's default) and the new
> ClassloaderPath.
> - ResourceStreamLocator should not do any loading on its own at all and just
> use the ResourceFinders defined in this new list in Application.
> This would also get rid of the hard-coded "META-INF/resources" lookup that
> currently is done in ResourceStreamLocator (I'll write a second ticket about
> that, it's causing us some problems).
> I think this could still be done within 6.0. Objections?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
