Developing Portlets With Java Server Faces Dave Meredith NGS Grid Development, e-Science Centre, Daresbury Laboratory, UK

Overview JSR 168 – Some Comments Why develop portlets with Java Server Faces Required Steps to Deploy a JSF Web Application as a Portlet Some Development Issues Summary / Useful Links

JSR 168 – Some Comments Assumes developers will be happy to ignore other (well known) development development frameworks like Velocity, Struts, and Java Server Faces and learn new Portlet API.  168 nvolves developing a GenericPortlet extension for every single portlet they develop.  Can result in complicated processAction() and doView() methods.  Will have to replicate functionality that is provided with web app framework.  Assumes developers will be happy with the JSR 168 portlet-style Model-View-Controller. Fortunately, it is possible to map these other web application frameworks to portlet actions (portal bridges – e.g. Struts portal bridge).

Why Develop Portlets with Java Server Faces ? JSF designed from the outset to be compatible with portals/ portlets. Some other frameworks involve quite complex portal-bridges – have heard using a portal bridge is comparable to ‘trying to fit a square peg in a round hole.’ (Stan Silvert, Java One Online 2005) Can deploy a JSF web application either as a standalone web application, or as a portlet for inclusion in a JSR168 portal container. Existing JSF Applications can be (semi-transparently) deployed as a Portlet application. Helps move away from common notion that portlets are mostly small apps. This requires a little (or no modification) – steps to do this will be shown later in talk.

Same JSF Application Deployed in Pluto Portal Container as Single Portlet JSF Application Deployed As Standalone Web Application (Cog4, JPA + Hibernate, JSF, JSDL, Jargon, JAX-WS, Vine ?)

Why Develop Portlets with Java Server Faces ? Same reasons as for developing regular JSF web applications JSF is standard Powerful MVC programming framework for building (large) Web Applications: Enforces good structuring of code – cleanly splits view from model Well defined navigation rules Managed beans / backing beans for logic (POJOs) Event handling (action events, action listeners, value-change events, phase listeners) Can interact with JSF processing lifecycle at different levels – (v.powerful if required) Powerful form validation Dependency injection via “faces-config.xml” file Not dependent on J2EE Application Server (can run is servlet container like Tomcat) Reusable UI components: e.g. tabbed panes, scrolling tables, calendars, hierarchical trees, table models.....etc Apache MyFaces has over 100 reusable components with addition of Oracle ADF (Trinidad). Future – AJAX enabled UI components (hope it will save me from having to learn AJAX and JS) Good tool support: e.g. drag 'n' drop design of JSF components in JSP using Sun Studio Creator. Developers may already be familiar with JSF: – have own code base (for me, this was a strong reason that I started to develop portlets with JSF).

In JSP (View - No logic / scriptlets ): <h:inputText id="jsdlNameInputText" value="#{ActiveJobProfile.name}" required=”true” validator="#{ActiveJobProfile.validateName}" valueChangeListener="#{ActiveJobProfile.valueChangeName}" /> In Backing Bean (Model): public class ActiveJobProfileBean implements Serializable { private String name; public void validateName(FacesContext context, UIComponent component, Object val) throws ValidatorException { /**TODO implement validation logic, throw ValidatorException if 'val' is incorrect */ } public void valueChangeName(ValueChangeEvent event){ /**TODO implement logic if value has changed */ } Why Develop Portlets with Java Server Faces ? Enforces good structuring of code Backing Beans are POJO’s with no dependency on container. Beans define logic. Display values of bean attributes in jsp view. Call bean methods to perform logic (actions, value change events, validators)

<!-- One shared DB Util object in application scope (creates single JPA EntityManagerFactory and serves ThreadLocal EntityManager instances ) --> J2seEntityManagerUtil org.davemeredith.J2seEntityManagerUtil application persistenceUnitName NgsJobProfileDbHibernateJ2SE JobProfileBO uk.ac.escience.ngs.portal.jobSubmit.dbBO.JobProfileBO application entityManagerUtil #{J2seEntityManagerUtil} ActiveJobProfile uk.ac.escience.ngs.portal.jobSubmit.ActiveJobProfileBean session jobProfileBO #{JobProfileBO} Why Develop Portlets with Java Server Faces ? JSF Dependency Injection (can ‘order’ the injection sequence, - no need for listeners !) (In faces-config.xml)

Overview Why develop portlets with Java Server Faces Required Steps to Deploy a JSF Web Application as a Portlet Some Development Issues Summary / Useful Links

Required Steps to Deploy a JSF Web Application as a Portlet 1) Make necessary modifications to your code: a) Use JSF navigation rules only b) Use abstracted ExternalContext in web application logic 2) Create portlet.xml deployment descriptor for your JSF application 3) Add jsf-portlet.jar to WEB-INF/lib of your application (JSF RI only, not necessary when using Apache MyFaces) 4) Package JSF portlet into a deployable.war file 4) Deploy JSF portlet application to your portal container and register it with the portal so it can be viewed within the portal interface (specifics vary according to the portal container you are using)

