Extending the V2 search API
If none of the bundled
ResultFilter implementations fits your requirements, you can write your own implementation.
Writing your Own SearchQuery
To illustrate how to write your own
SearchQuery, we will take a look at how the bundled
CreatorQuery was written.
First of all, you need to implement
SearchQuery. This is a generic simple Java object representing your custom search.
- Search query objects should be immutable.
- They should be constructed with all the required input to complete the query. In this case, we query on the creator username, so this is passed as a constructor parameter.
- Input should be exposed via an accessor. This will be used by the mapper, which we'll discuss below.
- Your query should have a unique key to identify it. This allows us to configure a mapper to map this type of query — more on this below.
The responsibility of the Lucene query mapper is to convert a generic search query POJO (plain old java object) to the actual Lucene search query.
- The contract of the
LuceneQueryMapperis to return a
org.apache.lucene.search.Querygiven a Confluence v2 search query object.
- We call
CreatorQueryand use it to construct the Lucene query.
Add your custom
LuceneQueryMapper as a plugin in
A new plugin type has been introduced for custom Lucene query mappers using the
lucene-query-mapper tag. You should add this to your plugin descriptor and define what v2 search query objects it can handle.
handlesattribute should be set to the unique keys you defined for your custom search query objects (that is,
CreatorQuery.KEYin this example).
- If you want to handle multiple query types with your mapper, you can declare this by specifying a
<handles>creator</handles>sub tag for each type supported.
keyattribute is a value to uniquely identify this mapper plugin.