Closed petejohanson closed 8 years ago
The reason this bombs in Expression#buildMatchingPattern() is because it attempts to use the variable name as the name of the named capture group, and "_" is not a valid character for a named capture group, so it throws.
By relying on lazy initialization in Expression#getMatchPattern(), we avoid hitting that problem for the simple builder case.
Thanks @petejohanson! Although, I'm curious as to why this hasn't come up when the tests are run. The uritemplatetest suite has names with underscores in it already and those are passing. I'm going to dig deeper before I accept.
Does the test suite use the builder at all? Or just parsing of existing Templates then processing? On Nov 12, 2015 6:47 PM, "Ryan J. McDonough" notifications@github.com wrote:Thanks @petejohanson! Although, I'm curious as to why this hasn't come up when the tests are run. The uritemplatetest suite has names with underscores in it already and those are passing. I'm going to dig deeper before I accept.
—Reply to this email directly or view it on GitHub.
https://github.com/damnhandy/Handy-URI-Templates/blob/master/src/test/java/com/damnhandy/uri/template/conformance/AbstractUriTemplateConformanceTest.java doesn't seem to use the builder at all, just parsing from existing template. Different code path?
I missed that part about it being related to the URI Template Builder. The conformance tests just focus on the template expansion. You fixe is a completely different code path. Accepting the PR. Thanks!
Any idea when you'll be doing the next release that includes this fix? Gauging whether I need to switch to -SNAPSHOT temporarily or not.
Thanks.
Just did :)
https://github.com/damnhandy/Handy-URI-Templates/releases/tag/handy-uri-templates-2.1.1
Should be bubbling up to Maven Central now.
Perfect, thanks for the quick turn around!