profile
viewpoint

rstoyanchev/demo-reactive-spring 121

Demo code for "Servlet and Reactive Stacks" talk

bclozel/spring-flights 49

Demo application showcasing RSocket support in Spring

rstoyanchev/reactive-for-webmvc 47

Demo from talk on reactive programming for existing applications

joshlong/the-spring-tutorial 8

this repository demonstrates how to build web applications with Spring

rstoyanchev/async-http-client-perftest 8

Test the performance of sending a large number of concurrent requests

rstoyanchev/context-holder 5

Test project for experimenting with request context feature for WebFlux

push eventspring-projects/spring-framework

Rossen Stoyanchev

commit sha b6f502db4e262a42ceb9076e16d455afd3ac3dbf

Polishing

view details

Rossen Stoyanchev

commit sha 2f12351292564fb2090707ee117620e2a51be640

Refine BlockHound support - disable for Java 14/15 for now until BlockHound support - targeted installation of required integrations only

view details

push time in 17 hours

issue commentspring-projects/spring-framework

spring-web custom ”HandlerMethodArgumentResolver“ nonoperative problem

This is indeed expected. Custom resolvers are ordered after built-in ones. Is this on an @RequestBody argument? What are you trying to do?

xudong1113

comment created time in a day

push eventspring-projects/spring-framework

Rossen Stoyanchev

commit sha 7e402ba4fe4dd91eac97786cb2598cd7097f9782

Improve docs on date and time formatting Closes gh-24370

view details

push time in a day

issue closedspring-projects/spring-framework

Improve default experience of data binding from HTML date and time input fields

tl;dr

The default Spring MVC date/time form binding is slightly at odds with the way modern date and time form input fields are submitted by browsers. This results in the need for (quite a bit of) explicit binding configuration to make default form submissions from browsers work.

Details

The current Spring MVC way of binding of date value stems from the time when date and time values were handled through simple <input type="text" … /> elements. When working with those, form values were usually rendered in the format that's matching the user's browser's locale. On form submissions Spring MVC would then consider the Locale provided (usually in an HTTP header sent by the browser or a value otherwise obtained from the request) when parsing the value provided.

The form elements of type date and time have been specified to contain values that roughly match the ISO formats for dates and times. That means that when using those explicit types, the browser now sends an ISO format but still a browser specific locale. Depending on the actual locale, this might cause the binding to fail, depending on whether the format backing the locale is compatible with the ISO format.

Assume a form backing object like this

class Form {
  LocalDate date;
  LocalTime time;
}

E.g. a browser submission with German locale with a date of 2019-01-15 and time of 20:15 would fail for the date binding, as the German flavor is 15.01.2019 but binding the time would succeed as by accident the German format parses ISO times properly.

Solutions / Workarounds

Annotating the form backing object

A very obvious way of fixing this is annotating all relevant form object fields with @DateTimeFormat(iso = …). While this works, it's a bit tedious one you have many of these types. Also, it's a bit surprising that the default configuration is not able to bind the standard values produced by the browser in the first place. On the other hand, Spring MVC cannot actually know whether the value it's supposed to bind is coming from a text field or a date specific one, especially considering the large amounts of existing applications.

Define ISO formats to be used for all date types globally

Using Spring MVC's WebMvcConfigurer one can tweak the form binding to globally use ISO formats like this:

@Bean
WebMvcConfigurer isoDatesByDefault() {
  return new WebMvcConfigurer() {
    public void addFormatters(FormatterRegistry registry) {
      DateTimeFormatterRegistrar registrar = new DateTimeFormatterRegistrar();
      registrar.setUseIsoFormat(true);
      registrar.registerFormatters(registry);
    }
  }
}

This has the advantage of avoiding the need for additional annotations on form backing objects. It of course breaks the date submission in any other formats (e.g. from plain text input fields using a format other than ISO).

Questions / Remarks

The Spring reference documentation seems a bit dated as it discusses the form binding of dates from the legacy Date point of view. Also, declaring a custom FormattingConversionService is not really idiomatic in a Spring Boot context in which you'd rather declare a WebMvcConfigurer to tweak the service.

I was wondering whether it might makes sense to let Boot expose a property to enable the configuration tweaks shown above to simplify switching to the ISO format in general. There's precedence in ISO date specific configuration in the Jackson space.

closed time in a day

odrotbohm

delete branch rstoyanchev/spring-framework

delete branch : blockhound

delete time in a day

push eventspring-projects/spring-framework

Rossen Stoyanchev

commit sha 2ae91404d1424bfc16b2dca62e4c6f8f3e9174f6

BlockHoundIntegration for spring-core

view details

push time in a day

PR merged spring-projects/spring-framework

BlockHoundIntegration for spring-core in: core type: enhancement

This pull request adds a BlockHoundIntegration for spring-core that whitelists locking in ConcurrentReferenceHashMap for #24241, and LocalVariableTableParameterNameDiscoverer for #24247.

+162 -1

0 comment

5 changed files

rstoyanchev

pr closed time in a day

push eventrstoyanchev/spring-framework

Rossen Stoyanchev

commit sha 96de4b3cee37615849e1ff2584ca7a08945f7ee6

Upgrade to Reactor Dysprosium-SR5 Closes gh-24355

view details

Rossen Stoyanchev

commit sha d1e24191f716e39fe164170d9c7788c6fdb44a5c

BlockHoundIntegration for spring-core

view details

push time in a day

push eventspring-projects/spring-framework

Rossen Stoyanchev

commit sha 96de4b3cee37615849e1ff2584ca7a08945f7ee6

Upgrade to Reactor Dysprosium-SR5 Closes gh-24355

view details

push time in a day

issue closedspring-projects/spring-framework

Upgrade to Reactor Dysprosium SR5

As part of upgrade arounds for:

  • https://github.com/reactor/reactor-netty/issues/948 in ErrorHandlerIntegrationTests
  • https://github.com/reactor/reactor-core/issues/1925 (if available) in StringDecoder

closed time in a day

rstoyanchev

push eventrstoyanchev/spring-framework

Hyunjin Choi

commit sha ede2a1d4b26ada78250389c0dda908212713dbad

Remove unnecessary semicolon in some enum classes

view details

Qimiao Chen

commit sha 1de2e0a4a7fe8c306d9cc8d4bdac8c18ba27d4e3

Fix formatting in webflux-webclient.adoc Closes gh-24578

view details

Sam Brannen

commit sha 7778508e69f5bb09e58779fd4cdb347bdebe13bb

Fix typos in ResolvableTypeTests See gh-24529 Co-authored-by: Qimiao Chen <chenqimiao1994@126.com>

view details

Rossen Stoyanchev

commit sha e387629e4888d039f5cdf251718f8de954ada797

BlockHoundIntegration for spring-core

view details

push time in a day

push eventspring-projects/spring-framework

Rossen Stoyanchev

commit sha 10c9d2fcecb1e4d18586eb1592dee59da13751b5

Upgrade to Reactor Calfiornium-SR16 Closes gh-24527

view details

push time in 2 days

issue closedspring-projects/spring-framework

LocalValidatorFactoryBean makes blocking call (detected by blockhound)

<!-- !!! For Security Vulnerabilities, please go to https://pivotal.io/security !!! --> Affects: 5.1.12.RELEASE


<!-- Thanks for taking the time to create an issue. Please read the following:

  • Questions should be asked on Stack Overflow.
  • For bugs, specify affected versions and explain what you are trying to do.
  • For enhancements, provide context and describe the problem.

Issue or Pull Request? Create only one, not both. GitHub treats them as the same. If unsure, start with an issue, and if you submit a pull request later, the issue will be closed as superseded. --> Blockhound detects a blocking call when LocalValidatorFactoryBean performs validation

Stack trace below: <details>

reactor.core.Exceptions$ReactiveException: java.lang.Error: Blocking call! java.io.FileInputStream#readBytes

	at reactor.core.Exceptions.propagate(Exceptions.java:356)
	at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:91)
	at reactor.core.publisher.Mono.block(Mono.java:1495)
	at com.mycompany.myapp.FailValidationIT.test(FailValidationIT.java:19)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:532)
	at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:171)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:72)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:167)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:114)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:59)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$4(NodeTestTask.java:108)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:72)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:98)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:74)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
	at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$4(NodeTestTask.java:112)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:72)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:98)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:74)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
	at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$4(NodeTestTask.java:112)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:72)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:98)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:74)
	at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:32)
	at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)
	at org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:51)
	at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:220)
	at org.junit.platform.launcher.core.DefaultLauncher.lambda$execute$6(DefaultLauncher.java:188)
	at org.junit.platform.launcher.core.DefaultLauncher.withInterceptedStreams(DefaultLauncher.java:202)
	at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:181)
	at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:128)
	at com.intellij.junit5.JUnit5IdeaTestRunner.startRunnerWithArgs(JUnit5IdeaTestRunner.java:69)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
	at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
	at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
	Suppressed: java.lang.Exception: #block terminated with an error
		at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:93)
		... 41 more
