Mongo Solr - No Qualified Conversion Service Bean Error

[bradykurtz]

When setting up spring-content to use both mongodb and solr I am getting a runtime error on spring startup. I am following these instructions

Field contentConversionService in org.springframework.content.solr.FullTextSolrIndexingConfig required a single bean, but 4 were found:
       - mongoStoreConverter: defined by method 'mongoStoreConverter' in internal.org.springframework.content.mongo.config.MongoStoreConfiguration
       - mvcConversionService: defined by method 'mvcConversionService' in class path resource [org/springframework/boot/autoconfigure/web/servlet/WebMvcAutoConfiguration$EnableWebMvcConfiguration.class]
       - defaultConversionService: defined by method 'defaultConversionService' in class path resource [org/springframework/data/rest/webmvc/config/RepositoryRestMvcConfiguration.class]
       - solrConversionService: defined by method 'solrConversionService' in class path resource [internal/org/springframework/content/solr/boot/autoconfigure/SolrAutoConfiguration.class]

I believe this is stemming from the Configuration Class FullTextSolrIndexingConfig.

My dependencies in my pom file look like this thus far:

<dependencies>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-actuator</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-data-rest</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-data-mongodb</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web</artifactId>
		</dependency>
		<dependency>
			<groupId>com.github.paulcwarren</groupId>
			<artifactId>spring-content-mongo-boot-starter</artifactId>
			<version>${spring.content.version}</version>
		</dependency>
		<dependency>
			<groupId>com.github.paulcwarren</groupId>
			<artifactId>spring-content-renditions-boot-starter</artifactId>
			<version>${spring.content.version}</version>
		</dependency>
		<dependency>
			<groupId>com.github.paulcwarren</groupId>
			<artifactId>spring-content-rest-boot-starter</artifactId>
			<version>${spring.content.version}</version>
		</dependency>
		<dependency>
			<groupId>com.github.paulcwarren</groupId>
			<artifactId>spring-content-solr-boot-starter</artifactId>
			<version>${spring.content.version}</version>
		</dependency>
		<dependency>
			<groupId>org.apache.solr</groupId>
			<artifactId>solr-solrj</artifactId>
			<exclusions>
				<exclusion>
					<groupId>org.codehaus.woodstox</groupId>
					<artifactId>wstx-asl</artifactId>
				</exclusion>
				<exclusion>
					<artifactId>log4j</artifactId>
					<groupId>log4j</groupId>
				</exclusion>
			</exclusions>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-devtools</artifactId>
			<scope>runtime</scope>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
		</dependency>
	</dependencies>

I also have my SolrClient Configured:
@Bean public SolrClient solrClient(){ return new HttpSolrClient.Builder(environment.getProperty("solr.host")).build(); }

My Mongo GridFsTemplate is also configured. I am running my mongo, solr, and my spring boot app in a docker environment using docker-compose for now.

[paulcwarren]

Thanks, @bradykurtz. I was unable to reproduce this with the dependencies you listed and a standard @SpringBootApplication configured application; i.e. no other annotations other than the @SpringBootApplication.

I was, however, able to reproduce it when I added additional configuration to component scan of the org.springframework.content.solr package. This forced the FullTextSolrIndexingConfig configuration class (that you noted) to be loaded causing the issue.

So, I wonder if your application is somehow scanning this package? Perhaps you have a @ComponentScan("org.springframework.content.solr") annotation or perhaps your application is re-using that package?

If it isn't that simple/obvious then maybe you could commit a small project in that reproduces the issue into your github org and point me at it? Then I can take a closer look and see if I can figure out what is going on there.

[bradykurtz]

@paulcwarren Thanks for responding so quickly. Your right I do not have just @SpringBootApplication. I do have have the following annotations:

@SpringBootApplication
@EnableMongoRepositories
@EnableMongoStores
@EnableFullTextSolrIndexing
@Import(HypermediaConfiguration.class)

I also pushed a demo (with instructions on how to run) of what I have so far to reproduce the error. You can find it here

Please let me know if you have any trouble. Thanks in advance for looking at this.

[paulcwarren]

Hi @bradykurtz, thanks for sharing that project. That was very helpful. So, yes it is the @EnableFullTextSolrIndexing annotation. That isn't required when using spring boot. Boot adds this annotation for you and auto-configures solr beans when and only if you need them. Adding that annotation forces the creation of additional solr beans regardless, leading to bean resolution error.

