I am using Oracle r2dbc in my Spring Boot application.
I have a DatabaseClient set up and when I call:
databaseClient.sql("select ...").fetch().one().block();
The function never returns. It just hangs forever. Why is this?
This happens when using an incompatible version of com.oracle.database.r2dbc:oracle-r2dbc.
Use the 0.1.0 version of Oracle R2DBC if you are programming with
Spring. The later versions of Oracle R2DBC implement the 0.9.x
versions of the R2DBC SPI. Currently, Spring only supports drivers
that implement the 0.8.x versions of the SPI.
https://github.com/oracle/oracle-r2dbc
Be sure to use 0.1.0 and NOT 0.2.0. (Versions 0.3.0 and later will give obscure errors instead of hanging.)
After updating the dependencies in your build system, you may have to invalidate / clear your IDE's cache as well. For Intellij/Maven users, I think the "Reload all Maven projects" button might work too.
Related
According with the Spring Roo 1.3 Docs, MongoDB is supported, and can be configured with:
roo> mongo setup
But with Spring Roo 2.0.0.RC1 you get:
roo> mongo setup
Command 'mongo setup' not found (for assistance press TAB or type "hint" then hit ENTER)
Searching 'mongo setup' on installed repositories
0 matches found with 'mongo setup' on installed repositories
MongoDB persistence layer was removed? Can be added in some way?
In this task, during the Spring Roo 2.0 definition, we decided to create a smaller and easier to maintain Spring Roo distribution.
From 2.0, Roo will contain the runtime and the main addons only, so new versions could be released more frequently and being kept up to date with lastest Spring projects. This provide us the posibility of make a better separation between the Spring Roo runtime and the main addons. The Roo runtime APIs (classpath, metadata, support, etc.) must be kept as stable and backwards compatible as possible.
On the other hand, we moved the addons not classified as ”main addon” (GWT, JSF, Mongo DB ...) to their own Git repository
https://github.com/spring-projects/spring-roo-community-addons
These addons will be maintained by the Roo community.
From now on we will know this addons as “Spring Roo Community Addons”.
As you could see, these addons are not migrated to the Spring Roo 2.x version, so if you want to use the Mongo DB addon you should download from there and apply some updates. After apply changes, generate the .jar files and use the addon install commands to include them in the Spring Roo shell.
Hope it helps,
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).
I've recently inherited a project that's built on some older technologies, including iBATIS 2.x, and Struts 1.x. Both of those seem to be supported (though #Deprecated) in Spring 3.2.x, and not at all in Spring 4.x:
org.springframework.orm.ibatis, Object Relational Mapping (ORM) Data Access - iBATIS SQL Maps
org.springframework.web.struts, Integrating with other web frameworks - Apache Struts 1.x and 2.x
However, before I start the effort of migrating to Spring 3, I want to know how much longer I can expect to see it supported by the upstream developers. Would I have enough time to keep running Spring 3 while I migrate other parts of my application to newer tools, and then finally migrate over to Spring 4? Or should I focus on upgrading all of these other things before I can get onto Spring?
I hardly understand your problem. iBATIS 2.x and Struts 1.x are both no longer supported. They can work fine, as does Spring 2.x, but if a security problem is discovered, it will not be fixed.
If you contemplate migrating to Spring 3.x, you should also contemplate the migration to MyBatis and Struts 2.x (or Spring MVC ?) unless you have special requirements.
BTW, Spring 3.0 and 3.1 series are no longer supported either, and support for 3.2 should end when 4.2 will reach General Availability status, as Spring Framework generally offers support for current version, and the 2 previous (legacy) ones.
Spring 3.X will be end-of-life as of Dec 31 2016, but there will only be maintenance releases until that time (no feature development will happen).
I just work on project that uses Spring 4 with MyBatis. There is project MyBatis-Spring that integrates these two. Works like charm.
Don't know how to help with second bullet, cause we are using Spring MVC.
Seems that they've just posted a blog post that includes clarification on this topic:
Furthermore, please note that the 3.2.x line - and therefore the
entire 3.x generation - is approaching its end of life in 2015. We are
still committed to basic maintenance for critical issues; however,
don’t expect more than two or three further 3.2.x releases down the
road.
Source: Spring Framework 4.1.4 & 4.0.9 & 3.2.13 released
So, it seems that I'd have at least a few months of 3.x being supported to work on transitioning everything.
For my current project I'm required to use Struts 1.2.4. But I also wanted to utilize Spring 4.1.x.
To compensate for the missing Struts support since Spring 4, I copied the code from the spring-struts 3.2.13 package and created a Spring 4.1.5 compatible spring-struts-forwardport package.
Obviously this is not the most elegant solution, but maybe this can help you solve your problem.
I guess this package will also work with the next Spring 4.1 releases.
This may be annoying and discussed before but I could not find a good reference which would help to set a direction. I have to plan a migration of TopLink 10g (Spring 2.5 ORM Native Support) to JPA. I need some guidelines (steps) to follow and plan a successful migration.
Let me brief what I have in my technology stack. Primarily, as I mentioned above, application build around Spring 2.5 and Spring 2.5 Native ORM Support of TopLink. Spring 2.5 bundled to support only up to TopLink 10g and if you simply upgrade the TopLink JAR with the latest version it would not work as latest version of TopLink has completely changed the packaging but this still can be tackled by easily find and replace the package names. The main issue is the native api of TopLink ORM in Spring 2.5 which is built around TopLink 10g.
The reason of this migration activity is we cannot upgrade Spring until we migrate data-layer to JPA.
Please share steps if you already achieved something similar in your past or if the above briefing gives you an understanding on the problem you can also drop your opinion on how should I plan this migration.
I am facing a similar migration, toplink10g and Spring 2.5. For the integration we were using as support spring-toplink.jar, but not such support for toplink 12 that actually is the current version. At the moment seems it is not a straight fordward solution but I started first using the renaming tool provided by oracle.
The renaming tool it is necesary since jpa toplink 11 g is provided by eclipselink. You will see all the packages oracle.toplink.* will be renamed by org.eclipse.persistence.*
Did you have any advice othe advices for this migration?
We have been trying to implement a hibernate search with our project and in this case we had to implement Hibernate 3.5 previously we were using Hibernate Core 3.2.
Initially we tried to upgrade our version directly to the latest hibernate search and hibernate core. But, in Hibernate 4 they have removed the TransactionManagerLookupClass.
So, now what we can do in order to upgrade our Hibernate to Hibernate 3.5. As we can't upgrade our Application Server because we have other applications running on the same server.
Currently we are using:
hibernate-commons-annotations-4.0.1.Final.jar
hibernate-core-4.1.9.Final.jar
hibernate-jpa-2.0-api-1.0.1.Final.jar
hibernate-search-4.1.0.Final.jar
hibernate-search-analyzers-4.1.0.Final.jar
hibernate-search-engine-4.1.0.Final.jar
hibernate-search-orm-4.1.0.Final.jar
These are the files that we are using but, we know Hibernate 4 is not at all compatible with JBOSS 4.2.3. What we want to know that is there anyway to upgrade our hibernate core to a version where it's compatible with Hibernate search.
Secondly, the way be which we can keep the same application server.
You could use a very old version of Hibernate Search which is compatible with such a very old version of Hibernate ORM.
A better alternative would be to download a more recent version of the application server like WildFly 8 and start using that for the new applications: you can use the old JBoss 4.2 for the old applications and use a new container in parallel.
Remember that you can run multiple different application servers on the same server, you only have to make sure they use different ports.