Migrate from Spring 2.5 Native ORM TopLink 10g to JPA - spring

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?

Related

Oracle R2DBC query hangs / never completes

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.

Spring Roo with Java 8

Does SpringRoo generate code for Java 8 features: Streams, Lambda, Parallel Processing? If so, please point to example links.
The SpringRoo release notes mention that it supports Java 8, but has no more details.
Some time ago I was evaluating Spring Roo. There is the 1.x branch which afaik does not have any special support for Java 8 since it was released years ago, and it is a feature of the upcoming 2.x version to support Spring 4 according to a blog entry from early 2015. But there is still no final version available, so possibly this is not a high-priority project.
You might also have a look at Spring Boot. With Spring Boot you can create JPA entities, CRUD repositories and REST interfaces with very little boilerplate code. In my opinion, this reduces the need for a tool such as Spring Roo.

How long will Spring 3.x continue to be supported?

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.

Issue with Upgrade to Hibernate 3.5 in JBoss 4.2.3

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.

Stable Spring version release

Right now I am trying to research on how stable Spring release are right now. I'm having problems determining whether the most current Spring release (3.1.1) is the best choice for a base architecture. Are there any differences between 3.0 and 3.1? If so are there any impact in terms of coding structure just like migrating from spring 2.0 to 3.0. Currently we have a base architecture for Spring 2.0 and we are thinking of migrating to 3.X for integrated AJAX support and integrated REST support as well. Are there any other perks in migrating to 3.X? Is it good idea to migrate to Spring 3.0? If yes are there any drawbacks in migrating also which version is the best to migrate to? Thanks for taking time in reading this, have a nice day.
Are there any differences between 3.0 and 3.1?
http://static.springsource.org/spring/docs/3.1.x/changelog.txt
EDIT:
ok, it that's too technical, try this:
http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/new-in-3.1.html
EDIT 2:
no, you do not have to use annotations. That's just a convenience feature mostly.
EDIT 3:
in Implementing Controllers all annotation based configurations have their XML-schema based counterparts. That said, unless you have very good reasons against annotations, you might try to gradually switch to this paradigm, as it is easier to read thus easier to maintain. (at least in in my opinion)
I've migrated some projects from spring 2.5.6 to spring-3.1 without any major problems. I can't speak to spring-3.1.1, but if its a non-milestone release I would be comfortable upgrading myself.
Here's a link to spring-3.1 features: http://static.springsource.org/spring/docs/3.1.0.M2/spring-framework-reference/html/new-in-3.1.html
If you're moving up from 2.x to 3.x I don't see any reason why you would NOT upgrade to 3.1, even if you don't see immediate use for 3.1 features.
Yes, there are some minor differences between Spring 3.0 and 3.1, some of them are well documented through the book Pro Spring 3, basically the JPA support has been improved with helper features like the spring-data project, the support of some standard compliant Java EE annotations and the possibility to create beans "profiles" inside your xml configuration that can be handy when used alongside with maven, among others features.
Migrating from 2.0 to 3.x shouldn't be problematic if you stick to the old xml based configuration

Resources