Ubik Batch Server BAR Format

From UbikWiki

(Difference between revisions)
(Configuration Changes)
Current revision (19:14, 1 May 2009) (edit) (undo)
(What is the difference between logical pool name and physical pool name ?)
 

(One intermediate revision not shown.)

Line 122:

Line 122:

Physical pool name exists in batch server configuration (i.e in datasource.xml file) : "jdbc/masterdatas1" for example.
Physical pool name exists in batch server configuration (i.e in datasource.xml file) : "jdbc/masterdatas1" for example.
- 
- 
-
== Classloading ==
 
-
Like many server applications, the new version of batch server installs a variety of class loaders (that is, classes that implement java.lang.ClassLoader) to allow different portions of the container to have access to different repositories of available classes and resources.In a Java environment, class loaders are arranged in a parent-child tree. Normally, when a class loader is asked to load a particular class or resource, it delegates the request to a parent class loader first, and then looks in its own repositories only if the parent class loader(s) cannot find the requested class or resource. The model for BAR class loaders differs slightly from this, as discussed below, but the main principles are the same.When batch server is started, it creates a set of class loaders that are organized into the following parent-child relationships, where the parent class loader is above the child class loader :
 
- 
- 
-
Bootstrap
 
-
 
-
|
 
-
 
-
batch-server-commons
 
-
 
-
| | ... |
 
-
 
-
BAR1 BAR2....BARn
 
-
 
- 
-
As indicated in the diagram above, batch server creates the following class loaders as it is initialized :
 
- 
-
* Bootstrap : This class loader contains the basic runtime classes provided by the Java Virtual Machine, plus any classes from JAR files present in the System Extensions directory ($JAVA_HOME/jre/lib/ext).
 
-
* batch-server-commons : This class loader is normally initialized from the contents of the CLASSPATH environment variable. All such classes are visible to both batch server internal classes, and to BARs.
 
-
* BARx : A class loader is created for each BAR that is deployed batch server. All unpacked classes and resources in the /classes directory of your BAR, plus classes and resources in JAR files under the /lib directory are made visible to the containing BAR, but to no others.
 
- 
-
As mentioned above, the BAR class loader differs from the default Java 2 delegation model : when a request to load a class from BARx class loader is processed, this class loader will look in the local repositories first, instead of delegating before looking.There are exceptions : classes which are part of the JRE base classes cannot be overriden.All other class loaders in batch server follow the usual delegation pattern.
 
- 
- 
-
Therefore, from the perspective of a BAR, class or resource loading looks in the following repositories, in this order :
 
-
* Bootstrap classes of your JVM
 
-
* /classes of your BAR
 
