Our project used to depend on spring 3.x.x and 4.x.x, while it has to upgrade to 5.3.18 due to the vulnerabilities security department require to handle.
we strong depend on gemfire 8.2.5 and it cannot upgrade due to many many reasons. we use gemfire with spring-data-gemfire 1.3.4 which depends on spring 3.x.x (4.x.x is also compatible).
When we upgrade to spring 5.x.x, the compatible problems occur such as most important usage about BeanFactoryLocator, it has been removed in the spring 5.x.x. Maybe there are other compatible problems as well.
So want to ask if there is anyway to remain spring 5.x.x and spring-data-gemfire 1.3.4 unchange and also solve the incompatible problems. Such as some bridge dependency to confirm spring smooth transition?
In short... NO.
There is no simple way to reconcile the differences between Spring Data GemFire 1.3.4 (which has long been out of Spring OSS support, BTW), that was based on Spring Framework 3.2.x (specifically, 3.2.8.RELEASE) and the now current version of Spring Framework 5.x.
This is a significant and major version gap across 2 generations no less, and many things have changed in-between and since then.
Spring Framework 3.x and 4.x have also long been out of OSS as well as commercial support.
The specific problem you are mentioning involving the Spring Framework's BeanFactoryLocator was addressed in SGF-587 over 5 years ago. Spring (Data) major.minor versions are only supported for ~1.5 years. An entire major generation even is only supported for roughly 3-4 years.
Related
I know that Spring Cloud at some version (3.0?) dropped direct support for some Netflix libraries like Ribbon or Hystrix. Now I'm trying to make a smooth migration of around 20 microservices running on production having some custom code extending Ribbon (and Hystrix to a lesser degree). The main goal is to upgrade from Spring Boot 2.3 to 2.6. As a consequence I need to upgrade Spring Cloud to 3.1.x, right?
My guess was to proceed with 2-step upgrade to avoid a one big-step migration:
Upgrade to Spring Boot 2.6 and Spring Cloud 3.1 while still using Ribbon and Hystrix
Make a way through a jungle of an old code and getting rid of Ribbon and Hystrix in smaller increments.
However to achieve this I'm trying to use simultanously Spring Boot 2.6, Spring Cloud with release train 2021.01 and 2 selected starters from older Spring Cloud (latest versions of these artifacts):
spring-cloud-starter-netflix-hystrix 2.2.10.RELEASE
spring-cloud-starter-netflix-ribbon 2.2.10.RELEASE
Is this possible at all? We are heavilly using Feign and Spring WebClient - client-side load-balancing must work for these. So far I found out Feign clients are not automatically integrated with Ribbon.
#spencergibb #OlgaMaciaszek - especially counting on you.
Answering my own question after receiving confirmation from Spring Cloud team by other means: this is a bad idea to try use Ribbon with Spring Cloud 2021.01 and it would require a really hard work to make it working.
So short answer is: "no".
JPAMapStore missing in latest version of Hibernate-Spring.
Its Available in hazelcast-spring-3.2.4.jar, However i am not able to find it latest version of Hibernate-Spring.
I am trying to use JPA based Mapstore for my Spring Boot Application
It was deleted long time ago and moved to Hazelcast Code Samples. It's not strictly related to core Hazelcast, so you can write it on your own or just copy from the Code Samples.
Some other related resources:
Hazelcast JPA Code Sample
Hazelcast JPA Example
Hazelcast Spring Data Module
I would like to use Cassandra NoSQL server with an RDBMS in Play 2.3.0!
Started to build it up using Kundera, according to this tutorial:
http://recipes4geeks.com/2013/07/06/play-nosql-building-nosql-applications-with-play-framework/
It works fine, and I can use it with pure mysql-jdbc connection, and it also works if I use jdbc for Cassandra connection and JPA for MySQL..
.. but the goal is to use a persistence framework, without handling basic JDBC stuffs!
It looks, this problem was mentioned in the link above:
Caution: javaJdbc app dependency downloads hibernate-entitymanager jar file that interferes with Kundera. Make sure you remove this app dependency which is by default present.
If I remove the hibernate-entitymanager from the dependencies, the project runs, but when it wants to call the Persistence.createEntityManagerFactory("mysql") method, Play says: No Persistence provider... as it was expected.
If I keep the hibernate-entitymanager in the dependencies list, beside the kundera client, the Play server simply shuts down.
Is there a possibility to make it work or I have to replace Kundera?
DataNucleus JPA supports persistence to all RDBMS around (via JDBC), as well as to Cassandra, MongoDB, Neo4j, LDAP, HBase and many others. It's Cassandra support seems to be for all latest versions and uses the native Cassandra driver (not JDBC) and so no chance of conflicts like above. You can read up on it at
http://www.datanucleus.org
Caution: javaJdbc app dependency downloads hibernate-entitymanager jar file that interferes with Kundera. Make sure you remove this app dependency which is by default present.
This should not be an issue with latest Kundera releases. Also you can email sample project at kundera#impetus.co.in in case looking for quick support.
We are using SpringSource-TC-Server and we are considering upgrading to java7. (Currently using java6).
We have not seen any reports on SpringSource-TC-Server not working well with java7 but we do not know of any name worthy projects that have migrated to such an environment.
I'm looking for answer(s) about the following:
Are there any known issues?
Are there any projects who migrated and can report on how it went?
Java 7 is officially supported since vFabric tc Server 2.7.0:
http://www.vmware.com/support/vfabric-tcserver/doc/vfabric-tcserver-rn-2.7.0.html#whatsnew
Since you're using tc Server instead of plain Tomcat probably due to commercial support, it's reasonable only to migrate the underlying Java JDK to the latest version when it is officially supported by the employed version of tc Server. Otherwise, you'd be running it in an unsupported configuration, which isn't far from running a plain unsupported open source version of Tomcat.
Operating tc Server on Java 7 in an officially supported arrangement of versions gives you 2 advantages:
It would have been thoroughly tested by vmWare for any incompatibilities so that you wouldn't have to deal with testing by yourself.
If any problems do occur, you can always get support from vmWare in resolving them.
I know it doesn't directly address your questions, as we in my company also haven't upgraded yet and are only planning to do so.
I just had an impression that your approach makes no sense for a commercially supported product and wanted to outline the reasonable (IMO) approach that is in wide use.
As to any known issues, Java 7 is known for its backward incompatible changes to the XML stack, especially the migration to JAXB 2.2 which changes handling of java.lang.Boolean objects (see the other question - What are the pitfalls when upgrading to Java 7). This can spring up in many different places, I've seen it cause problems in Apache CXF's cxf-codegen-plugin that generates Java stubs from WSDL since the wsdl2java tool it launches makes use of JAXB - the generated method names for boolean elements were no longer in the form of java.lang.Boolean isSomeBooleanProperty() but in the form of java.lang.Boolean getSomeBooleanProperty() which broke code depending on those stubs.
So perform thorough testing if you deal with SOAP web services or XML in general.
I have inherited an application that is running on JBoss 2.4.3 (which I believe is EJB spec 2.0 compatible), and I'm running into quite a few issues (like being able to use modern log4j "Logger" apis [JBoss 2.4 specific issues pushing me to upgrade]).
I understand that I should be able to use a EJB 2.1 container (Jboss 4) without issue, but should I expect to be able to go further?
What are the backwards compatibility requirements for EJB?
Are they meant to be backwards compatible through major versions?
Do application vendors make them fully backwards compatible?
What modifications are necessary to make an older application conform? (small or large? application configuration or re-compilation? etc)
log4j and EJB 2.0 are not related. If you have problems with log4j, then most likely it is a class path issue and not EJB 2.0 compatbility issue. Probably your old application assumes that log4j is somewhere on system class path.
http://what-when-how.com/enterprise-javabeans-3/backward-compatibility-and-interoperability-with-ejb-2/ states that
The EJB 3 specification requires that all complying containers support EJB 2
Which is a good sign. It goes on further to talk about mixing EJB 2 and 3 functionality. So there may be some exceptions, but it really shouldn't be any where near impossible.
Reality may be different; I'll update if I find problems with my jboss upgrade.
See this compatibility report for the EJB library: