I have a project with a dependency to org.springframework:spring-aspects which used to work fine with some Spring 4.x version. Now I've updated to some Spring 5.x version and the application refuses to start with org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'persistenceUnit' available
It turned out this could be resolved by excluding the newly added dependency to org.springframework:spring-orm. Is this the expected way to solve this problem?
We hit the same thing. It seems it's a bug that's already been fixed in Spring 5.2.4 (released on Feb 25th, 2020) - see Spring Framework issue #24491.
So it seems the right thing to do, until you can pick up this release, is to exclude spring-orm as you've done.
Related
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.
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 using the latest (by the time of writing) Spring-Boot-starter-data-jpa (version 1.2.6.RELEASE). I find it actually uses the Spring-data-jpa version 1.7.3.RELEASE, which is considerably behind the latest (1.9).
Is it a supported approach to upgrade individual dependencies such as the Spring-data-jpa? If I do this myself, for example, by declaring a direct dependency on the wanted newer version (may just override the version properties), any side effect you guys foresee?
The reason why I am doing this is that I need to use a special parameter in this annotation:#EnableJpaRepositories(repositoryBaseClass = JpaRepositoryWithI18n.class)
That is not available in the supplied 1.7.3 jpa library.
Any workaround would be appreciated too.
Thanks
EDIT:
I tested the following two ways: 1) declared a direct dependency to Spring-JPA-data 1.9.0 and excluded it from spring-boot-starter-data-jpa 2) upgrade Spring-boot-web-starter to 1.3.0m5
2) worked out well for me. This is also what dunni's answer suggested.
I have not tested Andi's answer as this is a new project, we could easily upgrade the entire spring boot and regression test it without worrying too much about side-effects.
But I can see Andi's answer is an easier approach than 1). More importantly, it shows how you can upgrade other dependencies independently -- just overide the versions in parent pom.
Thanks
Spring Data JPA 1.9 is part of the Spring Data Gosling release train. As described in the Gosling announcement you can use it with Spring Boot 1.2:
To upgrade to the new release train use the BOM we ship as described in our examples repository and configure its version to Gosling-RELEASE. If you’re using Spring Boot, upgrading to the release train is as easy as setting the Maven property spring-data-releasetrain.version to that version. Note, that to use Spring Data REST with Boot 1.2, you also need to upgrade to Spring HATEOAS 0.19.0.RELEASE (by setting the spring-hateoas.version property) and Jackson 2.5 or better (current 2.6.1 preferred, via the jackson.version property).
In short, add this to your pom:
<properties>
<spring-data-releasetrain.version>Gosling-RELEASE</spring-data-releasetrain.version>
</properties>
It's not supported in that matter, that the Spring Boot test cases don't include newer versions. So your application might work with the newer version, but there may be some errors. With minor releases it's more likely to work without problems than with major version upgrades. You can also upgrade Spring Boot to 1.3.0.M5 (you should note however, that this is a milestone version, not yet the release).
When using the spring plugin for struts 2, is it possible to use the latest version of spring or are you stuck with the version referenced in the plugin? For example in my project I am using struts 2.3.16.3 and its spring plugin automatically uses spring 3.0.5 . So if I add spring 4.1 to my pom as a dependency then there are multiple versions of spring added to the classpath.
You shouldn't have more than one Spring library in your classpath - disaster will be bound to happen. I guess you can either exclude the spring dependency in that plugin or set its version to the one you want.
The main problem with this approach is moving between major versions (3.x to 4.x) - if Spring is respecting Semantic Versioning incompatibilities will exist between the two versions and it is possible (or likely) that struts2-spring-plugin is using something that changed.
Edit: Comment below reports successful usage of struts2-spring-plugin and Spring4.
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)