What is not changed from JSR 168 to JSR 286 portlet specification?

Although JSR 286 specification provides some advanced features to the portal developers but there are some key features of JSR 168 that still remains the same in new API.

• Portlet Modes
• Window States
• Portlet Preferences
• Portlet Security
• User Information 

Difference between Friendly URL’s and URL mappings

In this article, I am going to talk about friendly URLs, URL mappings and difference between them.

Friendly URLs

Friendly URLs are human readable URL prefixes generated based on the content node hierarchy. The URL prefix for content sub node will contain the prefix assigned to the super and all other nodes above it. Friendly URLs are added to a page through page properties in Admin UI or we can add them through XML access too.



By default, Friendly URLs are disabled in websphere portal, to enable them

1. Open WAS admin console.
2. Navigate to Resources -> Resource environment -> Resource environment providers.
3. Search WP_ConfigService and click custom properties.
4. Click “NEW” and add “friendly.enabled” in name and “true ” for the value.
5. If it already exists change “friendly.enabled” to true

The URL assigned is stored in the page level metadata as com.ibm.portal.friendly.name.

URL Mappings

URL mappings are used to define the human readable URL prefixes to the content in the portal which will serve as entry points onto the portal. However, these URL mappings will not be preserved upon navigating to other content node. We can define URL mappings through Admin UI and XML access. Portal does not provide any API to construct URL mappings programatically. URL mappings are preferred when we need a URL to link up between two different portals. This will allow us to maintain a constant URL even with change in content node.



Few Important Points

1. We need to maintain URL mappings for each entry point and they will not be valid for the next navigation state.
2. We need to define friendly URLs for all the pages or nodes in the hierarchy before assigning it to sub pages. It cannot resolve a friendly URL unless and until all pages are properly defined with respective URLs.
3. For friendly URLs, URl assigned is stored in page level metadata as com.ibm.portal.friendly.name.

What is the best way to deploy portlets within Portal environment?

This article lists down different ways of deploying portlets within Portal environment listing advantages and disadvantages of each.

Portlet Deployment

One Portlet per war

In this approach, each portlet is bundled as one war file.

Advantages:

• Abstraction to the lowest level
• Independent development and testing of portlets
• Change to single portlet will not impact other portlets within portal

Disadvantages:

• Messy deployment as the number of portlets grow
• Sharing of portlet session is an issue

All portlets in a single War file

In this approach, we pack all the portlets in one war file.

Advantages:

• Clean deployment, easy to manage
• Easy to share portlet session

Disadvantages:

• Parallel development is a challenge
• The size of the deploying war becomes extremely large and takes a long time to deploy
• Single change in one portlet will cause a redeploy of all portlets, adding re-testing overheads and making portal unavailable

Grouping portlets in one war

This approach refer to portlets grouped together based on function/ same functionality into single WAR files. 

Advantages:

• Small changes to a functionality will not affect the overall portal
• Clean and easy to manage
• Portlets which need to share session will be grouped into one
• Parallel development at functionality level is possible

Disadvantages: 

• Maintenance at individual Portlet level might affect other packaged portlet of the application

Shared library management in ext of Portal server

Shared library in ext of Portlets

Shared Libraries

Apart from portlet applications, there are certain shared libraries used by most of the portlet applications (WAR's). This lead to challenge of how to deploy these shared applications. Here are few options:

Single Portlet application and shared libraries packed into one EAR 
This approach suggests having single portlet application, along with shared libraries and resource files, packed as one EAR file.

Advantages:

• Each EAR will be truly independent
• Common functionality could be extended based on the need of the portlet application
• Changes to shared libraries will not impact all the other independent EAR's

Disadvantages: 

• Each EAR would be large and will take longer deployment time
• Each individual EAR would contain copy of the framework classes and maintainability of different versions of framework classes in different columns will be a challenge
• More complex deployment process
• Changes to shared libraries will require redeployment of all the EARs
• Complex deployment
• Class loading strategy of the application server would have to be restricted to PARENT LAST

Multiple Portlet applications and shared libraries packed into one EAR file 

This approach suggests that multiple portlet applications along with shared libraries and resources files, such as properties, packed into one single EAR.

Advantages:

• All portlet applications share same common libraries

Disadvantages:

• Big size and will take a long time for deployment
• Change to single portlet application will require redeployment of whole EAR and thus unavailability of the application
• Complex deployment

Shared library in ext of Portal server

This approach suggests that the shared library to be placed within the ext library directory of the portal server. This approach is suggested when there is are framework libraries which need to be shared across the organization (Organization level frameworks for logging/exception handling etc.) and each application hosted in the environment should follow those standards.

Advantages:

• One of the most common way of sharing the files among the multiple applications
• In portal world, all the common files pertaining to theme, portlets and third party application are stored in shared library
• No need to use Dyna Cache or JSR 286 events to  save and share values across portlets
• Library would be available across applications
• Individual applications would be lighter since they won’t contain the code for framework classes

Disadvantages:

• Change management for the shared libraries would be very risky

Steps for Creating a Shared library on Portal Server

• Logon to Websphere Application server console
• Navigate to Environment -> Shared Libraries
• Click apply and save it

Assigning to a server 

• Go to servers -> Application servers -> websphere portal -> Java and Process management -> classloader.
• Click Shared library references
• Add the library that you want to share
• Save the configuration and restart the Portal server.

Note: Restart of server is mandatory for the class loader to load all the newly added class files. Now, you can add the shared jars to build path for proper compilation and deployment.