Caused by: java.lang.Error: Blocking call! java.io.FileInputStream#readBytes
	at reactor.blockhound.BlockHound$Builder.lambda$new$0(BlockHound.java:196)
	at reactor.blockhound.BlockHound$Builder.lambda$install$6(BlockHound.java:318)
	at reactor.blockhound.BlockHoundRuntime.checkBlocking(BlockHoundRuntime.java:46)
	at java.base/java.io.FileInputStream.readBytes(FileInputStream.java)
	at java.base/java.io.FileInputStream.read(FileInputStream.java:279)
	at java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:252)
	at java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:292)
	at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:351)
	at org.springframework.asm.ClassReader.readStream(ClassReader.java:306)
	at org.springframework.asm.ClassReader.<init>(ClassReader.java:273)
	at org.springframework.core.LocalVariableTableParameterNameDiscoverer.inspectClass(LocalVariableTableParameterNameDiscoverer.java:114)
	at org.springframework.core.LocalVariableTableParameterNameDiscoverer.getParameterNames(LocalVariableTableParameterNameDiscoverer.java:74)
	at org.springframework.core.PrioritizedParameterNameDiscoverer.getParameterNames(PrioritizedParameterNameDiscoverer.java:55)
	at org.springframework.validation.beanvalidation.LocalValidatorFactoryBean$1.getParameterNames(LocalValidatorFactoryBean.java:325)
	at org.hibernate.validator.internal.util.ExecutableParameterNameProvider.getParameterNames(ExecutableParameterNameProvider.java:37)
	at org.hibernate.validator.internal.metadata.aggregated.ParameterMetaData$Builder.build(ParameterMetaData.java:169)
	at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.findParameterMetaData(ExecutableMetaData.java:435)
	at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:388)
	at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
	at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
	at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:204)
	at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:166)
	at org.hibernate.validator.internal.engine.ValidatorImpl.validate(ValidatorImpl.java:157)
	at org.springframework.validation.beanvalidation.SpringValidatorAdapter.validate(SpringValidatorAdapter.java:358)
	at org.springframework.data.mongodb.core.mapping.event.ValidatingMongoEventListener.onBeforeSave(ValidatingMongoEventListener.java:61)
	at org.springframework.data.mongodb.core.mapping.event.AbstractMongoEventListener.onApplicationEvent(AbstractMongoEventListener.java:89)
	at org.springframework.data.mongodb.core.mapping.event.AbstractMongoEventListener.onApplicationEvent(AbstractMongoEventListener.java:31)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139)
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:402)
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:359)
	at org.springframework.data.mongodb.core.ReactiveMongoTemplate.maybeEmitEvent(ReactiveMongoTemplate.java:2432)
	at org.springframework.data.mongodb.core.ReactiveMongoTemplate.lambda$doInsert$24(ReactiveMongoTemplate.java:1252)
	at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:44)
	at reactor.core.publisher.MonoOnAssembly.subscribe(MonoOnAssembly.java:61)
	at reactor.core.publisher.MonoLiftFuseable.subscribe(MonoLiftFuseable.java:55)
	at reactor.core.publisher.Mono.subscribe(Mono.java:3877)
	at reactor.core.publisher.MonoSubscribeOn$SubscribeOnSubscriber.run(MonoSubscribeOn.java:123)
	at reactor.core.scheduler.WorkerTask.call(WorkerTask.java:84)
	at reactor.core.scheduler.WorkerTask.call(WorkerTask.java:37)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
	Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException: 
Assembly trace from producer [reactor.core.publisher.MonoDefer] :
	reactor.core.publisher.Mono.defer(Mono.java:199)
	org.springframework.data.mongodb.core.ReactiveMongoTemplate.doInsert(ReactiveMongoTemplate.java:1241)
Error has been observed by the following operator(s):
	|_	Mono.defer ⇢ org.springframework.data.mongodb.core.ReactiveMongoTemplate.doInsert(ReactiveMongoTemplate.java:1241)
	|_	Mono.subscribeOn ⇢ com.mycompany.myapp.FailValidationIT.test(FailValidationIT.java:19)

</details>

To reproduce, clone this example project and run test FailValidationIT

This issue has similarities with #24240 (also going through PrioritizedParameterNameDiscoverer::getParameterNames)

closed time in 2 days

cbornet

issue commentspring-projects/spring-framework

LocalValidatorFactoryBean makes blocking call (detected by blockhound)

This is now superseded by #24581.

Also I confirmed that using reflection with Java 8+ (via --parameters) does not have the same issue.

cbornet

comment created time in 2 days

issue closedspring-projects/spring-framework

Blocking call in ConcurrentReferenceHashMap on event loop

I encountered the following blocking call within ConcurrentReferenceHashMap on the event loop.

I'd like any of the following solutions:

  1. Fix ConcurrentReferenceHashMap so that it does not block, OR
  2. Move the blocking call to another thread pool (perhaps via BodyExtractors.toMono), OR
  3. Create a BlockHoundIntegration within spring that will whitelist this blocking call
java.lang.Error: Blocking call! jdk.internal.misc.Unsafe#park
	at reactor.blockhound.BlockHound$Builder.lambda$new$0(BlockHound.java:196)
	at reactor.blockhound.BlockHound$Builder.lambda$install$6(BlockHound.java:318)
	at reactor.blockhound.BlockHoundRuntime.checkBlocking(BlockHoundRuntime.java:46)
	at java.base/jdk.internal.misc.Unsafe.park(Unsafe.java)
	at java.base/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
	at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
	at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:917)
	at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1240)
	at java.base/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:267)
	at org.springframework.util.ConcurrentReferenceHashMap$Segment.doTask(ConcurrentReferenceHashMap.java:524)
	at org.springframework.util.ConcurrentReferenceHashMap.doTask(ConcurrentReferenceHashMap.java:419)
	at org.springframework.util.ConcurrentReferenceHashMap.put(ConcurrentReferenceHashMap.java:282)
	at org.springframework.util.ConcurrentReferenceHashMap.put(ConcurrentReferenceHashMap.java:271)
	at org.springframework.core.ResolvableType.forType(ResolvableType.java:1420)
	at org.springframework.core.ResolvableType.forType(ResolvableType.java:1344)
	at org.springframework.web.reactive.function.BodyExtractors.toMono(BodyExtractors.java:80)
	at org.springframework.security.oauth2.core.web.reactive.function.OAuth2AccessTokenResponseBodyExtractor.extract(OAuth2AccessTokenResponseBodyExtractor.java:59)
	at org.springframework.security.oauth2.core.web.reactive.function.OAuth2AccessTokenResponseBodyExtractor.extract(OAuth2AccessTokenResponseBodyExtractor.java:48)
	at org.springframework.web.reactive.function.client.DefaultClientResponse.body(DefaultClientResponse.java:110)
	at org.springframework.security.oauth2.client.endpoint.WebClientReactiveClientCredentialsTokenResponseClient.lambda$null$0(WebClientReactiveClientCredentialsTokenResponseClient.java:85)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:118)
	at reactor.core.publisher.FluxSwitchIfEmpty$SwitchIfEmptySubscriber.onNext(FluxSwitchIfEmpty.java:67)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:121)
	at reactor.core.publisher.FluxPeekFuseable$PeekFuseableSubscriber.onNext(FluxPeekFuseable.java:203)
	at reactor.core.publisher.FluxPeekFuseable$PeekFuseableSubscriber.onNext(FluxPeekFuseable.java:203)
	at reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:76)
	at reactor.core.publisher.MonoFlatMapMany$FlatMapManyInner.onNext(MonoFlatMapMany.java:242)
	at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2186)
	at reactor.core.publisher.MonoFlatMapMany$FlatMapManyMain.onSubscribeInner(MonoFlatMapMany.java:143)
	at reactor.core.publisher.MonoFlatMapMany$FlatMapManyInner.onSubscribe(MonoFlatMapMany.java:237)
	at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:54)
	at reactor.core.publisher.Flux.subscribe(Flux.java:8143)
	at reactor.core.publisher.MonoFlatMapMany$FlatMapManyMain.onNext(MonoFlatMapMany.java:188)
	at reactor.core.publisher.FluxRetryPredicate$RetryPredicateSubscriber.onNext(FluxRetryPredicate.java:82)
	at reactor.core.publisher.MonoCreate$DefaultMonoSink.success(MonoCreate.java:156)
	at reactor.netty.http.client.HttpClientConnect$HttpObserver.onStateChange(HttpClientConnect.java:397)
	at reactor.netty.ReactorNetty$CompositeConnectionObserver.onStateChange(ReactorNetty.java:494)
	at reactor.netty.resources.PooledConnectionProvider$DisposableAcquire.onStateChange(PooledConnectionProvider.java:526)
	at reactor.netty.resources.PooledConnectionProvider$PooledConnection.onStateChange(PooledConnectionProvider.java:435)
	at reactor.netty.http.client.HttpClientOperations.onInboundNext(HttpClientOperations.java:521)
	at reactor.netty.channel.ChannelOperationsHandler.channelRead(ChannelOperationsHandler.java:89)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
	at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
	at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:438)
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:326)
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:313)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:427)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:281)
	at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:253)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1422)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:931)
	at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:792)
	at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:502)
	at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:407)
	at io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1050)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:834)

spring-boot 2.2.2.RELEASE spring-core 5.2.2.RELEASE spring-security-oauth2-client 5.2.1.RELEASE

closed time in 2 days

philsttr

issue commentspring-projects/spring-framework

Blocking call in ConcurrentReferenceHashMap on event loop

This is now superseded by #24581.

philsttr

comment created time in 2 days

PR opened spring-projects/spring-framework

BlockHoundIntegration for spring-core

This pull request adds a BlockHoundIntegration for spring-core that whitelists locking in ConcurrentReferenceHashMap for #24241, and LocalVariableTableParameterNameDiscoverer for #24247.

+181 -0

0 comment

5 changed files

pr created time in 2 days

create barnchrstoyanchev/spring-framework

branch : blockhound

created branch time in 2 days

issue openedspring-projects/spring-framework

Backport of ContentDisposition fixes to HttpHeaders

ContentDisposition was created in 5.0, supporting all Content-Disposition types including "form-data", "inline" and "attachment" for use in client and server scenarios. Prior to that, HttpHeaders did have support for Content-Disposition of type "form-data", for use in client scenarios with the RestTemplate. This ticket is to review fixes in ContentDisposition that may be worth backporting to HttpHeaders in the 4.3.x branch for consistency.

created time in 2 days

fork rstoyanchev/BlockHound

Java agent to detect blocking calls from non-blocking threads.

