You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by GitBox <gi...@apache.org> on 2021/06/14 07:19:02 UTC

[GitHub] [sling-org-apache-sling-resourceresolver] rombert commented on a change in pull request #46: SLING-10447 Improve the querys that are used to load vanity paths, by specifying path restrictions

rombert commented on a change in pull request #46:
URL: https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/46#discussion_r649981504



##########
File path: src/test/java/org/apache/sling/resourceresolver/impl/mapping/MapEntriesTest.java
##########
@@ -370,26 +381,31 @@ public void test_vanity_path_updates() throws Exception {
     @Test
     public void test_vanity_path_registration_include_exclude() throws IOException {
         final String[] validPaths = {"/libs/somewhere", "/libs/a/b", "/foo/a", "/baa/a"};
-        final String[] invalidPaths = {"/libs/denied/a", "/libs/denied/b/c", "/nowhere"};
 
         final List<Resource> resources = new ArrayList<>();
         for(final String val : validPaths) {
             resources.add(getVanityPathResource(val));
         }
-        for(final String val : invalidPaths) {
-            resources.add(getVanityPathResource(val));
-        }
-
-
-        when(resourceResolver.findResources(anyString(), eq("sql"))).thenAnswer(new Answer<Iterator<Resource>>() {
-
-            @Override
-            public Iterator<Resource> answer(InvocationOnMock invocation) throws Throwable {
-                if (invocation.getArguments()[0].toString().contains("sling:vanityPath")) {
-                    return resources.iterator();
-                } else {
-                    return Collections.<Resource> emptySet().iterator();
-                }
+        when(resourceResolver.findResources(anyString(), eq("sql"))).thenAnswer((Answer<Iterator<Resource>>) invocation -> {

Review comment:
       I would be a bit cautious with pulling in too much into this test module. Bring in Sling Mocks in low-level modules has in my experience lead to various classpath clashes and overriding of depedencies.
   
   I think validating the query is better done at the integration test level. Or maybe, if we want to be sure, we might want to try importing a query parser from Oak and checking that the query is valid. But I think that running the full query is too much at this level.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org