SearchResultSetProcessor customization

The following is a description of the changes to how InfoSphere® MDM uses custom SearchResultSetProcessor.

Before OSGi

Custom SearchResultSetProcessor (implementations of the com.dwl.base.search.interfaces.ISearchResultSetProcessor interface) were simply added to a library of the EAR and configured in the SEARCHSQL table. The search framework used reflection to resolve the class. It didn’t matter in which .jar file the Java™ class resided: the application-wide class loader could find the search ResultSet processor class using reflection, and could load it.

For more information, see Custom SQL search queries and Adding pre-written SQL queries.

With OSGi

The search framework is unchanged. However, because the actual SearchResultSetProcessor customization can potentially be found in any bundle, you must indicate to the context class loader where the customization resides in order to avoid a ClassNotFoundException exception. The search framework will use this information to locate the custom SearchResultSetProcessor.

Before calling the search framework (that is, the SearchComponent. executeSearch() API), the caller must specify the classloader where the custom SearchResultSetProcessor can be resolved. This is done using the thread’s current context classloader.

Here’s an example:

ClassLoader cl = Thread.currentThread().getContextClassLoader();
	try{
		// set context classloader to the custom rule/bundle where Custom SearchResultSetProcessor lives
			Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader()); 
						
			//execute search
			SearchComponent searcher = new SearchComponent();
	
			searchRes = searcher.executeSearch(searchInput);
	}
	finally{
		// set back original context CL
			Thread.currentThread().setContextClassLoader(cl);
	}

In this example, the caller of the SearchComponent.executeSearch() API and the custom SearchResultSetProcessor class are both in the same bundle, OR the custom SearchResultSetProcessor class is at least visible to the caller's bundle by virtue of the import package. Thus, using this.getClass().getClassLoader() to get the classloader allows the custom SearchResultSetProcessor to get resolved.