Problem with named analyzer used on a domain class's field #33
Comments
|
Thanks for the follow-up! Let me know if you need any more data. I'll have another go at this later in the day, since I still need this, and keep you posted. |
lgrignon
changed the title
|
It was indeed the solr library which was inappropriate for hibernate search, you have to use the lucene analyzers. I just pushed a new version of the example to show you how to use analyzers with this plugin: Basically, you have to use those classes: import org.apache.lucene.analysis.standard.StandardTokenizerFactory
import org.apache.lucene.analysis.core.LowerCaseFilterFactory
import org.apache.lucene.analysis.ngram.NGramFilterFactoryYou can find the details here: Please tell me if it is ok for you and I will close. |
|
Excellent! I will have a look right now. |
|
I tried installing with this configuration: gradle.buildapplication.groovyand I got this on compile: Then I tried downgrading to hibernate-search:2.1.0 (the one I had before), and got this on build: Which based on this I assumed was a problem with my application.yml GORM configuration. My project setup is like so: tree at the src/ folder in my projectwhere the Domain contains the So to solve the GORM configuration issue, I tried setting my application.yml hibernate config exactly like yours in the example project. I didn't know if I had to set this in all of my 3 projects, the one with the Domain classes and the Api and Workers which depend on it as a plugin, so I added it on all 3. {Api,Workers,Domain}/grails-app/conf/application.ymlNote: For each of this attempts I have been deleting I also attempted deleting my filesystem This error is quite obscure in that it looks like it is a problem with the xml config, but I don't know how to port this config or something like this to my application.yml. My datastore is working without hibernate-search. In fact, it was working with hibernate-search without the named analyzers. So I believe the dataStore is correct, it must be a problem maybe with the org.hibernate.dialect.MySQLDialect? I am using mariadb as a backend. |
|
On further exploration with a teammate (@erichmx), we noticed that it sometimes works and sometimes doesn't. So there could be a race condition somewhere. |
|
@lgrignon it is very weird, I can now tell you that it is not related to the analyzer, just having a And also I don't understand why the My main hypothesis is that the sessionFactoryClosed is being called when the serviceRegistry is still null This is part of the log of a successful run: And the correpondent part of a failed run log: |
|
Could you provide a link to a github with your full project please? It would be perfect to reproduce. |
|
@erichmx Thanks again for reporting |
|
@lgrignon, here is more info. I updated to hibernate-search 2.1.1. Still the same exception. Looking more closely at the stacktrace I see a potential problem: org.hibernate.search.hcore.impl.HibernateSearchSessionFactoryObserver.sessionFactoryCreated is the one closing the sessionFactory!! and without logging why. My hypothesis is that is trying to access @Override
public void sessionFactoryCreated(SessionFactory factory) {
boolean failedBoot = true;
try {
final SessionFactoryImplementor factoryImplementor = (SessionFactoryImplementor) factory;
HibernateSessionFactoryService sessionService = new DefaultHibernateSessionFactoryService( factory );
if ( extendedIntegrator == null ) {
SearchIntegrator searchIntegrator = new SearchIntegratorBuilder()
.configuration( new SearchConfigurationFromHibernateCore( metadata, configurationService, classLoaderService, sessionService ) )
.buildSearchIntegrator();
extendedIntegrator = searchIntegrator.unwrap( ExtendedSearchIntegrator.class );
}
Boolean enableJMX = configurationService.getSetting( Environment.JMX_ENABLED, BOOLEAN, Boolean.FALSE );
if ( enableJMX.booleanValue() ) {
indexControlMBeanName =
enableIndexControlBean( configurationService, extendedIntegrator );
}
listener.initialize( extendedIntegrator );
//Register the SearchFactory in the ORM ServiceRegistry (for convenience of lookup)
-->> factoryImplementor.getServiceRegistry().getService( SearchFactoryReference.class ).initialize( extendedIntegrator );
failedBoot = false;
}
finally {
if ( failedBoot ) {
-->> factory.close();
}
}
} public SessionFactory buildSessionFactory() throws HibernateException {
...
setSessionFactoryObserver(new SessionFactoryObserver() {
private static final long serialVersionUID = 1;
public void sessionFactoryCreated(SessionFactory factory) {}
public void sessionFactoryClosed(SessionFactory factory) {
-->> ((ServiceRegistryImplementor)serviceRegistry).destroy();
}
});
StandardServiceRegistryBuilder standardServiceRegistryBuilder = createStandardServiceRegistryBuilder(bootstrapServiceRegistry)
.applySettings(getProperties());
StandardServiceRegistry serviceRegistry = standardServiceRegistryBuilder.build();
sessionFactory = super.buildSessionFactory(serviceRegistry);
-->> this.serviceRegistry = serviceRegistry;
return sessionFactory; |
|
The problem with their superb exception handling is that we cannot know what root exception caused this rollback process. Did you try running grails in debug and debugging in Eclipse with Hibernate & Hibernate search sources attached? |
|
Hello again, did you manage to fix your error? Thanks |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@betoesquivel wrote:
Other than that, I am only having an issue with building a named analyzer. I am trying to build a typeahead/autocomplete for a list of Categories with a name and a code.
I am following your example for the named analayzer with apache solr
compile group: 'org.apache.solr', name: 'solr-analysis-extras', version: '3.1.0'Everything in
application.groovycompilesBut when I try to use the analyzer in the class, like so:
I get this error on compile
If I don't use the analyzer: 'ngram'
There is no error.
I was wondering if the issue is where I am importing the Analyzer's classes from or the version of grails I am using.
The text was updated successfully, but these errors were encountered: