Idiomatic Wicket way of serving resources from Amazon S3 - wicket

Question

What is the Wicket way of serving user-uploaded assets from AWS S3?
Requirements:
No direct requests from browser to S3; all traffic is proxied through our servers;
Allow assets to be cached by the browser with cache busting (either via checksums or a version field in the database);
Asset are served to authorized users only.
I can think of the following solutions:
A single SharedResource for all resources that parses the URL and streams the assets:
// resource definition:
mountResources("/assets/${path}", new ResourceReference("assets") {
public IResource getResource() {
return new AbstractResource() {
public ResourceResponse newResourceResponse(RequestAttribute attributes) {
String path = attributes.getParameters().get("path").toString()
// request S3 and stream the content
// handle caching / busting by hand
}
}
}
})
// Usage:
page.add(new Image("image", new SharedResourceReference("assets"), new PageParameters().add("path", "image.jpg"))
Create a new ResourceReference for each asset and pass it directly to image. Plug into Wicket's caches by letting the Resource implement IStaticCacheableResource:
class S3ResourceReference extends ResourceReference {
private String path;
public S3ResourceReference(String path) { ... }
public IResource getResource() {
return new S3Resource(path);
}
}
class S3Resource extends AbstractResource implements IStaticCacheableResource {
public S3ResourceStream getResourceStream() {
S3Object object = getObject(path);
return new S3ResourceStream(object);
}
public ResourceResponse newResourceResponse(Attributes attributes) {
S3ResourceStream stream = getResourceStream();
// populate response
}
}
class S3ResourceStream extends AbstractResourceStream {
S3ResourceStream(S3Object object) {
// ...
}
public InputStream getInputStream() { return object.objectContent }
// override metadata methods
}
// Usage:
page.add(new Image("image"), new S3ResourceReference("image.jpg"));
Which of these approaches look more idiomatic?
Are there any pitfalls with usage of IStaticCacheableResource in the second snippet?

Answer 1

Here are the differences in those two approaches:
Page instance locking
In 1) the requests for the resources are made to an application scoped resource
In 2) the request is to a page scoped resource
In the second case Wicket will lock the access to the page instance during the serving of the resource. For that reason I prefer using the application scoped resource.
IStaticCacheableResource
If the resource implements this interface then Wicket will mangle the produced url to the resource and will add something like -123456789 in its file name. This hash is the resource modification time in DEVELOPMENT mode and its MD5 checksum in PRODUCTION mode. This helps for caching.
I hope you realize that you can use a mix of 1) and 2) - an application scoped resource reference + IStaticCacheableResource.
One more thing: I usually use new MyResourceReference() instead of new SharedResourceReference("the-name").