Issue when testing Context-Aware config

[Basic Danijel]

Hi everybody,

I'm trying to write a JUnit test for a piece of the logic that works with context-aware configurations.

For the reference, I'm using this test: https://github.com/apache/sling-org-apache-sling-testing-caconfig-mock-plugin/blob/8d6b363600277858541e314a22558043c8eb928f/src/test/java/org/apache/sling/testing/mock/caconfig/MockContextAwareConfigTest.java#L95

because on the project I'm working on, there are also nested configurations like the example above provides.

When working with CA configs on AEM Cloud instance (btw CA config editor is used: https://wcm.io/caconfig/editor/usage.html), I noticed that the editor has created the following JCR structure:

+ conf/

 + project_abc/

  + sling:configs/

    + com.projectabc.caconfigs.NestedConfig/

      + jcr:content/

        + sub/

          - item0

          - item1

However, when debugging the test method from GitHub (referenced above), I noticed that MockContextAwareConfig.writeConfiguration() method will create 'sub' property of the type String[] and put it as the property of 'jcr:content' node in the example above.

I think this could be the reason why my test is failing.

Is there any way to force MockContextAwareConfig.writeConfiguration() to create the same JCR structure as the Configuration Editor (https://wcm.io/caconfig/editor/usage.html) mentioned above?

I suppose the impl of 'org.apache.sling.caconfig.spi.ConfigurationPersistenceStrategy2' should be created for that but I'm really not sure. That's why I'm asking.

Best regards,

Danijel

[Stefan Seifert]

hello danijel.

 

if you want the exact same behavior/JCR data structure used in your unit test as in the running AEM instance, the same persistence strategy implementation with the same configuration has to be configured. e.g. in case your are using the “AEM Page” persistence strategy from https://wcm.io/caconfig/extensions/ you have to register and configure the related OSGi service in your unit test as well. if you did not use the persistence strategy from https://wcm.io/caconfig/extensions/, a default persistence strategy from AEM itself is in place, which is not available in unit tests.

 

however, in most cases it should not be important to configure the correct persistence strategy for the unit tests – if you are only reading/writing the data via the Context-Aware Configuration APIs, it does not play a role if the JCR structure is the same as in AEM or not. but you are right, if using nested caconfigs things get a bit tricky, and the node names/node hierarchy like “sub” may be slightly different in unit tests than in the real environment.

 

stefan

 

--
You received this message because you are subscribed to the Google Groups "wcm-io Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wcm-io-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wcm-io-dev/CAHy%3D9eAy7s%2B9pYjbNRqEFpOGC-UMiMr155NNPZ5UM73YssPTrw%40mail.gmail.com.

[Basic Danijel]

Hey Stefan,

Thank you for the reply.

I've debugged a bit these two methods:

1) io.wcm.caconfig.extensions.persistence.impl.PagePersistenceStrategy#persistConfiguration

2) io.wcm.caconfig.extensions.persistence.impl.PagePersistenceStrategy#persistConfigurationCollection

It looks like 1) will create sth like this:

+ conf/

 + project_abc/

  + sling:configs/

    + com.projectabc.caconfigs.NestedConfig/

      + jcr:content/

and then place 'sub' as the property of 'jcr:content' node.

The method 2) will create sth like this:

+ conf/

 + project_abc/

  + sling:configs/

    + com.projectabc.caconfigs.NestedConfig/

      + item0/

        + jcr:content/

and then place 'sub' as the property of 'jcr:content' node.

So, method 2) will introduce that intermediate node 'item0'.

On another side, the impl of org.apache.sling.caconfig.ConfigurationBuilder, actually org.apache.sling.caconfig.impl.ConfigurationBuilderImpl.AnnotationConverter#convert() method

will try to search for '/conf/project_abc/sling:configs/com.projectabc.caconfigs.NestedConfig/sub node and because it fails to find it, then 'com.projectabc.caconfigs.NestedConfig#sub' field won't be initialized.

It could be because of some implementation specific detail on the project I'm currently working on that I cannot figure out atm.

Btw, that impl is similar to this method https://github.com/apache/sling-org-apache-sling-testing-caconfig-mock-plugin/blob/8d6b363600277858541e314a22558043c8eb928f/src/test/java/org/apache/sling/testing/mock/caconfig/MockContextAwareConfigTest.java#L177

Best regards,

Danijel

To view this discussion visit https://groups.google.com/d/msgid/wcm-io-dev/BE1PPFB2A222D012FD04557C67C8051AC24B85C2%40BE1PPFB2A222D01.DEUP281.PROD.OUTLOOK.COM.