Revision as of 02:45, 20 April 2009

Glassfish V1

Just deploy the OpenCms WAR file and everything is fine.

Glassfish V2

You need to uncomment the lines in the opencms’s web.xml file relating to the ‘BEA’ workarounds (and you also need to delete the ‘description’ elements for the params for the xml to load properly):

OnErrorExitWithoutException true

and

OnErrorExitWithoutException true

RequestErrorPageAttribute weblogic.servlet.errorPage

And of course, you need to deploy it from a directory from the exploded WAR.

After deployment, you need to restart your glassfish domain.

As of OpenCms 7.0.4, the above params in the web.xml file have been removed and the servlet now attempts to detect which app servers require the special exception handling based on ServletContext.getServerInfo(). Unfortunately, there is no entry for "Sun Java System Application Server" which is Glassfish. You have to modify the source to add an entry for Glassfish. In addition, there is a problem with the exception handling code and it runs whether the server is detected or not, so the easiest fix is to update OpenCmsServlet.init() to only log the CmsInitExceptions during initialization.

Sun One Application Server 8.2

This is the needed steps to install and configure OpenCMS 6.2.3

Procedure:

1. Extract opencms.war from the downloaded
2. Deploy opencms.war on http://localhost:4848
3. Edit the following archives (Server configuration - Linux CentOS 4.4 and Postgresql 8.2)

- Edit /opt/SUNWappserver/domains/domain1/generated/xml/j2ee-modules/opencms/WEB-INF/sun-web.xml and it adds this line

<class-loader delegate="false"/>

- Edit /opt/SUNWappserver/lib/appclient/client.policy and it adds this line in the end

grant codeBase "file:${com.sun.aas.instanceRoot}${/}applications${/}j2ee-modules${/}opencms${/}-" { permission java.util.PropertyPermission "*", "read,write"; permission java.security.AllPermission; };

- Edit /opt/SUNWappserver/domains/domain1/config/server.policy and it adds this line in the end

grant codeBase "file:${com.sun.aas.instanceRoot}${/}applications${/}j2ee-modules${/}opencms${/}-" { permission java.util.PropertyPermission "*", "read,write"; permission java.security.AllPermission; };

Restart instance in order to apply changes As I complete continues the normal installation of opencms

JBoss

JBoss treats WAR files differently than other application servers in ways that severely affect the OpenCms installation procedure. To circumvent the problem, OpenCms has to be deployed as an unpacked WAR directory on JBoss.

Procedure:

• Extract opencms.war from the downloaded archive and copy it to the JBoss deploy directory
• Rename opencms.war to prevent naming confusion for the next step (example: opencms.2.war)
• Create a directory named "opencms.war"
• Unpack opencms.2.war in the opencms.war directory
• Depending on the OpenCms and JBoss version, upgrade your JSTL libraries (see this thread for details)
• (Optional) create a file jboss-web.xml in the WEB-INF folder with the following content to define the application's context-root.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
  <context-root>/opencms</context-root>
</jboss-web>

• (Optional, for unix/linux servers) grant the permission to read, write and execute for all on the opencms.war/ directory and it's subtree (chmod -R 777 opencms.war)

After these steps, the web config should work fine.

External Links

Tomcat + IIS Config

Websphere

Sun Java System Application Server 8.x

JBoss 5.0.1GA & OpenCms 7.0.5

Using the default JBoss 5.0.1.GA web app server configuration and OpenCms 7.0.5 will result in application deployment errors. To resolve this problem the following tasks must be performed:

• Unpack opencms.war into %jboss_home%\server\default\deploy directory so that the files will now be in %jboss_home%\server\default\deploy\opencms.war directory. (Edit by: Bsgcic)
• Confirm that the context-parameter "DefaultWebApplication" in opencms.war\WEB-INF\web.xml value is "ROOT". (Edit by: Bsgcic)
• Remove conflicting jars from /WEB-INF/lib (you can just change the file extension to ".delete" extension so you retain it but don't load the jar). These jars include: xercesImpl-2.9.0 and xml-apis-2.9.0. XercesImpl conflicts w/ the Xerces version in %jboss_home%/lib/endorsed. Xml-Apis causes ClassCastExceptions with Digester's getParser and getFactory methods. End result is OpenCms will not work properly and won't even install through the wizard.
• I also followed the steps described under the "JBOSS" heading immediately above this section. (Addition by: Bsgcic)

Additional Notes

• After importing all default modules, I was unable to access any of the new Template 2 demo pages due to HTTP 500 errors in which the app server refused to compile the JSPs requested. I did not investigate further on the cause.
• After importing the default modules some jars will be extract from the modules onto your /WEB-INF/lib directory. Again these have the potential to cause problems with JBoss 5 when you restart the web app. I found it necessary to remove the following jars: xalan, serializer, sax, and jaxp-api to successfully restart the web app.
• Creation and publication of basic JSP content pages and free text pages appeared to be functional.
• Please note that the original author had instructed to unpack opencms.war into %jboss_home%\server\default\deploy\ROOT.war directory. and to change context-parameter "DefaultWebApplication" in opencms.war\WEB-INF\web.xml value to "ROOT.war". I am running the same versions of Jboss (5.0.1.GA) and Opencms (7.0.5) and it did not work in the ROOT.war directory for me but did work in the %jboss_home%\server\default\deploy directory with DefaultWebApplication as the default value of "ROOT". The original author mentioned the following when instructing to unpack into the ROOT.war directory. However, should not be relevant if unpack into the deploy/opencms.war directory as mentioned above. Original author's comment if in ROOT.war directory: "If this value does not match the deployment directory, OpenCms will utilize this value as the context path for URLs within the CMS. That is your CMS generated URLs will be something like http://<yourhost>/ROOT/opencms/index.jsp instead of http://<yourhost>/opencms/index.jsp." (Addition by: Bsgcic)

WebLogic 8.1

This procedure describes only WebLogic 8.1 with the supplied JDK 1.4.2.

OpenCms has to be deployed as an unpacked WAR in WebLogic 8.1.

Procedure:

• Extract opencms.war to a temporary directory
• Replace the jar in "opencms/WEB-INF/lib" with the jar supplied in the Java 1.4 patch (opencms_6.2.3_java_1.4.zip)
• Deploy the exploded WAR to WebLogic
• Go to the Adminitration console and do a static export (Administration -> Database Management -> Start Static Export)
• Modify the web.xml file to change the 404 error handler :

<error-page>
  <error-code>404</error-code>
  <location>/system/handler/handle404.jsp</location>
</error-page>

• Create the JSP "/system/handler/handle404.jsp" with the following content :

<jsp:forward page="/opencms/handle404"/>

• Edit the file "WEB-INF/config/opencms-importexport.xml" search for the following line :

<exporturl>http://127.0.0.1:8080${CONTEXT_NAME}/handle404</exporturl>

and change it to

<exporturl>http://127.0.0.1:7001${CONTEXT_NAME}/handle404</exporturl>

Notes

We have to modify the error handler because WebLogic doesnt allow the same servlet to provide content and error handling. WebLogic is afraid that it might create an infinite loop.

Tomcat

When using tomcat, it's advisable to increase the memory available to the JDK. It can also be important to allocate more memory to the "PermGen" area; this is not reliably garbage collected, so repeated server restarts (particularly when developing Java classes) will rapidly exhaust the permgen space.

In order to allocate more memory to Tomcat under Linux or other *Nix systems, create a file called "setenv.sh" in $TOMCAT_HOME/bin/ . This will be executed by the tomcat startup scripts and can be used to pass environment options to the JVM tunning tomcat. An example setenv.sh script is:

export CATALINA_OPTS=" -Dcom.sun.management.jmxremote -Xmx1024m -Xms512m -XX:MaxPermSize=256m"

This will:

1. Enable remote JMX monitoring of the server (do not do this unless you know what you are doing!)
2. Allow Java to allocate up to 1GB of ram if needed
3. Require Java to allocate a minimum of 512Mb of ram at startup
4. Allow the Permgen area to grow up to 256MB

Increasing the memory available to tomcat will also greatly help the flex cache store JSP fragments, which will speed up overall performance.

An alternative solution is to switch to a different JVM. JRockit appears to be compatible with openCMS and does not have this issue, as it doesn't have a separate "permanent generation" space.