Content Feeder Actuator Endpoint for Reindexing

The Content Feeder has a new Spring Boot actuator endpoint "reindex" that can be used to trigger reindexing of selected contents. You can use this endpoint in a similar way as the existing JMX functionality.

For example, to trigger reindexing of content issues using the new actuator endpoint:

curl -i -X POST -H 'Content-Type: application/json' -d '{"aspects": "issues"}' http://localhost:40481/actuator/reindex

localhost:40481 has to be replaced by the host and HTTP port of the Content Feeder .

The example uses content issues, which are indexed since this release (see separate release note). Note, that content issues are reindexed periodically anyway, but the above command could be used if periodic reindexing is disabled in the configuration, or to reindex issues at a certain point in time.

The actuator can also be used to reindex other aspects, and it can be restricted to certain contents. For details on reindexing using the actuator or JMX, see the Search Manual's section 'Reindexing | Partial Reindexing of Content Feeder Indices".

(CMS-19291)

Reworked Commerce search API

The Commerce search API as defined in class com.coremedia.livecontext.ecommerce.catalog.CatalogService was changed. The methods accepting search parameters as a map are deprecated. A single method accepting parameters of type com.coremedia.livecontext.ecommerce.search.SearchQuery and com.coremedia.livecontext.ecommerce.common.StoreContext replaces them all: CatalogService#search(SearchQuery sq, StoreContext sc)

The paging parameters have been consolidated. The new SearchQuery parameter object does neither support pageSize nor pageNumber  because this information is redundant to limit and offset .

The new SearchQuery#offset is 0-based whereas CatalogService#SEARCH_PARAM_OFFSET was 1-based. In order not to confuse the editors the offset in the ProductList Studio form is still 1-based. The required offset conversion is implemented in all places, where the settings of product list contents are read. Custom implementations will have to be changed from searchParams.put(SEARCH_PARAM_OFFSET, Integer.toString(myOffset)) to searchQueryBuilder.setOffset(myOffset - 1) .

The method MarketingSpotService#searchMarketingSpots(String s, Map<String,String> m, StoreContext sc) has been deprecated in favor of MarketingSpotService#searchMarketingSpots(SearchQuery q, StoreContext sc) .

The methods DataSearchService#searchCategories(String s, Map<String,String> m, StoreContext sc) , DataSearchService#searchProducts(String s, Map<String,String> m, BaseCommerceBeanType b, StoreContext sc) and DataSearchService#searchMarketingSpots(String s, StoreContext sc) have been deprecated in favor of DataSearchService#search(SearchQuery q, StoreContext sc) .

Multi-facet support is included only for commerce adapter services based on base adapter 1.5. The new search implementation is backward-compatible in the sense that it works with older commerce adapter services (using base adapter older than 1.5) but then just the first facet is taken into account. Also note that the deprecated SearchResult#getFacets is only filled when connected to an old commerce adapter because the returned facet format is incompatible with the new facet format returned in SearchResult#getResultFacets .

For the backward compatibility of the commerce adapter used in your project, please consult the release notes of the commerce adapter.

(CMS-19118)

Pass Spring properties to plugins

You can now use all properties from the Spring environment of the application in your plugins. For details see section "Plugins for Java Applications > Application Properties" in the Blueprint Developer Manual.

(CMS-18986)

Third-Party Update: pf4j

org.pf4j:pf4j has been updated to 3.6.0. It is now possible to configure multiple plugin directories via the new list-valued Spring property plugins.directories . The property plugins.directory has been deprecated.

(CMS-18961)