Not sure if I understood correctly your question, but you can use sling run.mode to determine which instance the code is running on, see
1 person found this helpful
Jan, the way it works is for each CQ instance you can configure the Exteranlizer. When you get the Exeternalizer Service within CQ, it will only return the single configured service. If you want different configs between environments (prod, stage, test, etc) - you would need to configure the Externalizer differently on each environment. You can do this manually as illustrated in the attached image via the Felix Console, or you can use use osgi config nodes and leverage sling run modes as pacoolsky suggested (using sling run modes is the proper way).
Hope this helps
one of the latest cq-commons releases, and as far as I unterstood from the very first cq 5.5 version anyway, introduced a more detailed Link Externalizer configuration object.
It now exposes an additional domain property, with 3 separate values by default (local, author, publish), and several methods to retrieve those ones accordingly.
The general idea suits me well. I was still missing, though, the how to identify the instance running my bundle (author/publish).
Sling run modes you both suggested turn out to be exactly what I needed, sorry for my ignorance.
Thanks a lot guys.
Have a nice day
No, coding in runmode in your app code is the wrong solution - what you want is to have different externalizer configs depending on the runmode (as ootb), and use "local" in your case.
This purely depends on what link you want to generate:
- should later point to publish (even if created on author instance) -> use "publish"
- should point to author (even if created on publish instance, rare case, but for intranet situations maybe) -> use "author"
- should point to the current instance -> use "local" (this is not "localhost", but you have to configure that differently on instances, e.g. for author runmode this config would be the same as the "author" domain, in publish runmode "local" = "publish" domain)
Not sure what you mean by 'coding in runmode', but sth's telling me it's not the case. Perhaps the way I expressed myself was somehow misleading.
We do have several externalizer configs, as we can't relate on the default local/author/publish ones.
Having several projects running on each instance we need strict, site-specific external (internet) domains, each different from another.
Therefore the concept of pointing to a specific externalizer config property, based on the runmode was already familiar to us.
My issue, instead, was to keep my bundle as generic as possible, being able to replicate it author to publish with no updates required.
Means, no run mode hardcoded in it, or any property values whatsoever. Retrieving the run mode of the instance it's running on suits my case well then.
"Retrieving the run mode of the instance" <- that's what I mean with "coding in runmode". Code should usually never ask for the runmode (via sling settings service), but you should have a service that has your specific semantics as configuration options, and these are differently configured in different runmodes, i.e. by having different sling:OsgiConfig nodes in config.author, config.publish etc.
In your case of multiple sites I would replicate the ootb constants per site: local-<site>, author-<site>, publish-<site> (if you really need all 3 to differentiate between author and publish, maybe just <site> is enough). Then all you need is to call externalizer.externalLink(resolver, "<site>", "/path") in your code, and have different runmode configs for the externalizer service.