fork in 2 days

issue commentspring-projects/spring-framework

Blocking call under LocalVariableTableParameterNameDiscoverer with Boot JAR loader

This is essentially the same issue as #24247.

IrishkA13

comment created time in 4 days

issue commentspring-projects/spring-framework

Unable to handle malformed Accept header

But, it's not acceptable to throw a HTTP-500 in the middle

I can't reproduce that 500 error.

@GetMapping(path = "/24539")
public ResponseEntity<Map<String, String>> handle() {
	return ResponseEntity.ok()
			.body(Collections.singletonMap("issue", "24539"));
}

@ExceptionHandler
public ResponseEntity<Map<String, String>> handleEx(HttpMediaTypeNotAcceptableException ex) {
	return ResponseEntity.status(HttpStatus.NOT_ACCEPTABLE)
			.body(Collections.singletonMap("reason", ex.getMessage()));
}

Gives me the following log output. <details><summary>Click for log output</summary>

[http-nio-8080-exec-2] 21:05 [] [/]: Initializing Spring DispatcherServlet 'dispatcherServlet'
[http-nio-8080-exec-2] 21:05 [] DispatcherServlet: Initializing Servlet 'dispatcherServlet'
[http-nio-8080-exec-2] 21:05 [] DispatcherServlet: Detected StandardServletMultipartResolver
[http-nio-8080-exec-2] 21:05 [] DispatcherServlet: enableLoggingRequestDetails='false': request parameters and headers will be masked to prevent unsafe logging of potentially sensitive data
[http-nio-8080-exec-2] 21:05 [] DispatcherServlet: Completed initialization in 14 ms
[http-nio-8080-exec-2] 21:05 [] DispatcherServlet: GET "/24539", parameters={}
[http-nio-8080-exec-2] 21:05 [] RequestMappingHandlerMapping: Mapped to car.app.CarController#handle()
[http-nio-8080-exec-2] 21:05 [] ExceptionHandlerExceptionResolver: Using @ExceptionHandler car.app.CarController#handleEx(HttpMediaTypeNotAcceptableException)
[http-nio-8080-exec-2] 21:05 [] ExceptionHandlerExceptionResolver: Failure in @ExceptionHandler car.app.CarController#handleEx(HttpMediaTypeNotAcceptableException)
org.springframework.web.HttpMediaTypeNotAcceptableException: Could not parse 'Accept' header [null]: Invalid mime type "null": does not contain '/'
	at org.springframework.web.accept.HeaderContentNegotiationStrategy.resolveMediaTypes(HeaderContentNegotiationStrategy.java:59)
	at org.springframework.web.accept.ContentNegotiationManager.resolveMediaTypes(ContentNegotiationManager.java:128)
	at org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodProcessor.getAcceptableMediaTypes(AbstractMessageConverterMethodProcessor.java:396)
	at org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodProcessor.writeWithMessageConverters(AbstractMessageConverterMethodProcessor.java:226)
	at org.springframework.web.servlet.mvc.method.annotation.HttpEntityMethodProcessor.handleReturnValue(HttpEntityMethodProcessor.java:226)
	at org.springframework.web.method.support.HandlerMethodReturnValueHandlerComposite.handleReturnValue(HandlerMethodReturnValueHandlerComposite.java:82)
	at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:124)
	at org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver.doResolveHandlerMethodException(ExceptionHandlerExceptionResolver.java:407)
	at org.springframework.web.servlet.handler.AbstractHandlerMethodExceptionResolver.doResolveException(AbstractHandlerMethodExceptionResolver.java:61)
	at org.springframework.web.servlet.handler.AbstractHandlerExceptionResolver.resolveException(AbstractHandlerExceptionResolver.java:141)
	at org.springframework.web.servlet.handler.HandlerExceptionResolverComposite.resolveException(HandlerExceptionResolverComposite.java:80)
	at org.springframework.web.servlet.DispatcherServlet.processHandlerException(DispatcherServlet.java:1300)
	at org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1111)
	at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1057)
	at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:943)
	at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
	at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:634)
	at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:93)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:367)
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:860)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1598)
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:748)
[http-nio-8080-exec-2] 21:05 [] DefaultHandlerExceptionResolver: Resolved [org.springframework.web.HttpMediaTypeNotAcceptableException: Could not parse 'Accept' header [null]: Invalid mime type "null": does not contain '/']
[http-nio-8080-exec-2] 21:05 [] DispatcherServlet: Completed 406 NOT_ACCEPTABLE
[http-nio-8080-exec-2] 21:05 [] DispatcherServlet: "ERROR" dispatch for GET "/error", parameters={}
[http-nio-8080-exec-2] 21:05 [] RequestMappingHandlerMapping: Mapped to org.springframework.boot.autoconfigure.web.servlet.error.BasicErrorController#error(HttpServletRequest)
[http-nio-8080-exec-2] 21:05 [] ExceptionHandlerExceptionResolver: Using @ExceptionHandler org.springframework.boot.autoconfigure.web.servlet.error.BasicErrorController#mediaTypeNotAcceptable(HttpServletRequest)
[http-nio-8080-exec-2] 21:05 [] ExceptionHandlerExceptionResolver: Failure in @ExceptionHandler org.springframework.boot.autoconfigure.web.servlet.error.BasicErrorController#mediaTypeNotAcceptable(HttpServletRequest)
org.springframework.web.HttpMediaTypeNotAcceptableException: Could not parse 'Accept' header [null]: Invalid mime type "null": does not contain '/'
	at org.springframework.web.accept.HeaderContentNegotiationStrategy.resolveMediaTypes(HeaderContentNegotiationStrategy.java:59)
	at org.springframework.web.accept.ContentNegotiationManager.resolveMediaTypes(ContentNegotiationManager.java:128)
	at org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodProcessor.getAcceptableMediaTypes(AbstractMessageConverterMethodProcessor.java:396)
	at org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodProcessor.writeWithMessageConverters(AbstractMessageConverterMethodProcessor.java:226)
	at org.springframework.web.servlet.mvc.method.annotation.HttpEntityMethodProcessor.handleReturnValue(HttpEntityMethodProcessor.java:226)
	at org.springframework.web.method.support.HandlerMethodReturnValueHandlerComposite.handleReturnValue(HandlerMethodReturnValueHandlerComposite.java:82)
	at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:124)
	at org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver.doResolveHandlerMethodException(ExceptionHandlerExceptionResolver.java:407)
	at org.springframework.web.servlet.handler.AbstractHandlerMethodExceptionResolver.doResolveException(AbstractHandlerMethodExceptionResolver.java:61)
	at org.springframework.web.servlet.handler.AbstractHandlerExceptionResolver.resolveException(AbstractHandlerExceptionResolver.java:141)
	at org.springframework.web.servlet.handler.HandlerExceptionResolverComposite.resolveException(HandlerExceptionResolverComposite.java:80)
	at org.springframework.web.servlet.DispatcherServlet.processHandlerException(DispatcherServlet.java:1300)
	at org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1111)
	at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1057)
	at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:943)
	at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
	at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:634)
	at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:712)
	at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:461)
	at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:384)
	at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:312)
	at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:394)
	at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:253)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:175)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:367)
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:860)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1598)
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:748)
[http-nio-8080-exec-2] 21:05 [] DefaultHandlerExceptionResolver: Resolved [org.springframework.web.HttpMediaTypeNotAcceptableException: Could not parse 'Accept' header [null]: Invalid mime type "null": does not contain '/']
[http-nio-8080-exec-2] 21:05 [] DispatcherServlet: Exiting from "ERROR" dispatch, status 406

</details>

Note how ExceptionHandlerExceptionResolver returns null if exception handling itself failed in order to allow other resolvers work. Then you'll see the DefaultHandlerExceptionResolver turning that into a 406 response. Then comes the Boot ERROR dispatch which also fails to render but there is no 500 in this sequence.

I would still like to answer in a self/well-defined error format (instead of the empty 406), even if the request was not valid

It just occurred to me that you can present the content-type of the response, and avoid content negotiation. The following does work:

@ExceptionHandler
public ResponseEntity<Map<String, String>> handleEx(HttpMediaTypeNotAcceptableException ex) {
	return ResponseEntity.status(HttpStatus.NOT_ACCEPTABLE)
			.contentType(MediaType.APPLICATION_JSON)    // <-- this here
			.body(Collections.singletonMap("reason", ex.getMessage()));
}

I'm afraid we as a framework can't ignore a failure to parse the Accept header and go ahead and render anyway. You might be able to do that based in your case(s) and the above shows how you can do that.

ST-DDT

comment created time in 5 days

issue commentspring-projects/spring-framework

Support for byte-range requests in Servlet Functional endpoints

It's another case where access to both request and response is useful for writing to a server response. Perhaps a static, @Nullable method in ResourceRegionHttpMessageConverter that takes the input and output message and returns List<ResourceRegion> could help encapsulate at least the logic at least?

bclozel

comment created time in 5 days

push eventspring-projects/spring-framework

Rossen Stoyanchev

commit sha 96e77d417bb7311e860a5c2cd9cb1e55506c6d06

Update WebFlux section on HTTP/2 Closes gh-24558

view details

Rossen Stoyanchev

commit sha 97ba00eff263a63d302bb72b83f444275ddc4e9c

Use try-with-resource in XmlBeanDefinitionReader Closes gh-24492

view details

陈其苗

commit sha a09f02f64e89edd88d5c6a6e0e23f290d0461efb

Minor refactoring in AbstractPlatformTransactionManager See gh-24493

view details

Rossen Stoyanchev

commit sha adc13f203030d56dc5e0ed870879f0814cd68a53

Polishing contribution See gh-24493

view details

Rossen Stoyanchev

commit sha 8219d06ae12ad4b0ffd6648b81220dfc36a3c9b3

