Looks like this ~minor-ish issue isn't going to make the Solr 10 release, so we might just add an upgrade note. Such a note would read:
> If you're upgrading to Solr 10 and your configuration includes a log4j2.xml, be sure to update that configuration to replace "solr.log.dir" with "solr.logs.dir" (an added 's'). Solr will complain on startup if an older logging configuration is used. This situation is likely to happen if you use Solr's docker image with a volume created from the Solr 9 image, since Solr 9 would have initialized the volume with a log4j2.xml. Perhaps a future Solr version will not put log4j2.xml into the volume. On Sat, Sep 27, 2025 at 7:10 PM David Smiley <[email protected]> wrote: > I'm already seeing some value from my Solr upgrade test automation -- > https://github.com/apache/solr/pull/3706 > > I see that Solr 9 & 10 (at least when Dockerized) put a log4j2.xml (a > config file) into /var/solr/log4j2.xml. Note the volume is /var/solr and > of course is intended for data. This is a config file. Moving on... Solr > 9 writes its config file with "solr.log.dir" var substitution but Solr 10 > renamed that to "solr.logs.dir". When Solr 10 takes over this volume, it > successfully starts but nonetheless its console logs are spewing error > messages about it not being able to resolve solr.log.dir. I know we've got > some nifty EnvUtils sys prop deprecation migration but that would only work > if an old property is passed into the VM; it doesn't help when a config > file has old references, like here. > > In this case I'd like to see if we can get that log4j2.xml file out of > there, using one in the r/o Docker container, not in the volume. It > doesn't belong there IMO. Proposal is to remove this: > > https://github.com/apache/solr/blob/0fb94f7b38e7a7b735ce97ad8d19412e5fbd1f93/solr/docker/scripts/init-var-solr#L59 > and add/edit other stuff TBD. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley >
