Ticket created: https://issues.apache.org/jira/browse/IGNITE-7284
-Val On Wed, Dec 20, 2017 at 6:12 PM, Dmitriy Setrakyan <[email protected]> wrote: > Sounds good, markers should work. > > On Wed, Dec 20, 2017 at 1:00 PM, Valentin Kulichenko < > [email protected]> wrote: > > > Dmitry, > > > > WARNING_DEV_ONLY actually sounds like a custom *level* name. > Unfortunately, > > this is not possible because most of the loggers do not support this. > > > > I also don't like having special category for such warnings at least for > > these reasons: > > - Category does not defines severity of log statement, it defines its > > origin (component, piece of code, class, ...). > > - Category can have different level statements. WARNING_DEV_ONLY category > > will actually allow ERROR or INFO statements. > > - Overall, this approach is not in line with typical logger architecture > > and therefore can easily confuse our users. > > > > Modern loggers tend to use markers for such tasks [1]. Marker is similar > to > > level, but it's optional and application can create as many markers as > > needed, and then use them for log filtering. I propose to do the > following: > > > > - Add marker support to IgniteLogger interface. > > - Introduce marker for dev only warnings. > > - Loggers that support markers will use them directly (Log4J 2.x, > > Logback, SLF). > > - For other loggers just add a system property to enable/disable dev > > only warnings. Such loggers (e.g. JUL) are not frequently used in > large > > production systems anyway, so I think this solution is enough for > them. > > Additionally, we can also add option to dynamically enable/disable dev > > only > > warnings via MBean. > > > > [1] > > https://stackoverflow.com/questions/16813032/what-are- > > markers-in-java-logging-frameworks-and-what-is-a-reason-to-use-them > > > > > > Thoughts? > > > > -Val > > > > On Mon, Dec 11, 2017 at 4:21 PM, Dmitriy Setrakyan <[email protected]> > wrote: > > > > > I actually like the new WARNING_DEV_ONLY category for logging. If we > > > provide it in the default logger configuration, then users will not > have > > to > > > do anything extra unless they want to change it. Moreover, if it is a > > > category, then it can be turned on and off using standard logger > > > configuration. > > > > > > D. > > > > > > On Mon, Dec 11, 2017 at 3:28 PM, Valentin Kulichenko < > > > [email protected]> wrote: > > > > > > > Igniters, > > > > > > > > We have bunch of warnings in the product which are useful only during > > > > development. One of the examples of is "Class ... cannot be > serialized > > > > using BinaryMarshaller because it either implements Externalizable > ...' > > > > warning - it is very useful when one is writing code as it warns > about > > > > possible mistakes and suggest how to fix them, but once > implementation > > is > > > > done, it is meaningless. Moreover, in production environments all > > > warnings > > > > and errors are often automatically monitored, so this introduces an > > issue > > > > of false positive alerts generated by this kind of warnings. > > > > > > > > I see two possible solutions for this: > > > > - Add 'devOnly' flag to IgniteLogger#warning method and ignore them > if > > > > special system property is set. > > > > - Introduce special logger category for such warnings so that user > can > > > > control if they are logged or not. > > > > > > > > I think my vote is for the first option as it's more straightforward > > and > > > > doesn't require any additional configuration from a user. > > > > > > > > Thoughts? > > > > > > > > -Val > > > > > > > > > >
