Suppressing "development" warning

[Valentin Kulichenko]

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

[Dmitriy Setrakyan-2]

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 <
[hidden email]> 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
>

[Valentin Kulichenko]

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 <[hidden email]> 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 <
> [hidden email]> 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
> >
>

[dsetrakyan]

Sounds good, markers should work.

On Wed, Dec 20, 2017 at 1:00 PM, Valentin Kulichenko <
[hidden email]> 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 <[hidden email]> 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 <
> > [hidden email]> 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
> > >
> >
>

[Valentin Kulichenko]

Ticket created: https://issues.apache.org/jira/browse/IGNITE-7284

-Val

On Wed, Dec 20, 2017 at 6:12 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> Sounds good, markers should work.
>
> On Wed, Dec 20, 2017 at 1:00 PM, Valentin Kulichenko <
> [hidden email]> 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 <[hidden email]>
> 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 <
> > > [hidden email]> 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
> > > >
> > >
> >
>