Recent discussions on CapTech’s internal social media platform addressed a favorite challenge for technology professionals: how to describe what you do for a living to those without a lot of technical expertise.  To achieve that goal without boring your audience to tears, oversimplification is nearly inevitable.   Personally, I’ve found the threat of oversimplification even more daunting when I attempt to be a little bit specific about what I do by using not just an industry term, but a highly flexible industry term: portal.

At several of our clients, we have integrated the Google Search appliance into a Portal.  In order to accomplish this integration we could take 1 of 2 approaches:

1.     Utilize GSA’s built-in ability to format the presentation logic via a XLST.

At several of our clients, we have integrated the Google Search appliance into a Portal. In order to accomplish this integration we could take 1 of 2 approaches:

1. Utilize GSA’s built-in ability to format the presentation logic via a XLST.

2. Utilize GSA’s ability to return straight XML.

Both approaches work well and can suit the needs of a portal. Option 1 though will not work if you need to sort the entire result set prior to displaying it to the users. The reasons for this is as follows:

Over the past 9 months my colleagues and I have been developing an enterprise portal using JBoss Portal and Alfresco.  Currently, Alfresco does not offer out of the box content portlets so we created our own.  Working closely with Alfresco we chose to use their new WCM product for its user sandbox and workflow approval features.  This article explains some interesting findings related to performance and scalability when integrating with Alfresco web content.

The purpose of this post is to describe how you can redirect a user to a specific landing page within a JBoss Portal application. The jboss-service.xml file in your JBOSS_HOME/server/default/deploy/jboss-portal.sar/META-INF directory contains the managed bean definitions and registration of the beans that are used. There is one entry that is of importance to accomplish the redirect, which is the DeafultPortalCommandFactory. This factory is called when every request for your portal is made. Its main objective is to check what the next command is, and if it does not have one, it will render/return the default portal page in your -object.xml.To change this behavior you can extend the org.jboss.portal.core.model.portal.DeafultPortalCommandFactory class and override the doMapping() method to invoke the desired redirect (which can be a redirect to another portlet other than the default or an entirely different portal). You may want to stick a flag in the session to notate that the session has been redirected to avoid a redirect loop. Below is the doMapping() method of com.demo.NewDefaultPortalCommandFactory.java:
Then just package your new class as a JBoss component (.sar file) and register it within the jboss-service.xml. Your new JBoss component will have a packaging structure similar to the one below.
new-portal.sar/
com.demo.NewDefaultPortalCommandFactory
META-INF/
jboss-service.xml
You will need to define your new DefaultPortalCommandFactory within the jboss-service.xml inside your portal.sar.

Finally, you simply need to comment out (or modify) the registration of the DefaultPortal and add an entry your new Command Factory in the jboss-service.xml file in the jboss-portal.sar/META-INF.