There are a couple of small problems with debugging. Until these are fixed by JetBrains it is worth pointing them out:
Remove this from IntelliJ-IDEA-4.5.3/bin. It is a 32 bit binary and needs to be replaced with a 64 bit one. Removing it causes no loss in functionality.
Add -Didea.no.launcher=true to the following line in idea.lax:
lax.nl.java.option.additional=-Xms32m -Xmx256m -Dsun.java2d.noddraw=true -Didea.system.path="~/.IntelliJIdea/system" -Didea.config.path="~/.IntelliJIdea/config" -Didea.popup.weight=heavy
Thats it. Everything then works perfectly.
I have been looking at the performance of our web integration tests lately. They are an order of magnitude slower than our EJB integration tests.
WebConversation conversation = new WebConversation();
And then turn it on with HttpUnitOptions.setScriptingEnabled(true) for those WebConversations that need it.
On a test page on an AMD64 we went from 7 seconds to 1.5 for 200 test runs with this change only.
The next culprit: dom4J
We also create a DOM using dom4j in order to do XPath evaluation. This is also VERY expensive. Removing this gives about the same level of improvement. The new HttpUnit 1.6 makes resorting to XPath a little less necessary. We will gradually phase it out.
23 November 2004
ehcache 1.1 released. This version splits out the constructs
package into a separate sub-project. This simplifies ehcache for those
using it in Hibernate or directly. It also moves the constructs to a
separate jar and release cycle. There is only 1 minor bug fix but then
there was only one bug reported.
See the release notes and full changelog here.
Announcing ehcache-constructs-0.5. A subproject of ehcache, ehcache-constructs builds on top of ehcache to create implementations for common caching patterns. All implementations use ehcache as the backing cache. They also share a common purpose – to create very high performance Java applications.
At present ehcache-constructs contains:
General Purpose Caching
* BlockingCache – a cache which blocks subsequent threads until the first read thread populates a cache entry
* SelfPopulatingCache – a read-through cache. A cache that populates elements as they are requested without requiring the caller to know how the entries are populated. It also enables refreshes of cache entries without blocking reads on the same entries.
* UpdatingSelfPopulatingCache – a read-through cache. A cache that populates elements as they are requested without requiring the caller to know how the entries are populated. The cache entry is automatically updated on subsequent reads.
* SelfPopulatingCollectionsCache – a SelfPopulatingCache that adds threading safety where it is known in advance that all entries will be collections.
Servlet 2.3 caching filters that cache HTTP/S responses:
* CachingFilter – an abstract, extensible caching filter.
* SimplePageCachingFilter – a concrete implementation which caches pages based on the request URI and Query String.
* SimplePageFragmentCachingFilter – a concrete implementation which caches page fragments based on the request URI and Query String.
See the [ehcache-constructs](http://ehcache.sf.net/ehcache-constructs) subsite for an overview, documentation, javadoc, clover test coverage and more.
JPAM is a Java-PAM bridge. PAM, or Pluggable Authentication Modules, is a standard security architecture used on Unix, Linux and Mac OS X systems.
JPAM permits the use of PAM authentication facilities by Java applications running on those platforms.
These facilities include:
JPAM has its own proprietary API via the PAM class but also supports JAAS with a LoginModule implementation.
Binaries are available for:
* Linux 32 bit i386
* Linux 64 bit amd64
* Mac OS X ppc
Visit the JPAM website [here](http://jpam.sf.net)
In the world of open source, it seems there are periods of inching forward punctuated by large jumps. I believe we are in the middle of one of those jumps now. In this post I argue that the combination of Fedora Core 3, AMD64, the emergence of Firefox, Java 5 64 bit makes for one of those jumps.