Hi again, hardy is right. Here is a longer version of the proposal (that is more discussion friendly): Okay. Let me explain my idea with this little example: We have a fulltext enabled search that takes multiple parameters. For easier usage we have a parameter-wrapper similar to this: public class PlaceQueryBean { private String name; public String getName() { return this.name; } public void setName(String name) { this.name = name; } } This is just a shortened version with only one parameter. But if we wanted to write a Hibernate Search Query, it would look similar to this: queryBuilder.term().onField("name").matching(queryBean.getName())... As the parameters get more the query gets bigger and bigger and you have to "manually" retrieve the data out of the Query-Bean (which is easier to use than vanilla Lucene queries, but you are still required to write a lot of boilerplate code). In my Extension a query like that would only have to be added to the class via annotations. You only have to write the query-structure and lose the hand written queries. And another big plus: The query logic is in the exact same spot where the data is (and not in the service). @Queries(@Query(must = @Must(@SearchField(fieldName = "name", propertyName = "name")))) public class PlaceQueryBean extends BaseQueryBean { private String name; public String getName() { return this.name; } public void setName(String name) { this.name = name; } } Yes that's correct, but I am thinking which methods of the BeanInterface can be moved to the Annotations. And by these "callback"-methods from the Searcher you can still build normal Hibernate-Search queries. Yes. Yes. What do you mean by that? Normally you would pass a Bean that has a list of values. Which junction to use there is specified in the SearchField Annotation via the betweenValues() property. Yes. You can pass a optional profile value to the Searcher. I plan on moving most of the stuff that has to be hand-written to bean declarations (Sorts, Filters, etc.) Do you need to modify core functionality or could this I don't think I'd need to modify any core functionality. I hope I have done better this time :). Martin Braun martinbraun123(a)aol.com www.github.com/s4ke -----Original Message----- From: Hardy Ferentschik <hardy(a)hibernate.org&gt; To: Martin Braun <martinbraun123(a)aol.com&gt; Cc: Hibernate <hibernate-dev(a)lists.jboss.org&gt; Sent: Mon, Feb 3, 2014 9:13 pm Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search Hi Martin, great that you like Hibernate Search and want to make it even easier to use. On 3 Jan 2014, at 19:08, Martin Braun <martinbraun123(a)aol.com&gt; wrote: finished, but I had a quick look at the code, but for the sake of discussion, it would be great if you could outline your approach in an email. Maybe with some example code? It would make it much easier for everyone interested to see what you want to achieve. Let me try to sum your approach up from what I read in the readme and glancing at the code. Please correct me from where I am wrong. Your approach is bean driven, where the bean defines the query parameters you have for a given query. You also created a set of annotations which allow you to specify the query via annotations on the bean. When you create a Searcher you pass it the bean and the parameter values. From there is query is build and executed for you. Is this correct? How would you provide multiple parameters and how do you select a given query in a bean (it seems you envision the possibility to provide more than one). Is this correct? What are your plans? Can you maybe share your vision for this extension? How would you envision to integrate it with Search? Do you need to modify core functionality or could this be an optional “search” module? —Hardy