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 users@mirage.dev.java.net

    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.
 

    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.

    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. 

 

      

Browser caching has been taken for granted for so long, that I had not had an opportunity to explore it. Recently, I went through it for leveraging the cache of the browser and I want to put together the findings here :

    Expiration caching -
        The browser caches contents of a page (with the key as the url) for a predefined amount of time, which is indicated in the HTTP Response headers. After this time the browser sends a request to the server, to check for fresh contents.

     Validation caching -
          With HTTP 1.1 a new tag called the Entity Tag (ETag) is introduced, which is opaque to the browser (i.e., just stored by the browser). The browser does not do anything with the ETag but just sends the value as "If-None-Match" HTTP Request header. The server can utilize the ETag by sending a value which identifies the contents of a page, for instance, the userId so that the cache is valid for the user's session. On receiving the ETag value in the "If-None-Match" header, the server can validate whether the contents in the browser cache are still valid, for instance, now the server knows that the user has logged out, and so the cache is invalid, and the fresh contents can be sent back.

    The typical steps involved are : 

1. The browser caches contents of a page if the HTTP Response's header indicates so. This might be through setting the "Expires" header or the new "Cache-Control: max-age=number_of_seconds" header. This provides the period till when the cache is valid.
   
2. The browser uses this cache (without sending a request to the server) when the Back button, or the Forward button is clicked, and when accessing the History or Bookmarked url, provided the cache has not expired.
3. If the Refresh button is clicked, then the browser sends a request to the server since it is an explicit request by the user to reload the page. The HTTP Request header "If-Modified-Since" will have the time period which the server can check against. The server thus has an opportunity to send fresh contents. But if the cached contents are still valid, then the server need not send any body in the response but just send a 304 status in the HTTP Response. If a 304 status is seen by the browser, the browser's cache is reused. If an ETag was sent in the original HTTP Response (ETag: exampleETagValue) then the browser sends this value as "If-None-Match" conditional header in the HTTP Request along with the "If-Modified-Since". As explained before the server can validate the cache by checking whether the ETag is still valid or not.
4. If the cache has expired (due to the expiration period being
   completed, or due to explicit cache clearance by the user), then the
   server must send a response containing the content. For such a request, the conditional HTTP Request headers will not be present.

I think this about covers the basics of expiration and validation caching in HTTP 1.1 used by the browsers. If you have any contradictory or supplementary information, please do let me know, as I'm new to this as well.

    The long standing debate of Ruby on Rails vs. JavaEE applications will continue to stand for some time. But I believe in the notion of "If you can't fight them, join them". So Ruby guys, here is some good news for you. The OpenPortal Portlet Container Project  will soon support Ruby on Rails applications so that they can be treated on par with the JSR-168 portlets. So whether you are writing a Java portlet or a Ruby on Rails application, you can aggregate them using the OpenPortal Portlet Container.

    The ROR application is treated as a first class citizen by the OpenPortal. A new container implementation is provided so that the ROR application can be invoked by the OpenPortal. A ROR application can now be bundled in a Web Application Archive (war) due to the efforts of the Rails Integration project. To enable ease of use and minimal knowledge of Java/JavaEE a plugin on Netbeans 6 is developed. Netbeans 6 supports Ruby on Rails application development. The new plugin leverages the same so that with a few clicks a war which the OpenPortal Portlet Container can recognize.

    The screen cast for the development of the Ruby on Rails portlet can be found here. The screen cast shows how one can deploy and aggregate the now famous simple ROR blog application into the OpenPortal Portlet Container.

    If you are at JavaOne make sure that you check out the Sun's Portal booth where there are live demos of the same on display. So pretty soon you will be able to write your ROR application knowing that there is a Java Portal capable of aggregating your application with other java portlets, and sleep peacefully. :)

