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

check file with realPath is existing #26709

Closed
wants to merge 1,006 commits into from
Closed

Conversation

drgnchan
Copy link
Contributor

#26707 .Tomcat's StandardContext.getRealPath(String path) will return non null value when the file actually not exists.So add some code in ServletContextResource to check file is actually exists with jdk's File class.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 21, 2021
Copy link

@cuspymd cuspymd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is already an exists() method, do you think it is correct to check the existence of the file in the isFile() method?

@drgnchan
Copy link
Contributor Author

There is already an exists() method, do you think it is correct to check the existence of the file in the isFile() method?

maybe it is a directory.

@rstoyanchev rstoyanchev added the in: core Issues in core modules (aop, beans, core, context, expression) label Nov 11, 2021
rstoyanchev and others added 26 commits January 12, 2022 08:55
….2, AssertJ 3.22, HtmlUnit 2.56, XMLUnit 2.8.4
# Conflicts:
#	build.gradle
Prior to this commit, the PrintingResultHandler in MockMvc -- typically
invoked via .andDo(print()) -- printed an `application/json` response
body using the default encoding (ISO-8859-1), which resulted in UTF-8
characters being garbled.

Since an `application/json` response is implicitly encoded using UTF-8,
the PrintingResultHandler now infers UTF-8 encoding for such response
bodies.

Closes spring-projectsgh-27926
Prior to this commit, the `apiDiff` custom Gradle task would only use
the configured repositories in the build to generated the API diff
report. This causes issues when the report has to be generated against a
previous milestone: the Spring Framework build only relies on Maven
Central and a specific `libs-spring-framework-build` repository for
building the project. In this case, the task cannot resolve the previous
milestone artifacts to generate the report.

This commit improves the `ApiDiffPlugin` to automatically add the Spring
Milestone repository to the root project configuration when the task is
executed.

Fixes spring-projectsgh-27928
Prior to this commit, XmlValidationModeDetector did not properly parse
all categories of comments (described below). When such categories of
comments were encountered XmlValidationModeDetector may have
incorrectly detected that an XML file used a DTD when it used an XSD,
or vice versa.

This commit revises the parsing algorithm in XmlValidationModeDetector
so that multi-line comments and multiple comments on a single line are
properly recognized.

Specifically, with this commit the following categories of comments are
now handled properly.

- Multiple comments on a single line
- Multi-line comment: beginning on one line and then ending on another
  line with an additional comment following on that same line.
- Multi-line comment: beginning at the end of XML content on one line
  and then spanning multiple lines.

Closes spring-projectsgh-27915
Instead of simply returning prematurely and allowing the tests to be
marked as SUCCESS, this commit uses a failed assumption to abort the
the trasferTo tests for Undertow, resulting in the parameterized test
invocation properly being marked as ABORTED.

See spring-projectsgh-25310
This commit introduces a dedicated (disabled) transferToWithUndertow()
test method to simplify debugging of transferTo issues with Undertow.

See spring-projectsgh-25310
Closes spring-projectsgh-27908
Commit 6316a35 introduced a regression for property names starting with
multiple uppercase letters (such as setEMail(...)).

This commit fixes that regression and includes an additional test to
cover this case.

See spring-projectsgh-27929
Closes spring-projectsgh-27941
jhoeller and others added 26 commits February 17, 2022 22:37
Prior to this commit, SpEL was able to recover from an error that
occurred while running a CompiledExpression; however, SpEL was not able
to recover from an error that occurred while compiling the expression
(such as a java.lang.VerifyError). The latter can occur when multiple
threads concurrently change types involved in the expression, such as
the concrete type of a custom variable registered via
EvaluationContext.setVariable(...), which can result in SpEL generating
invalid bytecode.

This commit addresses this issue by catching exceptions thrown while
compiling an expression and updating the `failedAttempts` and
`interpretedCount` counters accordingly. If an exception is caught
while operating in SpelCompilerMode.IMMEDIATE mode, the exception will
be propagated via a SpelEvaluationException with a new
SpelMessage.EXCEPTION_COMPILING_EXPRESSION error category.

Closes spring-projectsgh-28043
The TYPE_HIERARCHY_AND_ENCLOSING_CLASSES search strategy for
MergedAnnotations was originally introduced to support @nested test
classes in JUnit Jupiter (see spring-projects#23378).

However, while implementing spring-projects#19930, we determined that the
TYPE_HIERARCHY_AND_ENCLOSING_CLASSES search strategy unfortunately
could not be used since it does not allow the user to control when to
recurse up the enclosing class hierarchy. For example, this search
strategy will automatically search on enclosing classes for static
nested classes as well as for inner classes, when the user probably
only wants one such category of "enclosing class" to be searched.
Consequently, TestContextAnnotationUtils was introduced in the Spring
TestContext Framework to address the shortcomings of the
TYPE_HIERARCHY_AND_ENCLOSING_CLASSES search strategy.

Since this search strategy is unlikely to be useful to general users,
the team has decided to deprecate this search strategy in Spring
Framework 5.3.x and remove it in 6.0.

Closes spring-projectsgh-28079
Co-authored-by: Andy Wilkinson <wilkinsona@vmware.com>
This commit also updates Objenesis version in the file to align with the
version that Spring Framework is using.

See spring-projectsgh-28100
* pr/28100:
  Fix library name for JavaPoet in src/docs/dist/license.txt

Closes spring-projectsgh-28100
Before this commit, CronField.Type::rollForward added temporal units
to reach the higher order field. This caused issues with DST, where
the added amount of hours was either too small or too large.

This commit refactors the implementation so that it now adds one to the
higher order field, and reset the current field to the minimum value.

Closes spring-projectsgh-28095
@bclozel
Copy link
Member

bclozel commented Sep 26, 2022

Closing this PR in favor of #26707 - your contribution has been merged in b71e686, but this outdated PR got wrongly updated with lots of duplicate commits (a rebase and a force-push without any merge would have made things better).

Sorry it took us so long to process this PR, this fix is going to be shipped with the next 5.3.x maintenance release.

@bclozel bclozel closed this Sep 26, 2022
@sbrannen sbrannen added status: superseded An issue that has been superseded by another and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Dec 13, 2022
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) status: superseded An issue that has been superseded by another
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet