Marist College and IBM are working to get WebSphere supported with version 2.6. We've done this many times in the past on multiple versions of sakai, but now that platform portability is a key initiative for the community we want to work to get WebSphere supported among Sakai's other application servers... and, honestly, we are sick of doing this over and over again!
You'd think that a web application written in Tomcat would just simply deploy in another appserver, but unfortunately this is not the case. There are subtle differences with how different JVMs and application servers support the specifications. This will sometimes cause a webapp to 'break' when it is deployed in a different environment. If you would like to learn more about some of the things we've uncovered in the past, check out our IVT webcast at: http://ivtweb.com/ibm. The webcast talks about the database and appserver inconsistencies that we've found through our porting efforts with Sakai. Hopefully there is some useful information there if other commercial db/appserver providers wish to support Sakai.
In order to get Sakai supported on Websphere, we had to modify several tools. However, we minimized the amount of change required and ensured that the existing Tomcat behavior is not affected.
Branches
The following tools/modules were branched for us to perform our work. We ensured that these branches are kept in sync with trunk by merging on a weekly basis. The following information provides a summary of the required changes needed to be made in order to get the tool working in Websphere. Note that some of the JIRA issues require an account on our JIRA instance. Please send a request to Marty Banting (mbanting@ca.ibm.com) for access.
| Module | Branch | Summary of Required Changes | Associated JIRAs | Status |
|---|---|---|---|---|
Assignment |
https://source.sakaiproject.org/svn//assignment/branches/SAK-13408 | The problem is due to the different Xerces XML packages that IBM's JRE and Sun's JRE come with. In Sun's JRE, the Xerces implementation accepts attributes set to null values and replaces them with empty strings when serializing their node. In IBM's JRE (which Websphere uses), the Xerces implementation throws an exception when it attempts to serialize a null attribute. The above code checks for null values and sets them to empty strings. This has been successfully tested on Websphere and Tomcat. | WS-23 | Merged |
Blog |
https://source.sakaiproject.org/svn//blog/branches/SAK-13408 | Part of problem is caused by the uk.ac.lancs.e_science.sakaiproject.api.blogger.post.xml.XMLToPost class in the blogger. It hardcodes a reference to "com.sun.org.apache.xerces.internal.parsers.SAXParser", which is the internal parser provided by Sun's JRE. This is not available in the IBM JRE. This hardcoded reference isn't needed, since it will automatically be selected by the JAXP implementation in the Sun JRE anyways. This will similarly happen on the IBM JRE as well, except with the corresponding SAXParser implementation in the IBM JRE. To fix this, simply removing it and letting JAXP select the SAXParser works for both JREs. In addition, When PostCreateView.jsp and PostEditView.jsp uses enctype="multipart/form-data", the UploadFilter class determines the request needs to be checked for an upload, and sends the request to the Apache Commons FileUpload library to be analyzed. The class org.apache.commons.fileupload.MultipartStream checks the request's input stream for any file uploads. This reading of the input stream, however, modifies the stream and subsequently causes problems for Websphere and JSF, preventing it from correctly navigating to the next page. The implemented fix creates a couple of inner classes, BufferedHttpServletRequestWrapper and BufferedServletInputStream, in UploadFilter.java to be used only if in Websphere, that essentially creates a BufferedInputStream for the InputStream, allowing the stream to be reset back to the beginning after the Apache Commons FileUpload library is finished analyzing it. This has been successfully tested on Websphere and Tomcat. | WS-98 | Merged |
Chat |
https://source.sakaiproject.org/svn//chat/branches/SAK-13408 | The JSP 2.0 Extended Language (EL) tag library included as a prelude to all of ChatTool's JSPs uses a runtime interpretation of variables. Expressions of the form ${...} will only be interpreted when EL tags are NOT ignored (i.e. they are enabled). By default, Tomcat will enable the runtime interpretation of EL tag expressions, but Websphere will not. This is remedied by explicitly configuring the webapp in its web.xml. This has been successfully tested on Websphere and Tomcat. | WS-16 WS-77 |
Merged |
Gradebook |
https://source.sakaiproject.org/svn//gradebook/branches/SAK-13408 | This fix addresses the problem of the RoleFilter receiving a blank page name on WebSphere. This fix has been successfully tested on Websphere and Tomcat. | WS-1 | Merged |
Kernel |
https://source.sakaiproject.org/svn//kernel/branches/SAK-13408 | This is a result of a context.redirect() method call by the tool with a relative URL. The context.redirect() invocation ultimately results in a HttpServletResponseWrapper.sendRedirect() method call. Unfortunately, the URI value is different between Tomcat and MySQL. The fix is to modify ActiveToolComponent.MyActiveTool.WrappedResponse.sendRedirect() to convert the given target relative URL to an absolute URL using the current context path and path info, if deployed on Websphere. Tomcat behavior is not affected and stays the same. This has been successfully tested on Websphere and Tomcat. | SAK-14219 | Merged |
Metaobj |
https://source.sakaiproject.org/svn//metaobj/branches/SAK-13408 | The file template.jsp needed the inner quotes to be escaped (<jsp:include page="<%= (String)request.getAttribute(\"_body\")%>" />) in order to be parsed properly by Websphere's JSP parser. Tomcat's parser also still successfully parses and compiles this JSP with this change. In addition, Websphere can't access the spring.tld file if it is in a JAR file. The file has been added to the WEB-INF directory. This has been successfully tested on Websphere and Tomcat. | WS-18 | Merged |
Msgcntr |
https://source.sakaiproject.org/svn//msgcntr/branches/SAK-13408 | No changes made. | ||
OSP |
https://source.sakaiproject.org/svn//osp/branches/SAK-13408 | All the OSP issues that were found (and listed in the next column) are of the same cause. The file template.jsp needed the inner quotes to be escaped (<jsp:include page="<%= (String)request.getAttribute(\"_body\")%>" />) in order to be parsed properly by Websphere's JSP parser. Tomcat's parser also still successfully parses and compiles this JSP with this change. In addition, Websphere can't access the spring.tld file if it is in a JAR file. The file has been added to the WEB-INF directory. This has been successfully tested on Websphere and Tomcat. | WS-4 WS-19 WS-20 WS-21 WS-22 WS-62 WS-63 |
Merged |
Reference |
https://source.sakaiproject.org/svn//reference/branches/SAK-13408 | No changes made. | ||
Rwiki |
https://source.sakaiproject.org/svn//rwiki/branches/SAK-13408 | Tomcat and WAS have different URL structures; Attempting to add a link or image would lead to site unavailable errors in Websphere if the Tomcat URL structure is used. The fix allows Webpshere to use its own URL structure. This has been successfully tested on Websphere and Tomcat. | WS-57 | Merged |
Samigo |
https://source.sakaiproject.org/svn//sam/branches/SAK-13408 | In confirmTempRemove.jsp, the JSP parser and compiler in Websphere translates and displays """ as a literal string. However, Tomcat allows the browser to translate it to a quotation mark. The fix is to use an escaped quotation mark. This has been successfully tested on Websphere and Tomcat. | WS-13 | Merged |
Search |
https://source.sakaiproject.org/svn//search/branches/SAK-13408 | Websphere must be told where to look for *.vm files. This has been successfully tested on Websphere and Tomcat. | WS-9 | Merged |
Sections |
https://source.sakaiproject.org/svn//sections/branches/SAK-13408 | This fix addresses the problem of the RoleFilter receiving a blank page name on WebSphere. In addition, the Websphere JSP compiler wraps the navigation buttons. To fix this issue, the number of columns is decreased in order for the buttons to stay on the same line. This has been successfully tested on Websphere and Tomcat. | WS-45 WS-72 |
Merged |
Here is a link to our parent JIRA: http://jira.sakaiproject.org/jira/browse/SAK-13408
Thanks,
Chris Davia and Marty Banting,
IBM Global Education
Comments (2)
Jun 14
Stephen Marquard says:
Could you post just the slides from the webcast on Confluence in a less bandwidt...Could you post just the slides from the webcast on Confluence in a less bandwidth-intensive format, e.g. PDF or just in a Confluence page?
Jun 16
Marty Banting says:
Hi Stephen, thanks for your interest. Powerpoint slides are now attached.Hi Stephen, thanks for your interest. Powerpoint slides are now attached.