> On Nov 6, 2023, at 2:37 AM, Piotr P. Karwasz wrote:
>
> Hi Ralph,
>
> On Sun, 5 Nov 2023 at 05:39, Ralph Goers wrote:
>> If we have changes in 2.x that are not in 3.x they aren’t many and we will
>> never find that out without releasing. In general users don’t want to use
>> alphas or
It seems like a good idea to keep releasing alpha-beta-milestones (whatever
we want to call these) for pre-3.0 for now. TBH, I've not even tried it in
my work projects yet. I'd rather do that on a very recent alpha. It feels
like our alpha1 is "old".
Gary
On Mon, Nov 6, 2023, 4:37 AM Piotr P.
Hi Ralph,
On Sun, 5 Nov 2023 at 05:39, Ralph Goers wrote:
> If we have changes in 2.x that are not in 3.x they aren’t many and we will
> never find that out without releasing. In general users don’t want to use
> alphas or betas. The alphas and betas are there so we can get feedback on
>
I added @InternalApi to all the classes that were marked “consider this class
private”. As for the plugins, yes, now that we’ve got that stabilized, I think
that makes sense to keep stable, too.
—
Matt Sicker
> On Nov 5, 2023, at 16:22, Ralph Goers wrote:
>
>
>
>> On Nov 5, 2023, at 2:58
> On Nov 5, 2023, at 2:58 PM, Matt Sicker wrote:
> I’ve suggested that we annotate code around API compatibility guarantees, and
> we are using @InternalApi in main to mark things that shouldn’t be used as
> stable code (even if it’s unlikely to change over time).
>
Please be careful of
> On Nov 4, 2023, at 00:08, Christian Grobmeier wrote:
> […]
>
> Agreed, the earlier, so better, but making Log4j 3.x GA "first thing next
> year" seems to be quite of a rush.
After another beta release, I don’t think that’s a rush. It’s not like the
entire ecosystem will upgrade all at
> On Nov 3, 2023, at 10:08 PM, Christian Grobmeier wrote:
>
>
>> However, like myself, organizations are not going to delay upgrading
>> too long. Having Log4j 3.x be available before the majority of orgs
>> switch to Spring 3 will greatly improve its adoption.
>
> Agreed, the earlier, so
On Fri, Nov 3, 2023, at 22:28, Ralph Goers wrote:
>> On Nov 3, 2023, at 12:47 PM, Christian Grobmeier
>> wrote:
>> Sorry, I am a bit lost here - you spoke about Spring 3, and it sounded like
>> it was something new. I understand this is nothing new. So, what exactly are
>> we aiming at that
> On Nov 3, 2023, at 12:47 PM, Christian Grobmeier wrote:
>
> On Fri, Nov 3, 2023, at 03:36, Ralph Goers wrote:
>>> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier
>>> wrote:
>>> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote:
Log4j 3 matching Spring 3 seems obviously a good thing
On Fri, Nov 3, 2023, at 03:36, Ralph Goers wrote:
>> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier
>> wrote:
>> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote:
>>> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
>>> 17 seems to me as well a good thing.
>>>
>>>
I believe there is confusion here as to what level of compatibility
requirements we set at the release of 3.0.0. Some remaining changes proposed
for 3.x are technically breaking changes depending on the level of API
stability in question. Personally, I think we should demarcate what APIs are
> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier wrote:
>
>
>
> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote:
>> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
>> 17 seems to me as well a good thing.
>>
>> Gary
>>
>> On Thu, Nov 2, 2023, 7:04 AM Ralph
If we actually annotate the various public APIs like how JUnit 5 does, then we
could have more flexibility to remove things.
> On Nov 2, 2023, at 4:10 AM, Piotr P. Karwasz wrote:
>
> Hi Ralph,
>
> On Thu, 2 Nov 2023 at 09:42, Apache wrote:
>> I’m confused. 3.0.0 hasn’t even been released so
Hi Ralph,
On Thu, 2 Nov 2023 at 11:53, Ralph Goers wrote:
> Releases do not have to be perfect. In fact, someone advised me once that you
> don’t want them to be as that is how you draw in new committers.
I don't know about that, all you got from Log4Shell is one lousy
committer. And that was
On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote:
> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
> 17 seems to me as well a good thing.
>
> Gary
>
> On Thu, Nov 2, 2023, 7:04 AM Ralph Goers wrote:
>
>> I should add that I am concerned that we are missing a huge
JPMS is something to work _around_, not _with_ IMO.
Gary
On Thu, Nov 2, 2023, 12:25 AM Christian Grobmeier wrote:
>
>
> On Thu, Nov 2, 2023, at 02:12, Ralph Goers wrote:
> > Christian, I was at least 3 years ahead of you on this one.This is
>
> Sorry I was not active for a while. Good you were
Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
17 seems to me as well a good thing.
Gary
On Thu, Nov 2, 2023, 7:04 AM Ralph Goers wrote:
> I should add that I am concerned that we are missing a huge opportunity
> with Spring 3. A lot of folks will start their
I should add that I am concerned that we are missing a huge opportunity with
Spring 3. A lot of folks will start their migration to Spring 3 early next
year. Tying Log4J 3.x to that is a big opportunity for people to upgrade at the
same time.
Ralph
> On Nov 2, 2023, at 3:53 AM, Ralph Goers
Piotr, I haven’t committed much to 3.x since June because it already has
everything I set out to do. It is everyone else who keeps adding crap that
“must” be done before it can be released. Yet another year is far too long. If
that is the case my vote is to skip the additional stuff. And I will
On Thu, Nov 2, 2023, at 08:53, Ralph Goers wrote:
>> On Nov 1, 2023, at 9:24 PM, Christian Grobmeier wrote:
>>
>>
>>
>> On Thu, Nov 2, 2023, at 02:12, Ralph Goers wrote:
>>> Christian, I was at least 3 years ahead of you on this one.This is
>>
>> Sorry I was not active for a while. Good
Hi Ralph,
On Thu, 2 Nov 2023 at 09:42, Apache wrote:
> I’m confused. 3.0.0 hasn’t even been released so how can I be preventing
> adding anything. Personally I would prefer the monitoring to be in a separate
> repo but I am ok with adding it to the main build. IAM all for moving async
> out
I’m confused. 3.0.0 hasn’t even been released so how can I be preventing adding
anything. Personally I would prefer the monitoring to be in a separate repo but
I am ok with adding it to the main build. IAM all for moving async out but
unless it can be done quickly I’d rather do it in a future
Hi Ralph,
On Thu, 2 Nov 2023 at 08:39, Piotr P. Karwasz wrote:
> Hi Ralph,
> On Thu, 2 Nov 2023 at 05:53, Ralph Goers wrote:
> > JPMS is not the main target for 2.x as 2.x still supports Java 8 and has to
> > use “versioned” jars so it can work in Java 8 and Java 11+. 3.x only
> > supports
Hi Ralph,
On Thu, 2 Nov 2023 at 05:53, Ralph Goers wrote:
> JPMS is not the main target for 2.x as 2.x still supports Java 8 and has to
> use “versioned” jars so it can work in Java 8 and Java 11+. 3.x only
> supports Java 11 and is really where we want to focus our attention. I wish
>
> On Nov 1, 2023, at 9:24 PM, Christian Grobmeier wrote:
>
>
>
> On Thu, Nov 2, 2023, at 02:12, Ralph Goers wrote:
>> Christian, I was at least 3 years ahead of you on this one.This is
>
> Sorry I was not active for a while. Good you were here.
>
>> precisely why in 3.x we extracted a
On Thu, Nov 2, 2023, at 02:12, Ralph Goers wrote:
> Christian, I was at least 3 years ahead of you on this one.This is
Sorry I was not active for a while. Good you were here.
> precisely why in 3.x we extracted a LOT of stuff from log4j-core into
> their own modules.
Why not 2.x?
> To
Christian, I was at least 3 years ahead of you on this one.This is precisely
why in 3.x we extracted a LOT of stuff from log4j-core into their own modules.
To be honest the main driver was JPMS - our goal for 3.x Is for log4j-core to
only have a hard dependency on java.base and as few optional
> On Nov 1, 2023, at 2:22 PM, Christian Grobmeier wrote:
>
> We should not underestimate the impact log4shell had. Jndi was at the epi
> center. Us, providing a giant jar including so much stuff with potential
> security holes don’t do us a favor.
This is exactly why in 3.x, the main branch,
As some might know, I am writing a book and the publisher gathers a lot of
feedback. Also I talk to many people in my classrooms and also to many pros at
my clients side.
What I hear is usually:
- is log4j really secure?
- can’t I disable certain features?
- are you sure you get jndi right this
I don’t see any reason why we shouldn’t publish the JNDI support in its own
module as we’re planning in main already. Whether we eventually split out
anything from the main repo is another story, but in 3.x, JNDI, like most of
the optional features, will require downloading additional
If you want separate logging config files in an EJB environment using JNDI is
pretty much required. The same would be true for any properties needed in the
configuration.
In any case, despite Piotr saying this is a majority vote, it is not. I will
veto any attempt to remove JNDI components
On Wed, Nov 1, 2023, at 00:01, Ralph Goers wrote:
> There is a difference between a JEE application that only uses servlets
> vs one that uses EJBs. At a former employer we often used JBoss to run
> servlets even though we had no EJBs. In an environment with EJBs I am
> not sure how you can
Hi
On Tue, Oct 31, 2023, at 23:23, Matt Sicker wrote:
> I’m not sure how much people use this deployment model anymore, but
> JNDI was and still is at the core of JavaEE (now JakartaEE) dependency
> injection APIs. While CDI is the current way of using dependency
> injection there, CDI is
There is a difference between a JEE application that only uses servlets vs one
that uses EJBs. At a former employer we often used JBoss to run servlets even
though we had no EJBs. In an environment with EJBs I am not sure how you can
distinguish the various components from each other without
I’m not sure how much people use this deployment model anymore, but JNDI was
and still is at the core of JavaEE (now JakartaEE) dependency injection APIs.
While CDI is the current way of using dependency injection there, CDI is
compatible with JNDI and the other JavaEE tech that came in between
Piotr, I think it is important to differentiate what is a requirement and
what is just another way of achieving something. My employer has several
Tomcat- and JBoss-based JEE applications (using Log4j) and we don't have a
single JNDI usage I know of.
I would like to hear "the functional need"
Hi Christian,
On Tue, 31 Oct 2023 at 21:57, Christian Grobmeier wrote:
> I am surprised we still have JNDI in the code at all, but this made me
> curious:
> why do JEE users need JNDI features for logging? Why can't they just use the
> normal log mechanism?
JNDI is basically a bean
Hi,
on the recent deprecation vote I saw this vote (from Ralph):
> * JNDI-related features:
-1 Unfortunately, JEE users require this.
I am surprised we still have JNDI in the code at all, but this made me curious:
why do JEE users need JNDI features for logging? Why can't they just use the
38 matches
Mail list logo
