[jboss-dev-forums] [JBoss Transactions Development] - beanifying the config

[Jonathan Halliday]

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&containerType=14&container=2041]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20100330/d71f20f2/attachment.html