You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2026/10/09 12:32:00 UTC
[jira] [Commented] (OPENJPA-3013) Collect the deserialization candidate loaders without a MultiClassLoader
[ https://issues.apache.org/jira/browse/OPENJPA-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125516#comment-18125516 ]
ASF subversion and git services commented on OPENJPA-3013:
----------------------------------------------------------
Commit c234e2c14f6ac27e7c7415b3dc6085fd04731f3a in openjpa's branch refs/heads/OPENJPA-3013 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=c234e2c14 ]
[OPENJPA-3013] Collect the candidate loaders without a MultiClassLoader
The loaders to consult were collected into a MultiClassLoader and unwrapped
again, which only served to keep the protected hook that contributes them.
Collect them into a list and build the array from it instead.
The hook therefore takes a List<ClassLoader>; the MultiClassLoader overload is
deprecated for removal and no longer called, so a subclass overriding it has to
move to the new signature.
> 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)