We are working on using RESTEasy 4.5.8 with OpenLiberty and our tests that use an encoded @ApplicationPath value, such as "@ApplicationPath("apppathrest%21")", on an Application class are failing because the value is not being decoded and resolved properly. I have been able to run this test scenario successfully on Quarkus. I've turned on Quarkus logging but have not been able to isolate where the decoding is taking place. Hopefully somebody on this mailing list can direct me to where this decoding is triggered within RESTEasy or what I am potentially neglecting. Thanks _______________________________________________ resteasy-dev mailing list -- resteasy-dev(a)lists.jboss.org To unsubscribe send an email to resteasy-dev-leave(a)lists.jboss.org

Thanks Rebecca. In Open Liberty, we don't use Undertow, so would it be possible to encode the app URLs in RESTEasy directly? I've heard that a Java SE requirement is coming in the 3.1 level of the spec, so encoding in RESTEasy might make things easier for a future release of RESTEasy too. _______________________________________________ resteasy-dev mailing list -- resteasy-dev(a)lists.jboss.org To unsubscribe send an email to resteasy-dev-leave(a)lists.jboss.org