App server related topics

From OpenCms Wiki
Revision as of 10:42, 19 January 2009 by Matinh (Talk | contribs)
Jump to: navigation, search

Contents

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; };


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

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.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox