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
Solved! Go to Solution.
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.
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.
If you really want to use Spring's annotation based configuration when developing Alfresco extensions, you could have a look at the Dynamic Extensions for Alfresco plugin.
...
Standard Alfresco Platform Extensions use Spring XML based configuration. With Dynamic Extensions, developers have the ability to create Alfresco Platform Extensions using Spring's annotations based configuration.
...
I don't think it is likely that Alfresco will support this by default, ever.
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.