PS: If you are going to the JavaOne booth then say hi to Sandeep Soni who has contributed in a major way to get the ROR application in the OpenPortal Portlet Container project.

    It has been an exciting week, with the prospect of integrating and running a Ruby on Rails application as a Portlet. As any Ruby fan would know, it is very easy to generate a web application on Rails with a few commands. So the next logical step was to see if we can somehow get a Portlet out of this web application. JRuby is a wonderfully powerful java implementation of Ruby and the Rails-integration project, which is a JRuby extras project helps in the integration of a Rails application with a Servlet container. 

    There is a plugin provided by the Rails integration project, which creates a war out of a Rails application. This war can be deployed on say Glassfish as a web application and can be used as any normal Java EE web application. For more details of how to do this, check out Ashish's blog entry. 

    So it appeared that there was an existing way to get a Java EE web application. So we used the Portal pack Netbeans plugin to create a Portlet application. We then made sure that the appropriate doXXXX() methods did a Request Dispatch to the rails application by providing the url of the controller and action needed to perform. For instance, using the famous Cookbook Ruby on Rails application, the doView() would be appropriately taking the user to the list of Recipes and so on. As of now this seems to work fine. This is still work in progress, but the presence of JRuby and Rails-integration projects has made the creation of a Portlet a lot easier. Right now this has been working on the Open Source Portlet Container on java.net.

    Next steps would be :

 

1. Provide Portlet urls instead of direct rails urls so that every request appropriately goes through the Portlet Container.
2. Check the statefulness, i.e., session management.
3. Provide a flash demo of the entire process of converting a Ruby on Rails application into a Portlet application, and make it run on the Open Source Portlet Container.

Check this space for more on this, in the coming days.

 

The Enterprise class Portlet Container can now be installed and used with Tomcat. The installation instructions are available on the site and can be accessed at this link. Please try it out. If you face any problems do let us know.

There is a new plugin on the block for Netbeans 5.5 and it rocks! The Portlet plugin for Netbeans allows you create new Portlets with just a few clicks and deploy the Portlet on the Enterprise class Portlet Container which is now part of the Java Application Platform SDK Update 2 which you can download here. The Netbeans plugin is available for download here. The usage of the plugin is very well illustrated in flash demos at http://portalpack.netbeans.org/. Please check out Satya's blog for more details. 

    So all the questions on Hello World portlets should be categorically answered by using the plugin!
 

The Enterprise Class Portlet Container on java.net is available as part of the Java Application Platform SDK Update 2. You can download the App SDK at this link. The Portlet Container can be accessed on java.net here. Right now kudos is in order for the portlet container team for a great job!

Please check out Deepak's blog providing details of the same. 

    The open source implementation of WSRP v1 by Sun is now available for Windows as well. Please check the WSRP Milestone1 Preview here. The installation instructions are the same for Windows and Unix platforms. The Portlet Container works on Windows already, and that should not be a problem either. Again, the installation instructions for the Portlet container remain the same as that on non-windows platforms.

    So if you are using a Windows box and have been shying away from checking out the WSRP implementation, here is your opportunity to play with it :) If you do have any issues please let us know at users@wsrp.dev.java.net .

 

    Anyone who has tried to use any WSRP implementation would know how difficult it is to get something working! So here is something simple to appease the famished.

    Sun's Open Source WSRP Project at java.net provides the implementation of the WSRP 1.0 specification and runs on Sun's Open Source Portlet Container. The instructions on the WSRP project site are detailed and are in easy to understand and use steps. Please follow the instructions to get the source, compile and create a distribution. Once you have the distribution, to administer and manage the WSRP Producer and Consumer, two administration portlets are provided with the source, which are built along with the other sources.
    Please ensure that JAVA_HOME is set to jdk 1.5 home as the admin server uses the platform MBean server to register the MBeans required for administration and management of WSRP Producer and Consumer. Follow the below steps to get your administration portlets up and running.

Start the Admin server:

