Copyright 2004 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Struts Portlet Framework: This is the initial version of a small framework to allow Struts to be used as Action handler and context renderer within a portlet. It's far from complete yet but already the standard MailReader example application does run nicely under Jetspeed 2. This example application can be found under the demo folder. Documentation I haven't really written yet (you're looking at all there is right now) but will be provided as soon as possible. Overview: The problem with embedding Struts within a portlet is that Struts processes action handling and view rendering all in one event. To be able to use Struts the framework creates a *virtual* servlet context in which it intercepts the Struts processing after its action handling and postpones the view rendering to the portlet RenderRequest. To be able to do this *right* a Struts portlet application needs to follow some rules. Not every Struts application will run out of the box! A Struts page url within the portlet is encoded as a portlet render parameter. To be able to target a different page, adapted versions of the and tags are supplied (taglib struts-portlet.tld). These will generated a PortletURL with the target page correctly encoded as (action) parameter. Other Struts tags will have to be adapted as well but only these are done for now. Assumptions, restrictions and features: All user interactions go through actions. Direct jsp access by the user will break the framework. This is already *recommended* for any Struts application so this should be not a big problem. Enforce this by storing all jsp files beneath WEB-INF. Struts page url's may not contain '|' or '$' characters. These are currently used to encode a page url to be able to use it as a render parameter. No direct output rendering from an action. All output should be rendered from an ActionForward after action processing. After an action the resulting view rendering ActionForward is included, forwarded or redirected to by Struts. The framework will intercept this and postpone the actual rendering to the RenderRequest event of the portlet. For an include or forward the current Struts context will be temporarily saved in a StrutsRenderContext object in the session. This contains the actual render path, the current ActionMapping, ActionForm, ActionMessages and errors (if defined). For a redirect just the new Struts page url will be set (note: these ActionForwards need to point at an action mapping, NOT a jsp). During a RenderRequest the framework will send Struts once again through the same processing path but will intercept before it will actually start checking/validating parameters. It'll then check if a StrutsRenderContext is available. If so, the context will be loaded into the request context and the saved ActionForward path will now be included (forwards are not allowed in portlets). Otherwise Struts will just continue processing (but won't have any parameters to process). The consequence of this solution is that input action chaining isn't supported (atleat not yet). So action processing realy should be done in one action only. Furthermore, view rendering should normally NOT be dependent on request scope input parameters. This is supported by the StrutsRenderContext (which ONLY saves the ActionForm and messages and currently NO other parameters or attributes) but really only meant for handling validation errors and will only work once (refreshing after a validation error will clear any input /errormessage). A proper MVC implementation should already give you that by the way. If input state has to be preserved beyond one request, session scope ActionForms and ActionMessages stored in the session (supported since Struts 1.2) should be used. To get the proper flow, ActionForwards used after a successfull action processing really should define redirect="true". Struts will normaly forward back to the error page after a validation error. The input attribute of the actionmapping is used for that. But this normally is pointing to a ActionForward directed at an jsp or pointing to a jsp itself. That won't do using this framework. Therefore the page url requesting the action is saved by the struts-portlet tags as well. If after an action processing errors are found the framework will ignore the input page url but uses its own saved url. One thing which the framework supports will formally this is not allowed in a portlet is accepting response.sendError() calls. During ActionRequest processing the error code (and optional message) are saved in a StrutsErrorContext. When the RenderRequest comes along an error page will be rendered (currently embedded within StrutsPortlet). A page refresh will bring up the current Struts page again. Futhermore, any non-handled exception will end up on that *catch-all* error page. Usage: - run maven install (default goal so just maven will do) This will build and install (in your local maven repository) two jars: - struts-portlet-spi-.jar - struts-portlet-.jar The spi jar only contains the StrutsServletContextProvider interface. This interface has to be implemented for a specific portal and gives the struts-portlet access to the servlet context its running in. For J2 this has already been done: org.apache.jetspeed.portlet.StrutsServletContextProviderImpl and globabally available to any J2 portlet (embedded in the jetspeed-commons-.jar located in Tomcat/shared/lib). The J2 implementation with J2 running under Tomcat 4.1.29 is the only one which has been tested so far. The other jar contains the framework classes. This jar has to be put in the WEB-INF/lib of a portlet. - create/modify web.xml: Define as action servlet: org.apache.struts.portlet.PortletServlet which extends org.apache.struts.action.ActionServlet. Define an extension mapping for the action servlet (*.do). Directory mapping is not supported. Add the struts-portlet.tld taglib. The .tld can be found in folder tld. - create/modify portlet.xml: Use as portlet-class: org.apache.struts.portlet.StrutsPortlet Define the following init-param elements: - name: ServletContextProvider value: org.apache.jetspeed.portlet.StrutsServletContextProviderImpl (or one of your own if not using J2) required: yes - name: ViewPage value: to welcome page like: /welcome.do or /index.do (note the extension: jsp's won't do) required: yes The welcome file list from web.xml is not used! - name: EditPage value: to default edit page required: no, default taken from ViewPage - name: HelpPage value: to default help page required: no, default taken from ViewPage - name: ActionPage value: to default action page required: no, default taken from ViewPage - Use the right struts.jar and its .tld files. The framework is developed against the nightly build of 20040407. Anything after that will probably/hopefully work. - Copy the struts-portlet.tld from this project to your tld folder. - modify struts-config.xml: Define as controller processorClass: org.apache.struts.portlet.PortletRequestProcessor. Note, tiles usage isn't possible yet (probably won't be difficult to support so maybe soon). - replace all struts tags which generate action urls: The struts-portlet.tld currently contains adaptions for and . Others will need to be provided later. These adapted tags ensures the correct portlet url's will be generated. - replace remote javascript retrieval ( with for the same reason as above. - setup the actions and mappings with respect to the above mentioned assumptions and restrictions. Demo: As example implementation and proof of concept the Struts MailReader example application (from nightly build 20040407) is is converted to a Struts portlet. The example has been modified on the following points: - all jsp files and the tour.html are moved below WEB-INF in folder view. - the and tags are replaced by their struts-portlet versions - the remote javascript tags (for validation) are replaced by the struts-portlet script tag - the welcome file index.jsp is removed (not needed anymore and did issue an illegal forward anyway) - the CheckLogonTag has been removed: This one issued an illegal forward when the user wasn't logged on. Besided being *bad* practice to do flow control during view rendering having moved the jsp files below the WEB-INF now enforced action processing anyway so the check is done now appropriately there. - The struts-config files (there are two) are modified according the above rules. - Logoff doesn't invalidate the session anymore which could interfere with the current session implementation in J2 (which as far as I know is shared between all portlets, not sure if that's according to the specs though). Known issues: - JS2-11 (http://nagoya.apache.org/jira/browse/JS2-11) currently requires web-app_2_3.dtd to be available from the working directory when deploying the demo application. [FIXED 2004-04-19 DST] - JS2-14 (http://nagoya.apache.org/jira/browse/JS2-14) breaks the local anchor references in the tour. [FIXED 2004-04-19 DST] To build and deploy navigate to the demo folder and run (make sure the production database is running): maven deploy Note that the project.properties in the demo folder should be adapted to your environment first! Undeploy using: maven undeploy During deployment/undeployment an example portlet-entity is inserted/removed from the database using ID 15 (the next one available if just the jetspeed demo portlets are all deployed). Under subfolder jetspeed an example struts-demo.psml and an extended Log4J.properties file can be found for testing the example under jetspeed. Simply copy these files over to your deployed jetspeed webapp folder. As the demo is configured for deployment under Jetspeed-2 a Struts Portlet SPI implementation will be available at runtime. To get it running under a different portal an implementation for StrutsServletContextProvider has to be provided. If its not delivered by the portal itself you can try to define one yourself and include it in the demo together with the spi jar. 20040418, Ate Douma