-
Notifications
You must be signed in to change notification settings - Fork 77
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
SpringWolf UI send the payloadType with the name of the message when the payload is a String and produce a 400 BadRequest #752
Comments
Welcome to Springwolf. Thanks a lot for reporting your first issue. Please check out our contributors guide and feel free to join us on discord. |
The change is staged for release and will be part of the next release. If you want to try and verify it in your application today, Thank you for the report/contribution! |
Thank you for the fix, when u think to publish the release 1.3.x @timonback ? I need to implement springwolf in my project for the docs generation and for testing purpose. |
Hi @pcomp96 , |
This morning i have tested the 1.3.0-SNAPSHOT version but the error still presented. If i remove the name attribute from @asyncmessage annotation the UI use the payloadType String.class as name of the message and this cause UI issue for the labels and consider both messages as same. @AsyncListener(
operation = @AsyncOperation(
channelName = "${queue.in.x-to-me-feedback}",
description = "X send the feedback to Me over this channel", // Optional
payloadType = String.class,
message = @AsyncMessage(
name= "XFeedbackMessagePayload",
messageId = "XFeedbackMessage",
description = "Example payload message that X send to me",
title = "X send feedback to Me - Message"
),
headers = @Headers(
schemaName = "XToMeFeedbackHeaders",
values = {
@Header(name = "headerXFeedback1", value = "1", description = "..."),
@Header(name = "headerXFeedback2", value = "2", description = "...")
}
)
)
)
@JmsAsyncOperationBinding
public IntegrationFlow jmsListenerXFeedback(...)
@AsyncListener(
operation = @AsyncOperation(
channelName = "${queue.in.x-to-me-data}",
description = "X send the data to Me over this channel",
payloadType = String.class,
message = @AsyncMessage(
name= "XDataMessagePayload",
messageId = "XDataMessage",
description = "Example payload message that X send to Me",
title = "X send data to Me - Message"
),
headers = @Headers(
schemaName = "XToMeDataHeaders",
values = {
@Header(name = "headerXData1", value = "1", description = ""),
@Header(name = "headerXData2", value = "2", description = ""),
}
)
)
)
@JmsAsyncOperationBinding
@Bean
public IntegrationFlow jmsListenerXData(...) Without name attributeYou can see that i have the same labels on the operation but i have different message declaration on the annotation.
With name attributeThis error appear in Java console because send the name of the message and not the payload type...
|
Thanks for the update. Can you share (parts of) the payload? Is it a string in both cases, but you want to have a different documentation for each one of them? You might be looking for AsyncApiPayload annotation, see https://www.springwolf.dev/docs/configuration/documenting-messages/#primitive-final-and-external-classes (Havent tested it, there can be a bug in publishing) As a safety mechanism, you can only publish classes that have been registered as a schema. So, XDataMessagePayload must be used either as part of the method signature or payloadType in the annotation. |
The @AsyncApiPayload annotation not solve the problem I do not want declare n. envelope classes for my n. String Messages(with different docs), honestly speaking, in my opinion is a bad approach. I want only specific the message description and unique messageid for I think that the UI might send the payloadType as a String type in this case and not with the name of the message UIThe labels are the same and the messages payload and header that the operations sends are the same. This is a problem on testing side because the headers in the string messages are different. Question: UI not use the message-id to distinguish the different message? |
Thanks for clarifying, I am trying to summarize. First issue: You want to use the message description and id, but that does not work when using plain string. Publishing is just to verify, but the ui shows already unexpected data. Regardless, I will need to properly reproduce this, probably on Friday. You can help, by forking the repo, adapting the jms example https://github.com/springwolf/springwolf-core/blob/master/springwolf-examples/springwolf-jms-example/src/main/java/io/github/springwolf/examples/jms/consumers/ExampleConsumer.java and opening a draft PR (no need for passing tests, etc). I want to make sure that I fully understand your issue and we can resolve it the next release. |
precisely when i set the name attribute in the @asyncmessage and the payloadType in @AsyncLis/Pub annotations is setted to String.class,
When i set String.class as payloadType and not set the name attribute in @asyncmessage,
I have 2 listener on 2 different channels,
I'm not able to make a PR this week because i'm really busy sorry , but i think that my example on the top is enough to reproduce the steps. @AsyncListener(
operation = @AsyncOperation(
channelName = "${queue.in.x-to-me-feedback}",
description = "X send the feedback to Me over this channel", // Optional
payloadType = String.class,
message = @AsyncMessage(
name= "XFeedbackMessagePayload",
messageId = "XFeedbackMessage",
description = "Example payload message that X send to me",
title = "X send FEEDBACK to Me - Message"
),
headers = @Headers(
schemaName = "XToMeFeedbackHeaders",
values = {
@Header(name = "headerFeedbackXToMe1", value = "1", description = "..headerFeedback XToMe1 description.."),
@Header(name = "headerFeedbackXToMe2", value = "2", description = "..headerFeedback XToMe2 description.."),
}
)
)
)
@JmsAsyncOperationBinding
@Bean
public IntegrationFlow xSendFeedbackListenerFlow(!NoPayloadHere){
//Flow logic
}
@AsyncListener(
operation = @AsyncOperation(
channelName = "${queue.in.x-to-me-data}",
description = "X send the data to Me over this channel", // Optional
payloadType = String.class,
message = @AsyncMessage(
name= "XDataMessagePayload",
messageId = "XDataMessage",
description = "Example payload message that X send to Me",
title = "X send DATA to Me - Message"
),
headers = @Headers(
schemaName = "XToMeDataHeaders",
values = {
@Header(name = "headerDataXToMe1", value = "1", description = "..headerData XToMe1 description.."),
@Header(name = "headerDataXToMe2", value = "2", description = "..headerData XToMe2 description.."),
}
)
)
)
@JmsAsyncOperationBinding
@Bean
public IntegrationFlow xSendDataListenerFlow(!NoPayloadHere){
//Flow logic
} |
Nice! 💯 @timonback When you merge it into the master branch? |
Probably Friday, just tuen on the notifucations on both PRs, then you will get a ping automatically |
@pcomp96 The PRs have been merged and are ready as SNAPSHOT |
Hi @timonback , Thanks again for your effort! I hope I was helpful! It was a pleasure, see you next time 🙏🏻 ⏭️ |
Thank you, great collaboration! Can we feature your company as an user, see #342 ? |
The change is available in the latest release. 🎉 Thank you for the report/contribution and making Springwolf better! |
Describe the bug
I'm using spring integration with some jms adapter, I created the specification on my listener like in the code example.
When i try to publish a message from the SpringWolf UI , the client send this request body:
The payloadType is filled with the attribute
name = "XDataMessagePayload"
and not with the attributepayloadType = String.class
setted in the annoation.This produce a 400 BadRequest and a pubilsh failed error in the UI.
Dependencies and versions used
springboot
version3.2.3
springwolf-ui
version1.2.0
springwolf-core
version1.2.0
springwolf-jms
version1.2.0
Code example
Note: If I omit the attribute name="XDataMessagePayload" and have multiple messages with the same payloadType (String.class), in the UI the labels all appear the same as the last processed message.. 👎🏻
Stack trace and error logs
On the chrome console side :
On the backend side with the debug log enabled
The text was updated successfully, but these errors were encountered: