RESTEASY003210: Could not find resource for full path
by Edoardo Panfili
Hi,
I am switching from (tomcat8+java8+resteasy3.6) to (tomcat9+java11+resteasy4)
All seem works fine except the home page of my application.
If I point the browser to "http://localhost:8080/myApp/" this is the answer:
"RESTEASY003210: Could not find resource for full path: http://localhost:8080/myApp/"
Don't know why resteasy is responding outside the application path, can someone help me?
this is my configuration:
---------------------------------
import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;
@ApplicationPath("/ws")
public class WebServices extends Application {
}
---------------------------------
In my pom.xml file I am using this dependencies:
org.jboss.resteasy:resteasy-jaxrs-all:4.0.0.Final
org.jboss.resteasy:resteasy-jackson2-provider:4.0.0.Final
org.jboss.resteasy:resteasy-servlet-initializer:4.0.0.Final
thank you
Edoardo
1 month, 4 weeks
jakarta.ws.rs vs javax.ws.rs
by Benno Fünfstück
Hello,
I see that resteasy uses the `javax.ws.rs` package. But the jakarta EE
jars provide `jakarta.ws.rs`. It seems that the two namespaces are not
compatible. What's the relation between them?
Best,
Benno
7 months, 3 weeks
resteasy XXE vulnerability
by Wang Veronica
Hi experts,
We use resteasy 3.0.6final, and XXE vulnerability was reported during penetration test.
Seems that 3.0.6final contains partial fix for XXE vulnerability, but need to set resteasy.document.expand.entity.references parameter to false explicitly. A more complete fix seems to have been done after 3.0.10.
We can upgrade to a more recent version, e.g. 3.1.2. Another option I am thinking is not to support XML Media type (we actually need to support json only). Is this a feasible approach to ultimately avoid XXE attack and any pointers to achieve this? (In our REST API code, we currently declare consume and produce annotations to support application/xml and application/json).
Is there a simple resteasy configuration to disable support of application/xml?
Thanks, Veronica
9 months
Integration with Spring Boot v1 and Prometheus
by Alexandre Briani Kieling
Hi,
What's the best way to instrument a REST API based on Spring Boot v1 and
RESTEasy?
I noticed that Micrometer doesn't integrate with RESTEasy, only Spring MVC
and Jersey.
Should I use the Prometheus Java client?
--
Alexandre KielingSr. Software EngineerRed Hat Fuse
9 months
Resteasy client defines servlet
by Leonid Rozenblyum
Hello.
Recently due to update of resteasy-client from 3.0.1.Final to 3.6.3.Final
we faced failures to process our spring mvc controller at '/' path.
After some debugging I found out the reason:
1) resteasy-client transitively depends on resteasy-jaxrs
2) resteasy-jaxrs (at least since 3.0.20.final)
(see commit
https://github.com/resteasy/Resteasy/commit/840cb666c8e89767e9c9821eb173b...
)
registers org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher
as a servlet with value = '')
Is it an expected behaviour that *client *dependency register a servlet?
Are there any ways to disable it?
Thanks for advice!
2 years, 9 months
Selecting MessageBodyWriter seems to ignore priority given a specific type match
by Steven Schlansker
Hi Resteasy users, [ apologies for the re-post, sent from wrong email the first time ]
I'm a happy user of Resteasy + Jackson for Json processing.
Recently, I had the misfortune of attempting to serialize a basic String:
client.post(Entity.json("Test"));
if you call Jackson directly, it does the right thing:
mapper.writeValueAsString("Test") => "\"Test\""
However, much to my surprise, when sending it via JAX-RS client, it is written as a bare word without quotes -- and is rejected server-side.
After some debugging, I realized that both StringTextStar and JacksonJsonProvider were ending up with Priorities.USER and being seen as equivalent.
No good! So I changed my registration:
context.register(new JacksonJsonProvider(myMapper), Integer.MAX_VALUE);
I then proceeded to triumphantly ... observe the same test failure as before!
Dug quite a bit further in, and it seems that the selection process in MediaTypeMap$TypedEntryComparator
has the unfortunate property that it will select (via compareTypes) a *less priority* MessageBodyWriter if the type is a tighter bound on the Entity.
So in my case, I get
StringTextStar -> String.class@5000
JacksonJsonProvider -> Object.class(a)Integer.MAX_VALUE
and the TypedEntryComparator selects StringTextStar since String is-assignable to Object, despite my attempt at an ultimate priority registration.
How do I fix this? Preferably without removing StringTextStar entirely, as I'm sure that will break something else (reading error messages perhaps).
Thanks for any advice,
Steven
2 years, 9 months
Microprofile client @RegisterProvider on a sub-resource
by Milan Konzal
I would like to register different Providers on different sub-resources but when I try it, it is not working (I get an exception regarding missing provider when the method on the sub-resource was called).
Is it expected? I can't find any information in the MP specification nor Resteasy documentation.
My resource proxy
@Path("/foo")
@RegisterProvider(XYZWriter.class)
@RegisterProvider(XYZReader.class)
public interface Foo {
@POST
@Consumes("xyz")
@Produces("xyz")
FooResponse get(FooContent content);
@Path("/bar")
Bar getBar();
}
My sub resource proxy
@RegisterProvider(ABCReader.class)
public interface Bar {
@POST
@Produces("abc")
BarResponse get();
}
My call
foo.getBar().get();
Only registrations on the resource proxy are done.
I'm using Resteasy 4.5.8 implementation of MP rest client.
5 years, 7 months
UrlInfo behind a proxy?
by Benno Fünfstück
Hello,
when running resteasy behind a reverse proxy, is there any way to
override the detected base UrlInfo? Because the address the application
is listening in this case won't match the actual public address.
Regards,
Benno
5 years, 8 months
Migration difficulties from WF10/3.0.14 to WF21/3.13.1
by Christian Beikov
Hi,
I'm in the process of doing a migration but I am having some problems
and I'm not sure how to approach this.
I debugged quite far into the Resteasy JAX-RS integration and also
looked at past commits to ServerResponseWriter which is AFAICS the
source of the problem. I identified the following two commits related to
https://issues.redhat.com/browse/RESTEASY-1227 which might be the reason
for my issue:
*
https://github.com/resteasy/Resteasy/commit/992f605197c52030e88a21145e6ec...
*
https://github.com/resteasy/Resteasy/commit/fb33d3c1bac91bdb1d686008bb679...
The problem I have, is that when a HEAD request is made, which doesn't
have an Accept header, Resteasy can't figure out how to encode the
result object from my resource method. Previously, Resteasy tried to
find a MessageBodyWriter, which it now does not anymore, as it instead
throws a NotAcceptableException. As per the comment in the code, this
seems to be due to JAX-RS 2.0 section 3.8.6.
It seems that the MessageBodyWriter resolving only occurs when there is
an Accept header, which is ok if section 3.8.4 were properly respected.
It states that "If A = {}, set A {'*/*'}", which AFAICS is exactly what
is missing here. If '*/*' were added to A(note that "chosen" is set to
that value in the code), the MessageBodyWriter resolving would AFAIK
work correctly again for my case.
Is this a regression or did I misread the specification?
Regards,
Christian
5 years, 8 months
