Since CloverETL Server is considered a universal JEE application running on various application servers, databases and jvm implementations, problems may occur during the installation. These can be solved by a proper configuration of the server environment. This section contains tips for the configuration.

JAVA_HOME or JRE_HOME environment variables are not defined

If you are getting this error message during an attempt to start your application server (mostly Tomcat), perform the following actions.

On Linux:

These two commands will help you set paths to the variables on the server.

As a final step, restart the application server.

On Windows OS:

Set JAVA_HOME to your JDK installation directory, e.g. C:\Program Files\java\jdk1.6.0. Optionally, set also JRE_HOME to the JRE base directory, e.g. C:\Program Files\java\jre6.

Tomcat log file catalina.out is missing on Windows

Tomcat start batch files for Windows aren't configured to create catalina.out file which contains standard output of the application. Catalinal.out may be vital when the Tomcat isn't started in console and any issue occurs. Or even when Tomcat is executed in the console, it may be closed automatically just after the error message appears in it.

Please follow these steps to enable catalina.out creation:

Then use new startup file instead of [tomcat_home]/bin/startup.bat

Timeouts waiting for JVM

If you get the Jetty application server successfully running but cannot start Clover Server, it might be because of the wrapper waiting for JVM too long (it is considered a low-memory issue). Examine [JETTY_HOME]\logs\jetty-service.log for a line like this:

Startup failed: Timed out waiting for signal from JVM. 
      

If it is there, edit [JETTY_HOME]\bin\jetty-service.conf and add these lines:

	  wrapper.startup.timeout=60
      wrapper.shutdown.timeout=60 
      

If that does not help either, try setting 120 for both values. Default timeouts are 30 both.

clover.war as default context on Websphere (Windows OS)

If you are deploying clover.war on the IBM Websphere server without context path specified, be sure to check whether it is the only application running in the context root. If you cannot start Clover Server on Websphere, check the log and look for a message like this:

	  com.ibm.ws.webcontainer.exception.WebAppNotLoadedException: 
	  Failed to load webapp: Failed to load webapp: Context root /* is already bound. 
	  Cannot start application CloverETL
	  

If you can see it, then this is the case. Getting rid of the issue, the easiest way is to stop all other (sample) applications and leave only clover.war running on the server. That should guarantee the server will be available in the context root from now on (e.g. http://localhost:9080/).

Figure 2.1. Clover Server as the only running application on IBM Websphere

Derby.system.home cannot be accessed

If the server cannot start and the following message is in the log:

java.sql.SQLException: Failed to start database 'databases/cloverserver'
	  

then see the next exception for details. After that check settings of the derby.system.home system property. It may point to an unaccessible directory, or files may be locked by another process. We suggest you set a specific directory as the system property.

System variables and more than one CloverETL Server instances running on the single machine (Windows OS)

If you are setting system variables like clover_license_file or clover_config_file on Windows OS, remember you should not be running more than one CloverETL Server. Therefore if you ever needed to run more instances at once, use other ways of setting parameters (see Chapter 16, Configuration for description of all possibilities) The reason is the environment variable is shared by all applications in use causing them to share configurations and fail unexpectedly.

Special characters and slahes in path

When working with servers, you ought to stick to folder naming rules more than ever. Do not use any special characters in the server path, e.g. spaces, accents, diacritics are all not recommended. It's unfortunatelly common naming strategy on Windows systems. It can produce issues which are hard to find. If you are experiencing weird errors and cannot trace the source of them, why not install your application server in a safe destination like:

C:\JBoss6\

Similarly, use slashes but never backslahes in paths inside the *.properties files, e.g. when pointing to the Clover Server license file. If you incorrectly use backlash, it will be considered an escape character and the server may not work fine. This is an example of a correct path:

license.file=C:/CoverETL/Server/license.dat

JAXB and early versions of JVM 1.6

CloverETL Server contains jaxb 2.1 libraries since version 1.3. This may cause conflicts on early versions of JVM 1.6 which contain jaxb 2.0. However JDK6 Update 4 release finally contains jaxb 2.1, thus update to this or newer version of JVM solves possible conflicts.

File system permissions

Application server must be executed by OS user which has proper read/write permissions on file system. Problem may occur, if app-server is executed by root user for the first time, so log and other temp files are created by root user. When the same app-server is executed by another user, it will fail because it cannot write to root's files.

JMS API and JMS third-party libraries

Missing JMS libraries do not cause fail of server startup, but it is issue of deployment on application server, thus it still suits to this chapter.

clover.war itself does not contain jms.jar, thus it has to be on application server's classpath. Most of the application servers have jms.jar by default, but i.e. tomcat does not. so if the JMS features are needed, the jms.jar has to be added explicitly.

If "JMS Task" feature is used, there must be third-party libraries on server's classpath as well. The same approach is recommended for JMS Reader/Writer components, even if these components allow to specify external libraries. It is due to common memory leak in these libraries which causes "OutOfMemoryError: PermGen space".