I have a REST API that was working with Jersey 2.6 and Swagger 1.3.7. I read that Jersey 2.9 fixes a warning that I was getting so I upgraded to the latest Jersey 2.16 but then Swagger stopped working. I went back and upgraded one version at a time until I saw that Swagger was working with 2.15 so I settled on that. Now, the PUT API fails with Swagger with the following error:
The server refused this request because the request entity is in a format not supported by the requested resource for the requested method
The API works using FireFox RESTClient and specifying "application/json".
I do have "jersey-media-json-jackson" as a dependency and call "Client client = ClientBuilder.newClient().register(JacksonFeature.class);" in the program.
I tried upgrading Swagger but that did not help.
Has Swagger been verified to work with Jersey 2.15/2.16?
I've recently managed to get swagger-core to work with Jersey 2.16 with a similar issue. Keep in mind they are using the latest version (1.5.X) and not 1.3.X but the same solution will apply.
The problem is most likely with version resolution, specifically, the one of jackson-databind. For some reason, even jersey-media-json-jackson 2.16 depends on an older version of jackson-databind, even though it works fine with the latest version. Without having more details, it would be difficult to suggest a full solution, but you can follow the dependency tree and see the conflicts there.
If you do require further assistance, I'd suggest either using our mailing list, or even better, the IRC channel where we could interact online and resolve it.
Related
We have recently upgraded our API's (using Forms Authentication) Servicestack version 4.0.40 to latest stable version of Servicestack (V5.1.0). We use Autofac Ioc registration using InstancePerHttpRequest for API's (this is using Autofac.Integration.Mvc from Autofac.Mvc4 package).
Below code does not work anymore after servicestack upgrade.
this.UseAutofac(afcBuilder.Build());
Error CS0012 The type 'ServiceStackHost' is defined in an assembly
that is not referenced. You must add a reference to assembly
'ServiceStack, Version=4.0.48.0, Culture=neutral,
PublicKeyToken=null'.
So we have tried alternate ways to make it work using InstancePerDependency but that is causing missing "ASP.NET_SessionId" cookie value after API authentication.
Please suggest code to get actual "InstancePerHttpRequest" work with latest ServiceStack version.
I've already answered this question in ServiceStack Customer Forums but for anyone else's benefit with similar issues I'll include it below:
The issue isn't with ServiceStack or AutoFac it's with one of your dependencies which still has a binary reference to an old v4.0.48 of ServiceStack (highlighted in the Exception). You can't mix and match ServiceStack .dlls from different versions so you would need to re-compile whichever assembly has the old binary ServiceStack reference to use the version of ServiceStack you're using.
Autofac wouldn't have a dependency to ServiceStack, it would be one of your dependencies that is registered with Autofac. You can either use an Assembly inspector like JetBrains dotpeek and inspect the .dll references of each dll reference in your project or comment out registrations until you find the one with the dependency.
Basically you're unlikely to get anywhere focusing on ServiceStack or Autofac .dll's, you need to find the .dll that has a reference to ServiceStack v4.0.48 and re-compile it to use the version of ServiceStack you've upgraded to.
If you look at the dependency of Autofac.Mvc4, you'll see it only has a dependency to Autofac. Autofac's not going to have a dependency to ServiceStack v4.0.48, one of your own .dll's is going to have the old binary reference that's causing the issue.
Using the latest versions of signalR and #aspnet/signalr I still get issues connecting. I'm fairly sure the versions are exactly the same.
I've been following the startup project here. But instead I'm using an Angular 5 application. I get issues with CORS headers and more specifically the OPTIONS request returns a 405 method not allowed.
Visual studio version here.
Typescript/javascript client version here
I faced same issue and it appeared that order matters. Make sure you've put it like this:
app.UseCors(...builder...)
app.UseSignalR(...routes...)
app.UseMvc(...routes...)
I am using JBOSS AS 7.0.2 Final, and was trying to upgrade the version of RESTEASY that comes with 7.0.2 RESTEASY 2.2.1.GA to a newer version such as 2.3.4.Final. I followed the directions as indicated in patching provided by JBOSS, and when I did that, at application server startup it throws the error of being unable to parse the module.xml file.
I attempted the same procedure on 7.1.1 Final and it works fine.
First Question is, anyone know how to update RESTEASY in 7.0.2 (My other servers are all using this so I really like not to have to reset my other servers and replace with newer version of JBOSS)
I was hoping to upgrade RESTEASY, with hopes that this error may have been resolved in newer version
I have also tried by adjusting my POM to use version 2.3.4.Final and tried every scope, but it always would fail to use the newer jars and stick with JBOSS supplied jar.
15:14:09,947 SEVERE [org.jboss.resteasy.core.SynchronousDispatcher] (http--127.0.0.1-8443-6) Failed executing POST /countermeasure/customQueryLite: org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: java.util.ArrayList of media type
: application/xml
at org.jboss.resteasy.core.ServerResponse.writeTo(ServerResponse.java:216) [resteasy-jaxrs-2.2.1.GA.jar:]
It works fine for json, and text, and singular xml objects, but not list objects for xml.
Any answers in regards to these issues with resteasy and jboss would be helpful.
Must be the way Eclipse is set up. Anyone have any ideas?
Exception in thread "main" java.lang.NoSuchMethodError: com.sun.jersey.client.apache.DefaultApacheHttpMethodExecutor.headerValueToString(Ljava/lang/Object;)Ljava/lang/String;
at com.sun.jersey.client.apache.DefaultApacheHttpMethodExecutor.writeOutBoundHeaders(DefaultApacheHttpMethodExecutor.java:271)
It looks like DefaultApacheHttpMethodExecutor.headerValueToString was removed from the Jersey library after its 1.7 release:
http://java.net/projects/jersey/lists/commits/archive/2011-06/message/12
Here are some options:
Replace your current version of Jersey and with an older version of Jersey:
Use a newer version of the JIRA REST client. I don't know if any newer versions support the change to the Jersey API.
Actually, the "headerValueToString" method is supported in jersey-client-1.5.jar. Some later versions don't support the method yet, such as jersey-client-1.15.jar.
I use "jersey-apache-client-1.8.jar" downloaded from "http://download.java.net/maven/2/com/sun/jersey/contribs/jersey-apache-client/1.8/" and it works well
I am using Jersey 1.9 and it is generating my WADL perfectly except I need to redefine the resources base URI.
I'm running Jetty 7 sitting behind Apache using mod_proxy as a reverse proxy to route REST requests back to Jetty / Jersey. So Jersey generates the resources base URI as
http://localhost:8080/testRestAPI/rest/
when I need something like
http://mydomain.com/rest/
I found this from Google but it is not working: http://jersey.576304.n2.nabble.com/Changing-baseURI-when-generating-WADL-td6169703.html
unfortunately, you've found a bug in Jersey implementation. Please file a new issue as stated on mailing list - jira link: http://java.net/jira/browse/JERSEY
What you can do for now is downgrade to Jersey 1.8, which should not be affected by latest changes in this area. Thanks and sorry for inconvenience!
EDIT: issue link: http://java.net/jira/browse/JERSEY-773
it is already fixed, so you should be able to use this feature in Jersey 1.10-b02 and newer.