Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Allow MessageHeaderAccessor to be created with existing headers #33153

Closed
Nephery opened this issue Jul 5, 2024 · 1 comment
Closed

Allow MessageHeaderAccessor to be created with existing headers #33153

Nephery opened this issue Jul 5, 2024 · 1 comment
Assignees
Labels
in: messaging Issues in messaging modules (jms, messaging) type: enhancement A general enhancement
Milestone

Comments

@Nephery
Copy link

Nephery commented Jul 5, 2024

This issue was split from PR: #33137


Add a constructor that lets users create a MessageHeaderAccessor object given only a headers map.

This is a small optimization in high volume scenarios to avoid creating unnecessary Message<?> objects when you only have a headers map.

The specific use case I'm looking at, is being able to create a MessageHeaderAccessor object to process headers from a "consolidated headers" object (such as from the Rabbit Binder or Solace Binder) created for a Message<List<?>> consumed from Spring Cloud Stream's batched consumers.

e.g.: Being able to do something like this:

@Bean
Consumer<Message<List<Payload>>> input() {
	return batchMsg -> {
		List<Payload> batchedPayloads = batchMsg.getPayload();
		List<Map<String, Object>> batchedHeaders = (List<Map<String, Object>>) batchMsg.getHeaders().get(SolaceBinderHeaders.BATCHED_HEADERS);

		for (int i = 0; i < batchedPayloads.size(); i++) {
			Map<String, Object> headersMap = batchedHeaders.get(i);
			MessageHeaderAccessor accessor = null;
			if (headersMap instanceof MessageHeaders headers) {
				accessor = MessageHeaderAccessor.getAccessor(headers, null);

			}
			if (accessor == null || || !headers.isMutable()) {
				accessor = new MessageHeaderAccessor(headersMap);
			}

			// Do some logic with the accessor
		}
	};
}

With the current implementation, instead of just being able to do:

MessageHeaderAccessor accessor = new MessageHeaderAccessor(headersMap);

I would need to do this, which is pointless if the accessor's constructor will just extract the headers from the Message<?>:

MessageHeaderAccessor accessor = new MessageHeaderAccessor(new GenericMessage<?>(payload, headersMap));
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jul 5, 2024
@Nephery
Copy link
Author

Nephery commented Jul 5, 2024

One problem with your change is that there are now two constructors with a single argument that are nullable so this will break backward compatibility.

@snicoll as an alternative solution, maybe you could create a public static MessageHeaderAccessor getMutableAccessor(Map<String, Object> headers, ...) which delegates to a private MessageHeaderAccessor(Map<String, Object> headers) constructor?

Then either change the new function's name or add a second parameter (like @Nullable Class<T> requiredType) so that it doesn't conflict with the existing getMutableAccessor(Message<?> message)?

@jhoeller jhoeller added the in: messaging Issues in messaging modules (jms, messaging) label Jul 8, 2024
@snicoll snicoll self-assigned this Jul 8, 2024
@snicoll snicoll changed the title Add header-only constructor to create MessageHeaderAccessor Allow MessageHeaderAccessor to be created with existing headers Jul 8, 2024
@snicoll snicoll added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jul 8, 2024
@snicoll snicoll added this to the 6.2.0-M5 milestone Jul 8, 2024
@snicoll snicoll closed this as completed in 078dfd4 Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: messaging Issues in messaging modules (jms, messaging) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

4 participants