You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by "Andreas Veithen (JIRA)" <ji...@apache.org> on 2016/02/13 22:28:18 UTC
[jira] [Updated] (AXIOM-468) StAXUtils may cause class loader leak
[ https://issues.apache.org/jira/browse/AXIOM-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Veithen updated AXIOM-468:
----------------------------------
Fix Version/s: 1.3.0
> StAXUtils may cause class loader leak
> -------------------------------------
>
> Key: AXIOM-468
> URL: https://issues.apache.org/jira/browse/AXIOM-468
> Project: Axiom
> Issue Type: Bug
> Components: API
> Affects Versions: 1.2.15
> Reporter: Andreas Veithen
> Priority: Minor
> Fix For: 1.3.0
>
>
> By default, StAXUtils keep per class loader maps of XMLInputFactory and XMLOutputFactory instances (where the key is the thread context class loader). These maps are implemented as WeakHashMap<ClassLoader,XMLInputFactory> and WeakHashMap<ClassLoader,XMLOutputFactory>. This may cause a class loader leak if the XMLInputFactory or XMLOutputFactory instance has a strong reference to the ClassLoader used as key. That case occurs in two scenarios:
> 1. A StAX implementation is loaded by a class loader that is not the class loader that loads StAXUtils or one of its parent class loaders, and that class loader is set as the context class loader when StAXUtils is used. Note that this is basically the use case for which the per class loader maps were designed.
> 2. For whatever reason, the XMLInputFactory/XMLOutputFactory instance keeps a strong reference to the thread context class loader set when the instance was created. In that scenario, if StAXUtils is used with a thread context class loader that is set to any class loader other than the one that loaded StAXUtils or one of its parents, then StAXUtils will prevent that class loader from being garbage collected. This type of behavior has been reported for the default StAX implementation in the Oracle JRE (see http://markmail.org/message/2kfstgjckrgiimmt). Woodstox is probably not affected.
> The scenario for which the per class loader feature was designed is probably very rare. As shown above, that scenario is always prone to class loader leaks. Therefore this feature should probably be removed without replacement, and StAXUtils should always load the StAX implementation visible to its own class loader. Note that this mode is already supported, but it is not the default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org