Migrating custom Java classes

You can migrate custom Java classes either by reusing them where applicable, or reimplementing them in an alternative way.

Procedure

If you previously created a custom project for search-related customizations, you must import the project into your new environment.
For example, the WebSphereCommerceServerExtensionsLogic project is not configured under the search EAR application. Either configure it, or create your own utility project and add it to the Search EAR application class path. You can also use a similar project under the Search EAR, SearchServerExtensionsLogic. For more information, see Creating a custom project for search-related customizations.
Reusing custom expression providers.

Most custom expression providers can be reused without any changes in the search server, as the search server supports Selection Criteria objects and control parameters.
Reusing custom processors.

All custom search query preprocessors can be reused in the search server, as search query preprocessors operate on the native physical SolrQuery object that is defined in the AbstractSolrSearchQueryPreprocessor parent class that all preprocessors extend from, which is also available in the search server.

Search query result postprocessors might require reimplementation. If your custom code operates on the native QueryResponse object, the custom code is reusable. However, if the custom postprocessor operates on the SolrCatalogNavigationViewImpl, it cannot be reused.

Alternatively, change your custom code to operate on the SearchResponse.
For example, the following snippet shows how to use the SearchResponse:
```
List<Map<String, Object>> catalogEntryViews = (LinkedList<Map<String, Object>>)iSearchResponseObject.getResponse().get("external object name");
```
Where the object name is the external object name. For more information about resolving external names, see the sample custom postprocessors in the wc-search.xml file.
Reimplementing custom search query result filters.

Custom result filters operate on the logical CatalogNavigationViewType noun. This logical noun is not supported in the search server. All custom result filters must be reimplemented by using search query postprocessors instead.

The catalogEntryViewList for result filters used a list of CatalogEntryViewType objects. However, in the search query postprocessor, it is instead a list of Map objects.
For example, the following code exists in the search query result filters:
```
CatalogNavigationViewType catalogNavigationView = (CatalogNavigationViewType) dataObject;

List<CatalogEntryViewType> catalogEntryViewList = catalogNavigationView
				.getCatalogEntryView();
```
The following snippet is an alternative approach to use on a search query postprocessor:
```
List<Map<String, Object>> catalogEntryViews = (LinkedList<Map<String, Object>>)iSearchResponseObject.getResponse().get("external object name");
```
Where the external object name is the external object name of the catalogEntryView.
Reimplementing Business Object Mediators.

Business Object Mediators operate on the logical CatalogNavigationViewType noun. This is not supported on the search server. Instead, an alternative to use is search query postprocessors, which are used by default. All custom mediators that extend the AbstractReadBusinessObjectPartMediatorImpl parent class must be reimplemented by using search query postprocessors.