The Resource may be null, but the Asset.toClientURI() doesn't have to
be null. Make the FileSystemAsset to the right thing when the Resource
is null.

I actually don't follow you about misisng Resources on the file
system. Why is this any different than files in the context?  You
might create a Resource (often, from another Resource) speculatively,
and use exists() or toUrl() to determine if a file actually exists.

On Fri, Apr 3, 2009 at 4:58 PM, manuel aldana <[email protected]> wrote:
> hi,
>
> i am implementing a 'FilesystemResource extends AbstractResource' for a
> tap-jira ticket.
>
> the contract for toUrl() says:
> return URL or null, if resource does not exist.
>
> this contract is fine for application bundled assets (context+classpath),
> but in my view not for outside-application maintained artifacts (like
> filesystem files). non-existent files in filesystem should not break the
> page but rather return a 404 when it is accessed from the browser. further
> more deploying filesystem artifacts and webapp are often distinct steps and
> should therefore be decoupled.
>
> but breaking this toUrl() contract would also break automatic failover if
> localized assets don't exist (the failover to non-localized asset is using
> the null-return information). maybe we can change the asset-localization
> failover and make it explicit inside module-configuration (enable/disable
> asset localization).
>
> we will come across the same problem when providing an URL alias asset
> (which could point to a CDN).
>
> what do you think?
>
> --
> manuel aldana
> [email protected]
> software-engineering blog: http://www.aldana-online.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>



-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to