Merge pull request #24493 from chenqimiao-pr/AbstractPlatformTransactionManager Closes gh-24493

view details

push time in 5 days

PR closed spring-projects/spring-framework

Extract a method named openNewTransaction to reuse some code in: data type: task

Extract a method named openNewTransaction to reuse some code

+19 -19

0 comment

1 changed file

chenqimiao

pr closed time in 5 days

PR closed spring-projects/spring-framework

Reviewers
Use try-with-resource instead of try-finally to close stream in: core type: task

Use try-with-resource instead of try-finally to close stream, and merge two try blocks into one. This looks more concise.

+7 -12

0 comment

1 changed file

chenqimiao

pr closed time in 5 days

PR closed spring-projects/spring-framework

Update section on HTTP/2 in WebFlux documentation in: web type: task

I check the http/2 Wiki. I think it is a confusing phrase.

+0 -3

0 comment

1 changed file

moonchanyong

pr closed time in 5 days

pull request commentspring-projects/spring-framework

Repeatable Read HttpServletRequest InputStream

ContentCachingRequestWrapper does cache the content and makes it available for repeated use via getContentAsByteArray(). If you want getInputStream() to also be used multiple times, you could extend ContentCachingRequestWrapper. Something like:

public class RepeatableContentCachingRequestWrapper extends ContentCachingRequestWrapper {


    public RepeatableContentCachingRequestWrapper(HttpServletRequest request) {
        super(request);
        StreamUtils.drain(super.getInputStream());
    }


    @Override
    public ServletInputStream getInputStream() throws IOException {
        return new ByteServletInputStream(getContentAsByteArray());
    }


    private static class ByteServletInputStream extends ServletInputStream {

        private final InputStream is;

        private ByteServletInputStream(byte[] content) {
            this.is = new ByteArrayInputStream(content);
        }

        @Override
        public boolean isFinished() {
            return true;
        }

        @Override
        public boolean isReady() {
            return true;
        }

        @Override
        public void setReadListener(ReadListener readListener) {

        }

        @Override
        public int read() throws IOException {
            return this.is.read();
        }

        @Override
        public void close() throws IOException {
            this.is.close();
        }
    }
}
lixiaolong11000

comment created time in 5 days

pull request commentspring-projects/spring-framework

Repeatable Read HttpServletRequest InputStream

I've edited your comment to improve the formatting. You might want to check out this Mastering Markdown guide for future reference. Keep in mind that @ is a mention and needs to be escaped to avoid notifications.

lixiaolong11000

comment created time in 5 days

issue closedspring-projects/spring-framework

WebFluxTest cannot read URL with matrix variable

Hi, I notice WebFluxTest cannot test with a URL with matrix variable. For example I have a test:

    @Autowired
    WebTestClient webTestClient;
    @Test
    public void exampleTest(){
        
        webTestClient.get().uri("http://localhost:8080/example/employees/id=1")
                     .exchange()
                     .expectBody().consumeWith(response -> assertTrue(new String(response.getResponseBody(),
                                               StandardCharsets.UTF_8).contains(expected)));
  }

The code to test is:

@Controller
public class Example {
    
    @GetMapping("/example/employees/{id}")
    @ResponseBody
    public String example(@MatrixVariable("id") int id) {
         ....
    }

And there is a config here:

@Configuration
public class MyConfig implements WebMvcConfigurer {
  @Override
    public void configurePathMatch(PathMatchConfigurer configurer) {
        UrlPathHelper urlPathHelper = new UrlPathHelper();
        urlPathHelper.setRemoveSemicolonContent(false); // <---
        configurer.setUrlPathHelper(urlPathHelper);
    } ...
}

Output:

"status":400,"error":"Bad Request","message":"Missing matrix variable 'id' for method parameter of type int"}

closed time in 5 days

aCodeRancher

issue commentspring-projects/spring-framework

WebFluxTest cannot read URL with matrix variable

@WebFluxTest is for testing WebFlux controllers. So given the above, you are testing the controller with WebFlux infrastructure, so the given Spring MVC config is probably ignored.

This is the part in the Javadoc for testing with a live server:

If you are looking to load your full application configuration and use WebTestClient,
you should consider @SpringBootTest combined with @AutoConfigureWebTestClient
rather than this annotation.

Also this in the reference docs.

aCodeRancher

comment created time in 5 days

pull request commentspring-projects/spring-framework

Added debug logging to DefaultWebSessionManager

Thanks for the changes, I've made small adjustments.

pulse00

comment created time in 5 days

push eventspring-projects/spring-framework

Rossen Stoyanchev

commit sha a134e92e7f382dd78b0542aec07aa66519222c4f

Improve checks on URI string in MockMvc request builder Closes gh-24556

view details

Robert Gründler

commit sha ae9268004ddbf462fd16db6aa9f06065ed4de1cb

Added debug logging to DefaultWebSessionManager See gh-24518

view details

Rossen Stoyanchev

commit sha de608a08ed9517a64cfc279810cbb55071017490

Polishing contribution See gh-24518

view details

Rossen Stoyanchev

commit sha ca6241a09312327863a3ee6e254a2627419bcbd7

Merge pull request #24518 from pulse00-patch/web-session-debug-logs Closes gh-24518

view details

push time in 5 days

PR closed spring-projects/spring-framework

Added debug logging to DefaultWebSessionManager in: web type: task

Added some debug logs regarding session expiration to the DefaultWebSessionManager.

+14 -1

0 comment

1 changed file

pulse00

pr closed time in 5 days

issue closedspring-projects/spring-framework

NullPointerException when no protocol is explicited on MockHttpServletRequestBuilder class

Affects: spring-boot-starter-test 2.1.6.RELEASE

Use Case: When performing an spring integration test over a get controller we add an url as a String to MockHttpServletRequestBuilder to perform such action.

Issue: When we add that url String without the protocol (for instance: "localhost:port...") the request returns a NullPointerException.

Code failing:

MockHttpServletResponse response = 
    mockMvc.perform(MockMvcRequestBuilders.get("localhost:port/some domain/etc...")).andReturn().getResponse();

Code working:

MockHttpServletResponse response = 
    mockMvc.perform(MockMvcRequestBuilders.get("http://localhost:port/some domain/etc...")).andReturn().getResponse();

Just to clarify the only difference is that the second url contains the http protcol explicitly declared

Expectation: Since http is the default protocol in many other frameworks I expect it to be inferred as url protocl if no other is defined explicitly.

Cause: Inside that MockMvcRequestBuilders.get("uri") method there is a call to a private constructor who converts that String into an actual URI

MockHttpServletRequestBuilder(HttpMethod httpMethod, String url, Object... vars) {
	this(httpMethod.name(), UriComponentsBuilder.fromUriString(url).buildAndExpand(vars).encode().toUri());
}

But it does not work properly since this.utl.getRawPath() returns null which later causes updatePathRequestProperties to throw mentioned NullPointerException image

Thanks in advance!

closed time in 5 days

dFarras

PR closed spring-projects/spring-framework

Reviewers
Fix typo and polish if block in: core type: task

This pr is to polishing some if blocks in ResolvableType and fixing some typos in ResolvableTypeTests. Looking forward to your reply.

+7 -10

1 comment

2 changed files

chenqimiao

pr closed time in 5 days

pull request commentspring-projects/spring-framework

Fix typo and polish if block

I think the code should remain as is returning at that point only if the condition evaluates to true, but otherwise continuing and eventually exiting through the false return at the end.

chenqimiao

comment created time in 5 days

issue commentspring-projects/spring-framework

Unable to handle malformed 'Accept' header

Small correction. It's not a message converter where the failure occurs. It's the AbstractMessageConverterMethodProcessor which is trying to perform content negotiation in order to find a compatible message converter.

Suppose we did ignore the HttpMediaTypeNotAcceptableException, we wouldn't know then what media type to render the response with. A 406 error seems an acceptable outcome for what is essentially a bad request.

If you want more control over the parsing of the Accept header you can use the WebMVcConfigurer#configureContentNegotiation, possibly replacing the HeaderContentNegotiationStrategy with an extension that suppresses parsing errors, if it there is something you can rely to fall back on. Or perhaps using */* in you case too.

ST-DDT

comment created time in 6 days

issue commentspring-projects/spring-framework

Extend WebClient with createException(HttpStatus code)

As an API I'm not keen on exposing such a method at this level. It is an exceptional situation, not something that should be a common case. Furthermore it leads down a path of having more more overloaded methods. Even here you've already mentioned custom error text. For the status, it could be HttpStatus or also raw status value.

ClientResponse provides a method to create an exception from its internal state. If necessary you can then map it to a different exception and change any of the bits:

response.createException().map(ex -> 
        new WebClientResponseException(
                502, "custom status", ex.getHeaders(), ex.getResponseBodyAsByteArray(), UTF_8))

This gives you full control over all the fields and IMO is more readable in the sense that it's clear what's being done vs a createException(HttpStatus) which raises questions.

The only small thing here is that WebClientResponseException doesn't expose its responseCharset field. This is something we can correct.

membersound

comment created time in 6 days

issue closedspring-projects/spring-framework

WebClient builder call from one microservice to another microservice giving bad request error for first time in Webflux

We are making use of WebClient Builder call for communication among micro services in our project.It's springboot-thymleaf-webflux based application.Everything is running fine till now but we got a requirement from Client to change GET call to POST call in thymleaf controller.After making these changes at UI and Backend,Thymleaf calls are working fine but one of the XHR i.e post call from UI-- is giving bad request error for WebClient call to second microservice for first click and working for second click.I compared header and request for both click did not find any difference.I am not able to understand why WebClient behaving abnoramlly first time and working fine second time.

Below is code snippet for WebClient call and it is routing to WebClientResponseException without hitting to second microservice by saying BAD Request for http://second-microservice -eureka-address/endpoint-url

     * Submitting xyz 
     * @param submitFlowRequest
     */
