Gaderian is specifically targetted for J2EE: deployment in a WAR or EAR, particularly as part of a Tapestry application. Of course, J2EE is not a requirement, and Gaderian is quite useful even in a simple, standalone environment.
In the world of J2EE, multi-threading is always an issue. Gaderian services are usually singletons, and must be prepared to operate in a multi-threaded environment. That means services should not have any specific state, much like a servlet.
Gaderian expects that initially, work will progress in a single startup thread. This is the early state, the construction state, where the module deployment descriptors are located and parsed, and the contents used to assemble the registry; this is the domain of RegistryBuilder .
The construction activities are not thread-safe. This includes the parser, and other code (virtually all of which is hidden from your application).
The construction state ends when the RegistryBuilder
returns the Registry from method constructRegistry().
The registry is thread-safe.
Everything that occurs with the Registry and modules must be thread-safe. Key methods are always synchronized. In particular, the methods that construct a service and construct configuration point elements are thread-safe. Operations such as building the interceptor stack, instantiating core service implementations, and converting XML to Java objects operate in a thread-safe manner. However, different threads may be building different services simultaneously. This means that, for example, an interceptor service implementation must still be thread-safe, since it may be called upon to generate interceptors for two or more different services simultaneously.
On the other hand, the Java objects constructed from XML <rules> don't need to be thread-safe, since that construction is synchronized properly ... only a single thread will be converting XML to Java objects for any single configuration point.
When services simply must maintain state between method invocations, there are several good options: