Skip to content

ServletTestExecutionListener breaks old code [SPR-11144] #15771

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
spring-projects-issues opened this issue Dec 4, 2013 · 3 comments
Closed
Assignees
Labels
status: backported An issue that has been backported to maintenance branches type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Dec 4, 2013

Aleksandr Dubinsky opened SPR-11144 and commented

The Javadoc for ServletTestExecutionListener says:

Note that ServletTestExecutionListener is enabled by default but takes no action if the ApplicationContext loaded for the current test is not a WebApplicationContext.

However, this is not true. The afterTestMethod() method calls RequestContextHolder.resetRequestAttributes() without checking for the presence of a WebApplicationContext. This breaks old test code simply by upgrading to Spring 3.2, and it is difficult for a user to ascertain why.


Issue Links:

Backported to: 3.2.6

@spring-projects-issues
Copy link
Collaborator Author

Sam Brannen commented

Aleksandr Dubinsky, good catch!

We'll address this in time for Spring Framework 4.0 with a potential backport to 3.2.x

Regards,

Sam

@spring-projects-issues
Copy link
Collaborator Author

Sam Brannen commented

Fixed as described in the comments for commits c89985c and a3b022a on GitHub:

Ensure ServTEL doesn't reset ReqAttrs by accident

Prior to this commit, the ServletTestExecutionListener did not
overwrite RequestAttributes in the RequestContextHolder if the
ApplicationContext associated with the given TestContext was not a
WebApplicationContext; however, the ServletTestExecutionListener would
clear the RequestAttributes after every test method execution,
regardless of whether the context was a WebApplicationContext or not.
This behavior breaks backwards compatibility with integration tests
that managed the RequestAttributes in RequestContextHolder themselves.

This commit addresses this issue by introducing a TestContext attribute
named RESET_REQUEST_CONTEXT_HOLDER_ATTRIBUTE in
ServletTestExecutionListener. This attribute is used internally within
ServletTestExecutionListener to ensure that the RequestContextHolder is
only cleared (i.e., reset) if the ServletTestExecutionListener actually
populated the RequestContextHolder.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Dec 10, 2013

Sam Brannen commented

Applied a further fix as described in the comments for commits 6ded287 (3.2.6) and 099b10d (4.0) on GitHub:

Honor presence of @WebAppConfiguration in ServTEL

The previous commit for issue #15771 revealed a bug in
ServletTestExecutionListener (STEL). Specifically, STEL acted on the
fact that the ApplicationContext for a given TestContext was an
instance of WebApplicationContext. This behavior could potentially
break test code from previous releases of the Spring Framework that
relied on a custom setup of the RequestAttributes in the
RequestContextHolder with a custom WebApplicationContext ContextLoader.

This commit addresses this issue by ensuring that STEL only comes into
play if the test class is annotated with @WebAppConfiguration (for
prepareTestInstance() and beforeTestMethod()) or if the TestContext
attribute named RESET_REQUEST_CONTEXT_HOLDER_ATTRIBUTE is set to
Boolean.TRUE (for afterTestMethod()).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: backported An issue that has been backported to maintenance branches type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants