Jonathan Halliday [
http://community.jboss.org/people/jhalliday] replied to the discussion
"beanifying the config"
To view the discussion, visit:
http://community.jboss.org/message/534687#534687
--------------------------------------------------------------
I think it's about time for another round...
Many of the remaining static initializers are concerned with taking a property value from
an EnvironmentBean and using it to instantiate a class or classes e.g.
String checkedActionFactory =
arjPropertyManager.getCoordinatorEnvironmentBean().getCheckedActionFactory();
Class factory =
Thread.currentThread().getContextClassLoader().loadClass(checkedActionFactory);
CheckedActionFactory _checkedActionFactory = (CheckedActionFactory)
factory.newInstance();
I'd like something that gives better control over
a) dynamic changes - it should not be necessary to reload the class (which basically
means restarting the server) to change the effective value. Actually this is not just an
issue for Class type properties and should probably be discussed separately.
b) type safety - ideally we'd detect problems at the point setCheckedActionFactory
was called
c) class loading, particularly with regard to availability of the class and supply of
any parameters it may need.
I'm mulling over a few alternatives, such as adding a typed version of the getter to
the EnvironmentBean
CheckedActionFactory _checkedActionFactory =
arjPropertyManager.getCoordinatorEnvironmentBean().getCheckedActionFactoryInstance();
and having some form of update synchronization between that and the
setCheckedActionFactory(String) method. That may be sync on write i.e. instantiate the
class at the point its stringified name is supplied, or it may be lazy. It may also be
desirable to add a typed setter to the EnvironmentBean:
public class CoordinatorEnvironmentBean {
public void setCheckedActionFactoryInstance(CheckedActionFactory instance) {...}
although then we have also to tackle the reverse update of the String value from the
class. However, it would allow for better beans wiring by DI frameworks compared to the
current situation. In particular, the CheckedActionFactory impl could require ctor params
and have those wired by the DI farmework, which is not possible with the current loading
mechanism.
Anybody care to venture an opinion before I pick an implementation alternative at random?
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/534687#534687]
Start a new discussion in JBoss Transactions Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]