@Override
public Mono<ApiResponse<SubmitResponse>> submitFlow(SubmitFlowRequest submitFlowRequest,
        Map<String, String> headers) {

    long startTime = System.currentTimeMillis();
    String uri = propertyConfig.getAggregationService()
            + propertyConfig.getAggregationSubmitCCInfoURL();
    DefaultUriBuilderFactory factory = new DefaultUriBuilderFactory(uri);
    factory.setEncodingMode(DefaultUriBuilderFactory.EncodingMode.URI_COMPONENT);
    MultiValueMap<String, String> clientHeaders = buildHeaders(headers);
    return webClientBuilder.uriBuilderFactory(factory).build().post()
            .headers(httpHeaders -> httpHeaders.addAll(clientHeaders)).accept(MediaType.APPLICATION_JSON)
            .syncBody(submitFlowRequest).retrieve().bodyToMono(ApiResponse.class)
            .onErrorMap(ConnectException.class,
                    error -> new VzwRuntimeException(ErrorCodeEnum.V404.toString(), Constants.OPP_TC_SYSTEM_ERROR,
                            (Constants.CONNECTION_FAILURE_TEXT + Constants.AGGREGATION)))
            .onErrorMap(WebClientResponseException.class,
                    error -> new VzwRuntimeException(ErrorCodeEnum.V404.toString(), Constants.OPP_TC_SYSTEM_ERROR,
                            (Constants.CONNECTION_FAILURE_TEXT + Constants.AGGREGATION)))
            .flatMap(res -> {
                Audit apiAudit = Audit.builder().apiUrl(uri).request(LoggerUtil.asJson(submitFlowRequest))
                        .response(LoggerUtil.asJson(res))
                        .executionTime(String.valueOf(System.currentTimeMillis() - startTime))
                        .headers(LoggerUtil.asJson(clientHeaders)).transactionType(res.getData()!=null?mapper.map(res.getData(), SubmitResponse.class).getTransactionType():"").build();
                LoggerUtil.logExternalApiCalls(apiAudit);
                return Mono.just((ApiResponse<SubmitResponse>) res);
            });
}

Please provide me some lead.I am tired of finding solution for this.

closed time in 6 days

manuj20

issue commentspring-projects/spring-framework

WebClient builder call from one microservice to another microservice giving bad request error for first time in Webflux

It sounds like you're getting a 400 error from the second microservice. You'll need to find out what is the reason for that. You should examine check the exact request and response on the wire between microservice 1 and 2. You can do that with wire logging on Reactor Netty. If that doesn't reveal the problem you can also debug or check logging from the microservice 2 in order to find why it returns 400.

Only when you know what the reason for the 400 is, you can begin to think about the root cause. At this stage there is not enough information to say that the WebClient is behaving abnormally.

There is very little I can do with the given information, and there isn't enough evidence of an issue in the framework, so I'm going to close this for now. If you find out more and you do suspect an issue in the framework feel free to comment further. However keep in mind that either the problem needs to be clear or I'll need instructions or a sample for how to reproduce it.

Two small notes:

The WebClient.Builder is used to create a WebClient instance which can then be used for many calls. The builder should not be used for every request.

The flatMap at the end could be just map and instead of wrapping the response with Mono.just, simply return the response.

manuj20

comment created time in 6 days

issue commentspring-projects/spring-framework

Documentation - add link to latest current version in the reference

If you're looking at some 4.3.x version, or even older, would you consider current to be 4.3.26 or 5.2.3?

Generally when using a search engine, you should see links that point to the "current" Spring Framework reference, https://docs.spring.io/spring/docs/current/spring-framework-reference/. If that is not the case it would be useful to know.

maciejwalkowiak

comment created time in 6 days

issue commentspring-projects/spring-framework

DefaultCorsProcessor should return HTTP 204 instead of 200

The CORS spec allows it:

HTTP status code is in the 2xx range

The question is if browsers handle it without any issues.

buckett

comment created time in 6 days

issue commentspring-projects/spring-framework

WebFluxTest cannot read URL with matrix variable

WebFluxTest is part of Spring Boot so this issue belongs in the Boot issue tracker.

That said some things are not clear or missing. The test class annotations are not visible from the provided snippet. WebFluxTest is primarily for WebFlux testing but the server configuration WebMvcConfigurer is for Spring MVC. As you're connecting over a live port, it's possible that the server is Spring MVC but I think you'll probably need to provide more information about your setup.

Best of all if you could please provide a sample.

aCodeRancher

comment created time in 6 days

issue commentspring-projects/spring-framework

WebFluxTest cannot read URL with matrix variable

I've edited your comment to improve the formatting. You might want to check out this Mastering Markdown guide for future reference.

aCodeRancher

comment created time in 6 days

issue commentspring-projects/spring-framework

NullPointerException when no protocol is explicited on MockHttpServletRequestBuilder class

Actually it looks like fromUriString is quite useful because it allows to provide a path only. We need to keep that so it comes down to, either provide a URI with a path only (i.e. no scheme, host, port), or otherwise a proper HTTP URL.

If you want the short syntax you could go with just path, skipping host and port. Any reason not to do that.

dFarras

comment created time in 6 days

issue commentspring-projects/spring-framework

NullPointerException when no protocol is explicited on MockHttpServletRequestBuilder class

MockMvcRequestBuilders uses UriComponentsBuilder.fromUriString, which can't parse the given input correctly because "localhost:" looks like a scheme.

Switching to UriComponentsBuilder.fromHttpUrl provides a more helpful error:

java.lang.IllegalArgumentException: [localhost:8080/path] is not a valid HTTP URL

I don't we should go further and fill in the protocol since we don't know if that should be "http:" or "https:" and that could lead to surprises, and possibly even possible contradictions (e.g. "localhost:443").

dFarras

comment created time in 6 days

issue commentspring-projects/spring-framework

SpringBoot Error w/SecurityManager and AllPermission

I noticed that a different classloader may be used depending on whether springboot is initialized with a SecurityManager or not, regardless of policy settings. That's about as far as I got in the code. I checked to see if I could identify a SecurityManager unit test where this code path is exercised but didn't notice anything.

I don't think there is enough here to believe the root cause has anything in the Spring Framework.

I reviewed the next and other bug submissions to the spring project but didn't notice anything similar. I'm hope this information is helpful.

Do you mean that you searched this repository (Spring Framework) or the Spring Boot repository? The question seems more suited for Spring Boot based on the context.

I'm also wondering did you consider asking on the WebGoa's own issue tracker https://github.com/WebGoat/WebGoat?

spoofzu

comment created time in 6 days

issue commentspring-projects/spring-framework

WebMvcConfigurer not working without @EnableWebMvc after upgrading to spring-boot 2.x

In addition for an upgrade you should review the release notes and migration notes. It's possible that you did but you did not mention it. Generally, it's a good idea to determine if something is expected or not by reviewing the available information, before creating an issue. In your case it's probably related to the following migration note.

ShriprasadM

comment created time in 6 days

issue closedspring-projects/spring-framework

WebMvcConfigurer not working without @EnableWebMvc after upgrading to spring-boot 2.x

I am updating from spring-boot 1.5.4 to spring-boot 2.2.4. After migrating my JUnitss started breaking for ContentNegotiatingViewResolver.

I have the following functionality.

  1. Download the CSV / xls file.
  2. For this, we have used ContentNegotiatingViewResolver. Hence, we can make the following HTTP request http://localhost:8080/myapp/download.xls http://localhost:8080/myapp/download.csv
  3. based on file extension present in URL, the appropriate view is resolved and file with required extension is responded.

This is working as expected with sprint-boot 1.5.4. But after migration, my unit tests are failing to return HTTP 404 status.

But, after the upgrade, if I annotated my class implementing WebMvcConfigurer with @EnableWebMvc unit tests are able to detect the above URLs. Even the same behavior is observed when application is running the upgrade.

Not sure, if @EnableWebMvc is mandatory for classes implementing WebMvcConfigurer or it is an issue with Spring - boot 2.2.4 i.e. with spring 5.

Please guide me.

closed time in 6 days

ShriprasadM

issue commentspring-projects/spring-framework

WebMvcConfigurer not working without @EnableWebMvc after upgrading to spring-boot 2.x

Thanks for getting in touch, but it feels like this is a question that would be better suited to Stack Overflow. As mentioned in the guidelines for contributing, we prefer to use the issue tracker only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it) or add some more details if you feel this is a genuine bug.

ShriprasadM

comment created time in 6 days

issue commentspring-io/issue-bot

Waiting for feedback label is removed too early in some edge cases

Right, I got it now! Yes it would be nice to control if the clock restarts or continues, and I can imagine some additional label like comment-provided for when the clock should continue, but as you pointed out, the time taken for the team to respond should be subtracted from the overall clock time.

Beyond that even if we didn't have that sophistication I would still be okay with a simple resetting of the clock. Yes that might prolong things but as long as there is a clock that'll close eventually on its own, and it's no different from what we have today.

dreis2211

comment created time in 6 days

issue commentspring-io/issue-bot

Waiting for feedback label is removed too early in some edge cases

If more feedback is needed and without it the issue cannot be scheduled then the clock should be on, no? If more feedback is needed but the issue clearly can be scheduled then I don't see the need to leave waiting-for-feedback and have a clock running. So I'm not following what the concern is.

dreis2211

comment created time in 6 days

push eventspring-projects/spring-framework

Rossen Stoyanchev

commit sha 4e552625219dc324c5ceff7dc6383f0c86774d1a

Upgrade to Reactor Californium snapshots See gh-24527

view details

push time in 6 days

issue commentspring-projects/spring-framework

AbstractClientHttpResponse not compatible with Cloudflare 521 status code

Ignore my comment. What @sbrannen said.

