Skip to content

Conversation

@MoonBow-1
Copy link
Contributor

A smaller PR from #15, which brings the EventMessage related classes.

  • Tested using the JMeter test plan
  • Does not fix the setters that are used in HttpEventData

@MoonBow-1 MoonBow-1 requested a review from kortemik August 25, 2025 12:47
@MoonBow-1 MoonBow-1 self-assigned this Aug 25, 2025
Copy link
Member

@kortemik kortemik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will re-review once comments are fixed

@MoonBow-1 MoonBow-1 removed the review label Aug 27, 2025
Copy link

@Laukkala Laukkala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only real issue I found was with the fact that Exceptions might not get logged if Response.body() is not called for some reason. Currently it seems that body() is being called eventually, but it might cause problems later on if another developer forgets to call it after receiving a Response. I would suggest separating the responsibility of writing to logs to another object, and leave the responsibility of generating the user-facing message as it is.

Copy link

@Laukkala Laukkala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the changes to logging, this looks good to me once review comments from other reviewers have been resolved

@MoonBow-1 MoonBow-1 requested a review from kortemik September 1, 2025 06:55
@kortemik kortemik requested a review from eemhu September 5, 2025 12:31
@p000010u p000010u removed the review label Sep 5, 2025
@MoonBow-1
Copy link
Contributor Author

I'll remove the HttpStatus fields from Responses tomorrow, and look into refactoring the contentType() method found in Response implementations, since now the application returns ResponseEntity<JsonNode> instead of String.

This is because of how Spring Boot handles response codes

…l or not an JSON object

- Does not throw an exception anymore
- Now uses ExceptionEventContext for the data
- toString() methods implemented for XForwarded* objects
- equals() and hashCode() methods implemented for Xforwarded*Stubs
…nd there

- Response code can now be set by each Response type
- Integration Test tests that a failed request returns response code 400 and the correct response message and an id field
- Status and Application types can be removed from the Response implementations
…ponseEntities

- This has removed the status fields from all Response implementations
- ResponseEntities contain the status code and content type
- These requests are supposed to fail
@eemhu
Copy link
Contributor

eemhu commented Oct 14, 2025

otherwise ok

@MoonBow-1 MoonBow-1 requested a review from eemhu October 14, 2025 10:24
@kortemik kortemik merged commit 8d70c2e into teragrep:master Nov 11, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants