Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PathMatchingResourcePatternResolver inconsistently throws IOException in case of non-existing resources [SPR-7365] #12023

Closed
spring-projects-issues opened this issue Jul 11, 2010 · 2 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jul 11, 2010

Christian Cwienk opened SPR-7365 and commented

PathMatchingResourcePatternResolver behaves inconsistently (and imho in an unintuitive manner) as to the respect of throwing IOExceptions when resolving a given ant-style path pattern to concrete resources (tested with local filesystem):

In cases where no files are found (existing directory with no matching files), an empty array of Resource is returned (which is intuitive). If however, a part of the pathPattern does not exist (i.e. a directory does not exist), an IOException is being thrown unless the non-existing directory is specified after the first occurence of a wildcard, in which case an empty result array is returned.

imho, this is unintuitive and inconsistent for two reasons:

  1. I'd expect a path pattern matcher to try match applying a best-effort strategy; in case nothing can be matched, I'd regard that as a normal outcome and would expect to get an empty result-array (which in some but not all cases actually happens)

  2. Provided throwing an IOException in case part of the specified path does not exist made sense; then I'd expect this behaviour to be also applied for path parts after occurrences of wildcards (which is not the case).


I've created a possible solution for this issue by subclassing the class in question (see attached files). However I'd very much appreciate it if this change could be incorporated into a future release of the Spring framework.

Best Regards,

Christian


Affects: 2.5.6

Attachments:

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Fortunately, this has already been fixed since Spring 3.0 RC2...

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Christian Cwienk commented

Great, thanks a lot; yet another reason to finally change to a newer release =)

@spring-projects-issues spring-projects-issues added type: enhancement A general enhancement in: core Issues in core modules (aop, beans, core, context, expression) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 3.0 RC2 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants