Posted by Vincent Partington in the early evening: January 1st, 2009
Spring 2.0 and later versions offer schema based configuration that allows us to have a more expressive and concise way to specify our configuration. For example, Spring Security 1.0 configuration used to be quite hairy, but became a lot simpler with Spring 2.0.
One disadvantage is that the documentation of the namespaces is not as good as that for regular beans. For regular beans, I can have a look at Javadoc, while for the namespaces that come with Spring the documentation is not up to the same level of detail. Until a Javadoc-like tool can generate this documentation from the schemas, the best documentation is the schemas themselves.
One little problem
But ignoring that issue, I recently ran into a very practical problem with using schema based configuration in combination with a PropertyPlaceholderConfigurer.
(more…)
Posted by Vincent Partington just before lunchtime: December 13th, 2008
VMWare Server 2.0 was released about two months ago. Virtualization is hot and has a lot of different uses. I use it to run the Linux-based middleware products (Apache, IBM WebSphere Server, IBM WebSphere Portal, etc.) for which we are building an automated deployment product on my . But more about that later…
Anyway, I’ve been running betas and release candidates of VMWare Server 2.0 for six months now and while the functionality is great, initially the performance was very bad on my Thinkpad T61p running Windows Vista. Last week I finally got it to work with proper performance. A perfect time to let other people know how. 
Posted by Vincent Partington in the early evening: October 12th, 2008
If you are using Eclipse to write your JUnit 4 tests you might have noticed that when you organize the imports, the line
import static org.junit.Assert.*;
at the top of your JUnit 4 classes is replaced by stuff like:
import static org.junit.Assert.assertTrue;
import static org.junit.Assert.assertNotNull;
Posted by Vincent Partington in the early evening: May 26th, 2008
Last week we discussed #6 - which means we’ve now passed the halfway point of SOA Pitfall countdown! Let’s quickly move on to #5.
Like the Not Invented Here syndrome we discussed earlier, Big Design Up Front (BDUF) is something not only witnessed within the realm of SOA. However, where the NIH syndrome is generally accepted to be a bad thing, things are not that simple when it comes to BDUF.
Posted by Vincent Partington in the early morning: April 23rd, 2008
At Xebia we are involved in quite a number of Service Oriented Architecture (SOA) projects, from small to big. In that capacity we see a lot of good stuff happening, but we also encounter quite a number of projects that have stalled or failed.
To share our experiences with these SOA projects, Gero Vermaas, Viktor Grgic, Rik de Groot, and myself have decided to write a series of blogs about the most annoying pitfalls of SOA. Each week we will be publishing one item from the list. This way we hope to spread awareness of these dangers and also provide you with a checklist of what to watch out for. Of course, as is always the case with these kinds of lists, they are not complete and not all the issues are as absolute as the title may imply. YMMV!
The first item we want to discuss is the Not Invented Here Syndrome (NIH). Of course this is something that can be witnessed in more areas of IT, but in a SOA context it actually applies on two different levels.
(more…)
Posted by Vincent Partington around lunchtime: April 30th, 2007
For the last two and a half months, I’ve been blogging about the Enterprise Java Application Performance Problems Top 10:
- #10 – Excessive logging
- #9 – Incorrect application server configuration
- #8 – Incorrect usage of Java EE
- #7 – Unnecessary use of XML
- #6 – Improper caching
- #5 – Excessive memory usage
- #4 – Badly performing libraries
- #3 – Incorrectly implemented concurrency
- #2 – Unnecessary remoting
- #1 – Incorrect database usage
Posted by Vincent Partington in the late afternoon: April 29th, 2007
I’ll keep you in suspense no longer. 
It’s time for numero uno of the EJAPP Top 10 countdown!
Somewhat unexpectedly for an Enterprise Java Application Performance Problems Top 10, the #1 issue is the incorrect usage of databases.
Posted by Vincent Partington in the late evening: April 25th, 2007
Picking up the pace to make sure I get the countdown finished before I go to JavaOne , I’ll quickly move on to #2 of the EJAPP Top 10 countdown….
While remoting is often used in Enterprise Java applications due to the fact that other systems and applications need to be invoked, unnecessary remoting is an important cause of badly performing Enterprise Java applications.
Posted by Vincent Partington in the early evening: April 22nd, 2007
We’ve reached the top 3 of the EJAPP Top 10 countdown now, so let’s get going…
Incorrectly implemented concurrency can cripple the performance of your application in very unpredictable ways. Applications that perform pretty well under light load may crawl to a halt under heavier load.
A major cause is lock contention, which only becomes an issue when multiple threads are involved. For example, if a request that takes 100ms, spends 25ms in a critical section, no more than four requests can be handled every 100ms. No matter how much you decrease the other 75ms, Amdahl’s law tells us the maximum speedup by introducing parallelization is 4!
Posted by Vincent Partington in the late evening: April 16th, 2007
After skipping the easter weekend to go snowboarding in Chamonix, I’ll continue the EJAPP Top 10 countdown with number 4.
Badly performing libraries are a problem that occurs more often than one would expect. This issue is somewhat similar to the incorrect usage of Java EE in that not enough care is taken in selecting and using a certain technology. Some development teams will happily pile JAR after JAR into their WEB-INF/lib directory or into their POM file, :
- without checking whether that library is really needed (and does not overlap with functionality already offered by other libraries used),
- without checking whether that library can offer good performance or whether a better performing alternative is available,
- without reading the documentation to see how it should properly be used, and
- without defining how the library is going to be used within the application