[ 
https://issues.apache.org/jira/browse/TAP5-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121044#comment-14121044
 ] 

Jochen Kemnade commented on TAP5-2185:
--------------------------------------

Well, without the fix, I get a 404 straightaway, *with* the fix, I get a 302, 
redirecting to a *context* asset (which does not even exist), and get a 404 
when that is requested. The effect is about the same (the image is not shown), 
but the behavior is rather confusing.
{{asset.getResource().exists()}} won't help, because 
{{ContextResource.resolveURL()}} will resolve the {{url}} to {{null}} which 
{{validateURL}} will accept.
Maybe we could check the resource's class, use the context asset factory for 
{{ContextResource}}, the classpath asset factory for {{ClasspathResource}} and 
log a warning and return a 404 for custom assets. What do you think?

> Problem with the asset checksums and relative paths based on them
> -----------------------------------------------------------------
>
>                 Key: TAP5-2185
>                 URL: https://issues.apache.org/jira/browse/TAP5-2185
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.4
>            Reporter: Lenny Primak
>            Assignee: Thiago H. de Paula Figueiredo
>              Labels: month-of-tapestry
>             Fix For: 5.4
>
>
> When JavaScript modules reference other (non-tapestry) JS code via relative 
> paths,
> or absolute paths that have to be configured, the checksum is preventing
> the other resources from being accessed properly
> Discussion regarding this can be found here:
> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Re-5-4-Problems-with-the-asset-checksums-and-relative-paths-based-on-them-td5723366.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to