[
https://issues.apache.org/jira/browse/FELIX-5908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16581038#comment-16581038
]
Timothy Ward commented on FELIX-5908:
-------------------------------------
The attached GitHub Pull Request contains two commits, the first containing
tests demonstrating the issue, the second containing a fix for the issue
> NoClassDefFoundError for the CM Security Domain combiner
> --------------------------------------------------------
>
> Key: FELIX-5908
> URL: https://issues.apache.org/jira/browse/FELIX-5908
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin
> Affects Versions: configadmin-1.9.4
> Reporter: Timothy Ward
> Priority: Major
>
> This is a pretty weird bug, so I'll try to explain it.
> When running with security on the Configuration Admin Updater thread applies
> an Access Control Context which, amongst other things, sets up a Domain
> Combiner. This Domain Combiner lazily creates a combined Protection Domain
> based on the target bundle.
>
> All of this works fine until you end up in the following situation:
> # The MS/MSF being called attempts to perform a checked operation (for which
> they may or may not have permission)
> # The Check causes the CM Domain Combiner to be instantiated, triggering a
> class load if it is the first time
> # The Loading of the class can then trigger *more* security checks in some
> cases, for example setting the CodeSource of the class being defined can
> require a security check if there are multiple frameworks in the VM, or if
> the code was installed from a custom URL handler that has a custom
> toExternalForm() implementation
> # This security check retrievers the CM Domain Combiner, which attempts to
> load the class again
> # The Java ClassLoader detects the cycle and throws a NoClassDefFoundError
>
> I am setting up a "simple" test demonstrating this (it necessarily has
> several moving parts) and a proposed patch.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