1. cd <wsrp-directory>/dist/wsrp
2. Edit config/deployenv.conf file to provide the GLASSFISH_HOME and the data storage directory where the WSRP Producer and Consumer data will be stored. You may have already done this if you have deployed the WSRP Producer and Consumer. If so, then you can skip this step.
3. cd <wsrp-directory>/dist/wsrp/admin
4. $JAVA_HOME/bin/rmiregistry 1099 &
5. $ANT_HOME/bin/ant -f run.xml

This will start the admin server and create a producers.xml file in the data storage directory specified in <wsrp-directory>/dist/wsrp/config/deployenv.conf and also a consumer.xml file containing the default information.

Deploy the Admin portlets: 

1. Access the Portlet Container Driver at http://<hostname>:<port>/portletcontainerdriver/dt
2. Click on the Admin tab.
3. In the Deploy a Portlet section, browse to the directory <wsrp-directory>/dist/wsrp/admin and select the wsrp-producer-portlet.war.
4. Deploy the portlet.
5. Similarly browse, select and deploy wsrp-consumer-portlet.war.
6. Click on the Portlets tab. You should be able to access both the administration portlets, with an entry for SampleProducer in the WSRP Producer Portlet.

Use the Admin Portlets:

1. Click on the SampleProducer link and update the Producer by selecting the Portlets that you want to be exposed to the Consumers.
2. Copy the WSDL url of the Producer. Save the Producer.
3. In the WSRP Consumer Portlet, click on New button.
4. Provide the WSDL url of the Producer. (Paste the copied url)
5. Click on Get Info button. This will get the Service Description of the Producer.
6. Provide the appropriate details. Click on Save.
7. The newly created Consumer would be visible in a table in the WSRP Consumer Portlet.
8. Click on the "Create" link in the newly created Consumer row. This is to create a channel.
9. Select one of the Portlets whose display names are provided in a drop down list (these are the portlets that are made available in the WSRP Producer), and provide the name for the channel.
10. Click on Save. This will create a new channel for the remote portlet.
11. Click on the WSRP tab. You will be able to access the remote portlet.

That's all there is to it really. The number of steps may seem to be overwhelming, but it is very easy to follow and will indeed get you up and running very quickly. Try it out and if you have any doubts, concerns, comments or downright criticisms please feel free to let us know at users@wsrp.dev.java.net.

Rock on. :)

 

    It gives me great pleasure to write about the fact that the WSRP 1.0 open source implementation by Sun is out for preview. The project can be accessed at https://wsrp.dev.java.net. 

    The documentation of how to get this working on the Sun's open source  Portlet Container is present on the site. Please feel free to download the code and use it. If you do have any problems, please let us know at users@wsrp.dev.java.net and we will be more than happy to help you out and take your feedback.

But for now, this is a time to cherish for the WSRP team. Team lets a take a bow :)

    If you have already installed Sun Open Source Enterprise Class Portlet Container and want to deploy your portlets and test them, you can do so quite easily. Right now, Sun Portlet Container comes with tasks for deploying portlets when the Portlet Container is deployed on GlassFish. To deploy the Sun Portlet Container on GlassFish, please check out my previous blog entry.

    If you have built the portlet container, then a dist/portlet-container directory would be created containing among various directories, a bin directory. I'll refer to this dist/portlet-container as  PORTLET_CONTAINER_HOME.
    So to deploy your portlets, follow these simple steps  :

1. Start GlassFish application server.
   
2. cd $PORTLET_CONTAINER_HOME/bin
3. ant deploy-portlet -Dportlet-war=<name-of-the-portlet-war>

    That about does it for the deployment of your portlet.

    So, for instance, if you have developed a portlet with portlet name WeatherPortlet which is bundled in a war named prediction.war present in a directory like /space/work/portlets, you can deploy the same using

       ant deploy-portlet -Dportlet-war=/space/work/portlets/prediction.war

    You can access this portlet via the following link (assuming defaults, of course)

    http://localhost:8080/portletcontainerdriver/ospc?pc.portletId=prediction.WeatherPortlet

    So start coding your portlets and testing them in an easy way.