beanifying the config

[jhalliday]

In an effort to better accommodate the assorted bean-centric configuration and dependency wiring frameworks (e.g. Spring, MC) I'm considering further changes to the way TS internals are configured.

Currently we have a property management system based on a per module Environment class (a set of named constant Strings), paired with a per module PropertyManager (which is basically a java.util.Properties). The normal usage idiom for retrieving config is something like

String theValue = mymodulePropertyManager.getPropertyManager().getProperty(mymodule.Environment.SOME_KEY);

The drawbacks of this are a) it's not type safe - theValue may need munging to a particular type, a somewhat laborious process that's repeated all over the codebase and b) the PropertyManager does not know about default values - applying one is up to the consuming code, which means they are spread all over the place as I discovered whilst trying to update the manuals.

What I'd like to do is introduce a per-module EnvironmentBean, which will simply have typesafe getters and setters for any property currently defined in the corresponding Environment class. A singleton instance of this will be created and populated by walking the properties file and calling setters accordingly. Anything not set will have a default value declared in the EnvironmentBean, making it easy to find these. Injection frameworks can retrieve this singleton and apply their own config by making additional setter calls.

Usage will therefore become of the form

MyType theValue = mymodulePropertyManager.getEnvironmentBean().getMyValue();

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

This will also reduce the desire to do this property retrieval in static blocks, as there will no longer be any significant hassle or performance overhead to retrieving it from the manager on each use. However, actually relocating the retrieval code will need careful thought - in some cases all hell will break loose if a value is changed whilst the system is running. Maybe the javabeans validation/veto mechanism or similar can eventually be used to disallow changes when the system is in certain states. Meanwhile we are no worse off than currently, as System.setProperty carries equivalent risks at present.

Thoughts?

[marklittle]

Sounds like a plan to me.

[ben.cotton2]

"jhalliday" wrote:
In an effort to better accommodate the assorted bean-centric configuration and dependency wiring frameworks (e.g. Spring, MC) I'm considering further changes to the way TS internals are configured.

[... snip ...]

What I'd like to do is introduce a per-module EnvironmentBean,

[... snip ...]

Interesting re: the consideration to "accommodate ... assorted ... dependency wiring frameworks".

1. Do any current (or past considered) parts of the TS internals' code make use of DI Singleton Beans?

2. If answer to #1 is "Yes", is it true that those TS Singleton Beans are bound exclusively to the Spring framework API (as its lone DI provider)?

3. Would the implementation of the new per-module EnvironmentBeans give any priority to considering non-Spring DI APIs (especially e.g. Guice)?

4. Is there any value (beyond academic) to considering a "DI-provider independent" approach to building these (and potentially future) TS Singleton Beans?

[ben.cotton2]

"jhalliday" wrote:


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

Nice.

[ben.cotton2]

4. Is there any value (beyond academic) to considering a "DI-provider independent" approach to building these (and potentially future) TS Singleton Beans?

Obviously there is some value to this consideration, as evidenced by the MC team's impressive plan to provide the JBoss implementation of JSR-299 ( http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246067#4246067 )

[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.

[marklittle]

"jhalliday" wrote:
1) No. The design of the code base pre-dates DI frameworks (and indeed Java) by quite a wide margin.

Are you saying we're old ;-)

"jhalliday" wrote:

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.

Noooooooo!! ;-) Don't do it. Move away from the keyboard.

[jhalliday]

> Are you saying we're old ;-)

You may think that, but I could not possibly comment.

> Noooooooo!! ;-) Don't do it. Move away from the keyboard.

You giving me the day off boss? :-)

[marklittle]

"jhalliday" wrote:

You giving me the day off boss? :-)

Now it's me who can't possibly comment ;)

[jhalliday]

So next time I casually mention I'm thinking of changing the configuration system, please stop me. Turns out there are (drum roll please...) not less than 120 configuration properties in the codebase. Not counting XTS. Got to love IDEs with refactoring support.

In place of the old config properties (and yes Mark, they are still there for backward compatibility) we now have a set of configuration beans as described previously. In general it's one per module, which the exception of ArjunaCore/arjuna which has four.

Almost all the code now uses the beans rather than accessing the property manager directly. Indeed I'm tempted to ditch the property manager entirely, but first we need to figure out if/how we want to handle persistent configuration changes.

Meanwhile there is just the marathon task of documenting each and every property. Any volunteers? :-)

[marklittle]

Yes, I'll help document them if the task is still going on.

[mmusgrov]

And I can do the ones that concern ports and hosts and ...

[jhalliday]

Time for phase two of the cunning plan to beanify the world...

- Now that the properties file is flat rather than hierarchic, it makes no sense to continue having per-module properties files. There should be a single, global properties file from which all beans are populated.

- The per-module build time properties are similarly little used, with the exception of values that could just as well be global: sourceid (i.e. svn tag) and such. Can anyone see a reason for sticking with a custom per-module build properties file, rather than using META-INF/MANIFEST.MF?

- The per-module Info.java classes and the Configuration.java classes should be removed in favour of bean properties, a method to dump the state of the EnvironmentBeans and a method to dump the global build time data, which are more useful in the modern world.

comments?

[adinn]

comments?

All sounds utterly reasonable to me.

[marklittle]

Junk it. Time moves on and requirements change. What is there needs to be changed :-)