I tried this feature in HBase but got some problems.
I've already filed LOG4J2-3394 to describe the problems.
PTAL. Thanks.
张铎(Duo Zhang) 于2022年1月17日周一 12:30写道:
> I spent some time reading the code of log4j2-core, and posted what I have
> learned so far on the jira issue.
>
> I could give it a
I spent some time reading the code of log4j2-core, and posted what I have
learned so far on the jira issue.
I could give it a try but I need a mentor.
Appreciate if someone in the community could help here.
Thanks.
张铎(Duo Zhang) 于2022年1月15日周六 11:54写道:
> Filed https://issues.apache.org/jira/br
Filed https://issues.apache.org/jira/browse/LOG4J2-3341.
Gary Gregory 于2022年1月11日周二 21:21写道:
> On Tue, Jan 11, 2022 at 8:20 AM 张铎(Duo Zhang)
> wrote:
>
> > So we could open an issue for this feature then? As we have already
> started
> > to discuss the implementation :)
> >
>
> Yes, that sounds
On Tue, Jan 11, 2022 at 8:20 AM 张铎(Duo Zhang) wrote:
> So we could open an issue for this feature then? As we have already started
> to discuss the implementation :)
>
Yes, that sounds like a good idea. Feel free to go ahead :-)
Gary
>
> Thanks~
>
> Volkan Yazıcı 于2022年1月11日周二 19:42写道:
>
> >
So we could open an issue for this feature then? As we have already started
to discuss the implementation :)
Thanks~
Volkan Yazıcı 于2022年1月11日周二 19:42写道:
> Giving it a one more try:
>
>
>${sys:hadoop.root.logger}
>
>hadoop.root.logger.level
>hadoop.root.logger.appender
Giving it a one more try:
${sys:hadoop.root.logger}
hadoop.root.logger.level
hadoop.root.logger.appender
On Mon, Jan 10, 2022 at 3:54 PM Ralph Goers
wrote:
> Yeah, that syntax is better although it doesn’t solve the multiple
> appender refs case either.
>
> LoggerConf
Yeah, that syntax is better although it doesn’t solve the multiple appender
refs case either.
LoggerConfig accepts a List so it would seem that if we modify
LoggerConfig
to add another attribute that is a string that creates an AppenderRef for each
item then
one could do
Ralph
> On Jan
I am curious if shall we adopt a more generic approach to extraction:
${sys:hadoop.root.logger}
hadoop.root.logger.level
hadoop.root.logger.appender
On Mon, Jan 10, 2022 at 5:53 AM Ralph Goers
wrote:
> OK, I had a suspicion the reason for needing this was something li
Thanks Ralph, what you proposed is fine by me.
I'm not very familiar with the implementations inside log4j2 so in the
above example I just want to make clear that enhancing property parsing
could also be a direction for solve the problem.
Ralph Goers 于2022年1月10日周一 12:53写道:
> OK, I had a suspici
Ralph Goers schrieb am So., 9. Jan. 2022,
20:53:
> StrSubstitutor is already complicated
Having just reviewed that function and its looping caller, I would have to
agree
OK, I had a suspicion the reason for needing this was something like that.
The syntax you propose below would require modifying PropertiesUtil, the
Property
plugin and StrSubstitutor to support arrays. I don’t think I’d want to go down
that path.
StrSubstitutor is already complicated and the id
Thank you for the reply.
And yes, it is not only for the root logger, we have tons of different
loggers in hadoop, as hadoop is constructed with several different projects
actually, and they are developed by different groups of people...
And on splitting the config in shell, actually this is exac
We already support this with two variables. But if they only want to pass one
then we have two options:
1. Modify PropertiesConfiguration to support a new element that allows a Level
and AppenderRef which then gets split internally.
2. Create a Lookup that extracts the relevant portion of the dat
I think it is reasonable to say we can support this through 2 instead of 1
variable.
Duo?
Gary
On Sun, Jan 9, 2022, 16:24 Ralph Goers wrote:
> I’m looking at this and have a couple of concerns. The script has
>
>
> HADOOP_ROOT_LOGGER=${HADOOP_ROOT_LOGGER:-${HADOOP_LOGLEVEL},console}
>
> HADO
I agree, let's make it easier for Hadoop :-)
Gary
On Sun, Jan 9, 2022, 15:54 Matt Sicker wrote:
> This sounds fairly reasonable, though I haven’t looked at implementation
> details. We should make a Jira ticket to track the change. Otherwise, I
> think it’s a good idea to support the syntax.
>
I’m looking at this and have a couple of concerns. The script has
HADOOP_ROOT_LOGGER=${HADOOP_ROOT_LOGGER:-${HADOOP_LOGLEVEL},console}
HADOOP_DAEMON_ROOT_LOGGER=${HADOOP_DAEMON_ROOT_LOGGER:-${HADOOP_LOGLEVEL},RFA}
HADOOP_SECURITY_LOGGER=${HADOOP_SECURITY_LOGGER:-INFO,NullAppender}
So it s
This sounds fairly reasonable, though I haven’t looked at implementation
details. We should make a Jira ticket to track the change. Otherwise, I think
it’s a good idea to support the syntax.
—
Matt Sicker
> On Jan 9, 2022, at 09:02, 张铎 wrote:
>
> I brought this up in the incubator mailing li
I brought this up in the incubator mailing list, and was suggested to
report directly to the log4j community.
https://issues.apache.org/jira/browse/HADOOP-16206
In hadoop we started to try migrating to log4j2 long ago, but it is not
easy. For now, one of the most blocker issues is the lack of sup
18 matches
Mail list logo