[
https://issues.apache.org/jira/browse/SOLR-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792350#comment-16792350
]
Gus Heck commented on SOLR-13322:
---------------------------------
The two subtasks I opened are for bits that probably should have a Changes
Entry, one is a class going away, (I hope) and the other is a place where we'll
throw an exception that used to be silently ignored.
Other bits I think I can just fixup in case anyone wants to look:
org.apache.solr.client.solrj.embedded.JettySolrRunner#main --> just throw
the exception rather than catching/printing it.
QueryParserTokenManager: debugStream and setDebugStream() are unused -->
just delete them
org/apache/solr/search/mlt/CloudMLTQParser.java:175 --> just don't
printStacktrace()
org/apache/solr/util/RecordingJSONParser.java:76 --> add a logger and log a
message to log.error() instead
org/apache/solr/client/solrj/response/json/HeatmapJsonFacet.java:55 -->
log.debug
org/apache/solr/client/solrj/io/stream/ZplotStream.java:242 --> just delete
org/apache/solr/client/solrj/impl/XMLResponseParser.java:456 --> just remove
org.apache.solr.common.cloud.SolrZkClient#printLayoutToStdOut --> remove,
use version tat accepts a stream
org/apache/solr/client/solrj/cloud/SocketProxy.java:410 --> Just throw the
exception, the only caller also throws
org.apache.solr.common.util.FastJavaBinDecoder#main --> just remove, seems
similar to the ConfigOverlay case
org.apache.solr.cloud.ZkController#printLayoutToStdOut --> unused method
(becomes proble after fixing SolrZkClient)
> 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
> Priority: Minor
> 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: [email protected]
For additional commands, e-mail: [email protected]
