Ubik Batch Server BAR Format

From UbikWiki

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

(9 intermediate revisions not shown.)

Line 1:

Line 1:

[[Category:Ubik Batch Server]]
[[Category:Ubik Batch Server]]
-
= Console Batch 4.0.0.x and above: User Documentation =
 
-
== What's new ? ==
 
-
The main new feature in version 4.x of console is the multiclassloading management.
 
-
Indeed, as an application server, the batch server can now have several deployed batches using different classloaders (and, of course, different versions of dependencies jars).
 
-
Batches are now gathered in a batch archive, a BAR file, and each BAR has its own classloader.
 
- 
-
With this version, it is possible to :
 
-
* deploy, undeploy or even redeploy a BAR without stopping the console
 
-
* have 2 BARs, each one using a different version of a dependency jar (masterdatas-1.3.jar and masterdatas-1.5.jar for example)
 
-
* have a specific logging configuration file (i.e log.properties or log.xml) for each BAR
 
-
* bind the same logical pool name ("jdbc/masterdatas" for example) to different physical pools (masterdatas1, masterdatas2)
 
-
* bind two logical pool names ("jdbc/appli1" and "jdbc/appli2" for example) to the same physical pool (jdbc/masterdatas)
 
- 
-
== 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 :
 
-
<source lang="java">
 
-
DaoSqlBatchStart starter =
 
-
new DaoSqlBatchStart("jdbc/logicalNameForMasterdatas", "MY SQL QUERY",
 
-
10, false, new String[] { MyDO.class.getName() });
 
-
</source>
 
- 
-
Physical pool name exists in console configuration (i.e in datasource.xml file) : "jdbc/masterdatas1" for example.
 
- 
== What is a BAR ? ==
== What is a BAR ? ==
-
A BAR is a Batch Archive. It is highly similar to a WAR : it contains classes, dependencies jars, a deployment descriptor and a logging configuration file. This is the structure of a BAR file :
+
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)
-
* /classes : contains batches JAVA classes. Even if you do not have classes in your BAR (because they are in a jar), please be sure that this folder exists and is empty.
+
== Structure of a BAR file :==
-
* /lib : contains dependencies jars for batches (masterdatas, webservices, etc).Even if you do not have dependencies jars in your BAR (because you do not need to), please be sure that this folder exists and is empty.
+
* /classes : contains JAVA batches classes. Even if you do not have classes in your BAR (because they are in a jar)
-
* bar.xml : the deployment descriptor file. This file must always be named "bar.xml" and be placed under the root of the BAR file.
+
* /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'''<nowiki>: the logging configuration file. This file must always be placed under the root of the BAR file and referenced in bar.xml in element <</nowiki>logging-file>.
* log.properties or '''log.xml'''<nowiki>: the logging configuration file. This file must always be placed under the root of the BAR file and referenced in bar.xml in element <</nowiki>logging-file>.
-
Note : this structure should always be respected. Otherwise, your BAR will not be considered as a valid one and the console will refuse it at deployment time.
+
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 ==
== The bar.xml file ==

Line 41:

Line 23:

<!DOCTYPE bar-configuration PUBLIC "-//Ubik-Ingenierie //DTD BAR Configuration 1.0//EN" "http://www.ubik-ingenierie.com/consolebatch/config/bar.dtd">
<!DOCTYPE bar-configuration PUBLIC "-//Ubik-Ingenierie //DTD BAR Configuration 1.0//EN" "http://www.ubik-ingenierie.com/consolebatch/config/bar.dtd">
<bar-configuration>
<bar-configuration>
-
<!-- The display-name must be unique for all bars deployed in the console server.
+
<!-- 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.
It is recommanded that display-name is the same as the BAR file name for better convenience.
Display-name must be unique
Display-name must be unique

Line 83:

Line 65:

|-
|-
| display-name
| 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 console. As BARs files should also be unique in the same console, giving to this value the BAR file name can be a good way to ensure the unicity.
+
| 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.
|-
|-

Line 107:

Line 89:

|-
|-
| bar-resource
| 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 console.You do not need to precise which console 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..
+
| 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..
|-
|-

Line 126:

Line 108:

* 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.
* 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'''
* '''Batch names must not contain a "." in their name'''
-
* You cannot have TWO BARs that have a same batch. Console does not manage duplicate batches.
+
* 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.
* 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 console ones, like hibernate for example, you must use the same version as the console one (refer to the classloading part for more informations).
+
* 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.
* 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.
-
== Classloading ==
+
== What is the difference between logical pool name and physical pool name ? ==
-
Like many server applications, the new version of console 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 console 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 :
+
Logical pool name is the JNDI Context name that is written in your batch code :
-
 
+
<source lang="java">
-
 
+
DaoSqlBatchStart starter =
-
Bootstrap
+
new DaoSqlBatchStart("jdbc/logicalNameForMasterdatas", "MY SQL QUERY",
-
+
10, false, new String[] { MyDO.class.getName() });
-
|
+
-
+
-
Console-commons
+
-
+
-
| | ... |
+
-
+
-
BAR1 BAR2....BARn
+
-
+
-
 
+
-
As indicated in the diagram above, console 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).
+
-
* Console-commons : This class loader is normally initialized from the contents of the CLASSPATH environment variable. All such classes are visible to both console internal classes, and to BARs.
+
-
* BARx : A class loader is created for each BAR that is deployed console. 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 diverges 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 console 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
+
-
* Console-commons (that contains all jar dependencies such as log4j, mx4j, etc.)
+
-
 
+
-
List of console dependencies that cannot be embedded in your BAR in another version:
+
-
* '''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)
+
-
 
+
-
== Configuration Changes ==
+
-
=== BAR Upload setup ===
+
-
Batch Server now runs a specific Upload Server that can receive BAR installation requests.
+
-
To setup this server (WHICH IS MANDATORY), configure 2 additional options in <INSTALL_DIR>/config/config.properties:
+
-
<source lang="text">
+
-
# Folder that will contain BARs transfered from Batch Web Controller
+
-
# This folder must only be used by this server and it must be writable
+
-
BAR_UPLOAD_DIRECTORY=@BAR_UPLOAD_DIRECTORY@
+
-
# Port on which the Batch server listens for BARs upload
+
-
BAR_UPLOAD_LISTEN_PORT=@BAR_TRANSFER_PORT@
+
</source>
</source>
-
=== Logs configuration ===
+
Physical pool name exists in batch server configuration (i.e in datasource.xml file) : "jdbc/masterdatas1" for example.
-
Each BAR can have its own logging configuration. Each BAR must have a logging configuration file, even if it is empty. It replaces the old application-logging.properties file. It is a Log4J configuration file.
+
-
 
+
-
=== config.properties file ===
+
-
You have to specify the value of the INSTALL_DIR property. It is the full path to the directory where the console is installed ("C:/DDN/sources/workspace/console" for example).
+
-
 
+
-
 
+
-
 
+
-
=== JVM Properties ===
+
-
The server now REQUIRES a JDK 5.
+
-
 
+
-
Ensure the following JVM properties are set :
+
-
<source lang="text">
+
-
-XX:MaxPermSize=128m -DLOG_ROOT_PATH=<Path to log folder>
+
-
</source>
+
== Authors ==
== Authors ==
* David Dégardin
* David Dégardin
* Philippe Mouawad
* Philippe Mouawad
- 
-
== History ==
 
-
<pageby/>
 

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