https://issues.apache.org/bugzilla/show_bug.cgi?id=18500
--- Comment #5 from Christopher Schultz <ch...@christopherschultz.net> 2011-09-20 21:33:24 UTC --- Unfortunately for this enhancement, the Mapper is written to use a relatively high-performance binary search algorithm to find a matching <Host> given all the <Host> and <Alias> definitions (where <Alias>es are basically treated as if they were additional <Host> definitions with shared configuration information). Such an algorithm can't work with regular expressions because they can't be sorted in any sane way. Thus, a linear search would have to be performed which will degrade performance (along with the execution of all those regular expression matches). If we're going to do this, I would recommend that we add another layer of abstraction near the insertMap/find/findIgnoreCase mechanism. Something along these lines: 1. The Mapper works exactly as it currently does under "normal" operations. 2. When a Host (or Alias) is added with special markings (say, leading and trailing "/" marks which are easily recognizable and otherwise illegal in a hostname), we switch into "regex mode". 3. Entering into regex mode creates another List/Map/whatever of metadata that will need to be maintained: existing <Hosts> are processed-into this data structure. 4. Hosts (and Aliases) added after going into regex mode will of course have this metadata updated as appropriate 5. In internalMap, modify the call to findIgnoreCase depending upon the current mode: if we're in "normal" mode, just call findIgnoreCase and move-on; if we're in "regex" mode, make a different call that uses the aforementioned metadata to find the proper index into the <Host> array This could be done by re-factoring the Mapper to use a pair of new private inner classes: one that behaves like the current implementation, and one that works with regular expressions. Switching from one mode to the other could be done by replacing the currently-effective Mapper with one of the other type. You could even go back if you really wanted to. We will need a policy of conflict resolution: more than one <Host> could match. We can't use a policy like "longest match wins" because it's tough to tell which regex is "longer" due to their complexities. I would favor a linear search where the first-defined <Host> wins. The Digester should give us all <Host> elements in XML-order, so the user can specify the order of preference just by ordering server.xml to their liking. Thoughts? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
