Bugfix: Fixed Configuration Model for Redirect Manager after change in "redirect" resource as "sling:Folder"

[vabs95]

Issue: Regression

Cause:

The resource type for redirects has been changed to "sling:Folder". However, the JCR query used to display the list of configurations has not been updated and currently only retrieves nodes of type "nt:unstructured".

Fix:

Refactor Configurations Model to read the configs directly without query.

Regression via #3399

[vabs95]

FYI @kwin and @YegorKozlov

[YegorKozlov]

@vabs95 a good catch!

I'd say we should rewrite the code further and get rid of the jcr query at all. We can simply iterate over /conf/*, something like:

    public Collection<RedirectConfiguration> getConfigurations() {
        List<RedirectConfiguration> lst = new ArrayList<>();
        String bucketName = redirectFilter == null ? RedirectFilter.DEFAULT_CONFIG_BUCKET : redirectFilter.getBucket();
        String configName = redirectFilter == null ? RedirectFilter.DEFAULT_CONFIG_NAME : redirectFilter.getConfigName();
        Resource conf = request.getResourceResolver().getResource("/conf");
        for (Resource confRoot : conf.getChildren()) {
            String storageSuffix = bucketName + "/" + configName;
            Resource res = confRoot.getChild(storageSuffix);
            if (res != null && res.isResourceType(REDIRECTS_RESOURCE_TYPE)) {
                RedirectConfiguration cfg = new RedirectConfiguration(res, storageSuffix);
                lst.add(cfg);
            }
        }
        lst.sort(Comparator.comparing(RedirectConfiguration::getName));
        return lst;
    }

It would be also great to update the tests. There are tests for CreateRedirectConfigurationServlet, e.g.
https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/213279b88757a3798893397f09ec74e39f16a1b3/bundle/src/test/java/com/adobe/acs/commons/redirects/servlets/CreateRedirectConfigurationServletTest.java#L60C1-L61C1

but the way they read the created resources is not aligned with the code.
instead of reading the resource directly:

        Resource cfg = context.resourceResolver().getResource("/conf/global/settings/redirects");

the test should read via the model:

        Configurations confModel = context.request().adaptTo(Configurations.class);
        Collection<RedirectConfiguration> configurations = confModel.getConfigurations();
        RedirectConfiguration cfg = configurations.iterator().next();
        assertEquals("/conf/global/settings/redirects", cfg.getPath());

this way the test will cover both the create and read parts.

[vabs95]

@YegorKozlov Changes done as requested.

[davidjgonzalez]

Neither here nor there, but if you do write a query, and Oak determines that the faster way to collect the results is to just traverse the tree, it will traverse the tree. The overhead of the query is negligible.