[
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
(v6.3.4#6332)
