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.

Sign up for GitHub

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

Jump to bottom

UrlBasedViewResolvers should not override custom requestContextAttribute with null #23129

Closed
2 tasks
sbrannen opened this issue Jun 13, 2019 · 1 comment
Closed
2 tasks

UrlBasedViewResolvers should not override custom requestContextAttribute with null #23129

sbrannen opened this issue Jun 13, 2019 · 1 comment
Assignees
@sbrannen
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone
5.2 RC1

Comments

@sbrannen
Copy link
Member

Overview

org.springframework.web.servlet.view.UrlBasedViewResolver.buildView(String) and org.springframework.web.reactive.result.view.UrlBasedViewResolver.createView(String) both override the requestContextAttribute in the created View even if the requestContextAttribute in the UrlBasedViewResolver is null.

Consequently if a custom subclass of org.springframework.web.servlet.view.AbstractView or org.springframework.web.reactive.result.view.AbstractUrlBasedView configures the requestContextAttribute, it will be overwritten with null if the view is dynamically instantiated by a UrlBasedViewResolver. On the other hand, the custom configured requestContextAttribute will remain in tact if the view is used outside of a UrlBasedViewResolver, and this subtle difference can lead to unexpected results.

If the user explicitly configures the requestContextAttribute for a UrlBasedViewResolver, the user is probably (hopefully) aware of the effect. However, if the user does not explicitly configure the requestContextAttribute for a UrlBasedViewResolver we should not overwrite any custom configuration with null.

Deliverables

  • Only propagate a non-null requestContextAttribute to a dynamically instantiated View in UrlBasedViewResolver in spring-webmvc.
  • Only propagate a non-null requestContextAttribute to a dynamically instantiated View in UrlBasedViewResolver in spring-webflux.
@sbrannen sbrannen added in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement labels Jun 13, 2019
@sbrannen sbrannen added this to the 5.2 RC1 milestone Jun 13, 2019
@sbrannen sbrannen self-assigned this Jun 13, 2019
@sbrannen sbrannen changed the title UrlBasedViewResolvers override custom requestContextAttribute with null UrlBasedViewResolvers should not override custom requestContextAttribute with null Jun 13, 2019
sbrannen added a commit that referenced this issue Jun 13, 2019
@sbrannen
Do not override requestContextAttribute with null in UrlBasedViewReso…
0816a7f 
…lvers

Prior to this commit, if a subclass of
org.springframework.web.servlet.view.AbstractView or
org.springframework.web.reactive.result.view.AbstractUrlBasedView
configured a custom value for the requestContextAttribute, that value
was overwritten with null whenever the View was dynamically
instantiated by a UrlBasedViewResolver, and this could lead to
confusing behavior for users of the View.

This commit addresses this issue by ensuring that the
UrlBasedViewResolvers in spring-webmvc and spring-webflux do not
override the requestContextAttribute in a View if the
UrlBasedViewResolver has not been explicitly configured with a custom
requestContextAttribute value.

Closes gh-23129
@sbrannen
Copy link
Member Author

This work has already been completed in the following feature branch.

https://github.com/spring-projects/spring-framework/commits/issues/gh-23129

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sbrannen sbrannen

Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Milestone
5.2 RC1
Development

No branches or pull requests
1 participant
@sbrannen