a) Ensure page navigation in web application is implemented by JSF navigation rules only (remove any re-direct links). JSF components are rendered so that URL processing is delegated to a ViewHandler which can either create portlet URLs if hosted in a portal, or a FacesServlet URLs if a regular JSF app. Remove links/re-directs: Back With JSF navigation rules: (In faces-config.xml) goActiveJobProfile /ActiveJobProfile.jsp (In Jsp) 1) Make Some Necessary Modifications to Your Code

b) A JSF portlet application must not rely on any servlet-specific APIs Use abstracted 'ExternalContext' class to get access to methods and objects that you would normally get from HttpServletRequest, HttpServletResponse, ServletContext. /** to get the ExternalContext */ FacesContext fc = FacesContext.getCurrentInstance(); ExternalContext ec = fc.getExternalContext(); /** wrong ! */ HttpServletRequest req = (HttpServletRequest) ec.getRequest(); Map paramMap = req.getParameterMap(); String cp = req.getContextPath(); Cookies[] cookies = req.getCookies(); /** right ! */ Map paramMap = ec.getRequestParameterMap(); String cp = ec.getRequestContextPath(); Map cookies = ec.getRequestCookieMap(); /** useful functions for portlet deployment */ String remoteUserUUID = ec.getRemoteUser(); boolean inRole = ec.isUserInRole("userA"); c) Ensure 3 rd party libs / packages / dependencies can be deployed to target container (some issues with shared libs and web-app/WEB-INF/libs and security) 1) Make Some Necessary Modifications to Your Code

2) Create a portlet.xml Deployment Descriptor for JSF web application (using JSF Reference Implementation) NgsJobSubmit_Portlet com.sun.faces.portlet.FacesPortlet com.sun.faces.portlet.INIT_VIEW /index.jsp 0 text/html VIEW en NgsJobSubmit_Portlet NGS, HPC, Job Submission JSF RI does not have a concept of modes, so you (usually) need to disable EDIT and HELP modes in portlet.xml.

NgsJobSubmit_Portlet org.apache.myfaces.portlet.MyFacesGenericPortlet default-view /ActiveJobProfile.jsp 0 text/html VIEW en NgsJobSubmit_Portlet NGS, HPC, Job Submission MyFaces can support EDIT and HELP modes by subclassing MyFacesGenericPortlet. Only supported with MyFaces ) Create a portlet.xml Deployment Descriptor for JSF web application (using Apache MyFaces)

jsf-portlet.jar is the portlet integration library that must reside with your application in the WEB-INF/lib subdirectory. That way, your application can run as a portlet. javaserverfaces_portlet.class Go to and download javaserverfaces_portlet.class (look under Documents & Files menu item) Use"java -cp. javaserverfaces_portlet.class" to install. Based on JSF 1.x release This generates jsf-portlet.jar or, use jsf-portlet.jar that comes with Sun Studio Creator (free download). Also has a project template for creating a JSF portlet using the JSF RI. 3) Add jsf-portlet.jar to WEB-INF/lib of your application (JSF Reference Implementation)

