[ https://issues.apache.org/jira/browse/TAP5-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693762#action_12693762 ]
Dan Adams commented on TAP5-423: -------------------------------- I've implemented something very similar to this in our CMS projects: there is a "fileasset" asset type which provides access to a filesystem-based store that is also accessible via a URL. You can't tell where it is based on the URL, you can only access files within that store so it's secure, and you can't tell where the files are actually located / served from (eg could be on a CDN rather or served through apache statically or something). By and large, this is has been great however one problem I ran into was that requesting an Asset that doesn't exist causes an exception but you may want to require a fileasset that doesn't exist so that you can write to it. But that wasn't hard to work around. This could be extended in the future without a lot of change to support multiple roots or even multiple content stores (eg one root is on a CDN, one is on a filesystem, and one is from a database) . It's a simple implementation right now used by one project (so the API hasn't yet been put through the paces) but I'd be willing to provide it if you'd like it. > Implement a file-system Asset type > ---------------------------------- > > Key: TAP5-423 > URL: https://issues.apache.org/jira/browse/TAP5-423 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core > Affects Versions: 5.0.18 > Reporter: manuel aldana > > currenty it is built in to retrieve assets from classpath and from webcontext. > a file system asset type which can retrieve stuff directly from the > filesystem (e.g. from /srv/statics/xxxx) makes also sense. > something like: > *ResourceFileSystem extends AbstractResource* and *FileSystemAssetFactory > extends AssetFactory* -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.