Slides from my Alfresco DevCon 2018 30min talk about common patterns of patching the base bundles for Alfresco Content Services (ACS) and Alfresco Processes Services (APS), including summaries of advantages / drawbacks for each pattern. The recording of the talk will be uploaded to the Alfresco YouTube channel sometime in the next days / weeks.

1. Axel Faust, Acosix GmbH

2. Patch Handling Patterns

3. Disclaimer(s)
●
●
8 years ACS vs. 1 year APS
●
ACS / APS = complex beasts ; 30 min = short
●
Naturally: patching / “messing around“ rarely appreciated
(my skills)∩(graphical slide wizardry)=∅

4. Necessity of Patching
●
Personal Alfresco JIRA statistics
– Not including customer support issues
– Two issues rejected due to age (2+ years)
JIRA issues since 2014
0
5
10
15
20
25
30
35
40
45
Open
Resolved
Rejected
Avg. days
0 50 100 150 200 250 300 350 400
Resolved
Open

5. Necessity of Patching
●
Statistics from collaboration update @ BeeCon 2017
●
11.75 % fixed
●
64.46 % rejected

6. Necessity of Patching
●
Alfresco issue priorities
– Triage: make issues actionable or close
– Resources: only if high profile or aligned with roadmap
– Support: continuation of operation / work-around
●
„Something is broken? Help yourself, hack the source“
(BeeCon 2016 t-shirt)

7. Pattern Overview
●
Source Patching
●
Defined Override Paths
●
Spring Overrides
●
Spring Post-Processing
●
Augmentation / Extension (JS)
●
I18n Patching

8. Pattern: Source Patching
●
Modify original Alfresco code and re-build artefacts
a) Full source clone + build
b) Track only changed files + repackage
●
Baselines
– ACS: SVN / GitHub
– APS: sources ZIP (no build routine)
–
Patched JARs: ¯_( ツ )_/¯ (only Greenmail / Tika @ GitHub)

9. Pattern: Source Patching
●
Various Challenges
– Comparing / tracking changes
– Build correctness
– Unsuited for addon providers
●
Last resort, unless
– Given no choice (APS UI / „private“ monoliths in Java)
– Providing PR / patch for Alfresco
– Collaboration on „soft“ forks, i.e. LXCommunity

10. Pattern: Defined Override Paths
●
Explicit ACS file overrides via lookup
– Repo / Share web scripts
– Surf models / templates
●
Surf DependencyHandler => „implicit“ override
1. Remote resource
2. classpath*:path
3. classpath*:/META-INF/path
4. webapp:path

11. Pattern: Defined Override Paths
●
„First found wins“ problems
– Explicit + implicit „hiding“ via classloader
– Conflict detection / info?
●
Reserved for end-user / customer
– Grey-ish: override to add extension points

12. Pattern: Spring Override
<bean id="SiteService_security" class="org.alfresco.repo.security.permissions.impl.acegi.MethodSecurityInterceptor">
<property name="authenticationManager"><ref bean="authenticationManager"/></property>
<property name="accessDecisionManager"><ref bean="accessDecisionManager"/></property>
<property name="afterInvocationManager"><ref bean="afterInvocationManager"/></property>
<property name="objectDefinitionSource">
<value>
org.alfresco.service.cmr.site.SiteService.cleanSitePermissions=ACL_NODE.0.sys:base.ReadProperties
org.alfresco.service.cmr.site.SiteService.createContainer=ACL_ALLOW,AFTER_ACL_NODE.sys:base.ReadProperties
org.alfresco.service.cmr.site.SiteService.createSite=ACL_METHOD.GROUP_SITE_CREATORS
org.alfresco.service.cmr.site.SiteService.deleteSite=ACL_ALLOW
org.alfresco.service.cmr.site.SiteService.findSites=ACL_ALLOW,AFTER_ACL_NODE.sys:base.ReadProperties
org.alfresco.service.cmr.site.SiteService.getContainer=ACL_ALLOW,AFTER_ACL_NODE.sys:base.ReadProperties
org.alfresco.service.cmr.site.SiteService.listContainers=ACL_ALLOW,AFTER_ACL_NODE.sys:base.ReadProperties
<!-- …. -->
org.alfresco.service.cmr.site.SiteService.hasSite=ACL_ALLOW
org.alfresco.service.cmr.site.SiteService.isMember=ACL_ALLOW
org.alfresco.service.cmr.site.SiteService.listMembers=ACL_ALLOW
org.alfresco.service.cmr.site.SiteService.listMembersInfo=ACL_ALLOW
org.alfresco.service.cmr.site.SiteService.listMembersPaged=ACL_ALLOW
org.alfresco.service.cmr.site.SiteService.listSiteMemberships=ACL_ALLOW
org.alfresco.service.cmr.site.SiteService.listSites=ACL_ALLOW,AFTER_ACL_NODE.sys:base.ReadProperties
org.alfresco.service.cmr.site.SiteService.listSitesPaged=ACL_ALLOW,AFTER_ACL_NODE.sys:base.ReadProperties
org.alfresco.service.cmr.site.SiteService.removeMembership=ACL_ALLOW
org.alfresco.service.cmr.site.SiteService.canAddMember=ACL_ALLOW
org.alfresco.service.cmr.site.SiteService.setMembership=ACL_ALLOW
org.alfresco.service.cmr.site.SiteService.updateSite=ACL_ALLOW
org.alfresco.service.cmr.site.SiteService.countAuthoritiesWithRole=ACL_ALLOW
org.alfresco.service.cmr.site.SiteService.isSiteAdmin=ACL_ALLOW
org.alfresco.service.cmr.site.SiteService.*=ACL_DENY
</value>
</property>
</bean>

