Portlet Factory, Version 6.1.2
Development of a WebSphere JSR 168 portlet
To limit yourself to the functionality defined in JSR 168, you cannot use features specific to IBM® WebSphere® Portal server, such as Click-to-Action (C2A) or People Awareness. These features will still work on a WebSphere Portal server that uses JSR 168, but will not work on other JSR 168 portals.
The JSR 168 portlet specification does not support J2EE 1.2 portlet applications. If you build JSR 168 portlets, the portlets must be based on the J2EE 1.3 or later specification.
Do not rely on HTTP headers for the functionality of your models and portlets. The JSR168 Portlet Specification states the following : "Depending on the underlying web-server/servlet container and the portal/portlet container implementation, client request HTTP headers may not be always available. Portlets should not rely on the presence of headers to function properly."
Portlets may run remote to the portal server, by Web Services for Remote Portlets (WSRP). As such, do not rely on HttpServletRequest API methods that in a traditional Web application return information about the caller or browser request (for example, getRemoteAddr, getRemoteHost, getRequestURL, getProtocol). In other words, the HTTP request to the portlet may not be the same as the HTTP request from the browser to the portal.
Existing portlets configured using the WebSphere Portal portlet adapter are not immediately and automatically configured once the JSR 168 Portlet Adapter is installed. To make an existing deployed portlet available as a JSR 168 portlet, simply perform a copy of the base portlet and set the model name. Your portlets will now run as JSR 168 portlets and will not require any code changes. IBM WebSphere Portlet Factory functionality that does not work with WSRP
The following functionality does not work in a portlet that is built to the Web Services for Remote Portlets (WSRP) specification.
Parent topic: Development of a WebSphere portlet