On Mon, Apr 8, 2024 at 1:11 PM Apache wrote:
> My opinion is to drop it from 3.0.0. 2.x is going to live a long time still.
> By the time it dies Log4J 1.x will have been dead well over 15 years, maybe
> even 20. That would give users plenty of time to be aware that they need to
> plan to upgr
On Tue, Jan 2, 2024 at 1:00 PM Piotr P. Karwasz wrote:
>
> Hi Ralph,
>
> On Tue, 2 Jan 2024 at 11:59, Apache wrote:
> >
> > If this is a runtime dependency then I am against using it in Log4J api and
> > core.
>
> It is an annotation-only library, with a retention of `RUNTIME`.
> However annotat
On Tue, Dec 19, 2023 at 2:05 PM Gary Gregory wrote:
> Do note that building from sources, not git, is an Apache requirement.
Okay, but in what universe is building from a Git tag on the sources
(which is, what the release:perform goal does) different from
"building from sources"?
Jochen
On Mon, Apr 10, 2023 at 11:54 PM Gary Gregory wrote:
>
> The PR talks about SDT which is...?
SimpleDateFormat?
On Sat, Apr 16, 2022 at 11:31 PM Matt Sicker wrote:
>
> Features only available in DI have been asked about in a couple different
> situations already in 2.x development.
Whatever those features may be, I think that "use 3.0" is a reasonable
reply ti such requests.
Jochen
--
Philosophy is use
On Tue, Mar 29, 2022 at 9:11 PM Matt Sicker wrote:
>
> I don’t know if any new javax APIs are defined anymore. There’s JakartaEE for
> the new APIs, though that’s through Eclipse at this point I think.
>
> Also, for a generic plugin library, there are some things I’d likely do
> slightly differe
How about adopting a minimal Json parser into log4j-core? Examples:
1: https://github.com/KasparNagu/plain-java-json (ASL)
2: https://code.google.com/archive/p/json-simple/ (ASL)
3: https://github.com/ralfstx/minimal-json (MIT)
Seems doable, and would work.
Jochen
On Thu, Feb 17, 2022 at 9:56 A
On Thu, Jan 13, 2022 at 4:23 AM Carter Kozak wrote:
> We've discussed the idea of using a code formatter before, I finally had a
> moment put up an example. Please take a look and provide feedback at your
> convenience :-)
> https://github.com/apache/logging-log4j2/pull/697
The main problem, t
On Sat, Jan 1, 2022 at 4:40 PM Xeno Amess wrote:
> > People should migrate to log4j2.
> good thinking, but what if they migrate to logback...
No, it's not (good thinking, that is).
Log4j1 is a part of basically *every* Java based server software, that
I am aware of. People don't want to touch
Having worked with symbolic links on Windows a lot, I find that
privileges are present, in most cases. However, there is the technical
question "How do I create them?"
The best solution, that I have found so far is letting "cmd" do the
job for me. (The mklink command is not a separate executable,
On Fri, Jun 18, 2021 at 6:20 PM Ralph Goers wrote:
> 2. The configuration does “strange things” because Maven doesn’t support
> creating a
> JPMS module, JPMS test module, and running unit tests in a single Maven module
> out of the box while also avoiding
> https://bugs.java.com/bugdatabase/vi
On Wed, Jun 16, 2021 at 1:31 PM Volkan Yazıcı wrote:
> In essence, the build is taking more than it should. Maven "verify" is
> taking more than half an hour and "site" is taking ages. This in addition
> to impeding the development cycle, cripples the release process too.
And why do you blame th
On Tue, Apr 13, 2021 at 5:44 PM Ralph Goers wrote:
> We also have dependencies on things like java.rmi, java.naming, java.sql. I
> am also not clear on whether they are all really optional or not. Ideally,
> the only required dependency we should have is for java.base.
Most likely, those depen
On Mon, Mar 15, 2021 at 7:35 PM Gary Gregory wrote:
>
> +1
>
> Gary
> PS: publicizing the links gives me an impression of support.
And keeping the dist files doesn't?
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief of Tim
On Mon, Jan 25, 2021 at 10:06 PM Tim Perry wrote:
>
> Is it okay to import hamcrest to use in the tests?
>
>
> org.hamcrest
> hamcrest
> 2.2
> test
>
Isn't that pulled in automatically via junit? See, for example, the
Pom in https://search.maven.org/artifact/junit/junit/4.13.1/j
Hi,
consider a logging server. Let's say, there's a REST service "log",
accepting the following parameters:
- applicationId
- category
- level
- message
The purpose here is to use the application id as identification of a
log4j configuration. So, the implementation would look roughly
On Sun, Sep 27, 2020 at 6:38 PM Ralph Goers wrote:
>
> It would not create a new LoggerContext. But a ConfigurationSource represents
> an entire configuration. So calling initialize with it would cause a new
> Configuration to be created. So yes, all your existing LoggerConfigs would be
> repla
Thanks, Ralph,
but that would create a new LoggerContext, wouldn't it? (Thus,
invalidating my existing loggers.)
Jochen
On Sun, Sep 27, 2020 at 5:08 PM Ralph Goers wrote:
>
> Try calling
>
> Configurator.initialize(null, configurationSource);
>
> Ralph
>
> > On
Hi,
in LoggerContext, I have
void updateLoggers(Configuration);
I understand, that this method provides the means to change the logging
configuration at runtime. Very well!
Problem is: I do not have a Configuration, but a ConfigurationSource.
So, what to do?
Thanks,
Jochen
--
Look, th
On Wed, Jul 15, 2020 at 10:06 AM Volkan Yazıcı wrote:
>
> The reason I wanted to go with a simple `String type` field is to keep
> the impact surface and backward compatibility issues at the bay.
>
> I am in favor of `KeyValuePair` -- `KeyValuePair` feels like
> an engineering overkill for our usa
On Tue, Feb 4, 2020 at 10:29 AM Volkan Yazıcı wrote:
> I have a couple of questions regarding working on the manual. I will
> appreciate if you can spare some time to help me out with them:
>
> 1. What is the easiest Maven command just to get `/target/site`
>generated? `./mvnw site` works, bu
On Fri, Jan 17, 2020 at 2:10 PM Volkan Yazıcı wrote:
> Isn't it possible to combine this into a single "String eol"?
Sounds reasonable, except that one should use a byte array, rather
that a string, shouldn't one?
Jochen
On Tue, Oct 8, 2019 at 10:26 PM Ralph Goers wrote:
>
> IIUC this will require a dependency on a Java EE jar? For that reason alone,
> no.
Don't think so. A simple (mostly JSR 330 compliant) provider can be
implemented in a few classes:
https://github.com/jochenw/afw/tree/master/afw-core/src/ma
On Sat, Jun 29, 2019 at 1:21 PM Dominik Psenner wrote:
> We could also push log4net back to incubation. What do you think?
If availability of people is an issue, then this would be an excellent
way of exhausting those even more.
Jochen
You are creating millions of loggers? Meaning either of
- I have a million different logger Id's, and create a logger for
every single one, or
- I have a limited number of different logger Id's, but invoke
LoggerContext.getLogger(String), or
LogManager.getLogger(String), or something similar, wi
On Mon, May 7, 2018 at 2:15 PM William Davis
wrote:
> I've noticed that there are several Async implementations of standard
> appenders out in the wild. Is there a reason none of these have made there
> way into the core product? Is it just b/c no one has taken the time to do
a
> pull request, or
On Wed, Feb 21, 2018 at 3:48 AM, Gary Gregory wrote:
> How about dropping the MR jaring (a horrible design with this META_INF
> business IMO)?
Having to admit, that I haven't got the slightest idea about
feasibility, and amount of work, but: IMO, the best solution would be
to release, say, a log
On Fri, Feb 16, 2018 at 4:03 PM, Gary Gregory wrote:
> On Fri, Feb 16, 2018 at 7:03 AM, Matt Sicker wrote:
>
>> Is this property name already set in stone? Why not log4j2.
>> StatusLogger.DateFormat?
>>
>
> +1
Wrong question, in my opinion: Why use a system property at all? The
preferred source
On Sun, Jan 21, 2018 at 4:55 PM, Gary Gregory wrote:
> - Put everything back into one repo (Chainsaw too?)
In general, yes. However, Chainsaw would be one step too far. From my
point of view, Chainsaw is a consumer, and not a part of log4j-core.
At the most, split a meaningful part out of Chains
On 2018-01-09 14:46, Apache wrote:
> The Logging api only allows you to log a single event at a time so it
> doesn?019t make sense for an appender to have a method that accepts multiple
> events since it can?019t happen. That said, appenders can queue the events
> and send them downstream in ba
On 2018-01-09 14:46, Apache wrote:
> The Logging api only allows you to log a single event at a time so it
> doesnât make sense for an appender to have a method that accepts multiple
> events since it canât happen. That said, appenders can queue the events and
> send them downstream in b
Hi,
currently writing my first appender, and wondering about the following:
The Appender interface specifies a method for logging a single event.
However, my custom Appender would greatly benefit in terms of
performance, if I could implement an additional method
append(LogEvent[] events). Now, I
32 matches
Mail list logo
