There seems to be some inconsistency between how run modes are handled by the replication agent configuration and by other configurations in AEM.
For reference, i am using AEM 6.2, com.adobe.granite.replication.core:6.0.14
At issue here is the fact that when multiple run modes are appended to a replication agent group, they are evaluated with an OR operation.
Let me give an example. The obvious run modes that everyone will be familiar with is "author" and "publisher"; thus, you will typically have replication agents found under both /etc/replication/agents.author and /etc/replication/agents.publish.
Now, we know that when doing OSGI configurations, a group of configurations applies if, and only if, it matches all of the runmodes. Thus, the run modes can be used to restrict the configurations. Lets say that for your production set you applied the run mode "prod" to all of the AEM instances.
It would then make sense to have configurations that are:
- config.author //applies to all author instances
- config.author.prod //applies to only prod author instances
- config.publish //applies to all publish instances
- config.publish.prod //applies to only prod publish instances
- config.prod //applies to all prod instances, both author and publish
- config //applies to all instances
Now that we understand the behaviour for OSGI configurations; i would expect the same sort of run mode based configuration logic to apply to replication agent configurations as well. However, if i use the following replication agent group:
- /etc/replication/agents.author.prod
it does not mean agents for prod author instances (as it would with OSGI configurations). Instead, it means that these replication agents are applicable for any author or prod instance. So an instance with the run modes "prod, publish" would apply because it has prod, as would "author, test" because it has author.
I fail to see any utility in this. Adding more run modes doesn't further constrain the configurations, it actually relaxes the constraints.
Additionally, when looking at the code I see that there is a special carve-out for using * to mean "all run modes". Given how this actually works, that could have simply been accomplished by placing replication agents at /etc/replication/agents.author.publish. That special case, which doesn't need to exist, makes me feel like the run modes should have been evaluated with an AND condition, in which case there might be some use to having a wildcard.
We would like to place our replication agents under SCM, and not have to juggle having different repositories for each set of servers. We already do this with everything else (such as OSGI) configurations, such that deploying to or updating an instance can largely be automated. As it stands now, we can't do that with replication agents because I cant make configurations like the following:
- agents.prod.author
- agents.prod.publish
- agents.test.author
- agents.test.publish
- etc.
in the above example, on an instance with the run modes "prod, author". The first 3 sets of replication agents all apply. Is i said; I fail to see any utility in this behaviour.
If you wanted some configuration to apply to two different run modes, then why wouldn't you just add a common run mode to all those machines, as they surely share something in common.
Does anyone have an example where the current behaviour is of any benefit?
Is there any way, with the existing behaviour, to accomplish what we want?
Changing this behaviour consists of changing 2 lines in "AgentConfigGroupImpl", does anyone see any reason the behaviour shouldn't be changed to just be the same as other configurations?
Thanks,
Kyle
