Retrieving external URL parameters in WebSphere portal environment (using com.ibm.wps.pb.utils.portlet. PortletUtils)

PortletUtils is a utility class which is provided by websphere portal server. With help of JSR286, it provides some method which really useful. 

PortletUtils.getHttpServletRequest(javax.portlet.PortletRequest portletrequest)

http://localhost:10039/wps/myportal/MYPAGE?test=sample

HttpServletRequest req=PortletUtils.getHttpServletRequest(request);

System.out.println("req.getParameter('test'):"+req.getParameter("test"));  // sample is printed

PortletUtils.getPortletDefinitionId(PortletConfig portletconfig)

String portletUniqueName = "";

ObjectID objID = PortletUtils.getPortletDefinitionId(getPortletConfig());

if(null != objID) {

portletUniqueName = objID.getUniqueName();

}

PortletUtils.getPortletDefinitionId(javax.portlet.PortletRequest portletrequest)

String portletUniqueName = "";

ObjectID objID = PortletUtils.getPortletDefinitionId(request)

if(null != objID) {

portletUniqueName = objID.getUniqueName();

}

PortletUtils.getHttpServletResponse(javax.portlet.PortletResponse portletresponse)

HttpServletResponse req=PortletUtils.getHttpServletRequest(response);

PortletUtils.getUser(javax.portlet.PortletRequest portletrequest)

     User user= PortletUtils. getUser (request);

PortletUtils.getPageId(HttpServletRequest httpservletrequest)

String pageuniquename = "";

ObjectID objID = PortletUtils.getPageId(req);

if(null != objID) {

pageuniquename = objID.getUniqueName();

}.

Implementing friendly URLs in IBM WebSphere Portal 8-based WCM rendering

A good article on implementing friendly URLs in IBM WebSphere Portal 8-based WCM rendering

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Implementing_a_clean_URL_in_IBM_WebSphere_Portal_8-based_WCM_rendering

Retrieving the rendering context within a WCM .jsp component

1. For the preview to work, place the code in the following directory:
\ibm\WebSphere1\profiles\wp_profile\installedApps\<cellName>\wcm.ear\ilwwcm.war\jsp\html>

2. Access via a .jsp component configured with the following path: /jsp/html/render.jsp. 

Note that this .jsp will not work if accessed directly using a URL in a browser such as xxxx/wps/wcm/jsp/html/render.jsp. The .jsp must be accessed via Preview or a rendering portlet.

If you are accessing the content via the Web Content Viewer local rendering portlet, you must also place the .jsp in the war/jsp/html directory for the local rendering portlet. Here is a sample location:

\websphere\PortalServer\installedApps\WCM_Local_ng_Portlet_zkj5916.ear\zkj5916.war\jsp\html\

If you use the Remote Rendering Portlet, you must place it there as well.

<%@ taglib uri="/WEB-INF/tld/wcm.tld" prefix="wcm" %> 
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" %> 
<%@ page import="com.ibm.workplace.wcm.api.*" %> 
<wcm:initworkspace user="<%= (java.security.Principal)request.getUserPrincipal()%>">Cannot get Workspace</wcm:initworkspace> 

<% 

RenderingContext currentRenderingContext = (RenderingContext) pageContext.getRequest().getAttribute(Workspace.WCM_RENDERINGCONTEXT_KEY);


out.println("APP PATH: " +currentRenderingContext.getWcmWebAppPath() + "<br>"); 
out.println("Servlet PATH: " +currentRenderingContext.getWcmServletPath() + "<br>"); 
out.println("Rendering Context " +currentRenderingContext.getPath()); 

%> 

<%-- 
Note: if the rendering context is returning %2F instead of "/", you may want to use the string replaceAll method to modify. For example:

String myContext = currentRenderingContext.getPath() ; 
String myModifiedContext = myContext.replaceAll("%2F", "/"); 
--%>

Different ways of Handling CSS and JavaScript in WCM

We can handle CSS and JavaScript in WCM in following three different approaches. 

Approach 1: Storing the CSS as Style Sheet Component and JavaScript as File Resource Components 

Note:  You can upload the JavaScript file into WCM as the File Resource Component and refer that in presentation template as below

<script  language="javascript" src="<Component name="library/test-javascript-cmpnt" format="url"/>" />

Pros:
1. Out of box component 

Cons:
1. Authors can't modify the CSS in the authoring interface when they have to make changes.
2. You can not refer the File Resource components(like images) stored in WCM like below

table{  
     background-image: url(<Component name="bckImage" format="url"/>); 
} 

3. Need to place CSS and JavaScript on somewhere for future changes(outside of WCM).


Approach 2: Storing CSS and Javascript as HTML Components 
Store CSS styles as HTML components and then embedded those components in presentation templates inside of <style> blocks. (Same for the javascript also) 

Pros:
1.Authors can modify CSS classes inside the WCM authoring.
2.Additional request to load the CSS files is not required (fewer HTTP requests generates from page)

Cons:

1. Here CSS files are rendering from WCM, Can't take the advantage of browser caching
2. Response size and time may increase as Styles are coming from the JCR.

Approach 3: Storing CSS and Javascript as Content Item under some SiteArea

Steps to implementing CSS as a content item -
a). Create a authoring template with a single Body HTML element,
b). Create a presentation template that just refer Body element (you may not use Ephox RTE element because it includes <P> tags , causing CSS Styles failed )
c). Name ContentItem as *.css ("test.css").
d). You can add the above contentItem from other presentation templates as CSS or Javascript . Make sure to append "?subtype=css" to path of content item while referring in other Presentation templates to force WCM content to be rendered with text/css as MIME type instead of text/html (default MIME type for WCM content is text/html or text/plain).

Ex: <link rel="StyleSheet" href="/wps/wcm/myconnect/library/Site/SiteArea/test.css?subtype=css" type="text/css"/>

Following are the advantages if you naming the ContentItem as *.css
a)  When site is pre rendered for delivering content, content items stored as *.css will generate files valid CSS file to pre render
b)  Even when content served through the WCM servlet , this allows the browser to cache the CSS file

Pros:
1.Authors can modify CSS classes inside the WCM authoring portlet with normal workflow process
2.Additional request to load the CSS files is not required (fewer HTTP requests generates from page)

Cons
1. Make sure this content item (css) doesn't pick up by some navigators or menu components as it is content item


Note:
a). In Second and Third approach approach , your CSS styles or javascript can refer File Resource Components(like for background images) that stored in WCM repository as components by simply using the Component Tag as below

body{
   background-image: url(<Component name="bckImage" format="url"/>);
}

b). "subtype" query string parameter only applies to the default content renderer and will not work on URLs which is used to invoke the component renderer (i.e. which contain srv=cmpnt in the query string parameter).

c). You may need to add an extension mapping for CSS to WcmConfigService.properties in older versions. Following are steps to do this.

1. Search for the line "#mapping of mimetypes to extensions" in wcmconfigservices.properties file located under <Portal_root>\wcm\shared\app\config\wcmservices\ directory.
2. There is an attribute named "mimetype.list=extensiontype.gif". Add ",extensiontype.css" (no spaces, include the dot ( . ) character at the front of the string) at the end of the line. 
3. Add a new line "extensiontype.css=text/css" (no spaces) after the "extensiontype.lzh=application/octet-stream" 
4. Save the file.
5. Restart WebSphere Portal Server (WPS).

IBM Reference URL

Rendering WCM Library components in non rendering portlets

// Get the workspace

Workspace workspace = Repository.getWorkspace("admin user id", "admin user id Password");

// set current working library

 workspace.setCurrentDocumentLibrary(workspace.getDocumentLibrary("name of the library where you have your components"));

// retrieve library component

DocumentIdIterator docIds=workspace.findByName(DocumentTypes.LibraryComponent,"component name");
if (docIds.hasNext()){
DocumentId did = (DocumentId)docIds.next();
LibraryComponent libComp = (LibraryComponent)workspace.getById(did);

// Create the rendering context

RenderingContext context =  workspace.createRenderingContext(portletRequest,

                                  portletResponse,

                                  new HashMap(),

                                  "http://localhost:10039/wps/wcm",

                                  "connect");




// Set the path to the content to be rendered

context.setRenderedContent("/Library1/SiteA/SiteArea1/SiteArea1-1/myContent(refer some default content)");

// Get the rendered string

String renderedContent = workspace.render(context,libComp );

Avoid problems when uninstalling IBM WebSphere Portal server

ere are scenarios in which you have to uninstall WebSphere Portal for a particular reason. For example, you might have specified the wrong information in the Setup Manager during installation, or you used Secure way LDAP and now want to install Domino and use Domino LDAP. In these situations, you have to reinstall WebSphere Portal to make these changes, which means you have to first uninstall it. 

Often uninstalling WebSphere Portal becomes a tricky task. The WebSphere environment has several Java processors running in the background, and even if you don't stop one of these Java processors, you can't successfully uninstall WebSphere components. If you have to uninstall WebSphere Portal, you can use the uninstaller that comes with WebSphere Portal, or you can also use the Windows Add/Remove Programs option. 

Make sure you uninstall components in the following order: 

1. WebSphere Portal 
2. WebSphere Application Server 
3. Secure Way LDAP 
4. DB2 
5. IBM HTTP Server 

You can leave the gsktoolkit as it is. Don't mess with this file because it causes problems during your next installation. 

After you remove all these components, reboot your machine. Then remove all physical directories from the machine, such as the C:/IBM/WebSphere directory, which contains WebSphere Application Server and WebSphere Portal information. 

Remove the IBMWPO directory created by the Setup Manager during Portal installation last. You can find this file under the Program files in the IBM directory. Make sure you also check the registry under HKEY_LOCAL_MACHINE/SOFTWARE/IBM to confirm that no previous version information is available. If you follow all these steps, reboot your machine again, and you're ready for a fresh WebSphere Portal installation.

Steps for uninstalling WebSphere Portal Server

While uninstalling the WebSphere Portal Server, all the components that come as a part of the umbrella installation of WPS will also be uninstalled. 

But when the uninstall wizard is run, some folders and registries / registry keys of few components might not have been removed from the file system / registry. This will cause the fresh WPS installation to finish successfully, but with an incomplete installation of the MQ Server (This can be seen in the logs - \log\mq_install.log). 

To ensure a trouble free reinstall, the following steps can be followed.

1. Stop the Portal Server
2. Stop the Application Server
3. Stop all Java processes that are running
4. Uninstall WPS from Add/Remove programs
5. Uninstall MQ components if not used
6. Uninstall WebSphere Embedded messaging
7. Uninstall Secure Way LDAP, if left uninstalled
8. Uninstall DB2 if left uninstalled
9. Do NOT remove “gsktoolkit”
10. Reboot the machine
11. Remove all physical directories from the file system (Do NOT delete “gsk”)
12. Remove IBMWPO directory if it exists
13. Remove the following windows registry entries: *

a. Registry entry for IBM:

· HKEY_LOCAL_MACHINE\SOFTWARE\IBM

b. Two keys for the Embedded Messaging feature for WEMPS:

· HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\1E5744D76F283AA4AAC375A09C50C9A0

· HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Features\1E5744D76F283AA4AAC375A09C50C9A0

c. Two keys for IBM WebSphere MQ:

· HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\83CD08B8AE134C44AA89E431C1B384F7

· HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Features\83CD08B8AE134C44AA89E431C1B384F7

Once the above steps have been done, a fresh installation of the WebSphere Portal Server can be started. 

Note: This issue is generic to WAS installations (v5.0 / v5.1) and could possibly be applicable to a wide number of products installed over WAS 5.0 or WAS 5.1.

Precautions: While removing the registry entries, one should be very careful, and before deleting, should always take a backup of the registries to be deleted. For more information on how to take registry backups, please visit the Microsoft website.