Development Guidelines

Development Instances

ExtraView recommends that customers install at least two, and preferably three instances of ExtraView, supporting web software and databases. These are typically known as the development instance, the staging instance and the production instance. The staging instance is optional. These instances should preferably be installed on separate machines, although it is common to use a single database server with multiple user accounts for the different instances.

  1. The development instance – all development happens on this instance. When development and testing is complete, the code is moved to the staging instance
  2. The staging instance – final testing and QA happens on this instance, after the development code is moved to this environment. Once the final testing is complete, the code is moved to the production instance
  3. The production instance – this is the instance of code that accesses the live database and is accessed by all end users.

The Development Environment

  • ExtraView recommends a Window platform for development, although all the essential tools are available under Unix, Linux and Solaris
  • Web Server – such as Apache
  • Application Server – such as Apache Tomcat
  • ExtraView – current version
  • A supported database such as Oracle, MySQL or SQL Server
  • Sun J2SE JDK
  • Note: The JDK that you use to compile your user custom code must be the same version used by ExtraView to build ExtraView
  • ExtraView and associated jars for developing user custom code.

See the recommended versions of the various components on the Server Requirements page.

Development tools

  • Preferably use an IDE such as Eclipse
  • Any text editor can be used in place of the IDE
  • The ExtraView jar file - obtained from ExtraView Corporation
  • Do not develop code on your production ExtraView environment. At minimum, set up a separate development environment
  • Within ExtraView, set the behavior setting named USER_CUSTOM_CLASSNAME within the Behavior Settings Administration menu to be the name you will use for your UserCustom class, for example –
    com.extraview.usercustom.myCompanyName

Basic Development Steps

  1. Use javac with the classpath for your system and include the jars
  2. Develop your code in a class named myCompanyName.java as the source file
    This class should probably extend UserCustom.java to inherit the capabilities that ExtraView ships in its best practices implementation. It is likely that you will extend the class file CustomCodeBase.java. This file itself extends UserCustom.java
  3. Compile the new myCompanyName.java code
  4. The myCompanyName.class is copied into the appropriate class directory. This is typically –

    <tomcat-base>/webapps/<instance-name>/WEB-INF/classes/com/extraview/usercustom

  5. Test your code – the application server must be “bounced”, i.e., stopped and started, before you run the ExtraView application within your browser. Note that when bouncing the application server, all current interactive sessions are lost and all users are required to login into ExtraView again
  6. Test the new code by running through use case scenarios. For example, add a problem to invoke the ucAddPreInsert method. Inspect the output through ExtraView and by looking at the ExtraView system log which is typically located at:

    <tomcat-base>/webapps/<instance-name>/WEB-INF/logs/EVJ.log

  7. You should develop your code to output debug messages to the system log by invoking the system logging method
  8. System.err.println messages are displayed on the application server console. This makes its use ineffective, and makes the system logging method much more preferable and convenient to use.

    9. JVM Memory

    If ExtraView gets even just a single OUT OF MEMORY error, then the JVM –Xms and –Xmx arguments should be increased at the startup time of the JVM. Note that the JVM_HEAP environment variable is used to set these parameters