The EventCounter class has already been removed in HADOOP-17524.

And on the filters, by default log4j1.2 bridge has log4j1 filter support,
but as said above, maybe it is not fully functional if you have some
advanced usage. So mind providing more information about how we use filters
in Hadoop?

Thanks.

Arpit Agarwal <aagar...@cloudera.com.invalid>于2022年1月21日 周五00:44写道:

> Hi Duo,
>
> Thank you for starting this discussion. Log4j1.2 bridge seems like a
> practical short-term solution. However the bridge will silently affect
> applications that add appenders or filters. NameNode audit logger and
> metrics come to mind. There may be others.
>
> Thanks,
> Arpit
>
>
> > On Jan 20, 2022, at 5:55 AM, Duo Zhang <zhang...@apache.org> wrote:
> >
> > There are 3 new CVEs for log4j1 reported recently[1][2][3]. So I think it
> > is time to speed up the migration to log4j2 work[4] now.
> >
> > You can see the discussion on the jira issue[4], our goal is to fully
> > migrate to log4j2 and the current most blocking issue is lack of the
> > "log4j.rootLogger=INFO,Console" grammer support for log4j2. I've already
> > started a discussion thread on the log4j dev mailing list[5] and the
> result
> > is optimistic and I've filed an issue for log4j2[6], but I do not think
> it
> > could be addressed and released soon. If we want to fully migrate to
> > log4j2, then either we introduce new environment variables or split the
> old
> > HADOOP_ROOT_LOGGER variable in the startup scripts. And considering the
> > complexity of our current startup scripts, the work is not easy and it
> will
> > also break lots of other hadoop deployment systems if they do not use our
> > startup scripts...
> >
> > So after reconsidering the current situation, I prefer we use the
> log4j1.2
> > bridge to remove the log4j1 dependency first, and once LOG4J2-3341 is
> > addressed and released, we start to fully migrate to log4j2. Of course we
> > have other problems for log4j1.2 bridge too, as we have TaskLogAppender,
> > ContainerLogAppender and ContainerRollingLogAppender which inherit
> > FileAppender and RollingFileAppender in log4j1, which are not part of the
> > log4j1.2 bridge. But anyway, at least we could just copy the source code
> to
> > hadoop as we have WriteAppender in log4j1.2 bridge, and these two classes
> > do not have related CVEs.
> >
> > Thoughts? For me I would like us to make a new 3.4.x release line to
> remove
> > the log4j1 dependencies ASAP.
> >
> > Thanks.
> >
> > 1. https://nvd.nist.gov/vuln/detail/CVE-2022-23302
> > 2. https://nvd.nist.gov/vuln/detail/CVE-2022-23305
> > 3. https://nvd.nist.gov/vuln/detail/CVE-2022-23307
> > 4. https://issues.apache.org/jira/browse/HADOOP-16206
> > 5. https://lists.apache.org/thread/gvfb3jkg6t11cyds4jmpo7lrswmx28w3
> > 6. https://issues.apache.org/jira/browse/LOG4J2-3341
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
>
>

Reply via email to