XWIKI-20477: Upgrade to Solr 9

[tmortagne]

Jira URLs

XWIKI-20477: Upgrade to Solr 9.4.1 and Lucene 9.8.0
XWIKI-12955: Upgrade to JAX-RS 2.1.6 (JSR370)
XCOMMONS-2407: Upgrade to Antlr 4.13.1
XWIKI-21709: Upgrade to Jetty Client 10.0.19
XWIKI-12674: Replace Restlet with Jersey
XWIKI-19813: Automatically migrate Solr cores when the major version changes

Changes

Description

The main goal was to upgrade to Solr 9.

But upgrading Solr also requires:

• Upgrade to JAX-RS 2.1
• Upgrade to Jetty Client 10.0.19+
• Upgrade to Antlr 4.11.1+

To make migration of some cores from Solr 8 to Solr 9 easier (which means having both versions of the core usable at the same time) the naming of the cores changed a bit: they are now all suffixed with the major version of Solr.

A new XWikiSolrCore was introduced to hold various information about the core. We used to pass around the SolrClient, but it's missing some information like the core name, and it will be interesting to have a more obvious location to put some Solr core related tool.

Anything that was using Restlet classes (quite a lot more than expected...) moved to using pure JAX-RS APIs (and in some rare cases Servlet API).

Clarifications

JAX-RS and Jersey

Solr moved to JAX-RS 2. Problem is that Restlet is not compatible with it so we had to find another implementation and since Solr uses Jersey now as JAX-RS implementation, moving to Jersey ourselves is what made the most sense (even if there are other implementations of JAX-RS 2.1).

Restlet had quite a lot of non JAX-RS standard hacks and while I kept some that I have hit during tests (for example forcing a specific media type through the URL parameter ?media=json) I did not keep everything. Those are mainly located in org.xwiki.rest.internal.PreMatchingRequestFilter.

While JAX-RS fixed quite a few Restlet bugs in the implementation of javax.ws.rs.core.UriBuilder it's very possible that someone might have relied on one of those bugs. For example, I found code in org.xwiki.test.ui.TestUtils which was expecting / to not be escaped in elements passed to UriBuilder#build (which does not really make any sense).

We are proxying the internal tool used by Jersey to do injection because XWiki JAX-RS components (anything implementing org.xwiki.rest.XWikiRestComponent) are expected to be XWiki components too with full support of the XWiki component system (and especially injection of other XWiki component and other XWiki component related tools and metadata). Another consequence is that we had to take care of the injection of JAX-RS javax.ws.rs.core.Context annotated fields on XWiki side.

Antlr 4.10+

Any lexer which was built with Antlr <4.10 won't work anymore (for example, it's the case of the dokuwiki syntax parser).

Executed Tests

Not much in terms of new tests, but those changes impact most integration tests (anything which manipulates an XWiki REST endpoint or Solr).

There is still one planned integration test: add an XWiki upgrade test with custom data containing Solr 8 cores.

Expected merging strategy

• Prefers squash: No
• No backport

[vmassol]

Any lexer which was built with Antlr <4.10 won't work anymore (for example, it's the case of the dokuwiki syntax parser).

So this is a breaking change we need to document in the backward-compat section of the RN, right?

Are there any other breaking changes you know of? (for example does the move to Jersey has impacts that we need to mention in the RN?).

Thanks for your work on this! Looks complex

[michitux]

Given my comments on the Solr core migration, is there any test that implicitly or explicitly tests Solr core migration? I didn't see any, but maybe I missed it.

[tmortagne]

Are there any other breaking changes you know of? (for example does the move to Jersey has impacts that we need to mention in the RN?).

Yes, I mentioned stuff that Restlet was adding (like some other special URL parameters) which I did not keep because it was not documented or used anywhere in XWiki.

There is also simply the fact that Restlet was full of bugs and, as usual in such cases, someone might have relied on one of those bugs (I indicated an example in the PR description)...

[tmortagne]

Given my comments on the Solr core migration, is there any test that implicitly or explicitly tests Solr core migration? I didn't see any, but maybe I missed it.

Not yet, I plan to add an XWiki upgrade test based on a custom data which contains a Solr 8 with cores from back then.

[tmortagne]

I plan to add an XWiki upgrade test based on a custom data which contains a Solr 8 with cores from back then

Done, the upgrade test is based on custom XWiki 12.10.1 data.