springwolf
UI publish endpoint fails when spring.jackson.property-naming-strategy=SNAKE_CASE (payload fields generated in camelCase)
When spring.jackson.property-naming-strategy=SNAKE_CASE is enabled in a Spring Boot application, the Springwolf UI fails to publish messages to Kafka because it generates the payload with camelCase field names, while the application expects snake_case.
As a result, publishing from the UI triggers a schema mismatch error like:
2025-12-03T19:31:55.625-03:00 INFO 80552 ---
[property-naming-strategy-conflict] [nio-8080-exec-7]
i.g.s.c.c.PublishingPayloadCreator :
Specified payloadType java.lang.String is not a registered springwolf schema.
Known payloadTypes: [
com.springwolf.property_naming_strategy_conflict.kafka.schema.Loan,
SpringKafkaDefaultHeaders-Loan-1030528931,
LoanHeaders
]
However, if I manually publish the message using Postman with snake_case fields, the application processes it correctly. This confirms that the UI is generating the wrong field naming format.
Dependencies and versions used
-
springwolf-kafka: 1.18.0
-
springwolf-ui: 1.18.0
-
Spring Boot: 3.5.8
Steps to reproduce
-
Clone the example repository reproducing the issue: https://github.com/florenciazabala/springwolf-property-naming-strategy
-
Run the Spring Boot application.
-
Open Springwolf UI → select a Kafka topic → click Publish.
-
The UI generates the payload using camelCase instead of snake_case.
-
Publish → The application logs the error above and rejects the message.
-
Send the same payload from Postman using snake_case, and the message is successfully processed.
Expected behavior
Springwolf UI should honor the Jackson naming strategy configured in the application, generating payload fields in snake_case when property-naming-strategy=SNAKE_CASE is set.
Actual behavior
Springwolf UI always generates payloads in camelCase, causing deserialization errors when the backend expects snake_case.
Minimal reproducible example
Repository: 👉 https://github.com/florenciazabala/springwolf-property-naming-strategy
Hi @florenciazabala thanks for reporting this issues. We plan to fix it by renaming the payload type to type. As this is a breaking change we plan it in for the migration to SpringBoot 4.
