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 > > >
