[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425862#comment-16425862
]
Steve Rowe edited comment on SOLR-7887 at 4/4/18 5:02 PM:
--
Reopening to address Jenkins Maven builds' compilation failures for solr-core
module, e.g. from [https://builds.apache.org/job/Lucene-Solr-Maven-7.x/172/]:
{noformat}
[mvn] [INFO] Error for project: Apache Solr Core (during install)
[mvn] [INFO]
[mvn] [INFO] Compilation failure
[mvn] cannot access org.apache.yetus.audience.InterfaceAudience
[mvn] class file for org.apache.yetus.audience.InterfaceAudience not
found
[mvn]
[mvn] [INFO]
[mvn] [INFO] For more information, run Maven with the -e switch
[mvn] [INFO]
[mvn] [INFO] BUILD ERRORS
[mvn] [INFO]
[mvn] [INFO] Total time: 53 seconds
[mvn] [INFO] Finished at: Wed Apr 04 00:54:42 UTC 2018
[mvn] [INFO] Final Memory: 297M/1626M
[mvn] [INFO]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/build.xml:679: The
following error occurred while executing this line:
: Java returned: 1
{noformat}
was (Author: steve_rowe):
Reopening to address Jenkins Maven builds' compilation failures for solr-core
module, e.g.:
{noformat}
[mvn] [INFO] Error for project: Apache Solr Core (during install)
[mvn] [INFO]
[mvn] [INFO] Compilation failure
[mvn] cannot access org.apache.yetus.audience.InterfaceAudience
[mvn] class file for org.apache.yetus.audience.InterfaceAudience not
found
[mvn]
[mvn] [INFO]
[mvn] [INFO] For more information, run Maven with the -e switch
[mvn] [INFO]
[mvn] [INFO] BUILD ERRORS
[mvn] [INFO]
[mvn] [INFO] Total time: 53 seconds
[mvn] [INFO] Finished at: Wed Apr 04 00:54:42 UTC 2018
[mvn] [INFO] Final Memory: 297M/1626M
[mvn] [INFO]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/build.xml:679: The
following error occurred while executing this line:
: Java returned: 1
{noformat}
> 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
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch,
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.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, SOLR-7887.patch, SOLR-7887.patch,
> SOLR-7887_followup_2.patch, SOLR-7887_followup_2.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
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414667#comment-16414667 ] Varun Thacker edited comment on SOLR-7887 at 3/26/18 10:33 PM: --- [~koji] while upgrading log4j.properties for prometheus [https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/conf/log4j.properties] , I see that it only has a CONSOLE appender . Any reason why it doesn't have a default file based appender as well ? If you are fine I plan on using [https://github.com/apache/lucene-solr/blob/master/solr/server/resources/log4j2.xml] configuration for prometheus as well in my subsequent patch. The second change I plan on making is while converting the log4j.properties from the test package to log4j2.xml use SYSTEM_ERR instead of SYSTEM_OUT ( what it uses currently ) The reason being all test packages today use SYSTEM_ERR ( [https://github.com/apache/lucene-solr/blob/branch_7_3/solr/solrj/src/test-files/log4j.properties#L5] for example ) and this seems to be the only package using SYSTEM_OUT . Maybe it doesn't make a difference but atleast we'll standardize it was (Author: varunthacker): [~koji] while upgrading log4j.properties for prometheus [https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/conf/log4j.properties] , I see that it only has a CONSOLE appender . Any reason why it doesn't have a default file based appender as well ? If you are fine I plan on using [https://github.com/apache/lucene-solr/blob/master/solr/server/resources/log4j2.xml] configuration for prometheus as well in my subsequent patch. > 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 >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Fix For: 7.4 > > Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, > SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.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, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887_followup_2.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
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414576#comment-16414576 ] Varun Thacker edited comment on SOLR-7887 at 3/26/18 9:13 PM: -- Follow-up patch2: - Thanks Ralph for pointing out the url structure. Patch merges and minor and major versions again and updates the ref guide to reflect the correct url structure ( untested ) - To keep the behaviour of SOLR_LOG_PRESTART_ROTATION constant ( one could turn it off ) remove from the default log4j2.xml ( tested manually ) was (Author: varunthacker): Follow-up patch2: - Thanks Ralph for pointing out the url structure. Patch merges and minor and major versions again and updates the ref guide to reflect the correct url structure ( untested ) Follow-up patch2: - Thanks Ralph for pointing out the url structure. Patch merges and minor and major versions again and updates the ref guide to reflect the correct url structure ( untested ) - To keep the behaviour of SOLR_LOG_PRESTART_ROTATION constant ( one could turn it off ) remove from the default log4j2.xml ( tested manually ) - To keep the behaviour of SOLR_LOG_PRESTART_ROTATION constant ( one could turn it off ) remove from the default log4j2.xml ( tested manually ) > 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 >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Fix For: 7.4 > > Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, > SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.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, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887_followup_2.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
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414537#comment-16414537
]
Steve Rowe edited comment on SOLR-7887 at 3/26/18 8:58 PM:
---
Java9 builds on Policeman Jenkins have been erroring out because of a
limitation of the Java code that handles {{ant check-lib-versions}}: the
{{InterpolatedProperties}} class does not handle recursive interpolation, i.e.
properties that are not of the form {{/org/name}} that refer to other
properties. E.g. from
[https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1596/]:
{noformat}
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:633: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:122: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build.xml:108: The
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/tools/custom-tasks.xml:108:
java.lang.IllegalArgumentException: named capturing group is missing trailing
'}'
at
java.base/java.util.regex.Matcher.appendExpandedReplacement(Matcher.java:1052)
at java.base/java.util.regex.Matcher.appendReplacement(Matcher.java:908)
at
org.apache.lucene.dependencies.InterpolatedProperties.interpolate(InterpolatedProperties.java:64)
at
org.apache.lucene.dependencies.InterpolatedProperties.load(InterpolatedProperties.java:50)
at
org.apache.lucene.validation.LibVersionsCheckTask.collectDirectDependencies(LibVersionsCheckTask.java:385)
at
org.apache.lucene.validation.LibVersionsCheckTask.execute(LibVersionsCheckTask.java:220)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at
org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:398)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:302)
at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:221)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393194#comment-16393194 ] Erick Erickson edited comment on SOLR-7887 at 3/9/18 6:11 PM: -- bq: The size of the patches were in the 190kb Yeah, that puzzled me too. "All tests pass". I took a look and the earlier patch has things like : 19K Mar 9 10:03 audience-annotations-LICENSE-ASL.txt. These are part of Yetus, so I'm guessing your patch has some cruft in it unrelated to log4j2. I took the yetus dependencies out as per Tomás' comments. was (Author: erickerickson): bq: The size of the patches were in the 190kb Yeah, that puzzled me too. "All tests pass", but I'll take a look to see if I can identify why the new one is smaller. > 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: Erick Erickson >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, 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
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386432#comment-16386432
]
Erick Erickson edited comment on SOLR-7887 at 3/5/18 5:53 PM:
--
And This morning it doesn't even compile if you do a fresh pull from
master. IIRC the last time I updated from master was yesterday afternoon, but
that may not be entirely accurate.
NOTE: If you want to work with trying to resolve dependencies, you need to
delete all the jars in
solr/core/lib
solr/solr-ref-guide/lib
solr/server/lib/ext
solr/solrj-test-lib
and delete ~/.ivy2/cache
what happened to me was that I removed my ivy cache as a sanity check and
precommit started failing. Eventually I found that even after "ant clean-jars",
there were left-over soft links like:
./solr/core/lib/slf4j-log4j12-1.7.24.jar ->
/Users/Erick/.ivy2/cache/org.slf4j/slf4j-log4j12/jars/slf4j-log4j12-1.7.24.jar,
apparently clean-jars doesn't remove things not in the dependencies, which
makes sense.
of course since I'd cleaned my ivy cache since
/Users/Erick/.ivy2/cache/org.slf4j/slf4j-log4j12/jars/slf4j-log4j12-1.7.24.jar
wasn't there. This did NOT show up until precommit though. Whether this is the
root of my inability to start Solr is anybody's guess. And whether that's part
of my current inability to compile (although it was working fine last night) is
also a good question. Compilation over a current pull fails with:
::
[ivy:retrieve] :: UNRESOLVED DEPENDENCIES ::
[ivy:retrieve] ::
[ivy:retrieve] :: org.slf4j#slf4j-log4j12;${/org.slf4j/slf4j-log4j12}:
not found
[ivy:retrieve] :: log4j#log4j;${/log4j/log4j}: not found
[~elyograg]
Are you talking about one of the log4j2.xml files? If so, what I did was copy
the _same_ log4j2.xml file from into three places, example/resources,
server/resources and server/scripts/cloud-scripts.
Nobody seems to know which of those three is used at what point so I decided to
make them all the same. At least they'll be consistent. I'm perfectly open to
changing them, but having all three do different things is confusing as you
well know. Until SOLR-12008 is fully addressed, I'm opting for them all being
the same, maybe a bad call..
was (Author: erickerickson):
And This morning it doesn't even compile if you do a fresh pull from
master. IIRC the last time I updated from master was yesterday afternoon, but
that may not be entirely accurate.
NOTE: If you want to work with trying to resolve dependencies, you need to
delete all the jars in
solr/core/lib
solr/solr-ref-guide/lib
solr/server/lib/ext
solr/solrj-test-lib
and delete ~/.ivy2/cache
what happened to me was that I removed my ivy cache as a sanity check and
precommit started failing. Eventually I found that even after "ant clean-jars",
there were left-over soft links like:
./solr/core/lib/slf4j-log4j12-1.7.24.jar ->
/Users/Erick/.ivy2/cache/org.slf4j/slf4j-log4j12/jars/slf4j-log4j12-1.7.24.jar,
apparently clean-jars doesn't remove things not in the dependencies, which
makes sense.
of course since I'd cleaned my ivy cache since
/Users/Erick/.ivy2/cache/org.slf4j/slf4j-log4j12/jars/slf4j-log4j12-1.7.24.jar
wasn't there. This did NOT show up until precommit though. Whether this is the
root of my inability to start Solr is anybody's guess. And whether that's part
of my current inability to compile (although it was working fine last night) is
also a good question. Compilation over a current pull fails with:
::
[ivy:retrieve] :: UNRESOLVED DEPENDENCIES ::
[ivy:retrieve] ::
[ivy:retrieve] :: org.slf4j#slf4j-log4j12;${/org.slf4j/slf4j-log4j12}:
not found
[ivy:retrieve] :: log4j#log4j;${/log4j/log4j}: not found
Shawn:
Are you talking about one of the log4j2.xml files? If so, what I did was copy
the _same_ log4j2.xml file from into three places, example/resources,
server/resources and server/scripts/cloud-scripts.
Nobody seems to know which of those three is used at what point so I decided to
make them all the same. At least they'll be consistent. I'm perfectly open to
changing them, but having all three do different things is confusing as you
well know. Until SOLR-12008 is fully addressed, I'm opting for them all being
the same, maybe a bad call..
> 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:
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371018#comment-16371018
]
Varun Thacker edited comment on SOLR-7887 at 2/21/18 6:57 AM:
--
More updates to the patch.
There is a bug which i'm looking into next :
When calling Log4j2Watcher#setLevel where category is
"org.apache.solr.update.processor" the LoggerConfig returned is "root" so if
we set it to DEBUG then the root logger changes and not just the individual
class/package
{noformat}
LoggerConfig loggerConfig = getLoggerConfig(ctx, category);{noformat}
was (Author: varunthacker):
More updates to the patch.
There is a bug which i'm looking into next :
When calling Log4j2Watcher#setLevelwhere category is
"org.apache.solr.update.processor" the LoggerConfig returned is "root" so if
we set it to DEBUG then the root logger changes and not just the individual
class/package
{noformat}
LoggerConfig loggerConfig = getLoggerConfig(ctx, category);{noformat}
> 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.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
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371018#comment-16371018
]
Varun Thacker edited comment on SOLR-7887 at 2/21/18 6:57 AM:
--
More updates to the patch.
There is a bug which i'm looking into next :
When calling Log4j2Watcher#setLevelwhere category is
"org.apache.solr.update.processor" the LoggerConfig returned is "root" so if
we set it to DEBUG then the root logger changes and not just the individual
class/package
{noformat}
LoggerConfig loggerConfig = getLoggerConfig(ctx, category);{noformat}
was (Author: varunthacker):
More updates to the patch.
There is a bug right now which i'm looking into next :
When calling Log4j2Watcher#setLevelwhere category is
"org.apache.solr.update.processor" the LoggerConfig returned is "root" so if
we set it to DEBUG then the root logger changes and not just the individual
class/package
{noformat}
LoggerConfig loggerConfig = getLoggerConfig(ctx, category);{noformat}
> 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.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
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334774#comment-16334774
]
Steve Rowe edited comment on SOLR-7887 at 1/22/18 7:28 PM:
---
{quote}I think that all of the log4j components should use a single property
for their version, instead of having "/log4j/log4j-api", "/log4j/log4j-core",
etc.
{quote}
>From the latest patch:
{noformat}
--- solr/solr-ref-guide/ivy.xml (date 1516411619000)
[...]
-
+
+
{noformat}
This will fail precommit, which requires that all {{rev}} values are exactly
{{${//}}}. The canonical way of dealing with shared versions is to
declare a {{.version}} property in {{ivy-versions.properties}} and then
use it, rather than literal versions, as the value for the properties that
should share it. E.g.:
{noformat}
com.carrotsearch.randomizedtesting.version = 2.5.3
/com.carrotsearch.randomizedtesting/junit4-ant =
${com.carrotsearch.randomizedtesting.version}
/com.carrotsearch.randomizedtesting/randomizedtesting-runner =
${com.carrotsearch.randomizedtesting.version}
{noformat}
was (Author: steve_rowe):
bq. I think that all of the log4j components should use a single property for
their version, instead of having "/log4j/log4j-api", "/log4j/log4j-core", etc.
>From the latest patch:
{noformat}
--- solr/solr-ref-guide/ivy.xml (date 1516411619000)
[...]
-
+
+
{noformat}
This will fail precommit, which requires that all {{rev}} values are exactly to
{{//}}. The canonical way of dealing with shared versions is to
declare a {{.version}} property in {{ivy-versions.properties}} and then
use it, rather than literal versions, as the value for the properties that
should share it. E.g.:
{noformat}
com.carrotsearch.randomizedtesting.version = 2.5.3
/com.carrotsearch.randomizedtesting/junit4-ant =
${com.carrotsearch.randomizedtesting.version}
/com.carrotsearch.randomizedtesting/randomizedtesting-runner =
${com.carrotsearch.randomizedtesting.version}
{noformat}
> 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
>Priority: Major
> Attachments: SOLR-7887-WIP.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
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333289#comment-16333289 ] Shawn Heisey edited comment on SOLR-7887 at 1/20/18 8:08 PM: - General observation about the ivy versions: I don't think there should be separate version strings for each component in a multi-jar system like log4j. It would be extremely unlikely for us to *ever* incorporate different versions of each of those components. For dependencies like httpcomponents, separate strings do make sense, because that project actually does have entirely separate source repositories and releases for the different jars they maintain, and the latest version numbers do not always match. Digesting all that into advice, which you're free to take or ignore: I think that all of the log4j components should use a single property for their version, instead of having "/log4j/log4j-api", "/log4j/log4j-core", etc. was (Author: elyograg): General observation about the ivy versions: I don't think there should be separate version strings for each component in a multi-jar system like log4j. It would be extremely unlikely for us to *ever* incorporate different versions of each of those components. For dependencies like httpcomponents, separate strings do make sense, because that project actually does have entirely separate source repositories and releases for the different jars they maintain, and the latest version numbers do not always match. Digesting all that into advice, which you're free to take or ignore: I think that all of the log4j components should use a "/log4j/log4j" property for their version, instead of having "/log4j/log4j-api", "/log4j/log4j-core", etc. > 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 >Priority: Major > Attachments: SOLR-7887-WIP.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
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16300958#comment-16300958 ] Ralph Goers edited comment on SOLR-7887 at 12/22/17 4:53 AM: - Log4j 2.10.0 provides AppenderSkeleton in the log4j-1.2-api jar. I verified that it solves the Hadoop issue when I migrated Flume to Log4j 2. Also, I was informed that the reason Oracle closed the issue with doclint as they consider there to be workarounds - either don't use doclint or disable annotation processing. If you have no custom Log4j plugins and no other need for annotation processing you can disable it. was (Author: ralph.go...@dslextreme.com): Log4j 2.10.0 provides AppenderSkeleton in the log4j-1.2-api jar. I verified that it solves the Hadoop issue when I migrated Flume to Log4j 2. > 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 > Attachments: SOLR-7887-WIP.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 (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198147#comment-16198147 ] Ralph Goers edited comment on SOLR-7887 at 10/10/17 4:33 AM: - If you need it, Log4j 2 could look into implementing AppenderSkeleton but it most likely would end up being a no-op so Hadoop's Appender might not do anything. That almost certainly doesn't matter since the appender would never be called by Log4j 2. If you can create a Log4j 2 Jira issue that identifies what Hadoop is trying to do perhaps we can find a way to accommodate it. Also, please note that the doclint error was captured in https://issues.apache.org/jira/browse/LOG4J2-1925. It is caused by a bug in javac as documented in http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8186647. Oracle has closed it as won't fix. The problem does not occur in Java 9. was (Author: ralph.go...@dslextreme.com): If you need it, Log4j 2 could look into implementing AppenderSkeleton but it most likely would end up being a no-op so Hadoop's Appender might not do anything. If you can create a Log4j 2 Jira issue that identifies what Hadoop is trying to do perhaps we can find a way to accommodate it. Also, please note that the doclint error was captured in https://issues.apache.org/jira/browse/LOG4J2-1925. It is caused by a bug in javac as documented in http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8186647. Oracle has closed it as won't fix. The problem does not occur in Java 9. > 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 > Attachments: SOLR-7887-WIP.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 (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198147#comment-16198147 ] Ralph Goers edited comment on SOLR-7887 at 10/10/17 4:22 AM: - If you need it, Log4j 2 could look into implementing AppenderSkeleton but it most likely would end up being a no-op so Hadoop's Appender might not do anything. If you can create a Log4j 2 Jira issue that identifies what Hadoop is trying to do perhaps we can find a way to accommodate it. Also, please note that the doclint error was captured in https://issues.apache.org/jira/browse/LOG4J2-1925. It is caused by a bug in javac as documented in http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8186647. Oracle has closed it as won't fix. The problem does not occur in Java 9. was (Author: ralph.go...@dslextreme.com): If you need it, Log4j 2 could look into implementing AppenderSkeleton but it most likely would end up being a no-op so Hadoop's Appender might not do anything. If you can create a Log4j 2 Jira issue that identifies what Hadoop is trying to do perhaps we can find a way to accommodate it. > 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 > Attachments: SOLR-7887-WIP.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 (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15311153#comment-15311153 ] Shawn Heisey edited comment on SOLR-7887 at 6/1/16 9:31 PM: I suspect that if you add log4j-jcl, commons-logging, log4j-1.2-api, and log4j-jul, you'll cover the three logging libraries which are used by dependencies. The information on the runtime dependency page says that log4j-jcl requires commons logging ... which seems odd, because I would have expected it to *implement* commons logging like jcl-over-slf4j (which is in the stock lib/ext directory) does. Edit: I just noticed that you mentioned log4j-1.2-api already, and that it didn't work. I am not sure what to say about that. was (Author: elyograg): I suspect that if you add log4j-jcl, commons-logging, log4j-1.2-api, and log4j-jul, you'll cover the three logging libraries which are used by dependencies. The information on the runtime dependency page says that log4j-jcl requires commons logging ... which seems odd, because I would have expected it to *implement* commons logging like jcl-over-slf4j (which is in the stock lib/ext directory) does. > 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 > Attachments: SOLR-7887-WIP.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 (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15311074#comment-15311074
]
Keith Laban edited comment on SOLR-7887 at 6/1/16 8:46 PM:
---
I took a stab at upgrading from log4j to log4j2, which includes porting over
the work that [~thelabdude] did over at
https://github.com/lucidworks/solr-log4j2 .. Although I'm running into some
issues. I'll do my best to document where I'm at so far.
*Changes so far:*
# Removed dependencies for log4j and slf4j-log4j12
# Added log4j2 dependencies: log4j-api, log4j-core, log4j-slf4j-impl (new slf4j
bridge)
# Deleted {{org.apache.solr.logging.log4j.\*}} and added
{{org.apache.solr.logging.log4j2.\*}} from Tim's impl
# Added Tim's Log4j2Watcher Test
# Updated {{RequestLoggingTest}} and {{LoggingHandlerTest}} for log4j2
# Updated {{SolrLogLayout}} for log4j2 (no tests?)
# Updated log4j.properties in example/resources to log4j2.xml
# Update {{bin/solr}} to use new log4j2.xml and system property
{{-Dlog4j.configurationFile}}
# This build will compile and run and LogWatcher works in admin UI as expected
*The problems i'm facing are*:
# Bringing in log4j2 dependencies for some reason is causing javac doclint to
fail with errors like "Invalid use of @throws" in random places throughout
solr. For the mean time i've changed lucene/common-build.xml to use {{}} until I can figure out
whats going on
# What finally railroaded me here is that HDFS uses log4j directly and tests
which use HDFS fail during runtime with no class found exceptions. I tried
including the log4j2-1.2 api as a stop-gap but the the nature of how hdfs uses
log4j does not allow this as a fix.
If someone wants to jump in here and help out that would be great. I think this
would be an big win for the next major release of solr.
was (Author: k317h):
I took a stab at upgrading from log4j to log4j2, which includes porting over
the work that [~thelabdude] did over at
https://github.com/lucidworks/solr-log4j2 .. Although I'm running into some
issues. I'll do my best to document where I'm at so far.
*Changes so far:*
# Removed dependencies for log4j and slf4j-log4j12
# Added log4j2 dependencies: log4j-api, log4j-core, log4j-slf4j-impl (new slf4j
bridge)
# Deleted {{org.apache.solr.logging.log4j.\*}} and added
{{org.apache.solr.logging.log4j2.\*}} from Tim's impl
# Added Tim's Log4j2Watcher Test
# Updated {{RequestLoggingTest}} and {{LoggingHandlerTest}} for log4j2
# Updated {{SolrLogLayout}} for log4j2 (no tests?)
# Updated log4j.properties in example/resources to log4j2.xml
# Update {{bin/solr}} to use new log4j2.xml and system property
{{-Dlog4j.configurationFile}}
# This build will compile and run and LogWatcher works in admin UI as expected
*The problems i'm facing are*:
# Bringing in log4j2 dependencies for some reason is causing javac doclint to
fail with errors like "Invalid use of @throws" in random places throughout
solr. For the mean time i've changed lucene/common-build.xml to use {{}} until I can figure out
whats going on
# What finally railroaded me here is that HDFS uses log4j directly and tests
which use HDFS fail during runtime with no class found exceptions. I tried
including the log4j2-1.2 api as a stop-gap but the the nature of how hdfs uses
log4j2 does not allow this as a fix.
If someone wants to jump in here and help out that would be great. I think this
would be an big win for the next major release of solr.
> 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
> Attachments: SOLR-7887-WIP.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
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
