You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Jesse Long (Created) (JIRA)" <ji...@apache.org> on 2012/03/08 01:30:57 UTC

[jira] [Created] (WICKET-4443) AbstractClassResolver recreates URL incorrectly

AbstractClassResolver recreates URL incorrectly
-----------------------------------------------

                 Key: WICKET-4443
                 URL: https://issues.apache.org/jira/browse/WICKET-4443
             Project: Wicket
          Issue Type: Bug
          Components: wicket
    Affects Versions: 1.5.4
            Reporter: Jesse Long


AbstractClassResolver converts java.net.URLs to their external form (java.lang.String), then converts them back to java.net.URLs. It looks like the conversion to external form is for comparison between URLs (comparing URLs is slow, Strings not so - see WICKET-3867), because we only want one result per URL (Set<URL>).

The problem is that, when converting from the external form back to a java.net.URL, the no context URL is given to the URL constructor, just the external form String is given. Passing a context URL to the java.net.URL constructor is the only way of setting the URLStreamHandler related to the URL. So, if you have some exotic URL schema, like I do, using protocols the standard Java libraries dont know about, you can no longer load your resources.

Please see the code in CompoundClassResolver#getResources() - it implements a unique list of URL by comparing the external forms of the URLs, while still managing to use the original URL objects, with their URLStreamHandlers attached.

--
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

        

[jira] [Commented] (WICKET-4443) AbstractClassResolver recreates URL incorrectly

Posted by "Martin Grigorov (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227530#comment-13227530 ] 

Martin Grigorov commented on WICKET-4443:
-----------------------------------------

The suggestion is committed.
                
> AbstractClassResolver recreates URL incorrectly
> -----------------------------------------------
>
>                 Key: WICKET-4443
>                 URL: https://issues.apache.org/jira/browse/WICKET-4443
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.5.4
>            Reporter: Jesse Long
>            Assignee: Martin Grigorov
>              Labels: classloader
>             Fix For: 1.5.6, 6.0.0
>
>         Attachments: WICKET-4443.patch
>
>
> AbstractClassResolver converts java.net.URLs to their external form (java.lang.String), then converts them back to java.net.URLs. It looks like the conversion to external form is for comparison between URLs (comparing URLs is slow, Strings not so - see WICKET-3867), because we only want one result per URL (Set<URL>).
> The problem is that, when converting from the external form back to a java.net.URL, the no context URL is given to the URL constructor, just the external form String is given. Passing a context URL to the java.net.URL constructor is the only way of setting the URLStreamHandler related to the URL. So, if you have some exotic URL schema, like I do, using protocols the standard Java libraries dont know about, you can no longer load your resources.
> Please see the code in CompoundClassResolver#getResources() - it implements a unique list of URL by comparing the external forms of the URLs, while still managing to use the original URL objects, with their URLStreamHandlers attached.

--
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

        

[jira] [Resolved] (WICKET-4443) AbstractClassResolver recreates URL incorrectly

Posted by "Martin Grigorov (Resolved) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov resolved WICKET-4443.
-------------------------------------

    Resolution: Fixed
    
> AbstractClassResolver recreates URL incorrectly
> -----------------------------------------------
>
>                 Key: WICKET-4443
>                 URL: https://issues.apache.org/jira/browse/WICKET-4443
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.5.4
>            Reporter: Jesse Long
>            Assignee: Martin Grigorov
>              Labels: classloader
>             Fix For: 1.5.6, 6.0.0
>
>         Attachments: WICKET-4443.patch
>
>
> AbstractClassResolver converts java.net.URLs to their external form (java.lang.String), then converts them back to java.net.URLs. It looks like the conversion to external form is for comparison between URLs (comparing URLs is slow, Strings not so - see WICKET-3867), because we only want one result per URL (Set<URL>).
> The problem is that, when converting from the external form back to a java.net.URL, the no context URL is given to the URL constructor, just the external form String is given. Passing a context URL to the java.net.URL constructor is the only way of setting the URLStreamHandler related to the URL. So, if you have some exotic URL schema, like I do, using protocols the standard Java libraries dont know about, you can no longer load your resources.
> Please see the code in CompoundClassResolver#getResources() - it implements a unique list of URL by comparing the external forms of the URLs, while still managing to use the original URL objects, with their URLStreamHandlers attached.

--
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

        

[jira] [Commented] (WICKET-4443) AbstractClassResolver recreates URL incorrectly

