> On Jan 18, 2024, at 12:59 PM, Piotr P. Karwasz
> wrote:
>
> Hi Ralph,
>
> On Thu, 18 Jan 2024 at 18:18, Ralph Goers wrote:
>>> Besides we already broke their code, when 2.7 introduced breaking
>>> changes to ConfigurationFactory.
>>
>> ? The contribution I made was done last year - long
Hi Ralph,
On Thu, 18 Jan 2024 at 18:18, Ralph Goers wrote:
> > Besides we already broke their code, when 2.7 introduced breaking
> > changes to ConfigurationFactory.
>
> ? The contribution I made was done last year - long past 2.7.
Yes, what I meant is that Spring Boot uses some Log4j Core speci
I have a much more liberal view of the API. That is, if the class isn’t
documented as private AND it can be reasonably used outside of Log4j then it is
public. However, I would actually have to look at every class to see how much
different it is from your list.
Ralph
> On Jan 18, 2024, at 9:
> On Jan 18, 2024, at 9:01 AM, Piotr P. Karwasz wrote:
>
> Hi Ralph,
>
> On Thu, 18 Jan 2024 at 15:56, Ralph Goers wrote:
>> Spring uses PropertiesUtil. I suspect it isn’t alone. That would mean
>> anything impacted by the property changes would have to be in the spi or
>> abstracted to re
Hi Ralph,
On Thu, 18 Jan 2024 at 16:15, Ralph Goers wrote:
> Note that LogManager has
>
> import org.apache.logging.log4j.simple.SimpleLoggerContextFactory;
> import org.apache.logging.log4j.spi.LoggerContext;
> import org.apache.logging.log4j.spi.LoggerContextFactory;
> import org.apache.logging
Hi Ralph,
On Thu, 18 Jan 2024 at 15:56, Ralph Goers wrote:
> Spring uses PropertiesUtil. I suspect it isn’t alone. That would mean
> anything impacted by the property changes would have to be in the spi or
> abstracted to reference something in the spi. I am assuming a log4j-spi-2.x
> would al
Hi Volkan,
On Wed, 17 Jan 2024 at 17:12, Volkan Yazıcı wrote:
> Given Ralph and Piotr are strongly opinionated about keeping
> `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release
> `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x`
> instead?
The main p
> On Jan 18, 2024, at 8:14 AM, Ralph Goers wrote:
>
>
>
>> On Jan 18, 2024, at 7:55 AM, Ralph Goers wrote:
>>
>>
>>
>>> On Jan 18, 2024, at 5:37 AM, Volkan Yazıcı wrote:
>>>
>>> If we
>>>
>>> 1. move all non-API (`AbstractLogger`, `PropertiesUtil`, etc.) classes
>>> in `log4j-api-3.x`
> On Jan 18, 2024, at 7:55 AM, Ralph Goers wrote:
>
>
>
>> On Jan 18, 2024, at 5:37 AM, Volkan Yazıcı wrote:
>>
>> If we
>>
>> 1. move all non-API (`AbstractLogger`, `PropertiesUtil`, etc.) classes
>> in `log4j-api-3.x` to a new `log4j-spi-3.x` module, and
>> 2. Only implement `log4j-a
> On Jan 18, 2024, at 5:37 AM, Volkan Yazıcı wrote:
>
> If we
>
> 1. move all non-API (`AbstractLogger`, `PropertiesUtil`, etc.) classes
> in `log4j-api-3.x` to a new `log4j-spi-3.x` module, and
> 2. Only implement `log4j-api-2.x` *interfaces* (not abstract classes!)
> in `log4j-core`
> On Jan 18, 2024, at 6:15 AM, Gary Gregory wrote:
>
> Using the same API jar for 3.x core is intriguing. I like the idea of
> a cleaned-up API jar (no custom Supplier) that can front 2.x and 3.x.
>
I don’t think that is what Volkan is proposing as it definitely would break
compatibility be
Using the same API jar for 3.x core is intriguing. I like the idea of
a cleaned-up API jar (no custom Supplier) that can front 2.x and 3.x.
I'd love to hash this out in a call.
Gary
On Thu, Jan 18, 2024 at 12:02 AM Ralph Goers wrote:
>
> The quick answer to this question is “I don’t know”. When
If we
1. move all non-API (`AbstractLogger`, `PropertiesUtil`, etc.) classes
in `log4j-api-3.x` to a new `log4j-spi-3.x` module, and
2. Only implement `log4j-api-2.x` *interfaces* (not abstract classes!)
in `log4j-core`
we can have a Log4j 3 without a `log4j-api-3.x` module, right?
>
Now that I have had 10 seconds to think about it. The change to the property
syntax and how PropertiesUtil works will create serious problems for what you
are proposing.
Ralph
> On Jan 17, 2024, at 10:02 PM, Ralph Goers wrote:
>
> The quick answer to this question is “I don’t know”. When we
I am afraid I don’t really understand that. How does moving the spine content
to another module help? Doesn’t that mean users would now need
log4j-api-2.x.jar and log4j-spi-3,x,jar? What is the benefit of that?
Ralph
> On Jan 17, 2024, at 12:09 PM, Matt Sicker wrote:
>
> That might work, yea
The quick answer to this question is “I don’t know”. When we first started on
the 3.x adventure I can assure you that log4j-api was very different in the 3.x
branch because of the changes we needed to make for JPMS and to the build.
However, since we have since carried those changes back to 2.x
That might work, yeah.
> On Jan 17, 2024, at 12:46 PM, Volkan Yazıcı wrote:
>
> We can move the spi package content in main to a separate module in main.
> SPI problem is solved?
>
> On Wed, 17 Jan 2024 at 18:33, Matt Sicker wrote:
>
>> I suspect this won’t work that well once I’ve implemente
We can move the spi package content in main to a separate module in main.
SPI problem is solved?
On Wed, 17 Jan 2024 at 18:33, Matt Sicker wrote:
> I suspect this won’t work that well once I’ve implemented
> https://github.com/apache/logging-log4j2/issues/1977 as the current
> provider SPI is fa
Or if we back port any of those changes I’ll propose, then perhaps we can
continue with the API at 2.x. That does require that the API target Java 8,
though.
> On Jan 17, 2024, at 11:32 AM, Matt Sicker wrote:
>
> I suspect this won’t work that well once I’ve implemented
> https://github.com/a
I suspect this won’t work that well once I’ve implemented
https://github.com/apache/logging-log4j2/issues/1977 as the current provider
SPI is fairly lacking. It might make more sense to release the main API as
3.0.0 and have 2.x depend on the updated API.
> On Jan 17, 2024, at 10:11 AM, Volkan
20 matches
Mail list logo
