You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Volkan Yazıcı <vo...@gmail.com> on 2021/01/29 15:53:31 UTC
Renaming log4j2.asyncLoggerThreadNameStrategy to log4j2.threadNameStrategy
(Was: [jira] LOG4J2-3009)
Triggered by Carter's remark... Shall we
rename log4j2.asyncLoggerThreadNameStrategy to log4j2.threadNameStrategy
and display a warning if the deprecated one is defined? Are there more of
such properties?
On Fri, Jan 29, 2021 at 4:44 PM Carter Kozak (Jira) <ji...@apache.org> wrote:
> The {{log4j2.asyncLoggerThreadNameStrategy}} may be set to {{UNCACHED}}
> to override this default on all systems. It may be set in a
> log4j2.component.properties file, or via a jvm system property.
> It's a tad odd that these are described as properties for async logging,
> in reality they're more closely associated with gc-logging, and don't
> really relate to asynchronous features. Likely a historical artifact.
> Docs:
>
> https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties
> https://logging.apache.org/log4j/2.x/manual/async.html#SysPropsAllAsync
>
Re: Renaming log4j2.asyncLoggerThreadNameStrategy to
log4j2.threadNameStrategy (Was: [jira] LOG4J2-3009)
Posted by Volkan Yazıcı <vo...@gmail.com>.
Allright. Created LOG4J2-3011
<https://issues.apache.org/jira/browse/LOG4J2-3011>: "Support aliases in
PropertiesUtil to ease renaming deprecated properties with new ones"
On Fri, Jan 29, 2021 at 6:20 PM Matt Sicker <bo...@gmail.com> wrote:
> Plugins have aliases via the @PluginAlias annotation, though I don't
> think there's an equivalent feature for properties yet. This sounds
> like something that could potentially be improved in PropertiesUtil.
>
> On Fri, 29 Jan 2021 at 10:24, Carter Kozak <ck...@ckozak.net> wrote:
> >
> > Oh hmm, it looks like things are a little more manual than I'd thought!
> PropertiesUtil.Util.tokenize and PropertySource.getNormalForm massage the
> data, but I had thought there were direct string replacements for a few
> property names that I can't seem to find (perhaps I imagined them?). Given
> we already do some key-manipulation, I think it's a reasonable place to
> define mappings from old to new key names.
> >
> > On Fri, Jan 29, 2021, at 11:10, Volkan Yazıcı wrote:
> > > "a framework in place to migrate property names without disrupting
> users"?
> > > That is totally new to me. Any pointers?
> > >
> > > On Fri, Jan 29, 2021 at 5:01 PM Carter Kozak <ck...@ckozak.net>
> wrote:
> > >
> > > > We have a framework in place to migrate property names without
> disrupting
> > > > users, I would support using a default name that aligns more closely
> with
> > > > the feature. I don't think we warn when deprecated names are used,
> I'd
> > > > expect that could become noisy, and we want folks to upgrade without
> > > > worrying about scaring their users with warnings from us.
> > > >
> > > > For what it's worth, the feature is entirely unnecessary beyond java
> 8
> > > > since the getName() allocations were removed.
> > > >
> > > > Carter
> > > >
> > > > On Fri, Jan 29, 2021, at 10:53, Volkan Yazıcı wrote:
> > > > > Triggered by Carter's remark... Shall we
> > > > > rename log4j2.asyncLoggerThreadNameStrategy to
> log4j2.threadNameStrategy
> > > > > and display a warning if the deprecated one is defined? Are there
> more of
> > > > > such properties?
> > > > >
> > > > > On Fri, Jan 29, 2021 at 4:44 PM Carter Kozak (Jira) <
> jira@apache.org>
> > > > wrote:
> > > > >
> > > > > > The {{log4j2.asyncLoggerThreadNameStrategy}} may be set to
> {{UNCACHED}}
> > > > > > to override this default on all systems. It may be set in a
> > > > > > log4j2.component.properties file, or via a jvm system property.
> > > > > > It's a tad odd that these are described as properties for async
> > > > logging,
> > > > > > in reality they're more closely associated with gc-logging, and
> don't
> > > > > > really relate to asynchronous features. Likely a historical
> artifact.
> > > > > > Docs:
> > > > > >
> > > > > >
> > > >
> https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties
> > > > > >
> > > >
> https://logging.apache.org/log4j/2.x/manual/async.html#SysPropsAllAsync
> > > > > >
> > > > >
> > > >
> > >
>
Re: Renaming log4j2.asyncLoggerThreadNameStrategy to
log4j2.threadNameStrategy (Was: [jira] LOG4J2-3009)
Posted by Matt Sicker <bo...@gmail.com>.
Plugins have aliases via the @PluginAlias annotation, though I don't
think there's an equivalent feature for properties yet. This sounds
like something that could potentially be improved in PropertiesUtil.
On Fri, 29 Jan 2021 at 10:24, Carter Kozak <ck...@ckozak.net> wrote:
>
> Oh hmm, it looks like things are a little more manual than I'd thought! PropertiesUtil.Util.tokenize and PropertySource.getNormalForm massage the data, but I had thought there were direct string replacements for a few property names that I can't seem to find (perhaps I imagined them?). Given we already do some key-manipulation, I think it's a reasonable place to define mappings from old to new key names.
>
> On Fri, Jan 29, 2021, at 11:10, Volkan Yazıcı wrote:
> > "a framework in place to migrate property names without disrupting users"?
> > That is totally new to me. Any pointers?
> >
> > On Fri, Jan 29, 2021 at 5:01 PM Carter Kozak <ck...@ckozak.net> wrote:
> >
> > > We have a framework in place to migrate property names without disrupting
> > > users, I would support using a default name that aligns more closely with
> > > the feature. I don't think we warn when deprecated names are used, I'd
> > > expect that could become noisy, and we want folks to upgrade without
> > > worrying about scaring their users with warnings from us.
> > >
> > > For what it's worth, the feature is entirely unnecessary beyond java 8
> > > since the getName() allocations were removed.
> > >
> > > Carter
> > >
> > > On Fri, Jan 29, 2021, at 10:53, Volkan Yazıcı wrote:
> > > > Triggered by Carter's remark... Shall we
> > > > rename log4j2.asyncLoggerThreadNameStrategy to log4j2.threadNameStrategy
> > > > and display a warning if the deprecated one is defined? Are there more of
> > > > such properties?
> > > >
> > > > On Fri, Jan 29, 2021 at 4:44 PM Carter Kozak (Jira) <ji...@apache.org>
> > > wrote:
> > > >
> > > > > The {{log4j2.asyncLoggerThreadNameStrategy}} may be set to {{UNCACHED}}
> > > > > to override this default on all systems. It may be set in a
> > > > > log4j2.component.properties file, or via a jvm system property.
> > > > > It's a tad odd that these are described as properties for async
> > > logging,
> > > > > in reality they're more closely associated with gc-logging, and don't
> > > > > really relate to asynchronous features. Likely a historical artifact.
> > > > > Docs:
> > > > >
> > > > >
> > > https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties
> > > > >
> > > https://logging.apache.org/log4j/2.x/manual/async.html#SysPropsAllAsync
> > > > >
> > > >
> > >
> >
Re: Renaming log4j2.asyncLoggerThreadNameStrategy to log4j2.threadNameStrategy (Was: [jira] LOG4J2-3009)
Posted by Carter Kozak <ck...@ckozak.net>.
Oh hmm, it looks like things are a little more manual than I'd thought! PropertiesUtil.Util.tokenize and PropertySource.getNormalForm massage the data, but I had thought there were direct string replacements for a few property names that I can't seem to find (perhaps I imagined them?). Given we already do some key-manipulation, I think it's a reasonable place to define mappings from old to new key names.
On Fri, Jan 29, 2021, at 11:10, Volkan Yazıcı wrote:
> "a framework in place to migrate property names without disrupting users"?
> That is totally new to me. Any pointers?
>
> On Fri, Jan 29, 2021 at 5:01 PM Carter Kozak <ck...@ckozak.net> wrote:
>
> > We have a framework in place to migrate property names without disrupting
> > users, I would support using a default name that aligns more closely with
> > the feature. I don't think we warn when deprecated names are used, I'd
> > expect that could become noisy, and we want folks to upgrade without
> > worrying about scaring their users with warnings from us.
> >
> > For what it's worth, the feature is entirely unnecessary beyond java 8
> > since the getName() allocations were removed.
> >
> > Carter
> >
> > On Fri, Jan 29, 2021, at 10:53, Volkan Yazıcı wrote:
> > > Triggered by Carter's remark... Shall we
> > > rename log4j2.asyncLoggerThreadNameStrategy to log4j2.threadNameStrategy
> > > and display a warning if the deprecated one is defined? Are there more of
> > > such properties?
> > >
> > > On Fri, Jan 29, 2021 at 4:44 PM Carter Kozak (Jira) <ji...@apache.org>
> > wrote:
> > >
> > > > The {{log4j2.asyncLoggerThreadNameStrategy}} may be set to {{UNCACHED}}
> > > > to override this default on all systems. It may be set in a
> > > > log4j2.component.properties file, or via a jvm system property.
> > > > It's a tad odd that these are described as properties for async
> > logging,
> > > > in reality they're more closely associated with gc-logging, and don't
> > > > really relate to asynchronous features. Likely a historical artifact.
> > > > Docs:
> > > >
> > > >
> > https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties
> > > >
> > https://logging.apache.org/log4j/2.x/manual/async.html#SysPropsAllAsync
> > > >
> > >
> >
>
Re: Renaming log4j2.asyncLoggerThreadNameStrategy to
log4j2.threadNameStrategy (Was: [jira] LOG4J2-3009)
Posted by Volkan Yazıcı <vo...@gmail.com>.
"a framework in place to migrate property names without disrupting users"?
That is totally new to me. Any pointers?
On Fri, Jan 29, 2021 at 5:01 PM Carter Kozak <ck...@ckozak.net> wrote:
> We have a framework in place to migrate property names without disrupting
> users, I would support using a default name that aligns more closely with
> the feature. I don't think we warn when deprecated names are used, I'd
> expect that could become noisy, and we want folks to upgrade without
> worrying about scaring their users with warnings from us.
>
> For what it's worth, the feature is entirely unnecessary beyond java 8
> since the getName() allocations were removed.
>
> Carter
>
> On Fri, Jan 29, 2021, at 10:53, Volkan Yazıcı wrote:
> > Triggered by Carter's remark... Shall we
> > rename log4j2.asyncLoggerThreadNameStrategy to log4j2.threadNameStrategy
> > and display a warning if the deprecated one is defined? Are there more of
> > such properties?
> >
> > On Fri, Jan 29, 2021 at 4:44 PM Carter Kozak (Jira) <ji...@apache.org>
> wrote:
> >
> > > The {{log4j2.asyncLoggerThreadNameStrategy}} may be set to {{UNCACHED}}
> > > to override this default on all systems. It may be set in a
> > > log4j2.component.properties file, or via a jvm system property.
> > > It's a tad odd that these are described as properties for async
> logging,
> > > in reality they're more closely associated with gc-logging, and don't
> > > really relate to asynchronous features. Likely a historical artifact.
> > > Docs:
> > >
> > >
> https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties
> > >
> https://logging.apache.org/log4j/2.x/manual/async.html#SysPropsAllAsync
> > >
> >
>
Re: Renaming log4j2.asyncLoggerThreadNameStrategy to log4j2.threadNameStrategy (Was: [jira] LOG4J2-3009)
Posted by Carter Kozak <ck...@ckozak.net>.
We have a framework in place to migrate property names without disrupting users, I would support using a default name that aligns more closely with the feature. I don't think we warn when deprecated names are used, I'd expect that could become noisy, and we want folks to upgrade without worrying about scaring their users with warnings from us.
For what it's worth, the feature is entirely unnecessary beyond java 8 since the getName() allocations were removed.
Carter
On Fri, Jan 29, 2021, at 10:53, Volkan Yazıcı wrote:
> Triggered by Carter's remark... Shall we
> rename log4j2.asyncLoggerThreadNameStrategy to log4j2.threadNameStrategy
> and display a warning if the deprecated one is defined? Are there more of
> such properties?
>
> On Fri, Jan 29, 2021 at 4:44 PM Carter Kozak (Jira) <ji...@apache.org> wrote:
>
> > The {{log4j2.asyncLoggerThreadNameStrategy}} may be set to {{UNCACHED}}
> > to override this default on all systems. It may be set in a
> > log4j2.component.properties file, or via a jvm system property.
> > It's a tad odd that these are described as properties for async logging,
> > in reality they're more closely associated with gc-logging, and don't
> > really relate to asynchronous features. Likely a historical artifact.
> > Docs:
> >
> > https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties
> > https://logging.apache.org/log4j/2.x/manual/async.html#SysPropsAllAsync
> >
>