Definieer alleen een op opslagplaats gebaseerde configuratie voor een specifieke instantie

Dit artikel schetst een op bewaarplaats-gebaseerde configuratie voor een specifieke instantie, die hoe te om configuratie in de bewaarplaats van CRX als knopen van nodetype het slingeren:OsgiConfig in Adobe Experience Manager op te slaan.

Beschrijving description

Milieu

Adobe Experience Manager

Uitgave/Symptomen

Dit artikel definieert een op gegevensopslagruimte gebaseerde configuratie voor een specifieke instantie.

Resolutie resolution

1. Configureer de Apache Felix Web Management Console

De configuratie op de Console van het Beheer van het Web van de Felix van Apache ( http:// < gastheer > :< haven > /system/console/configMgr ) is altijd specifiek voor de huidige instantie.
U kunt een beschrijving in de documentatie vinden: https://helpx.adobe.com/nl/experience-manager/6-4/sites/deploying/using/configuring-osgi.html#OSGiConfigurationintheRepository

2. Configuratie op basis van opslagplaats

Het is ook mogelijk om configuratie in de gegevensopslagplaats van CRX als knopen van nodetype te bewaren:OsgiConfig.

Voor meer informatie, zie https://helpx.adobe.com/nl/experience-manager/6-4/sites/deploying/using/configuring-osgi.html#OSGiConfigurationintheRepository

Met deze methode, is het mogelijk om configuratie onder verscheidene instanties te delen.
De naam van deze knooppunten moet gelijk zijn aan de PID (Persistent Identity) van de configuratie (bijvoorbeeld de naam van de service). Als u http:// < gastheer > bekijkt:< haven > /system/console/configMgr , ziet u deze namen die als dienst.pid eigenschappen worden vermeld. Deze configuratieknooppunten moeten onderliggende knooppunten van nodetype nt:omslag zijn met een naam die met config begint die met een punt wordt gevolgd. Alle runtime-wijzen waarop config van toepassing is worden ook gescheiden met een punt.

Voorbeelden: config.author, config.publish, config.signer.dev, config.author.foo.dev

looppas-Wijze

Het is mogelijk om te bepalen op welke specifieke runtime-modi een specifieke instantie wordt uitgevoerd. Een auteurinstantie wordt standaard uitgevoerd in de uitvoeringsmodus en een publicatie-instantie wordt uitgevoerd in de uitvoeringsmodus. Het is mogelijk verschillende uitvoeringsmodi te definiëren voor één instantie (bijvoorbeeld auteur, foo en dev).

Stel deze uitvoeringsmodi in als VM-opties.

Bijvoorbeeld op de console:

java -Dsling.run.modes=author,foo,dev -Xmx256m -jar aem64-quickstart.jar

of in het beginscript:

# default JVM options
CQ_JVM_OPTS='-Dsling.run.modes=author,foo,dev'

De huidige looppas-wijzen van een instantie zijn zichtbaar in http:// < gastheer > :< haven > /system/console/status-slingsettings

Nota: het wordt niet geadviseerd om de standaard runtime-wijzen auteur te veranderen of te verwijderen en te publiceren. Voeg in plaats daarvan gewoon uw specifieke uitvoeringsmodi toe aan de standaardlijst met bestaande uitvoeringsmodi.

Nota: het zelfde mechanisme werkt voor de op bewaarplaats-gebaseerde bundelinstallatie. Plaats de bundels onder knooppunten van nodetype nt:omslag met een naam die met installatie begint, gevolgd door een punt. Alle uitvoeringsmodi waarop de bundels van toepassing zijn, worden gescheiden met een punt.

Voorbeeld: om een specifieke SMTP mailserverconfiguratie voor al uw instanties te hebben die op runtime-wijze foo lopen, creeer eenvoudig een knoop met naam config.foo en nodetype nt:omslag in /apps/wij-retail en kopieer de knoop /libs/cq/config/com.day.cq.mailer.DefaultMailService aan /apps/we-retail/config.foo en pas eigenschappen smtp.host aan.

Voorbeeld: om een specifieke configuratie van de Logrotation te hebben, gebruik het configuratiepakket in het KB- artikel hoe te request.log en access.logroteren en anders noemen de knoop config bijvoorbeeld aan config.foo als de config voor al uw instanties zou moeten worden genomen die op runtime-wijze slechts lopen.