rubasace

comment created time in 6 days

issue openedreactor/reactor-netty

Hook for redirect request handling

HttpClient provides an option to follow server redirects and HttpClientRequest exposes the URL redirect chain as String[] via redirectedFrom().

It would be useful to expose a global hook related to redirecting, possibly as followRedirect variants in HttpClient next to the existing ones, where the redirectRequestConsumer would be invoked before the request is committed in order to apply post processing. For example:

public final HttpClient followRedirect(boolean followRedirect, Consumer<HttpClientRequest> redirectRequestConsumer) {
    // ...
}

public final HttpClient followRedirect(BiPredicate<HttpClientRequest, HttpClientResponse> predicate, 
        Consumer<HttpClientRequest> redirectRequestConsumer) {
    // ...
|

So that HttpClient can be configured once, upfront, with regards to redirects.

created time in 7 days

issue closedspring-projects/spring-framework

AbstractClientHttpResponse not compatible with Cloudflare 521 status code

While trying to access the http status from an interceptor on the RestTemplate I'm getting the following exception:

No matching constant for [521] at 
org.springframework.http.HttpStatus.valueOf(HttpStatus.java:538) at 
org.springframework.http.client.AbstractClientHttpResponse.getStatusCode(AbstractClientHttpResponse.java:33) at 
org.springframework.http.client.BufferingClientHttpResponseWrapper.getStatusCode(BufferingClientHttpResponseWrapper.java:50)

It seems that 521 (Web server is down) isn't a valid value for org.springframework.http.HttpStatus. I can just get the raw number but does it make sense to support it from Spring side?

closed time in 7 days

rubasace

push eventspring-projects/spring-framework

Rossen Stoyanchev

commit sha 87f866b68871049fe2706a5b916214244e969a65

Update DigestUtils Javadoc with regards to InputStream Closes gh-24534

view details

Rossen Stoyanchev

commit sha 68b980f8498a7a07004ed05547400f4997252bad

Remove producible request attribute before mapping The attribute was previously removed only before exception resolution in the DispatcherServlet in order to allow error rendering to make an independent choice on content negotation. However, Boot rendering happens later in an ERROR dispatch which could also be a nested dispatch on some servers. So the attribute must also generally be removed prior to mapping. We also move the methods where this is done to the base RequestMappingInfoHandlerMapping class which also deals with the produces condition and where the producible attribute is added in the first place. Closes gh-24466

view details

push time in 7 days

issue closedspring-projects/spring-framework

If controller method has produces="*/*" in 5.2.3 response is 500 instead of 406

With the following commit, if a RequestMapping specifies produces="*/*and the request headers don't specify any accept, it will override the response with a 500 as the code below suggests :

https://github.com/spring-projects/spring-framework/commit/34d32402d352fe7bca2f45d3bc5c7243459ec556#diff-24571dc5c7743b2a69f7a5df4f2109b2R316

closed time in 7 days

smaldini

issue closedspring-projects/spring-framework

Update DigestUtils Javadoc with regards to InputStream closing

Maybe I need to use this file later, but for now, I just want the md5 string.

Would you modify the DigestUtils class to close it automatically?

Code: DigestUtils

Result: result

closed time in 7 days

wanjiaXG

issue commentspring-io/issue-bot

Waiting for feedback label is removed too early in some edge cases

I think when feedback-is-provided" is present, the ticket is in a state where the next step must be taken by a developer and that means the clock should be off. Upon reviewing the new information, the developer would either accept/schedule, or comment and dropfeedback-is-provided`, which would put the clock back on.

dreis2211

comment created time in 7 days

issue commentspring-projects/spring-framework

Escape quotes in filename in ContentDisposition.Builder when charset not specified

@rshanlever, please follow the regular channels for follow-up questions.

rstoyanchev

comment created time in 7 days

issue closedspring-projects/spring-framework

Wss4jSecurityInterceptor not propagating time to live values when validating ws-security soap header timestamp

<!-- !!! For Security Vulnerabilities, please go to https://pivotal.io/security !!! --> Affects: spring-ws-security-3.0.8.RELEASE


<!-- Thanks for taking the time to create an issue. Please read the following:

  • Questions should be asked on Stack Overflow.
  • For bugs, specify affected versions and explain what you are trying to do.
  • For enhancements, provide context and describe the problem.

Issue or Pull Request? Create only one, not both. GitHub treats them as the same. If unsure, start with an issue, and if you submit a pull request later, the issue will be closed as superseded. -->

Description

I have spring web services deployed to remote hosts offshore that may not be using NTP services to keep their clocks synchronised resulting in potential skewing of those server system clocks. This is out of my control and causes an issue with the web service ws-security handling specifically relating to the ws-security header timestamp validation of the received message.

I attempted to increase the time to live attributes on the definition of the Wss4jSecurityInterceptor bean for example by setting these 3:

      <property name="timestampStrict" value="${server.wss.timestampStrict}" />
      <property name="validationTimeToLive" value="${server.wss.validation.ttl}" />
      <property name="futureTimeToLive" value="${server.wss.future.ttl}" />

The full bean definition:

<bean id= "wss4jInterceptor" class="org.springframework.ws.soap.security.wss4j2.Wss4jSecurityInterceptor">
      <!-- Securing the outgoing message -->
      <property name="securementActions" value="${server.wss.actions}" />
      <property name="timestampPrecisionInMilliseconds" value="true" />
      <property name="securementTimeToLive" value="${server.wss.securement.ttl}" />
      <property name="securementSignatureKeyIdentifier" value="DirectReference" />
      <property name="securementUsername" value="${ws.server.ks.sig.reply.privatekey.alias}" />
      <property name="securementPassword" value="${ws.server.ks.sig.reply.privatekey.password}" />
      <property name="securementSignatureParts" value="{}{http://schemas.xmlsoap.org/soap/envelope/}Body" />
      <property name="securementSignatureCrypto">
        <bean class="org.springframework.ws.soap.security.wss4j2.support.CryptoFactoryBean">
          <property name="keyStorePassword" value="${ws.server.ks.sig.reply.password}" />
          <property name="keyStoreLocation" value="${ws.server.ks.sig.reply.url}" />
        </bean>
      </property>
      <!-- Validating the incoming message -->
      <property name="validationActions" value="${server.wss.actions}" />
      <property name="timestampStrict" value="${server.wss.timestampStrict}" />
      <property name="validationTimeToLive" value="${server.wss.validation.ttl}" />
      <property name="futureTimeToLive" value="${server.wss.future.ttl}" />
      <property name="validationSignatureCrypto">
        <bean class="org.springframework.ws.soap.security.wss4j2.support.CryptoFactoryBean">
          <property name="keyStorePassword" value="${server.ks.sig.rqst.password}" />
          <property name="keyStoreLocation" value="${server.ks.sig.rqst.url}" />
        </bean>
      </property>
      <property name="exceptionResolver" ref="myExceptionResolver"/>
    </bean>

Problem

Strangely, the problem did not improve. The timestamp validation was still failing. I had increased the ttl values to 420 seconds (7 minutes) but it appeared the update had no effect. I've done some analysis debugging the Wss4jSecurityInterceptor locally and came up with the following observations: Default values from Wss4jSecurityInterceptor:

private boolean timestampStrict = true;
private int validationTimeToLive = 300;
private int futureTimeToLive = 60;

The TimestampValidator.validate() method is actually called twice within the Wss4jSecurityInterceptor.validateMessage() method.
Firstly in the securityEngine.processSecurityHeader() and subsequently in the verifyTimestamp() method. It appears that the TimestampValidator.validate() method requires an initialised RequestData object passed in with the various time to live attributes propagated from the attributes of the Wss4jSecurityInterceptor.

Within the code of the Wss4jSecurityInterceptor.validateMessage() method there is an attempt to do just that via initializeValidationRequestData():

@Override
protected void validateMessage(SoapMessage soapMessage, MessageContext messageContext)
			throws WsSecurityValidationException {
...
RequestData validationData = initializeValidationRequestData(messageContext);
WSHandlerResult result = securityEngine
				.processSecurityHeader(elem, validationData);
...
verifyTimestamp(result);

However, the initializeValidationRequestData() method doesn't propagate the attributes. Therefore the processSecurityHeader() processing ends up using the default values contained in the RequestData object being:

    /**
     * The time in seconds between creation and expiry for a Timestamp. The default
     * is 300 seconds (5 minutes).
     */
    private int timeStampTTL = 300;

    /**
     * The time in seconds in the future within which the Created time of an incoming
     * Timestamp is valid. The default is 60 seconds.
     */
    private int timeStampFutureTTL = 60;

This is why the overall ws-security header validation still fails because it's using these default values instead of those I had explicitly set on the Wss4jSecurityInterceptor bean.

Workaround

To address this, I extended Wss4jSecurityInterceptor and overrode the initializeValidationRequestData() method as follows:

    /**
     * Fix: The parent calls a processSecurityHeader method on the <code>WSSecurityEngine</code>
     * prior to calling the verifyTimestamp as part of the validateMessage method.
     * The problem is that the necessary time to live attributes are not propagated 
     * during the initializeValidationRequestData method in the parent so we need
     * to do it explicitly here unfortunately.
     */
    @Override
    protected RequestData initializeValidationRequestData(MessageContext messageContext)
    {
        RequestData requestData = new RequestData();
        requestData = super.initializeValidationRequestData(messageContext);
        requestData.setTimeStampFutureTTL(futureTimeToLive);
        requestData.setTimeStampTTL(validationTimeToLive);
        requestData.setTimeStampStrict(timestampStrict);
        return requestData;
    }

This ensures that the RequestData object is correctly configured before either of the two calls to verify the timestamps. Without this, the processSecurityHeader() would fail the timestamp validation as it wasn't picking up the specified ttl values from the bean.

I think the initializeValidationRequestData() method in Wss4jSecurityInterceptor class should propagate the values to the RequestData object as per my overridden method and that would solve this bug.

Perhaps then the correctly initialised RequestData object could be passed to the verifyTimestamp() method too precluding the need for a new object to be created again inside that method.

closed time in 7 days

mightybeaker

issue commentspring-projects/spring-framework

Wss4jSecurityInterceptor not propagating time to live values when validating ws-security soap header timestamp

@mightybeaker I believe this issue is intended for the issue tracker of the Spring Web Services (see link to JIRA on that page). If I'm mistaken, and you have reason to believe the issue is in the Spring Framework, then please explain, and I will re-open again.

mightybeaker

comment created time in 7 days

pull request commentspring-projects/spring-framework

Repeatable Read HttpServletRequest InputStream

@lixiaolong11000 it is okay to provide links to StackOverflow for extra context but not as a substitute for a proper issue description, as indicated in our CONTRIBUTING guidelines.

Reviewing long SO threads and trying to extrapolate what you might have meant is very ineffective, and it causes everyone else who comes along and reads this issue to the same.

For example I don't know why you made a copy of ContentCachingRequestWrapper, you made no mention of that, and it's still not clear why you cannot make it work. If you don't mind explaining, I will have another look.

lixiaolong11000

comment created time in 8 days

PR closed spring-projects/spring-framework

Repeatable Read HttpServletRequest InputStream status: waiting-for-triage

Cannot Read HttpServletRequest,getInputStream() Multi Times.

  • When I readed HttpServletRequest.getInputStream() in the Filter, then the @RequestBody parsing parmeter face an exception like "java.io.IOException: Stream closed".
  • The exception above is that HttpServletRequest,getInputStream() can only be read once, I read HttpServletRequest.getInputStream() in the filter before RequestParamMethodArgumentResolver read.

The Same Problem In StackOverFlow

  • https://stackoverflow.com/questions/4449096/how-to-read-request-getinputstream-multiple-times
  • https://stackoverflow.com/questions/5345173/unable-to-read-request-getinputstream
+255 -0

3 comments

2 changed files

lixiaolong11000

pr closed time in 8 days

pull request commentspring-projects/spring-framework

Repeatable Read HttpServletRequest InputStream

RepeatableReadInputStreamAndContentCacheRequestWrapper.java appears to be a duplicate of our own ContentCachingRequestWrapper.java. I don't know how this class was created but it appears to have originated from ContentCachingRequestWrapper if you look to the Javadoc and much of the structure.

lixiaolong11000

comment created time in 8 days

issue commentspring-projects/spring-framework

Consider closing InputStream automatically in DigestUtils.md5DigestAsHex

Oops, did not mean to close it. Yes I think the Javadoc can mention explicitly that InputStream must be closed externally.

wanjiaXG

comment created time in 8 days

IssuesEvent

issue closedspring-projects/spring-framework

Consider closing InputStream automatically in DigestUtils.md5DigestAsHex

Maybe I need to use this file later, but for now, I just want the md5 string.

Would you modify the DigestUtils class to close it automatically?

Code: DigestUtils

Result: result

closed time in 8 days

wanjiaXG

issue commentspring-projects/spring-framework

Consider closing InputStream automatically in DigestUtils.md5DigestAsHex

I believe the underlying reason for this is that if a resource, such as an InputStream was opened externally, then it must also up to the external caller to decide and control. In other words the code that takes the InputStream cannot assume that closing it is the right thing to do.

This class for example is used in Spring MVC where the input stream is that of the HTTP response and it must not be closed.

Note also that this is a class mainly for internal use within the framework as the Javadoc says. You can of course use it but it is not designed to serve framework needs, which sometimes more flexibility in exchange for convenience.

wanjiaXG

comment created time in 8 days

push eventspring-projects/spring-framework

Rossen Stoyanchev

commit sha df1145b797d1cdb4eb44343ad2cb9a2c26b9b499

Correct documentation error in section on BeanWrapper Closes gh-24510

view details

Rossen Stoyanchev

commit sha fb6ee012815345285fafe081009fe2fb9f4a6589

Consistently call setComplete before WS upgrade Even thought Tomcat and Jetty, which commit the response more lazily, were not impacted by this issue, it still makes sense for them to complete the WebFlux response (and pre-commit actions) at the same time as for other servers for consistent behavior. See gh-24475

view details

push time in 8 days

issue closedspring-projects/spring-framework

Incorrect mention of getPropertyValues in BeanWrapper section of documentation

In the section of 3.3.1 in spring framework version 5.1.3.RELEASE core technologies document, the document describes that there is a getPropertyValues method. In fact, there is no such method in the BeanWrapeer class. I'm not sure if this is a version problem or refers to a method in another class instead of BeanWrapper.

图片

closed time in 8 days

zhuzhuman978

issue commentspring-projects/spring-boot

Avoid 406 Not Acceptable for error pages

Ah yes indeed it was, and it is working as expected, my bad. Cheers!

bclozel

comment created time in 8 days

issue commentspring-projects/spring-boot

Avoid 406 Not Acceptable for error pages

It would be really useful to have this one in 2.2.x. I keep running into issues where the original status is obscured.

bclozel

comment created time in 8 days

issue closedspring-projects/spring-framework

StringToCollectionConverter splits string by comma [SPR-15356]

None opened SPR-15356 and commented

When you submit a form (only tried post) with a parameter that includes a comma, and the parameter is bound to a List<String> then this value is passed through to the method org.springframework.core.convert.support.StringToCollectionConverter.convert(Object, TypeDescriptor, TypeDescriptor). That method then splits the String at the comma, resulting in a list with two elements instead of one.

I understand that comma is used to split array values in the url. I checked the raw request and the comma is translated to %2C so this shouldn't happen. It must be a bug somewhere in the call hierachy.

This problem only exists if one value is submitted for the list. If two or more values are submitted (e.g. two checkboxes checked) then a different converter is choosen (array to list) and no comma splitting is done.


Affects: 4.3.7

closed time in 13 days

spring-issuemaster

issue commentspring-projects/spring-framework

StringToCollectionConverter splits string by comma [SPR-15356]

This is actually a duplicate of #23820.

spring-issuemaster

comment created time in 13 days

issue commentspring-projects/spring-framework

The problem of spring framework version 5.1.3.RELEASE core technologies document

It looks like that was getPropertyValue(s) at some point, i.e. meant to refer to all overloaded variants, but was edited in 395e3d008cc3fa63dbfc7319fad0f29120e84053.

zhuzhuman978

comment created time in 13 days

issue commentAzure/azure-sdk-for-java

Enable client libraries to opt-out of buffer copying when using azure-core-netty

other services may choose to prefer performance over data correctness

Data correctness doesn't seem like a preference. Are there scenarios where corrupted data could be acceptable? Or do you perhaps mean is that applications might want to turn off deep copying if data is consumed immediately within onNext? In which case it would make sense to turn copying off.

I think the obstacle at the core of this problem is that returning java.nio.ByteBuffer eliminates the possibility to take advantage of pooled ByteBufs because the code downstream does not have access to the retain and release controls.

I don't know if it is feasible, but if you could expose an additional API to consume data as Flux<ByteBuf>s, then the applications could opt into working with ByteBufs, which makes perfect in cases where further downstream Netty is involved. This would give an application the ability to retain and pass on pooled direct buffers. In the case of a WebFlux controller those would be written through Netty to the server response.

srnagar

comment created time in 14 days

push eventspring-projects/spring-flex-roo

Jonathan Leitschuh

commit sha cbd0d2db424fb3ddec11b06a59af2d78c8d43e55

Use HTTPS instead of HTTP to resolve dependencies This fixes a security vulnerability in this project where the `pom.xml` files were configuring Maven to resolve dependencies over HTTP instead of HTTPS. Signed-off-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com>

view details

push time in 14 days

PR merged spring-projects/spring-flex-roo

[SECURITY] Use HTTPS to resolve dependencies in Maven Build

mitm_build


This is a security fix for a vulnerability in your Apache Maven pom.xml file(s).

The build files indicate that this project is resolving dependencies over HTTP instead of HTTPS. This leaves your build vulnerable to allowing a Man in the Middle (MITM) attackers to execute arbitrary code on your or your computer or CI/CD system.

This vulnerability has a CVSS v3.0 Base Score of 8.1/10.

POC code has existed since 2014 to maliciously compromise a JAR file in-flight. MITM attacks against HTTP are increasingly common, for example Comcast is known to have done it to their own users.

This contribution is a part of a submission to the GitHub Security Lab Bug Bounty program.

Detecting this and Future Vulnerabilities

This vulnerability was automatically detected by LGTM.com using this CodeQL Query.

As of September 2019 LGTM.com and Semmle are officially a part of GitHub.

You can automatically detect future vulnerabilities like this by enabling the free (for open-source) LGTM App.

I'm not an employee of GitHub nor of Semmle, I'm simply a user of LGTM.com and an open-source security researcher.

Source

Yes, this contribution was automatically generated, however, the code to generate this PR was lovingly hand crafted to bring this security fix to your repository.

The source code that generated and submitted this PR can be found here: JLLeitschuh/bulk-security-pr-generator

Opting-Out

If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called .github/GH-ROBOTS.txt to your repository with the line:

User-agent: JLLeitschuh/bulk-security-pr-generator
Disallow: *

This bot will respect the ROBOTS.txt format for future contributions.

Alternatively, if this project is no longer actively maintained, consider archiving the repository.

CLA Requirements

This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).

- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

Tracking

All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/bulk-security-pr-generator/issues/2

+8 -8

0 comment

1 changed file

JLLeitschuh

pr closed time in 14 days

push eventspring-projects/spring-framework

Rossen Stoyanchev

commit sha d55210551612e7ded3a068818ebc76a1e151bab3

Eliminate windowUntil from StringDecoder This is a follow-up on the earlier commit 28a95e89f35600199ee1254dee9e8ed53f958bcc eliminating windowUntil entirely which generates a BubblingException wrapper. This also keeps the chain a little simpler. See gh-24355

view details

Rossen Stoyanchev

commit sha 9277b470404ce1dce790fa82e684c9d8220940e7

Polishing: remove use of cast where avoidable

view details

push time in 14 days

push eventrstoyanchev/spring-mvc-chat

Jonathan Leitschuh

commit sha 552fa8754d22db6df6ae9530d47ea711454d64bf

Use HTTPS instead of HTTP to resolve dependencies This fixes a security vulnerability in this project where the `pom.xml` files were configuring Maven to resolve dependencies over HTTP instead of HTTPS. Signed-off-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com>

view details

push time in 14 days

PR merged rstoyanchev/spring-mvc-chat

[SECURITY] Use HTTPS to resolve dependencies in Maven Build

mitm_build


This is a security fix for a vulnerability in your Apache Maven pom.xml file(s).

The build files indicate that this project is resolving dependencies over HTTP instead of HTTPS. This leaves your build vulnerable to allowing a Man in the Middle (MITM) attackers to execute arbitrary code on your or your computer or CI/CD system.

This vulnerability has a CVSS v3.0 Base Score of 8.1/10.

POC code has existed since 2014 to maliciously compromise a JAR file in-flight. MITM attacks against HTTP are increasingly common, for example Comcast is known to have done it to their own users.

This contribution is a part of a submission to the GitHub Security Lab Bug Bounty program.

Detecting this and Future Vulnerabilities

This vulnerability was automatically detected by LGTM.com using this CodeQL Query.

As of September 2019 LGTM.com and Semmle are officially a part of GitHub.

You can automatically detect future vulnerabilities like this by enabling the free (for open-source) LGTM App.

I'm not an employee of GitHub nor of Semmle, I'm simply a user of LGTM.com and an open-source security researcher.

Source

Yes, this contribution was automatically generated, however, the code to generate this PR was lovingly hand crafted to bring this security fix to your repository.

The source code that generated and submitted this PR can be found here: JLLeitschuh/bulk-security-pr-generator

Opting-Out

If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called .github/GH-ROBOTS.txt to your repository with the line:

User-agent: JLLeitschuh/bulk-security-pr-generator
Disallow: *

This bot will respect the ROBOTS.txt format for future contributions.

Alternatively, if this project is no longer actively maintained, consider archiving the repository.

CLA Requirements

This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).

- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

Tracking

All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/bulk-security-pr-generator/issues/2

+3 -3

0 comment

1 changed file

JLLeitschuh

pr closed time in 14 days

push eventrstoyanchev/spring-mvc-31-demo

Jonathan Leitschuh

commit sha 4ddb286b16a33c0bfd4c59d371e187e6b6dd5674

Use HTTPS instead of HTTP to resolve dependencies This fixes a security vulnerability in this project where the `pom.xml` files were configuring Maven to resolve dependencies over HTTP instead of HTTPS. Signed-off-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com>

view details

push time in 14 days

PR merged rstoyanchev/spring-mvc-31-demo

[SECURITY] Use HTTPS to resolve dependencies in Maven Build

mitm_build


This is a security fix for a vulnerability in your Apache Maven pom.xml file(s).

The build files indicate that this project is resolving dependencies over HTTP instead of HTTPS. This leaves your build vulnerable to allowing a Man in the Middle (MITM) attackers to execute arbitrary code on your or your computer or CI/CD system.

This vulnerability has a CVSS v3.0 Base Score of 8.1/10.

POC code has existed since 2014 to maliciously compromise a JAR file in-flight. MITM attacks against HTTP are increasingly common, for example Comcast is known to have done it to their own users.

This contribution is a part of a submission to the GitHub Security Lab Bug Bounty program.

