Why is Alfresco still uses spring xml configuration files?

kaffi

Hi folks

We all know that Alfresco is running mostly on the Spring framework. In the latest SDK, they are still using bean XML configuration files.  My question is in general, why they are not moving to annotation-based configuration? I know that is possible these days also with Alfresco. It would reduce the effort during SDK upgrades a lot.

Thank you for the inputs in advance.

Regards

Kaffi

afaust

I cannot speak for Alfresco (and I feel sure I am the odd man out on this topic within the community), but as someone who has worked on Alfresco for 9 years straight now, developing non-trivial solutions / applications and needing to customise Alfresco for customers of all sizes, I have to say that XML configuration in Spring is still superior to annotation-driven configuration. I also have to work on Alfresco Process Services in one of my projects, and that product uses annotation-based dependency wiring exclusively. Everytime I need to override some of the default Alfresco components / beans to fix a bug in their code or work around, I have to perform various kinds of hacks to work around the annotation-based nature to inject my class into the mix, where in Alfresco Content Service I can often just simply define a bean override in a custom XML. At runtime, I can then potentially comment / remove that XML to (temporarily) disable the patch/override, whereas with annotation-based config I am almost always forced to recompile the entire solution (or outsource enablement / configuration properties to *.properties files, which would go against the principle of annotation-based config reducing the amount of text-based configuration).

Annotation-based configuration is great and ideally suited for any application / product that you build, own and maintain yourself, without ever giving it to any customers / communities with the premise of everything being open, accessible and easily extendable. Another requirement would be that your software is free of bugs, incorrect assumptions, design flaws or other types of issues that customers / partners / service providers have to deal with in the field, without the luxury to wait for support and without the inclination to do source-level patches on the original classes / files.

I don't know what kind of efforts you see dealing with XML files during SDK upgrades. I recently did an upgrade of a project from SDK 2.2 to SDK 4, and the only thing I needed to do was move the files from folder structure A to folder structure B - a straight move, no directory merges / files changes whatsoever.