[
https://issues.apache.org/jira/browse/OPENJPA-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Solodovnik resolved OPENJPA-3013.
---------------------------------------
Fix Version/s: 4.2.0
Assignee: Richard Zowalla
Resolution: Fixed
> Collect the deserialization candidate loaders without a MultiClassLoader
> ------------------------------------------------------------------------
>
> Key: OPENJPA-3013
> URL: https://issues.apache.org/jira/browse/OPENJPA-3013
> Project: OpenJPA
> Issue Type: Improvement
> Components: jpa
> Reporter: Richard Zowalla
> Assignee: Richard Zowalla
> Priority: Minor
> Fix For: 4.2.0
>
>
> Follow-up to OPENJPA-3012, from Romain Manni-Bucau's review remark on PR
> #210: the candidate class loaders are collected into a MultiClassLoader and
> unwrapped into an array immediately afterwards, which is a surprising use of
> a class loader as a container.
> The container only existed to keep the protected hook that contributes the
> loaders, addContextClassLoaders(MultiClassLoader), which
> PersistentObjectInputStream overrides to add the loader of its StoreContext.
> Collect the loaders into a List<ClassLoader> and build the array from it, as
> suggested in the review. The hook then takes a List<ClassLoader>; the
> MultiClassLoader overload is deprecated for removal and is no longer called,
> so a subclass that overrides it has to move to the new signature.
> Serialization is an internal utility (org.apache.openjpa.util), and the
> change is confined to the one in-tree override.
> No behaviour change: the loader order, the de-duplication, the null filtering
> and the fallback to the stream's own resolveClass are unchanged, which
> TestSerializationClassResolving covers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
