[
https://issues.apache.org/jira/browse/WICKET-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402219#comment-13402219
]
Carl-Eric Menzel commented on WICKET-4617:
------------------------------------------
My new solution (will be in sandbox/resourcefinder later today) clarifies
ResourceStreamLocator and ResourceFinder like this:
- ResourceStreamLocator uses a ResourceNameIterator to generate filenames to
try and then uses a list of ResourceFinders to load the file.
- ResourceStreamLocator no longer does any loading on its own
- IResourcePath is removed - adding multiple paths to a single Path instance is
rather odd
- Path and WebApplicationPath both just implement IResourceFinder
- ResourceSettings now contains a list of IResourceFinders instead of just one
- to look in multiple paths, you add Path instances to that list
- Instead of ResourceStreamLocator's hackish classpath loading, there is a new
ClassPathResourceFinder that cleanly separates this stuff. it also simply
resides in the list in ResourceSettings, put there by Application and
WebApplication.
- the META-INF/resources lookup is just another ClassPathResourceFinder,
instead of being hardcoded in RSL.
> 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
