spring component-scan and ALF-13091

[valery_antonov]

So, in 4.0, standard spring way of defining beans through annotations is broken (https://issues.alfresco.com/jira/browse/ALF-13091), and they say "we are going to fix it little bit later".

Question is - how should I write my own code? With *context.xml? Sorry, I dont have as much programmers as Alfresco has…

[afaust]

Hello,

this is the first time I have heard of component scans being used in an Alfresco context. I don't see the difference between the effort required to correctly wire beans via annotations compared to *-context.xml (which is the common practice). It is not rocket science and should not require "additional" programmers as implied. Of course, if you have already set up your annotations, you have to duplicate that effort into XML, but is it more than a day's worth?

Regards
Axel

[valery_antonov]

Alfresco has ~900KB in ~100 context files, several hundreds of beans (or may be >1000?). Messy, unmanageable heap. This is not alfresco-specific problem - to avoid that, several years ago Spring introduced annotation-based configs. I dont see any reasons why not to use annatations -it is a mainstream for Java EE development. Of course, it is up to you, for me it is much better to just put @Component on Java class, and @Autowired or @Inject on fields, than to jump between Java and xml. And yes, we already have a lot of annotated beans (~400)

Really, I dont understand why Alfresco needs all that tricks with child contexts - they didnt get much profit (may be Alfresco needs OSGi, but I doubt it is worth)

[afaust]

Hello,

the 900 KB / 100 context files of Alfresco is mainly their problem to deal with. 400 custom beans of course is a number where I can understand that it'd be a significant effort to re-create context file based bindings for. Of course, it is always kind of risky to use a different approach to development than the vendor and majority of community, irregardless of wether it is standard practice in other fields / circles - if no one else feels the pain, you are left alone to deal with a specific situation you feel uncomfortable about.

All in all, I see annotation vs. context as purely a developer preference point and there is - from my perspective - not a lot of benefit in fussing about it, as long as the way it is implemented works and there are other significant (business) features that need improving / to be added to server customers / end user needs. it is the same issue I have with certain technical aspects I dislike in Alfresco (e.g. error handling in several places, hardwiring of some modules in code rather than via Spring …). It works for > 95 % of users / developers but inconveniences me, because I have a different mindset about certain things - I recognize that there is not much benefit for Alfresco / the community, if Alfresco would fix these aspects so I don't expect them to.
If it would seriously affect me and my work, I wouldn't wait for Alfresco to fix such an issue and rather do it myself.

Regards
Axel

[valery_antonov]

Alfresco context files is my problem also I need to build custom war, changing or excluding something etc

I agree, that they have priorities, and support other developers is not the highiest priority. The problem is not the features (component scan is, let say, feature) but compatibility - it worked in 3.4, and it is broken now. Probably, I will just fix that bug myself, but not now - I dont really need to switch to 4.0, there is nothing worth in it (I dont use Activiti nor Solr)

[mrogers]

And if you ***really*** need that change then please explain why its important on the JIRA and vote for it.

At the moment there are zero votes.

[valery_antonov]

And David Ward  will return non-customer issue back from Siberia (or Odin, ok - it is also far away )? Ok, lets try

[mrogers]

I think its unlikely  :!: 

However if it is important then there's less chance of it being pushed back from Odin.

And if its one of the top voted issues then I'll look into it up myself.

[valery_antonov]

3rd party development-related issues are unlikely to be top-voted, I guess But still, thanks

BTW, where could I read about Odin etc - Alfresco roadmap is… hmm… All that crazy story with Activiti just killed it, with one feature I was ready to vote for planned for Swift and abandoned - composite fields