[jboss-dev-forums] [Design of JBoss Transaction Services] - Re: beanifying the config

[jhalliday]

1) No. The design of the code base pre-dates DI frameworks (and indeed Java) by quite a wide margin. It's not particularly DI friendly. On the other hand, it does not force you to pull in a DI framework you may not want when embedding TS.

2, 3, 4) Right now JBossTS does not link against, nor provide xml wiring for, any DI framework, with the partial exception of the atsintegration module hooking into JBossAS 5 via MC.

At this stage I don't plan on introducing any compile time dependency on MC or any other framework, other than for the AS integration module.

What I do want to accomplish it to have a more bean oriented configuration mechanism so that any DI container can use that in preference to the config file, which makes for a better embedding approach.

Over time we may embrace one or more framework more fully, but first we need to deal with the lifecycle issues - part of JBossTS don't cope well with being shutdown and restarted, much less reconfigured on the fly.

> > and the type conversion and default handling code will vanish from the point of consumption.
> nice

Well, yes and no. Centralising the type conversion code is good, but moving the default handling is less of a clear cut win. In cases where only a single bit of code uses a given property, it actually results in moving the decl of the default away from its point of use. Whilst this makes configuration easier for the end user, it makes life harder for the maintenance programmer. I'm inclined to go with a hybrid approach where the bean does

private int someProp = ClassThatUsesIt.DEFAULT_VALUE;

rather than removing the DEFAULT_VALUE from ClassThatUsesIt and having the config bean do

private int someProp = <default_value>

It means bi-directional linkage between the bean the the utilizing classes, but makes for greater clarity of intent when reading either.

The other problem the bean approach brings is one we just got rid of - you have to know where a property resides before you can set it. In the old hierarchic property file format, users frequently defined a property in the wrong section and then wondered why it had no effect. That's solved by moving to a flat format, but a similar issue arises when a slew of beans enter the picture.

It's not always intuitively clear which bean contains a relevant property. At least the method and type checking will cause exceptions if you get it wrong, unlike the property file problem. The only fix I can see for this is to put all the properties (100+ of them) on a single bean, a cure which is probably worse than the disease.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246123#4246123

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246123