4) Deploy JSF portlet application to your portal container and register it with the portal This is different according to the portlet container you are using. For Pluto (Reference Implementation of JSR 168 portlet container), modify 3 Pluto files and add some Pluto boilerplate code to web.xml: Pluto Files to Modify: /webapps/pluto/WEB-INF/data/ portletcontext.txt portletentityregistry.xml pageregistry.xml a) portletcontext.txt (lists the context path of each portlet application) /testsuite /pluto /SimpleMyFacesPortletsMixed /SimpleRIPortlet /chapter04 /chapter05 /NgsJobSubmissionPortlet1

b) portletentityregistry.xml (registers the portlet with the portal container) NgsJobSubmissionPortlet1. ” --> NgsJobSubmissionPortlet1.NgsJobSubmit_Portlet

c) pageregistry.xml (defines the layout of the portlets in the portal) NgsJobSubmit NGS Job Submission / JSDL Job Profiles Portlet. -->

NgsJobSubmit_PortletServlet NgsJobSubmit_Portlet Wrapper Automated generated Portlet Wrapper org.apache.pluto.core.PortletServlet portlet-guid. --> NgsJobSubmissionPortlet1.NgsJobSubmit_Portlet portlet-class org.apache.myfaces.portlet.MyFacesGenericPortlet NgsJobSubmit_PortletServlet /NgsJobSubmit_PortletServlet/* Add Pluto boilerplate code to web.xml Define a new servlet mapping that wraps the JSF portlet. Note, this code is added when you use Pluto hot-deploy page

Overview Why develop portlets with Java Server Faces Required Steps to Deploy a JSF Web Application as a Portlet Some Development Issues Summary / Useful Links

Some Development Issues 1) Mixing JSF portlets with other portlets in the same portlet application A portal container can host multiple JSF and 168 portlets in the same portal. portal |_ webapps/ |_ 168 portlet application (.war) Portlet applications must communicate |_ JSF portlet application (.war) by an external mechanism (e.g. db, |_ JSF portlet application (.war) Web services) |_ 168 portlet application (.war) However, only one JSF portlet can be integrated into a single portlet application. The problem of inter-portlet communication still exists – (wait for JSR 286).war |_ WEB-INF/ |_ |_ Can write a single portlet application |_ with one JSF portlet and multiple 168 |_ portlets (all share same portlet application |_ session and share data)..war |_ WEB-INF/ |_ |_ Cant write a single portlet application |_ with more than one JSF portlet |_

Some Development Issues 2) web.xml Versioning In Pluto, I could only deploy a JSF portlet application if web.xml is based on web app version 2.3.dtd, not version 2.4.xsd (may be resolved with later releases of pluto) <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" " <web-app xmlns=" xmlns:xsi=" xsi:schemaLocation=" version="2.4">.... 3) Have not yet tried JSF 1.2 JSF 1.2 provides new unified expression language (unified EL), which is essentially an amalgamation of the JSP EL and the JavaServer Faces 1.1_01 EL.

Turn off MyFaces AutoScroll org.apache.myfaces.AUTO_SCROLL false Client State Saving Method, not as Server <!-- Specify where the state should be saved. If state is saved on client, the state of the entire view is rendered to a hidden field on the page. JSR-168 independent but seems buggy when "server" specified (makes sense as are depending more on the portlet container ??) --> javax.faces.STATE_SAVING_METHOD client

Apache MyFaces / Trinidad JSF home Good talk on portlet development with JSF (Building Killer Portlets with JSF – Stan Silvert, Java One Online, 2005) Summary JSF (in my opinion), is a viable framework for the development of powerful web-application like portlets (and standalone web apps). Can deploy existing JSF Web apps as a single portlet. JSF is a standard – always best for future support. There are a few ‘gotchas’ that developers need to be aware of. Intra-portlet communication the main problem, (believe this will be addressed in JSR 286).

A portlet is a piece of Java code that manages the content of one section of a web portal’s HTML. It can do anything else that a Java web application can do.  You can connect a portlet to a database, invoke a web service, download an RSS feed, etc. It lives in a portlet container, which creates, manages, and destroys all the portlets of the portal. Portlet containers are part of portals.  Portals must do other things like manage login, users, groups, layouts, etc. JSR 168 standardizes two main things:  How the portlet container manages portlet lifecycles  How the portlets are programmed.