But ValueSerialization is also "SPI" and you claimed elsewhere that we reserve the right to change that...
On Fri, Jun 26, 2015 at 10:07 AM, Paul Merlin <[email protected]> wrote: > Niclas, > > Niclas Hedhman a écrit : > > Gang, > > > > There is something awkward about the Value Deserialization system, but I > > have a hard time to put my finger on it. > > > > The entity types are found by Entity Store implementations that are > > residing in layers below. But value types can't be deserialized without a > > valuesModuleFinder (which erroneously assumes a single module for all > > types, but that is separate issue) handing a module from layers above. > That > > shouldn't really be necessary. > > > > I think that the issue stems from the fact that the UnitOfWork isn't > > involved, and there is nothing else carrying this vital information. I > also > > think that the underlying mistake was to first do "@Structure Module > > module" injection into the ValueDeserializerAdapter, later realizing that > > wouldn't work (and adding the valuesModuleFinder as a result), but at > that > > point failing to add Module in the methods instead of the constructor > > argument. > I think you got the history right :) > Seems legit that UoW is not involved as Serialization must work without > one, we're talking about Values here. > > > I will see if I can come up with a solution to this. > > > > Any feedback is appreciated, as always... > Unfortunately, adding Module in the methods would break API > compatibility. If it's the way to go, we could add new methods with a > Module parameter and @Deprecate the other methods planning their removal > for 3.0. > > HTH > > /Paul > > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
