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 2023/06/22 08:34:31 UTC
Renaming `log4j-core`
Hi all,
I think one of the main problems preventing Log4j API from being used
more wildly are naming problems and misinformation on many sites.
Personally I find the name `log4j-core` for our implementation quite
unfortunate: this is often interpreted as "core Log4j classes", which
suggests that all artifacts including `log4j-api` should be considered
as a unit.
I would profit from the major version bump to change it to
`log4j-impl` or `log4j-runtime`.
Similar changes have occurred in other projects. For example JAXB
changed it's implementation from `jaxb-impl`[1] to `jaxb-runtime`[2]
(and also the group id), during the jakartification process.
The Java EE Mail project used `javax.mail-api` for their API and
`javax.mail` for their implementation. Now they renamed their
implementation to `angus-mail`, which stresses the difference between
API and implementation more (although in this case Angus **is** the
only implementation available).
So, what do you think about renaming `log4j-core`?
Piotr
[1] https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-impl
[2] https://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-runtime
[3] https://mvnrepository.com/artifact/javax.mail/javax.mail-api
[4] https://mvnrepository.com/artifact/com.sun.mail/javax.mail
[5] https://mvnrepository.com/artifact/org.eclipse.angus/angus-mail
Re: Renaming `log4j-core`
Posted by Matt Sicker <ma...@musigma.org>.
Perhaps we can keep the artifact id but advertise the module as something besides “Log4j Core”? When introducing the hypothetical new name for the module, we can include a parenthetical “AKA Log4j Core” to clarify.
—
Matt Sicker
> On Jun 22, 2023, at 10:12, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Pretend for a moment that you work for a company that has lots of shared components that don’t always do everything correctly and publish artifacts that declare a dependency on log4j-core (Note: I do). If we change the name of log4j-core to something else then suddenly both an older version of log4j-core and the new artifact are going to be on the class path. The user will absolutely not know this until they start running their application and start to have weird problems. This is exactly why when Commons components change the artifact name they also require the package names to be changed. However, this still would not really help in our case as now both log4j 2.x and log4j 3.x would be present which would undoubtedly create a host of problems.
>
> Without having an easy and foolproof way to deal with that I would have to vote -1 on changing the artifact name.
>
> Note that all the examples of projects renaming do not have the same problems Log4j will when both are present on the class path.
>
> However, I am in favor of splitting the web site in two between the API and the implementation, possibly even giving some of the optional modules their own web site or at least breaking them more clearly into their own pages.
>
> Ralph
>
>> On Jun 22, 2023, at 1:34 AM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>>
>> Hi all,
>>
>> I think one of the main problems preventing Log4j API from being used
>> more wildly are naming problems and misinformation on many sites.
>>
>> Personally I find the name `log4j-core` for our implementation quite
>> unfortunate: this is often interpreted as "core Log4j classes", which
>> suggests that all artifacts including `log4j-api` should be considered
>> as a unit.
>>
>> I would profit from the major version bump to change it to
>> `log4j-impl` or `log4j-runtime`.
>>
>> Similar changes have occurred in other projects. For example JAXB
>> changed it's implementation from `jaxb-impl`[1] to `jaxb-runtime`[2]
>> (and also the group id), during the jakartification process.
>>
>> The Java EE Mail project used `javax.mail-api` for their API and
>> `javax.mail` for their implementation. Now they renamed their
>> implementation to `angus-mail`, which stresses the difference between
>> API and implementation more (although in this case Angus **is** the
>> only implementation available).
>>
>> So, what do you think about renaming `log4j-core`?
>>
>> Piotr
>>
>> [1] https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-impl
>> [2] https://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-runtime
>> [3] https://mvnrepository.com/artifact/javax.mail/javax.mail-api
>> [4] https://mvnrepository.com/artifact/com.sun.mail/javax.mail
>> [5] https://mvnrepository.com/artifact/org.eclipse.angus/angus-mail
>
Re: Renaming `log4j-core`
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Sun, 25 Jun 2023 at 00:23, Ralph Goers <ra...@dslextreme.com> wrote:
>
> The only thing I am aware of is a “relocation” - https://maven.apache.org/guides/mini/guide-relocation.html. This would mean continuing to publish log4j-core and have to reference the new artifact. However, I recall doing that was attempted to redirect log4j 1.x to reload4j and I don’t recall that being very successful.
I think the PMC didn't agree to relocate `log4j:log4j` to an external
artifact. Other artifacts like `slf4j-log4j12` have been relocated:
https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12
Piotr
Re: Renaming `log4j-core`
Posted by Ralph Goers <ra...@dslextreme.com>.
The only thing I am aware of is a “relocation” - https://maven.apache.org/guides/mini/guide-relocation.html. This would mean continuing to publish log4j-core and have to reference the new artifact. However, I recall doing that was attempted to redirect log4j 1.x to reload4j and I don’t recall that being very successful.
Ralph
> On Jun 24, 2023, at 1:00 PM, Tim Perry <ti...@gmail.com> wrote:
>
> Can we publish log4j-core so it spits out a deprecation warning and just
> pulls in log4j-impl or log4j-runtime or whatever? That might address
> Ralph's concern. If we can't avoid the issues Ralph describes, then I'd
> vote -1 too.
>
> On Thu, Jun 22, 2023 at 8:13 AM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> Pretend for a moment that you work for a company that has lots of shared
>> components that don’t always do everything correctly and publish artifacts
>> that declare a dependency on log4j-core (Note: I do). If we change the
>> name of log4j-core to something else then suddenly both an older version of
>> log4j-core and the new artifact are going to be on the class path. The user
>> will absolutely not know this until they start running their application
>> and start to have weird problems. This is exactly why when Commons
>> components change the artifact name they also require the package names to
>> be changed. However, this still would not really help in our case as now
>> both log4j 2.x and log4j 3.x would be present which would undoubtedly
>> create a host of problems.
>>
>> Without having an easy and foolproof way to deal with that I would have to
>> vote -1 on changing the artifact name.
>>
>> Note that all the examples of projects renaming do not have the same
>> problems Log4j will when both are present on the class path.
>>
>> However, I am in favor of splitting the web site in two between the API
>> and the implementation, possibly even giving some of the optional modules
>> their own web site or at least breaking them more clearly into their own
>> pages.
>>
>> Ralph
>>
>>> On Jun 22, 2023, at 1:34 AM, Piotr P. Karwasz <pi...@gmail.com>
>> wrote:
>>>
>>> Hi all,
>>>
>>> I think one of the main problems preventing Log4j API from being used
>>> more wildly are naming problems and misinformation on many sites.
>>>
>>> Personally I find the name `log4j-core` for our implementation quite
>>> unfortunate: this is often interpreted as "core Log4j classes", which
>>> suggests that all artifacts including `log4j-api` should be considered
>>> as a unit.
>>>
>>> I would profit from the major version bump to change it to
>>> `log4j-impl` or `log4j-runtime`.
>>>
>>> Similar changes have occurred in other projects. For example JAXB
>>> changed it's implementation from `jaxb-impl`[1] to `jaxb-runtime`[2]
>>> (and also the group id), during the jakartification process.
>>>
>>> The Java EE Mail project used `javax.mail-api` for their API and
>>> `javax.mail` for their implementation. Now they renamed their
>>> implementation to `angus-mail`, which stresses the difference between
>>> API and implementation more (although in this case Angus **is** the
>>> only implementation available).
>>>
>>> So, what do you think about renaming `log4j-core`?
>>>
>>> Piotr
>>>
>>> [1] https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-impl
>>> [2] https://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-runtime
>>> [3] https://mvnrepository.com/artifact/javax.mail/javax.mail-api
>>> [4] https://mvnrepository.com/artifact/com.sun.mail/javax.mail
>>> [5] https://mvnrepository.com/artifact/org.eclipse.angus/angus-mail
>>
>>
Re: Renaming `log4j-core`
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jun 26, 2023, at 2:57 PM, Tim Perry <ti...@gmail.com> wrote:
>
>
>
>> On Jun 26, 2023, at 1:38 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>>
>>
>>> On Jun 26, 2023, at 12:17 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>>>
>>> Hi Ralph,
>>>
>>> On Mon, 26 Jun 2023 at 20:33, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>> On Jun 25, 2023, at 11:32 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>>>>>
>>>>> Hi Tim,
>>>>>
>>>>>> On Sat, 24 Jun 2023 at 22:00, Tim Perry <ti...@gmail.com> wrote:
>>>>>>>
>>>>>>> Can we publish log4j-core so it spits out a deprecation warning and just
>>>>>>> pulls in log4j-impl or log4j-runtime or whatever?
>>>>>>
>>>>>> This is probably the best solution.
>>>>
>>>> How can it be implemented?
>>>
>>> We replace `log4j-core` with an empty JAR file with `log4j-impl` as dependency.
>>
>> I can’t say I am thrilled with this idea but I also can’t point to any concrete problems it would cause without testing
>
> It would need a class which prints a depreciation warning at startup as well. Preferably with directions to fix.
>
> I’m not thrilled by this, but at least it helps them along.
>
> Possibly better to stick with log4j-core
Yeah - I think it is better to fix the web site. Separate Log4j-API to its own site. Then see where we are.
Ralph
Re: Renaming `log4j-core`
Posted by Tim Perry <ti...@gmail.com>.
> On Jun 26, 2023, at 1:38 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>
>> On Jun 26, 2023, at 12:17 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>>
>> Hi Ralph,
>>
>> On Mon, 26 Jun 2023 at 20:33, Ralph Goers <ra...@dslextreme.com> wrote:
>>>> On Jun 25, 2023, at 11:32 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>>>>
>>>> Hi Tim,
>>>>
>>>>> On Sat, 24 Jun 2023 at 22:00, Tim Perry <ti...@gmail.com> wrote:
>>>>>>
>>>>>> Can we publish log4j-core so it spits out a deprecation warning and just
>>>>>> pulls in log4j-impl or log4j-runtime or whatever?
>>>>>
>>>>> This is probably the best solution.
>>>
>>> How can it be implemented?
>>
>> We replace `log4j-core` with an empty JAR file with `log4j-impl` as dependency.
>
> I can’t say I am thrilled with this idea but I also can’t point to any concrete problems it would cause without testing
It would need a class which prints a depreciation warning at startup as well. Preferably with directions to fix.
I’m not thrilled by this, but at least it helps them along.
Possibly better to stick with log4j-core
Re: Renaming `log4j-core`
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jun 26, 2023, at 12:17 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi Ralph,
>
> On Mon, 26 Jun 2023 at 20:33, Ralph Goers <ra...@dslextreme.com> wrote:
>>> On Jun 25, 2023, at 11:32 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>>>
>>> Hi Tim,
>>>
>>> On Sat, 24 Jun 2023 at 22:00, Tim Perry <ti...@gmail.com> wrote:
>>>>
>>>> Can we publish log4j-core so it spits out a deprecation warning and just
>>>> pulls in log4j-impl or log4j-runtime or whatever?
>>>
>>> This is probably the best solution.
>>
>> How can it be implemented?
>
> We replace `log4j-core` with an empty JAR file with `log4j-impl` as dependency.
I can’t say I am thrilled with this idea but I also can’t point to any concrete problems it would cause without testing.
>
>>> We could also consider adding other dependencies to `log4j-core` that
>>> were split into separate modules, like `log4j-smtp`.
>>
>> I’m not sure I understand what you are getting at here.
>
> My idea was to add as dependencies of `log4j-core` all the 3.x modules
> that were split off it. This way users would have the same
> `log4j-core` as in 2.x. I am however not convinced it could work,
> since 2.x optional dependencies would become non-optional deps.
I think that would be a horrible idea. It defeats the whole point of splitting them out.
Ralph
Re: Renaming `log4j-core`
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Mon, 26 Jun 2023 at 20:33, Ralph Goers <ra...@dslextreme.com> wrote:
> > On Jun 25, 2023, at 11:32 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
> >
> > Hi Tim,
> >
> > On Sat, 24 Jun 2023 at 22:00, Tim Perry <ti...@gmail.com> wrote:
> >>
> >> Can we publish log4j-core so it spits out a deprecation warning and just
> >> pulls in log4j-impl or log4j-runtime or whatever?
> >
> > This is probably the best solution.
>
> How can it be implemented?
We replace `log4j-core` with an empty JAR file with `log4j-impl` as dependency.
> > We could also consider adding other dependencies to `log4j-core` that
> > were split into separate modules, like `log4j-smtp`.
>
> I’m not sure I understand what you are getting at here.
My idea was to add as dependencies of `log4j-core` all the 3.x modules
that were split off it. This way users would have the same
`log4j-core` as in 2.x. I am however not convinced it could work,
since 2.x optional dependencies would become non-optional deps.
Piotr
Re: Renaming `log4j-core`
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jun 25, 2023, at 11:32 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi Tim,
>
> On Sat, 24 Jun 2023 at 22:00, Tim Perry <ti...@gmail.com> wrote:
>>
>> Can we publish log4j-core so it spits out a deprecation warning and just
>> pulls in log4j-impl or log4j-runtime or whatever?
>
> This is probably the best solution.
How can it be implemented?
> We could also consider adding other dependencies to `log4j-core` that
> were split into separate modules, like `log4j-smtp`.
I’m not sure I understand what you are getting at here.
Ralph
Re: Renaming `log4j-core`
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Tim,
On Sat, 24 Jun 2023 at 22:00, Tim Perry <ti...@gmail.com> wrote:
>
> Can we publish log4j-core so it spits out a deprecation warning and just
> pulls in log4j-impl or log4j-runtime or whatever?
This is probably the best solution.
We could also consider adding other dependencies to `log4j-core` that
were split into separate modules, like `log4j-smtp`.
Piotr
Re: Renaming `log4j-core`
Posted by Tim Perry <ti...@gmail.com>.
Can we publish log4j-core so it spits out a deprecation warning and just
pulls in log4j-impl or log4j-runtime or whatever? That might address
Ralph's concern. If we can't avoid the issues Ralph describes, then I'd
vote -1 too.
On Thu, Jun 22, 2023 at 8:13 AM Ralph Goers <ra...@dslextreme.com>
wrote:
> Pretend for a moment that you work for a company that has lots of shared
> components that don’t always do everything correctly and publish artifacts
> that declare a dependency on log4j-core (Note: I do). If we change the
> name of log4j-core to something else then suddenly both an older version of
> log4j-core and the new artifact are going to be on the class path. The user
> will absolutely not know this until they start running their application
> and start to have weird problems. This is exactly why when Commons
> components change the artifact name they also require the package names to
> be changed. However, this still would not really help in our case as now
> both log4j 2.x and log4j 3.x would be present which would undoubtedly
> create a host of problems.
>
> Without having an easy and foolproof way to deal with that I would have to
> vote -1 on changing the artifact name.
>
> Note that all the examples of projects renaming do not have the same
> problems Log4j will when both are present on the class path.
>
> However, I am in favor of splitting the web site in two between the API
> and the implementation, possibly even giving some of the optional modules
> their own web site or at least breaking them more clearly into their own
> pages.
>
> Ralph
>
> > On Jun 22, 2023, at 1:34 AM, Piotr P. Karwasz <pi...@gmail.com>
> wrote:
> >
> > Hi all,
> >
> > I think one of the main problems preventing Log4j API from being used
> > more wildly are naming problems and misinformation on many sites.
> >
> > Personally I find the name `log4j-core` for our implementation quite
> > unfortunate: this is often interpreted as "core Log4j classes", which
> > suggests that all artifacts including `log4j-api` should be considered
> > as a unit.
> >
> > I would profit from the major version bump to change it to
> > `log4j-impl` or `log4j-runtime`.
> >
> > Similar changes have occurred in other projects. For example JAXB
> > changed it's implementation from `jaxb-impl`[1] to `jaxb-runtime`[2]
> > (and also the group id), during the jakartification process.
> >
> > The Java EE Mail project used `javax.mail-api` for their API and
> > `javax.mail` for their implementation. Now they renamed their
> > implementation to `angus-mail`, which stresses the difference between
> > API and implementation more (although in this case Angus **is** the
> > only implementation available).
> >
> > So, what do you think about renaming `log4j-core`?
> >
> > Piotr
> >
> > [1] https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-impl
> > [2] https://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-runtime
> > [3] https://mvnrepository.com/artifact/javax.mail/javax.mail-api
> > [4] https://mvnrepository.com/artifact/com.sun.mail/javax.mail
> > [5] https://mvnrepository.com/artifact/org.eclipse.angus/angus-mail
>
>
Re: Renaming `log4j-core`
Posted by Ralph Goers <ra...@dslextreme.com>.
Pretend for a moment that you work for a company that has lots of shared components that don’t always do everything correctly and publish artifacts that declare a dependency on log4j-core (Note: I do). If we change the name of log4j-core to something else then suddenly both an older version of log4j-core and the new artifact are going to be on the class path. The user will absolutely not know this until they start running their application and start to have weird problems. This is exactly why when Commons components change the artifact name they also require the package names to be changed. However, this still would not really help in our case as now both log4j 2.x and log4j 3.x would be present which would undoubtedly create a host of problems.
Without having an easy and foolproof way to deal with that I would have to vote -1 on changing the artifact name.
Note that all the examples of projects renaming do not have the same problems Log4j will when both are present on the class path.
However, I am in favor of splitting the web site in two between the API and the implementation, possibly even giving some of the optional modules their own web site or at least breaking them more clearly into their own pages.
Ralph
> On Jun 22, 2023, at 1:34 AM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi all,
>
> I think one of the main problems preventing Log4j API from being used
> more wildly are naming problems and misinformation on many sites.
>
> Personally I find the name `log4j-core` for our implementation quite
> unfortunate: this is often interpreted as "core Log4j classes", which
> suggests that all artifacts including `log4j-api` should be considered
> as a unit.
>
> I would profit from the major version bump to change it to
> `log4j-impl` or `log4j-runtime`.
>
> Similar changes have occurred in other projects. For example JAXB
> changed it's implementation from `jaxb-impl`[1] to `jaxb-runtime`[2]
> (and also the group id), during the jakartification process.
>
> The Java EE Mail project used `javax.mail-api` for their API and
> `javax.mail` for their implementation. Now they renamed their
> implementation to `angus-mail`, which stresses the difference between
> API and implementation more (although in this case Angus **is** the
> only implementation available).
>
> So, what do you think about renaming `log4j-core`?
>
> Piotr
>
> [1] https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-impl
> [2] https://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-runtime
> [3] https://mvnrepository.com/artifact/javax.mail/javax.mail-api
> [4] https://mvnrepository.com/artifact/com.sun.mail/javax.mail
> [5] https://mvnrepository.com/artifact/org.eclipse.angus/angus-mail
Re: Renaming `log4j-core`
Posted by Gary Gregory <ga...@gmail.com>.
I'm all for it.
Finding a good new name is challenging, sure "impl" seems obvious, but
maybe this is where slf4j/logback can be a lesson with it's clear split.
Having a separate site for the API only might help.
Gary
On Thu, Jun 22, 2023, 04:35 Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi all,
>
> I think one of the main problems preventing Log4j API from being used
> more wildly are naming problems and misinformation on many sites.
>
> Personally I find the name `log4j-core` for our implementation quite
> unfortunate: this is often interpreted as "core Log4j classes", which
> suggests that all artifacts including `log4j-api` should be considered
> as a unit.
>
> I would profit from the major version bump to change it to
> `log4j-impl` or `log4j-runtime`.
>
> Similar changes have occurred in other projects. For example JAXB
> changed it's implementation from `jaxb-impl`[1] to `jaxb-runtime`[2]
> (and also the group id), during the jakartification process.
>
> The Java EE Mail project used `javax.mail-api` for their API and
> `javax.mail` for their implementation. Now they renamed their
> implementation to `angus-mail`, which stresses the difference between
> API and implementation more (although in this case Angus **is** the
> only implementation available).
>
> So, what do you think about renaming `log4j-core`?
>
> Piotr
>
> [1] https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-impl
> [2] https://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-runtime
> [3] https://mvnrepository.com/artifact/javax.mail/javax.mail-api
> [4] https://mvnrepository.com/artifact/com.sun.mail/javax.mail
> [5] https://mvnrepository.com/artifact/org.eclipse.angus/angus-mail
>