Keep up the blogging!

After a few years of springin’ – I think that having “sensible defaults” saves you a lot of over-springin’. I still want the OPTION of injecting something – but by default – I want a sensible constructor overload and/ or a setter aviailable as a “seam” when I need it. This gets rid of much of the over-springin’ IMO.

As to annotations – I do not like to decorate my actual target classes with ANYTHING like this stuff. This is why I opted for an approach where I still have POCO’s (except in the container-aware scenarios where I need a handle to the factory) – that are not embellished with any container info – just a config – like spring – and a container “up high” in the app that pulls it all together.

As to “overriding the annotations” – the answer is no – BUT the deeper answer is – it is not needed because you can have different configs’ just like in spring. In fact, you can get a good degree of reuse as well by simply using composed sets of glue cofigs. You can import a config using composition. You then put your environmental depends and per-enviroment variations in configs that are small – and import the main configs – just like I have done using spring.

Since they all lie outside your actual code – you can again think of them as the same as a spring config. In fact – if you package them by themselves, you can wire your hard dependencies to the cofig package alone and your other packages have not a clue – they just ref your core abstractions.

There it is:)

I hope you are well – and that Sunguard is treating you all well these days. My best to Solomon next time you see him.

-Chris

To me the main value of a Spring XML config file is that you can get an understanding of how an application works – the main components, how they are related, maybe even the “workflow” of the application – much quicker than digging through lots of code.

The downside of the pure-XML approach is that it is easy to get caught up with defining everything in Spring XML, which has a few nasty side effects (just ask my colleague Solomon – http://jroller.com/page/Solomon?entry=compiling_xml_for_faster_startup).

Where possible, therefore, I lean towards defining only the top level application objects and “workflow” components in Spring XML and use annotations for the rest.

One question on Glue: Do you have the option of overriding the annotations? For example, in a test env you may want the object to be prototype but in the main app you need the same object to be configured as a singleton.