When upgrading my Spring Boot 2.5 to 3.0 , I am facing some issues with Wiremock, probably due to the move to jakarta namespace. Even upgrading to latest wiremock-jre8 , ie 2.35.0 (as of december 2022) doesn't seem to help. I get this error :
java.lang.NoClassDefFoundError: javax/servlet/DispatcherType
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)
at com.github.tomakehurst.wiremock.jetty9.JettyHttpServerFactory.getServerConstructor(JettyHttpServerFactory.java:37)
at com.github.tomakehurst.wiremock.jetty9.JettyHttpServerFactory.<clinit>(JettyHttpServerFactory.java:30)
Looks like this is a know issue related to jakarta namespace and Jetty 11 support, that will take a while to get properly fixed :
https://github.com/wiremock/wiremock/issues/1760
As indicated in the issue, using wiremock-jre8-standalone instead of wiremock-jre8 helps working around the issue, until it gets properly fixed in Wiremock 3.x
E.g. Wiremock version 1.58 works (if you don't mind using an older version) in combination with Spring Boot 3
Related
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.
I have a Java 11 application that works perfectly fine with Spring Boot v2.2.6.RELEASE, but it breaks when I upgrade to v2.2.7.RELEASE. The problem is that I get a java.lang.NullPointerException when reading the nested object:
jaxbUnmarshaller.unmarshal(new StringSource(xml)).getChild().foo();
I checked the SB release notes and this seems to be the breaking change: https://github.com/spring-projects/spring-boot/issues/21195
As migrating from Glassfish Jaxb 2.3.2 to 2.3.3 is a patch change, I would expect that this upgrade should require no changes from my side. I tried to check for some migration guide but found nothing at jaxb-ri page. Any idea would be welcome.
This sounds like a bug in the JAXB reference implementation. If you haven't already done so, I would search the RI's open issues for an existing report of your problem. If you don't find anything, I would then open an issue that describes your problem and includes a minimal sample that works with 2.3.2 and fails with 2.3.3.
I'm developing a Java Web Application with Spring 5 (not Spring Boot) and I'm facing a problem with the library spring-ladp-core (2.3.2.RELEASE).
I get this error:
java.lang.NoSuchMethodError: org.springframework.util.ReflectionUtils.accessibleConstructor(Ljava/lang/Class;[Ljava/lang/Class;)Ljava/lang/reflect/Constructor;
at org.springframework.web.SpringServletContainerInitializer.onStartup(SpringServletContainerInitializer.java:155)
and I can't understand exactly what's the problem, maybe a dependencies version problem but I don't know how to solve it. I mean the spring-ldap-core is no more updated since 2017 so is it outdated? Is supposed no longer be used?
I need to build an authentication mechanism with Spring security and LDAP, is the spring-security-ldap library the correct way to implement this?
I have an "old" project with Spring 4 and spring-ldap-core and it works fine, is spring-ldap-core no more compatibile with recent versions of Spring (Spring > 4)?
Thanks.
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)
We have an application that is currently running spring 2.5.6 and mule 2.2.1. We have decided to go ahead and upgrade the app to use spring 3.2 we also upgraded spring security to 3.1. I understand that Mule 2.2.1 uses spring 2.5.6 for configuration and so forth. We were to re-factor our code and build the entire project. However after deploying the application and starting the server, my server started in about 6 seconds instead of the normal 30 seconds and then I noticed that none of my services were not loaded. Unfortunately after days of investigating I cannot find where everything fails, as there are no errors in any of the logs including spring and mule logs. My question is it possible to get these to play together or should I just forget about getting this to work.
I read this post http://lifeinide.blogspot.com/2012/07/spring-3-and-mule-2-initialized-by.html and followed these instruction and still was not able to get it work. Mule says it started up just fine without any errors but I can hit any of my services. Any help? Thanks
Thanks #genjosanzo for the pointer. It helped met dig into this issue better and eventually make it work.
#mtanzania,
We had a similar need like yours - need to make Mule 2.2.1 work with Spring 3.2.x releases. Upgrade to Mule 3 involved rewrite of Mule extensions such as exception handling strategies, a RabbitMQ Mule transport etc. Upgrade to Mule 3 was therefore ruled out.
In order to make this work, you need to rewrite/update 3 java files from your module:
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:2.2.1
with implementations from :
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:3.4.0
To be more specific, you need these classes to be updated/upgraded: MuleBeanDefinitionDocumentReader.java, MuleApplicationContext.java and SpringXmlConfigurationBuilder.java
With these updated versions, you can continue to create the MuleContext like:
SpringXmlConfigurationBuilder springConfigBuilder = new SpringXmlConfigurationBuilder(muleConfigPaths);
MuleContext context = new DefaultMuleContextFactory().createMuleContext(springConfigBuilder)
The modified implementations are here : Mule in Trooper and sample class that uses this is here : Trooper Mule container
Mule uses some internal spring API to parse the mule configuration and creates the correspondent beans.
For this reason the upgrade might work with spring 3.0.x but I'm pretty sure that something got broken with spring 3.1.x (i.e. this code has been introduced to maintain backward compatibility).
How about upgrading mule as well? Most of the 2.2.x syntax is still supported and many new feature has been introduced in newer mule versions.
FWIW, the above answer from #regunathb is right on. Patching in those three classes works. However, it is important to note that the 3.4 version of those classes from mule-module-spring-config will not work as-is. You must get the modified versions of the classes that #regunathb posted on GitHub, otherwise you'll end up with various incompatibilities between 3.4 and 2.2.1.