Starting the samples

JViews TGO includes a rich set of sample code to be used as a reference for the development of an application. Samples fall into three areas: application samples, applet samples, and server-side samples. All sample source code is in the subdirectories of <installdir>/<jviews-product>89/samples.
JViews TGO is based on the Java™ Platform, Standard Edition (Java SE). To run a client application, you must have the Java Platform, Standard Edition Runtime Environment (JRE™ ). To run a server-side application within the provided Apache™ Tomcat server, you must run Tomcat with a Java SE installation (see http://java.sun.com/javase). To run a sample applet, you must have the Java plug-in installed in your browser (see http://java.sun.com/products/plugin/).

Running application and applet samples

The samples provided in the distribution are already compiled so you are not required to compile them to be able to run them. If you want to modify a sample and recompile it, every sample contains a build.xml file so that you can compile and run the sample. This file is an Ant project file. Ant is a Java-based build tool that is developed by the Apache Software Foundation (see http://ant.apache.org.) The distribution contains a version of Ant that you can use if you do not have Ant already installed on your computer. The Ant installation can be found in the <installdir>/jviews-framework89/tools directory.
To use Ant, you must set the following environment variables:
  • JAVA_HOME to point to the Java Platform, Standard Edition that you are using. For more information about supported versions of Java® , see Detailed System Requirements for Rogue Wave® JViews.
    The build.bat and build.sh scripts use the version of Ant provided in the distribution. If you use these scripts, you do not set any other environment variables. If you want to run Ant directly, for example to use your own Ant installation, then you must set:
  • ANT_HOME to point to your Ant directory.
    Add the Ant bin directory to your PATH.
To recompile a sample, go to the samples directory and enter the command:
build.bat
(or build.sh on UNIX® and Linux®).
Alternatively, if you use Ant directly:
ant clean
The samples that can run as applications also have a run target in their build.xml files and run.[bat|sh] batch files:
run.bat
(or run.sh on UNIX and Linux).
Alternatively, if you use Ant directly:
ant run
For more information on how to use the build.xml file of a sample use:
ant -projecthelp
You can read the Ant documentation at http://ant.apache.org/manual/index.html.
Applet memory requirements
To browse all the Java applets displayed in the Product guide, you might have to modify the settings in your IBM® or Sun™ Java plug-in to increase the amount of permanent generation memory available for applets.
To increase this memory:
  1. Exit your browser before making any changes.
  2. Run the Java plug-in Control Panel.
    On Microsoft® Windows® systems, use Start > Control Panel > Java.
    On Linux® systems, run the shell script ControlPanel in the bin/ directory of the Java installation.
    On Macintosh® systems, use Finder to access Applications > Utilities > Java and then run Java Plugin Setup.
  3. Select the Java tab and click View in Java Applet Runtime Settings.
  4. In the table of available JREs, select the row containing the JRE that is used in your browser. If you are unsure which JRE to choose, select all installed Java versions, that is, all rows in the table.
  5. In the column headed Java Runtime Parameters enter:
    -XX:MaxPermSize=256m
  6. Click OK.
  7. Click Apply or, on Macintosh systems, click Apply Now.
This setting allocates up to 256 MB of permanent generation memory to your browser.

Copying a sample

You can copy the directory of any sample application to any location. After the sample is copied you must either change the jviews.home property in the Ant build file or set the environment variable JVIEWS_HOME to point to the installation directory where your Rogue Wave® JViews products are installed. You cannot, however, copy applets or server-side samples to a different location in the same way without making major changes to the HTML pages of the sample.

Running the server-side samples on Apache Tomcat

The distribution contains several samples that show the use of the product running in a Web client. To run the server-side samples, the library requires a Web server compatible with JViews (see Requirements for Rogue Wave JViews TGO ). The Tomcat Web server is supplied with the distribution so that you are not required to download a Web server to run these samples. Tomcat is the official reference implementation of the Servlet and JSP™ specifications. For more information about Tomcat, see http://jakarta.apache.org/tomcat/.

Building the samples for the Apache Tomcat Web server supplied with the product

For your convenience, all server-side samples are already installed and ready to run under Tomcat. All you have to do is to run the Tomcat Web server.
If you want to rebuild the samples, for example, in the case you changed the source code:
  1. Review the values defined in the file ./build.xml and modify them as required.
    For example, you can specify different source directories or third-party .jar files.
  2. Depending on your system, run the script build.sh (on Linux) or build.bat (on Windows).
    An Ant executable is provided in jviews-framework89\tools\apache-ant-1.7.0. If Ant is in your path, you can also run the ant -f build.xml command-line instruction.
This procedure compiles the source code of the demo and creates a .war file that you can use on the Tomcat Web server supplied with the product.
Note
Because this server uses shared libraries, the shared .jar files are not placed in the .war file.

Building the samples for another Apache Tomcat Web server

If you want to use another Tomcat Web server, you can build a complete .jar file for the sample.
You can proceed in one of two ways:
  • Depending on your system, edit the file build.sh (on Linux) or build.bat (on Windows) replacing the string build with build.complete.
  • If Ant is in your path, run the ant -f build.xml build.complete command-line instruction.
    An Ant executable is provided in jviews-framework89\tools\apache-ant-1.7.0.
Either of these procedures generates a larger .war file that contains all the .jar files necessary to deploy the .war on a standard Tomcat installation, without using shared libraries. For more details about deploying this .war file, refer to your Tomcat user guide.

Running the server-side samples on the Apache Tomcat server supplied with the product

To run the samples on the Tomcat Web server supplied with the product:
  1. Set the JAVA_HOME environment variable to point to your Java Development Kit installation.
  2. Go to the directory containing the Rogue Wave JViews scripts that will copy all the files required by Tomcat and then run Tomcat.
    These scripts are located in:
    • <installdir>/jviews-framework89/tools/tomcat-jsf for Ajax and JSF demos.
  3. Depending on your system, run the start_tomcat.bat or start_tomcat.sh script to start the Tomcat server.
    Note
    • The first time that you start the Tomcat server, it takes some time because it has to copy the samples and install them in the server.
    • If you are running on Windows, you have menu items in the Windows Start menu to start and stop the Tomcat server.
  4. Launch a Web browser to access the demos:
    • For Ajax and JSF demos, access http://localhost:8080.
      You can use the preconfigured Tomcat Manager application to see all the installed Web applications. The default login credentials for Tomcat are username: tomcat password:tomcat
The JavaScript and Ajax samples require one of the browsers listed in Requirements for Rogue Wave JViews TGO. The server-side samples contain a .war file (Web Archive) that you use to install the sample in any compatible Web server.

Running the samples for WebSphere Application Server (WAS)

In addition to the Ant scripts provided for running the samples on Tomcat (see Running the server-side samples on Apache Tomcat), there are a number of scripts to help the deployment of the JViews samples on a WebSphere Application Server. These scripts deploy the samples to the WebSphere Application Server and configure a shared library that includes the Rogue Wave JViews .jar files. You can also use these scripts to start and stop the application server.

Installing and starting the samples for WAS

The function to install and start the sample applications is similar across both the Tomcat script and the WAS script. The following instructions assume that WebSphere Application Server is installed. If it is not installed, complete the installation of WAS before continuing. Refer to the WAS product installation guide for help.
You must also make sure that Ant is in your path. An Ant executable is provided in jviews-framework89\tools\apache-ant-1.7.0.
Building a complete .war file
You can create a .war file that contains the full set of product .jar files, which results in a much larger .war file.
To build and install a complete .war file:
  1. Review the defined values in file ./build_was.properties and modify as required; for example, to specify WAS username and password credentials.
  2. Run the command-line instruction ant -f build_was.xml ws.installapp.complete.
Building a .war file with shared libraries
To recompile the sample application and deploy it to the application server:
  1. Double-check the values in file ./build_was.properties.
  2. Run the command-line instruction ant -f build_was.xml ws.installapp.
This process initializes the environment, including starting the WebSphere Application Server (WAS) if it has not already been started, creates a shared library in the WAS runtime environment, and deploys the sample .war file. On completion of application deployment, the WAS Ant script, build_was.xml, produces a URL You can use this URL to view the sample in a supported Web browser, for example, Internet Explorer or Mozilla Firefox. For supported browsers, see Requirements for Rogue Wave JViews TGO .
The shared library in the WAS references the required product .jar files located in the product installation. In this way, you do not have to copy these files to multiple locations on the same machine.
Auxiliary Ant tasks
Auxiliary tasks offer helpful guidance as to the system configuration, for example:
  • ws.list.ports lists all WAS ports and highlights the one that corresponds to the WebSphere admin console.
  • ws.list.profiles lists all the WAS profiles.
Uninstalling the sample application
To uninstall the sample application:
  • Run the command-line instruction ant -f build_was.xml ws.uninstallapp.
    The sample application is removed from the WebSphere Application Server.

Running the server-side samples on WAS

Launch a Web browser to access the demos:
  • For Ajax and JSF demos, access https://localhost:9443/
    By default, applications are deployed on port 9443 of the WebSphere Application Server. If this port is already in use or if the administrator wants to deploy to another port, you can change it using the Admin Console. Follow the links in the left-side panel to Servers > Server Types > WebSphere Application Servers and select the required server instance from the list of available servers, then select Ports (in the Communications section).
  • To display the list of all installed Web applications or to install other sample applications, access the Admin Console: https://localhost:9043/ibm/console/. By default, the application server starts in secure mode. Access to the Admin Console therefore requires authentication credentials to be specified during the installation or later configuration of WebSphere Application Server. After logging on, follow the links, from the left-side menu, to Applications > Application Types > WebSphere enterprise applications.

Running the server-side samples in a headless environment

The server-side components can run with the headless support that is built into the Java SE. For more information about this feature, refer to the Java SE release notes. If you are not running on Windows, you can also run with a virtual X server like Xvfb (X Virtual Frame Buffer). This solution is described on the Sun website at http://java.sun.com/products/java-media/2D/forDevelopers/java2dfaq.html#xvfb.

Common features of samples

All samples are built on a common base class, AbstractSample. This class provides a number of features that some or all samples share. These features are accessible from the File menu of the menu bar that is present in most samples.
This section explains these features, and gives some information on how to build a sample using the common base class.

Reloading business and style data

Some samples have menu items labeled Reload business objects and Reload styles. If these are present, they allow you to reload the original files.
If you have made any changes to these files since launching the sample, they will become visible. Otherwise, the original state of the sample will be restored.

How to use the AbstractSample class

The AbstractSample class provides support for running the same code both as an applet or as a standalone application. You can find the source code for this class in the file <installdir>/samples/<sampledir>/src/AbstractSample.java, for example in:
<installdir>/samples/network/basic/src/AbstractSample.java
This section explains the usage of the class. You may find this useful if you want to extend one of the samples, or write a new sample from scratch. However, you do not need to know the details of the implementation in order to use or understand the samples.
AbstractSample initializes the application correctly depending on the mode of operation, then calls a virtual method doSample(Container), passing the Java Container to which you should add the GUI components. To know whether a sample is being run as an applet or not, you can call the isApplet() method.
To build a sample that can be run as a standalone application, the user should provide a main method, and call the constructor of the sample, as well as the shared initialization method init(Container).
A basic sample framework looks like this:
public class Main extends AbstractSample {
  public static final String sampleTitle = "My Sample";
  public static final int sampleWidth = 770;
  public static final int sampleHeight = 626;

  /**
   * Execute the main part of the sample.
   */
  protected void doSample (Container container) {
    // Initialize JTGO. Check whether we are in an applet or not
    if (isApplet())
      IltSystem.Init(this);
    else
      IltSystem.Init();
    // Add graphic components, for example:
    container.add(new JButton("Hello Sample!!!"));
  }

  public static void main (String[] args) {
    // Create top level Frame
    JFrame frame = new JFrame("Rogue Wave® JTGO " + sampleTitle);
    // Create sample instance
    Main sample = new Main();
    // Call base class initialization method
    sample.init(frame.getContentPane());
    // Resize the frame and make it visible
    frame.setSize(sampleWidth,sampleHeight);
    frame.setVisible(true);
  }
If you want to use the default menu bar, you should create a constructor like this:
public Main(){
    // Create panel with a menubar
    super(sampleTitle, sampleLoggerName, true);
  }
This example creates the sample with a title and a logger name, and specifies whether the default sample menu bar should be created.
Each sample contains a predefined logger, that is created according to the given logger name. The JViews TGO samples have a logger name based on the distribution hierarchy. For example, the logger name in <installdir>/samples/network/basic is "samples.network.basic".
You can use the newly created logger directly in your sample through the sample attribute "log", as follows:
try {
    dataSource.parse(sampleDataSourceFile);
  } catch(Exception e){
    log.severe("Exception caught while reloading business objects");
    e.printStackTrace();
  }
You can customize the default menu bar by overloading the method populateMenuBar(JMenuBar). This method is called by the base class when the menu bar is constructed.
For example, you could write:
protected void populateMenuBar(JMenuBar menubar) {
    super.populateMenuBar(menubar, true, true);
  }
Here we call another base class method which adds the default actions to reload the business objects and styles.
You can also add your own actions, or remove the predefined ones.
If the default actions to reload the business objects and styles are enabled, you need to overload the virtual methods reloadBusinessObjects and reloadCSSStyles() to provide the desired behavior. These methods might typically look like:
protected void reloadBusinessObjects() {
    dataSource.clear();
    try {
      dataSource.parse(sampleDataSourceFile);
    } catch(Exception e){
      log.severe("Exception caught while reloading business objects");
      e.printStackTrace();
    }
  }

  protected void reloadCSSStyles(){
    String[] css = new String[] {sampleCSSFilename};
    try {
      networkComponent.setStyleSheets(css);
    } catch(Exception e){
      e.printStackTrace();
    }
 }
You can globalize the samples by adding labels, mnemonics and titles to a properties file called resources.SampleMessages.
The contents of this file is available in the sample as a ResourceBundle . To initialize the resource bundle, you need to call the method initContext(IlpContext) just after initializing the JViews TGO application context, as illustrated below:
// ------------------------
       // Initialize JTGO
       // ------------------------
       // Read a deployment descriptor file to initialize JTGO services
       if (isApplet())
         IltSystem.Init(this, "deploy.xml");
       else
         IltSystem.Init("deploy.xml");

       // Initialize the context and resources
       initContext(IltSystem.GetDefaultContext());
Once the resource bundle is initialized, you can access resources from this resource bundle using the method ResourceUtils.getString(String resourceName). For example:
String selStr = ResourceUtils.getString("label.selection.empty");

Common features of Faces samples

Most faces samples are based on the class AbstractSampleContext. This class provides the common features that are needed for the faces samples to operate, initialize, and be easily integrated. This section helps you understand these features.

What is the AbstractSampleContext

The AbstractSampleContext is the abstraction used as a context for the samples. It is abstract because the actual objects that reside in this context are sample-specific. For example, the graphic component that is to be used in a given sample (IlpNetwork or IlpEquipment) is defined at the implementation level by overriding the method AbstractSampleContext.createComponent().
The AbstractSampleContext also ensures that samples have a well-defined approach for initializing themselves. For example, if your sample needs to create custom types, or adjust JViews TGO settings, or create or query resources of some sort, the appropriate approach is to override the method AbstractSampleContext.initializeSample() that is called when the AbstractSampleContext instance is created.

What objects does the AbstractSampleContext provide

In its original form, the AbstractSampleContext provides the IlpContext used in the sample.
In addition, given that most samples are associated with a graphic component (IlpNetwork or IlpEquipment), AbstractSampleContext also hosts a generic IlpGraphicComponent instance. This generic instance can be exposed at the implementation level through a more narrow accessor, like public IlpNetwork getNework() or public IlpEquipment getEquipment().
AbstractSampleContext can provide any object that is of interest. You can create additional bean properties at the implementation level. For example, in the network faces samples, an additional property, network, is created to expose the IlpNetwork.

What services does the AbstractSampleContext provide

The AbstractSampleContext currently provides access to a sample Logger that can be used to log messages of any sort.

How does the AbstractSampleContext get initialized

When AbstractSampleContext is instantiated by the JSF Managed Bean facility, it enforces the following steps in its constructor:
  1. Create the JViews TGO IlpContext implementation used by the sample.
    This is done by calling AbstractSampleContext.createContext(), which by default returns an IltFacesDefaultContext instance.
  2. Initialize the context with the provided deployment file.
    It uses by default a deployment descriptor file that is located in resources/configuration/deployment/deploy.xml. You can override this default setting by using the AbstractSampleContext(String deploymentFile, String loggerName) constructor.
  3. Initialize the Logger of the sample.
  4. Initialize the sample by calling AbstractSampleContext.initializeSample().
  5. Create the graphic component by calling AbstractSampleContext.createComponent().

How can I access the AbstractSampleContext

The samples can access the AbstractSampleContext instance through the JSF Managed Bean facility. The typical name for the managed bean is sampleContext and the default scope is session.
In your JSP™ page, you can access the sample context by using the standard JSF Expression Language syntax. For example, to access the IlpContext bean property of the AbstractSampleContext, you would use this Expression Language fragment: "#{sampleContext.context}".

How do the JViews TGO Faces samples use the AbstractSampleContext

Each JViews TGO Faces sample has a concrete implementation of the AbstractSampleContext, named SampleContext, which implements the protected abstract methods to provide the necessary logic.
The SampleContext also adds bean properties that are needed for each specific sample.
Tip
Check the JViews TGO faces samples for concrete examples of what has been explained in this section.