[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516345#comment-17516345
]
Romain Manni-Bucau commented on LOG4J2-2795:
[~mattsicker] tested master right now and got 405ms (really regular around 40x
ms for some dozen of startups) for:
{code:java}
public class Run {
public static void main(final String... args) {
final long start = System.nanoTime();
LogManager.getLogger(Run.class).info("foo");
final long end = System.nanoTime();
System.out.println(TimeUnit.NANOSECONDS.toMillis(end - start) + "ms");
}
} {code}
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515116#comment-17515116
]
Romain Manni-Bucau commented on LOG4J2-2795:
[~mattsicker] AFAIK it is not the case on master since
org.apache.logging.log4j.plugins.util.PluginManager#collectPlugins(java.util.List)
is still called and
org.apache.logging.log4j.plugins.util.PluginRegistry#decodeCacheFiles is still
there so there is nothing really lazy or matching only the configuration
surface and not the full scope of log4j. Hope I didn't miss something.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514949#comment-17514949
]
Romain Manni-Bucau commented on LOG4J2-2795:
To give another metrics for my computer: a real "small" application (johnzon +
cdi + yupiik-logging/JUL) starts in ~250ms (with scanning not optimized and
some startup init code) which is 30ms faster than log4j alone for a
getLogger().info() main - just enables to compare why I speak about a few
dozens of ms to init the logging.
Wonder if you evaluated to not collect plugins but just try to load them lazily
when they are referenced. Concretely, ConsoleAppender wouldnt be loaded until
it appears in some configuration etc...Also loading it using a registrar class
(kind of ServiceLoader mecanism but with a name deduced from the name
encoutered by log4j) can enable to simplify the serialization too and get back
to something closer to the previous (v1) configuration where it was loaded per
class directly (even if it still has an indirection with the resource lookup
but it is a bit better).
That + dropping most of static init would be great I think even if I can't
evaluate the gain yet.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514460#comment-17514460
]
Romain Manni-Bucau commented on LOG4J2-2795:
[~mattsicker] right but still, the first "info" logging time should be almost
free compared to an IoC startup when it includes scanning (CDI in my original
reference). It is also way more than JUL or any other alternative so it is
quite important for modern deployment (thinking to k8s in particular).
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17513182#comment-17513182
]
Romain Manni-Bucau commented on LOG4J2-2795:
Hi [~mattsicker] , I'm around 362 with the defaults, 278ms without jmx so a bit
better but still very high IMHO.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512695#comment-17512695
]
Romain Manni-Bucau commented on LOG4J2-2795:
Here it is https://gist.github.com/rmannibucau/f077856a9e4d51226cffe5e8d4af512f
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512568#comment-17512568
]
Romain Manni-Bucau commented on LOG4J2-2795:
Yes it is there on ubuntu.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17510806#comment-17510806
]
Romain Manni-Bucau commented on LOG4J2-2795:
I did a nanotime around the getLogger().info(), time measurement is worse but
also takes into account way more so we can't only blame log4j there ;)
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17510263#comment-17510263
]
Romain Manni-Bucau commented on LOG4J2-2795:
I'm just testing a plain main doing a logger.info (and i just have log4j-core
dep tree, not even a real classpath).
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17510073#comment-17510073
]
Romain Manni-Bucau commented on LOG4J2-2795:
[~mattsicker] I didn't reprofile it since the ton of static inits is one of the
issue and requires a drastical change in the code. Technically a single
singleton - manager or context - abusing of static data is needed (rest are
plain instances with fields) so think using the internal reflection-less IoC to
align the code design on something more modern and less time consuming at
startup can be worth it to solve this issue. Taking 10 times more than an
actual IoC is weirdish to get logs ;).
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509699#comment-17509699
]
Romain Manni-Bucau commented on LOG4J2-2795:
Hi
Just tested master.
For Java 17 it does not work: `java.lang.IllegalAccessError: Cannot access
field protected org.apache.logging.log4j.plugins.di.Injector
org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.injector`.
On Java 11 I'm around 430ms (vs 45ms for a simple implementation) so looks like
it is still way too slow.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-1312) org.apache.logging.log4j.web.Log4jServletContextListener leaking
[ https://issues.apache.org/jira/browse/LOG4J2-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294696#comment-17294696 ] Romain Manni-Bucau edited comment on LOG4J2-1312 at 3/3/21, 5:47 PM: - Not handy but should be reproducable deploying a war which fail in a listener after log4j one, the thread local will never be cleaned. If log4j is in tomcat/lib another webapp can inherit form it (and use it) whereas in other cases it will just leak mem. was (Author: romain.manni-bucau): Not handy should be reproducable deploying a war which fail in a listener after log4j one, the thread local will never be cleaned. If log4j is in tomcat/lib another webapp can inherit form it (and use it) whereas in other cases it will just leak mem. > org.apache.logging.log4j.web.Log4jServletContextListener leaking > > > Key: LOG4J2-1312 > URL: https://issues.apache.org/jira/browse/LOG4J2-1312 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Romain Manni-Bucau >Priority: Major > > org.apache.logging.log4j.web.Log4jServletContextListener calls > this.initializer.setLoggerContext(); and > this.initializer.clearLoggerContext(); in respectively contextInitialized and > contextDestroyed. By default it sets/resets a thread local. There is no > guarantee to reuse the same thread for undeployment than for deployment so it > doesn't really work + it leaks for all deployments in between so it is > possible a webapp reuse the context of another webapp in between. > The only way to move one step forward is to be able to lookup the servlet > context by classloader IMO but this still has the issue a lot of things - > including logging - can happen before the servlet context is available and > here the application can't use these features so wonder if it shouldn't be a > way to configure the servlet context representation log4j uses in log4j2.xxx > for such cases (ex: tomee starts CDI before servlets to ensure injections can > be done properly in servlets but then you can't log in CDI lifecycle using > log4j2). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LOG4J2-1312) org.apache.logging.log4j.web.Log4jServletContextListener leaking
[ https://issues.apache.org/jira/browse/LOG4J2-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294696#comment-17294696 ] Romain Manni-Bucau commented on LOG4J2-1312: Not handy should be reproducable deploying a war which fail in a listener after log4j one, the thread local will never be cleaned. If log4j is in tomcat/lib another webapp can inherit form it (and use it) whereas in other cases it will just leak mem. > org.apache.logging.log4j.web.Log4jServletContextListener leaking > > > Key: LOG4J2-1312 > URL: https://issues.apache.org/jira/browse/LOG4J2-1312 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Romain Manni-Bucau >Priority: Major > > org.apache.logging.log4j.web.Log4jServletContextListener calls > this.initializer.setLoggerContext(); and > this.initializer.clearLoggerContext(); in respectively contextInitialized and > contextDestroyed. By default it sets/resets a thread local. There is no > guarantee to reuse the same thread for undeployment than for deployment so it > doesn't really work + it leaks for all deployments in between so it is > possible a webapp reuse the context of another webapp in between. > The only way to move one step forward is to be able to lookup the servlet > context by classloader IMO but this still has the issue a lot of things - > including logging - can happen before the servlet context is available and > here the application can't use these features so wonder if it shouldn't be a > way to configure the servlet context representation log4j uses in log4j2.xxx > for such cases (ex: tomee starts CDI before servlets to ensure injections can > be done properly in servlets but then you can't log in CDI lifecycle using > log4j2). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LOG4J2-1312) org.apache.logging.log4j.web.Log4jServletContextListener leaking
[ https://issues.apache.org/jira/browse/LOG4J2-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294340#comment-17294340 ] Romain Manni-Bucau commented on LOG4J2-1312: [~rgoers] don't think it got solved so still an issue with webapp "runtime" deployments. > org.apache.logging.log4j.web.Log4jServletContextListener leaking > > > Key: LOG4J2-1312 > URL: https://issues.apache.org/jira/browse/LOG4J2-1312 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Romain Manni-Bucau >Priority: Major > > org.apache.logging.log4j.web.Log4jServletContextListener calls > this.initializer.setLoggerContext(); and > this.initializer.clearLoggerContext(); in respectively contextInitialized and > contextDestroyed. By default it sets/resets a thread local. There is no > guarantee to reuse the same thread for undeployment than for deployment so it > doesn't really work + it leaks for all deployments in between so it is > possible a webapp reuse the context of another webapp in between. > The only way to move one step forward is to be able to lookup the servlet > context by classloader IMO but this still has the issue a lot of things - > including logging - can happen before the servlet context is available and > here the application can't use these features so wonder if it shouldn't be a > way to configure the servlet context representation log4j uses in log4j2.xxx > for such cases (ex: tomee starts CDI before servlets to ensure injections can > be done properly in servlets but then you can't log in CDI lifecycle using > log4j2). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LOG4J2-658) shutdown hook called too early
[
https://issues.apache.org/jira/browse/LOG4J2-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294337#comment-17294337
]
Romain Manni-Bucau commented on LOG4J2-658:
---
[~rgoers] it hasn't been solved AFAIK?
> shutdown hook called too early
> --
>
> Key: LOG4J2-658
> URL: https://issues.apache.org/jira/browse/LOG4J2-658
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-rc1, 2.0-rc2, 2.0.2
>Reporter: Romain Manni-Bucau
>Assignee: Matt Sicker
>Priority: Major
>
> Hi
> this issue follow few mail exchanges from the commons list. Here the
> interesting part for log4j2:
> {quote}
> Here what I do (we can move it to another thread since that's 100% log4j2
> related):
> unzip apache-tomee-1.7.0-SNAPSHOT-webprofile.zip &&
> cd apache-tomee-webprofile-1.7.0-SNAPSHOT/ &&
> rm conf/logging.properties &&
> echo 'openejb.log.factory=log4j'>conf/system.properties &&
> cp ~/log4j2.xml conf/log4j2.xml &&
> cp
> ~/.m2/repository/org/apache/logging/log4j/log4j-api/2.0-rc2-SNAPSHOT/log4j-api-2.0-rc2-SNAPSHOT.jar
> lib/ &&
> cp
> ~/.m2/repository/org/apache/logging/log4j/log4j-core/2.0-rc2-SNAPSHOT/log4j-core-2.0-rc2-SNAPSHOT.jar
> lib/ &&
> cp
> ~/.m2/repository/org/apache/logging/log4j/log4j-1.2-api/2.0-rc2-SNAPSHOT/log4j-1.2-api-2.0-rc2-SNAPSHOT.jar
> lib/ &&
> ./bin/catalina.sh
> it makes server starting with log4j2 logs, if you ctrl+c logs are not
> printed. Sure it is cause context is closed too early and then loggers have
> NullConfiguration. (If I debug in java.lang.ApplicationShutdownHooks#runHooks
> to wait all hooks exec it works)
> {quote}
> Basically the issue is that when shutting down with ctrl+C some logs are
> swallowed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259766#comment-17259766
]
Romain Manni-Bucau commented on LOG4J2-2795:
Up :)
Any hope it gets better in the coming months or is it completely out of the
radar for the project?
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LOG4J2-2649) Is Log4j2 considered to support successful static compilation under GraalVM?
[ https://issues.apache.org/jira/browse/LOG4J2-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125079#comment-17125079 ] Romain Manni-Bucau commented on LOG4J2-2649: +1, please ensure to provide the META-INF/native-image with all the reflection preconfigured to avoid to the end users to do that work ;). > Is Log4j2 considered to support successful static compilation under GraalVM? > - > > Key: LOG4J2-2649 > URL: https://issues.apache.org/jira/browse/LOG4J2-2649 > Project: Log4j 2 > Issue Type: New Feature >Reporter: YangGuanchao >Priority: Blocker > Original Estimate: 168h > Remaining Estimate: 168h > > Oracle released GraalVM [https://github.com/oracle/graal] to support the > static compilation of Java applications to Native Image, which can increase > the startup speed of Java by at least 10 times. In the cloud native field, > this basic technology is believed to be in the near future. Will be supported > by more and more vendors, such as the Spring/Spring Boot community has > supported or plans to support the feature of GraalVM, see this issue: > [https://github.com/spring-projects/spring-framework/search?q=Graalvm&type=Issues] > can support static compilation, so it is recommended that Log4j2 also need > to support static compilation as soon as possible, and can be compiled > correctly under GraalVM. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LOG4J2-2649) Is Log4j2 considered to support successful static compilation under GraalVM?
[ https://issues.apache.org/jira/browse/LOG4J2-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124975#comment-17124975 ] Romain Manni-Bucau commented on LOG4J2-2649: One issue I noted with log4j2 is that it uses a lot of static init which means most of the dependency must be init at build time, loosing all the dynamic configuration of the framework. Can be more elegant to use the lifecycle of log4j to do that and limit a lot the static init to bootstrap SPI binding - it is also a good practise to be able to stop/restart properly the *factories IMHO. > Is Log4j2 considered to support successful static compilation under GraalVM? > - > > Key: LOG4J2-2649 > URL: https://issues.apache.org/jira/browse/LOG4J2-2649 > Project: Log4j 2 > Issue Type: New Feature >Reporter: YangGuanchao >Priority: Blocker > Original Estimate: 168h > Remaining Estimate: 168h > > Oracle released GraalVM [https://github.com/oracle/graal] to support the > static compilation of Java applications to Native Image, which can increase > the startup speed of Java by at least 10 times. In the cloud native field, > this basic technology is believed to be in the near future. Will be supported > by more and more vendors, such as the Spring/Spring Boot community has > supported or plans to support the feature of GraalVM, see this issue: > [https://github.com/spring-projects/spring-framework/search?q=Graalvm&type=Issues] > can support static compilation, so it is recommended that Log4j2 also need > to support static compilation as soon as possible, and can be compiled > correctly under GraalVM. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17082215#comment-17082215
]
Romain Manni-Bucau commented on LOG4J2-2795:
Hi [~rgoers], guess 1 at least should be solved (it depends your classpath so
can be very slow). Others can wait and guess then starting time is acceptable
even if still slow compared to concurrents.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LOG4J2-2809) java.lang.NullPointerException at java9 org.apache.logging.log4j.util.StackLocator.calcLocation()
[
https://issues.apache.org/jira/browse/LOG4J2-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070272#comment-17070272
]
Romain Manni-Bucau commented on LOG4J2-2809:
Master works perfectly for me, just awaiting a release :)
> java.lang.NullPointerException at java9
> org.apache.logging.log4j.util.StackLocator.calcLocation()
> --
>
> Key: LOG4J2-2809
> URL: https://issues.apache.org/jira/browse/LOG4J2-2809
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Andre Elis
>Assignee: Ralph Goers
>Priority: Major
> Fix For: 2.13.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When log() is called from a class using an instance created/stored at
> ThreadLocal
> its StackWalker.StackFrame names changes to
> "WrappingClass$ClassFromThreadLocal".
> This causes NPE because walker.walk(LOCATOR) returns null.
> {code:java}
> StackTraceElement element = walker.walk(LOCATOR).toStackTraceElement();
> {code}
> It is suggested to check the result of walk() for null-ness and react in the
> way different from NPE.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LOG4J2-2809) java.lang.NullPointerException at java9 org.apache.logging.log4j.util.StackLocator.calcLocation()
[
https://issues.apache.org/jira/browse/LOG4J2-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17068755#comment-17068755
]
Romain Manni-Bucau commented on LOG4J2-2809:
Same there, proposed a trivial fix with
[https://github.com/apache/logging-log4j2/pull/356] but anything better is fine
for me.
For some background, a lot of loggingLibX -> slf4j -< log4j-slf4j pass wrong
fqn (java.util.Logger) and this now fails on java 9 whereas on java 8 it was
just not correct for the location but logs were not lost.
> java.lang.NullPointerException at java9
> org.apache.logging.log4j.util.StackLocator.calcLocation()
> --
>
> Key: LOG4J2-2809
> URL: https://issues.apache.org/jira/browse/LOG4J2-2809
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Andre Elis
>Assignee: Ralph Goers
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When log() is called from a class using an instance created/stored at
> ThreadLocal
> its StackWalker.StackFrame names changes to
> "WrappingClass$ClassFromThreadLocal".
> This causes NPE because walker.walk(LOCATOR) returns null.
> {code:java}
> StackTraceElement element = walker.walk(LOCATOR).toStackTraceElement();
> {code}
> It is suggested to check the result of walk() for null-ness and react in the
> way different from NPE.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053143#comment-17053143
]
Romain Manni-Bucau commented on LOG4J2-2795:
Hi [~rgoers], I have a few questions about some code parts and in particular
org.apache.logging.log4j.core.config.AbstractConfiguration#initialize and
friends:
# why a ScriptManager is created there? can't it be created lazily in
org.apache.logging.log4j.core.config.AbstractConfiguration#doConfigure, it
triggers some serious loading for nothing most of the time
# why PluginManager isnt cached per package?
# why we can't get a static extension support in configuration factory
(@ConfigurationFactoryConfiguration(suffixes = \{".xml"})) to avoid to load the
class and instantiate it if not needed, the processor would store it avoid a
bunch of classloading for nothing
# Same in
org.apache.logging.log4j.core.lookup.Interpolator#Interpolator(org.apache.logging.log4j.core.lookup.StrLookup,
java.util.List), why eveything is early instantiated?
Will not solve everything but at least the ScriptManager drop helps for me.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated LOG4J2-2795:
---
Attachment: image-2020-03-06-08-58-21-169.png
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17051845#comment-17051845
]
Romain Manni-Bucau commented on LOG4J2-2795:
Even if it is true most JVM will have JIT, it still does not justify this
slowness. Concretely just adding log4j - so not changing anything to your
functional - makes your single test passing from 30ms to > 1s which is likely
not acceptable just for logs. Indeed it is possible to exclude log4j to use
something else most of the time but I don't see a reason it is that slow to
init - in particular when you know a CDI container starts 3-4 faster. This is
why i reported this issue.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17051832#comment-17051832
]
Romain Manni-Bucau commented on LOG4J2-2795:
Well the ipv4 workaround can be a doc highlighting I guess.
About dropping the plugins, the idea was to measure the cost of the
pluggability vs the cost of the earger loading. If on 1s, 800ms are taken
without any plugging there is a big issue. If plugins take 800ms then they can
be lazily loaded using a lookup convention and it would already help IMHO.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17051821#comment-17051821
]
Romain Manni-Bucau commented on LOG4J2-2795:
Hmm, this part can depend the machine, wonder if it should be done lazily since
it is not always used. Also add {{-Djava.net.preferIPv4Stack=true}} on the JVM
can help but still the reflection init cost is quite huge. An interesting test
can be to drop all plugins from core to split the "infra" init cost and actual
loading cost.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17049963#comment-17049963
]
Romain Manni-Bucau commented on LOG4J2-2795:
Right, but in the context of the test it is quite reasonable (junit5 so a bit
more than junit4 but not an EE stack ;)). In any case it can't justify the
overhead compared to throwing an exception which stays negligible. I can
request to use the tccl if needed but not sure it would impact the perf.
Will attach the hotspots i got yesterday with 2.13.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated LOG4J2-2795:
---
Attachment: log4j2.png
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17049949#comment-17049949
]
Romain Manni-Bucau commented on LOG4J2-2795:
Hi Ralph,
Yes Plugin API helps, for the same line (on another computer) I went from 2.5s
to 1.4s so guess only part of the reflection can still need some precomputation
but it is better on master.
Side note: getting a caller is expensive but not the *functional* case here
since I don't log anything.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
Romain Manni-Bucau created LOG4J2-2795:
--
Summary: Make LogManager/LoggerContext creation time reasonable
Key: LOG4J2-2795
URL: https://issues.apache.org/jira/browse/LOG4J2-2795
Project: Log4j 2
Issue Type: Task
Components: Core
Affects Versions: 2.13.0
Reporter: Romain Manni-Bucau
Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
itself.
For a logging framework it is likely way too much (by comparison a CDI test
with classpath scanning takes ~50ms).
This ticket is about trying to be faster (maybe by removing java serialization
usage and reducing registry usage + reflection of plugins by generating java
code?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (LOG4J2-2688) [web] session attribute lookup support
Romain Manni-Bucau created LOG4J2-2688: -- Summary: [web] session attribute lookup support Key: LOG4J2-2688 URL: https://issues.apache.org/jira/browse/LOG4J2-2688 Project: Log4j 2 Issue Type: Improvement Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (LOG4J2-2523) log4j-web should support header+attributes lookup
[ https://issues.apache.org/jira/browse/LOG4J2-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16874236#comment-16874236 ] Romain Manni-Bucau commented on LOG4J2-2523: [~NicolaIsotta] proposing https://github.com/apache/logging-log4j2/pull/287 > log4j-web should support header+attributes lookup > - > > Key: LOG4J2-2523 > URL: https://issues.apache.org/jira/browse/LOG4J2-2523 > Project: Log4j 2 > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 3.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Since log4j has a filter it can read headers and attributes from the request > and not limit itself to the context. This is quite useful to track a > correlation id without any glue code to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4J2-2523) log4j-web should support header+attributes lookup
[ https://issues.apache.org/jira/browse/LOG4J2-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16725020#comment-16725020 ] Romain Manni-Bucau commented on LOG4J2-2523: PR sent at https://github.com/apache/logging-log4j2/pull/246 > log4j-web should support header+attributes lookup > - > > Key: LOG4J2-2523 > URL: https://issues.apache.org/jira/browse/LOG4J2-2523 > Project: Log4j 2 > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Since log4j has a filter it can read headers and attributes from the request > and not limit itself to the context. This is quite useful to track a > correlation id without any glue code to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (LOG4J2-2523) log4j-web should support header+attributes lookup
Romain Manni-Bucau created LOG4J2-2523: -- Summary: log4j-web should support header+attributes lookup Key: LOG4J2-2523 URL: https://issues.apache.org/jira/browse/LOG4J2-2523 Project: Log4j 2 Issue Type: New Feature Reporter: Romain Manni-Bucau Since log4j has a filter it can read headers and attributes from the request and not limit itself to the context. This is quite useful to track a correlation id without any glue code to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4J2-1650) log4j2-core diet
[ https://issues.apache.org/jira/browse/LOG4J2-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16544574#comment-16544574 ] Romain Manni-Bucau commented on LOG4J2-1650: The proposal was to keep only implemented interfaces in the API and only main implementations dependencyless in core (i assume the default synchronous rolling file appender is the max which can fit here). Anything else is extension. The size is critical cause logging is everywhere and libraries/servers cant impose 25% of their size for logging with 80% of it being not used in 90% of the deployments. It impacts build times, packaging, dockerization and therefore network time at the end so yes it is important. > log4j2-core diet > > > Key: LOG4J2-1650 > URL: https://issues.apache.org/jira/browse/LOG4J2-1650 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Priority: Major > > Hello, > log4j2 is ~1.3M. It is a lot to get started with logging and several parts > are not mandatory to start and rarely needed all together like jackson, db, > yaml (this one is not that big) etc...Also saw Generate class which is quite > big but not sure it is needed at runtime and the annotation processor logic > is never needed at runtime. > Anyway, by comparison logback and log4j1 are ~500k so hopefully we could only > pay the same price to get started with log4j2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4J2-1650) log4j2-core diet
[ https://issues.apache.org/jira/browse/LOG4J2-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16544547#comment-16544547 ] Romain Manni-Bucau commented on LOG4J2-1650: [~garydgregory]this is what i did yesterday and i dont see a way to achieve it with current design which is fat. Could 3.0 throw away plugin and builder desigbs/patterns? If not i guess it is time lost :( > log4j2-core diet > > > Key: LOG4J2-1650 > URL: https://issues.apache.org/jira/browse/LOG4J2-1650 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Priority: Major > > Hello, > log4j2 is ~1.3M. It is a lot to get started with logging and several parts > are not mandatory to start and rarely needed all together like jackson, db, > yaml (this one is not that big) etc...Also saw Generate class which is quite > big but not sure it is needed at runtime and the annotation processor logic > is never needed at runtime. > Anyway, by comparison logback and log4j1 are ~500k so hopefully we could only > pay the same price to get started with log4j2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4J2-1650) log4j2-core diet
[ https://issues.apache.org/jira/browse/LOG4J2-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16544274#comment-16544274 ] Romain Manni-Bucau commented on LOG4J2-1650: Dropping the optional dependencies from log4j-core makes the core going back to 1.3M which is back to the state when this issue was open. Extracting JMX, Net, OSGi, tools, http/syslog appenders features in another jar saves a bit more but not enough. So my opinion today is that log4j2 needs a serious work on: # its modularity (it is very monolith today and other modules generally just reuses a core abstraction which means there is some inconsistency at the modularity level) # its design: log4j2 introduces several layers (builders, plugins, dat etc) which all take a lot of size for a logging library (we are not doing scala ;)) I guess an option can be to bypass log4j-core and reimplement the log4j-api extracting the good piece of code (rolling appender and context classloader selector mainly) without all the extensions and abstractions, builders etc... This is however a core choice of the project, would be great to see if it can hit master anytime soon. > log4j2-core diet > > > Key: LOG4J2-1650 > URL: https://issues.apache.org/jira/browse/LOG4J2-1650 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Priority: Major > > Hello, > log4j2 is ~1.3M. It is a lot to get started with logging and several parts > are not mandatory to start and rarely needed all together like jackson, db, > yaml (this one is not that big) etc...Also saw Generate class which is quite > big but not sure it is needed at runtime and the annotation processor logic > is never needed at runtime. > Anyway, by comparison logback and log4j1 are ~500k so hopefully we could only > pay the same price to get started with log4j2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4J2-1650) log4j2-core diet
[ https://issues.apache.org/jira/browse/LOG4J2-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16544217#comment-16544217 ] Romain Manni-Bucau commented on LOG4J2-1650: Up, now log4j2 is 2M, this is way too much to be something reliable at all levels but the final application one (servers, libraries etc). Can we try to provide a functional default delivery (I guess the rolling file is the minimal feature we want as appender) which would be around 500k and stable? Cause of that we are starting to speak about dropping log4j2 as default system on Meecrowave which wouldn't be a good health sign for both projects (for log4j2 as adaption and meecrowave cause log4j2 features are great but deliveries too fat). > log4j2-core diet > > > Key: LOG4J2-1650 > URL: https://issues.apache.org/jira/browse/LOG4J2-1650 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Priority: Major > > Hello, > log4j2 is ~1.3M. It is a lot to get started with logging and several parts > are not mandatory to start and rarely needed all together like jackson, db, > yaml (this one is not that big) etc...Also saw Generate class which is quite > big but not sure it is needed at runtime and the annotation processor logic > is never needed at runtime. > Anyway, by comparison logback and log4j1 are ~500k so hopefully we could only > pay the same price to get started with log4j2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (LOG4J2-2171) Log4j2 is not embeddable due to its system classloader usage
[
https://issues.apache.org/jira/browse/LOG4J2-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau closed LOG4J2-2171.
--
> Log4j2 is not embeddable due to its system classloader usage
>
>
> Key: LOG4J2-2171
> URL: https://issues.apache.org/jira/browse/LOG4J2-2171
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Assignee: Matt Sicker
>Priority: Major
> Fix For: 3.0.0
>
>
> Hi guys,
> in several places, log4j2 enforces the system classloader to be used. I have
> a case where I isolate a classloader from the app which can have log4j2 and I
> don't want any leakage between both classloaders.
> This is current not possible. Can we have at least an option to skip this
> classloader and only use the tccl one?
> For reference: {{org.apache.logging.log4j.util.LoaderUtil#getClassLoaders}},
> {{org.apache.logging.log4j.util.LoaderUtil#findUrlResources}}, etc... are the
> places making it not working
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2171) Log4j2 is not embeddable due to its system classloader usage
[
https://issues.apache.org/jira/browse/LOG4J2-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16319252#comment-16319252
]
Romain Manni-Bucau commented on LOG4J2-2171:
Yes, doable, but keep in mind it doesnt merge props which are not read from the
same place
> Log4j2 is not embeddable due to its system classloader usage
>
>
> Key: LOG4J2-2171
> URL: https://issues.apache.org/jira/browse/LOG4J2-2171
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>
> Hi guys,
> in several places, log4j2 enforces the system classloader to be used. I have
> a case where I isolate a classloader from the app which can have log4j2 and I
> don't want any leakage between both classloaders.
> This is current not possible. Can we have at least an option to skip this
> classloader and only use the tccl one?
> For reference: {{org.apache.logging.log4j.util.LoaderUtil#getClassLoaders}},
> {{org.apache.logging.log4j.util.LoaderUtil#findUrlResources}}, etc... are the
> places making it not working
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2171) Log4j2 is not embeddable due to its system classloader usage
[
https://issues.apache.org/jira/browse/LOG4J2-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318771#comment-16318771
]
Romain Manni-Bucau commented on LOG4J2-2171:
Wondered for the prefix as well but just applied the pattern of what was
already here - I didnt add the ignore one ;). I thought of the strategy as well
but concluded a boolean was more natural. Also my flag must not use
propertiesutil which uses findUrlResources so having 2 flags is not that bad.
> Log4j2 is not embeddable due to its system classloader usage
>
>
> Key: LOG4J2-2171
> URL: https://issues.apache.org/jira/browse/LOG4J2-2171
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>
> Hi guys,
> in several places, log4j2 enforces the system classloader to be used. I have
> a case where I isolate a classloader from the app which can have log4j2 and I
> don't want any leakage between both classloaders.
> This is current not possible. Can we have at least an option to skip this
> classloader and only use the tccl one?
> For reference: {{org.apache.logging.log4j.util.LoaderUtil#getClassLoaders}},
> {{org.apache.logging.log4j.util.LoaderUtil#findUrlResources}}, etc... are the
> places making it not working
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2171) Log4j2 is not embeddable due to its system classloader usage
[
https://issues.apache.org/jira/browse/LOG4J2-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318255#comment-16318255
]
Romain Manni-Bucau commented on LOG4J2-2171:
done at https://github.com/apache/logging-log4j2/pull/140
> Log4j2 is not embeddable due to its system classloader usage
>
>
> Key: LOG4J2-2171
> URL: https://issues.apache.org/jira/browse/LOG4J2-2171
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>
> Hi guys,
> in several places, log4j2 enforces the system classloader to be used. I have
> a case where I isolate a classloader from the app which can have log4j2 and I
> don't want any leakage between both classloaders.
> This is current not possible. Can we have at least an option to skip this
> classloader and only use the tccl one?
> For reference: {{org.apache.logging.log4j.util.LoaderUtil#getClassLoaders}},
> {{org.apache.logging.log4j.util.LoaderUtil#findUrlResources}}, etc... are the
> places making it not working
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (LOG4J2-2171) Log4j2 is not embeddable due to its system classloader usage
Romain Manni-Bucau created LOG4J2-2171: -- Summary: Log4j2 is not embeddable due to its system classloader usage Key: LOG4J2-2171 URL: https://issues.apache.org/jira/browse/LOG4J2-2171 Project: Log4j 2 Issue Type: Bug Reporter: Romain Manni-Bucau Hi guys, in several places, log4j2 enforces the system classloader to be used. I have a case where I isolate a classloader from the app which can have log4j2 and I don't want any leakage between both classloaders. This is current not possible. Can we have at least an option to skip this classloader and only use the tccl one? For reference: org.apache.logging.log4j.util.LoaderUtil#getClassLoaders, org.apache.logging.log4j.util.LoaderUtil#findUrlResources, etc... are the places making it not working -- This message was sent by Atlassian JIRA (v6.4.14#64029)
