Is RESTEASY-2845 correctly implemented?

[ilx]

Hi, I just noticed that our client stopped to work like it used to after we upgraded to 5.0.5 and I have detected that it might be related to RESTEASY-2845.

In past versions the following interface worked just fine with ids that contain / (i.e. something like Applications/Folder123/Config432 was valid id):

@Path("something")
@Consumes(Array(MediaType.APPLICATION_JSON))
@Produces(Array(MediaType.APPLICATION_JSON))
trait Resource { 

@POST
@Path("{id:.+}/commands/{commandId:.+}/confirm")
def confirmCommand(@PathParam("id") id: String, @PathParam("commandId") commandId: String): Response
}

but after the upgrade to 5.0.5 id is always encoded and we get client error.

I noticed that it's because of:

      if (pathParamsMap.size() > 1) {
         target = target.resolveTemplates(pathParamsMap);
      }

If encoding of path param has to be implemented I guess this invocation would be fine, but why only if pathParamsMap size is > 1? We can have more than 1 pathParam. That does not feel correct.

A workaround to get same behaviour is to remove 2nd PathParam, but that simply feels wrong...

[jamezp]

This definitely looks like a bug to me. I've filed https://issues.redhat.com/browse/RESTEASY-3291 to track it. I made it critical since it breaks backwards compatibility.

[jamezp]

Just as a follow up, we've decided to revert the commit that created this issue. It's going to take more thought in how we handle that and reverting seems like the best solution for now.

[ilx]

Cool, thank you for taking a look into it.
I noticed that there might be a potential NPE with new/reverted code if processors can be null, please take a look.

[jamezp]

Yes, there is potential there. We haven't hit it yet so I'm guessing it hasn't been an issue before. I do recall asking that to be fixed when the original bug fix was introduced. It's something we can look at before we do a new release probably.