-
* /lib/*.jar of your BAR
 
-
* batch-server-commons (that contains all jar dependencies such as log4j, mx4j, etc.)
 
- 
-
List of batch server dependencies:
 
-
* '''activation-1.1.1.jar''' (UPGRADE)
 
-
* antlr-2.7.6.jar
 
-
* asm-1.5.3.jar
 
-
* asm-attrs-1.5.3.jar
 
-
* bcel-5.1.jar
 
-
* '''bcprov-jdk14-138.jar''' (UPGRADE)
 
-
* cglib-2.1.3.jar
 
-
* commons-beanutils-1.7.0.jar
 
-
* commons-codec-1.3.jar
 
-
* commons-collections-3.2.jar
 
-
* commons-dbcp-1.2.1.jar
 
-
* commons-digester-1.8.jar
 
-
* '''commons-lang-2.4.jar''' (UPGRADE)
 
-
* '''commons-logging-1.1.jar''' (UPGRADE)
 
-
* commons-mail-1.0.jar
 
-
* commons-modeler-2.0.jar
 
-
* commons-pool-1.2.jar
 
-
* concurrent-1.3.4.jar
 
-
* dom4j-1.6.1.jar
 
-
* ehcache-1.3.0.jar
 
-
* ejb-2.0.jar
 
-
* fwk-do-substract-1.0.0.jar
 
-
* '''geronimo-j2ee-connector_1.5_spec-1.0.jar''' (NEW)
 
-
* '''geronimo-j2ee-management_1.0_spec-1.0.jar''' (NEW)
 
-
* '''hibernate-3.2.6.jar''' (UPGRADE)
 
-
* ibatis-common-2-2.0.jar
 
-
* ibatis-dao-2-2.0.jar
 
-
* ibatis-sqlmap-2-2.0.jar
 
-
* jaas-1.0.jar
 
-
* jaxen-1.1-beta-7.jar
 
-
* '''jms-1.1.jar''' (NEW)
 
-
* jmxremote-1.0.jar
 
-
* jmxri-1.2.1.jar
 
-
* jta-1.0.1.jar
 
-
* '''log4j-1.2.15.jar''' (UPGRADE)
 
-
* '''mail-1.4.1.jar''' (UPGRADE)
 
-
* '''mx4j-tools-3.0.2.jar''' (UPGRADE)
 
-
* naming-common-1.1.jar
 
-
* naming-factory-1.1.jar
 
-
* naming-resources-1.1.jar
 
-
* quartz-1.5.2.jar
 
-
* quickserver-1.4.7.jar
 
-
* servletapi-2.3.jar
 
-
* '''ubik-batch-server-jms-5.0.1.0.jar''' (NEW)
 
-
* '''ubik-console-5.0.1.0.jar''' (UPGRADE)
 
-
* '''ubik-console-config-5.0.1.0.jar''' (UPGRADE)
 
-
* '''ubik-console-logging-5.0.1.0.jar''' (UPGRADE)
 
-
* '''ubik-console-persister.1.0.2.jar''' (UPGRADE)
 
-
* '''ubik-console-shared-data-5.0.1.0.jar''' (UPGRADE)
 
-
* '''ubik-console-transfer-5.0.1.0.jar''' (UPGRADE)
 
-
* ubik-fwk-1.0.jar
 
-
* velocity-1.4.jar
 
-
* '''xerces-resolver-2.8.1.jar''' (NEW)
 
-
* '''xercesImpl-2.8.1.jar''' (UPGRADE)
 
-
* '''xml-apis-1.3.03.jar''' (UPGRADE)
 
- 
- 
== Authors ==
== Authors ==
* David Dégardin
* David Dégardin
* Philippe Mouawad
* Philippe Mouawad

Current revision

Contents

What is a BAR ?

A BAR is a Batch Archive. It is highly similar to a WAR, it contains:

  • Batch Classes
  • Their JAR dependencies
  • a deployment descriptor (bar.xml)
  • a logging configuration file (log4j)

Structure of a BAR file :

  • /classes : contains JAVA batches classes. Even if you do not have classes in your BAR (because they are in a jar)
  • /lib : contains jars dependencies for batches.Even if you do not have dependencies jars in your BAR (because you do not need to)
  • bar.xml : the deployment descriptor file. This file must always be named "bar.xml" and be placed under the root of the BAR file
  • log.properties or log.xml: the logging configuration file. This file must always be placed under the root of the BAR file and referenced in bar.xml in element <logging-file>.

Note : this structure should always be respected. Otherwise, your BAR will not be considered as a valid one and the batch server will refuse it at deployment time.

The bar.xml file

This file is the deployment descriptor file. It helps you to configure your BAR.

Empty bar.xml file sample :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE bar-configuration PUBLIC "-//Ubik-Ingenierie //DTD BAR Configuration 1.0//EN" "http://www.ubik-ingenierie.com/consolebatch/config/bar.dtd">
<bar-configuration>
<!-- The display-name must be unique for all bars deployed in the batch server. 
It is recommanded that display-name is the same as the BAR file name for better convenience. 
Display-name must be unique
-->
<display-name>UNIQUE_PROJECT_NAME_FOR_EXAMPLE</display-name>
<!-- Groups of batches -->
<groups>
<group name="GROUP_NAME">
<batches>
<batch-classname>FULL_QUALIFIED_NAME_OF_THE_BATCH_CLASS</batch-classname>
<batch-classname>FULL_QUALIFIED_NAME_OF_THE_BATCH_CLASS2</batch-classname>
</batches>
</group>
<group name="GROUP_NAME2">
<batches>
<batch-classname>FULL_QUALIFIED_NAME_OF_THE_BATCH_CLASS3</batch-classname>
<batch-classname>FULL_QUALIFIED_NAME_OF_THE_BATCH_CLASS4</batch-classname>
</batches>
</group>
</groups>
<!-- Resources -->
<bar-resources>
<bar-resource name="jdbc/console" type="javax.sql.DataSource" />
<bar-resource name="LOGICAL_POOL_NAME" type="javax.sql.DataSource" />
</bar-resources>
<!-- Log4J Configuration -->
<logging-file>LOGGING_CONFIGURATION_FILE_NAME</logging-file>
<!-- Classes to execute when BarLoader is created -->
<plugin>
<plugin-class>FULL_QUALIFIED_NAME_OF_THE_PLUGIN_CLASS</plugin-class>
</plugin>
</bar-configuration>

Description of bar.xml elements :


Element name
Description
display-name It can be considered as the unique ID of a BAR. The value should be unique for all BARs deployed in the same batch server. As BARs files should also be unique in the same batch server, giving to this value the BAR file name can be a good way to ensure the unicity.
groups A BAR can contain batches of different groups. Child elements of this one are GROUP elements.
group The value is the name of the group of batches. Batches are gathered in groups. For a group, you can have several batches. Child element of this one is the BATCHES element.
batches Child elements of this one are BATCH-CLASSNAME.
batch-classname The value is the full-qualified name (i.e with the package name) of the batch class.
bar-resources It contains a list of BAR-RESOURCE elements
bar-resource Resources are javax.sql.DataSource ones (attribute value), javax.jms.ConnectionFactory, javax.jms.Queue or javax.jms.Topic .Resources you put in this file are logical names for resource(i.e the JNDI Context name that is written in your batch code) and must be bound to a physical resource that exists in batch server.You do not need to precise which batch server pool will be chosen in the bar.xml file but do not forget to add all used pools to this list, otherwise batch will not work (it will not be able to connect to database because binding is not done and logical name is unknown for the BAR).Note that "jdbc/console" will be automatically bound to the physical console pool by default. Even if you do not have resources to bind, please leave this line..
logging-file The value must be the name of the logging configuration file for your BAR that must be placed to the root of your BAR.
plugin It contains a list of PLUGIN-CLASS elements
plugin-class The value of this element must be the full-qualified name of a class placed in your BAR that implements Iplugin interface. When creating the classloader for your BAR, init() method of this class will be called. When destroying the classloader, destroy() method will be called.Note that classes that you put in this list MUST implements IPlugin interface, otherwise a TechnicalException will be thrown when deploying your BAR.

Constraints

  • You cannot have TWO BARs that have batches for the same group. If it is the case, you should put all these batches in the same BAR.
  • Batch names must not contain a "." in their name
  • You cannot have TWO BARs that have a same batch. Batch server does not manage duplicate batches.
  • You cannot have a "registering" batch that call registerAsBatch methods of other batches. Otherwise these batches will be unknown in the BAR. Indeed, only batches that are described in the bar.xml file are added to the BAR classloader. You will get a ClassNotFoundException when registerAsBatch methods for these unknown batches are called.
  • If your BAR uses same dependencies jars as the batch server ones, like hibernate for example, you must use the same version as the batch server one (refer to the classloading part for more informations).
  • When updating a jndiConnection for a batch/launch with MC4J, be careful and only use logical names. Indeed, them and only them are bound to physical pools. Putting a physical name will lead you to NamingException because the name will not be found in JNDI context of the BAR this batch belongs to.

What is the difference between logical pool name and physical pool name ?

Logical pool name is the JNDI Context name that is written in your batch code :

DaoSqlBatchStart starter = 
     new DaoSqlBatchStart("jdbc/logicalNameForMasterdatas", "MY SQL QUERY", 
          10, false, new String[] { MyDO.class.getName() });

Physical pool name exists in batch server configuration (i.e in datasource.xml file) : "jdbc/masterdatas1" for example.

Authors

  • David Dégardin
  • Philippe Mouawad
Personal tools