Posted by "Jesse Long (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227005#comment-13227005 ] 

Jesse Long commented on WICKET-4443:
------------------------------------

I looked around. UrlResourceStreamReference is package private to the org.apache.wicket.util.resource.locator.caching package. It is used ONLY by the CachingResourceStreamLocator class, which converts UrlResourceStream instances to UrlResourceStreamReference instances, and stores them in a java.util.Map.

This map acts as a cache of the result of locating resources, including not-found entries. The idea behind the cache it to avoid having to FIND resources every time they are required, but just use the caches find result from the map.

The map is never serialized, as CachingResourceStreamLocator is not Serializable and neither is IResourceStreamLocator, which it implements.

IResourceStreamLocator is mainly used from: Application.get().getResourceSettings().getResourceStreamLocator().

I vote we just keep a reference to the original URL.

Pro: we can load arbitrary URLs, from any url scheme, using its configured URLStreamHandler.

Con: the URL object probably uses slightly more memory that the external form string.
                
> AbstractClassResolver recreates URL incorrectly
> -----------------------------------------------
>
>                 Key: WICKET-4443
>                 URL: https://issues.apache.org/jira/browse/WICKET-4443
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.5.4
>            Reporter: Jesse Long
>            Assignee: Martin Grigorov
>              Labels: classloader
>             Fix For: 1.5.6, 6.0.0
>
>         Attachments: WICKET-4443.patch
>
>
> AbstractClassResolver converts java.net.URLs to their external form (java.lang.String), then converts them back to java.net.URLs. It looks like the conversion to external form is for comparison between URLs (comparing URLs is slow, Strings not so - see WICKET-3867), because we only want one result per URL (Set<URL>).
> The problem is that, when converting from the external form back to a java.net.URL, the no context URL is given to the URL constructor, just the external form String is given. Passing a context URL to the java.net.URL constructor is the only way of setting the URLStreamHandler related to the URL. So, if you have some exotic URL schema, like I do, using protocols the standard Java libraries dont know about, you can no longer load your resources.
> Please see the code in CompoundClassResolver#getResources() - it implements a unique list of URL by comparing the external forms of the URLs, while still managing to use the original URL objects, with their URLStreamHandlers attached.

--
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

        

[jira] [Updated] (WICKET-4443) AbstractClassResolver recreates URL incorrectly

Posted by "Jesse Long (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesse Long updated WICKET-4443:
-------------------------------

    Attachment: WICKET-4443.patch

Patch that changes various parts, mainly IClassResolvers to use a TreeSet with a Comparator that compares URLs' toExternalForm when a Set<URL> is needed.

Also, add some docs about possible MalformedURLException in UrlResourceStreamReference (related to this bug)
                
> AbstractClassResolver recreates URL incorrectly
> -----------------------------------------------
>
>                 Key: WICKET-4443
>                 URL: https://issues.apache.org/jira/browse/WICKET-4443
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.5.4
>            Reporter: Jesse Long
>              Labels: classloader
>         Attachments: WICKET-4443.patch
>
>
> AbstractClassResolver converts java.net.URLs to their external form (java.lang.String), then converts them back to java.net.URLs. It looks like the conversion to external form is for comparison between URLs (comparing URLs is slow, Strings not so - see WICKET-3867), because we only want one result per URL (Set<URL>).
> The problem is that, when converting from the external form back to a java.net.URL, the no context URL is given to the URL constructor, just the external form String is given. Passing a context URL to the java.net.URL constructor is the only way of setting the URLStreamHandler related to the URL. So, if you have some exotic URL schema, like I do, using protocols the standard Java libraries dont know about, you can no longer load your resources.
> Please see the code in CompoundClassResolver#getResources() - it implements a unique list of URL by comparing the external forms of the URLs, while still managing to use the original URL objects, with their URLStreamHandlers attached.

--
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

        

[jira] [Resolved] (WICKET-4443) AbstractClassResolver recreates URL incorrectly

Posted by "Martin Grigorov (Resolved) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov resolved WICKET-4443.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 6.0.0
                   1.5.6
         Assignee: Martin Grigorov

Thanks for the patch!

I added a note to UrlResourceStreamReference's javadoc explaining how to deal with custom URL schemes. Unfortunately there is no getter method in j.n.URL to get its handler and reuse it later ...
                
