Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 0 rates

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)

Implementation ideas

  • 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, ...

Possible pitfalls

  • 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 ?
  • No labels