https://github.com/spring-projects/spring-framework/blob/d7778c0212d0e23b86fcd4585d749307c89c5bef/spring-web/src/main/java/org/springframework/web/util/pattern/PathPattern.java#L504

I'm working on a project (spring-rest-2-ts) that converts spring controllers to ES (TS) however at the following line: https://github.com/blue-veery-gmbh/spring-rest-2-ts/blob/86b75e9265454049c3162bfba6792607a02491c4/spring-rest2ts-spring/src/main/java/com/blueveery/springrest2ts/implgens/BaseImplementationGenerator.java#L93 the project needs to use a PathPattern by a PathPatternParser (otherwise it will not support {id:regex} type patterns, which is where my implementation is failing) however it doesn't look like PathPattern exposes this information once parsed.

It would be very helpful to get access to the head element of a parsed PathPattern so that such implementations can be made that support future features.

Comment From: bclozel

PathElement and all its implementations are package private, because those are implementation details for the path matching contract. I don't think we should expose those.

Comment From: ememisya

PathElement and all its implementations are package private, because those are implementation details for the path matching contract. I don't think we should expose those.

Do you have an alternative way to solve the scenario mentioned without code duplication?

Comment From: bclozel

@ememisya I don't understand the use case actually. You'd like to parse the patterns to rewrite them in another format?

Comment From: ememisya

The use case is converting controllers annotated by @RequestMapping to ECMAScript however in that pursuit the following issue arises:

The path pattern being more complex than simply something like /context/{pathVariable} as shown below leaves one with an undesirable option while implementing the use case.

  @RequestMapping(value = "/context/{id:^[0-9]{1,19}$}", method = RequestMethod.PATCH,
          produces = MediaType.APPLICATION_JSON_VALUE)

The syntax and logic to parse the annotation appears to be in PathPatternParser's parse method, however the developer gets no output from it other than whether or not it succeeded.

The only sensible approach then is to create a parser of your own. That being said it is much more preferable if there existed a way to access the parse results for future considerations and code maintenance.

Comment From: bclozel

I see. The syntax itself has been stable since its introduction in Spring Framework 5.0. We cannot (and won't) change the syntax without breaking millions of applications. Besides the regexp variant, the syntax is more predictable than our previous AntPathMatcher variant which allowed ** in the middle of patterns and forced backtracking.

With this in mind, I think the tradeoff is clearly in favor of not opening those classes to the world as we want to be free to rewrite and improve the internal implementation in case we find performance opportunities. I'm sorry this makes things more difficult for you, but we have to balance this with maintenance work.

I'm declining this issue as a result.

Comment From: ememisya

While I understand your considerations the issue still remains. Surely most people will resort to illegal access and simply set getHeadSection accessible. It's a little absurd (and only given Spring Framework's sheer size and popularity) to introduce a syntax which likely exists as an annotation upon millions of projects and provide no tools to anybody else to actually parse it for any sort of introspection. There is a simple solution to this that does not require illegal access or code duplication nor cause compatibility issues and that is as stated.