we are planning to migrate our Tomcat from 8.5 to 10/11 version.
at the moment we are using Java 8, we are planning to use Java 17 .
I wanted to know if any one has previously migrated and what were the concerns regarding that.
I am aware that javax needs to be changed to jakarta series.
in our 8.5 tomcat we are using following maven dependencies
spring - 4.3.25.RELEASE
jackson
googleapi
graph
aws amazon jdk
javax servlet
mysql connector 5.1.44
log4j
slf4j
jsoup
unirest
httpcomponents
should we also need to update these dependencies to latest version? to be compatible with latest Tomcat 10
any other issues I need to be aware of ? I will post more on the same thread as I face issues while miggrating, appreciate the feedback and support from you guys. Thanks
Solution/ best way to migrating and also any tools that does it automatically? issues faced be individuals and how they resolved while migrating.
Related
I have a server I built a few years ago which provides both REST endpoints and websocket.
It packages as a jar file (as opposed to war) with an embedded Jetty server. Rest is provided by Jersey(2.26). Jersey and JEE Websocket are each ContextHandlers configured into Jetty. The server was built on Java 8.
I want to update the server. My main goals of the update is move to Java 17 and from JEE->Jakarta.
I just found Helidon and thought it to be the perfect solution, particularly since it even has an example of a server that combines REST and websocket.
As I started working with Helidon I found to my disappointment that helidon-webserver-jersey pulls in Jersey2.35 (JEE) not Jersey3.x (Jakarta).
I know that Jersey is doing parallel development in 2.x and 3.x, but I'm still surprised that something as new as Helidon connects to 2.x not 3.x.
I'm curious what the reasoning was behind that decision and if there are plans in the near future to move to Jersey3.x
I haven't started on the websocket piece yet, but I'm guessing its JEE not Jarkata as well. Is that true?
Jersey 3.x as well as the full "jakartification" of Helidon will come with version 3.x.
3.0.0-M1 is already available: https://medium.com/helidon/helidon-3-0-0-m1-release-7dad655cd469
The application is created using spring boot version 1.2.5 Release. I can see that it includes an embedded tomcat version which is 8.0.23. Is it possible to upgrade to a recent tomcat version, let's say, tomcat 9 with spring boot 1.2.5 and still run the application? Or do we need to upgrade the spring boot version to be compatible with tomcat 9? Is there any documentation for the spring boot version compatibility with Tomcat? Thank you.
Why do you want to upgrade it? What is the newer version of tomcat going to bring?
I personally go with the defaults for the spring version unless there is a specific need or issue.
That being said this question may have some pointers
How to change embedded tomcat's version in existing spring boot app?
You may be able to just set the property
9.0.5
It would be preferable to upgrade to the latest Spring Boot release (currently 2.2.5-RELEASE) to avail yourself of the latest features. There are many tutorials, migration guides, problem solutions, etc., out there to guide you, of which here are just a couple:
https://spring.io/blog/2018/03/12/upgrading-start-spring-io-to-spring-boot-2
Global CORS configuration breaks when migrating to Spring Boot 2.0.x
You didn't specify a reason for keeping your Spring Boot version at 1.2.5-RELEASE and only upgrading tomcat, but if you really must, there are other answers, such as here: How to change embedded tomcat's version in existing spring boot app?
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).
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)
I'd like to take advantage of some JDK7 features. What issues might I run into given that I use Apache Tomcat 7.0.x (latest) and Spring 3.1 (latest)?
There were a few compilation gotchas where JDK 6 could infer the generic type properly where JDK 7 could not. This was apparently a bug in JDK 6 as referenced here.
If you are using container-specific resources (e.g., data sources, etc.) be sure to verify these are still operating properly (though this will be immediately obvious on Spring startup if any of these are wired in).
If you are using Spring Security, and you upgrade, you do not need to make any changes per se to get get things running. However, you should take advantage of their less verbose configuration options (especially for REST URL's) that are available in Spring Security 3.1.
Other than that, our upgrade was seamless.
With the last Ubuntu update (11.10) I switched to JDK 7 (OpenJDK 1.7.0_147). I'm using Spring 3.0, Tomcat 6, and JRE 6 on the server (we have both VM and "physical" server installations). The code, compiled with JDK 7 runs on this configuration without any problems. I'm sure, switching to Spring 3.1 won't cause any changes. Not so sure about Tomcat 7, but hopefully this information will be useful to you.
You might run into a problem if you're using Java 7 features in a JSP. Tomcat by default user Java 1.6 for JSP compilation. See http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html#Production%20Configuration
To solve the problem you'll want to override the compilerSourceVM and compilerSourceVM init parameters in your application's web.xml file. More on that here: https://stackoverflow.com/a/20194823/1029261