[ 
https://issues.apache.org/jira/browse/SOLR-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gus Heck resolved SOLR-13322.
-----------------------------
       Resolution: Fixed
    Fix Version/s: master (9.0)

Resolving in master only on the theory that print statements probably won't be 
added in the back porting process, and if System.outs do sneak in on branches 
eventually they age away anyway.

> 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
>             Fix For: master (9.0)
>
>         Attachments: SOLR-13322.patch, 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]

Reply via email to