Gus Heck created SOLR-13322:
-------------------------------
Summary: Enable checking for System.out references in Solr codebase
Key: SOLR-13322
URL: https://issues.apache.org/jira/browse/SOLR-13322
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: Build
Affects Versions: master (9.0)
Reporter: Gus Heck
Attachments: sysout-forbidden.txt
This is almost trivial (just delete this line from the solr build.xml):
{code:java}
<target name="-check-forbidden-sysout"/>{code}
What that line is doing is overriding the top level target that does the
checking and makes it do nothing.
BUT.... unfortunately the "almost" of this is that that instantly detects a
large number of things, many of which are valid usages because they are in
command line tools that really do want to report information to system out
(I'll attach the output)
This leaves us with two possibilities:
# Add @ SuppressForbidden (though there seem to be two of these)
# Convert the CLI oriented code to use logging (probably a custom logging
config for this use case with no leading date stamp etc...)
In the first case there's the additional question of whether or not we can
suppress just the one bundle (jdk-system-out) or if we have to suppress all
forbidden apis checks (which is a worrisome thought).
Also it's worth noting that a there are a couple of other detections relating
to eclipse generated try/catch blocks that are triggered by removing the above
line from the build.
Conversation on Slack indicates that [~thetaphi] will likely have some thoughts
on this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
