Guide‎ > ‎



After installing, edit the indicated files to configure your project to use Automated Business Logic.

Project Structure

Automated Business Logic places no constraints on how you structure your project.  We recommend following Java/Groovy/Grails guidelines, as appropriate.  See, for example, how BusLogicIntro is structured.

Link to abl project

To facilitate support, we recommend (but don't require) that you include ABL (created from the download installation) as a linked project, and utilize the jar files located inside it.  Note most IDEs do not require you to physically copy the ABL files to include them in a new workspace.

If you use Maven, however, you will most likely want to use that instead.

You may also need to alter your Project > Properties > Deployment Assembly to make these jars available for your web application.

Hibernate Config

As explained in the Architecture, Business Logic executes as a listener for Hibernate events. You must therefore configure Hibernate to invoke the Business Logic listener.

Hibernate provides hibernate.cfg.xml to specify values for various Hibernate configuration options (specified by properties), and a list of the Domain Objects to be managed, including their locations.  You can name this file as you wish (see buslogicdemo.cfg.xml in the example above), so long as you specify it when you create the session factory.

Business Logic requires that you register the Business Logic runtime, by specifying the following 

<property name="hibernate.current_session_context_class">

See the reference documentation for details about this.

For example, the BusLogicDemo and BusLogicIntro sample projects contain jUnit tests whose setup() function opens the session factory by calling the routine shown below (caution - use of static is appropriate for simple testing, not multi-user production systems):

For more information, see here.

The following are optional.


Place the file in your classpath to specify options. You can obtain a copy of this from the BusLogicIntro project. The sections below explore some of the key settings. Please see the properties file for all the settings and their meanings.


This property is required if all your Business Logic Components are not in the same package as your Domain Objects. For example, here is the setting for BusLogicIntro:

logicPackageNames =,buslogicintro.businesslogic.orderentry...


This setting controls system behavior when your application attempts to directly alter sum/count attributes. This is normally considered an application error, since it indicates that extra work is being undertaken, perhaps indicating that some team members are not aware the Automated Business Logic is being used.

Another scenario in which this might occur is migrating an existing application to Business Logic. It is convenient to configure the system to ignore application code attempts to update such values since they will be corrected (even if incorrect), and this means you don't have to remove this code for migration. This enables you to build new logic in a declarative manner, without undertaking the effort to alter existing code.

Logic Finder

This property provides detail control over associating Logic Classes with Domain Objects.  Typical uses include:
  • Class Name differs from Entity Name
In the example shown below, the Hibernate/JPA entity Name does not match the Domain Objects' class name, so the Logic Finder remaps it as shown
  • Logic Extensions
Often in extending packaged software, sites can customize the logic by extending vendor classes:

public class OrderCustomizedLogic extends vendor.OrderLogic {...

In such cases, you can instruct the system to search first for the extension class, then for the vendor class.

Below is an example of a Logic Finder.

While the example above uses the ABL getLogicClassForBeanName, you can load the class yourself.  Be aware you may need to deal with class loader issues.

You can find more information here.


This properties file enables you to configure how much logging is generated.  Granularity is provided at the sub system level (e.g., event listener framework vs. rules engine).  

This file is optional, in which case typical development settings are used so you can see each rule that fires.  You will want to alter this appropriately for production.

Connection Pool 

We recommend following Hibernate guidelines for connection pooling. Hibernate's documentation recommends deferral to the app server whenever possible, since they presumably know best how to do connection pooling in their own environment. So in Websphere, Tomcat, etc... just use a JNDI data source and let the container do its magic.