Detecting this and Future Vulnerabilities

This vulnerability was automatically detected by LGTM.com using this CodeQL Query.

As of September 2019 LGTM.com and Semmle are officially a part of GitHub.

You can automatically detect future vulnerabilities like this by enabling the free (for open-source) LGTM App.

I'm not an employee of GitHub nor of Semmle, I'm simply a user of LGTM.com and an open-source security researcher.

Source

Yes, this contribution was automatically generated, however, the code to generate this PR was lovingly hand crafted to bring this security fix to your repository.

The source code that generated and submitted this PR can be found here: JLLeitschuh/bulk-security-pr-generator

Opting-Out

If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called .github/GH-ROBOTS.txt to your repository with the line:

User-agent: JLLeitschuh/bulk-security-pr-generator
Disallow: *

This bot will respect the ROBOTS.txt format for future contributions.

Alternatively, if this project is no longer actively maintained, consider archiving the repository.

CLA Requirements

This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).

- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

Tracking

All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/bulk-security-pr-generator/issues/2

+1 -1

0 comment

1 changed file

JLLeitschuh

pr closed time in 14 days

push eventrstoyanchev/spring-sockjs-protocol-webapp

Jonathan Leitschuh

commit sha 973adf28f4b4bd3b2697986a2ddca16f206b404c

Use HTTPS instead of HTTP to resolve dependencies This fixes a security vulnerability in this project where the `pom.xml` files were configuring Maven to resolve dependencies over HTTP instead of HTTPS. Signed-off-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com>

view details

push time in 14 days

PR merged rstoyanchev/spring-sockjs-protocol-webapp

[SECURITY] Use HTTPS to resolve dependencies in Maven Build

mitm_build


This is a security fix for a vulnerability in your Apache Maven pom.xml file(s).

The build files indicate that this project is resolving dependencies over HTTP instead of HTTPS. This leaves your build vulnerable to allowing a Man in the Middle (MITM) attackers to execute arbitrary code on your or your computer or CI/CD system.

This vulnerability has a CVSS v3.0 Base Score of 8.1/10.

POC code has existed since 2014 to maliciously compromise a JAR file in-flight. MITM attacks against HTTP are increasingly common, for example Comcast is known to have done it to their own users.

This contribution is a part of a submission to the GitHub Security Lab Bug Bounty program.

Detecting this and Future Vulnerabilities

This vulnerability was automatically detected by LGTM.com using this CodeQL Query.

As of September 2019 LGTM.com and Semmle are officially a part of GitHub.

You can automatically detect future vulnerabilities like this by enabling the free (for open-source) LGTM App.

I'm not an employee of GitHub nor of Semmle, I'm simply a user of LGTM.com and an open-source security researcher.

Source

Yes, this contribution was automatically generated, however, the code to generate this PR was lovingly hand crafted to bring this security fix to your repository.

The source code that generated and submitted this PR can be found here: JLLeitschuh/bulk-security-pr-generator

Opting-Out

If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called .github/GH-ROBOTS.txt to your repository with the line:

User-agent: JLLeitschuh/bulk-security-pr-generator
Disallow: *

This bot will respect the ROBOTS.txt format for future contributions.

Alternatively, if this project is no longer actively maintained, consider archiving the repository.

CLA Requirements

This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).

- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

Tracking

All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/bulk-security-pr-generator/issues/2

+2 -2

0 comment

1 changed file

JLLeitschuh

pr closed time in 14 days

pull request commentspring-projects/spring-framework

Use equals method() instead of ==

I've changed this to Boolean.TRUE.equals(..) consistent with the rest of the framework, and shorter. Boolean.TRUE returns a constant.

hyeonisism

comment created time in 15 days

pull request commentspring-projects/spring-framework

ExecutorConfigurationSupport to take Duration for await termination period

I've turned that into awaitTerminationMillis which is usable for XML config, consistent with the rest of the framework, itself a shortcut for a Duration.

ttddyy

comment created time in 15 days

push eventspring-projects/spring-framework

Rossen Stoyanchev

commit sha e4a530efac8955151dedec67e1916b0321462699

Minor refactoring in CommonsLogWriter Closes gh-24495

view details

Rossen Stoyanchev

commit sha 7d1d9895351091a390cc54ea5fed24d8ec51611a

Minor polishing in ConcurrentReferenceHashMap Closes gh-24494

view details

Rossen Stoyanchev

commit sha 28a95e89f35600199ee1254dee9e8ed53f958bcc

Upgrade to Dysprosium SR5 snapshots See gh-24355

view details

Rossen Stoyanchev

commit sha 0a974511bd4826136f0a6e8be3d326587314a229

Expose awaitTerminationMillis presion Closes gh-24496

view details

Rossen Stoyanchev

commit sha e35d3b8bb55245b29b0b243079dee73b312d504d

Update advice on RestTemplate Closes gh-24503

view details

push time in 15 days

issue closedspring-projects/spring-framework

Update advice on RestTemplate

It would be more helpful, and also accurate, to explain that the RestTemplate is in maintenance mode rather than mention a potential deprecation in the future.

closed time in 15 days

rstoyanchev

PR closed spring-projects/spring-framework

ExecutorConfigurationSupport to take Duration for await termination period in: core type: enhancement

I noticed ExecutorConfigurationSupport(ThreadPoolTask[Executor|Scheduler]) only takes seconds for await termination.

I'm writing a graceful shutdown logic for k8s environment and awaiting by second is a bit large granularity to control the shutdown/await. Graceful shutdown get triggered by liveness probe and the frequency for liveness probe is not so long.

This PR changes the minimum unit to milliseconds and adds a method to take Duration to specify the await termination.

+17 -6

0 comment

1 changed file

ttddyy

pr closed time in 15 days

PR closed spring-projects/spring-framework

Use equals method() instead of == in: core type: task

Equals are better than comparisons using "==" Also, Boolean returns each new object.

+3 -3

0 comment

1 changed file

hyeonisism

pr closed time in 15 days

more