Community

beanifying the config

reply from Jonathan Halliday in JBoss Transactions Development - View the full discussion

> I was suggesting that we change all of our classes to not cache the return value from the bean and always call the bean

 

Indeed. I'm likewise suggesting we do that, but noting that it is a separate, more complex, problem than I'm looking to solve in the short term. For now I'll settle for moving the classloading responsibility into the bean.

 

> For instance, if there's no setter defined then it has to be one that can only be defined at start-up and not programmatically

 

which misses the point of DI. There has to be a setter or the framework (Spring/JBossMC) can't set a value in the first place. The startup IS programmatic. Even our standalone propertyFile->Bean loading works by reflection on the setters now.

Reply to this message by going to Community

Start a new discussion in JBoss Transactions Development at Community