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