Intercepting with a Filter is "too late".

[Will Hartung <wi...@msoft.com>]

Hi all,

I have a simple Filter.

The role of the filter is essentially to "lazy load" a static resource
in to the space of my webapp from an external repository so that Tomcat
can serve it directly.

The goal was to store this content out side of the web app so that I
could easily upgrade and deploy bug fixes and changes without losing the
actual data, but still allow Tomcat to do the actual serving of the content.

I want Tomcat to serve up the content simply because the stock container
does it very well, is well tested, knows all the mime types, etc. vs
writing a servlet that reads from the external repository and then
streams it out itself. That, to me, is pretty redundant for a simple
task of serving "static" resources.

The problem that I'm having, however, is when I ask for a "non-existent"
resource.

Specifically, consider if I ask for http://example.com/myapp/static/xyz.jpg.

In a normal webapp, you would have a static folder containing xyz.jpg,
and tomcat would simply serve it up straight.

I have my filter intercepting on /static, it checks the local web app
dir and notices that the file, xyz.jpg, does not exist and proceed to
copy it in to the web app directory. Then it simply does a Filter chain
to let the request proceed.

The problem is that when a resource is freshly copied, Tomcat replies
with a 404, even though it fired my filter, and my filter has copied the
resource. It's "pre-determined", even before firing my filter, that the
resource does not exist, and fails anyway, even though I put the
resource where it belongs before I continue on the request chain.

When I make a new request, Tomcat sees the new file and serves it up
normally.

Anyone have any thoughts on how to get around this? If not, can someone
point me to the handle static resource code in the tomcat source base so
I can yank it out and put it in my own application? It's seems like a
silly thing to do, cutting and pasting that handler logic, but doing it
AGAIN, is an even sillier thing to do.

Regards,

Will Hartung
(willh@msoft.com)



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Intercepting with a Filter is "too late".

[Will Hartung <wi...@msoft.com>]

Leon Rosenberg wrote:
> I think the quick and dirty solution would be to send a redirect to
> the same url with a dummy param after you copied the file  from the
> filter and abort execution. The second request should get the file
> then.
Yea, I've considered that. The only issue at the moment is sometimes it 
take TWO clicks through for the file to show up, so there's no guarantee 
(to me at least) that the redirect will actually work.
> For the future development I would consider streaming the content of
> the file through a servlet instead of copying it. Depending on the
> number and size of the resources you could cache everything and be
> faster.
It would just be nice if Tomcat exposed their logic for this. My point 
being that Tomcat ALREADY does this kind of streaming, the OS does the 
caching for me, so such a fundamental process shouldn't have to be 
rewritten. Also, at least with Tomcat 4, for some bizarre reason with 
PDFs, if we streamed the data, we'd have strange behaviors, but if 
Tomcat delivered the file, they would work fine. We duplicated the 
headers, checked everything with a proxy, and couldn't tell the 
difference, but apparently Acrobat could. So, we write PDFs to disk and 
have Tomcat deal with it.

I wonder if it would work with a Forward. Servlet takes the request, 
creates the file if necessary, then Forwards to the new file. Use the 
servlet as a crude renaming device.

Regards,

Will Hartung
(willh@msoft.com)


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Intercepting with a Filter is "too late".

[Leon Rosenberg <ro...@googlemail.com>]

On 8/23/06, Will Hartung <wi...@msoft.com> wrote:
...
> I have my filter intercepting on /static, it checks the local web app
> dir and notices that the file, xyz.jpg, does not exist and proceed to
> copy it in to the web app directory. Then it simply does a Filter chain
> to let the request proceed.
>
> The problem is that when a resource is freshly copied, Tomcat replies
> with a 404, even though it fired my filter, and my filter has copied the
> resource. It's "pre-determined", even before firing my filter, that the
> resource does not exist, and fails anyway, even though I put the
> resource where it belongs before I continue on the request chain.
>
> When I make a new request, Tomcat sees the new file and serves it up
> normally.
>
> Anyone have any thoughts on how to get around this? If not, can someone
> point me to the handle static resource code in the tomcat source base so
> I can yank it out and put it in my own application? It's seems like a
> silly thing to do, cutting and pasting that handler logic, but doing it
> AGAIN, is an even sillier thing to do.

I think that it's pretty logical behaviour since tomcat will probably
look for path resolution before any filter is called. Therefor it
already decided that the resource doesn't exist before your filter
copies it.
I think the quick and dirty solution would be to send a redirect to
the same url with a dummy param after you copied the file  from the
filter and abort execution. The second request should get the file
then.

For the future development I would consider streaming the content of
the file through a servlet instead of copying it. Depending on the
number and size of the resources you could cache everything and be
faster.

regards
leon



>
> Regards,
>
> Will Hartung
> (willh@msoft.com)
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org