[ 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)