In fact, you dont actually need @EnableMongoRepositories or @EnableMongoStores either. In essence, when using Spring Boot these features are automatically enabled or turned on by putting the relevant dependencies on the classpath. We usually only add these annotations when not using Spring Boot or when the need arises to override settings like basePackages (that instructs Spring Data/Content where to look for Repositories/Stores).

Whilst testing I did actually find a bug in our search REST endpoint when used with mongodb (there is actually a gap in our test coverage that we will fix moving forwards) so if you are planning to submit searches via the search REST endpoint; i.e. GET <repository>/searchContent/findKeyword?keyword= you may want to camp on 0.4.0-SNAPSHOT until we release 0.4.0. Apologies for that.

[bradykurtz]

@paulcwarren Thanks. I have removed the Enable Annotations in the repo. I also tried to update to 0.4.0-SNAPSHOT and I can't find that in the maven repo. My thought was to use the spring content REST endpoints. However since I could not update to 0.4.0-SNAPSHOT I setup a simple Rest Controller. I could Autowire my Mongo Repo in just fine but my ContentStore is not being picked up as a bean and thus I can not Autowire it. This is checked into the repo. I believe my dependencies are correct. I am stepping through the code now and If I can find my error I will let you know.

[paulcwarren]

You're right. SNAPSHOT versions are not available from maven central. Sorry! If you want 0.4.0-SNAPSHOT (or any build of head in fact) then you should add the following to your POM:

	<repositories>
		<repository>
			<id>snapshots</id>
			<name>nexus</name>
			<url>https://oss.sonatype.org/content/repositories/snapshots</url>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
		</repository>
	</repositories>

[bradykurtz]

Thanks Paul. I was able to pull it down. Do you know why ContentStore beans are not able to be autowired?

I can see in the MongoContentAutoConfigureRegistrar the interface is picked up and added to the registry.

I am getting:

Method threw 'org.springframework.content.commons.repository.StoreAccessException' exception. Cannot evaluate com.sun.proxy.$Proxy88.toString()

[paulcwarren]

I think I know what is happening here. If you inspect a content store proxy (in intellij) the inspector popup does give you that weird proxy error. I think we need to add toString implementation on our store proxy class, or something like that. Will investigate. But actually if you drill down on that proxy you'll see it has a target correctly set to an instance of DefaultMongoStoreImpl. So I think you are good. That proxy will implement your interface and when you make calls on it, the proxy will forward them onto the generic DefaultMongoStoreImpl implementation class.

As a test I also added the Spring Data/Content REST dependencies and was then able to use postman to add new assets, associate content with those assets and do fulltext searches.

[paulcwarren]

I fixed that second issue whilst on a plane yesterday and pushed to origin/master so it will be available to you if you use 0.4.0-SNAPSHOT and for your dependencies to update (mvn -U).

Regardless, did you see your content store being auto-wired?

[bradykurtz]

I tested the auto-wire functionality before pulling down the latest snapshot. As you suspected it was autowiring correctly. I pulled down the latest snapshot and it fixed what I was seeing. Thanks so much. I am still working on successfully setting content. I am getting a solr error now (404 not found /solr/update/extract). This is my first time using solr so I am probably doing something wrong. It does appear to be getting father though now as expected.

org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://localhost:8983/solr: Expected mime type application/octet-stream but got text/html. <html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<title>Error 404 Not Found</title>
</head>
<body><h2>HTTP ERROR 404</h2>
<p>Problem accessing /solr/update/extract. Reason:
<pre>    Not Found</pre></p>
</body>
</html>

[paulcwarren]

Yeah, solr is a whole thing. Perhaps, I can explain how we set up out acceptance tests. That might help.

Our acceptance tests download and use solr 7.5.0 (older 7.x version will likely work though) and start it with <solr install dir>/bin/solr start -e dih. This starts solr with an example configuration that we know has the extraction handler configured. In this configuration is a core (index), also called 'solr'.

We configure the solr client bean to point to the solr instance and to the solr core; i.e.

    @Bean
    public SolrClient solrClient(){
         return new HttpSolrClient.Builder("http://localhost:8983/solr/solr")).build();
    }

where http://localhost:8983/solr addresses the solr instance itself and the remaining solr adfdresses the 'solr' core.

HTH

[paulcwarren]

Hi @bradykurtz. Where are we on this? Do you need more assistance at all? If not, ok if I close?

[paulcwarren]

Closing due to inactivity. Feel free to re-open if you need anything else.