felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3296) URLHandlers caches null as values for common protocols
Date Thu, 03 May 2012 14:30:53 GMT

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

Felix Meschberger commented on FELIX-3296:

> The idea is that if there is a previous urlhandlersfactory, we should delegate to that
one. If it
> isn't doing that, there is a bug in there. Caching the null value is what should happen.

Event the platform is not expecting the URLStreamHandlerFactory to be "complete". If the factory
does not return anything, it checks with its known handler classes (see URL.getURLStreamHandler(String);
at least in the Sun VM).

> Caching the null value is what should happen

That's still happening, if there is a null situation after all.

> Thing is, somebody on the outside doesn't want us to see the classes, so we shouldn't
try to get them from some place else

Agreed. But then that somebody (URLStreamHandlerFactory) should provide the handlers. Particularly
the jar: handler but probably also the other ones, at least http: and https: would be helpful.

> but the URLHandlers are a very tricky hack to begin with so lets see whether there is
a different way. 

I'd love to have a better solution ;-)

> Am I correct in saying that jboss installs its own urlhandlersfactory which will give
us the required protocols? 

It installs, but does not give the missing handlers, which is why I did that trickery.

BTW: The patch implements exactly the three steps: trying the factory, falling back to known
packages in framework class loader, falling back to known packages in system class loader.
> 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


View raw message