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
Related
Spring Boot contains loads of dependencies: Spring Framework, Spring Data, etc. How do the Spring maintainers accomplish releasing everything while different teams work on different Spring projects?
We have a similar situation, we have 4-5 teams each making different libraries which are used by other teams. We prefer to be able to allow teams to release independently but this is a huge undertaking to ensure binary compatibility of interface and behaviour.
Each release of Spring Boot provides a curated list of dependencies it supports. In practice, you do not need to provide a version for any of these dependencies in your build configuration as Spring Boot is managing that for you. When you upgrade Spring Boot itself, these dependencies will be upgraded as well in a consistent way.
The curated list contains all the spring modules that you can use with Spring Boot as well as a refined list of third party libraries. The list is available as a standard Bills of Materials (spring-boot-dependencies) and additional dedicated support for Maven and Gradle are available as well.
URL: https://docs.spring.io/spring-boot/docs/1.3.8.RELEASE/reference/html/using-boot-build-systems.html
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.
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)
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
What's the current situation with integrating Guice and OSGi? I.e. exposing OSGi services from Guice, injecting them, etc.
Peaberry's main page mentions "The Guice trunk (which will become 2.0)", but 1.2 seems up-to-date, since it fixes http://code.google.com/p/peaberry/issues/detail?id=58. Its author has switched Sisu, but it doesn't seem to be released yet. Any others?
The integration of Guice 3.0 and Peaberry 1.2 currently is working like expected. Just the page seems to be a little outdated sind the snippet mentioned above refers to the Guice 2.0 trunk which has been superseded.
The Bug your referencing is fixed for the 1.2 Peaberry release when you look at the repository history here.
It's true that Sisu is currently developed and it solves (at least how I interpret it) some additional problems that are currently existing with Guice + Peaberry + OSGi (e.g. automatic component scanning and discovery) but it isn't ready yet.
In my opinion Peaberry solves the same integration cases of DI and OSGi that are also solved by Spring Dynamic Modules (now Eclipse Gemini Blueprint) and is therefore very useful. Also I don't think necessarily that the Peaberry project will be abandoned in favor of sisu.
If all you stay true to the OSGi idea of developing independent bundles that are wired through services but you want to use DI inside them, Peaberry currently offers everything you need for that.
The only problem I'm currently facing with that combination is that the official guice-servlet module doesn't seem to play with the OSGi HttpService by default.