up, should we drop log4j2 by default and switch to JUL?
If so we can create a log4j2-compat module easy to integrate back if needed
to mitigate the transition without having to change the minor (several
people already drop it to reuse another impl until they use the bundle goal
which enforces log4j2).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le sam. 14 juil. 2018 à 19:18, Romain Manni-Bucau <[email protected]> a
écrit :

> Checked a bit the options we have and i'm quite unhappy with all of them
> so after having checked I would be to keep a very light abstraction like we
> have (LogFacade from memory) and switch back on JUL by default in all our
> integrations (core+available config, bundle, maven, ...). Log4j2 would
> still be usable adding it in the classpath but it wouldn't be delivered
> anymore by default.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le sam. 14 juil. 2018 à 15:10, Romain Manni-Bucau <[email protected]>
> a écrit :
>
>> found back https://issues.apache.org/jira/browse/LOG4J2-1650, maybe we
>> can revive it
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le sam. 14 juil. 2018 à 12:28, Romain Manni-Bucau <[email protected]>
>> a écrit :
>>
>>> Hi Mark,
>>>
>>> you can use JUL with meecrowave (I do in some integrations) so I guess
>>> the discussion is rather: do we contribute to log4j2 to clean it up or do
>>> we drop it. I wouldn't go back to log4j1 which is really in maintenance
>>> mode and no more adapted to today's apps.
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github
>>> <https://github.com/rmannibucau> | LinkedIn
>>> <https://www.linkedin.com/in/rmannibucau> | Book
>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>>
>>>
>>> Le sam. 14 juil. 2018 à 11:41, Mark Struberg <[email protected]>
>>> a écrit :
>>>
>>>> hi folks!
>>>>
>>>> I've reviewed our use of logging and I wonder if it's really worth it
>>>> to use log4j2?
>>>> It adds a whoopy 2MB to our bundle. That's quite something :/
>>>>
>>>> I'd love to keep the MDC feature. This is really essential for my
>>>> dayjob. But log4j1 is just 300kB whereas log4j2 is 2MB.
>>>> So is it really worth it?
>>>> Note that log4j2 was substantially smaller (900kB) in 2.0 but
>>>> continuously grew over the last 2 years.
>>>> I've already triggered a discussion over there.
>>>>
>>>> Wdyt?
>>>> Would of course be a MW-2.3.x release.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>

Reply via email to