[
http://jira.amdatu.org/jira/browse/AMDATU-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11493#comment-11493
]
Bram de Kruijff commented on AMDATU-425:
----------------------------------------
I'm not sure this is a bug. Not sure it is not either.... it is inconsistent
with the Felix HttpService behavior. Let me explain how this is implemented
right now and take from there. See
http://www.amdatu.org/confluence/display/Amdatu/Web+Framework for the
terminology.
1) It is true that if no target web resource is mapped the (tenant) filterchain
is not invoked. I believe (not sure) this is according to the servlet
specification as there is no "default" servlet specified. No target no chain..
wondering how mainstream containers handle this.
2) In Dispatcher we use this loophole to (legacy) support components that do
not use whiteboard (like system console).If we do not match a target we pass
the request back the HttpService and let it evaluate its own registry.
So...
3) You could map your own default 404servlet under "/" which will catch all
requests that did not map any other target. Once that is in place you can also
map that servlet. BUT this will effectively override the fallback meaning the
system console becomes unreachable.
4) You could implement a DispatchExtenderFilter which will be invoked before
the tenant chain and target are resolved. BUT this can never be tenantaware
and, there is a nice catch, you will never get a 404 because we fall back to
the HttpService when we don''t match a target :) Also a typical application
should not need or use DispatchExtenderFilter.
5) You could register your 404filter with the ExtHttpService directly. There
you will be able to catch them, BUT still this can never be tenantaware. Also,
this is a model we are trying to get away from a s it is non whiteboard (and
more).
So..
6) If 3 works for you, you're done in a couple off lines.
7) We can change Dispatcher behavior to invoke the tenant chain even without a
target, but throwing a 404 at the end will again disable the fallback mechanism.
8) Probably the only real solution is letting Dispatcher replace (or at least
hide) Felix HttpService and intercept non-whiteboard registrations so we can
handle them in one registry and do not need the uniformed fallback anymore...
Does any of the above (tmp) solution work for you in the short term?
> Filters are not invoked when a request doesn't map on a Servlet
> ---------------------------------------------------------------
>
> Key: AMDATU-425
> URL: http://jira.amdatu.org/jira/browse/AMDATU-425
> Project: Amdatu
> Issue Type: Bug
> Reporter: Arthur Meijer
> Fix For: 0.2.1
>
>
> If an incoming request can not be mapped on a servlet, the filter chain with
> url mappings is ignored.
> This way, it's not possible anymore to create a filter to log 404's or to
> redirect old urls to the new urls.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Amdatu-developers mailing list
[email protected]
http://lists.amdatu.org/mailman/listinfo/amdatu-developers
