[jira] [Updated] (SLING-11924) ModelExporter should not serialize a ResourceResolver
[
https://issues.apache.org/jira/browse/SLING-11924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh updated SLING-11924:
--
Description:
With the addition of {{ResourceResolver.getPropertyMap()}} (SLING-10895) I
found that the serialization of a ResourceResolver can fail like this:
{noformat}
rg.apache.sling.models.factory.ExportException:
com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer
found for class com.day.cq.wcm.core.impl.policies.ContentPolicyManagerImpl and
no properties discovered to create BeanSerializer (to avoid exception, disable
SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain:
com.myapp.PageImpl[":items"]> [...] > com.myapp.MyModel["resolver"]
>org.apache.sling.resourceresolver.impl.ResourceResolverImpl["propertyMap"]
>java.util.HashMap["com.day.cq.wcm.core.impl.policies.ContentPolicyAdapterFactory.ContentPolicy"])
at
org.apache.sling.models.jacksonexporter.impl.JacksonExporter.export(JacksonExporter.java:138)
[org.apache.sling.models.jacksonexporter:1.1.2]
at
org.apache.sling.models.impl.ModelAdapterFactory.exportModel(ModelAdapterFactory.java:1333)
[org.apache.sling.models.impl:1.5.4]
{noformat}
This is caused by the fact, that a Sling Model class serializes a
ResourceResolver, which is problematic for these 2 reasons:
* It can fail for the above mentioned reason in an unpredictable way (for
example, some code adds items via {{getPropertyMap().put(x,y)}} and the
serialization fails at a totally different place.
* The serialization of the RR discloses implementation details (e.g.
searchpaths, or other things which might be stored in the propertyMap).
I am not aware of any reason, why a ResourceResolver should be serialized,
instead more specialized types should be used instead.
For these reasons we should have a way to disable the serialization of the
ResourceResolver. For backwards compatibility we can keep the existing behavior
as a default, but I also see reasons why it the serialization of the RR should
be turned off by default.
See also the discussion on sling-dev:
https://lists.apache.org/thread/8xl4lgfl5omv3md4drgyqqz3vmfllsom
was:
With the addition of {{ResourceResolver.getPropertyMap()}} (SLING-10895) I
found that the serialization of a ResourceResolver can fail like this:
{noformat}
rg.apache.sling.models.factory.ExportException:
com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer
found for class com.day.cq.wcm.core.impl.policies.ContentPolicyManagerImpl and
no properties discovered to create BeanSerializer (to avoid exception, disable
SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain:
com.myapp.PageImpl[":items"]> [...] > com.myapp.MyModel["resolver"]
>org.apache.sling.resourceresolver.impl.ResourceResolverImpl["propertyMap"]
>java.util.HashMap["com.day.cq.wcm.core.impl.policies.ContentPolicyAdapterFactory.ContentPolicy"])
at
org.apache.sling.models.jacksonexporter.impl.JacksonExporter.export(JacksonExporter.java:138)
[org.apache.sling.models.jacksonexporter:1.1.2]
at
org.apache.sling.models.impl.ModelAdapterFactory.exportModel(ModelAdapterFactory.java:1333)
[org.apache.sling.models.impl:1.5.4]
{noformat}
This is caused by the fact, that a Sling Model class serializes a
ResourceResolver, which is problematic for these 2 reasons:
* It can fail for the above mentioned reason in an unpredictable way (for
example, some code adds items via {{getPropertyMap().put(x,y)}} and the
serialization fails at a totally different place.
* The serialization of the RR discloses implementation details (e.g.
searchpaths, or other things which might be stored in the propertyMap).
I am not aware of any reason, why a ResourceResolver should be serialized,
instead more specialized types should be used instead.
For that reason we should have a way to disable the serialization of the
ResourceResolver. For backwards compatibility we can keep the existing behavior
as a default, but I also see reasons why it the serialization of the RR should
be turned off by default.
See also the discussion on sling-dev:
https://lists.apache.org/thread/8xl4lgfl5omv3md4drgyqqz3vmfllsom
> ModelExporter should not serialize a ResourceResolver
> -
>
> Key: SLING-11924
> URL: https://issues.apache.org/jira/browse/SLING-11924
> Project: Sling
> Issue Type: Task
> Components: Sling Models
>Affects Versions: Sling Models Jackson Exporter 1.0.2
>Reporter: Joerg Hoh
>Priority: Major
>
> With the addition of {{ResourceResolver.getPropertyMap()}} (SLING-10895) I
> found that the serialization of a ResourceResolver can fail like this:
> {noformat}
> rg.apache.sling.models.factory.ExportException:
> com.fasterxml.jackson.databind.exc.InvalidDefinition
[jira] [Updated] (SLING-11924) ModelExporter should not serialize a ResourceResolver
[
https://issues.apache.org/jira/browse/SLING-11924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh updated SLING-11924:
--
Fix Version/s: Models Jackson Exporter 1.1.4
> ModelExporter should not serialize a ResourceResolver
> -
>
> Key: SLING-11924
> URL: https://issues.apache.org/jira/browse/SLING-11924
> Project: Sling
> Issue Type: Task
> Components: Sling Models
>Affects Versions: Sling Models Jackson Exporter 1.0.2
>Reporter: Joerg Hoh
>Priority: Major
> Fix For: Models Jackson Exporter 1.1.4
>
>
> With the addition of {{ResourceResolver.getPropertyMap()}} (SLING-10895) I
> found that the serialization of a ResourceResolver can fail like this:
> {noformat}
> rg.apache.sling.models.factory.ExportException:
> com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer
> found for class com.day.cq.wcm.core.impl.policies.ContentPolicyManagerImpl
> and no properties discovered to create BeanSerializer (to avoid exception,
> disable SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain:
> com.myapp.PageImpl[":items"]> [...] > com.myapp.MyModel["resolver"]
> >org.apache.sling.resourceresolver.impl.ResourceResolverImpl["propertyMap"]
> >java.util.HashMap["com.day.cq.wcm.core.impl.policies.ContentPolicyAdapterFactory.ContentPolicy"])
> at
> org.apache.sling.models.jacksonexporter.impl.JacksonExporter.export(JacksonExporter.java:138)
> [org.apache.sling.models.jacksonexporter:1.1.2]
> at
> org.apache.sling.models.impl.ModelAdapterFactory.exportModel(ModelAdapterFactory.java:1333)
> [org.apache.sling.models.impl:1.5.4]
> {noformat}
> This is caused by the fact, that a Sling Model class serializes a
> ResourceResolver, which is problematic for these 2 reasons:
> * It can fail for the above mentioned reason in an unpredictable way (for
> example, some code adds items via {{getPropertyMap().put(x,y)}} and the
> serialization fails at a totally different place.
> * The serialization of the RR discloses implementation details (e.g.
> searchpaths, or other things which might be stored in the propertyMap).
> I am not aware of any reason, why a ResourceResolver should be serialized,
> instead more specialized types should be used instead.
> For these reasons we should have a way to disable the serialization of the
> ResourceResolver. For backwards compatibility we can keep the existing
> behavior as a default, but I also see reasons why it the serialization of the
> RR should be turned off by default.
> See also the discussion on sling-dev:
> https://lists.apache.org/thread/8xl4lgfl5omv3md4drgyqqz3vmfllsom
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11924) ModelExporter should not serialize a ResourceResolver
[
https://issues.apache.org/jira/browse/SLING-11924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh updated SLING-11924:
--
Description:
With the addition of {{ResourceResolver.getPropertyMap()}} (SLING-10895) I
found that the serialization of a ResourceResolver can fail like this:
{noformat}
org.apache.sling.models.factory.ExportException:
com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer
found for class com.day.cq.wcm.core.impl.policies.ContentPolicyManagerImpl and
no properties discovered to create BeanSerializer (to avoid exception, disable
SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain:
com.myapp.PageImpl[":items"]> [...] > com.myapp.MyModel["resolver"]
>org.apache.sling.resourceresolver.impl.ResourceResolverImpl["propertyMap"]
>java.util.HashMap["com.day.cq.wcm.core.impl.policies.ContentPolicyAdapterFactory.ContentPolicy"])
at
org.apache.sling.models.jacksonexporter.impl.JacksonExporter.export(JacksonExporter.java:138)
[org.apache.sling.models.jacksonexporter:1.1.2]
at
org.apache.sling.models.impl.ModelAdapterFactory.exportModel(ModelAdapterFactory.java:1333)
[org.apache.sling.models.impl:1.5.4]
{noformat}
This is caused by the fact, that a Sling Model class serializes a
ResourceResolver, which is problematic for these 2 reasons:
* It can fail for the above mentioned reason in an unpredictable way (for
example, some code adds items via {{getPropertyMap().put(x,y)}} and the
serialization fails at a totally different place.
* The serialization of the RR discloses implementation details (e.g.
searchpaths, or other things which might be stored in the propertyMap).
I am not aware of any reason, why a ResourceResolver should be serialized,
instead more specialized types should be used instead.
For these reasons we should have a way to disable the serialization of the
ResourceResolver. For backwards compatibility we can keep the existing behavior
as a default, but I also see reasons why it the serialization of the RR should
be turned off by default.
See also the discussion on sling-dev:
https://lists.apache.org/thread/8xl4lgfl5omv3md4drgyqqz3vmfllsom
was:
With the addition of {{ResourceResolver.getPropertyMap()}} (SLING-10895) I
found that the serialization of a ResourceResolver can fail like this:
{noformat}
rg.apache.sling.models.factory.ExportException:
com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer
found for class com.day.cq.wcm.core.impl.policies.ContentPolicyManagerImpl and
no properties discovered to create BeanSerializer (to avoid exception, disable
SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain:
com.myapp.PageImpl[":items"]> [...] > com.myapp.MyModel["resolver"]
>org.apache.sling.resourceresolver.impl.ResourceResolverImpl["propertyMap"]
>java.util.HashMap["com.day.cq.wcm.core.impl.policies.ContentPolicyAdapterFactory.ContentPolicy"])
at
org.apache.sling.models.jacksonexporter.impl.JacksonExporter.export(JacksonExporter.java:138)
[org.apache.sling.models.jacksonexporter:1.1.2]
at
org.apache.sling.models.impl.ModelAdapterFactory.exportModel(ModelAdapterFactory.java:1333)
[org.apache.sling.models.impl:1.5.4]
{noformat}
This is caused by the fact, that a Sling Model class serializes a
ResourceResolver, which is problematic for these 2 reasons:
* It can fail for the above mentioned reason in an unpredictable way (for
example, some code adds items via {{getPropertyMap().put(x,y)}} and the
serialization fails at a totally different place.
* The serialization of the RR discloses implementation details (e.g.
searchpaths, or other things which might be stored in the propertyMap).
I am not aware of any reason, why a ResourceResolver should be serialized,
instead more specialized types should be used instead.
For these reasons we should have a way to disable the serialization of the
ResourceResolver. For backwards compatibility we can keep the existing behavior
as a default, but I also see reasons why it the serialization of the RR should
be turned off by default.
See also the discussion on sling-dev:
https://lists.apache.org/thread/8xl4lgfl5omv3md4drgyqqz3vmfllsom
> ModelExporter should not serialize a ResourceResolver
> -
>
> Key: SLING-11924
> URL: https://issues.apache.org/jira/browse/SLING-11924
> Project: Sling
> Issue Type: Task
> Components: Sling Models
>Affects Versions: Sling Models Jackson Exporter 1.0.2
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Models Jackson Exporter 1.1.4
>
>
> With the addition of {{ResourceResolver.getPropertyMap()}} (SLING-10895) I
> found that the serialization of a ResourceResolver can fail like this:
> {noformat}
> org.apache.s
