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
#25263 fiexed in 5.2X #25341
Closed
Closed
#25263 fiexed in 5.2X #25341
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit finishes the first step for migrating our complete build and release pipeline to Concourse CI. We're creating here a new "Release" jobs group in our pipeline. We can now release Milestones from our pipeline with: * the "stage-milestone" job, which creates and tags a new Milestone version on the source repository, builds the artifacts and deploys them in a staging repository and updates the version to the next SNAPSHOT. * the "promote-milestone" fetches the build information from the staging repository and promotes the released milestone in the official milestone repository. Interactions with the Artifactory and Bintray REST APIs are done using the https://github.com/spring-io/concourse-release-scripts project. Closes spring-projectsgh-22490
Prior to this commit, the Spring TestContext Framework (TCF) favored a @primary transaction manger over one configured via the TransactionManagementConfigurer API, and this contradicts the behavior in production Spring applications. This commit aligns the transaction manger lookup within the TCF so that a transaction manger configured via the TransactionManagementConfigurer API is properly favored over a @primary transaction manager. Closes spring-projectsgh-24869
Native server request headers have been wrapped rather than copied since 5.1. This commit applies the same change to the client side where, to make matters worse, headers were copied repeatedly on every access, see also previous commit ca897b95. For Netty and Jetty the wrappers are the same as on the server side but duplicated in order to remain package private. See spring-projectsgh-24680
from() has the flaw of ignoring the body and it can't be fixed because applications are guaranteed to be setting it already and if set twice the builder drains the first body. mutate() is a better fit in any case for what needs to be done in a filter chain. It can be done more efficiently and is consistent with similar options on the server side. See spring-projectsgh-24680
Given that the body is a Flux<DataBuffer> there probably could be a Flux<DataBuffer> body(); At least bodyToFlux(DataBuffer.class) which is used when mutating and is a common case should not incur overhead. See spring-projectsgh-24680
When mutating a ServerHttpRequest or ClientResponse, the respective builders no longer access cookies automatically which causes them to be parsed and does so only if necessary. Likewise re-applying the read-only HttpHeaders wrapper is avoided. See spring-projectsgh-24680
This commit picks up where 613bd3b left off by ensuring that a transaction manager configured via the TransactionManagementConfigurer API takes precedence over any transaction manager configured as a bean in the ApplicationContext unless @transactional is configured with a qualifier for the explicit transaction manager to use in tests. Closes spring-projectsgh-24869
Prior to this commit, patterns like `"/path/**/other"` would be treated as `"/path/*/other"` (single wildcard, i.e. matching zero to many chars within a path segment). This will not match multiple segments, as expected by `AntPathMatcher` users or by `PathPatternParser` users when in patterns like `"/resource/**"`. This commit now rejects patterns like `"/path/**/other"` as invalid. This behavior was previously warned against since spring-projectsgh-24958. Closes spring-projectsgh-24952
Prior to this commit, the `VersionResourceResolver` implementations would write a strong ETag HTTP response header with the resolved version of the resource (the actual value depending on the chosen strategy). This approach doesn't work well when combined with HTTP compression. Web servers disable HTTP response copression in the presence of strong ETags since mutating the response body would break the contract. This commit changes this semantic and ensures that weak ETags are used instead. Closes spring-projectsgh-24898
Partially reverts 1edc08f
This commit fixes a recent regression as a result of 5225a57 with the determination of non-pattern vs pattern URLs. That in turn affects the ability to perform direct matches by URL path. There is also a fix in PathPattern to recognize "catch-all" patterns as pattern syntax. See spring-projectsgh-24945
This commit introduces the DefaultMultipartMessageReader, a fully reactive multipart parser without third party dependencies. An earlier version of this code was introduced in fb642ce, but removed again in 77c24aa because of buffering issues. Closes spring-projectsgh-21659
This commit removes the UndertowDataBuffer, in favor of using regular DataBuffers from the DataBufferFactory. During the development of the DefaultPartHttpMessageReader, it was determined that invoking various slicing and releasing operators on the UndertowDataBuffer resulted in memory leaks. This commit fixes that.
Using @SafeVarargs in Jackson mapper builder and factory bean classes allows the varargs methods to be used without a compiler warning. The implementations of these methods do not perform unsafe operations on their varargs parameter. It is therefore safe to add this annotation. The following two methods are changed: - add @SafeVarargs to Jackson2ObjectMapperBuilder#modulesToInstall and make it final - add @SafeVarargs to Jackson2ObjectMapperFactoryBean#setModulesToInstall and make it final This is a backwards incompatible change as these methods now have to be declared final. Existing subclasses that override one of these methods will break. Closes spring-projectsgh-25311
Prior to this commit, the Gradle build failed due to a varargs warning. See spring-projectsgh-25311
PR spring-projectsgh-358 introduced a "scheme but no host" check in the fromHttpUrl() method in UriComponentsBuilder, but a similar check was not added to fromUriString() at that time. This commit introduces a "scheme but no host" check in fromUriString() to align with the functionality in fromHttpUrl(). Note, however that the regular expressions used to match against the hostname or IP address are inexact and still permit invalid host names or IP addresses. True validation of the host portion of the URI is out of scope for this commit. Closes spring-projectsgh-25334
…er bean not to be created spring-projects#25263
spring-projects-issues
added
the
status: waiting-for-triage
An issue we've not yet triaged or decided on
label
Jun 30, 2020
bclozel
removed
the
status: waiting-for-triage
An issue we've not yet triaged or decided on
label
Feb 18, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,I tried to fiexed #25263,The test case is in ImportedConfigurationClassEnhancementTests#checkOverloadedBean,The test passed,It's in the Spring-Context module,You can verify it.
Regards
lifejwang11