Since log4j-core has more than log4j-api, yes, it seems to only
consider direct dependencies instead of transitive ones. I typically
just add log4j-core as a dependency since log4j-api comes with it for
free basically.
On Thu, 29 Aug 2019 at 15:55, Ralph Goers wrote:
>
> I’d have to look at it ag
I’d have to look at it again but I suspect there might be a way that we could
create a version of AppenderSkeleton that works with Log4j 2. The problem is
that people were accessing the internals of Log4j so that even if we could
provide support for those signatures I am not sure they would real
We have some code for making migrations simpler. I wonder if perhaps
we can make a system that maps log4j 1 plugin classes and attributes
into their equivalent 2.x plugins. Not necessarily as classes but as
some sort of config file that can be extended to form compatibility
mappings. Then we should
At work we have one main hurdle to update one our projects from Log4j 1 to
2: How do we migrate installed applications from Log4j1 configurations to
Log4j2.
I started to work on this a long time ago but only got the basics working
which is in Log4j2 now: The idea is to read a Log4j1 config file as
At first I was concerned because on the log4j2 GitHub repo page, it
had less than 1000 dependent users, though it turns out that stat is
for the log4j2 parent pom, not the library. Anyways, some stats:
* log4j-api about 51k:
https://github.com/apache/logging-log4j2/network/dependents?package_id=UG
