diff options
author | Dave Borowitz <dborowitz@google.com> | 2012-06-07 12:08:48 -0700 |
---|---|---|
committer | Dave Borowitz <dborowitz@google.com> | 2012-06-08 12:16:31 -0700 |
commit | 61c4e39067777633ea5d6d02f7493b4c459aef20 (patch) | |
tree | bb2f58d2eb8b5f8f1e55485ca091b34f55ad6d5b /org.eclipse.jgit.packaging | |
parent | 7016504ecc1c7eeda721ff1c34f4af0684cd9c2e (diff) | |
download | jgit-61c4e39067777633ea5d6d02f7493b4c459aef20.tar.gz jgit-61c4e39067777633ea5d6d02f7493b4c459aef20.zip |
Expand RegexPipeline documentation
Include some behaviors that were not clear to me until I had used it a
few times.
Warn about broken behavior for capture groups that do not match. It
would be nice to support these, but even for the cases where it's
clear what the behavior should be, it would be infeasible to
implement.
For example, consider the second group of the regex "(/a)/b(/c)?"
matched against the path "/a/b". We might want getServletPath() to
return "/a/b" and getPathInfo() to return null, but this is hard to
implement: there's no easy way to say "the substring up to the point
where (/c) would have matched if it were in the string even though
it's not." And even if we could, it's not clear there is even a right
answer in the general case.
Moreover, ideally we could warn about such broken patterns at servlet
initialization time, rather than at runtime, but even answering the
question of whether there are capture groups that might not match
requires more customized regular expression parsing than we want to
embark on. Hence, the best we can do is document how it fails.
Change-Id: I7bd5011f5bd387f9345a0e79b22a4d7ed918a190
Diffstat (limited to 'org.eclipse.jgit.packaging')
0 files changed, 0 insertions, 0 deletions