Attributes on Demand

Problem Statement

ApacheDS provides several services which inject several attributes into entries in search responses. These attributes are not physically stored in the backend but are provided on demand at run time. Examples include injection of "top" object class value in objectClass attribute in SchemaService, injection of collective attributes in CollectiveService. The problem with this approach is that those injected attributes cannot be evaluated in search operations because the search engine (as implemented in partitions) relies at the very core of the system. All those injections happen in the interceptor chain which sits on top of the partition implementations. So a search filter like (objectClass=top) will not work as simply expected in ApacheDS.

Proposed Solution

Provide a simple virtualization layer on top of partition implementations. This layers works between partition implementations and search engine implementations in order to intercept entry retrieval codes and feed in desired attributes into those entries. So the search engine will not even know that it's working with virtual attributes although it will work as expected.

To make this abstraction those interfering points should be determined. As an example, the lookup method in org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition class should be refactored.

The virtualization layer can itself be a chain of interceptors to allow easy management of different services as virtual attribute providers.