[
https://issues.apache.org/jira/browse/ZEST-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niclas Hedhman updated ZEST-105:
--------------------------------
Description:
The ValueSerialization extensions are dependent on type lookup when
deserializing values, but they go about it in the wrong way. They make the type
lookup relative to their own Module, which completely breaks everything, and it
can't even be worked around in many cases.
Entities that has values in them, are not prone to this, since a slightly
different approach is done in the entity store, although I am not sure it is
immune to this Visibility/TypeLookup issue.
There is even a "Values Module Finder" feature in the whole subsystem, which is
a hack-ish work-around the short-comings of the actual API.
At a minimum, a Module needs to be provided for which the Visibility should be
computed from. It is likely that the Module used is dynamic, and changes as the
Value Type tree is traversed, i.e. when a nested type is "found" its Module
(i.e. the module it was found in) should be used for its further TypeLookup
operations. This mimics the UnitOfWork to a much closer degree.
The necessary model elements are present, and to correct the implementations
shouldn't be too hard, but there will be a change in the ValueSerialization
API/SPI, and we should simply delay the change until 3.0. There might be many
over wanted changes that could affect the new design.
was:
The ValueSerialization extensions are dependent on type lookup when
deserializing values, but they go about it in the wrong way. They make the type
lookup relative to their own Module, which completely breaks everything, and it
can't even be worked around in many cases.
Entities that has values in them, are not prone to this, since a slightly
different approach is done in the entity store, although I am not sure it is
immune to this Visibility/TypeLookup issue.
There is even a "Value Type Finder" feature in the whole subsystem, which is a
hack-ish work-around the short-comings of the actual API.
At a minimum, a Module needs to be provided for which the Visibility should be
computed from. It is likely that the Module used is dynamic, and changes as the
Value Type tree is traversed, i.e. when a nested type is "found" its Module
(i.e. the module it was found in) should be used for its further TypeLookup
operations. This mimics the UnitOfWork to a much closer degree.
The necessary model elements are present, and to correct the implementations
shouldn't be too hard, but there will be a change in the ValueSerialization
API/SPI, and we should simply delay the change until 3.0. There might be many
over wanted changes that could affect the new design.
> ValueSerialization Type Lookup is wrong.
> ----------------------------------------
>
> Key: ZEST-105
> URL: https://issues.apache.org/jira/browse/ZEST-105
> Project: Zest
> Issue Type: Bug
> Affects Versions: 2.0, 2.1
> Reporter: Niclas Hedhman
> Fix For: 3.0
>
>
> The ValueSerialization extensions are dependent on type lookup when
> deserializing values, but they go about it in the wrong way. They make the
> type lookup relative to their own Module, which completely breaks everything,
> and it can't even be worked around in many cases.
> Entities that has values in them, are not prone to this, since a slightly
> different approach is done in the entity store, although I am not sure it is
> immune to this Visibility/TypeLookup issue.
> There is even a "Values Module Finder" feature in the whole subsystem, which
> is a hack-ish work-around the short-comings of the actual API.
> At a minimum, a Module needs to be provided for which the Visibility should
> be computed from. It is likely that the Module used is dynamic, and changes
> as the Value Type tree is traversed, i.e. when a nested type is "found" its
> Module (i.e. the module it was found in) should be used for its further
> TypeLookup operations. This mimics the UnitOfWork to a much closer degree.
> The necessary model elements are present, and to correct the implementations
> shouldn't be too hard, but there will be a change in the ValueSerialization
> API/SPI, and we should simply delay the change until 3.0. There might be many
> over wanted changes that could affect the new design.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
