The datatoolsshared.jar has the following dependencies which are provided and installed with the console:
IBM Java Runtime Environment 5.0 or higher
It also depends on the following jars:
Spring 2.0: list the jar file names here as well as the corresponding minimal property files
Commons Logging 1.1: list the jar file names here as well as the corresponding minimal property files
Commons Configuration 1.4: list the jar file names here as well as the corresponding minimal property files
Derby 10.2: list the jar file names here as well as the corresponding minimal property files
Servlet 2.4: list the jar file names here as well as the corresponding minimal property files
JavaMail 1.1: list the jar file names here as well as the corresponding minimal property files
Properties files: datatoolsconsole.properties
The datatoolsshared.jar provides shared classes and interfaces for portlets and Web services in the console as well as stand-alone Java applications that are used to manage the console installation. Portlet developers who want to develop their own console modules are not required to use any of the functions provided by the shared jar. However to ensure a consistent user experience and enable easy integration into the console installer package, portlet developers are strongly encouraged to use this API. Not all public classes of the API should be used independently. For example, some classes in the messenger package implement the back-end service for the common JavaScript console messenger widget. Portlet developers should primarily use the JavaScript widget to interact with the console messenger. The documentation will indicate if a class should not be used independently.
The API provides the following packages:
cache | Provides classes to use the cache service provided by the console. |
connection | Provides classes to manage and obtain connections to IBM and non-IBM data servers. |
logging | Provides classes to intercept all uncaught middle tier Java exceptions and to post logs to the console logging Web service. |
Provides classes to send e-mail through an SMTP server. | |
messenger | Provides classes that implement the back-end service for the console messenger. |
net | Provides classes for the installer to get the port and IP address information. |
persistence | Provides classes to access and manage the configuration database. |
security | Provides classes for password and data encryption as well as JavaScript encoding and decoding functions. |
util | Provides classes to manage system and user preferences, to get string representation of a property list, to manage universally unique identifiers (UUIDs), to obtain version and product level information, as well as to provide encoding functions for XML. |
The documentation for each class or interface contains usage examples.
AOP: Aspect-Oriented Programming
Cache Service: A composite cache providing cache chunks for different components to use.
CSV: Comma-Separated Value
DAO: Data Access Object
DDL: Data Definition Language
Derby: A Java based, open source database management system
I18N: Internationalization
JCS: Java Caching System
JDBC: Java DataBase Connectivity
POJO: Pure Object/Java Object
REST-Style: Representation State Transfer-Style
SMTP: Simple Mail Transfer Protocol
Spring: A light-weighted J2EE application framework
UUID: Universally Unique IDentifier
WSDL: Web Service Description Language
Answer: The shared API is owned by the infrastructure team. Send a note to DSAC-Scrum-Feng with your request. After a team review and approval from the architect, the class or interface will be added.
Question: How are changes to the shared API managed?
Answer: All changes to the shared API will be incremental following a version (1.0.0.0, 2.0.0.0, and so forth) to avoid causing regression. New or overloaded classes or interfaces can be added in a fix, modification, or release as well.
Question: How are code changes to the shared API communicated?
Answer: If a code change to a shared class becomes necessary after a release is shipped, a notification will be sent to all developers to review and test the code change to avoid regression. Ensure that you are on the DSAC-Developers mailing list.
Question: Do I have to use the shared API to store configuration data?
Answer: It is highly recommended that you only persist data from a portlet or Java application through the shared API to facilitate install upgrades and reconfiguration. For instance, if you write to your own properties file, create your own Derby or Cloudscape database. The installer will not preserve that data.
/html>