Error loading class 'solr.ICUCollationField' whilst setting up core

I was just encountering the ICUCollationField issue with Search API Solr 4.3.7 and Solr 9.8.0, and found the previous solutions did not work, but the following two solutions did work:

1. Either add the following line to /etc/default/solr.in.sh:
$SOLR_OPTS -Dsolr.sharedLib=/opt/solr/modules/analysis-extras/lib"

2. Or copy the contents of:
/opt/solr/modules/analysis-extras/lib
to
/opt/solr/server/solr-webapp/webapp/WEB-INF/lib

Hi, I have encountered the same issue with Search API Solr 4.3.7 and Solr 9.8.0. I found the following at the Logging page of Solr config;

WARN false

d8

SolrConfig

Configset references one or more <lib/> directives,&#8203; but <lib/> usage is disabled on this Solr node. Either remove all <lib/> tags from the relevant configset,&#8203; or <strong>enable use of this feature by setting 'solr.config.lib.enabled=true'</strong>

I have taken another solution and it works.
sudo vi /etc/default/solr.in.sh

SOLR_OPTS="$SOLR_OPTS -Dsolr.config.lib.enabled=true"

Major Changes in Solr 9.8: https://solr.apache.org/guide/solr/latest/upgrade-notes/major-changes-in-solr-9.html#solr-9-8

For people running solr in containers: This can be fixed by supplying module configuration via the SOLR_MODULES environment variable.

The following value loads all the modules referenced from solrconfig.xml currently shipped by Search API Solr module:

SOLR_MODULES=extraction,langid,ltr,analysis-extras

Hello!,

As says znerol, if you edit your docker-compose.yml and you add this to the file, the issue will be fixed:

solr:
image: wodby/solr:$SOLR_TAG
container_name: "${PROJECT_NAME}_solr"
environment:
SOLR_MODULES: extraction,langid,ltr,analysis-extra

The important part is "SOLR_MODULES:"

It will be neccesary restart the container

Hello!,

As says znerol, if you edit your docker-compose.yml and you add this to the file, the issue will be fixed:

solr:
image: wodby/solr:$SOLR_TAG
container_name: "${PROJECT_NAME}_solr"
environment:
SOLR_MODULES: extraction,langid,ltr,analysis-extras

The important part is "SOLR_MODULES:"

It will be neccesary restart the container

I encountered the same issue with DDEV while upgrading Solr from version 8 to 9.

To fix it, I had to add the following to docker-compose.solr.yaml:

services:
    solr:
        build:
            args:
               SOLR_BASE_IMAGE: ${SOLR_BASE_IMAGE:-solr:9}
          environment:
              - SOLR_MODULES=extraction,langid,ltr,analysis-extras,scripting

And in .ddev/solr/conf/solrconfig.xml, I had to update the XSLTResponseWriter class:

  - <queryResponseWriter name="xslt" class="solr.XSLTResponseWriter">
  + <queryResponseWriter name="xslt" class="solr.scripting.xslt.XSLTResponseWriter">

After these changes, all communication started working correctly.

Maybe it will help someone :)

#37 got things working for me, after much hair pulling.

Thanks!

#40 solved it for me. Specifically:

          environment:
              - SOLR_MODULES=extraction,langid,ltr,analysis-extras,scripting

Was all that I needed for my ddev environment. Specifically using the latest ddev/ddev-solr.

I was re-examining this today trying to understand why I was running into the issue in the first place. Confusingly, after removing the lines I mentioned in my previous comment, and the lines mentioned in comment #4 in 💬 Error loading class 'solr.ICUCollationField' Fixed , I saw that my local solr was still automatically creating the collection instead of running into the error from before. I believe the only difference was that I had updated my config set. Looking at the git log, I saw that I had replaced versions of the module dir settings - e.g. these lines - replacing versions that looked more like the jump start templates

I'm not certain how I ended up with the jumpstart version of the config set rather than what's in the template, but this is something to be on the watch out for, as I'm thinking that the environment variable fix isn't necessary if you are using a config set generated from the correct templates.

@bburg from the Solr 9.8 release notes:

<lib/> directives have been made into an "opt-in" feature in Solr 9.8 and must be explicitly enabled if desired (using a system property or environment variable like -Dsolr.config.lib.enabled=true) If not explicitly enabled, Solr will log a warning but otherwise quietly ignore any <lib/> tags in configsets. This is a breaking change, and we apologize for the disruption, but it’s a necessary response to a number of security gaps that have come to light around this feature. <lib/> directives should be considered deprecated and will be removed entirely in Solr 10.0. Current users of <lib/> have a number of options to ensure their libraries remain on Solr’s classpath, including: SOLR_MODULES, core "lib" directories, the solr.xml <sharedLib> tag, Solr’s package manager, etc.

It follows that:

• If you have these lines (uncommented) in your config, then you are relying on a deprecated feature.
• In order to use such a config, you need to specify -Dsolr.config.lib.enabled=true on the command line.
• It is recommended to rely on SOLR_MODULES=extraction,langid,ltr,analysis-extras,... to be prepared for Solr 10