[MAGNOLIA-380] Better url matcher for cache, security, virtual URI... Created: 07/May/05  Updated: 23/Jan/13  Resolved: 15/Nov/06

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 2.1 Final
Fix Version/s: 3.0 Final

Type: Improvement Priority: Minor
Reporter: Fabrizio Giustina Assignee: Fabrizio Giustina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

Actually Magnolia allow you to configure URIs with * and ? wildcards, which are converted to regexp for exaluation. This is not really performant and flexible, we should use a custom matcher instead (just like the patternmatcher in Ant).



 Comments   
Comment by Fabrizio Giustina [ 07/May/05 ]

removed the info.magnolia.cms.util.regexp package.
Added a new UrlPattern interface with a default wildcard implementation and a match-all implementation, plus junit tests
Changed all methods which used java.util.regexp in order to use the new Pattern interface (none of these methods were supposed to be called by users, so there should be no problem)

Please check if everythings works ok. This should also solve the priority issue when matching urls with more than one wildcard .
I also removed the unused oro dependency (and the mx4j dependency, don't know why it was there)

todo: change the internal implementation of SimpleUrlPatter removing regular expressions.

Comment by Magnolia International [ 15/Nov/06 ]

This is done as far as I can tell - if more work needed (see below), please create subtasks or (linked) new issues.

About the "avoiding regular expressions" comment - does it really have a noticeable impact? On performance, or usability ?

Generated at Mon Feb 12 03:16:51 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.