Planet Hippo

Jeroen Reijn (Hippo) — Jboss ModeShape: A federating JCR repository

February 04, 2010

Some interesting stuff is happing in the JCR community. With Apache Jackrabbit 2.0.0 out (with JCR 2.0) and an interesting project called Jboss ModeShape almost reaching it's final 1.0 release. ModeShape recently came to my attention and it seems an interesting project. In this post I will give a short introduction of ModeShape and it's features.

What's ModeShape?

ModeShape is a Java Content Repository implementation which will support both JSR-170 and JSR-283. It's not trying to be just another isolated content repository, but a repository with a strong focus on content federation. In other words: ModeShape's main goal is to provide a single JCR interface for accessing and searching content coming from different back-end systems. These systems can even be of different sorts. You might think of a ModeShape repository containing information from a relation database, a file system and perhaps even another Java content repository like for instance Hippo CMS 7's content repository. You can configure these sources of information with the help of ModeShapes connector framework.

Connectors

One of ModeShape's key concepts is the concept of connectors. A connector will allow you to connect to a certain type of back-end system and transparently expose the information inside the ModeShape repository. In the current 1.0.0 beta release there are already a couple of out of the box connectors available:


  • In-Memory Connector
  • File System Connector
  • JPA Connector
  • Federation Connector
  • Subversion Connector
  • JBoss Cache Connector
  • Infinispan Connector
  • JDBC Metadata Connector 

That's already quite a few, but for the upcoming release they also have plans for expanding the set of connectors with for instance a JCR connector, which I find quite interesting myself, because that would allow you to expose other JCR implementations like Hippo CMS 7 (Apache JackRabbit) in combination with other systems through one JCR interface.

There are many other content solutions out there, so if you can't find a connector that suits your need, you can of course write one yourself and perhaps donate it to the ModeShape project.

Sequencers

One of ModeShapes other interesting features is the concept of sequencers. With sequencers you can gather additional information from a certain item inside the repository and store that extracted information in the repository. ModeShape has quite a few sequencers out of the box:


  • Compact Node Type (CND) Sequencer
  • XML Document Sequencer
  • ZIP File Sequencer
  • Microsoft Office Document Sequencer
  • Java Source File Sequencer
  • Java Class File Sequencer
  • Image Sequencer
  • MP3 Sequencer
  • DDL File Sequencer
  • Text Sequencers

The example below is of the ImageSequencer, which can gather information from certain types of images stored inside the repository. The ImageMetaDataSequencer is used here to extract metadata like size, dimensions and so on from the image if they have one of the specified extensions and the extracted information is stored somewhere else inside the repository.

JcrConfiguration config = ...
config.sequencer("Image Sequencer")
.usingClass("org.modeshape.sequencer.image.ImageMetadataSequencer")
.loadedFromClasspath()
.setDescription("Sequences image files to extract the characteristics of the image")
.sequencingFrom("//(*.(jpg|jpeg|gif|bmp|psd)[*])/jcr:content[@jcr:data]")
.andOutputtingTo("/images/$1");

Conclusion

With other mature JCR implementations out there I think ModeShapes strongest point is it's focus on content federation. Providing a single JCR interface for content stored in different systems is a great initiative, because the JCR API is quite easy to learn and to use. I see a bright future for ModeShape, since companies are sharing more and more in-house information on the web these days. I myself will try to keep a close eye on ModeShape and see how it evolves.

Lars Peters (Hippo) — Why WCM/Portal convergence is a good thing

January 27, 2010

Stephen Powers' blogpost on convergence between WCM and Portal sparked a nice little controversy about the alleged trade-off between integration and separation of concerns. It ain't necessarily so: If integration is done right, the trade-off does not need to be there at all.

Convergence is a two way street. From the WCM perspective we like to think of Portals as a way to offer 'self service', personalization, security and integration with other applications / widgets / iframes and the like. From the Portal perspective we need WCM to provide tools to work with our portal content that does not reside in other applications.

