Application Bundling

*.jar

For the purpose of using canvas binaries within your application, you need to include the canvas binaries (JARs) within your application. Based on the nature of deployment, this could mean one of the following approaches being taken:

• Copy the JARs into the WEB-INF/lib folder of your WAR file
• Copy the JARs into the META-INF/lib folder of your EAR file
• Copy the JARs along with other Third Party JARs into a shared library / user library that is referenced through the Application server specific deployment descriptor.

Irrespective of the nature of bundling chosen, Canvas makes itself available as a collection of small independent units as well as a collated (all-in-one) JAR. If the approach is to include the all-in-one JAR, then the following items needs to be included:

• CTFull.jar
• CTEJBs.jar
• CTResources.jar

If the approach is to include individual modules, then all the JARs from the canvas folder except CTFull.jar needs to be included.

Canvas uses a collection of third party applications as reusable blocks (JARs) for enabling various features. Not all these components are needed for every application. Details of the optional JARs in the dependency bundle are as follows:

• The following libraries are used for providing App Export and Information Reporting modules. The following JARs can be ignored if these both features are not used:
  
  • batik*.jar
  • fop-1.1.jar
  • iText-2.0.8.jar
  • itextpdf-5.4.4.jar
  • javacsv2.0.jar
  • poi-3.9.jar
  • rendersnake-1.7.2.jar
  • shani-parser-v1.4.17.jar
• The following JARs contain the JDBC drivers for DB2 database. These JARs can be ignored if DB2 is not used:
  
  • db2jcc_license_cisuz.jar
  • db2jcc4.jar
    
    
• The following JARs are part of the Jersey library and used for consumption of REST services. If the application does not use REST services, or implements its own manner of consuming REST services, then these JARs can be ignored:
  
  • jersey*.jar
    
    
• The following JAR contains the JDBC drivers for MySQL database. If MySQL is not used, the following JAR can be ignored:
  
  • mysql-connector-java-5.1.38-bin.jar
    
    
• The following JAR contains the JDBC drivers for Oracle database. If Oracle is not used, the following JAR can be ignored:
  
  • ojdbc6.jar
    
    
• The following JAR contains the JDBC drivers for Microsoft SQL database. If Microsoft SQL is not used, the following JAR can be ignored:
  
  • sqljdbc4-3.0.jar
    
    
• The following JARs are for logging-related modules. Many of the application servers look to bootstrap the logging libraries or load it automatically from their distribution which results in Class loading / assignment errors. In such scenarios, try removing these JARs from within your WAR / EAR file to see if the problem resolves:
  
  • slf4j-api-1.6.1.jar
  • log4j-1.2.14.jar
  • slf4j-log4j12-1.6.1.jar
    
    
• The following JARs are related to XML based processing. Similar to Logging, one of the most impacted items that results in lot of unrelated XML processing errors in the application for no reason. If such errors are faced, try removing these JARs in the same order as provided here to see if the problem resolves:
  
  • xercesImpl-2.7.1.jar
  • xml-apis*.jar

*.zip

This package contains all the UI assets (JSP, JS, CSS, Images, HTML) that are provided as a default package for the end application. It is expected that this package gets extracted into the Root of your WAR file. Once extracted, the following folder structure must be visible within your WAR file:

<WAR file root>
           CTRIAFramework
                   javascript
                   jsp
                   UIArena
                   UITemplates

As a typical manner of storage, it is expected that the end application does not store the individual assets provided in the ZIP file. Instead, the entire ZIP file is expected to be stored like a third party JAR and expanded to the root of the WAR file as a build activity. This allows for easier update when any subsequent patches / enhancements are released.