> AbstractClassResolver recreates URL incorrectly
> -----------------------------------------------
>
>                 Key: WICKET-4443
>                 URL: https://issues.apache.org/jira/browse/WICKET-4443
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.5.4
>            Reporter: Jesse Long
>            Assignee: Martin Grigorov
>              Labels: classloader
>             Fix For: 1.5.6, 6.0.0
>
>         Attachments: WICKET-4443.patch
>
>
> AbstractClassResolver converts java.net.URLs to their external form (java.lang.String), then converts them back to java.net.URLs. It looks like the conversion to external form is for comparison between URLs (comparing URLs is slow, Strings not so - see WICKET-3867), because we only want one result per URL (Set<URL>).
> The problem is that, when converting from the external form back to a java.net.URL, the no context URL is given to the URL constructor, just the external form String is given. Passing a context URL to the java.net.URL constructor is the only way of setting the URLStreamHandler related to the URL. So, if you have some exotic URL schema, like I do, using protocols the standard Java libraries dont know about, you can no longer load your resources.
> Please see the code in CompoundClassResolver#getResources() - it implements a unique list of URL by comparing the external forms of the URLs, while still managing to use the original URL objects, with their URLStreamHandlers attached.

--
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

        

[jira] [Commented] (WICKET-4443) AbstractClassResolver recreates URL incorrectly

Posted by "Jesse Long (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225907#comment-13225907 ] 

Jesse Long commented on WICKET-4443:
------------------------------------

UrlResourceStreamReference caches the URL as a string. Is there any reason for this? If we just keep a reference to the URL object, it may suffice.

My first thought was that it caches the URL as a string in external form because it needs to be serialized, but UrlResourceStreamReference does not implement {Serializable, IClusterable} and neither does its parent - AbstractResourceStreamReference, and neither does the interface require serialization - IResourceStreamReference. Could we not just let UrlResourceStreamReference keep a reference to the original URL?
                
> AbstractClassResolver recreates URL incorrectly
> -----------------------------------------------
>
>                 Key: WICKET-4443
>                 URL: https://issues.apache.org/jira/browse/WICKET-4443
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.5.4
>            Reporter: Jesse Long
>            Assignee: Martin Grigorov
>              Labels: classloader
>             Fix For: 1.5.6, 6.0.0
>
>         Attachments: WICKET-4443.patch
>
>
> AbstractClassResolver converts java.net.URLs to their external form (java.lang.String), then converts them back to java.net.URLs. It looks like the conversion to external form is for comparison between URLs (comparing URLs is slow, Strings not so - see WICKET-3867), because we only want one result per URL (Set<URL>).
> The problem is that, when converting from the external form back to a java.net.URL, the no context URL is given to the URL constructor, just the external form String is given. Passing a context URL to the java.net.URL constructor is the only way of setting the URLStreamHandler related to the URL. So, if you have some exotic URL schema, like I do, using protocols the standard Java libraries dont know about, you can no longer load your resources.
> Please see the code in CompoundClassResolver#getResources() - it implements a unique list of URL by comparing the external forms of the URLs, while still managing to use the original URL objects, with their URLStreamHandlers attached.

--
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

        

[jira] [Reopened] (WICKET-4443) AbstractClassResolver recreates URL incorrectly

Posted by "Martin Grigorov (Reopened) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov reopened WICKET-4443:
-------------------------------------


I'll investigate this option next week.
                
> AbstractClassResolver recreates URL incorrectly
> -----------------------------------------------
>
>                 Key: WICKET-4443
>                 URL: https://issues.apache.org/jira/browse/WICKET-4443
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.5.4
>            Reporter: Jesse Long
>            Assignee: Martin Grigorov
>              Labels: classloader
>             Fix For: 1.5.6, 6.0.0
>
>         Attachments: WICKET-4443.patch
>
>
> AbstractClassResolver converts java.net.URLs to their external form (java.lang.String), then converts them back to java.net.URLs. It looks like the conversion to external form is for comparison between URLs (comparing URLs is slow, Strings not so - see WICKET-3867), because we only want one result per URL (Set<URL>).
> The problem is that, when converting from the external form back to a java.net.URL, the no context URL is given to the URL constructor, just the external form String is given. Passing a context URL to the java.net.URL constructor is the only way of setting the URLStreamHandler related to the URL. So, if you have some exotic URL schema, like I do, using protocols the standard Java libraries dont know about, you can no longer load your resources.
> Please see the code in CompoundClassResolver#getResources() - it implements a unique list of URL by comparing the external forms of the URLs, while still managing to use the original URL objects, with their URLStreamHandlers attached.

--
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