[jira] [Commented] (FELIX-5977) Immediately deliver automatic resolution warning when finding imacting resolution issues
[ https://issues.apache.org/jira/browse/FELIX-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680963#comment-16680963 ] Carsten Ziegeler commented on FELIX-5977: - [~alpic80] No problem, which framework version are you using? > Immediately deliver automatic resolution warning when finding imacting > resolution issues > > > Key: FELIX-5977 > URL: https://issues.apache.org/jira/browse/FELIX-5977 > Project: Felix > Issue Type: Improvement > Components: Resolver >Affects Versions: scr-2.0.10 >Reporter: Alain Picard >Priority: Minor > > Starting our project took multiple minutes and we asked for advice on the > osg-dev forum, but only found out what was happening after activating full > tracing, which then provided the needed information. > It was suggested to open this issue so that messages of this nature should > always be automatically reported without the need for tracing to be enabled. > Here is an example of what we got: > Apache Felix Declarative Services (2.0.10.v20170501-2007) > RESOLVER: Candidate permutation failed due to a conflict between imports; > will try another if possible. (Uses constraint violation. Unable to resolve > resource org.eclipse.sirius.common.acceleo.mtl [osgi.identity; > osgi.identity="org.eclipse.sirius.common.acceleo.mtl"; type="osgi.bundle"; > version:Version="2.0.0.qualifier"; singleton:="true"] because it is exposed > to package 'com.google.common.base' from resources com.google.guava > [osgi.identity; osgi.identity="com.google.guava"; type="osgi.bundle"; > version:Version="25.1.0.jre"] and com.google.guava [osgi.identity; > osgi.identity="com.google.guava"; type="osgi.bundle"; > version:Version="21.0.0.v20170206-1425"] via two dependency chains. > Chain 1: > org.eclipse.sirius.common.acceleo.mtl [osgi.identity; > osgi.identity="org.eclipse.sirius.common.acceleo.mtl"; type="osgi.bundle"; > version:Version="2.0.0.qualifier"; singleton:="true"] > require: > (&(osgi.wiring.bundle=com.google.guava)(bundle-version>=21.0.0)) > | > provide: osgi.wiring.bundle: com.google.guava > com.google.guava [osgi.identity; osgi.identity="com.google.guava"; > type="osgi.bundle"; version:Version="25.1.0.jre"] > Chain 2: > org.eclipse.sirius.common.acceleo.mtl [osgi.identity; > osgi.identity="org.eclipse.sirius.common.acceleo.mtl"; type="osgi.bundle"; > version:Version="2.0.0.qualifier"; singleton:="true"] > require: > (&(osgi.wiring.bundle=org.eclipse.acceleo.engine)(bundle-version>=3.4.1)) > | > provide: osgi.wiring.bundle; > bundle-version:Version="3.7.1.201705121344"; > osgi.wiring.bundle="org.eclipse.acceleo.engine"; singleton:="true" > org.eclipse.acceleo.engine [osgi.identity; > osgi.identity="org.eclipse.acceleo.engine"; type="osgi.bundle"; > version:Version="3.7.1.201705121344"; singleton:="true"] > import: > (&(osgi.wiring.package=com.google.common.collect)(&(version>=15.0.0)(!(version>=22.0.0 > | > export: osgi.wiring.package=com.google.common.collect; > uses:=com.google.common.base > com.google.guava [osgi.identity; osgi.identity="com.google.guava"; > type="osgi.bundle"; version:Version="21.0.0.v20170206-1425"] > import: > (&(osgi.wiring.package=com.google.common.base)(&(version>=21.0.0)(!(version>=22.0.0 > | > export: osgi.wiring.package: com.google.common.base > com.google.guava [osgi.identity; osgi.identity="com.google.guava"; > type="osgi.bundle"; version:Version="21.0.0.v20170206-1425"]) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on
[
https://issues.apache.org/jira/browse/FELIX-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-5978 started by Karl Pauls.
-
> Felix framework unable to retrieve custom URL handlers when security is on
> --
>
> Key: FELIX-5978
> URL: https://issues.apache.org/jira/browse/FELIX-5978
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Timothy Ward
>Assignee: Karl Pauls
>Priority: Critical
> Fix For: framework-6.0.2
>
>
> When running with multiple frameworks in the same VM, custom URL Handlers,
> and OSGi security on there are a couple of problems:
>
> Firstly, this security exception results in the custom URL handler being
> ignored. The framework should really be using a doPriv here.
> {code:java}
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "getClassLoader")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.Class.getClassLoader(Class.java:683)
> at
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
> at java.net.URL.toExternalForm(URL.java:929)
> at java.net.URL.toString(URL.java:915)
> at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
> at
> org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
> {code}
> Secondly, the wrong framework is returned some of the time due to the logic
> of URLHandlers.getFrameworkContext() - in this method it assumes that there
> will be a bundle class loader on the stack, which is not true when the
> launcher is starting a bundle (the framework reflectively loads the Activator
> type which requires a URL check to set the security domain).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on
[
https://issues.apache.org/jira/browse/FELIX-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned FELIX-5978:
-
Assignee: Karl Pauls
> Felix framework unable to retrieve custom URL handlers when security is on
> --
>
> Key: FELIX-5978
> URL: https://issues.apache.org/jira/browse/FELIX-5978
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Timothy Ward
>Assignee: Karl Pauls
>Priority: Critical
> Fix For: framework-6.0.2
>
>
> When running with multiple frameworks in the same VM, custom URL Handlers,
> and OSGi security on there are a couple of problems:
>
> Firstly, this security exception results in the custom URL handler being
> ignored. The framework should really be using a doPriv here.
> {code:java}
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "getClassLoader")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.Class.getClassLoader(Class.java:683)
> at
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
> at java.net.URL.toExternalForm(URL.java:929)
> at java.net.URL.toString(URL.java:915)
> at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
> at
> org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
> {code}
> Secondly, the wrong framework is returned some of the time due to the logic
> of URLHandlers.getFrameworkContext() - in this method it assumes that there
> will be a bundle class loader on the stack, which is not true when the
> launcher is starting a bundle (the framework reflectively loads the Activator
> type which requires a URL check to set the security domain).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on
[
https://issues.apache.org/jira/browse/FELIX-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680417#comment-16680417
]
Karl Pauls commented on FELIX-5978:
---
I applied the patch provided by [~timothyjward] - thanks a lot!
> Felix framework unable to retrieve custom URL handlers when security is on
> --
>
> Key: FELIX-5978
> URL: https://issues.apache.org/jira/browse/FELIX-5978
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Timothy Ward
>Assignee: Karl Pauls
>Priority: Critical
> Fix For: framework-6.0.2
>
>
> When running with multiple frameworks in the same VM, custom URL Handlers,
> and OSGi security on there are a couple of problems:
>
> Firstly, this security exception results in the custom URL handler being
> ignored. The framework should really be using a doPriv here.
> {code:java}
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "getClassLoader")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.Class.getClassLoader(Class.java:683)
> at
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
> at java.net.URL.toExternalForm(URL.java:929)
> at java.net.URL.toString(URL.java:915)
> at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
> at
> org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
> {code}
> Secondly, the wrong framework is returned some of the time due to the logic
> of URLHandlers.getFrameworkContext() - in this method it assumes that there
> will be a bundle class loader on the stack, which is not true when the
> launcher is starting a bundle (the framework reflectively loads the Activator
> type which requires a URL check to set the security domain).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on
[
https://issues.apache.org/jira/browse/FELIX-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-5978.
---
Resolution: Fixed
> Felix framework unable to retrieve custom URL handlers when security is on
> --
>
> Key: FELIX-5978
> URL: https://issues.apache.org/jira/browse/FELIX-5978
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Timothy Ward
>Assignee: Karl Pauls
>Priority: Critical
> Fix For: framework-6.0.2
>
>
> When running with multiple frameworks in the same VM, custom URL Handlers,
> and OSGi security on there are a couple of problems:
>
> Firstly, this security exception results in the custom URL handler being
> ignored. The framework should really be using a doPriv here.
> {code:java}
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "getClassLoader")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.Class.getClassLoader(Class.java:683)
> at
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
> at java.net.URL.toExternalForm(URL.java:929)
> at java.net.URL.toString(URL.java:915)
> at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
> at
> org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
> {code}
> Secondly, the wrong framework is returned some of the time due to the logic
> of URLHandlers.getFrameworkContext() - in this method it assumes that there
> will be a bundle class loader on the stack, which is not true when the
> launcher is starting a bundle (the framework reflectively loads the Activator
> type which requires a URL check to set the security domain).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on
Timothy Ward created FELIX-5978:
---
Summary: Felix framework unable to retrieve custom URL handlers
when security is on
Key: FELIX-5978
URL: https://issues.apache.org/jira/browse/FELIX-5978
Project: Felix
Issue Type: Bug
Affects Versions: framework-6.0.1, framework-6.0.0
Reporter: Timothy Ward
Fix For: framework-6.0.2
When running with multiple frameworks in the same VM, custom URL Handlers, and
OSGi security on there are a couple of problems:
Firstly, this security exception results in the custom URL handler being
ignored. The framework should really be using a doPriv here.
{code:java}
java.security.AccessControlException: access denied
("java.lang.RuntimePermission" "getClassLoader")
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
at java.lang.Class.getClassLoader(Class.java:683)
at
org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
at java.net.URL.toExternalForm(URL.java:929)
at java.net.URL.toString(URL.java:915)
at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
at
org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at
org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
{code}
Secondly, the wrong framework is returned some of the time due to the logic of
URLHandlers.getFrameworkContext() - in this method it assumes that there will
be a bundle class loader on the stack, which is not true when the launcher is
starting a bundle (the framework reflectively loads the Activator type which
requires a URL check to set the security domain).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5977) Immediately deliver automatic resolution warning when finding imacting resolution issues
[ https://issues.apache.org/jira/browse/FELIX-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679539#comment-16679539 ] Carsten Ziegeler commented on FELIX-5977: - [~alpic80] In how far is this related to SCR? This looks like a resolver / framework bug to me > Immediately deliver automatic resolution warning when finding imacting > resolution issues > > > Key: FELIX-5977 > URL: https://issues.apache.org/jira/browse/FELIX-5977 > Project: Felix > Issue Type: Improvement > Components: Resolver >Affects Versions: scr-2.0.10 >Reporter: Alain Picard >Priority: Minor > > Starting our project took multiple minutes and we asked for advice on the > osg-dev forum, but only found out what was happening after activating full > tracing, which then provided the needed information. > It was suggested to open this issue so that messages of this nature should > always be automatically reported without the need for tracing to be enabled. > Here is an example of what we got: > Apache Felix Declarative Services (2.0.10.v20170501-2007) > RESOLVER: Candidate permutation failed due to a conflict between imports; > will try another if possible. (Uses constraint violation. Unable to resolve > resource org.eclipse.sirius.common.acceleo.mtl [osgi.identity; > osgi.identity="org.eclipse.sirius.common.acceleo.mtl"; type="osgi.bundle"; > version:Version="2.0.0.qualifier"; singleton:="true"] because it is exposed > to package 'com.google.common.base' from resources com.google.guava > [osgi.identity; osgi.identity="com.google.guava"; type="osgi.bundle"; > version:Version="25.1.0.jre"] and com.google.guava [osgi.identity; > osgi.identity="com.google.guava"; type="osgi.bundle"; > version:Version="21.0.0.v20170206-1425"] via two dependency chains. > Chain 1: > org.eclipse.sirius.common.acceleo.mtl [osgi.identity; > osgi.identity="org.eclipse.sirius.common.acceleo.mtl"; type="osgi.bundle"; > version:Version="2.0.0.qualifier"; singleton:="true"] > require: > (&(osgi.wiring.bundle=com.google.guava)(bundle-version>=21.0.0)) > | > provide: osgi.wiring.bundle: com.google.guava > com.google.guava [osgi.identity; osgi.identity="com.google.guava"; > type="osgi.bundle"; version:Version="25.1.0.jre"] > Chain 2: > org.eclipse.sirius.common.acceleo.mtl [osgi.identity; > osgi.identity="org.eclipse.sirius.common.acceleo.mtl"; type="osgi.bundle"; > version:Version="2.0.0.qualifier"; singleton:="true"] > require: > (&(osgi.wiring.bundle=org.eclipse.acceleo.engine)(bundle-version>=3.4.1)) > | > provide: osgi.wiring.bundle; > bundle-version:Version="3.7.1.201705121344"; > osgi.wiring.bundle="org.eclipse.acceleo.engine"; singleton:="true" > org.eclipse.acceleo.engine [osgi.identity; > osgi.identity="org.eclipse.acceleo.engine"; type="osgi.bundle"; > version:Version="3.7.1.201705121344"; singleton:="true"] > import: > (&(osgi.wiring.package=com.google.common.collect)(&(version>=15.0.0)(!(version>=22.0.0 > | > export: osgi.wiring.package=com.google.common.collect; > uses:=com.google.common.base > com.google.guava [osgi.identity; osgi.identity="com.google.guava"; > type="osgi.bundle"; version:Version="21.0.0.v20170206-1425"] > import: > (&(osgi.wiring.package=com.google.common.base)(&(version>=21.0.0)(!(version>=22.0.0 > | > export: osgi.wiring.package: com.google.common.base > com.google.guava [osgi.identity; osgi.identity="com.google.guava"; > type="osgi.bundle"; version:Version="21.0.0.v20170206-1425"]) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on
[
https://issues.apache.org/jira/browse/FELIX-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680409#comment-16680409
]
ASF GitHub Bot commented on FELIX-5978:
---
Github user asfgit closed the pull request at:
https://github.com/apache/felix/pull/160
> Felix framework unable to retrieve custom URL handlers when security is on
> --
>
> Key: FELIX-5978
> URL: https://issues.apache.org/jira/browse/FELIX-5978
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Timothy Ward
>Priority: Critical
> Fix For: framework-6.0.2
>
>
> When running with multiple frameworks in the same VM, custom URL Handlers,
> and OSGi security on there are a couple of problems:
>
> Firstly, this security exception results in the custom URL handler being
> ignored. The framework should really be using a doPriv here.
> {code:java}
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "getClassLoader")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.Class.getClassLoader(Class.java:683)
> at
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
> at java.net.URL.toExternalForm(URL.java:929)
> at java.net.URL.toString(URL.java:915)
> at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
> at
> org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
> {code}
> Secondly, the wrong framework is returned some of the time due to the logic
> of URLHandlers.getFrameworkContext() - in this method it assumes that there
> will be a bundle class loader on the stack, which is not true when the
> launcher is starting a bundle (the framework reflectively loads the Activator
> type which requires a URL check to set the security domain).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on
[
https://issues.apache.org/jira/browse/FELIX-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679665#comment-16679665
]
ASF GitHub Bot commented on FELIX-5978:
---
GitHub user timothyjward opened a pull request:
https://github.com/apache/felix/pull/160
[FELIX-5978] Ensure getClassLoader() is called in a safe way when sec…
…urity is enabled
Previously URLHandlers would explode when security was on because it didn't
have permission to get the ClassLoader all the way down the stack
Signed-off-by: Tim Ward
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/timothyjward/felix FELIX-5978
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/felix/pull/160.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #160
commit e30d80a31b03731fd1b67fb551d58b10741eb5d1
Author: Tim Ward
Date: 2018-11-08T12:11:29Z
[FELIX-5978] Ensure getClassLoader() is called in a safe way when security
is enabled
Previously URLHandlers would explode when security was on because it didn't
have permission to get the ClassLoader all the way down the stack
Signed-off-by: Tim Ward
> Felix framework unable to retrieve custom URL handlers when security is on
> --
>
> Key: FELIX-5978
> URL: https://issues.apache.org/jira/browse/FELIX-5978
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Timothy Ward
>Priority: Critical
> Fix For: framework-6.0.2
>
>
> When running with multiple frameworks in the same VM, custom URL Handlers,
> and OSGi security on there are a couple of problems:
>
> Firstly, this security exception results in the custom URL handler being
> ignored. The framework should really be using a doPriv here.
> {code:java}
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "getClassLoader")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.Class.getClassLoader(Class.java:683)
> at
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
> at java.net.URL.toExternalForm(URL.java:929)
> at java.net.URL.toString(URL.java:915)
> at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
> at
> org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
> {code}
> Secondly, the wrong framework is returned some of the time due to the logic
> of URLHandlers.getFrameworkContext() - in this method it assumes that there
> will be a bundle class loader on the stack, which is not true when the
> launcher is starting a bundle (the framework reflectively loads the Activator
> type which requires a URL check to set the security domain).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] felix pull request #160: [FELIX-5978] Ensure getClassLoader() is called in a...
Github user asfgit closed the pull request at: https://github.com/apache/felix/pull/160 ---
[jira] [Commented] (FELIX-5977) Immediately deliver automatic resolution warning when finding imacting resolution issues
[ https://issues.apache.org/jira/browse/FELIX-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680155#comment-16680155 ] Alain Picard commented on FELIX-5977: - Maybe I miscategorized, but I do have the component as Resolver. Feel free to adjust. > Immediately deliver automatic resolution warning when finding imacting > resolution issues > > > Key: FELIX-5977 > URL: https://issues.apache.org/jira/browse/FELIX-5977 > Project: Felix > Issue Type: Improvement > Components: Resolver >Affects Versions: scr-2.0.10 >Reporter: Alain Picard >Priority: Minor > > Starting our project took multiple minutes and we asked for advice on the > osg-dev forum, but only found out what was happening after activating full > tracing, which then provided the needed information. > It was suggested to open this issue so that messages of this nature should > always be automatically reported without the need for tracing to be enabled. > Here is an example of what we got: > Apache Felix Declarative Services (2.0.10.v20170501-2007) > RESOLVER: Candidate permutation failed due to a conflict between imports; > will try another if possible. (Uses constraint violation. Unable to resolve > resource org.eclipse.sirius.common.acceleo.mtl [osgi.identity; > osgi.identity="org.eclipse.sirius.common.acceleo.mtl"; type="osgi.bundle"; > version:Version="2.0.0.qualifier"; singleton:="true"] because it is exposed > to package 'com.google.common.base' from resources com.google.guava > [osgi.identity; osgi.identity="com.google.guava"; type="osgi.bundle"; > version:Version="25.1.0.jre"] and com.google.guava [osgi.identity; > osgi.identity="com.google.guava"; type="osgi.bundle"; > version:Version="21.0.0.v20170206-1425"] via two dependency chains. > Chain 1: > org.eclipse.sirius.common.acceleo.mtl [osgi.identity; > osgi.identity="org.eclipse.sirius.common.acceleo.mtl"; type="osgi.bundle"; > version:Version="2.0.0.qualifier"; singleton:="true"] > require: > (&(osgi.wiring.bundle=com.google.guava)(bundle-version>=21.0.0)) > | > provide: osgi.wiring.bundle: com.google.guava > com.google.guava [osgi.identity; osgi.identity="com.google.guava"; > type="osgi.bundle"; version:Version="25.1.0.jre"] > Chain 2: > org.eclipse.sirius.common.acceleo.mtl [osgi.identity; > osgi.identity="org.eclipse.sirius.common.acceleo.mtl"; type="osgi.bundle"; > version:Version="2.0.0.qualifier"; singleton:="true"] > require: > (&(osgi.wiring.bundle=org.eclipse.acceleo.engine)(bundle-version>=3.4.1)) > | > provide: osgi.wiring.bundle; > bundle-version:Version="3.7.1.201705121344"; > osgi.wiring.bundle="org.eclipse.acceleo.engine"; singleton:="true" > org.eclipse.acceleo.engine [osgi.identity; > osgi.identity="org.eclipse.acceleo.engine"; type="osgi.bundle"; > version:Version="3.7.1.201705121344"; singleton:="true"] > import: > (&(osgi.wiring.package=com.google.common.collect)(&(version>=15.0.0)(!(version>=22.0.0 > | > export: osgi.wiring.package=com.google.common.collect; > uses:=com.google.common.base > com.google.guava [osgi.identity; osgi.identity="com.google.guava"; > type="osgi.bundle"; version:Version="21.0.0.v20170206-1425"] > import: > (&(osgi.wiring.package=com.google.common.base)(&(version>=21.0.0)(!(version>=22.0.0 > | > export: osgi.wiring.package: com.google.common.base > com.google.guava [osgi.identity; osgi.identity="com.google.guava"; > type="osgi.bundle"; version:Version="21.0.0.v20170206-1425"]) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (FELIX-5975) URLHandlersStreamHandlerProxy - OPEN_CONNECTION_PROXY null
[
https://issues.apache.org/jira/browse/FELIX-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned FELIX-5975:
-
Assignee: Karl Pauls
> URLHandlersStreamHandlerProxy - OPEN_CONNECTION_PROXY null
> --
>
> Key: FELIX-5975
> URL: https://issues.apache.org/jira/browse/FELIX-5975
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.6.1
> Environment: AIX server box, Tomcat 8.0.53
>Reporter: Julien Jalageas
>Assignee: Karl Pauls
>Priority: Blocker
> Fix For: framework-6.0.2
>
> Attachments: stacktrace.txt
>
>
> Hi,
> I am running into a blocking issue since I've upgraded from Tomcat 7.0.73 to
> Tomcat 8.0.53, SOAP based web services are failing with the following error:
> java.lang.IllegalStateException: *Stream handler unavailable due to: null*
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:359)
> Using a remote debugger, I was able to find that the real exception is
> actually a Null Pointer Exception thrown from
> *URLHandlersStreamHandlerProxy*.java, line 351:
> return (URLConnection) *OPEN_CONNECTION_PROXY*.invoke(svc, new Object[]\{url,
> proxy});
> where *OPEN_CONNECTION_PROXY* is null (I've attached the full stacktrace).
> Is there a fix available?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5975) URLHandlersStreamHandlerProxy - OPEN_CONNECTION_PROXY null
[
https://issues.apache.org/jira/browse/FELIX-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679957#comment-16679957
]
Julien Jalageas commented on FELIX-5975:
I was able to reproduce this issues on 3 different Tomcat versions (8.0.47,
8.0.53 & 8.5.34).
This issue is not present on Tomcat 9.
> URLHandlersStreamHandlerProxy - OPEN_CONNECTION_PROXY null
> --
>
> Key: FELIX-5975
> URL: https://issues.apache.org/jira/browse/FELIX-5975
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.6.1
> Environment: AIX server box, Tomcat 8.0.53
>Reporter: Julien Jalageas
>Priority: Blocker
> Attachments: stacktrace.txt
>
>
> Hi,
> I am running into a blocking issue since I've upgraded from Tomcat 7.0.73 to
> Tomcat 8.0.53, SOAP based web services are failing with the following error:
> java.lang.IllegalStateException: *Stream handler unavailable due to: null*
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:359)
> Using a remote debugger, I was able to find that the real exception is
> actually a Null Pointer Exception thrown from
> *URLHandlersStreamHandlerProxy*.java, line 351:
> return (URLConnection) *OPEN_CONNECTION_PROXY*.invoke(svc, new Object[]\{url,
> proxy});
> where *OPEN_CONNECTION_PROXY* is null (I've attached the full stacktrace).
> Is there a fix available?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on
[
https://issues.apache.org/jira/browse/FELIX-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679712#comment-16679712
]
Timothy Ward commented on FELIX-5978:
-
{quote}Secondly, the wrong framework is returned some of the time due to the
logic of URLHandlers.getFrameworkContext() - in this method it assumes that
there will be a bundle class loader on the stack, which is not true when the
launcher is starting a bundle (the framework reflectively loads the Activator
type which requires a URL check to set the security domain).
{quote}
While it would be nice to fix this, I've thought more deeply about it and I'm
really not sure whether it is possible to fix without a significant change to
the Felix BundleClassLoader (basically to register the Framework that is
associated with the current class load). I would like some advice as to whether
people think this would be a good idea. [~karlpauls]?
> Felix framework unable to retrieve custom URL handlers when security is on
> --
>
> Key: FELIX-5978
> URL: https://issues.apache.org/jira/browse/FELIX-5978
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Timothy Ward
>Priority: Critical
> Fix For: framework-6.0.2
>
>
> When running with multiple frameworks in the same VM, custom URL Handlers,
> and OSGi security on there are a couple of problems:
>
> Firstly, this security exception results in the custom URL handler being
> ignored. The framework should really be using a doPriv here.
> {code:java}
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "getClassLoader")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.Class.getClassLoader(Class.java:683)
> at
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
> at java.net.URL.toExternalForm(URL.java:929)
> at java.net.URL.toString(URL.java:915)
> at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
> at
> org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
> {code}
> Secondly, the wrong framework is returned some of the time due to the logic
> of URLHandlers.getFrameworkContext() - in this method it assumes that there
> will be a bundle class loader on the stack, which is not true when the
> launcher is starting a bundle (the framework reflectively loads the Activator
> type which requires a URL check to set the security domain).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5975) URLHandlersStreamHandlerProxy - OPEN_CONNECTION_PROXY null
[
https://issues.apache.org/jira/browse/FELIX-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679962#comment-16679962
]
Karl Pauls commented on FELIX-5975:
---
I'm not sure how to fix it yet. It would be helpful if you could reproduce it
in a setting where you can try a patched framework (preferably with framework
6.0.1).
> URLHandlersStreamHandlerProxy - OPEN_CONNECTION_PROXY null
> --
>
> Key: FELIX-5975
> URL: https://issues.apache.org/jira/browse/FELIX-5975
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.6.1
> Environment: AIX server box, Tomcat 8.0.53
>Reporter: Julien Jalageas
>Assignee: Karl Pauls
>Priority: Blocker
> Fix For: framework-6.0.2
>
> Attachments: stacktrace.txt
>
>
> Hi,
> I am running into a blocking issue since I've upgraded from Tomcat 7.0.73 to
> Tomcat 8.0.53, SOAP based web services are failing with the following error:
> java.lang.IllegalStateException: *Stream handler unavailable due to: null*
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:359)
> Using a remote debugger, I was able to find that the real exception is
> actually a Null Pointer Exception thrown from
> *URLHandlersStreamHandlerProxy*.java, line 351:
> return (URLConnection) *OPEN_CONNECTION_PROXY*.invoke(svc, new Object[]\{url,
> proxy});
> where *OPEN_CONNECTION_PROXY* is null (I've attached the full stacktrace).
> Is there a fix available?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5975) URLHandlersStreamHandlerProxy - OPEN_CONNECTION_PROXY null
[
https://issues.apache.org/jira/browse/FELIX-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-5975:
--
Fix Version/s: framework-6.0.2
> URLHandlersStreamHandlerProxy - OPEN_CONNECTION_PROXY null
> --
>
> Key: FELIX-5975
> URL: https://issues.apache.org/jira/browse/FELIX-5975
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.6.1
> Environment: AIX server box, Tomcat 8.0.53
>Reporter: Julien Jalageas
>Priority: Blocker
> Fix For: framework-6.0.2
>
> Attachments: stacktrace.txt
>
>
> Hi,
> I am running into a blocking issue since I've upgraded from Tomcat 7.0.73 to
> Tomcat 8.0.53, SOAP based web services are failing with the following error:
> java.lang.IllegalStateException: *Stream handler unavailable due to: null*
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:359)
> Using a remote debugger, I was able to find that the real exception is
> actually a Null Pointer Exception thrown from
> *URLHandlersStreamHandlerProxy*.java, line 351:
> return (URLConnection) *OPEN_CONNECTION_PROXY*.invoke(svc, new Object[]\{url,
> proxy});
> where *OPEN_CONNECTION_PROXY* is null (I've attached the full stacktrace).
> Is there a fix available?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] felix pull request #160: [FELIX-5978] Ensure getClassLoader() is called in a...
GitHub user timothyjward opened a pull request: https://github.com/apache/felix/pull/160 [FELIX-5978] Ensure getClassLoader() is called in a safe way when sec⦠â¦urity is enabled Previously URLHandlers would explode when security was on because it didn't have permission to get the ClassLoader all the way down the stack Signed-off-by: Tim Ward You can merge this pull request into a Git repository by running: $ git pull https://github.com/timothyjward/felix FELIX-5978 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/felix/pull/160.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #160 commit e30d80a31b03731fd1b67fb551d58b10741eb5d1 Author: Tim Ward Date: 2018-11-08T12:11:29Z [FELIX-5978] Ensure getClassLoader() is called in a safe way when security is enabled Previously URLHandlers would explode when security was on because it didn't have permission to get the ClassLoader all the way down the stack Signed-off-by: Tim Ward ---
