I'm trying to test my hibernate-search code with ejb3unit, which is what I've been using to unit test all my other JPA code.

I've gotten to the point where the code compiles and runs, except my search results come up empty and "Luke" reports that the indexes are corrupted after running the test.

Does anyone have experience using ejb3unit and hibernate-search?

Is it likely that the hibernate-search hooks aren't being setup correctly by ejb3unit, and is there a way to code around that if so?

Any ideas on how I can diagnose the problem further?

Thanks in advance!

Hi,

given your description there could be various problems. Since you are writing JPA code I assume that Hibernate Annotation is included in your dependency list, hence Search should bootstrap automatically. Have you checked the log files for Hibernate and Hibernate Search output.

Depending on how you create your test data you might also need some setup code indexing it. For example, if you create your test data using JPA the index should automatically be updated, but if you eg use DBUnit or another mechanism to create test data you will have to index manually.

It would help if you would provide more information about your setup and maybe attach some log output.

--Hardy

Thanks for the reply.

I've been looking into this a bit more and I realized that I probably have two problems:

First, the lucene index isn't updated unless I commit the transaction, but my test suites never commit the transaction; I rely on the way that hibernate automatically flushes to the database before each query. I don't think that hibernate-search also flushes to the lucene index before performing a search, so I'd need to find a way to force the lucene indexes to update before querying. I tried committing the transaction manually before a search, but I think I ran into my second problem at that point.


Second, I think hibernate-search won't do anything unless I have specified certain properties in persistence.xml and the version of ejb3unit I'm using doesn't let me pass properties through when the persistence context is created. I'll have to dig into this a bit more, maybe I can find a way to set those properties after-the-fact so that search does become active, or tweak my copy of ejb3unit to allow this (but I'd rather not).

Do you have any tips or tricks on some "magic" methods I can call (I don't really care if they are a bit hackish, since I'm just using them in unit tests) to setup these properties and flush changes to disk?

Thanks!

Hi,


You are right. Normally index changes are aligned with the transaction commit. There are ways around this which might be acceptable for a unit test setup. First of all you could call FullTextSession.flushToIndexes() manually and force an index update. Or you could set hibernate.search.worker.batch_size to 1 which effectively also writes each entity change immediately into the Lucene index. Personally I favour a setup where Hibernate Search is used in a more production environment like setup. This also means that I index the test data in a transaction, eg in setUp().


Provided that you are using Hibernate Annotations, Search should bootstrap automatically. So something should happen. Per default it will use, however, a file based directory provider (for unit testing a RAM based directory is probably better). Given that you did not specify the base dir for your indexes I would expect that the index files get created relative to the current directory.

If for some reason the automatic bootstrapping does nor work you can try to enable the Search specfic even listeners manually (see "Enabling Hibernate Search and automatic indexing" in the online documentation).

I never used ejb3unit, so I don't know anything about its working, but it seems odd to me that you wouldn't be able to somehow pass properties to the the persistence context.

Maybe it also helps you to have a look how the testcases in Hibernate Search itself are configured. Have for example a look at SearchTestCase.

--Hardy

Ah you are right that search is bootstrapping, since I am getting a bunch of index files. Maybe all I need to do it set the batch_size smaller somehow. Thanks!