13. Pattern: Spring Override
●
Virtually impossible in APS
– @Component / @Service disallow „override by ID“
– Beans referenced by type: @Primary
●
Issues
– Adapting to changes on release
– Import order tug-of-war
– Conflicts with vendor modules („bad boy“ RM)
– Unsuitable for addon providers

14. Pattern: Spring Post-Processing
●
Run-time augmentation
– Definitions: BeanDefinitionRegistryPostProcessor /
BeanFactoryPostProcessor
– Beans: BeanPostProcessor
●
APS-specific
– @Component
– @Configuration in com.activiti.conf + @ComponentScan/@PropertySources

15. Pattern: Spring Post-Processing

16. Pattern: Spring Post-Processing
●
Smart(er) post-processing
– Configurable enablement, conditional applications
– Dependencies + respect for other changes (merge)
YYYY-MM-DD HH:mm:ss,sss INFO [...] [localhost-startStop-1] [...] patch will not be applied - class of bean webscripts.container does not match expected
implementation org.alfresco.repo.web.scripts.RepositoryContainer

17. Pattern: Spring Post-Processing

18. Pattern: Spring Post-Processing
Extremely simple
example implemenation

19. Pattern: Spring Post-Processing
●
Benefits
– Usable in ACS + APS
– Dis-/enableable without rebuild
– Potentially adaptive to environment
– Suitable for addon providers
●
Issues
– Conflicts with uncoordinated / naive post-processors (again, RM)
– Order dependant on classpath / scanning order
– No out-of-the-box „share-global.properties“ for consolidated enablement config

20. Pattern: Augmentation / Extension (JS)
●
ACS/YUI: custom JS loaded via config / Surf extension module

21. Pattern: Augmentation / Extension (JS)
●
Aikau or APS: Extend + switch

22. Pattern: Augmentation / Extension (JS)

23. Pattern: Augmentation / Extension (JS)
●
ACS/Aikau: Replace / augment module fragments

24. Pattern: Augmentation / Extension (JS)
●
ACS/Aikau: Replace / augment module fragments

25. Pattern: Augmentation / Extension (JS)
●
Aikau „global patching“: loading via service / root module

26. ●
Ideally no change to source JS
=> APS: no need to split/re-aggregate file
●
Complexity of transitive call chain
●
Monolithic modules with inaccessible internals
(i.e. callback/promise/listener-hell in APS)
●
Limited ability to check base versions + adapt
Pattern: Augmentation / Extension (JS)

27. Pattern: I18n Patching
●
ACS: web script customisation (Surf extension module)
●
ACS/YUI: custom resource bundle
●
ACS/Aikau: patcher + custom i18n scope

28. Pattern: I18n Patching
●
APS: source patch only
– ./i18n/locale.json per sub-app (editor / workflow / idm…)
– Potential: JSON diff + merge via build
●
ACS i18n priorities: most specific + last loaded
– global < argument scope (Alfresco.util.message)
– global < page < default < module-static < configured scope(s)
(module:alfresco/core/Core#message)
– Share global < web script local < web script customisation

29. Time‘s (Almost/Already?) Up
●
No „one size fits all“ pattern(s)
●
Recommendation summary
– Prefer runtime-/extension-based patching
– Override/source patching as last resort
– Alfresco: need better extension / patching points

30. Thanks
Axel Faust
Twitter: @ReluctantBird83
IRC #alfresco: AFaust