Re: Tomcat 7 & regex
On 25.12.2010 20:53, Mark Thomas wrote: On 25/12/2010 01:49, Tim Funk wrote: +0.5 - I wonder if in some cases - it may be preferable to use a property called split which lets the user define the separator which we can pass to String.split(). [Which OTOH may be more confusing (yet powerful) since the user is using a regex to split get a list of regex] I think that just makes it more complicated. There is no need to split anything up since the regex can just use |. Rather than mix regex plus our own proprietary splitting mechanism, I think we should just use the support already provided by regex to do the same thing. +1 Maybe reminding users about "|" with a *simple* example helps. Concerning IP addresses and regexp: The escaping of the contained dots is not really necessary, as long as one is matching the whole address from the beginning to the end because the dots in the real address can only match the (escaped or not) dots in the pattern. What might be helpful is a general way of expressing networks (network address plus netmask or bits). For httpd 2.4 there will be a general expression parser which contains an operator called "-ipmatch" so network addresses can be used not only in Allow/Deny (now: Require) but also everywhere else. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 27717] very slow in JSTL 1.1
https://issues.apache.org/bugzilla/show_bug.cgi?id=27717 Jeremy Boynes changed: What|Removed |Added Attachment #26445|0 |1 is obsolete|| --- Comment #22 from Jeremy Boynes 2010-12-27 14:18:26 EST --- Created an attachment (id=26448) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26448) Patch for XPath using Xalan API Continuation of patch 26445 with addition of a Xalan based implementation. -- 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
Re: Tomcat 7 & regex
Mark, On 12/24/2010 1:34 PM, Mark Thomas wrote: > There are a number of configuration properties defined as "comma > separated regular expressions". As someone pointed out at at ApacheCon > that is a little odd. It stops "," being used in an expression and is > inefficient. A comma can still be used in a regular expression as long as the rules about how we split the whole value are well-defined (like commas can be escaped for in-regexp use). > Having just been bitten by this while setting up the new Jira instance, > I intend change all properties that take regex in Tomcat 7 to use a > single regex. This will simplify the code, simplify configuration and > make the regex processing faster. So the plan would be to have users convert values like this: 127\.0\.0\.1, 10\.10\.10\.1, 192\.168\.1\.[0-9]+ to this: (127\.0\.0\.1|10\.10\.10\.1|192\.168\.1\.[0-9]+) I have some recommendations: 1. If it's not okay to break the "configuration interface", you should change the name(s) of the attribute(s) so that old configurations are easier to adapt to new environments. Something like "allowedIPs" might become "allowedIPPattern". I'm not sure if incompatibility is something we're concerned about, though there have been a number of pre-releases on the 7.0 branch and this sounds like quite a breaking change. 2. Make it clear /which/ regular expressions will be supported. I hate it when an API says "use a regular expression" and then they don't tell you they're using Jakarta-ORO which doesn't (conveniently) support Unicode and you have to spend a long time figuring out why your patterns aren't working. Presumably, we'll be using the JDK's regular expression classes: please just state that explicitly. 3. Please make it clear, on a per-attribute basis if appropriate, whether the pattern will implicitly use start-of-input and end-of-input markers on the ends. I've been bitten several times by the operational differences between using Matcher.matches (which is implicitly "^...$") and Matcher.find/Matcher.replaceAll. Presumable, we'll be using Matcher.matches and therefore ^...$ is not necessary in any values being provided by the user: please just state that explicitly. 4. Please ensure that the documentation clearly reminds readers (in each attribute, rather than requiring the reader to go to a unified short blurb about regular expressions) that a "." is "anything" and not just a dot. Lots of (otherwise) smart people often write regular expressions for IP addresses like this: 10.10.1.1. Thanks! -chris signature.asc Description: OpenPGP digital signature
Re: Tomcat 7 & regex
Tim, On 12/25/2010 3:34 PM, Tim Funk wrote: > I am thinking from an admin point of view. While you can combine OR > conditionals in regex's - when you get something more complicated - you > may encounter a nasty nesting of () to get all the nested OR's correct. One can always use more, simpler | expressions rather than using a ton of () expressions to get the shortest regular expression. -chris signature.asc Description: OpenPGP digital signature
Re: Tomcat 7 & regex
On 27.12.2010 21:22, Christopher Schultz wrote: So the plan would be to have users convert values like this: 127\.0\.0\.1, 10\.10\.10\.1, 192\.168\.1\.[0-9]+ to this: (127\.0\.0\.1|10\.10\.10\.1|192\.168\.1\.[0-9]+) which is equivalent to 127\.0\.0\.1|10\.10\.10\.1|192\.168\.1\.[0-9]+ if we do not want to reference the resulting matches. One way to get rid of the dot escaping would be ^(127.0.0.1|10.10.10.1|192.168.1.[0-9]+)$ because the verbatim dots in the IP addresses can only match the any char dot in that expression. 3. Please make it clear, on a per-attribute basis if appropriate, whether the pattern will implicitly use start-of-input and end-of-input markers on the ends. I've been bitten several times by the operational differences between using Matcher.matches (which is implicitly "^...$") and Matcher.find/Matcher.replaceAll. Presumable, we'll be using Matcher.matches and therefore ^...$ is not necessary in any values being provided by the user: please just state that explicitly. +1 4. Please ensure that the documentation clearly reminds readers (in each attribute, rather than requiring the reader to go to a unified short blurb about regular expressions) that a "." is "anything" and not just a dot. Lots of (otherwise) smart people often write regular expressions for IP addresses like this: 10.10.1.1. ... which can be OK, see above. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48661] inconsistent error page behavior
https://issues.apache.org/bugzilla/show_bug.cgi?id=48661 William Leung changed: What|Removed |Added CC||l...@21cn.com -- 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
DO NOT REPLY [Bug 50523] New: Unsuccessfully Deployed WebApplication Has Not Removed From JMX Server When Undeployed
https://issues.apache.org/bugzilla/show_bug.cgi?id=50523 Summary: Unsuccessfully Deployed WebApplication Has Not Removed From JMX Server When Undeployed Product: Tomcat 7 Version: 7.0.5 Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: gurkanerdo...@yahoo.com Steps to create- 1- Deploy unvalid war file to webapps/ 2- Application has seen under JMX via Catalina:j2eeType=WebModule, 3- Delete application from webapps/ folder, application has undeployed 4- Application has still seen from JMX console. It must unregistered! -- 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
