JDK 11 is required for Broadleaf release trains 1.7.0-GA, and beyond.
JDK 17 is supported for Broadleaf release trains 1.8.1-GA, and beyond.
Introduced the new parameter categoryProductMembershipFilters
in the search request that is used to check if a related product is a member of the specified category.
Only applies when the category’s product membership type is RULE_BASED.
It should be used instead of ruleFilters
. For example, categoryProductMembershipFilters.rule=${category#productMembershipRule}
.
This new parameter is needed to split the general filters and the filters for the products when searching the products for the RULE_BASED
category.
With this change, the Solr query will look like (get products for the category id OR categoryProductMembershipFilters.rule) AND (filter products by ruleFilters.rule
.
Previously the filters didn’t work correctly because it built the Solr query like get products for the category id OR ruleFilters.rule
which is incorrect because we need to use AND instead of OR.
Fixed potential to lose "reindex" alias and associated collection during reindex process.
Previously, there were circumstances where a Solr reindex was kicked off and the background aliases and collections were not recreated, only deleted. This could occur when a Solr reindex was initiated and a subsequent shutdown or redeploy happened. This would leave Solr in a bad state that was detected by SolrConnectionValidator
causing the problem.
SolrConnectionValidator
has been changed to ensure that only the foreground collections are validated.
Additionally, DefaultSolrCloudAdminProvider#recreateAlisas(String)
now detects if an alias or associated collection is missing and recreates them on the fly.
Note that this functionality assumes that aliases are named as such: '{domain}_alias_{focus}, where domain is the type of index and the focus is either '1' or '2', where '1' is foreground and '2' is background or reindex alias. For example: catalog_alias_1 (foreground) or catalog_alias_2 (background).
Additionally, this assumes that collections assigned to these aliases match a similar naming convention: '{domain}_collection_{id}', where {id} is either '1' or '2'. For example, `catalog_collection_1 or catalog_collection_2. ** These changes should transparently fix issues where an alias or collection is deleted but not recreated during a reindex process, especially where a reindex node is shut down, potentially leaving things in bad state.
This should be completely transparent to clients or implementors unless they have changed the default collection or alias naming convention. While unlikely, if the default names of aliases or collections have been changed, consider overriding DefaultSolrCloudAdminProvider#resolveCollectionNameForAlias(String, ClusterStatus, Map<String,String>, Map<String,Map<Object>>)
and DefaultSolrCloudAdminProvider#resolveAlternateNameForCollectionName(String)
.