[
https://issues.apache.org/jira/browse/FELIX-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated FELIX-3296:
-------------------------------------
Attachment: FELIX-3296.patch
Proposed patch:
Instead of just trying to load the well-known default handlers we have to play
some tricks. The patch changes the setup as follows to load each pre-defined
scheme:
1. try installed URLStreamHandlerFactory if any
2. try loading well-known handler class through framework class loader
3. try loading well-known handler class through system class loader
(ClassLoader.getSystemClassLoader())
The first step IMHO makes sense if the pre-installed factory would overwrite
any well-known handler (for example the file: handler from JBoss). The last
step is to circumvent the JBoss ModuleClassLoader, which effectively hides the
Java Platform classes (as OSGi does).
> URLHandlers caches null as values for common protocols
> ------------------------------------------------------
>
> Key: FELIX-3296
> URL: https://issues.apache.org/jira/browse/FELIX-3296
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-3.0.8
> Environment: Apache Sling org.apache.sling.launchpad-6.war
> running in build of current master branch of JBoss Application Server 7
> (https://github.com/jbossas/jboss-as). I'm reporting this against
> framework-3.0.8 as that seems to be what's included in Sling, but a review of
> the code in 4.0.2 shows the class is the same.
> Reporter: Brian Stansberry
> Assignee: Karl Pauls
> Fix For: framework-4.2.0
>
> Attachments: FELIX-3296.patch
>
>
> A JBoss AS7 user has reported being unable to run the Apache Sling web app in
> AS 7. I determined that the issue is once
> org.apache.felix.framework.URLHandlers is installed as the JVM's
> URLStreamHandlerFactory, URLs with protocol "jar" can no longer be parsed.[1]
> Here's the problem. Line references are to [2]:
> 1) The singleton of this URLHandlers class gets instantiated. It attempts to
> load and cache standard handlers for common protocols. At L148 it does this
> for "jar".
> 2) At L353 it's trying to load one of the standard URLStreamHandler impls for
> the "jar" protocol, e.g. sun.net.www.protocol.jar.Handler. It uses
> Class.forName("sun.net.www.protocol.jar.Handler"). This fails (returns null)
> because the JBoss Modules module for this deployment does not have visibility
> to this class.
> 3) At L367 it stores "null" for this protocol in its m_builtIn map under key
> "jar".
> 4) Thereafter any call to createURLStreamHandler (L390) will call into
> getBuiltInStreamHandler (L413). That will return null because it will find
> the null in m_builtIn stored in step 3) above (L330 & L332).
> A fairly simple fix is to at L148 test the result of the
> getBuiltInStreamHandler call and if null remove the entry from m_builtIn. It
> should probably do the same kind of thing in the init(String) method (L120).
> An alternative is to do all the step 1) stuff between L142 and L148 after the
> try/catch block at L157. At that point a ref to the standard AS7
> URLStreamHandlerFactory will be available in field m_streamHandlerFactory and
> can be used to load the standard handlers rather than relying on
> Class.forName.
> [1] http://lists.jboss.org/pipermail/jboss-as7-dev/2012-January/004956.html
> [2]
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.felix/org.apache.felix.framework/2.0.5/org/apache/felix/framework/URLHandlers.java
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
