Skip to content

ServletContext.getResourcePaths() does not return all matching resources with Undertow #17243

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

Closed
wilkinsona opened this issue Jun 18, 2019 · 3 comments
Labels
for: external-project For an external project and not something we can fix type: bug A general bug

Comments

@wilkinsona
Copy link
Member

Our CompositeResourceManager only works property for ServletContext.getResource(). For ServletContext.getResourcePaths() the search stops as soon as the first delegate ResourceManager returns a non-null Resource. As a result, any resource paths that would have been provided by any subsequent ResourceManagers are lost.

@wilkinsona
Copy link
Member Author

A secondary problem is that Undertow's URLResource, which we use when running a packaged jar or war, only supports listing resources in a directory for file: URLs. This means that directories within a jar or war cannot be listed.

@wilkinsona
Copy link
Member Author

This is blocked at the moment as Undertow's ServletContext implementation filters out any resources that are not available on the file system in its getResourcePaths() method. I've opened UNDERTOW-1561.

@wilkinsona wilkinsona added the status: blocked An issue that's blocked on an external project change label Jun 18, 2019
@wilkinsona
Copy link
Member Author

There's been no movement on the Undertow issue in the 2.5 months since it was opened. I'm going close this one for now. We can re-open it if there's movement on the Undertow side and if changes in Spring Boot are still necessary.

@wilkinsona wilkinsona removed this from the 2.1.x milestone Sep 2, 2019
@wilkinsona wilkinsona added for: external-project For an external project and not something we can fix and removed status: blocked An issue that's blocked on an external project change labels Sep 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: external-project For an external project and not something we can fix type: bug A general bug
Projects
None yet
Development

No branches or pull requests

1 participant