[
https://jira.jboss.org/browse/JBTM-788?page=com.atlassian.jira.plugin.sys...
]
Jonathan Halliday closed JBTM-788.
----------------------------------
Resolution: Done
Done, although we're pushing the limits of what our BeanPopulator can handle. We need
to revisit the question of using a full injection framework for bean wiring.
refactor ObjectStore init/config
--------------------------------
Key: JBTM-788
URL:
https://jira.jboss.org/browse/JBTM-788
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Configuration, Transaction Core
Affects Versions: 4.12.0
Reporter: Jonathan Halliday
Assignee: Jonathan Halliday
Fix For: 4.13.0
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira