felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-5204) IllegalStateException when using custom URL handlers for bundles
Date Mon, 07 Mar 2016 11:16:40 GMT

    [ https://issues.apache.org/jira/browse/FELIX-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15182886#comment-15182886

Karl Pauls commented on FELIX-5204:

I did think about this issue for a while and I agree that there seems to be no really good
solution for your special case. 

Just to make this clear so, we are talking about a special case that is the issue here where
we are up against the Java standard libraries which unfortunately, one more time, don’t
play well with dynamic applications — hence, I strongly suggest that this is not a bug in
felix as such but more a feature request for a workaround that makes your scenario possible.

In general though, I don't think using the cached location is the right thing to do. The cached
location is meaningless as a code source for the actual purpose of having a code source. I
realize that there are libraries out there that are misusing the code source as a way to get
access to the source resources (as is the issue in your case) and that is why we have this
somewhat roundabout way of doing things the way we do them to make this possible. However,
you are running into yet a more complicated scenario where the code source is not valid anymore
at the time it is used and there is very little we can do about it. 

Personally, I’d say that this is not our problem and the correct way of fixing this on your
side is to provide the url handler you need as a built-in handler (i.e. use the jvm extension
property to provide the handler). That would make your scenario work and is the correct way
of doing it but assumes you have control over the jvm.  

Given that limitation I’m not against doing what you are proposing as a workaround but I
suggest we make it a real one i.e., by default we behave like we do currently and introduce
a configuration property to switch to the cached url. 

If that would work for you, could you modify your patch so that it introduces a property to
enable using cache urls only if it is set and otherwise keeps the current behavior including
the handling of the "reference:" protocol that your current proposal seems to remove?

> IllegalStateException when using custom URL handlers for bundles
> ----------------------------------------------------------------
>                 Key: FELIX-5204
>                 URL: https://issues.apache.org/jira/browse/FELIX-5204
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: framework-5.4.0
>            Reporter: Guillaume Nodet
>            Assignee: Guillaume Nodet
>             Fix For: framework-5.6.0
> The following exception can happen after having restarted the whole framework.
> {code}
> java.lang.IllegalStateException: Stream handler unavailable.
> 	at org.apache.felix.framework.URLHandlersStreamHandlerProxy.getDefaultPort(URLHandlersStreamHandlerProxy.java:180)
> 	at java.net.URLStreamHandler.sameFile(URLStreamHandler.java:407)
> 	at org.osgi.service.url.AbstractURLStreamHandlerService.sameFile(AbstractURLStreamHandlerService.java:131)
> 	at java.net.URLStreamHandler.equals(URLStreamHandler.java:333)
> 	at org.osgi.service.url.AbstractURLStreamHandlerService.equals(AbstractURLStreamHandlerService.java:81)
> 	at org.apache.felix.framework.URLHandlersStreamHandlerProxy.equals(URLHandlersStreamHandlerProxy.java:163)
> 	at java.net.URL.equals(URL.java:870)
> 	at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:940)
> 	at javax.crypto.JceSecurityManager.getCryptoPermission(JceSecurityManager.java:124)
> 	at javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2587)
> 	at javax.crypto.Cipher.initCryptoPermission(Cipher.java:700)
> 	at javax.crypto.Cipher.chooseProvider(Cipher.java:863)
> 	at javax.crypto.Cipher.init(Cipher.java:1396)
> 	at javax.crypto.Cipher.init(Cipher.java:1327)
> 	at org.apache.sshd.common.cipher.BaseCipher.init(BaseCipher.java:60)
> 	at org.apache.karaf.shell.ssh.SshUtils.buildCiphers(SshUtils.java:89)
> 	at org.apache.karaf.shell.ssh.Activator.createSshServer(Activator.java:183)
> 	at org.apache.karaf.shell.ssh.Activator.doStart(Activator.java:111)
> 	at org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:233)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> {code}
> The problems seems to be that the ProtectionDomain of the classes loaded from bundles
do use the URL handler as their code source.  This means that any access to those URL will
throw IllegalStateException after the framework has been shutdown.
> The protection domain should use the url the jar from the filesystem for the code source
url instead.

This message was sent by Atlassian JIRA

View raw message