[
https://issues.apache.org/jira/browse/SLING-13049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Liechti updated SLING-13049:
---------------------------------
Description:
h3. Update Regarding SlingRequestProcessorImpl Log Messaging
Following a review of community feedback and developer usage patterns, we have
decided to change the following log message from error to debug:
{{*ERROR* org.apache.sling.engine.impl.SlingRequestProcessorImpl Content Type
Header state has not been cleared properly, is set to NOT_VIOLATED}}
*Context and Resolution* Initially, this log was introduced as a diagnostic
tool to help developers identify specific request paths that were not being
fully cleared before disposal. While technically accurate, our analysis and
ongoing discussions with the community have led to the following conclusions:
* *Operational Impact:* Because the request lifecycle ends immediately after
reset of the state, there is no functional risk or performance degradation, so
debug is enough
* *Developer Experience:* Feedback indicated that once developers understood
the technical context, the message was often viewed as "noise" rather than an
actionable error, so lowering the importance is the right thing to do.
* *Log Cleanliness:* To ensure that logs remain focused on high-priority,
actionable items, we have moved this message to prevent unnecessary error log
volume.
We are committed to maintaining a clean and meaningful logging environment.
This change allows developers to focus on critical system events without the
distraction of non-impactful technical warnings.
was:
h3. Update Regarding SlingRequestProcessorImpl Log Messaging
Following a review of community feedback and developer usage patterns, we have
decided to remove the following log message:
{{*ERROR* org.apache.sling.engine.impl.SlingRequestProcessorImpl Content Type
Header state has not been cleared properly, is set to NOT_VIOLATED}}
*Context and Resolution* Initially, this log was introduced as a diagnostic
tool to help developers identify specific request paths that were not being
fully cleared before disposal. While technically accurate, our analysis and
ongoing discussions with the community have led to the following conclusions:
* *Operational Impact:* Because the request lifecycle ends immediately after
reset of the state, there is no functional risk or performance degradation
associated with this state remaining set.
* *Developer Experience:* Feedback indicated that once developers understood
the technical context, the message was often viewed as "noise" rather than an
actionable error.
* *Log Cleanliness:* To ensure that logs remain focused on high-priority,
actionable items, we have removed this message to prevent unnecessary log
volume.
We are committed to maintaining a clean and meaningful logging environment.
This change allows developers to focus on critical system events without the
distraction of non-impactful technical warnings.
> Change "Content Type Header" error log to debug in SlingRequestProcessorImpl
> ----------------------------------------------------------------------------
>
> Key: SLING-13049
> URL: https://issues.apache.org/jira/browse/SLING-13049
> Project: Sling
> Issue Type: Improvement
> Components: Engine
> Affects Versions: Engine 3.0.0, Engine 2.16.2, Engine 2.16.4, Engine 2.16.6
> Reporter: Remo Liechti
> Assignee: Remo Liechti
> Priority: Minor
>
> h3. Update Regarding SlingRequestProcessorImpl Log Messaging
> Following a review of community feedback and developer usage patterns, we
> have decided to change the following log message from error to debug:
> {{*ERROR* org.apache.sling.engine.impl.SlingRequestProcessorImpl Content Type
> Header state has not been cleared properly, is set to NOT_VIOLATED}}
> *Context and Resolution* Initially, this log was introduced as a diagnostic
> tool to help developers identify specific request paths that were not being
> fully cleared before disposal. While technically accurate, our analysis and
> ongoing discussions with the community have led to the following conclusions:
> * *Operational Impact:* Because the request lifecycle ends immediately after
> reset of the state, there is no functional risk or performance degradation,
> so debug is enough
> * *Developer Experience:* Feedback indicated that once developers understood
> the technical context, the message was often viewed as "noise" rather than an
> actionable error, so lowering the importance is the right thing to do.
> * *Log Cleanliness:* To ensure that logs remain focused on high-priority,
> actionable items, we have moved this message to prevent unnecessary error log
> volume.
> We are committed to maintaining a clean and meaningful logging environment.
> This change allows developers to focus on critical system events without the
> distraction of non-impactful technical warnings.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
