Como forçar o URIBuilder.path (…) a codificar parâmetros como "% AD"? Esse método nem sempre codifica parâmetros com porcentagem, corretamente

Como forçarURIBuilder.path(...) para codificar parâmetros como"%AD"?

Os métodospath, replacePath esegment doURIBuilder nem sempre codificam os parâmetros com porcentagem, corretamente.

Quando um parâmetro contém o caractere "%" seguido de dois caracteres que juntos formam um caractere codificado em URL, o "%" não é codificado como "% 25".

Por exemplo

URI uri = UriBuilder.fromUri("https://dummy.com").queryParam("param", "%AD");
String test = uri.build().toString();

"teste" é "https://dummy.com?param=%AD"
Mas deveria ser "https://dummy.com?param=%25AD"(com o caractere"% "codificado como"% 25 ")

O métodoUriBuilderImpl.queryParam(...) se comporta assim quando os dois caracteres após o "%" são hexadecimais. Ou seja, o método "com.sun.jersey.api.uri.UriComponent.isHexCharacter (char)" retorna verdadeiro para os caracteres após o "%".

Eu acho que o comportamento do UriBuilderImpl está correto, porque acho que ele tenta não codificar parâmetros que já estão codificados. Mas, no meu cenário, nunca tentarei criar URLs com parâmetros já codificados.

O que devo fazer?

Meu aplicativo Web usa Jersey e, em muitos lugares, construo URIs usando a classe UriBuilder ou invoco o métodogetBaseUriBuilder doUriInfo objetos.

Eu posso substituir "%" por "% 25", toda vez que invoco os métodosqueryParam, replaceQueryParam ousegment. Mas estou procurando uma solução menos complicada.

Como posso fazer o Jersey retornar minha própria implementação do UriBuilder?

Pensei em criar uma classe que estende o UriBuilderImpl que substitui esses métodos e que executa essa substituição antes de chamarsuper.queryParam(...) como queiras.

Existe alguma maneira de fazer Jersey retornar meu próprio UriBuilder em vez de UriBuilderImpl, ao chamarUriBuilder.fromURL(...), UriInfo.getBaseUriBuilder (...), etc?

Olhando para o métodoRuntimeDelegate, Pensei em estenderRuntimeDelegateImpl. Minha implementação substituiria o métodocreateUriBuilder(...), que retornaria meu próprioUriBuilder, ao invés deUriBuilderImpl. Então, eu adicionaria o arquivoMETA-INF/services/javax.ws.rs.ext.RuntimeDelegate e nele, o nome completo da classe do meuRuntimeDelegateImpl.

O problema é que o jersey-bundle.jar já contém umMETA-INF/services/javax.ws.rs.ext.RuntimeDelegate que aponta paracom.sun.jersey.server.impl.provider.RuntimeDelegateImpl, então o contêiner carrega esse arquivo em vez do meujavax.ws.rs.ext.RuntimeDelegate. Portanto, ele não carrega meuRuntimeDelegateimplementação.

É possível fornecer minha própria implementação deRuntimeDelegate?

Devo adotar uma abordagem diferente?

questionAnswers(3)

yourAnswerToTheQuestion