The Registry SPI may be used by infrastructure modules which handle
persistence of settings.
Normal modules should not need to use this SPI.
Registry SPI in detail
(TBD)
The heart of the Registry SPI is BasicContext interface. Any client
implementing the SPI must implement this interface. The
ResettableContext is optional extension of the BasicContext capable to
revert modifications to their default state. The RootContext is special
extension of context which describes root of the registry hierarchy and
several of its special capabilities like searching over the whole
registry hierarchy, making pending registry modifications permanent, provides one mutex for all synchronization
Each root context must implement the RootContext.
At the moment it is not expected that some other
implementations of backend storage would exist or would be needed. The
default one provided by NetBeans (currently known as SystemFilesystem)
will be documented in separate document. It will implement
ResettableContext; it will document how defaults can be declared; it
will document how it persist binded objects (eg. first the convertor is
searched; if failed "implements Serializable" is tested; if failed
throw exceptions and reject the object); etc.
The SpiUtils class has several helper methods for creating misc Objects, Contexts, etc.
Threading Model
(TBD)
Threading model is very simple. SPI clients do not have to synchronize
anything. They must only correctly implement RootContext.getMutex()
method. The implementation of Registry APIs synchronizes all its
methods calls on this mutex. That makes API thread save and it can be
accessed from arbitrary threads without the need of client
synchronization and that SPI will be always accessed only under the
read or write lock of the SPI mutex. That also means that one client
owning exlusive write lock and modifying a context blocks the whole
registry or more precisely the root context and its hierarchy of
context descendants to which the modified context belongs.