Sets the Search engine index connecion string.

Controls Compass registration through JNDI, using Compass JNDI lookups.

Controls Compass automatic properties, and property names.

Compass supports several transaction isolation levels. More information about them can be found in the Search Engine chapter.

Please read more about how Compass::Core implements it's transaction management in the Search Engine section.

When using the Compass::Core transaction API, you must specify a factory class for the CompassTransaction instances. This is done by setting the property compass.transaction.factory. The CompassTransaction API hides the underlying transaction mechanism, allowing Compass::Core code to run in a managed and non-managed environments. The two standard strategies are:

An important configuration setting is the compass.transaction.commitBeforeCompletion. It is used when using transaction factories that uses synchronization (like JTA and Spring). If set to true, will commit the transaction in the beforeCompletion stage. It is very important to set it to true when using a jdbc based index storage, and set it to false otherwise. Defaults to false.

Although the J2EE specification does not provide a standard way to reference a JTA TransactionManager, to register with a transaction synchronization service, Compass provides several lookups which can be set with a compass.transaction.managerLookup setting (thanks hibernate!). The setting is not required since Compass will try to auto-detect the JTA environment.

The following table lists them all:

The JTA transaction mechanism will use the JNDI configuration to lookup the JTA UserTransaction. The transaction manager lookup provides the JNDI name, but if you wish to set it yourself, you can set the compass.transaction.userTransactionName setting. Also, the UserTransaction will be cached by default (fetched from JNDI on Compass startup), the caching can be controlled by compass.transaction.cacheUserTransaction.

Property accessors are used for reading and writing Class properties. Compass comes with two implementations, field and property. field is used for directly accessing the Class property, and property is used for accessing the class property using the property getters/setters. Compass allows for registration of custom PropertyAccessor implementations under a lookup name, as well as changing the default property accessor used (which is property).

The configuration uses Compass support for group properties, with the compass.propertyAccessor group prefix. The name the property accessor will be registered under is the group name. In order to set the default property accessor, the default group name should be used.

Custom implementations of PropertyAccessor can optionally implement the CompassConfigurable interface, which allows for additional settings to be injected into the implementations.

Compass uses converters to convert all the different OSEM mappings into Resources. Compass comes with a set of default converters that should be sufficient for most applications, but does allow the extendibility to define custom converters for all aspects related to marshaling Objects and Mappings (Compass internal mapping definitions) into a search engine.

Compass uses a registry of Converters. All Converters are registered under a registry name (converter lookup name). Compass registers all it's default Converters under lookup names (which allows for changing the default converters settings), and allows for registration of custom Converters.

The following lists all the default Converters that comes with Compass. The lookup name is the lookup name the Converter will be registered under, the Converter class is Compass implementation of the Converter, and the Converter Type acts as shorthand string for the Converter implementation (can be used with the compass.converter.[converter name].type instead of the fully qualified class name). The default mapping converters are responsible for converting the meta-data mapping definitions.

Defining a new converter can be done using Compass support for group settings. compass.converter is the prefix for the group. In order to define new converter that will be registered under the "converter name" lookup, the compass.converter.[converter name] setting prefix should be used. The following lists all the settings that can apply to a converter definition.

Note, that any other setting can be defined after the compass.converter.[converter name]. If the Converter implements the org.compass.core.config.CompassConfigurable, it will be injected with the settings for the converter. The converter will get all the settings, with settings names without the compass.converter.[converter name] prefix.

For example, defining a new Date converter with a specific format can be done by setting two settings: compass.converter.mydate.type=date (same as compass.converter.mydate.type=org.compass.core.converter.basic.DateConverter), and compass.converter.mydate.format=yyyy-HH-dd. The converter will be registered under the "mydate" converter lookup name. It can than be used as a lookup name in the OSEM definitions.

In order to change the default converters, simply define a setting with the [converter name] of the default converter that comes with compass. For example, in order to override the format of all the dates in the system to "yyyy-HH-dd", simple set: compass.converter.date.format=yyyy-HH-dd.

Controls the different settings for the search engine.

The following section lists the different optimizers that are available with Compass::Core. Note that all the optimizers can be scheduled or not.

Compass allows storing the index in a database using Jdbc. When using Jdbc storage, additional settings are mandatory except for the connection setting. The value after the Jdbc:// prefix in the compass.engine.connection setting can be the Jdbc url connection or the Jndi name of the DataSource, depending on the configured DataSourceProvider.

It is important also to read the Jdbc Directory Appendix. Two sections that should be read are the supported dialects, and the performance considerations (especially the compound structure).

The following is a list of all the Jdbc settings:

With Compass, multiple Analyzers can be defined (each under a different analyzer name) and than referenced in the configuration and mapping definitions. Compass defines two internal analyzers names called: default and search. The default analyzer is the one used when no other analyzer can be found, it defaults to the standard analyzer with English stop words. The search is the analyzer used to analyze search queries, and if not set, defaults to the default analyzer (Note that the search analyzer can also be set using the CompassQuery API). Changing the settings for the default analyzer can be done using the compass.engine.analyzer.default.* settings (as explained in the next table). Setting the search analyzer (so it will differ from the default analyzer) can be done using the compass.engine.analyzer.search.* settings. Also, you can set a list of filter to be applied to the given analyzers, please see the next section of how to configure analyzer filters, especially the synonym one.

Compass comes with core analyzers (Which are part of the lucene-core jar). They are: standard, simple, whitespace, and stop. See the Analyzers Section.

Compass also allows simple configuration of the snowball analyzer type (which comes with the lucene-snowball jar). An additional setting that must be set when using the snowball analyzer, is the compass.engine.analyzer.[analyzer name].name setting. The settings can have the following values: Danish, Dutch, English, Finnish, French, German, German2, Italian, Kp, Lovins, Norwegian, Porter, Portuguese, Russian, Spanish, and Swedish.

Another set of analyer types comes with the lucene-analyzers jar. They are: brazilian, cjk, chinese, czech, german, greek, french, dutch, and russian.

You can specify a set of analyzer filters that can then be applied to all the different analyzers configured. It uses the group settings, so setting the analyzer filter need to be prefixed with compass.engine.analyzerfilter, and the value after it is the analyzer filter name, and then the setting for the analyzer filter.

Filters are provided for simpler support for additional filtering (or enrichment) of analyzed streams, without the hassle of creating your own analyzer. Also, filters, can be shared across different analyzers, potentially having different analyzer types.

With Compass, multiple Highlighters can be defined (each under a different highlighter name) and than referenced when using CompassHighlighter. Within Compass, an internal default highlighter is defined, and can be configured when using default as the highlighter name.

Several other settings that control compass.