GREYDiscussion points on merging URI2Repository and VirtualURI mapping.GREY
- URI2RepositoryMapping and VirtualURIMapping have very similar goal and functionality (i.e determine which repository node to use based on a URI)
- URI2RepositoryMapping and VirtualURIMapping have very similar interfaces, yet very different implementations and are not working "together"
- VirtualURIMapping need overhauling to fulfill MAGNOLIA-2343@jira
- See Proposal - overhaul and refactoring of AggregationState
- Could provide a way to generate links too (URI2RepositoryMapping already does, but not VirtualURIMapping)
- Merging the 2 functionality under one single and clean interface
- Needs to be symmetric (generating and resolving links)
- Using mechanisms similar to Apache's mod_rewrite: rules are executed one after the other, and each has the possibility to interrupt the chain
- Some "rules" could be "end points", therefore providing a cleaner and simpler (configuration) replacement for the various and inconsistent points of extension we currently have (/.magnolia pages, intercept filter, servlets); this would seem to work as is, since servlets are currently right after the VirtualURIFilter. Same mechanism of "end point" could then also be used for activation handler, remoting, website rendering, ...
- Order of rules if configured under /modules/xyz/urimappings
- RepositoryMappingFilter and AggregatorFilter would be merged - is there any reason why ContentSecurityFilter sits in between these 2 ?