[WICKET-4617] ResourceStreamLocator vs ResourceFinder

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.5.7, 6.0.0-beta2
• Fix Version/s: 6.0.0-beta3
• Assignee: Carl-Eric Menzel
• Reporter: Carl-Eric Menzel
• Created: 20/Jun/12 11:12
• Updated: 03/Jul/12 13:15
• Resolved: 03/Jul/12 13:15

Description

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?