One interesting feature of EL4J are modules. They allow to split an application in smaller pieces. EL4J itself also uses modules to split its features in more handy chunks. A module is similar to an eclipse plugin or to a maven project (in fact, an EL4J module is both mapped to an eclipse plugin and a maven module).
A module in EL4J contains (1) code, (2) predefined configuration and (3) dependencies. You can make dependencies on other modules or on jar files. When a module m1 uses another module m2, the module m1 has acces to all the content (code, config and dependencies) of module m2. This works transitively, i.e. if m2 depends on a module m3, m1 has also access to m2.
Sample use: Adding simple performance tracking
Why are modules useful? Let's assume you have an application with the module app. If you want to setup the performance interceptor to automatically time the duration of all calls to certain spring beans, you just make a dependency from your application to the module "light-statistics". From then on, you can access performance information via JMX.
Under the hood, the module light-statistics sets up the JAMON performance interceptor, adds it by default to all spring beans (you can override this) and makes the information available in JMX. No need to configure anything or know more about the working of the module light statistics. By default, all is setup for you.
In case you are not happy with the default, you can change anything. But simple things are simple to set up.
Here's a sample setup of modules:
In your applications, you make a dependency on all EL4J modules you need (above the module YourApplication needs the modules Security and WebTools. In this way, you automatically setup the things that are tedious to set up: jar-dependencies and the default configuration.
Are you afraid that EL4J loads configuration "magically"? You don't have to use this feature, we just recommend it for simplicity. For your application context, you specify the place from where configuration should be loaded from (as always in spring). By convention, we put configuration we recommend to always use for a given module in a directory called mandatory. The location we recommend to add to the list of locations to load configurations from is "classpath*:mandatory/*.xml". Spring then includes all the default configuration automatically. You also have the possibility to exclude a location in case you do not need it.
