On 26/12/15 13:05, Xiaoyu Huang wrote:
> System.out.println() is for easier debugging as I can see the results
> directly in wrapper.log.
>
> I see many examples in Fred code that uses both Logger and println(). An
> example in NodeCrypto.java line around 136:
>
>                     Logger.normal(this, "Could not use port: "+bindto+ ':'
> +portNo+": "+e, e);
>                     System.err.println("Could not use port: "+bindto+ ':'
> +portNo+": "+e);
>
> I'm not quite sure what's the best practice.
>
> -- Xiaoyu
Only critical stuff should be logged to stderr. E.g. if it's likely to
break the node completely, as in the above case: Freenet will fail to
start up if it fails to bind the darknet UDP port. Then if the user
comes to us we can quickly see what went wrong. Similarly with major
milestones in a normal startup, for the same reason, and generally
anything we'll need to know when a user comes to us saying their node is
totally broken, or where we need to tell the user but haven't yet got
around to implementing a user-alert to show it on the actual fred user
interface.

General debugging should use Logger. Then you can filter it using the
logger settings in the configuration, which allow e.g. to show different
priority levels for different subsystems, change the log rotation
interval etc.

Anything that indicates an actual error should be ERROR. Something that
is suspicious but only a problem if it happens a lot should be WARNING.
Important stuff that happens normally but it's useful to know about if
debugging should be NORMAL.

MINOR and DEBUG are used for really expensive, chatty logging of details
(including potentially incriminating details e.g. keys). These should
always be conditional on logMINOR/logDEBUG, which means you need the
following boilerplate setup:

private static volatile logMINOR;
private static volatile logDEBUG;
static {
Logger.registerClass(MyClassName.this);
}

This is repeated in many classes in fred.

This should be on a wiki page ...
>
> On Sat, Dec 26, 2015 at 1:39 AM, Ian <[email protected]> wrote:
>
>> This looks great!
>>
>> I notice a lot of System.out.println()s in the code, do we not have a
>> logging mechanism in Fred available for use by plugins?
>>
>> On Fri, Dec 25, 2015 at 10:14 AM, Xiaoyu Huang <[email protected]> wrote:
>>
>>> Hi All,
>>>
>>> As nextgens suggests, I write this plugin which is based on the newer and
>>> more stable UPnP lib named Cling (http://4thline.org/projects/cling/).
>>>
>>> Currently It only supports FredPluginIPDetector and
>> FredPluginPortForward.
>>> I will add FredPluginBandwidthIndicator and Web UI support when I have
>>> time.
>>>
>>> Code review, suggestions and tests are required. The source code can be
>>> accessed here:
>>>
>>> https://github.com/007pig/plugin-UPnP2
>>>
>>> I uses Gradle as the build system. So to build the plugin and package it
>> as
>>> plugin jar, you need:
>>>
>>>    1. Copy freenet.jar, freenet-ext.jar and bcprov-jdk15on-152.jar to
>>>    "[project root]/libs" dir.
>>>    2. Run "./gradlew build shadowjar".
>>>    3. After build, you can find the plugin in "[project root]/build/libs"
>>>    with file name "plugin-UPnP2-1.0-SNAPSHOT-all.jar".
>>>
>>> Thanks,
>>> Xiaoyu

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to