Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

@DestinationVariable not working with RSocket support #22776

Closed
bclozel opened this issue Apr 9, 2019 · 0 comments
Closed

@DestinationVariable not working with RSocket support #22776

bclozel opened this issue Apr 9, 2019 · 0 comments
Assignees
@bclozel
Labels
in: messaging Issues in messaging modules (jms, messaging) type: enhancement A general enhancement
Milestone
5.2 M1

Comments

@bclozel
Copy link
Member

bclozel commented Apr 9, 2019

The org.springframework.messaging.handler.annotation.support.reactive.DestinationVariableMethodArgumentResolver argument resolver is relying on destination template variables being set as message headers.

This is currently not being done by the RSocketMessageHandler and destination variables are not resolved.
@bclozel bclozel added in: messaging Issues in messaging modules (jms, messaging) type: enhancement A general enhancement labels Apr 9, 2019
@bclozel bclozel modified the milestones: 5.2 M2, 5.2 M1 Apr 9, 2019
@bclozel bclozel self-assigned this Apr 9, 2019
@bclozel bclozel closed this as completed in cd69a4a Apr 9, 2019
mdeinum added a commit to mdeinum/spring-framework that referenced this issue Aug 10, 2020
@mdeinum
Call StartupStep.end in finally block
37c61ed 
Prior to this commit it was possible that a StartupStep was
started but never ended. This was the case when an exception
occured during bean initializing. To always call the method
regardless of the outcome, the call to StartupStep.end has
been moved to a finally block.

When an exception occurs the StartupStep is also enriched with
the exception class and message for diagnostic purposes.

Related: spring-projectsgh-22776
@mdeinum mdeinum mentioned this issue Aug 10, 2020
Closed
bclozel pushed a commit that referenced this issue Aug 24, 2020
@mdeinum @bclozel
Call StartupStep.end in finally block
74a0147 
Prior to this commit it was possible that a StartupStep was
started but never ended. This was the case when an exception
occured during bean initializing. To always call the method
regardless of the outcome, the call to StartupStep.end has
been moved to a finally block.

When an exception occurs the StartupStep is also enriched with
the exception class and message for diagnostic purposes.

See gh-22776
Closes gh-25572
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bclozel bclozel

Labels
in: messaging Issues in messaging modules (jms, messaging) type: enhancement A general enhancement
Projects
None yet
Milestone
5.2 M1
Development

No branches or pull requests
1 participant
@bclozel