VirtualJournal: Create ServletFilter for "static" (e.g. images) files that does cascading lookup

the initial impl will try a minimalistic approach:

• rewrite URI to point to desired file
• let other Container machinery handle:
  • security/permissions
  • caching
  • etc.

this approach is lightweight and keeps System concerns, security/caching/etc., orthogonal v. forcing the impl to be security/cache/etc. aware.

Why is there URI rewriting? For these files, what container machinery will it go through? If it is simply serving up a static file from the file system, I'm unclear about what is initially needed besides the ability to determine what file is needed and stream it back. Caching can be placed outside of it as is mentioned.

re caching: why not use standard caching v. us impl an (eh|os)cache solution? also, serving directly makes the servlet responsible for security re relative pathing, other URI hacks etc. a lot of this machinery is already in place, e.g. why descend into issues like block size for read/writes on the return stream, etc. the philosophy is to drive the container/app as lightly as possible, v. impl yet another container func.

I'm now pretty confused. Caching is a separate issue. I'm agreeing with you that a) it should be outside of the servlet filter, and b) we use a standard package. If it is a servlet filter, what is going to send the file back? Are you saying send a redirect back to the client (http 302)? Is that what you mean me URI rewriting? I'm not sure that's a good idea given the number of items on just the home page right now. A simple request/response cached wouldn't seem to work well in the scenario either as it would always have to do a lookup for the resource and send the 302.

I'm also advocating for a light implementation. I'm not trying to add anything to the container. Actually trying to remove it from the container as much as possible.

the ServletFilter? would rewrite the URI in the HttpRequest?, it would then be handled just like any other URI re caching, "who sends it back", etc. no 302s, just modify the URI in the HttpRequest? and continue processing as normal.

Oh, I see what you're saying. I think you'd still want a cache to sit in front of the filter, though, wouldn't you? That way you wouldn't need to even do the lookup. These resources aren't going to be (or don't need to be) handled by the struts2 web application. We can configure a cache filter to match whatever resources and key off the hostname (or whatever determines the journal) and the requested resource.

the cache will not know what to serve until after the lookup. unless the lookup "logic" is also known by the cache. the initial proposed mapping is simple, I can imagine that at some point user profiles, etc. may be involved. as far as the struts2 webapp, it shouldn't even see these as they'll be served by the cache filter, once it knows what the mapping is.

Replying to jsuttor:

the cache will not know what to serve until after the lookup. unless the lookup "logic" is also known by the cache. the initial proposed mapping is simple, I can imagine that at some point user profiles, etc. may be involved.

Yes and no. Right now, I think it is probably safe to assume that all the logic will be based on information in the request. There wouldn't have to be any logic in the cache filter. It's matching based on keys we define. If, in the future, things need to happen based on additional information like a user profile, I think we may need to rework more than just the cache.

as far as the struts2 webapp, it shouldn't even see these as they'll be served by the cache filter, once it knows what the mapping is.

Yes, that's my point. The webapp will never see these requests right now (even if there is no cache). I think we're generally in agreement, and things are getting lost in the text of the discussion.

Replying to stevec:

Replying to jsuttor:

the cache will not know what to serve until after the lookup. unless the lookup "logic" is also known by the cache. the initial proposed mapping is simple, I can imagine that at some point user profiles, etc. may be involved.

Yes and no. Right now, I think it is probably safe to assume that all the logic will be based on information in the request. There wouldn't have to be any logic in the cache filter. It's matching based on keys we define. If, in the future, things need to happen based on additional information like a user profile, I think we may need to rework more than just the cache.

But then you have to duplicate the selection-logic in the part that generates the cache keys. I agree with Jeff here that the caches should be involved after the url-rewriting - the performance hit of doing the url-rewriting each time should be unmeasurable, assuming the filter caches things like directory-lookups.

Replying to ronald:

Replying to stevec:

Replying to jsuttor:

the cache will not know what to serve until after the lookup. unless the lookup "logic" is also known by the cache. the initial proposed mapping is simple, I can imagine that at some point user profiles, etc. may be involved.

Yes and no. Right now, I think it is probably safe to assume that all the logic will be based on information in the request. There wouldn't have to be any logic in the cache filter. It's matching based on keys we define. If, in the future, things need to happen based on additional information like a user profile, I think we may need to rework more than just the cache.

But then you have to duplicate the selection-logic in the part that generates the cache keys. I agree with Jeff here that the caches should be involved after the url-rewriting - the performance hit of doing the url-rewriting each time should be unmeasurable, assuming the filter caches things like directory-lookups.

No, you don't have any logic there. If you consider that the so-called logic is a formula, and you are simply substituting in variables into the formula to get a result, and the variables are all coming from the request, you don't need to duplicate any logic in the cache key generation. I'm assuming, of course, that feeding in the same variables to the "logic" will always give you the same result. Thus it can't receive any other input (say from stored session variables that the app changes at various times).

see impl @ source:/head/plosone/webapp/src/main/java/org/plos/web/VirtualJournalMappingFilter.java

Milestone 0.8 deleted