Skip to content

Conversation

@Anshul-target
Copy link

Problem

JUnit test output that is not a Java stack trace was getting highlighted as if it were a Java exception. This made normal logs (API responses, timestamps, tokens, plain text) look like stack traces, causing bad UX and confusion.

Solution

  • Only apply language-javastacktrace syntax highlighting to Error Details and Stack Trace fields (which always contain Java exceptions when present)
  • Remove automatic highlighting from Standard Output and Standard Error fields
  • Add conditional logic to detect Java exception patterns in stdout/stderr and apply highlighting only when appropriate

Changes

  • Modified the Jelly template to use a codeClass parameter
  • Error Details and Stack Trace: always highlighted (they only exist when there's a Java exception)
  • Standard Output and Standard Error: conditionally highlighted based on content detection

Testing

Tested with:

  1. Test with Java exception → Error Details, Stack Trace, and stdout properly highlighted ✅
  2. Test with regular logs → No highlighting on API responses, tokens, timestamps ✅
  3. Test with successful output → No highlighting on normal logs ✅

Before

Screenshot 2026-01-02 115442

After

Screenshot 2026-01-03 094342 Screenshot 2026-01-03 094411

…n-exception output

- Only apply 'language-javastacktrace' syntax highlighting to Error Details and Stack Trace fields
- Remove highlighting from Standard Output and Standard Error when they contain regular logs
- Add conditional logic to detect Java exceptions in stdout/stderr and highlight only when appropriate
- Improves UX by preventing API responses, timestamps, and tokens from being highlighted as stack trace
@Anshul-target Anshul-target requested a review from a team as a code owner January 3, 2026 04:36
Copy link
Member

@timja timja left a comment

Choose a reason for hiding this comment

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

this complexity is not worth it, the highlighted output generally is easier to read anyway... there are some cases where its not the best but mostly I've found it easier

@Anshul-target
Copy link
Author

this complexity is not worth it, the highlighted output generally is easier to read anyway... there are some cases where its not the best but mostly I've found it easier

Do i need to make some changes

Copy link
Member

@iamrajiv iamrajiv left a comment

Choose a reason for hiding this comment

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

What about custom exceptions, multi-line stack traces, or system properties containing "Exception"?

<local:item id="${id}" name="error" title="${%Error Details}" value="${it.errorDetails}" codeClass="language-javastacktrace" />
<j:forEach var="p" items="${it.properties}">
<local:item id="${id}" name="${p.key}" title="${p.key}" value="${p.value}" />
<local:item id="${id}" name="${p.key}" title="${p.key}" value="${p.value}" codeClass="" />
Copy link
Member

Choose a reason for hiding this comment

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

Why hardcode an empty string instead of removing the parameter entirely? This creates unnecessary complexity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants