Trap with System Properties

Recently I had developed a file upload module in a Portlet application. The module was tested and working perfectly in Windows.When the application was delpoyed in an AIX server, this fuctionality stopped working.
The fix was simple , though it took hours to debug.

To get the header of the multipart content I had code like this,
final int headerIndex= requestContent.indexOf(System. getProperty("line.separator") +System.getProperty("line.separator"));

Using this index I was trying to get the conetent and do the manipulation.

The server where the application was deployed "line.separator" was not set and System. getProperty("line.separator") was returning EMPTY STRING !!!.

This caused my logic to break in the server. So finally I had to put a empty string check (IF condition) for for the property ,line.separator and hard code as '\r\n' as i have no cotrol over the server setting.

This article is a good one for such traps while porting from Windows to AIX, http://www.ibm.com/developerworks/aix/library/au-aix-javatraps/index.html

Facelet - Flushing component

When deploying a new EAR created from a machine with time settings different from that of the server where application is deployed, flushing of the JSF components can happen.

Logs will show the following error.

INFO: Facelet[/pages/menu.jspx] was modified @ 11:45:04 AM, flushing component applied @ 11:41:30 AM

The reason being, when ever a new request is made, server sees the page as modifed in future time stamp and starts compiling again. This causes the component tree to be created again, causing to lose all the state stored by the component.

To fix this add facelets.REFRESH_PERIOD to the web.xml.

REFRESH_PERIOD indicates, When a page is requested, what interval in seconds should the compiler check for changes. If you don't want the compiler to check for changes once the page is compiled, then use a value of -1. Setting a low refresh period helps during development to be able to edit pages in a running application.

web.xml, should look like this,



-1 indicates not to check for changes, since production servers it is safe to set this value.

For more, https://facelets.dev.java.net/nonav/docs/dev/docbook.html#config-webapp-init

Migrating to WebSphere Portal 6.1, PUMA API

There are some minor chages related to PUMA. To get the user and group information make these changes,

Usage of class com.ibm.portal.puma.User should be rpelaced with com.ibm.portal.um.User
and
com.ibm.portal.puma.Group should be rpelaced with com.ibm.portal.um.Group

List attributes = new ArrayList();
attributes.add("cn");
//Get User Name
PumaProfile userProfile = pumaHomeSvc.getProfile(PortletRequest);
PumaLocator locator = pumaHomeSvc.getLocator(PortletRequest);
com.ibm.portal.um.User wpUser = (com.ibm.portal.um.User) userProfile.getCurrentUser();

List attribUser = userProfile.getDefinedGroupAttributeDefinitions();
Map userAttributes = userProfile.getAttributes(wpUser,attributes);
String userName = (String) userAttributes.get("cn");

//Get Group
com.ibm.portal.um.Group wpGroup;
List groups = locator.findGroupsByPrincipal(wpUser, false);

for (Iterator i = groups.iterator(); i.hasNext();) {
wpGroup = (com.ibm.portal.um.Group) i.next();
Map groupAttributes = userProfile.getAttributes(wpGroup, attributes);
String groupName = (String) groupAttributes.get("cn");
}

Migrating to Websphere Portal 6.1,ServletContext

Prior to 6.1 ServletContext could be retived like

PortletContext context = (PortletContext)FacesContext.getCurrentInstance().getExternalContext().getContext();
PortletUtils.getInternalContext(context ).getServletContext();

But this won't work any more.Instead

PortletContextWrapper contextWrapper = new PortletContextWrapper(config.getPortletContext());
//config is PortletConfig
ServletContext servletContext=contextWrapper;

PortletContextWrapper implements ServletContext , so this will work with out any issues.

Migrating to Websphere Portal 6.1,PortletSession

Another issue I faced is while to get the PortletSession. This I couldn't solve . But I got another solution and i was happy as long as it worked. (..But still trying)I was trying to get PortletSession like,

PortletSession)FacesContext.getCurrentInstance().getExternalContext().getSession(false);

Here I got java.lang.ClassCastException: com.ibm.ws.session.HttpSessionFacade incompatible with javax.portlet.PortletSession

PortletSession i need to store some user attributes.Tried different options,but noting worked. So decided to go like,

FacesContext.getCurrentInstance().getExternalContext().getSessionMap()

Now I'm putting my user related attribted in this SessionMap.

Migrating to WebSphere Portal 6.1,FacesContext Locator

Continutaion to my post Migrating to WebSphere Portal 6.1 ...


I had FacesContext Locator in the Project which I was migrating. The getFacesContext method gave me ClassCastException.

thrown : java.lang.ClassCastException: com.ibm.wps.pe.pc.legacy.impl.PortletConfigImpl incompatible with javax.servlet.ServletContext at com.ibm.faces.context.MultipartFacesContextFactoryImpl.getFacesContext(Mult­ipartFacesContextFactoryImpl.java:60

With changes as highlighted I was able to over come this.

public class RIFacesContextLocator implements FacesContextLocator{ ...

public FacesContext getFacesContext(PortletRequest request,PortletResponse response) throws EPSConfigurationException {
FacesContextFactory contextFactory = null;
if (request != null) {
contextFactory = (FacesContextFactory) request.getAttribute(PortletConstants.CONTEXT_FACTORY);
}
if (contextFactory == null) {
try {
contextFactory = (FacesContextFactory) FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
} catch (FacesException e) {
e.printStackTrace();
}
}
if (contextFactory != null) {
try {
PortletContextWrapper contextWrapper = null;
if (null != contextFactory) {
contextWrapper = new PortletContextWrapper(this.config.getPortletContext());
contextWrapper.setPorletConfig(this.config);
/*
*Commented Out
*return contextFactory.getFacesContext(this.config,request, response, this.lifecycleLocator.getLifecycle(request,response));
*/
return contextFactory.getFacesContext(contextWrapper,request, response, this.lifecycleLocator.getLifecycle(request,
response));
}
}
catch (FacesException e) {
e.printStackTrace();
}
}
return FacesContext.getCurrentInstance();
}

Migrating to WebSphere Portal 6.1

Recently (late though..) we migrated our portal application from Websphere Portal 5.1 to Websphere Portal 6.1 using RAD 7. Initially we had some issues in getting the environment ready. Even sample projects was not getting published. Server was just showing "Starting..." and never finished. Due to this the projects never got published.
After googling found this was issue with RAD and upgrading RAD from 7.0.0 to 7.0.5 solved this issue.

Migration Steps I followed

1. Created a dummy FacesPortlet Project in RAD 7.x and take the follwing jar files.
jsf-api.jar, jsf-ibm.jar , jsf-impl.jar , jsf-impl-messages.jar , jsf-portletbridge.jar
Update your jar files with the above files. jsf-portletbridge.jar will not be there in the old project.

2. Extend the portlet with FacesPortlet
public class MyPortlet extends FacesPortlet

previously I had

public class MyPortlet extends FacesGenericPortlet

3. Remove com.ibm.faces.context.PortletFacesContextFactoryImpl from faces-config.xml

This is the faces-config I created newly.

This will be the minimal chages to get your Portlet initialized. But to get the User and Group info there are some minor changes in PUMA API. Also to locate the faces context need some changes. Steps I followed are published as different posts.