[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16390651#comment-16390651
 ] 

Erick Erickson edited comment on SOLR-7887 at 3/8/18 6:42 AM:
--------------------------------------------------------------

All right, I see what's happening even if I don't know what the proper fix is 
yet.

in Log4J2Watcher, there's an inner class Log4j2Appender whose constructor calls:
super("*Log4j2WatcherAppender*", filter, null);

Here's the stack trace where the above is a problem:
AppenderControl.equals(185) [1]
AppenderControArraySet.add(49)
LoggerConfig.AddAppender(200)
-------------------- the above in: org.apache.logging.log4j.core.config;
Log4J2Watcher.registerListener(253)
LogWatcher.newRegisteredLogWatcher(139).

[1] equals() compares the name passed in by the 
super("*Log4j2WatcherAppender*", filter, null);
call in Log4j2Appender and since there's _already_ a "Log4j2WatcherAppender" in 
the list the new one is _not_ put in the list and the second test fails since 
nothing is logged to the new watcher..

If I declare a stupid AtomicInteger and do this:
super("Log4j2WatcherAppender" + stupid.incrementAndGet(), filter, null);
then TestLogWatcher succeeds with the duplicated test method. I have yet to 
test the full test run to see if this also cures the original problem. This is 
just to see if my theory is correct, it's nothing like a proper fix.

So the question becomes "what's the proper thing to do here?" The name passed 
in may _not_ be null, and doing some counter increment or similar trick seems 
like it could lead to a zillion appenders.


was (Author: erickerickson):
All right, I see what's happening even if I don't know what the proper fix is 
yet.

in Log4J2Watcher, there's an inner class Log4j2Appender whose constructor calls:
super("*Log4j2WatcherAppender*", filter, null);

Here's the stack trace where the above is a problem:
AppenderControl.equals(185) [1]
AppenderControArraySet.add(49)
LoggerConfig.AddAppender(200)
-------------------- the above in: org.apache.logging.log4j.core.config;
Log4J2Watcher.registerListener(253)
LogWatcher.newRegisteredLogWatcher(139).

[1] equals() compares the name passed in by the 
super("*Log4j2WatcherAppender*", filter, null);
call in Log4j2Appender and since there's _already_ a "Log4j2WatcherAppender" in 
the list the new one is _not_ put in the list and the second test fails since 
nothing is logged to the new watcher..

If I declare a stupid AtomicInteger and do this:
super("Log4j2WatcherAppender" + stupid.incrementAndGet(), filter, null);
then TestLogWatcher succeeds with the duplicated test method. I have yet to 
test the full test run to see if this also cures the original problem.

So the question becomes "what's the proper thing to do here?" The name passed 
in may _not_ be null, and doing some counter increment or similar trick seems 
like it could lead to a zillion appenders.

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> ----------------------------------------------------------------
>
>                 Key: SOLR-7887
>                 URL: https://issues.apache.org/jira/browse/SOLR-7887
>             Project: Solr
>          Issue Type: Task
>    Affects Versions: 5.2.1
>            Reporter: Shawn Heisey
>            Assignee: Varun Thacker
>            Priority: Major
>         Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to