I have a feeling this is going to end up being a topic on our next video chat.
I do appreciate your desire to use PRs for learning. I think you could do that
even if approvals aren’t required. Having PR’s sit for a month before they
can be committed is way too long. At my employer PRs are rarely
I think the appserver is a special case where we’d need separate projects for
Jakarta EE and Java EE.
For other sub-projects, I don’t know. I’ll leave that to someone who
understands the direction Oracle is taking Java, the Java module system, et
cetera.
> On Jan 27, 2022, at 1:08 PM, Ralph
Thank you for expanding upon this, Gary. The reasons I enjoy working on
open-source projects are rooted in trust and community, but lead me to a
different conclusion. Let me elaborate:
At work I interact with a set of developers who have a great deal of experience
working on our software, and ov
Is there a reason that the javax and Jakarta components can’t both reside
in the log4j-appserver module? The don’t share the same package space
so that shouldn’t be a problem.
Ralph
> On Jan 27, 2022, at 12:44 PM, Tim Perry wrote:
>
> The pom.xml changes look reasonable to me. I haven't check
Umm, guys. Log4j-plugins doesn’t know what a Configuration is. It has no
dependency
on log4j-core. So a configuration SPI located there doesn’t make a lot of sense.
In a sense, we already have a configuration SPI. You can use any magic
you want to create a tree of Nodes. Once you have that tre
Thanks, Ceki. Although the Apache license certainly allows copying code
to anything it is against ASF policy to take code against their author’s
wishes.
That said, we have not incorporated anything into log4j-1.2-api that we believe
may have security issues and won’t until we resolve them. Eve
Ralph,
I would like to observe that Vlardimir's JDBCAppender contribution was
made outside Apache. While the code in question is licensed under the
ASL, it has not been contributed to the Apache Foundation. Unless the
foundations rules have changed, you cannot copy the changes without
Vladimir's
Defining an appropriate SPI in log4j-plugins for how to transform a
configuration source into a configuration instance seems like a good
idea. Some of my earlier ideas on the DI SPI was to allow for
alternative implementations that were either generated code or
hand-written code to avoid runtime re
Incidentally, I'm in favor of adding jakarta as a suffix to the Java EE
module name so the Java EE and Jakarta EE module end up sorting next to
each other when listing the directories. It makes it easy to see which ones
have a Jakarta clone.
(I'm also in favor of learning to type Jakarta the first
I think having the two different modules makes sense. That makes it
easiest for users to use the version corresponding to their own
environment. We still have support for Servlet 2.5, so as long as
these modules don't see a lot of active development and continue to be
releasable, then I don't see t
The pom.xml changes look reasonable to me. I haven't checked it out and
played with it. I was thinking I'd have time, but I just got buried with
work elsewhere.
I do wonder if log4j should have two modules:
* log4j-appserver (Tomcat 9 or less)
* log4j-appserver-jakarta (Tomcat 10 or greater)
Ar
I think I'd lean toward a CTR by default policy where larger changes
should go through a PR. Simple cleanups, refactorings, and other easy
things shouldn't require more friction than the CTR plus release vote
process. I'd even suggest using PRs wherever you're not already fairly
comfortable in the
I'd be between options 1 and 2. I'm not a fan of duplicating the jar,
though publishing an empty redirect jar isn't ideal either. Given that
most of the intractable bugs in v1 were related to how log events are
processed which now go through the v2 system, this seems like a good
way to continue sup
> On Jan 27, 2022, at 11:41 AM, Vladimir Sitnikov
> wrote:
>
>> 1. It is an exact copy of log4j-1.2-api with the binary, source, and
> javadoc jars renamed to log4j:log4j.
>> 2. The pom.xml has a dependency on log4j-1.2-api and the jar file is empty.
>
> The options are bad as log4j-1.2-api
>1. It is an exact copy of log4j-1.2-api with the binary, source, and
javadoc jars renamed to log4j:log4j.
>2. The pom.xml has a dependency on log4j-1.2-api and the jar file is empty.
The options are bad as log4j-1.2-api misses several classes that are used a
lot in log4j 1.x deployments.
For inst
Log4j 2.17.2 is going to contain at least 3 dozen fixes or improvements to the
log4j 1.2
support. One of our PMC members has been actively working on migrating his
employer’s
applications from Log4j 1.x to log4j-1.2-api and has had great success. We have
also
had users experience issues and t
If I was asked to vote on moving to RTC I don’t know if I would be -1 but my
vote would be negative. Largely for the same reason as Gary. Yes, stuff has
been committed that I wish wasn’t but I can guarantee RTC wouldn’t have
fixed that. It is simply that I couldn’t review the commit in a timely
Crater and all,
Let me further elaborate that one of the attractions here is the Apache
value of community over code, and for me, commit-then-review,
exemplifies that. Ironically, I know people here a lot less personally and
professionally than I do people I work with; but, I trust you, I trust
ev
Hi Carter,
I think we'll have to agree to disagree, especially if you want RTC just to
add a single getter method, as your example shows. At work we use RTC for
everything, no exceptions, and that's all good and works for our team, _at
work_. This is not what I want to do in my free time.
Gary
O
On Wed, Jan 26, 2022 at 7:44 PM Carter Kozak wrote:
> If the API is a minimal core, that sounds like a bug! However, I don't
> think that's quite the case, it requires that the consumer implement their
> own loggers entirely. What I'm thinking about is more of an
> spi/implementation separation a
Hi Matt,
Thank you for your reply. I agree with all you say. My desire is to offer a
light-weight code path. I don't care about "liking" a format vs. another,
it's just that properties are built in java.base.
Gary
On Wed, Jan 26, 2022 at 6:51 PM Matt Sicker wrote:
> I'm not a fan of the proper
21 matches
Mail list logo
