You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by "Piotr P. Karwasz" <pi...@gmail.com> on 2022/05/03 13:38:06 UTC
Log4j 3.x features
Hi everyone,
This topic has been discussed several times, but the list of features that
need to be in version 3.0 is still fuzzy to me. From what I gathered
version 3.0 requires:
1. JPMS support with non-automatic modules. This seems to be done for
`log4j-api`, `log4j-plugins` and partially for `log4j-core`. The remaining
modules need to be converted and I think there are still some classes if
`log4j-api`, `log4j-plugins` and `log4j-core` that we can move to private
packages. For example all the implementations of `PropertySource` in
`log4j-api` do not need to be exported.
2. A DI system, which is certainly ready. However there are still places in
the code where it is not used. For example the managers are still directly
instantiated by the appenders, as well as some `log4j-1.2-api` builders
that require constructor parameters.
3. The properties enhancement (
https://cwiki.apache.org/confluence/display/LOGGING/Properties+Enhancement)
proposed by Ralph. Personally I would like a `log4j-api` jar common to
multiple web applications to be able to correctly detect a per-webapp
`log4j2.configurationFile` property.
4. We could profit from the major version change to move some things
around: for example do we really need three different file appenders? I
think that from a use perspective a single `FileAppender` with three
different file managers would be more intuitive.
Piotr
Re: Log4j 3.x features
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, May 18, 2022 at 5:37 PM Ralph Goers <ra...@dslextreme.com> wrote:
>
> I don’t really care what doc format the manual uses, so long as they are all the
> same and it is easy to update the manual outside of a release.
+1
Gary
>
> Ralph
>
> > On May 18, 2022, at 4:15 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
> >
> > 5. Manual is migrated from Markdown and XDOC to AsciiDoc – plus, 2 Markdown
> > files, sadly.
> >
> > On Tue, May 3, 2022 at 3:38 PM Piotr P. Karwasz <pi...@gmail.com>
> > wrote:
> >
> >> Hi everyone,
> >>
> >> This topic has been discussed several times, but the list of features that
> >> need to be in version 3.0 is still fuzzy to me. From what I gathered
> >> version 3.0 requires:
> >>
> >> 1. JPMS support with non-automatic modules. This seems to be done for
> >> `log4j-api`, `log4j-plugins` and partially for `log4j-core`. The remaining
> >> modules need to be converted and I think there are still some classes if
> >> `log4j-api`, `log4j-plugins` and `log4j-core` that we can move to private
> >> packages. For example all the implementations of `PropertySource` in
> >> `log4j-api` do not need to be exported.
> >>
> >> 2. A DI system, which is certainly ready. However there are still places in
> >> the code where it is not used. For example the managers are still directly
> >> instantiated by the appenders, as well as some `log4j-1.2-api` builders
> >> that require constructor parameters.
> >>
> >> 3. The properties enhancement (
> >> https://cwiki.apache.org/confluence/display/LOGGING/Properties+Enhancement
> >> )
> >> proposed by Ralph. Personally I would like a `log4j-api` jar common to
> >> multiple web applications to be able to correctly detect a per-webapp
> >> `log4j2.configurationFile` property.
> >>
> >> 4. We could profit from the major version change to move some things
> >> around: for example do we really need three different file appenders? I
> >> think that from a use perspective a single `FileAppender` with three
> >> different file managers would be more intuitive.
> >>
> >> Piotr
> >>
>
Re: Log4j 3.x features
Posted by Ralph Goers <ra...@dslextreme.com>.
I don’t really care what doc format the manual uses, so long as they are all the
same and it is easy to update the manual outside of a release.
Ralph
> On May 18, 2022, at 4:15 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>
> 5. Manual is migrated from Markdown and XDOC to AsciiDoc – plus, 2 Markdown
> files, sadly.
>
> On Tue, May 3, 2022 at 3:38 PM Piotr P. Karwasz <pi...@gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> This topic has been discussed several times, but the list of features that
>> need to be in version 3.0 is still fuzzy to me. From what I gathered
>> version 3.0 requires:
>>
>> 1. JPMS support with non-automatic modules. This seems to be done for
>> `log4j-api`, `log4j-plugins` and partially for `log4j-core`. The remaining
>> modules need to be converted and I think there are still some classes if
>> `log4j-api`, `log4j-plugins` and `log4j-core` that we can move to private
>> packages. For example all the implementations of `PropertySource` in
>> `log4j-api` do not need to be exported.
>>
>> 2. A DI system, which is certainly ready. However there are still places in
>> the code where it is not used. For example the managers are still directly
>> instantiated by the appenders, as well as some `log4j-1.2-api` builders
>> that require constructor parameters.
>>
>> 3. The properties enhancement (
>> https://cwiki.apache.org/confluence/display/LOGGING/Properties+Enhancement
>> )
>> proposed by Ralph. Personally I would like a `log4j-api` jar common to
>> multiple web applications to be able to correctly detect a per-webapp
>> `log4j2.configurationFile` property.
>>
>> 4. We could profit from the major version change to move some things
>> around: for example do we really need three different file appenders? I
>> think that from a use perspective a single `FileAppender` with three
>> different file managers would be more intuitive.
>>
>> Piotr
>>
Re: Log4j 3.x features
Posted by Volkan Yazıcı <vo...@yazi.ci>.
5. Manual is migrated from Markdown and XDOC to AsciiDoc – plus, 2 Markdown
files, sadly.
On Tue, May 3, 2022 at 3:38 PM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi everyone,
>
> This topic has been discussed several times, but the list of features that
> need to be in version 3.0 is still fuzzy to me. From what I gathered
> version 3.0 requires:
>
> 1. JPMS support with non-automatic modules. This seems to be done for
> `log4j-api`, `log4j-plugins` and partially for `log4j-core`. The remaining
> modules need to be converted and I think there are still some classes if
> `log4j-api`, `log4j-plugins` and `log4j-core` that we can move to private
> packages. For example all the implementations of `PropertySource` in
> `log4j-api` do not need to be exported.
>
> 2. A DI system, which is certainly ready. However there are still places in
> the code where it is not used. For example the managers are still directly
> instantiated by the appenders, as well as some `log4j-1.2-api` builders
> that require constructor parameters.
>
> 3. The properties enhancement (
> https://cwiki.apache.org/confluence/display/LOGGING/Properties+Enhancement
> )
> proposed by Ralph. Personally I would like a `log4j-api` jar common to
> multiple web applications to be able to correctly detect a per-webapp
> `log4j2.configurationFile` property.
>
> 4. We could profit from the major version change to move some things
> around: for example do we really need three different file appenders? I
> think that from a use perspective a single `FileAppender` with three
> different file managers would be more intuitive.
>
> Piotr
>
Re: Log4j 3.x features
Posted by Matt Sicker <bo...@gmail.com>.
On the compatibility front, it would be useful to figure out which parts of core are expected to remain compatible. Different plugin types will likely have different expectations of compatibility.
—
Matt Sicker
> On May 3, 2022, at 10:11, Gary Gregory <ga...@gmail.com> wrote:
>
> 5. Define the binary compatibility requirements.
>
> Gary
>
> On Tue, May 3, 2022, 09:38 Piotr P. Karwasz <pi...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> This topic has been discussed several times, but the list of features that
>> need to be in version 3.0 is still fuzzy to me. From what I gathered
>> version 3.0 requires:
>>
>> 1. JPMS support with non-automatic modules. This seems to be done for
>> `log4j-api`, `log4j-plugins` and partially for `log4j-core`. The remaining
>> modules need to be converted and I think there are still some classes if
>> `log4j-api`, `log4j-plugins` and `log4j-core` that we can move to private
>> packages. For example all the implementations of `PropertySource` in
>> `log4j-api` do not need to be exported.
>>
>> 2. A DI system, which is certainly ready. However there are still places in
>> the code where it is not used. For example the managers are still directly
>> instantiated by the appenders, as well as some `log4j-1.2-api` builders
>> that require constructor parameters.
>>
>> 3. The properties enhancement (
>> https://cwiki.apache.org/confluence/display/LOGGING/Properties+Enhancement
>> )
>> proposed by Ralph. Personally I would like a `log4j-api` jar common to
>> multiple web applications to be able to correctly detect a per-webapp
>> `log4j2.configurationFile` property.
>>
>> 4. We could profit from the major version change to move some things
>> around: for example do we really need three different file appenders? I
>> think that from a use perspective a single `FileAppender` with three
>> different file managers would be more intuitive.
>>
>> Piotr
>>
Re: Log4j 3.x features
Posted by Gary Gregory <ga...@gmail.com>.
5. Define the binary compatibility requirements.
Gary
On Tue, May 3, 2022, 09:38 Piotr P. Karwasz <pi...@gmail.com> wrote:
> Hi everyone,
>
> This topic has been discussed several times, but the list of features that
> need to be in version 3.0 is still fuzzy to me. From what I gathered
> version 3.0 requires:
>
> 1. JPMS support with non-automatic modules. This seems to be done for
> `log4j-api`, `log4j-plugins` and partially for `log4j-core`. The remaining
> modules need to be converted and I think there are still some classes if
> `log4j-api`, `log4j-plugins` and `log4j-core` that we can move to private
> packages. For example all the implementations of `PropertySource` in
> `log4j-api` do not need to be exported.
>
> 2. A DI system, which is certainly ready. However there are still places in
> the code where it is not used. For example the managers are still directly
> instantiated by the appenders, as well as some `log4j-1.2-api` builders
> that require constructor parameters.
>
> 3. The properties enhancement (
> https://cwiki.apache.org/confluence/display/LOGGING/Properties+Enhancement
> )
> proposed by Ralph. Personally I would like a `log4j-api` jar common to
> multiple web applications to be able to correctly detect a per-webapp
> `log4j2.configurationFile` property.
>
> 4. We could profit from the major version change to move some things
> around: for example do we really need three different file appenders? I
> think that from a use perspective a single `FileAppender` with three
> different file managers would be more intuitive.
>
> Piotr
>