Quality is an important aspect of every software development project. Writing unit tests is just one part of keeping an eye on quality. In this post I will try to explain how you can unit test your Hippo Site Toolkit (HST2) components, so you can be sure that the component still behaves as expected even after multiple maintenance cycles.
Most developers working with Java hardly have to think about the memory footprint of their application that they wrote. The garbage collector inside the JVM will remove most waste, but what happens when not all waste can be removed or something is wrong inside the application? This may result in an exception that probably a lot of developers and system administrators have seen before: java.lang.OutOfMemoryError (OOME). There are several causes for such an exception, but the most obvious is that there is memory leak somewhere in the application.
Once your Hippo CMS project is in production, there is always the case that you or your customer wants to add extra features to the website or portal. This might mean that the data model has to change The data model for a piece of content in Hippo CMS is stored based on a JCR nodetype definition. As you might know the editor templates, which are related to the data model, can be edited live in the CMS. When you’re done editing the editor templates, you can use the ‘Update all content’ button to persist the changes in your existing content model. This might be a nice way of doing things during development, but performing such an operation on a live clustered environment can be quite tricky and you might want to do it in a more controlled and tested way.
A while ago a user on the Hippo CMS 7 forum donated a patch, which provided a servlet for simple WebDAV support. He donated his code as a proof of concept and hoped that somebody with some deeper knowledge of Hippo and it’s nodetypes could pick this up and continue to work on it. Since the patch was left alone for quite some time I picked it up and turned it into a Hippo Forge project and called it: ‘Hippo CMS 7 WebDAV Support’.
At Hippo I work with/for customers that have quite a lot of content. The projects I work on have content in the range of 5.000 to 500.000 document gathered in one content repository. This can be just textual content, but most of the time this is a variety of different content types. You might think of images, PDFs and Microsoft office document formats. By default Apache JackRabbit, the layer underneath Hippo Repository, indexes this kind of content by using extractors, so that the information can be found within the Hippo CMS 7 search or from any application connected to the Hippo Repository which is performing a search on the content repository. Being able to search on content found within a file is interesting, but there is so much more that you can do with this kind of information.