I am trying to update the okhttp (Com.squareup.okhttp) 2.7.5 to okhttp3 (Com.squareup.okhttp3) 4.10.0
The implementation docs are not available online when searched for it.
Its EOL (end of life) for 2.7.5, while upgrading it iam facing lot of implementation errors w.r t the client generation and interceptors.
Can someone help with the implementation docs or links to solve my above problem?
Implementation for 4.10.0 is not available and the dependency from maven repo brings the kotlin files instead of JAVA classes
Here’s the okhttp 3 upgrade docs, which walk through API changes from 2.x through the current release.
https://square.github.io/okhttp/changelogs/changelog_3x/#version-300-rc1
Related
We are trying upgrade SPringFox2.0 to 3.0 Open API Specification. But when we generate open doc using '' url it is showing version as 2.0. Not sure why the version still pointing to old version.
We are using Springboot application
I followed the below steps to upgrade as per spring fox documentation
[http://springfox.github.io/springfox/docs/current/][1]
"2.1.3. Migrating from existing 2.x version"
Spring Boot Applications
1.Remove library inclusions of earlier releases. Specifically remove springfox-swagger2 and springfox-swagger-ui inclusions.
2.Remove the #EnableSwagger2 annotations
3.Add the springfox-boot-starter
4.Springfox 3.x removes dependencies on guava and other 3rd party libraries (not zero dep yet! depends on spring plugin and open api libraries for annotations and models) so if you used guava predicates/functions those will need to transition to java 8 function interfaces
I followed all the steps above, 'http://localhost:XXXX/api/v1/api-docs?group=API_Version_1' it got generated but version is showing 2.0
{"swagger":"2.0","info":{ ........
And also I modified in SwaggerConfig: DocumentationType.SWAGGER_2 TO DocumentationType.OAS_30 (it is not mentioned documentation, I guess they missed it)
I believe still some thing is missing, Spring Fox documentation is still out of date and poor coverage of 3.0 aspects.
I am wondering any one having same problem?
Try to use /v3/api-docs or /api/v3/api-docs in your case.
That did not work.
As per Spring fox documentation:
"The /v2/api-docs URL is the default that SpringFox uses for documentation. The v2 does not refer to your API's documentation version (which can be changed in the Docket configuration), but the version of the Swagger specification being used..."
springfox.documentation.swagger.v2.path=/my/docs (path of yours)
I have a RESTful web service application in java deployed on google app-engine which uses jersey 1.18.6.
I want to use postmark java client to send transactional emails from it.
When I integrated it, i was seeing the following exception:
javax.ws.rs.core.Response$Status$Family.familyOf(I)Ljavax/ws/rs/core/Response$Status$Family
From what I could find, I think this error was because of there were two different (and probably incompatible) version of jersey being used ,1.18.6 for jersey-server, jersey-guice and jersey-bundle and 2.25.1 for jersey-client (by postmark).
Then I tried to make the jersey version 1.18,6 throughout, so in the my main project pom, while including the dependency for postmark, I excluded the jersey-client (by added exclusions header) and separately added jersey-client dependency in my main project .
But then I got the following error:
java.lang.NoClassDefFoundError: javax/ws/rs/core/MultivaluedHashMap
This is I think the class MultivaluedHashMap is present only in jax-rs 2.x versions (which is compatible with jersey 2.x versions)
So my questions are:
Is there a version of postmark java client library which uses jersey 1.x instead of jersey 2.x?
If no then what options do I have other than migrating my main project from jersey 1.x to jersey 2.x. I don't want to do that since we will have to migrate not just the jersey dependencies but I think some other things like guice, shiro etc. which would be time consuming. Also it doesn't really seem optimal to modify multiple existing dependencies just to include one additional module.
There isn't. The very first commit of the project's pom.xml already used Jersey 2.25.1
as Mureinik mentioned above, when we worked on the library, our plan at Postmark was to use newer library versions, since they are better options in long run.
On our Github page Rupert made good suggestions, from which I find separate ClassLoader a good choice. I will play a bit with the library code in next couple of days on compatibility, however we are always in favour of using newer libraries for our codebase.
please check out my latest comment on Github issues page for possible solution for using older Jersey version https://github.com/wildbit/postmark-java/issues/11
It should be pretty easy to port the library to Jersey 1.x by porting only the HttpClient class on your side.
Is there any Spring 5.0.6.RELEASE osgified version patch available? We have to to do quick release so need to upgrade older spring but currently our framework uses OSGI based container, though spring has officially stopped supported OSGI. Is it possible to have patched version of latest Spring framework?
Though I know it's better to convert to Spring based container but since time doesn't allow I'm in search of any osgified version of Spring jars.
Apache Servicemix produces osgified versions of a lot of well known libraries, Spring included: https://github.com/apache/servicemix-bundles
Currently the latest osgfied version of Spring is "5.0.5.RELEASE", with "5.0.6.RELEASE" probably due to come in the near future. Otherwise, getting servicemix pom.xml for 5.0.5.RELEASE and manually changing Spring version should work (from 5.0.5 to 5.0.6 there should be just internal implementation changes).
I am currently using grails 3.1.
Kindly share the details of any monitoring plugin like grails-melody which is used in grails 2.*.
To my knowledge, grails-melody plugin is not applicable in grails 3+ version.
Any help is appreciated.
JavaMelody plugin works fabulously with Grails 3.1.
The source documentation is the most current, here:
https://github.com/javamelody/grails-melody-plugin
Just include this in your build.gradle:
dependencies {
runtime 'org.grails.plugins:grails-melody-plugin:1.60.1'
}
As of September 2016, the current version is 1.60.1.
Just build and run your project, then go to http://localhost:8080/monitoring to see your monitoring information. Replace the http://localhost:8080 bit as per your configuration, of course.
Since Grails 3 is build on Spring Boot, you get Actuator out of the box. See this article for more info.
According to you what are the risks of using Spring 4 with the jersey-spring3 integration module?
I have tried to use Spring 4.0 with the jersey spring example and the example still works but i'm unable to identify risks linked to this usage.
I have started using Jersey 2.7 and Spring 4.0.x recently in a project. I have setup a context hierarchy to inject beans, so far, I have discovered only one limitiation but that does not seem relate to Spring 4 but rather to the module itself or the HK2 Spring Bridge.
To give more insight about my use. I have a XJC/JAXB-backed which is consumed by a common service, repository and exposed through JAX-WS, and now hopefully through JAX-RS.
The multi-context stuff works now with #Autowiredwith 2.8-SNAPSHOT. I have applied my changes and the 2.8-SNAPSHOT to 2.7. Here is the diff.
Edit (Michael-O; 2014-10-17): Here is a modified Spring module based off 2.11 with multi-context support.
Not an answer to original question, just related information
This may be a little premature, but the new Major 3.0 version of Jersey will be using Spring 4, in the new jersey-spring4 module. The new Major version will be built with Java 8. Though a new Major version will be released, the 2.x line will still be actively developed to keep support for Java 7
I'll update this post once 3.0 has been release.
For anyone interested, you can see this mailing list to see what the Jersey team has to say about the new 3.x line.
Not sure if you came across any issues but I currently face one. It is described in other thread.
Simply, using jersey-spring3 2.12 and spring 4.1.0.RELEASE in one maven project leads to following class incompatibility:
2014-09-14 01:15:44.175:WARN:oejuc.AbstractLifeCycle:main: FAILED org.eclipse.jetty.server.handler.HandlerCollection#696
db620[org.eclipse.jetty.server.handler.ContextHandlerCollection#27abb6ca[o.e.j.m.p.JettyWebAppContext#737d100a{/,file:/C
:/Users/Josef/Workspace/TransitCenter/src/main/webapp/,STARTING}{file:/C:/Users/Josef/Workspace/TransitCenter/src/main/w
ebapp/}], org.eclipse.jetty.server.handler.DefaultHandler#6968c1d6, org.eclipse.jetty.server.handler.RequestLogHandler#7
d986d83]: java.lang.NoSuchMethodError: org.springframework.beans.factory.support.DefaultListableBeanFactory.getDependenc
yComparator()Ljava/util/Comparator;
java.lang.NoSuchMethodError: org.springframework.beans.factory.support.DefaultListableBeanFactory.getDependencyComparato
r()Ljava/util/Comparator;
at org.springframework.context.annotation.AnnotationConfigUtils.registerAnnotationConfigProcessors(AnnotationCon
figUtils.java:136)