Nale\u017cy pami\u0119ta\u0107, \u017ce ka\u017cdy z nich zosta\u0142 stworzony do konkretnego celu i zgodnie z dobrymi praktykami nie powinien by\u0107 u\u017cywany w spos\u00f3b niezgodny z przeznaczeniem.<\/p>\n\n\n\n
- \n
- Run Modes \u2013 <\/strong>powinny by\u0107 wykorzystywane do danych zwi\u0105zanych ze \u015brodowiskiem, np. konfiguracje autora lub publish.<\/li>\n\n\n\n
- Konfiguracje OSGi \u2013 <\/strong>najlepiej stosowa\u0107 je do nieedytowalnych przez autor\u00f3w systemowych konfiguracji, takich jak: schedulery, serwisy, cache, integracje.<\/li>\n\n\n\n
- Page Properties \u2013 <\/strong>dobrze nadaj\u0105 si\u0119 do konfiguracji zachowania pojedynczej strony, ale s\u0142abo si\u0119 skaluj\u0105 i s\u0105 trudne w zarz\u0105dzaniu przy du\u017cych projektach. Nie powinno si\u0119 tam przechowywa\u0107 informacji technicznych.<\/li>\n\n\n\n
- Niestandardowe strony konfiguracji \u2013 <\/strong>zwykle s\u0105 elastyczne, ale wymagaj\u0105 dodatkowego rozwoju i dalszego utrzymania.<\/li>\n\n\n\n
- Sling Context\u2011Aware Configuration \u2013 <\/strong>w t\u0119 opcj\u0119 zag\u0142\u0119bimy si\u0119 dok\u0142adniej w dalszej cz\u0119\u015bci artyku\u0142u.<\/li>\n<\/ul>\n\n\n\n
Sling Context\u2011Aware Configuration<\/strong><\/h2>\n\n\n\n
Zgodnie z dokumentacj\u0105, Context\u2011Aware Configurations (CAC) to konfiguracje powi\u0105zane z konkretnym zasobem lub drzewem zasob\u00f3w, np.: stron\u0105, stron\u0105 g\u0142\u00f3wn\u0105 witryny czy tenantem. Obs\u0142uguj\u0105 one:<\/p>\n\n\n\n
- \n
- dziedziczenie \u2013 nie trzeba ustawia\u0107 warto\u015bci na ka\u017cdej stronie poddrzewa,<\/li>\n\n\n\n
- fallback \u2013 warto\u015bci s\u0105 wyszukiwane a\u017c do korzenia konfiguracji.<\/li>\n<\/ul>\n\n\n\n
Domy\u015blna implementacja przechowuje dane pod \u015bcie\u017ck\u0105\/conf, zapewniaj\u0105c dodatkowe fallbacki. Konfiguracja jest powi\u0105zana z poddrzewem tre\u015bci poprzez w\u0142a\u015bciwo\u015b\u0107 sling:configRef, wskazuj\u0105c\u0105 na odpowiedni w\u0119ze\u0142 konfiguracji. Wszystkie zasoby pod tym poddrzewem pr\u00f3buj\u0105 znale\u017a\u0107 odpowiednie konfiguracje, przechodz\u0105c w g\u00f3r\u0119 hierarchii, je\u015bli to konieczne.<\/p>\n\n\n
\n\/content\n \/tenant1\n @sling:configRef="\/conf\/tenant1"\n \/region1\n @sling:configRef="\/conf\/tenant1\/region1"\n\t \/site1\n @sling:configRef="\/conf\/tenant1\/region1\/site1"\n \n\/conf\n \/tenant1\n \/sling:configs\n \/x.y.z.MyConfig\n @prop1 = 'tenant1"\n \/region1\n \/sling:configs\n \/x.y.z.MyConfig\n @prop1 = 'region1"\n\t \/site1\n \/sling:configs\n \/x.y.z.MyConfig\n @prop1 = 'site1'\n<\/pre><\/div>\n\n\n
Dane konfiguracyjne s\u0105 przechowywane pod w\u0119z\u0142em sling:configs, a same w\u0119z\u0142y konfiguracji s\u0105 nazwane zgodnie z nazwami klas, np.
x.y.z.MyConfig<\/code>, i zawieraj\u0105 pola, np. prop1.<\/p>\n\n\n\nJak zobaczymy w dalszej cz\u0119\u015bci, mechanizm ten jest bardzo elastyczny.<\/p>\n\n\n\n
Interfejsy konfiguracji<\/strong><\/h3>\n\n\n
\n@Configuration(label="Configuration", description="Sample configuration")\npublic @interface MyConfig {\n\n @Property(label="Parameter #1", description="Describe me")\n String param1();\n}\n<\/pre><\/div>\n\n\nS\u0105 to zwyk\u0142e interfejsy z adnotacjami @Configuration i @Property. Mo\u017cliwe jest r\u00f3wnie\u017c tworzenie konfiguracji zagnie\u017cd\u017conych oraz tablic:<\/p>\n\n\n
\n@Configuration(label="Configuration List", description="Sample list configuration")\npublic @interface MyConfigList {\n\n @Property(label="Key Value Pairs", description="List of key value pairs")\n KeyValue[] keyValues();\n\t\n\t@interface KeyValue {\n\t\t@Property\n\t\tString key();\n\t\t\n\t\t@Property\n\t\tString valye\n\t}\n}\n<\/pre><\/div>\n\n\nOdczyt konfiguracji<\/strong><\/h3>\n\n\n
\nResource contentResource = resourceResolver.getResource("\/content\/tenant1\/region1\/site1\/page1");\nMyConfig config = contentResource.adaptTo(ConfigurationBuilder.class).as(MyConfig.class);\n<\/pre><\/div>\n\n\nJak wida\u0107, jest to bardzo wygodne rozwi\u0105zanie, poniewa\u017c ca\u0142a logika zwi\u0105zana z dostarczaniem w\u0142a\u015bciwego kontekstu, wyszukiwaniem warto\u015bci p\u00f3l, dziedziczeniem oraz mechanizmem fallback jest obs\u0142ugiwana przez bibliotek\u0119 Context-Aware Configuration, bez konieczno\u015bci pisania jakiegokolwiek w\u0142asnego kodu. Warto r\u00f3wnie\u017c wspomnie\u0107, \u017ce Sling CAC jest cz\u0119\u015bci\u0105 standardowej instalacji OOTB AEM.<\/p>\n\n\n\n
Co jednak, kiedy mamy specjalne wymagania, a mimo to chcieliby\u015bmy nadal korzysta\u0107 z CAC?<\/strong> Na szcz\u0119\u015bcie, biblioteka pozwala dostosowa\u0107 j\u0105 do naszych potrzeb.<\/p>\n\n\n\n
Dostosowanie i adaptacja do potrzeb projektu<\/strong><\/h2>\n\n\n\n
Potencjaln\u0105 wad\u0105 przechowywania danych konfiguracyjnych w CAC jest brak przyjaznego, out-of-the-box interfejsu u\u017cytkownika do edycji konfiguracji. Obecnie konfiguracj\u0119 mo\u017cna zmienia\u0107 jedynie poprzez dostarczanie jej wraz z paczk\u0105 kodu albo bezpo\u015brednio w narz\u0119dziu CRXDE.<\/p>\n\n\n\n
Ale co w przypadku, kiedy chcemy, aby autorzy mogli edytowa\u0107 przynajmniej cz\u0119\u015b\u0107 konfiguracji i j\u0105 publikowa\u0107?<\/strong> Na szcz\u0119\u015bcie da si\u0119 to zrealizowa\u0107 przy u\u017cyciu niewielkiej ilo\u015bci w\u0142asnego kodu do edycji i zapisu danych \u2013 co wa\u017cne, nadal korzystaj\u0105c ze wszystkich zalet CAC przy ich odczycie.<\/p>\n\n\n\n
Przyjrzyjmy si\u0119 scenariuszowi, w kt\u00f3rym chcieliby\u015bmy po\u0142\u0105czy\u0107 przechowywanie danych na zwyk\u0142ych stronach, jako zwyk\u0142e komponenty, a jednocze\u015bnie odczytywa\u0107 te warto\u015bci w ustandaryzowany spos\u00f3b.<\/p>\n\n\n\n
Za\u0142\u00f3\u017cmy struktur\u0119:<\/p>\n\n\n
\n\/content\n \/tenant1\n \/region1\n\t \/site1\n\t \/configuration \u2013 configuration page\n\t \/jcr:content\n\t \/myconfig \u2013 configuration component\n\t @prop1 = \u201cvalue\u201d\n<\/pre><\/div>\n\n\n
gdzie istnieje specjalna strona konfiguracyjna z instancjami komponent\u00f3w przechowuj\u0105cych poszukiwane przez nas warto\u015bci p\u00f3l.<\/p>\n\n\n\n
W pierwszej kolejno\u015bci musimy zaimplementowa\u0107 interfejs ContextPathStrategy:<\/p>\n\n\n
\n@Component(\n service = ContextPathStrategy.class\n property = {\n \u201cservice.ranking.integer:1000\u201d \n }\n}\npublic class CustomContextPathStrategy implments ContextPathStrategy {\n private static final String CONFIG_PAGE = "configuration";\n \n @Override\n public Iterator<ContextResource> findContextResource(Resource resource) {\n List<ContextResource> contextResources = new ArrayList();\n \n Resource current = resource; \n while (current != null) {\n if (current.getPath().startsWith("\/content\/")) { \n Resource configurationPage = current.getChild(CONFIG_PAGE); \n if(configurationPage != null) {\n contextResources.add(new ContextResource(configurationPage, current.getPath()));\n }\n }\n current.getParent();\n }\n return contextResources.iterator();\n }\n}\n<\/pre><\/div>\n\n\nTa us\u0142uga OSGI b\u0119dzie u\u017cywana podczas wyszukiwania \u015bcie\u017cki kontekstu. Wysoki ranking zapewnia, \u017ce zostanie u\u017cyta jako pierwsza. W metodzie findContextResource przeszukujemy hierarchi\u0119 zasob\u00f3w w g\u00f3r\u0119 do poziomu \/content, szukaj\u0105c takiego, kt\u00f3ry posiada dziecko o nazwie configuration \u2013 czyli naszej strony konfiguracyjnej. Je\u015bli zostanie znaleziona, jest dodawana do wyniku.<\/p>\n\n\n\n
Nast\u0119pnie przychodzi czas na u\u017cycie tej us\u0142ugi we w\u0142asnej implementacji ConfigurationResourceResolvingStrategy. W tym miejscu wprost wykorzystujemy CustomContextPathStrategy, kt\u00f3ra zwraca wyszukane \u015bcie\u017cki kontekstu.<\/p>\n\n\n\n
Nast\u0119pnie iterujemy po nich, szukaj\u0105c komponentu, kt\u00f3rego nazwa odpowiada nazwie interfejsu konfiguracji (MyConfig) oraz zgodna jest z zasadami tworzenia nazw komponent\u00f3w w AEM (metoda getComponentName). Je\u015bli komponent zostanie znaleziony \u2013 metoda go zwraca, a je\u015bli nie \u2013 nast\u0119puje fallback do kolejnej \u015bcie\u017cki kontekstu i ca\u0142y scenariusz jest powtarzany.<\/p>\n\n\n
\n@Component {\n serice = ConfigurationResourceResolvingStrategy.class,\n property = {\n "serivce.ranking:Integer=1000"\n }\n}\npublic class CustomConfigurationResourceResolvingStrategy implements ConfigurationResourceResolvingStrategy {\n @Reference(target="(component.name=x.y.z.CustomContextPathStrategy)")\n private ContextPathStrategy contextPathStrategy;\n \n @Override\n public Resource getResource(Resource resourceResolver, Collection<String> bucketName) {\n String className = configName.substring(configName.lastIndex('.') + 1);\n return findContextResources(contentResource)\n .map(configurationPage -> findChildResource(configurationPage, getComponentName(className)))\n .filter(Object::nonNull)\n .findFirst()\n .orElse(null)\n }\n \n private String getComponentName(String className) {\n String componentName = className.toLowerCase();\n if(componentName.length() > 20) {\n return componentName.substring(0, 20);\n }\n return componentName;\n }\n \n private Resource findChildResource(Resource resource, String name) {\n if(resource.getName().equals(name)) {\n return resource;\n }\n for(Resource child : resource.getChildren()) {\n Resource result = findChildResource(child, name);\n if(resoult != null) {\n return result;\n }\n }\n return null;\n }\n\n ...\n implmenetation of the rest of the methods\n ...\n \n}\n<\/pre><\/div>\n\n\n![\"oferty](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2026\/01\/praca-PL-k-3.jpg\")
<\/a><\/figure>\n\n\n\nPodsumowanie<\/strong><\/h2>\n\n\n\n
W podobny spos\u00f3b mo\u017cna obs\u0142ugiwa\u0107 kolekcje. Trzeba jedynie pami\u0119ta\u0107, \u017ce nazwa konfiguracji ma posta\u0107 x.y.z.MyConfig\/jcr:content\/keyValues i trzeba to uwzgl\u0119dni\u0107, aby by\u0142a poprawnie zapisywana jak i odczytywana.<\/p>\n\n\n\n
Cz\u0119\u015b\u0107 \/jcr:content pochodzi z wewn\u0119trznej implementacji Granite i w trakcie moich eksperyment\u00f3w nie uda\u0142o mi si\u0119 jej zmieni\u0107.<\/p>\n\n\n\n
Stworzenie implementacji tych dw\u00f3ch interfejs\u00f3w jest wystarczaj\u0105ce, aby obs\u0142u\u017cy\u0107 nasz niestandardowy scenariusz i stanowi \u015bwietny przyk\u0142ad elastyczno\u015bci mechanizmu Sling Context-Aware Customization.<\/p>\n\n\n\n
Dalsze rozwa\u017cania<\/strong><\/h2>\n\n\n\n
Istnieje r\u00f3wnie\u017c biblioteka 3rd party, kt\u00f3ra udost\u0119pnia UI oraz w\u0142asne strategie konfiguracji: Context-Aware Configuration | wcm.io<\/a><\/p>\n\n\n\n
Zawsze warto tak\u017ce zajrze\u0107 do oficjalnej dokumentacji: Apache Sling :: Apache Sling Context-Aware Configuration<\/a><\/p>\n\n\n
- Konfiguracje OSGi \u2013 <\/strong>najlepiej stosowa\u0107 je do nieedytowalnych przez autor\u00f3w systemowych konfiguracji, takich jak: schedulery, serwisy, cache, integracje.<\/li>\n\n\n\n