- Over 100 resolved issues
- Updates to match up with latest version of some third party libraries, for example:
- Revised OSGi manifest headers
Please refer to the changelog for additional details.
Please refer to the changelog for additional details.
Dear Spring Community,
We are pleased to announce that Spring Integration 1.0.0.RC1 is now available.
Download | Reference Documentation | JavaDoc
1.0 Final is now just around the corner. Please give this Release Candidate a test drive, and provide your feedback through the Spring Integration Forum or Issue Tracker. For more information, visit the Spring Integration Home.
Spring Integration Lead
No, not the Obama/McCain smackdown on Nov 4. As you may have read in SD Times, SpringSource has been elected to the JCP Executive Committee for Java SE/EE, along with SAP, Ericsson, Nokia, Philips, and IBM. I will be the SpringSource representative.
Not that the JCP matches the scale of the presidential race. But this is an important moment for SpringSource, and one that reflects the years of hard work and leadership the entire team at SpringSource has provided in enterprise Java. More importantly, I believe that our election will help us to make Java stronger.
Updated 28-Oct-2008: Added up-to-date sample links and link to third sample
Last night I presented ‘Introduction to SpringSource dm Server’ at the Philadelphia Spring User’s Group. During this presentation I created a small application called GreenPages, demonstrating all the major aspects of dm Server. I promised the attendees that I would post the application and the slides here.
In the last few weeks since the GA release of dm Server many people have been asking about the best way to get started with dm Server, so I’m using this entry to collect all the relevant information together, including the Introduction to SpringSource dm Server presentation.
In this article we outline the main themes of Spring Batch 2.0, and highlight the changes from 1.x. Development work on the new release is well underway, with an M2 release last week, and we are getting a lot of interest, so now seems like a good time to give a few pointers.
The four main themes of the new release are
There are no changes to the physical layout of the project in Spring Batch 2.0.0.M2 (same old downloads, same basic layout of Java packages). We have not removed any features, but we have taken the opportunity to revise a couple of APIs, and there are some minor changes for people updating projects from 1.x. Spring Batch is immature enough and we were adding some pretty big features, so we decided a major version change was a good opportunity to have a bit of a clean out. We don’t expect anyone to have any difficulty upgrading, and if you are an existing user this article will help you to get the measure of the changes.
If you build an application for the SpringSource dm Server, or any other OSGi platform, you’ll probably encounter the
uses directive before long. Unless you have a clear understanding of the purpose of the directive, you won’t know when to code it and you’ll be left guessing when a bundle fails to resolve because of a
uses conflict. This article should give you a thorough understanding of the
uses directive, when to use it, and how to debug
OSGi is designed so that once bundles are ‘resolved’, you shouldn’t typically hit class cast exceptions and similar problems due to type mismatches. This is very important since OSGi uses a class loader for each bundle, so there is ample opportunity to expose users to various kinds of type mismatches.
Spring Batch 2.0.0.M2 is now available. See the Spring Batch downloads page for more information - there is the usual .zip download and also Maven artifacts in S3.
Most work in this release went into the chunk-oriented approach to processing, which means changes to the ItemReader and ItemWriter interfaces, plus the introduction of the ItemProcessor as a top-level concern for translating between input and output items. Chunk-oriented processing is a key enabler for performance and scalability, as well as being much clearer for users in the extension points and interfaces (no more framework callbacks in business code).
A few weeks ago Filip Hanik and I gave the second in a series of webinars on Optimising and Tuning Apache Tomcat. A recording of the webinar and a copy of the slides can be obtained from the webinars section of the SpringSource website. The same page has links for all the previous SpringSource webinars, as well as the Covalent webinar archive.
We weren’t able to get to all of the questions during the Q&A session so, as promised, here are the remaining questions and our answers.
You will almost certainly need to use a profiler to identify the root cause of a memory leak. The latest Sun JDKs include tools like jhat and jmap. There are also many other profilers available, both free and commercial. Filip and I use YourKit when investigating Tomcat memory leaks as YourKit provide free licences to open source developers.
This usually occurs when a class loaded by Tomcat retains a reference to a class loaded by the web application. When the web application is stopped, the Tomcat class loader continues to retain the reference to the class loaded by the web application. This class retains a reference to the web application's class loader which in turn, retains references to all the classes it loaded. Therefore, the web application class loader and all the classes it loaded are not eligible for garbage collection. This causes a memory leak. The typical root causes of this are JDBC drivers and logging frameworks.
The JVM to use is set using the JAVA_HOME (full JDK) or JRE_HOME (JRE only) environment variable. The correct place to set this will depend on your environment, particularly if Tomcat is configured to start automatically at system start. If you have a free choice on where to set this then use setenv.bat or setenv.sh as appropriate for your operating system.
No, we do not. The JVM vendor you choose depends on your OS.
We recommend mod_proxy_http with mod_jk a close second. Generally, mod_proxy_ajp is less stable than either mod_proxy_http or mod_jk. Note that mod_jk2 has been deprecated and should no longer be used.
When using SSL HTTP keep alive should be enabled as the SSL handshake is a relatively expensive operation to perform for every request.
Yes, we do. The feedback we have received from clients is that the APR connector is not stable on Solaris.
Without knowing the exact bugs or version you were using, it is difficult to comment. All known Apache httpd issues and the current status can be found in the ASF Bugzilla Database. Tomcat issues can also be found in Bugzilla.
For high concurrency environments, set it to 1. Otherwise, set it to the average number of objects you have on a page, anywhere between 10 and 100.
JkOptions +DisableReuse should be placed in your httpd.conf file with your other mod_jk settings.
When you need to support high concurrency with keep alive and APR is not an option, e.g. because it is unstable on your platform.
It depends. If you proxy all of the requests to Tomcat then performance will decrease slightly. If httpd handles some requests (eg all the static content) then you will probably see some benefit. There are a number of benchmarks that attempt to demonstrate that one connector is better than another. However, it is very unlikely that any of these benchmarks will be representative of your application. The only way to know for sure is to test it in your environment with realistic load and usage patterns.
Yes. Whether this offers the best performance for your environment will depend on that environment and your application. As with the previous question, the only way to know for sure is to test it in your environment with realistic load and usage patterns.
The security of your installation will depend on many factors. The use, or not, of Apache httpd is unlikely to significantly change the security of your installation. Other factors such as keep up to date with patches and using a firewall usually have a much greater impact on your overall level of security.
As always, it will depend on your environment but the httpd performance tuning documentation offers some useful general guidance.
SpringSource ERS is much more than just Apache Tomcat. From a pure Tomcat perspective, performance isn't the differentiating factor. The benefits of ERS are the simple installation, the easy to manage upgrades and patching, support for multiple instances and the integration of all of the components.
There will be lots of differences and the differences that matter will vary from organisation to organisation. Start by working out what you want from an application server and then compare that list to the market. There are benefits in consolidating. Greater consistency means simpler maintenance, less training and so on. However, there are also costs. You would need to look at your organisation and how it planned to consolidate (new projects only, all projects for next major release, everything now, etc) to compare the costs with the associated benefit.
Various reports have been published in this area. How useful the results are depends on how well matches the test is to your load. As always, the only way to know for sure is to test in your environment with realistic load and usage patterns.
Tomcat does not provide this as a configuration option. You can, of course, create multiple Tomcat instances, install your application on each instance and then load-balance across the instances.
The Manager status page is probably a good place to start. You can use the code for that Servlet as the basis for your own, more specific/extensive checks if required. If you do enhance it, consider contributing your enhancements back to the Apache Tomcat community.
The default location is in $CATALINA_BASE/conf.
Running a business is like writing code in at least one respect: You don't always get it right the first time, even if you know what you want to achieveâbut you do get a better result in the end if you are prepared to rework things when necessary. At SpringSource, we had a clear vision for our recently announced maintenance policy: balancing the needs of the open source community with those of enterprise users and the creators of Spring, for the benefit of all. However, we didn't get the balance quite right first time, and it's time for some refactoring.