Mongo Solr - No Qualified Conversion Service Bean Error about spring-content HOT 12 CLOSED

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.

from spring-content.

@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.

from spring-content.

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.

from spring-content.

@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.

from spring-content.

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>

from spring-content.

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()

from spring-content.

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.

from spring-content.

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?

from spring-content.

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>

from spring-content.

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

from spring-content.

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

from spring-content.

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

from spring-content.