Reference‎ > ‎

Installation: Configuring

The options for the ABL engine are set in a file named, which is loaded from the classpath. If you do not require any options from this file, then the file itself is optional. By default, all settings are optional.

The various options are explained in the file itself, but there may be a better explanation here.

Finding logic classes

The persistentPackageNames option can list one or more (comma-separated) Java packages that contain the Hibernate persistent beans. This allows the engine (during dependency analysis) to distinguish between calls to outside classes vs. calls to persistent beans. This is not required if all your persistent beans are in the same package. If, however, all your persistent beans are not in the same package, then you must list all packages containing persistent beans here (comma-separated).

The logicClassSuffix option allows you to change the default name extension for logic classes. Normally, the logic class for Customer would be CustomerLogic. If you prefer, say, CustomerRules, then you could make this option:

logicClassSuffix = Rules

The logicPackageNames option can list the Java packages that contain the business logic classes. This is useful if, for some reason, you cannot (or choose not to) follow the normal package naming convention. In this case, the logic objects will be looked for in the (comma-separated) list of packages provided in this option. The matching between persistent beans and logic classes will be named on the name of the persistent bean without its package.

For instance, let's assume that you have a persistent bean class
If you followed the usual package naming convention, you would have the business logic for that object in a class com.acme.businesslogic.CustomerLogic.
If that arrangement does not suit you, and you want to keep your logic classes in some other package, then you could use the logicPackageNames option to list that package. In our example, if your logic class was called, then you would have the following option:
logicPackageNames =

Notice that, if you had more than one persistent bean named Customer (in different packages, of course), this arrangement would not work (unless you wanted to use the same logic class for all the persistent beans named Customer, which would be unusual). In that case, you would need to use a business logic factory.

The businessLogicFactory option allows you to completely take over the finding of business logic classes. See the Javadoc for details.

You can also use dynamically reloadable logic classes. See the Dynamic Logic page for details.

Session settings

In order to activate the ABL engine, you will normally use one of the current session context classes provided by ABL. But what if some other piece of software (such as the Spring framework) also requires that its current session context class be installed in Hibernate?

In that case, you will use the CurrentSessionContextProxy class (see the Connecting page). When you do, you will also need to specify the third-party class using the currentSessionContextClass option. ABL's CurrentSessionContextProxy class will do whatever it does, but still forward all other things to the class specified using this option.

So if you were using Spring, you'd have the following option:
currentSessionContextClass = org.springframework.orm.hibernate3.SpringSessionContext

Logic execution

If a formula is defined with an expression, as opposed to with Java or Groovy code, by default the body of the method will be invoked anyway every time the formula is executed. This can be useful for debugging purposes. If you'd prefer to turn this feature off, you can use:

invokeFormulaMethods = false

By default, circular dependencies in the business logic will cause an exception to be thrown. In some cases, you may wish to override this, for instance if your logic is recursive on purpose. You can do this with the following setting:

circularDependenciesAllowed = true

When this is set, if circular dependencies are detected, they will be logged, but will not stop execution.

Listener services

The event listener service and the transaction summary service are described in their own pages.

Handling exceptions

In some circumstances, you may want to handle how exceptions are thrown by the engine. This is not unusual for certain frameworks, which may expect only certain exceptions types. All exception throwing is done by an implementation of the ExceptionFactory interface. If you create your own implementation, you can specify its name for the exceptionFactoryClass option, e.g.:

exceptionFactoryClass =

A common pattern is to handle ConstraintExceptions in a way that's appropriate for your framework or environment.