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
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).
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:
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
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
com.foo.logic.CustomerLogic, then you would have the following option:
logicPackageNames = com.foo.logic
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.
option allows you to completely take over the finding of business logic classes. See the Javadoc
You can also use dynamically reloadable logic classes. See the Dynamic Logic page
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
class (see the Connecting page
). When you do, you will also need to specify the third-party class using the
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
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.
The event listener service
and the transaction summary service
are described in their own pages.
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 = com.acme.foo.SpecialExceptionFactory
A common pattern is to handle
ConstraintExceptions in a way that's appropriate for your framework or environment.