You are probably using Internet Explorer which doesn't understand the "fixed" value for position. Try switching to a good browser.

Your ant-home/lib directory has to have the aspectjtools.jar in it. Then, put the following line somewhere near the beginning of your build file:

<iajc sourceRootsRef="sources" classpathRef="classpath" 
   	  	destdir="${build.classes.dir}" 
		aspectPath="lib/coinjema-core-0.5.jar"/>
		

You probably didn't use iajc to compile the code - your classes were never weaved with Coinjema's aspects. If you use Ant, you'll have to update your build file to use iajc instead of javac. If you use Eclipse, you can install the ajdt plugin and make your project an aspect project.

Hopefully you have some configuration data you need to hand off to some object in your system. Find an object that you want to inject some dependencies. Annotate the class with @CoinjemaObject. If the dependency object you have in mind to inject doesn't have a setter, create one for it and annotate the setter method with @CoinjemaDependency.

Now, when you call new MyObject() on this class, Coinjema will intercept the call and call that setter method with some appropriate object. Go ahead and run it.

A context has a name, such as "customerA/logging". This name represents the "logging" context which is inherits from the "customerA" context, which inherits from the root context (which is named ""). A context may be a file folder, or a set of rows in a database table. It could be a directory on a website accessed via http. Contexts can, in theory, be located anywhere, but it's simplest to use a folder for examples. The folder holds configuration files, and usually the term "context" refers to all the configuration data in a given folder.

The root context is the starting point of all the contexts Coinjema manages. The contexts are structured heirarchically just like a file system, and in fact, the easiest way to create the root context is to point Coinjema at some particular folder. In that folder you will put most of your system's configuration data. Subfolders will automatically be treated as sub-contexts and coinjema will look within them for more configuration data if appropriate at run-time.

The startup routine for your application has to intialize a root context for Coinjema:

Yes, badly.

Read about what you'll need (coinjema's dependencies). Download coinjema and the dependencies - none of them come with coinjema. Start with How to use Coinjema to get instructions on the basics of what you'll have to do.

Coinjema is a dependency injection framework that uses AspectJ to intercept calls to constructors and inject dependencies into yourobjects before the constructor returns.

Coinjema does its work via setter injection like many other frameworks, though your objects can also receive dependencies via constructors programmatically.

It injects dependency objects into your classes for you. It doesn't seem to have a whole lot of striking similarities to how other containers work. Which is good, else why would it need to exist?

• There is no factory that you have to use to create your objects. All objects are created via new YourObject()
• Your object dependencies are declared in your class file. Many feel the resulting coupling between your objects and Coinjema's defined annotations is undesirable in a dependency-injection framework. While I understand the reasons many don't want that coupling, I think it's better than putting those declarations elsewhere, such as in an xml configuration file. It feels more natural to me for a Java class to declare its own dependencies, even if that means it is required to differentiate dependencies that may come from a container, and dependencies that are set programmatically by your other classes.
• Declarations of dependencies is done via annotations - this is similar to the EJB 3.0 specs, with its @inject annotation.
• You don't register dependency objects with the container, the way you might with some other frameworks.
• Configuration information is defined using whatever format works best for that particular bit of information. You can use properties files, groovy scripts, groovy classes, serialized java objects, plain text files, and more. You can define your own highly specialized file format very easily, if desired.
• There is no xml used in this framework. You can throw away xerces - I have.
• Contexts allow you to define many inheriting sets of configuration information. The container automatically resolves which context your newly created object belongs to, and loads it with the appropriate dependencies.
• Coinjema has dynamic dependencies that can change depending on what context the object is currently executing in.
• More than any other framework I know of, Coinjema encourages massive use of runtime configuration data, and makes it easy to do so.
• Coinjema allows for configuration information to transparently come from a filesystem, a database, a URL, email, JavaSpaces, etc. ContextSources are simple to define, and Coinjema comes with a file system source and a simple JDBC source. Imagine putting your object-relational mapping configuration info in the database to allow multiple clients to use it?

Fair enough. I doubt it's a question of being able to do something that you can't do with Spring or Pico, but more a question of is it realistically simple enough to do? By letting you define multiple contexts that inherit from each other, and because Coinjema always knows what the correct context is for the current thread, you can easily inject highly customized data into your objects without any extra work on your part.

Here's an example. Say you have a webapp that many different customers of yours are using. You have 13 different customer sites on the same servlet container, but each customer's interface and behavior differs in specific details. Coinjema allows you to create a system wherein each customer directory is automatically a different context in which you can place configuration files that override the files from the default. Customer B might even point to a different database - that's just a new "datasource.groovy" script that you placed into their directory - all else stays the same. In your code, because Coinjema knows automatically that a given user is requesting a url from "/b", all the code that gets executed as a result of that request is automatically given the right configuration, and gets pointed to the new database with no effort on your part. Objects that are configured one way for user A are transparently configured another way for user B.

Plus, no XML. There's no need to write <property name="name" value="value"> anymore. If what you need is a set of properties, write a simple properties file. If you need a bean, create it in a groovy script. If you need a string, just put that string in a plain-old-text-file.

A bit. The annotations you put in your code will require that the coinjema jar (currently about 92k) be present for compiling and running. Compiling your code will require the use of iajc from aspectJ if you are going to use Coinjema. Your code will still compile fine without iajc, in which case it will behave like normal java code and you can set your dependencies manually.

All that is no big deal - your code, being in your control, it would be easy to remove the annotations if you wanted, or just not weave the coinjema aspects and ship with the coinjema jar without really using it. The problem is really about third-party jars - those that use coinjema and those that don't, but you would like them to.

If you create a library that uses Coinjema, you can distribute two binaries - a weaved binary and a non-weaved binary. The non-weaved binary will require the coinjema jar to be present, but in all other ways will behave like normal java code. Your objects will need the user to provide dependencies automatically. The weaved binary would require that the user creates a coinjema context somewhere and provides configuration data.

If you are using a library that doesn't use Coinjema but you wish it did, then you currently are out of luck. You can write a bunch of wrapper classes that provide the hooks into Coinjema on behalf of the third party classes. Beyond this, all I can say is it's a goal of mine to provide a way to define simple weaving rules that would allow a third-party package to be coinjemified, but no such tool exists now.