Until now ObjectStores have been configured using what are essentially global variables, most recently in the form of properties on a singleton instance of ObjectStoreEnvironmentBean. This causes a number of problems, including the inability to cleanly configure multiple stores with different settings and the need to add implementation specific properties to the bean even if only a small subset of implementations need them. To address this the model should be changed such that:

• store implementations take a bean as a constructor arg. StoreManager should be pretty much the only point of instantiation in the production code (unit tests are a law unto themselves) and takes care of supplying an appropriate bean instance via BeanPopulator and the 'multiple bean instances' change in JBTM-787.

• the type of the *EnvironmentBean instance should be determined by reflection on the instance constructor or such, allowing for beans to have implementation specific properties only. For example, a Dir makes no sense for the JDBC store and contrawise connection params don't apply to the filesystem based stores.

Note that as a side effect of these and earlier changes to the log format, the 'serialization' of objectstores into the log is no longer used. To reinstate it we'd need more than the original 'ObjectStoreType' stuff - a store instance is now effectively identified by impl class and config values, so we'd need to make the beans serializable too. This is a departure from the C++ version towards something more Java/DI centric.