Developer Runtime Configuration

From AlfrescoWiki

Jump to: navigation, search

Back to Developer Guide
See also: SVN Development Environment


Contents

[edit] Setting Environment Variables

See development environment notes.

[edit] Configuring Repository Location

One of the first things you should do is point dir.root to some concrete and permanent location. Otherwise you will start getting alf_data directories scattered around depending on where you run tests from in Eclipse or otherwise. This creates fatal issues as the Lucene indexes, content store and database get out of synch. On UNIX this is particularly troublesome, because most developers "live in their shells", and are accustomed to being able to run applications from anywhere.

To set this up nicely for your development environment, you could create a file:

   $TOMCAT_HOME/shared/classes/alfresco/extension/dev-context.xml

This will allow you to use the same set of customizations regardless of which Alfresco source code branch you're working on. It can contain any customizations and overrides, but typically it will override the import of system properties:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http://www.springframework.org/dtd/spring-beans.dtd'>

<beans>
    <!-- overriding to point to custom properties -->
    <bean id="repository-properties" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="ignoreUnresolvablePlaceholders">
            <value>true</value>
        </property>
        <property name="locations">
            <list>
                <value>classpath:alfresco/repository.properties</value>
                <value>classpath:alfresco/version.properties</value>
                <value>classpath:alfresco/domain/transaction.properties</value>

                <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
                <!-- Override core properties                                                -->
                <!--                                                                         -->
                <!--    On UNIX/Linux, you could use something like:                         -->
                <!--       <value>file:///etc/opt/alfresco/repository.properties</value>     -->
                <!--                                                                         -->
                <!--    On MS Windows, you could use something like:                         -->
                <!--       <value>file:c:/etc/alfresco/repository.properties</value>         -->
                <!--                                                                         -->
                <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
                <value>file:c:/etc/alfresco/repository.properties</value>    <!-- MS Windows -->

            </list>
        </property>
    </bean>
</beans>

On MS Windows, make c:/etc/alfresco/repository.properties contain:

dir.root=c:/temp/alfresco

On UNIX/Linux, make /etc/opt/alfresco/repository.properties contain:

dir.root=/var/opt/alfresco

By having this configuration, one can be sure that all tests use the same database and data root locations.

If instead, you'd like the dev-context.xml file to be incorporated directly into a .war file, then within the source code tree, copy it to:

root/projects/repository/config/alfresco/extension/dev-context.xml

However, this requires that you do this for every source code branch you're working on; this can be tedious & error-prone, depending on how often you create working copies of source code branches. The choice is yours, but the $TOMCAT_HOME/shared/classes/alfresco/extension/dev-context.xml location is probably all you'd ever need (assuming your customizations are the same from branch-to-branch).


Read the section on Repository Configuration for further details.

[edit] Configuring Tomcat

On UNIX/Linux/Mac, within catalina.sh there's a line that looks like this:

# ----- Execute The Requested Command -----------------------------------------

Just prior to that line, add the following to avoid JVM/Hibernate problems:

#----------------------------------------------------------------
#  The -server   flag avoids problems on Linux and Mac.
#  The -Xmx1024M flag gives the JVM ample memory.
#----------------------------------------------------------------
if ! [[ "${CATALINA_OPTS}" =~ '-server' ]]; then
    CATALINA_OPTS="$CATALINA_OPTS -server"
fi

if ! [[ "${CATALINA_OPTS}" =~ '-Xmx' ]]; then
    CATALINA_OPTS="$CATALINA_OPTS -Xmx1024M"
fi

After starting Tomcat, you can verify that the -server and -Xmx1024M flags are set by issuing the command:

ps auxw | grep tomcat

[edit] Configuring Log4J

Because developers must sometimes remove and redeploy an alfresco.war file repeatedly, is it sometimes useful to be able to maintain a dev-log4j.properties file outside of the webapp. This allows for changing log4j settings without touching the "shipping product", or any of a customer's local settings. Your optional dev-log4j.properties file should be in some alfresco/extension directory within the server's classpath, and outside the webapp itself (so you don't accidentally delete it). The dev-log4j.properties file augments/overrides all others. For example:

  $TOMCAT_HOME/shared/classes/alfresco/extension/dev-log4j.properties

See also: Developing an Alfresco Module


The logging levels for the the portal are set in a Log4J configuration file found at JBOSS_HOME\server\default\conf\log4j.xml. Some details on the types of configurations that are possible can be found in Log4J Configuration.

The log4j settings, when running in Tomcat, can be found in the projects\core\source\java folder.

[edit] Configuring OpenOffice

Install OpenOffice 1.1.4 (or 2.0), run it once to go through registration then disable the QuickStart. Then start OpenOffice with:

..\OpenOffice.org1.1.5\program\soffice "-accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager" -nologo -headless

[edit] Registering OpenOffice

Going through registration is necessary to be able to start OpenOffice as a server and you need a GUI to do so.

If registering OpenOffice isn't so easy as it looks (because you're in some command line interface without GUI support) you could disable the registering setting as mentioned in the OpenOffice project documentation. This can be customised or disabled by setting the (Common/Help/Registration/) URL value to an empty string.

If you look at C:\Program Files\OpenOffice.org 2.0\share\registry\data\org\openoffice\Office\Common.xcu or /usr/lib/openoffice/share/registry/data/org/openoffice/Office/Common.xcu you'll see:

<oor:component-data oor:name="Common" oor:package="org.openoffice.Office"
  xmlns:install="http://openoffice.org/2004/installation"
  xmlns:oor="http://openoffice.org/2001/registry"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    ...
    <node oor:name="Help">
        <node oor:name="Registration">
            <prop oor:name="URL">
                <value>http://www.openoffice.org/welcome/registration20.html</value>
            </prop>
        </node>
    </node>
    ...
</oor:component-data>