[jira] [Commented] (SLING-12104) OSGi Mock - Service Registration Designate OCD default empty property is ignored, which leads to NPE
[
https://issues.apache.org/jira/browse/SLING-12104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776572#comment-17776572
]
Robin Brouns commented on SLING-12104:
--
Of course [~sseifert], possible fix for this issue:
https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/pull/33
> OSGi Mock - Service Registration Designate OCD default empty property is
> ignored, which leads to NPE
>
>
> Key: SLING-12104
> URL: https://issues.apache.org/jira/browse/SLING-12104
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.3.10
>Reporter: Robin Brouns
>Priority: Major
>
> Considering the following sample Class:
> {code:java}
> package com.sample.website.job;
> import org.apache.commons.lang3.StringUtils;
> import org.apache.jackrabbit.oak.commons.PathUtils;
> import org.osgi.service.component.annotations.Activate;
> import org.osgi.service.component.annotations.Component;
> import org.osgi.service.component.annotations.Modified;
> import org.osgi.service.metatype.annotations.AttributeDefinition;
> import org.osgi.service.metatype.annotations.Designate;
> import org.osgi.service.metatype.annotations.ObjectClassDefinition;
> @Component(service = Runnable.class)
> @Designate(ocd = SampleJob.Config.class)
> public class SampleJob implements Runnable {
> private String sampleStringProperty;
> @Activate
> @Modified
> public void update(final Config configuration) {
> this.sampleStringProperty = configuration.sampleStringProperty();
> }
> @Override
> public void run() {
> if (PathUtils.isAbsolute(this.sampleStringProperty)) {
> // do something
> }
> }
> @ObjectClassDefinition(
> name = "Sample Configuration",
> description = "Sample Configuration Description"
> )
> @interface Config {
> @AttributeDefinition(
> name = "Sample String Property",
> description = "Sample String Property"
> )
> String sampleStringProperty() default StringUtils.EMPTY;
> }
> } {code}
> When I try to test this class with the default OSGi configuration via AEM
> Mocks:
> {code:java}
> final Runnable underTest =
> aemContext.registerInjectActivateService(SampleJob.class); {code}
> building this class leads to the following SCR definition:
> {code:java}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="com.sample.website.job.SampleJob" activate="update" modified="update">
>
>
>
>
>
> {code}
> the *default* value of *updateImportPath* (an empty String) is *not* injected
> in the Configuration, but null is being used, which could lead to NPE.
> AEM Mocks uses OSGi Mocks and the following method is used to retrieve the
> *default* properties and values
> [https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/c55d97ba266e0630200fcbb378b3f102d2dfba90/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiMetadataUtil.java#L292C24-L292C46]
>
> But as you can see the XPath Query doesn't match with the SCR definition: the
> property exists with a *name* and there is a {*}value{*}, but it is empty, so:
> {code:java}
> String query = getComponentXPathQuery(clazz) + "/property[@name!='' and
> @value!='']"; {code}
> doesn't return the property and its default value and the result is a
> Configuration returning *null*
> The simple fix would be to check if the *value* attribute exists via the
> XPath Query in the SCR definition, instead of checking for a non empty value.
> A more robust fix would probably be to parse the OCD MetaType (if it is a OCD
> config) and use the *default* attribute which is present over there, see:
> {code:java}
>
> http://www.osgi.org/xmlns/metatype/v1.2.0;
> localization="OSGI-INF/l10n/com.sample.website.job.SampleJob$Config">
>
> description="Sample String Property" default=""/>
>
>
>
>
>
> {code}
> What do you think about this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-12104) OSGi Mock - Service Registration Designate OCD default empty property is ignored, which leads to NPE
[
https://issues.apache.org/jira/browse/SLING-12104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776253#comment-17776253
]
Robin Brouns edited comment on SLING-12104 at 10/17/23 3:36 PM:
Apache Felix seems to read the OCD configuration and the default attribute, so
there is a difference now between the runtime and the testing suite:
[https://github.com/apache/felix-dev/blob/91432d1a3f08520d5eb75b5c8e3443bb75f7c467/metatype/src/main/java/org/apache/felix/metatype/MetaDataReader.java#L419]
was (Author: robin.bro...@amplexor.com):
Apache Felix seems to read the OCD configuration and the default attribute, so
there is a difference now between the runtime and the testing suite:
[https://github.com/apache/felix-dev/blob/91432d1a3f08520d5eb75b5c8e3443bb75f7c467/metatype/src/main/java/org/apache/felix/metatype/MetaDataReader.java#L419]
> OSGi Mock - Service Registration Designate OCD default empty property is
> ignored, which leads to NPE
>
>
> Key: SLING-12104
> URL: https://issues.apache.org/jira/browse/SLING-12104
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.3.10
>Reporter: Robin Brouns
>Priority: Major
>
> Considering the following sample Class:
> {code:java}
> package com.sample.website.job;
> import org.apache.commons.lang3.StringUtils;
> import org.apache.jackrabbit.oak.commons.PathUtils;
> import org.osgi.service.component.annotations.Activate;
> import org.osgi.service.component.annotations.Component;
> import org.osgi.service.component.annotations.Modified;
> import org.osgi.service.metatype.annotations.AttributeDefinition;
> import org.osgi.service.metatype.annotations.Designate;
> import org.osgi.service.metatype.annotations.ObjectClassDefinition;
> @Component(service = Runnable.class)
> @Designate(ocd = SampleJob.Config.class)
> public class SampleJob implements Runnable {
> private String sampleStringProperty;
> @Activate
> @Modified
> public void update(final Config configuration) {
> this.sampleStringProperty = configuration.sampleStringProperty();
> }
> @Override
> public void run() {
> if (PathUtils.isAbsolute(this.sampleStringProperty)) {
> // do something
> }
> }
> @ObjectClassDefinition(
> name = "Sample Configuration",
> description = "Sample Configuration Description"
> )
> @interface Config {
> @AttributeDefinition(
> name = "Sample String Property",
> description = "Sample String Property"
> )
> String sampleStringProperty() default StringUtils.EMPTY;
> }
> } {code}
> When I try to test this class with the default OSGi configuration via AEM
> Mocks:
> {code:java}
> final Runnable underTest =
> aemContext.registerInjectActivateService(SampleJob.class); {code}
> building this class leads to the following SCR definition:
> {code:java}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="com.sample.website.job.SampleJob" activate="update" modified="update">
>
>
>
>
>
> {code}
> the *default* value of *updateImportPath* (an empty String) is *not* injected
> in the Configuration, but null is being used, which could lead to NPE.
> AEM Mocks uses OSGi Mocks and the following method is used to retrieve the
> *default* properties and values
> [https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/c55d97ba266e0630200fcbb378b3f102d2dfba90/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiMetadataUtil.java#L292C24-L292C46]
>
> But as you can see the XPath Query doesn't match with the SCR definition: the
> property exists with a *name* and there is a {*}value{*}, but it is empty, so:
> {code:java}
> String query = getComponentXPathQuery(clazz) + "/property[@name!='' and
> @value!='']"; {code}
> doesn't return the property and its default value and the result is a
> Configuration returning *null*
> The simple fix would be to check if the *value* attribute exists via the
> XPath Query in the SCR definition, instead of checking for a non empty value.
> A more robust fix would probably be to parse the OCD MetaType (if it is a OCD
> config) and use the *default* attribute which is present over there, see:
> {code:java}
>
> http://www.osgi.org/xmlns/metatype/v1.2.0;
> localization="OSGI-INF/l10n/com.sample.website.job.SampleJob$Config">
>
> description="Sample String Property" default=""/>
>
>
>
>
>
> {code}
> What do you think about this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12104) OSGi Mock - Service Registration Designate OCD default empty property is ignored, which leads to NPE
[
https://issues.apache.org/jira/browse/SLING-12104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776253#comment-17776253
]
Robin Brouns commented on SLING-12104:
--
Apache Felix seems to read the OCD configuration and the default attribute, so
there is a difference now between the runtime and the testing suite:
[https://github.com/apache/felix-dev/blob/91432d1a3f08520d5eb75b5c8e3443bb75f7c467/metatype/src/main/java/org/apache/felix/metatype/MetaDataReader.java#L419]
> OSGi Mock - Service Registration Designate OCD default empty property is
> ignored, which leads to NPE
>
>
> Key: SLING-12104
> URL: https://issues.apache.org/jira/browse/SLING-12104
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.3.10
>Reporter: Robin Brouns
>Priority: Major
>
> Considering the following sample Class:
> {code:java}
> package com.sample.website.job;
> import org.apache.commons.lang3.StringUtils;
> import org.apache.jackrabbit.oak.commons.PathUtils;
> import org.osgi.service.component.annotations.Activate;
> import org.osgi.service.component.annotations.Component;
> import org.osgi.service.component.annotations.Modified;
> import org.osgi.service.metatype.annotations.AttributeDefinition;
> import org.osgi.service.metatype.annotations.Designate;
> import org.osgi.service.metatype.annotations.ObjectClassDefinition;
> @Component(service = Runnable.class)
> @Designate(ocd = SampleJob.Config.class)
> public class SampleJob implements Runnable {
> private String sampleStringProperty;
> @Activate
> @Modified
> public void update(final Config configuration) {
> this.sampleStringProperty = configuration.sampleStringProperty();
> }
> @Override
> public void run() {
> if (PathUtils.isAbsolute(this.sampleStringProperty)) {
> // do something
> }
> }
> @ObjectClassDefinition(
> name = "Sample Configuration",
> description = "Sample Configuration Description"
> )
> @interface Config {
> @AttributeDefinition(
> name = "Sample String Property",
> description = "Sample String Property"
> )
> String sampleStringProperty() default StringUtils.EMPTY;
> }
> } {code}
> When I try to test this class with the default OSGi configuration via AEM
> Mocks:
> {code:java}
> final Runnable underTest =
> aemContext.registerInjectActivateService(SampleJob.class); {code}
> building this class leads to the following SCR definition:
> {code:java}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="com.sample.website.job.SampleJob" activate="update" modified="update">
>
>
>
>
>
> {code}
> the *default* value of *updateImportPath* (an empty String) is *not* injected
> in the Configuration, but null is being used, which could lead to NPE.
> AEM Mocks uses OSGi Mocks and the following method is used to retrieve the
> *default* properties and values
> [https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/c55d97ba266e0630200fcbb378b3f102d2dfba90/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiMetadataUtil.java#L292C24-L292C46]
>
> But as you can see the XPath Query doesn't match with the SCR definition: the
> property exists with a *name* and there is a {*}value{*}, but it is empty, so:
> {code:java}
> String query = getComponentXPathQuery(clazz) + "/property[@name!='' and
> @value!='']"; {code}
> doesn't return the property and its default value and the result is a
> Configuration returning *null*
> The simple fix would be to check if the *value* attribute exists via the
> XPath Query in the SCR definition, instead of checking for a non empty value.
> A more robust fix would probably be to parse the OCD MetaType (if it is a OCD
> config) and use the *default* attribute which is present over there, see:
> {code:java}
>
> http://www.osgi.org/xmlns/metatype/v1.2.0;
> localization="OSGI-INF/l10n/com.sample.website.job.SampleJob$Config">
>
> description="Sample String Property" default=""/>
>
>
>
>
>
> {code}
> What do you think about this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12104) OSGi Mock - Service Registration Designate OCD default empty property is ignored, which leads to NPE
[
https://issues.apache.org/jira/browse/SLING-12104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Brouns updated SLING-12104:
-
Description:
Considering the following sample Class:
{code:java}
package com.sample.website.job;
import org.apache.commons.lang3.StringUtils;
import org.apache.jackrabbit.oak.commons.PathUtils;
import org.osgi.service.component.annotations.Activate;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Modified;
import org.osgi.service.metatype.annotations.AttributeDefinition;
import org.osgi.service.metatype.annotations.Designate;
import org.osgi.service.metatype.annotations.ObjectClassDefinition;
@Component(service = Runnable.class)
@Designate(ocd = SampleJob.Config.class)
public class SampleJob implements Runnable {
private String sampleStringProperty;
@Activate
@Modified
public void update(final Config configuration) {
this.sampleStringProperty = configuration.sampleStringProperty();
}
@Override
public void run() {
if (PathUtils.isAbsolute(this.sampleStringProperty)) {
// do something
}
}
@ObjectClassDefinition(
name = "Sample Configuration",
description = "Sample Configuration Description"
)
@interface Config {
@AttributeDefinition(
name = "Sample String Property",
description = "Sample String Property"
)
String sampleStringProperty() default StringUtils.EMPTY;
}
} {code}
When I try to test this class with the default OSGi configuration via AEM Mocks:
{code:java}
final Runnable underTest =
aemContext.registerInjectActivateService(SampleJob.class); {code}
building this class leads to the following SCR definition:
{code:java}
http://www.osgi.org/xmlns/scr/v1.3.0;
name="com.sample.website.job.SampleJob" activate="update" modified="update">
{code}
the *default* value of *updateImportPath* (an empty String) is *not* injected
in the Configuration, but null is being used, which could lead to NPE.
AEM Mocks uses OSGi Mocks and the following method is used to retrieve the
*default* properties and values
[https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/c55d97ba266e0630200fcbb378b3f102d2dfba90/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiMetadataUtil.java#L292C24-L292C46]
But as you can see the XPath Query doesn't match with the SCR definition: the
property exists with a *name* and there is a {*}value{*}, but it is empty, so:
{code:java}
String query = getComponentXPathQuery(clazz) + "/property[@name!='' and
@value!='']"; {code}
doesn't return the property and its default value and the result is a
Configuration returning *null*
The simple fix would be to check if the *value* attribute exists via the XPath
Query in the SCR definition, instead of checking for a non empty value.
A more robust fix would probably be to parse the OCD MetaType (if it is a OCD
config) and use the *default* attribute which is present over there, see:
{code:java}
http://www.osgi.org/xmlns/metatype/v1.2.0;
localization="OSGI-INF/l10n/com.sample.website.job.SampleJob$Config">
{code}
What do you think about this?
was:
Considering the following sample Class:
{code:java}
package com.sample.website.job;
import org.apache.commons.lang3.StringUtils;
import org.apache.jackrabbit.oak.commons.PathUtils;
import org.osgi.service.component.annotations.Activate;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Modified;
import org.osgi.service.metatype.annotations.AttributeDefinition;
import org.osgi.service.metatype.annotations.Designate;
import org.osgi.service.metatype.annotations.ObjectClassDefinition;
@Component(service = Runnable.class)
@Designate(ocd = SampleJob.Config.class)
public class SampleJob implements Runnable {
private String sampleStringProperty;
@Activate
@Modified
public void update(final Config configuration) {
this.sampleStringProperty = configuration.sampleStringProperty();
}
@Override
public void run() {
if (PathUtils.isAbsolute(this.sampleStringProperty)) {
// do something
}
}
@ObjectClassDefinition(
name = "Sample Configuration",
description = "Sample Configuration Description"
)
@interface Config {
@AttributeDefinition(
name = "Sample String Property",
description = "Sample String Property"
)
String sampleStringProperty() default StringUtils.EMPTY;
}
} {code}
When I try to test this class with the default OSGi configuration via AEM Mocks:
{code:java}
final Runnable underTest =
aemContext.registerInjectActivateService(SampleJob.class); {code}
building this class leads
[jira] [Created] (SLING-12104) OSGi Mock - Service Registration Designate OCD default empty property is ignored, which leads to NPE
Robin Brouns created SLING-12104:
Summary: OSGi Mock - Service Registration Designate OCD default
empty property is ignored, which leads to NPE
Key: SLING-12104
URL: https://issues.apache.org/jira/browse/SLING-12104
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: Testing OSGi Mock 3.3.10
Reporter: Robin Brouns
Considering the following sample Class:
{code:java}
package com.sample.website.job;
import org.apache.commons.lang3.StringUtils;
import org.apache.jackrabbit.oak.commons.PathUtils;
import org.osgi.service.component.annotations.Activate;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Modified;
import org.osgi.service.metatype.annotations.AttributeDefinition;
import org.osgi.service.metatype.annotations.Designate;
import org.osgi.service.metatype.annotations.ObjectClassDefinition;
@Component(service = Runnable.class)
@Designate(ocd = SampleJob.Config.class)
public class SampleJob implements Runnable {
private String sampleStringProperty;
@Activate
@Modified
public void update(final Config configuration) {
this.sampleStringProperty = configuration.sampleStringProperty();
}
@Override
public void run() {
if (PathUtils.isAbsolute(this.sampleStringProperty)) {
// do something
}
}
@ObjectClassDefinition(
name = "Sample Configuration",
description = "Sample Configuration Description"
)
@interface Config {
@AttributeDefinition(
name = "Sample String Property",
description = "Sample String Property"
)
String sampleStringProperty() default StringUtils.EMPTY;
}
} {code}
When I try to test this class with the default OSGi configuration via AEM Mocks:
{code:java}
final Runnable underTest =
aemContext.registerInjectActivateService(SampleJob.class); {code}
building this class leads to the following SCR definition:
{code:java}
http://www.osgi.org/xmlns/scr/v1.3.0;
name="com.sample.website.job.SampleJob" activate="update" modified="update">
{code}
the *default* value of *updateImportPath* (an empty String) is *not* injected
in the Configuration, but null is being used, which could lead to NPE.
AEM Mocks uses OSGi Mocks and the following method is used to retrieve the
*default* properties and values
[https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/c55d97ba266e0630200fcbb378b3f102d2dfba90/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiMetadataUtil.java#L292C24-L292C46]
But as you can see the XPath Query doesn't match with the SCR definition: the
property exists with a *name* and there is a {*}value{*}, but it is empty, so:
{code:java}
String query = getComponentXPathQuery(clazz) + "/property[@name!='' and
@value!='']"; {code}
doesn't return the property and it default value and the result is a
Configuration returning *null*
The simple fix would be to check if the *value* attribute exists via the XPath
Query in the SCR definition, instead of checking for a non empty value.
A more robust fix would probably be to parse the OCD MetaType (if it is a OCD
config) and use the *default* attribute which is present over there, see:
{code:java}
http://www.osgi.org/xmlns/metatype/v1.2.0;
localization="OSGI-INF/l10n/com.sample.website.job.SampleJob$Config">
{code}
What do you think about this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12001) Can't use MockFindQueryResources when making use of getServiceResourceResolver
[
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
[
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
[
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] [Updated] (SLING-12001) Can't use MockFindQueryResources when making use of getServiceResourceResolver
[
https://issues.apache.org/jira/browse/SLING-12001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Brouns updated SLING-12001:
-
Description:
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?
was:
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?
> 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
>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
[jira] [Created] (SLING-12001) Can't use MockFindQueryResources when making use of getServiceResourceResolver
Robin Brouns created SLING-12001:
Summary: 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
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-10391) Improve MockXSSAPIImpl
[ https://issues.apache.org/jira/browse/SLING-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746051#comment-17746051 ] Robin Brouns commented on SLING-10391: -- Think that is indeed a better idea, otherwise we need to update & align the mocks on every single update of the implementation > Improve MockXSSAPIImpl > -- > > Key: SLING-10391 > URL: https://issues.apache.org/jira/browse/SLING-10391 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing Sling Mock 3.0.2 >Reporter: Henry Kuijpers >Priority: Major > > MockXSSAPIImpl only has a few very simplistic method implementations (i.e. > for encodeForHTML it returns the input as-is). > I think we can make some improvements to it, by: > * Use StringEscapeUtils.escapeHtml4() to do HTML escaping (so that we can at > least see a difference in the output) > * Use StringEscapeUtils.escapeXml() to do XML escaping > etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-10391) Improve MockXSSAPIImpl
[ https://issues.apache.org/jira/browse/SLING-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743170#comment-17743170 ] Robin Brouns edited comment on SLING-10391 at 7/14/23 1:42 PM: --- PR: [https://github.com/apache/sling-org-apache-sling-testing-sling-mock/pull/24] is this what you need [~Henry Kuijpers] ? was (Author: robin.bro...@amplexor.com): PR: https://github.com/apache/sling-org-apache-sling-testing-sling-mock/pull/24 > Improve MockXSSAPIImpl > -- > > Key: SLING-10391 > URL: https://issues.apache.org/jira/browse/SLING-10391 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing Sling Mock 3.0.2 >Reporter: Henry Kuijpers >Priority: Major > > MockXSSAPIImpl only has a few very simplistic method implementations (i.e. > for encodeForHTML it returns the input as-is). > I think we can make some improvements to it, by: > * Use StringEscapeUtils.escapeHtml4() to do HTML escaping (so that we can at > least see a difference in the output) > * Use StringEscapeUtils.escapeXml() to do XML escaping > etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-10391) Improve MockXSSAPIImpl
[ https://issues.apache.org/jira/browse/SLING-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743170#comment-17743170 ] Robin Brouns commented on SLING-10391: -- PR: https://github.com/apache/sling-org-apache-sling-testing-sling-mock/pull/24 > Improve MockXSSAPIImpl > -- > > Key: SLING-10391 > URL: https://issues.apache.org/jira/browse/SLING-10391 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing Sling Mock 3.0.2 >Reporter: Henry Kuijpers >Priority: Major > > MockXSSAPIImpl only has a few very simplistic method implementations (i.e. > for encodeForHTML it returns the input as-is). > I think we can make some improvements to it, by: > * Use StringEscapeUtils.escapeHtml4() to do HTML escaping (so that we can at > least see a difference in the output) > * Use StringEscapeUtils.escapeXml() to do XML escaping > etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11850) HTL: Add support for suffix manipulation in ResourceRuntimeExtension
[
https://issues.apache.org/jira/browse/SLING-11850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723064#comment-17723064
]
Robin Brouns commented on SLING-11850:
--
[~radu] what do you think about this? Was there a reason to not add this
feature in HTL?
> HTL: Add support for suffix manipulation in ResourceRuntimeExtension
>
>
> Key: SLING-11850
> URL: https://issues.apache.org/jira/browse/SLING-11850
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.4.22-1.4.0
>Reporter: Robin Brouns
>Priority: Minor
> Labels: Sightly
>
> In JSP there is the possibility to include a resource in a component and
> adjust the suffix of the sub-request, processing this resource:
> {code:java}
> path="my-component"
> resourceType="application/components/other-component"
> replaceSuffix="some-suffix"/>
> {code}
> See also:
> [https://github.com/apache/sling-org-apache-sling-scripting-jsp-taglib/blob/7835da79f1de7c9c14fd478e9fec23f54fd6d711/src/main/java/org/apache/sling/scripting/jsp/taglib/AbstractDispatcherTagHandler.java#L89]
> But HTL lacks this option to adjust the suffix for the sub-request (by using
> data-sly-resource): see
> [https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L58]
>
> Is there a reason why this feature wasn't added and is not supported right
> now?
> Because we can manipulate the suffix in a URI context in HTL
> ([https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/URIManipulationFilterExtension.java#L221),]
> but just not in the Resource context.
> The _RequestDispatcher_ is already available and used in the
> _ResourceRuntimeExtension_ so it could be added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-11850) HTL: Add support for suffix manipulation in ResourceRuntimeExtension
Robin Brouns created SLING-11850:
Summary: HTL: Add support for suffix manipulation in
ResourceRuntimeExtension
Key: SLING-11850
URL: https://issues.apache.org/jira/browse/SLING-11850
Project: Sling
Issue Type: Improvement
Components: Scripting
Affects Versions: Scripting HTL Engine 1.4.22-1.4.0
Reporter: Robin Brouns
In JSP there is the possibility to include a resource in a component and adjust
the suffix of the sub-request, processing this resource:
{code:java}
{code}
See also:
[https://github.com/apache/sling-org-apache-sling-scripting-jsp-taglib/blob/7835da79f1de7c9c14fd478e9fec23f54fd6d711/src/main/java/org/apache/sling/scripting/jsp/taglib/AbstractDispatcherTagHandler.java#L89]
But HTL lacks this option to adjust the suffix for the sub-request (by using
data-sly-resource): see
[https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L58]
Is there a reason why this feature wasn't added and is not supported right now?
Because we can manipulate the suffix in a URI context in HTL
([https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/URIManipulationFilterExtension.java#L221),]
but just not in the Resource context.
The _RequestDispatcher_ is already available and used in the
_ResourceRuntimeExtension_ so it could be added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-6761) HTL: uri manipulator breaks query parameter encoding
Robin Brouns created SLING-6761:
---
Summary: HTL: uri manipulator breaks query parameter encoding
Key: SLING-6761
URL: https://issues.apache.org/jira/browse/SLING-6761
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting Sightly Engine 1.0.18, Scripting Sightly Engine
1.0.2
Environment: AEM 6.1 SP2 - CFP6
AEM 6.2
Reporter: Robin Brouns
When I try to manipulate a href tag with HTL, and the href contains a query
param with encoded percentage sign (%25), the HTL manipulator breaks the URI
encoding, resulting in a invalid URI.
For example when we have a *path* property in the repository, containing the
following value:
{code}
/example/search?q=6%25-10%25
{code}
and use the following HTL code:
{code}
Test with @ HTL URI
manipulator
Test without @ HTL URI manipulator
{code}
The result will be:
{code}
Test with @ HTL URI manipulator
Test without @ HTL URI manipulator
{code}
So the HTL URI manipulation removes the %25 encoding and replaces it with a
single percentage sign. Without manipulation the encoding is preserved. Same
holds for other HTL uri manipulators like *@ prependPath*
Other signs like *%3A* aren't affected.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
