For people working with Hibernate to manage their objects' persistence, Hibernate search is a real savior. After trying to develop similar functionality (collecting all objects changes and sending them to a full text search engine upon transaction commit) you find out pretty fast that there are lots of pitfalls out there.
On the other hand Solr has some significant advantages (like 1:m facets if you need it) which make it a better decision on some scenarios.
Since Hibernate Search is written in a very extendable way, it turns out there is an easy option to combine both together. This way you get Hibernate Search to do all the Hibernate monitoring hard work and collecting all changes, while you can use Solr to do all searches and faceting work.
By configuring Hibernate Search default worker backend with the "hibernate.search.default.worker.backend" configuration parameter ( or by configuring Hibernate Search to forward all changes through JMS) you can catch all changes in a very convenient format and forward them to Solr using the SolrJ client interface.
Although in most scenarios you will probably prefer working with Hibernate search for both updates and queries, if for some reason you need Solr and you use Hibernate, you can still get a lot from Hibernate search.
You can build a system in a very short time where FTS fields are annotated using Hibernate Search annotations and all updates end up in the Solr server. Then you can use Solr for queries and configure it to return only the IDs of the relevant documents / objects. Afterwards you can use the Ids list with hibernate to translate the list to hibernate objects.
Any comments / inputs are always welcomed...
If you are intrested I've written a small example which shows the main concepts at: