A context in Coinjema is essentially a collection of tiny configuration scripts and a cache of dependency objects created from those scripts for your Java classes. Contexts are hierarchical, with single inheritance. A file directory structure is structurally similar to a hierarchy of Coinjema contexts.
Currently, Coinjema currently has a directory-based implementation and a JDBC-based implementation (URL based implementation is also on my wish-list). ContextSource defines a simple interface that Coinjema uses to retrieve configuration information from a data repository. Other implementations could be written to allow configuration data to be stored on a website, in LDAP, etc.
If we assume a file-based context source, configuring your app with Coinjema consists of writing multiple small (eg Groovy) scripts, each one responsible for creating a single dependency object. Coinjema will find your script and correctly apply it based on the name of that script, which must match the classnames involved and/or custom values passed to the @CoinjemaDependency Annotation.
An example Groovy script that creates Logger objects for your objects' @CoinjemaDependency(alias="logger") setLogger(Logger l) method. The script is named "Logger.groovy".
As specified in Script Variables, "obj" is a variable passed into the parameterized script refers to the object that is being dependency-fulfilled. You can also see how simple Groovy scripts are to use for this - the Logger object returned from the getLogger() method is assumed to be the returned value of the script.
Contexts inherit from their parent contexts - so if the above script didn't exist in the current context, then Coinjema would search the parent for a script of the same name, until one was found. So it is easy to create many customized contexts for your application without having to duplicate a lot of configuration data.
With the new
@CoinjemaContextTrack Annotation Coinjema can track
the current context through your code's call graph. This
means that if you create a new object and put it in a new context, objects
subsequently created within your new object will automatically be part of the
same context - ie:
If you create your object with this constructor (it is optional), Coinjema will put it into the "altConfig" context - and look for configuration data in that context.
Any calls this new object makes will be from within the "altConfig" context, thus any new objects created by your new MyObject will also be in the "altConfig" context. Furthermore, if, from within a call stack originating in this MyObject instance, a new object is created with a specified context, Coinjema will search for the new context starting relative from the current context. Thus, if a new object is created in the "secondConfig" context, Coinjema will first search for a context called "altConfig/secondConfig". If it doesn't find it, then it will look for a context called just "secondConfig".
To summarize: Context is preserved within a call stack until you change it. When you change it, Coinjema tries to find the new context as a relative path to the new context. For more details, see CoinjemaContextTrack annotation.