Both are, of course, nothing new. Neither is the fact that vendors (Hippo with Hippo CMS and Apache Jetspeed Portal is the open source example) have been offering integrated portal offerings for a number of years. Given the challenges and costs involved in true integration, it clearly makes sense to offer integrated solutions as to keep such projects manageable. And who can better ensure integration is done right than the vendor itself?

New in Stephen's post is the fact that he, or rather IBM, sees the package of WCM & Portal becoming such a common combination that distinguishing the two markets would no longer be meaningful. This does not mean that WCM and Portals will become an undistinguishable mesh (or mess?) with the risk of losing all we gained from separating content from the presentation layer in the first place.

It does mean, just like before, that buyers should be careful not to select a package that restricts their choice in where and how to manage and publish their content. It also means that buyers should be critical when making decisions about such things as collaboration platforms. Collaboration systems put in place today, may be with us for many years to come. Where does the content reside? Can it be accessed, altered, integrated in other applications? What about the source code? Remember Lotus Notes?

For maximum flexibility and future readiness in purchasing an integrated WCM & Portal, there are four basic questions to ask:
1. Can the WCM system stand on its own? Would you buy it for its WCM functionality?
2. Can the Portal stand on its own? Would you buy it for its Portal functionality?
3. Are the two really integrated? Integrated user management, security, administration, URL mapping, ease of development etc.
4. Is it Open Source (eg, are you free to use and change the software as you wish)?

David Taylor (Hippo) — Jetspeed UI in 2.2.1

January 14, 2010

With this blog post, I introduce the new Jetspeed portal user interface we are developing for the upcoming release of version 2.2.1. For the past several years, the Apache Jetspeed Portal has had two user interfaces:

1. The Portal Pipeline, a server-side, servlet based aggregation engine. The server-side rendering engine was and still is the most common user interface for Jetspeed portals. It has progressed over the years, including the addition of nice features like a multi-threaded aggregation engine, rendering each portlet in parallel on its own thread.

2. The Desktop Pipeline, a client-side, Javascript based aggregation engine. The client-side rendering engine was not the default, and didn't get as much attention as the server-side. That said, I think the desktop pipeline had much more interesting features, with Ajax rendering pipelines serving portlet content to handle parallel rendering requests from within the browser. The desktop pipeline, even though it ran in the browser, still supported the Java Portlet API, adhering to the requirements of action and render phases. It also had some interesting features including drag and drop moving of portlets in either grid or detached mode, and resizing the portlets and layouts.

With version 2.2.1 (still unreleased), we are working on a single rendering engine sharing the same pipeline and code base. This engine can be configured to render portlets on the server-side or client-side. We call this new rendering engine "Jetui", since the client-side code is based on the YUI Javascript library. Jetui already supports many of the drag and drop customization features of the Desktop pipeline, with the addition of several new features. Two interesting new additions are the toolbars: a Page and Space Navigator and a Toolbox.

In this blog I will introduce the Jetspeed Toolbox. The Toolbox is designed to make user customizations very easy in just one click. The toolbox contains three panels:

- Portlet Selector
- Layouts
- Themes


The Portlet Selector can be docked to the left or right side of the page, or it can float freely on top of the page. Portlets can be searched for using this tool, as all portlet metadata is automatically indexed in the portlet registry. Additionally, portlets can be categorized and filtered based on categories (see the drop down list). One click addition of portlets is now possible without ever leaving the page being customized. Portlets are also filtered by secure access. Only portlets that are configured to be viewable to the current user are displayed in the Jetspeed Toolbox.









An interesting new feature is portlet preview mode:








Selecting the theme for the current page or space is as easy as selecting the theme tab and then clicking on the theme. Jetspeed introduces several new themes in 2.2.1:




Page layouts, selected from the Layout tab, provide several default layouts (with more coming).















We are working on integrating the W3C Widgets alongside Java Portlets. Like portlets, widgets will be available for searching and adding from the Jetspeed Toolbar. I will discuss Widgets more in an upcoming blog.



















In an upcoming blog, I will talk more about how to use templates to configure tools across pages...