[jira] [Commented] (SLING-12001) Can't use MockFindQueryResources when making use of getServiceResourceResolver

2023-08-15 Thread Robin Brouns (Jira)


[ 
https://issues.apache.org/jira/browse/SLING-12001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754634#comment-17754634
 ] 

Robin Brouns commented on SLING-12001:
--

Cool thanks [~sseifert]!

> Can't use MockFindQueryResources when making use of getServiceResourceResolver
> --
>
> Key: SLING-12001
> URL: https://issues.apache.org/jira/browse/SLING-12001
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing ResourceResolver Mock 1.4.2
>Reporter: Robin Brouns
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Testing ResourceResolver Mock 1.4.4
>
>
> I want to mock resourceResolver.findResources and found that there is a way 
> to do this via 
> [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/blob/master/src/main/java/org/apache/sling/testing/resourceresolver/MockFindQueryResources.java#L43]
>   
> {code:java}
> MockFindQueryResources.addFindResourceHandler(...) {code}
> This works as long as the Sling Context its Resource Resolver 
> (context.resourceResolver()) is used. But we have a piece of code, which uses 
> a Service Resource Resolver:
> {code:java}
> private ResourceResolver getServiceResolver() throws LoginException {
> return resourceResolverFactory.getServiceResourceResolver(
> Collections.singletonMap(ResourceResolverFactory.SUBSERVICE, 
> CLEAN_UP_SERVICE_NAME)
> );
> }{code}
> We can't mock the findResources method for this Service Resource Resolver, as 
> the ResourceResolverFactory *always* internally creates a new 
> MockResourceResolver object (see 
> [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/blob/master/src/main/java/org/apache/sling/testing/resourceresolver/MockResourceResolverFactory.java#L102)].
>  
> This means that *all* of the in memory changes like
>  * findResourcesHandlers
>  * queryResourcesHandlers
>  * ...
> are lost, so MockFindQueryResources can't be used, because we can't get the 
> service resolver from the context (because it is always a new object).
> Same holds true for 
> MockResourceResolverFactory.getAdministrativeResourceResolver(...).
> Is it maybe an idea to add functionality to register the Resource Handlers on 
> the MockResourceResolverFactory, which is able to pass them down to the 
> MockResourceResolver on creation?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SLING-12001) Can't use MockFindQueryResources when making use of getServiceResourceResolver

2023-08-15 Thread Robin Brouns (Jira)


[ 
https://issues.apache.org/jira/browse/SLING-12001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754534#comment-17754534
 ] 

Robin Brouns commented on SLING-12001:
--

True, for the unit tests, it doesn't matter that much. If you still want to 
have the fields available in the MockResourceResolver, you can always change 
the constructor to:


{code:java}
public MockResourceResolver(MockResourceResolverFactoryOptions options, 
MockResourceResolverFactory factory, Map> 
resources, Map attributes) {
this.temporaryResources = new LinkedHashMap();
this.deletedResources = new HashSet();
this.findResourcesHandlers = options.getFindResourcesHandlers();   
this.queryResourcesHandlers = options.getQueryResourcesHandlers();
    this.factory = factory;
this.options = options;
this.resources = resources;
this.attributes = attributes;
} {code}
but for now I think it is fine if they reside within the 
MockResourceResolverFactoryOptions

 

> Can't use MockFindQueryResources when making use of getServiceResourceResolver
> --
>
> Key: SLING-12001
> URL: https://issues.apache.org/jira/browse/SLING-12001
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing ResourceResolver Mock 1.4.2
>Reporter: Robin Brouns
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Testing ResourceResolver Mock 1.4.4
>
>
> I want to mock resourceResolver.findResources and found that there is a way 
> to do this via 
> [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/blob/master/src/main/java/org/apache/sling/testing/resourceresolver/MockFindQueryResources.java#L43]
>   
> {code:java}
> MockFindQueryResources.addFindResourceHandler(...) {code}
> This works as long as the Sling Context its Resource Resolver 
> (context.resourceResolver()) is used. But we have a piece of code, which uses 
> a Service Resource Resolver:
> {code:java}
> private ResourceResolver getServiceResolver() throws LoginException {
> return resourceResolverFactory.getServiceResourceResolver(
> Collections.singletonMap(ResourceResolverFactory.SUBSERVICE, 
> CLEAN_UP_SERVICE_NAME)
> );
> }{code}
> We can't mock the findResources method for this Service Resource Resolver, as 
> the ResourceResolverFactory *always* internally creates a new 
> MockResourceResolver object (see 
> [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/blob/master/src/main/java/org/apache/sling/testing/resourceresolver/MockResourceResolverFactory.java#L102)].
>  
> This means that *all* of the in memory changes like
>  * findResourcesHandlers
>  * queryResourcesHandlers
>  * ...
> are lost, so MockFindQueryResources can't be used, because we can't get the 
> service resolver from the context (because it is always a new object).
> Same holds true for 
> MockResourceResolverFactory.getAdministrativeResourceResolver(...).
> Is it maybe an idea to add functionality to register the Resource Handlers on 
> the MockResourceResolverFactory, which is able to pass them down to the 
> MockResourceResolver on creation?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SLING-12001) Can't use MockFindQueryResources when making use of getServiceResourceResolver

2023-08-15 Thread Stefan Seifert (Jira)


[ 
https://issues.apache.org/jira/browse/SLING-12001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754499#comment-17754499
 ] 

Stefan Seifert commented on SLING-12001:


well, this would be a completely different but also interesting approach. i've 
created a second PR 
https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/pull/11
 which moves the storage of the handlers to the 
MockResourceResolverFactoryOptions  - which is usually shared by the main 
resource resolver and all new instances created via the factory.

maybe that's even more elegant also it comes with a bit hidden side-effects - 
but that should not matter in unit test context?

> Can't use MockFindQueryResources when making use of getServiceResourceResolver
> --
>
> Key: SLING-12001
> URL: https://issues.apache.org/jira/browse/SLING-12001
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing ResourceResolver Mock 1.4.2
>Reporter: Robin Brouns
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Testing ResourceResolver Mock 1.4.4
>
>
> I want to mock resourceResolver.findResources and found that there is a way 
> to do this via 
> [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/blob/master/src/main/java/org/apache/sling/testing/resourceresolver/MockFindQueryResources.java#L43]
>   
> {code:java}
> MockFindQueryResources.addFindResourceHandler(...) {code}
> This works as long as the Sling Context its Resource Resolver 
> (context.resourceResolver()) is used. But we have a piece of code, which uses 
> a Service Resource Resolver:
> {code:java}
> private ResourceResolver getServiceResolver() throws LoginException {
> return resourceResolverFactory.getServiceResourceResolver(
> Collections.singletonMap(ResourceResolverFactory.SUBSERVICE, 
> CLEAN_UP_SERVICE_NAME)
> );
> }{code}
> We can't mock the findResources method for this Service Resource Resolver, as 
> the ResourceResolverFactory *always* internally creates a new 
> MockResourceResolver object (see 
> [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/blob/master/src/main/java/org/apache/sling/testing/resourceresolver/MockResourceResolverFactory.java#L102)].
>  
> This means that *all* of the in memory changes like
>  * findResourcesHandlers
>  * queryResourcesHandlers
>  * ...
> are lost, so MockFindQueryResources can't be used, because we can't get the 
> service resolver from the context (because it is always a new object).
> Same holds true for 
> MockResourceResolverFactory.getAdministrativeResourceResolver(...).
> Is it maybe an idea to add functionality to register the Resource Handlers on 
> the MockResourceResolverFactory, which is able to pass them down to the 
> MockResourceResolver on creation?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SLING-12001) Can't use MockFindQueryResources when making use of getServiceResourceResolver

2023-08-15 Thread Robin Brouns (Jira)


[ 
https://issues.apache.org/jira/browse/SLING-12001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754489#comment-17754489
 ] 

Robin Brouns commented on SLING-12001:
--

Looks good to me [~sseifert]! This will fix indeed the issue. One small remark, 
to make these handlers maybe part of the 
MockResourceResolverFactoryOptions so the MockResourceResolver can init based 
on the options (instead of factory executing some additional init for the 
MockResourceResolver).

> Can't use MockFindQueryResources when making use of getServiceResourceResolver
> --
>
> Key: SLING-12001
> URL: https://issues.apache.org/jira/browse/SLING-12001
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing ResourceResolver Mock 1.4.2
>Reporter: Robin Brouns
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Testing ResourceResolver Mock 1.4.4
>
>
> I want to mock resourceResolver.findResources and found that there is a way 
> to do this via 
> [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/blob/master/src/main/java/org/apache/sling/testing/resourceresolver/MockFindQueryResources.java#L43]
>   
> {code:java}
> MockFindQueryResources.addFindResourceHandler(...) {code}
> This works as long as the Sling Context its Resource Resolver 
> (context.resourceResolver()) is used. But we have a piece of code, which uses 
> a Service Resource Resolver:
> {code:java}
> private ResourceResolver getServiceResolver() throws LoginException {
> return resourceResolverFactory.getServiceResourceResolver(
> Collections.singletonMap(ResourceResolverFactory.SUBSERVICE, 
> CLEAN_UP_SERVICE_NAME)
> );
> }{code}
> We can't mock the findResources method for this Service Resource Resolver, as 
> the ResourceResolverFactory *always* internally creates a new 
> MockResourceResolver object (see 
> [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/blob/master/src/main/java/org/apache/sling/testing/resourceresolver/MockResourceResolverFactory.java#L102)].
>  
> This means that *all* of the in memory changes like
>  * findResourcesHandlers
>  * queryResourcesHandlers
>  * ...
> are lost, so MockFindQueryResources can't be used, because we can't get the 
> service resolver from the context (because it is always a new object).
> Same holds true for 
> MockResourceResolverFactory.getAdministrativeResourceResolver(...).
> Is it maybe an idea to add functionality to register the Resource Handlers on 
> the MockResourceResolverFactory, which is able to pass them down to the 
> MockResourceResolver on creation?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SLING-12001) Can't use MockFindQueryResources when making use of getServiceResourceResolver

2023-08-15 Thread Stefan Seifert (Jira)


[ 
https://issues.apache.org/jira/browse/SLING-12001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754480#comment-17754480
 ] 

Stefan Seifert commented on SLING-12001:


[~robin.bro...@amplexor.com] good idea, i've created a proposal following your 
approach in 
https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/pull/10

> Can't use MockFindQueryResources when making use of getServiceResourceResolver
> --
>
> Key: SLING-12001
> URL: https://issues.apache.org/jira/browse/SLING-12001
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing ResourceResolver Mock 1.4.2
>Reporter: Robin Brouns
>Assignee: Stefan Seifert
>Priority: Major
>
> I want to mock resourceResolver.findResources and found that there is a way 
> to do this via 
> [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/blob/master/src/main/java/org/apache/sling/testing/resourceresolver/MockFindQueryResources.java#L43]
>   
> {code:java}
> MockFindQueryResources.addFindResourceHandler(...) {code}
> This works as long as the Sling Context its Resource Resolver 
> (context.resourceResolver()) is used. But we have a piece of code, which uses 
> a Service Resource Resolver:
> {code:java}
> private ResourceResolver getServiceResolver() throws LoginException {
> return resourceResolverFactory.getServiceResourceResolver(
> Collections.singletonMap(ResourceResolverFactory.SUBSERVICE, 
> CLEAN_UP_SERVICE_NAME)
> );
> }{code}
> We can't mock the findResources method for this Service Resource Resolver, as 
> the ResourceResolverFactory *always* internally creates a new 
> MockResourceResolver object (see 
> [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/blob/master/src/main/java/org/apache/sling/testing/resourceresolver/MockResourceResolverFactory.java#L102)].
>  
> This means that *all* of the in memory changes like
>  * findResourcesHandlers
>  * queryResourcesHandlers
>  * ...
> are lost, so MockFindQueryResources can't be used, because we can't get the 
> service resolver from the context (because it is always a new object).
> Same holds true for 
> MockResourceResolverFactory.getAdministrativeResourceResolver(...).
> Is it maybe an idea to add functionality to register the Resource Handlers on 
> the MockResourceResolverFactory, which is able to pass them down to the 
> MockResourceResolver on creation?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)