I am getting started with ehcache(standalone server caching) and confused with different versions.
I have noticed that maven groupid for ehcache 2.x and 3.x is net.sf.ehcache and org.ehcache respectively, which suggests that ehcache versions 2.x and 3.x are for different purpose.
The change of major version coupled with the change of groupId is used to indicate that Ehcache 3.x is not compatible with Ehcache 2.x at the API level.
Both libraries are about caching, from small caches in-memory to distributed caches. Ehcache 3 is also fully compatible with the javax.cache API, the caching standard in Java.
Unless you have third party libraries that do not work yet with Ehcache 3, I recommend picking that version. It is the one under active development. Note that as of Ehcache 3.5, Java 8 is required.
You can of course look at features of each major version on http://ehcache.org.
Related
I was trying to find some examples and evidence if Spring 4.0.3 version support caffeine cache integration? If yes, what caffeine cache version is supported for Spring 4.0.3?
Support was added in Spring Framework 4.3 and in Spring Boot 1.4. Previously you could use the Guava provider, which was the baseline for Caffeine's. That will likely be a good approach until you are ready to upgrade. If you really need to use Caffeine for performance reasons then you might try this alternative integration.
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).
Does EHCache implemenation of JCache supports Distributed caching feature?
My requirement is Distributed Client-Server Cache: Multiple cache (clustered) nodes, collaborating in a distributed fashion and executing in isolation from the client application.
Thanks
Note: I am a developer working on Ehcache
Ehcache, depending on version, has two different ways it is integrated with JSR-107 / JCache:
Version 2.x needs the ehcache-jcache wrapper
Version 3, under active development, is a native implementation of it.
In both cases, while using the JSR-107 / JCache API in your application, you can benefit from the whole set of options available to native Ehcache. This includes the clustering support:
It is available with Ehcache 2.10.1 and Terracotta 4.3.1 today
It will be included in Ehcache 3. It has been released and is available with Ehcache 3.1 and above.
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.
Some vulnerabilities that apply to Spring Framework for versions are included in my Grails deployments. Are these also vulnerabilities in Grails (v2.2.5 which contains Spring 3.1.4)? The vulnerabilities listed here
http://www.cvedetails.com/vulnerability-list/vendor_id-9664/product_id-17274/Springsource-Spring-Framework.html
apply to e.g. Spring v 3.0.0 to 3.2.8 which includes 3.1.4 but Grails 2.2.5 is the latest release of 2.2.x.
How do I know if these CVEs apply to my version of Grails?
The Spring, Grails, and Groovy teams have been part of the same company since 2008 when SpringSource (sadly no longer an entity) bought G2One, continuing with the purchase of SpringSource by VMware, and the dissolution of SpringSource into Pivotal when it was formed from groups from EMC and VMware. They work together closely and of course the Spring team notifies the Grails team when vulnerabilities arise.
The issues in the page you linked to are either non-issues in Grails, or are old enough that any recent version of Grails uses a version of Spring that has a fix for the issue. Specifically, CVE-2014-1904 deals with web/servlet/tags/form/FormTag.java, but while JSP tags are supported in Grails, they're rarely used since GSP tags and includes are vastly more convenient. CVE-2014-0054, CVE-2013-7315, and CVE-2013-4152 relate to StAX/OXM/JAXB/XXE - a handful of XML-based acronyms that have no direct support in Grails, and to my knowledge no (or little if any) plugin support. CVE-2013-6429 discusses SourceHttpMessageConverter which doesn't seem to be directly used, but is potentially used by RestTemplate and therefore potentially by the rest-client-builder plugin.
But if these were issues, the Grails team would be notified and the issues would be addressed. This has happened a few times in the past, e.g. http://support.springsource.com/security/cve-2012-1833. Grails-specific issues are also reported using the same mechanism, e.g. http://www.pivotal.io/security/cve-2014-0053