Danilo Ghirardelli ha scritto:
Just a simple question a co-worker made, and it really made me think about: "why Magnolia stops even the requests it can't handle and returns a 404 and not pass it to the next filter in chain?"
If I right understood your question, the reason is that Magnolia is *by default* the unique configured filter handling all requests coming (see web.xml of every Magnolia context).
Filters are configured under <config>/server/filters and if a request can not be matched with a page or with a virtualUriMapping the 404 standard Tomcat error page.
The reason of filter stop is that there are no configured resources to serve, so why go on among next filters?
I didn't find a good answer to this simple question, so maybe I'm missing some structural defition about Magnolia. There are the bypasses to exclude some of the requests you can actually classify in some pattern, but there is no way to say if a generic request will be really handled by Magnolia.
Since you are using a CMS, it is strong enough to have your legacy apps on a different context or map different requests with different extensions / target path. In this way you can split all requests between CMS and other systems.
Would be possible to add some sort of "404Voter",
or some other way to say to Magnolia "if you cannot handle it just let it go to the next filter in chain"?
If you want to use another apps in chain with Magnolia, you can consider to extend some of CMS filters here: <config>server/filters/CMS/* and try to extends the standard behaviour, maybe with some forward requests...
HTH, Matteo ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
