[ 
https://issues.apache.org/jira/browse/OPENJPA-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18126072#comment-18126072
 ] 

ASF subversion and git services commented on OPENJPA-3013:
----------------------------------------------------------

Commit ace0ff4c9a63eb4e74225fff1149fa7c5d65d7a8 in openjpa's branch 
refs/heads/master from Paulo Cristovão de Araújo Silva Filho
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=ace0ff4c9 ]

Merge pull request #212 from apache/OPENJPA-3013

[OPENJPA-3013] Collect the candidate loaders without a MultiClassLoader

> 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
>            Priority: Minor
>
> 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)

Reply via email to