Sunday May 11, 2008

Project Mirage on WebSynergy

    With the announcement of Project WebSynergy, the new web presentation platform for internet and enterprise applications, the excitement is palpable :) The erstwhile portals, will look and feel and more importantly, think (yes think, just wait for Web 3.0 :) ) and act, much better now.

    The solution for aggregation and presentation might have been improved with Project WebSynergy, but most of the requirements still remain the same. And one of the main requirements has always been for a good Content Management System (CMS). Project Mirage fulfills this need for Project WebSynergy by providing an Open source CMS built on top of a JSR-170 implementation. This provides portlets which can be deployed on WebSynergy to utilize the CMS functionalities. This screencast tries to showcase a few of the features present.

    As of now, things are looking bright :) So download the zip file and try it out. Let us know what you feel about it.

    Please feel free to send any feedback on Project Mirage to

Wednesday Mar 05, 2008

CMS Out of the box

    There has been a long standing requirement to get an Out of the box Content Management System (CMS) and this has been solved by various vendors. But a good open source, standards based implementation which can be used in a Web application, a Portal, a Portlet application or even a command line implementation (yes they have needs too :) ), has been found wanting for some time. So welcome Project Mirage, an Open source CMS which leverages the JSR-170 content repository. This is part of the OpenPortal community.

    Project Mirage aims at providing CMS features as services on top of any JSR-170 (JCR) compliant content repository. This right now has an implementation using Apache Jackrabbit, which is the RI for JSR-170. By default, content modeling, versioning, templating using a WYSIWYG editor, access control are some of the services provided in the Project Mirage. Also out of the box, it integrates with SUN JavaCAPS workflow engine so that "Human business workflows" can be associated with contents.  SAW is used to ensure that the  implementation is not tied to JavaCAPS alone, as SAW provides a layer of abstraction on top of workflow engines.

    Look out for more posts on Project Mirage, how to use the API provided, and the default portlets which are built as part of the project.

Friday Aug 10, 2007

Caching with JSR 286

    The public review draft of JSR 286 was recently released and the related files can be downloaded from this link. One of the major changes introduced in the new Portlet specification is how the caching of markup and resources can be done by the Portlet Container. I just want to highlight the differences between the caching part of JSR 168 and JSR 286 here.

 JSR 168:

  • Only markup caching is supported. Resources are not accessed through a separate life cycle method.
  • Only "Expiration" cache is supported.
  • The cache is per user client and not shared across users.
  • The cached content is expired after a pre-defined (in portlet.xml) period, or as set in the portlet (programatically).
  • The expired cache is deleted and a fresh markup is fetched by calling the render method

JSR 286:

  • Resources can be cached. A new life cycle method serveResource() has been introduced which allows access to the PortletContext object apart from providing more control for the portlet developers.
  • "Validation" caching is supported along with "Expiration" caching. After the cache has expired the portlet has the option to check if the cache is still valid and indicate that the cache can be reused. To enable this, ETag has been introduced, which is similar to how the browsers, which conform to HTTP 1.1, perform caching. Once the cache has expired the Portlet Container calls the render/serveResource method with the ETag set in the RenderRequest/ResourceRequest, which the portlet can access and check if the cache is still valid. If the cache is still valid, then the portlet can set the USE_CACHED_CONTENT property in the response, and the new expiration time.
  • Cache scope has been introduced, which when set to "public" indicates that the cache can be shared across users. The default value is "private" which behaves like the JSR 168 caching where the cache is per user.

The introduction of ETag ensures that the browser can be leveraged to cache resources and markup. With the new features of public sharing of caches, resource caching, validation caching and leveraging browser caching,  the performance of aggregation of portlets by a portal can be seen to increase significantly.

Thursday Aug 02, 2007

Deploying portlets on OpenPortal Portlet Container

    Quite a few people have been posting queries about deploying JSR-168 portlets on the OpenPortal Portlet Container. I would like to elaborate on the various ways to deploy portlets on the OpenPortal Portlet Container now. Before you read further, you would need the OpenPortal Portlet Container to be installed. The installation instructions on the site are quite easy to follow and you should be up and running in a few minutes.

    There are now officially 3 different ways to deploy a JSR-168 portlet on the OpenPortal Portlet Container:

  1. Using the "Admin" tab in the Portlet Container Driver GUI, for web based interface.
  2. Using the ANT task, for command line interface.
  3. Using the autodeploy functionality, for a drag and drop interface :).

1. Portlet Container Driver "Admin" tab:

        After installing the Portlet Container, you can access the Portlet Container Driver at http://localhost:8080/portletdriver/dt (assuming default values for the host and server port). To deploy a portlet follow these steps :

  • Click on the Admin tab
  • Under the "Deploy a Portlet" section, click on the "Browse" button.
  • An explorer window is opened, using which select your Portlet war file.
  • Click on the "Deploy" button.
  • A message will be displayed indicating the success/failure of the deployment.

    Please note that a successful deployment means that the Portlet Container has been able to register the details, but it would take a brief amount of time for the war to be deployed on to the application server (based on the time in seconds set for the auto deployment to kick in. By default this is small, and it should be done in 3-5 seconds).

2. ANT task / CLI

      An ANT task is provided, for command line interface, to deploy portlets. You can invoke this task and pass the various parameters expected and the deployment will be done in a jiffy :). The following commands do the trick:

  • cd $PC_INSTALL_DIR/bin      (PC_INSTALL_DIR = GLASSFISH_HOME/domains/domain1/portlet-container)
  • ant -Dportlet-war=<portlet-war-file-path>deploy-portlet

       Well that's that really!


3. Auto-deploying portlets

         This is the easiest option of the three to use. Just copy your portlet war file to the $PC_INSTALL_DIR/autodeploy directory. As simple as that, and it will deploy your portlet! Please make sure that the server is running :)

So go ahead create those portlets (check out the Portal Pack Project for really cool and easy to use Netbeans plugin for creating Portlets) and deploy it on the OpenPortal Portlet Container and start using them.

PS: There is another way to deploy your portlets using Netbeans, and it is part of the Portal Pack Project and the site has screencasts on using the plugin to develop and deploy portlets. 






« July 2016