Home

What is this

This is a prototype, or proof of principle if you will, of programmatic configuration of CDI.

If somebody wants to make something similar – this is a good starting point. It includes pretty much all of the know-how.

What works

Currently Guice API for linked binding works e.g.

bind(Mailer.class).to(AsynchronousMailer.class).in(Singleton.class);

and AOP support e.g.

bindInterceptor(any(), annotatedWith(Transactional.class), new TxnInterceptor());

The rest is left as en excersize for the reader to implement. ;)

One Caveat

Due to the way CDI works it is impossible to express this binding.

bind(Mailer.class).annotatedWith(Blue.class).to(AsynchronousMailer.class).in(Singleton.class);
bind(Mailer.class).annotatedWith(Red.class).to(AsynchronousMailer.class).in(SessionScoped.class);

As both target AsynchronousMailer and CDI reads annotations from the AsynchronousMailer therefore it doesn’t work.

How to use it

Best if you check out unit test(s).

1. Run ant jar (this will create weld-guiceconfig.jar)
2. Put weld-guiceconfig.jar in the class path (all internal dependencies (guava, weld-extensions) are baked in using jarjar. Guice, weld, aopalliance and slf4j are not baked-in and have to be put on the classpath seperately.)
3. Create META-INF/guiceconfig/Modules.properties in your project and reference any Guice modules using fully qualified names

Will there be any more updates

Most probably not. This is not my dog food. Made it is a fun project to play with Weld a bit.

Check out weld.guiceconfig.attic package for an example of custom fluent style api bindings. In general this extension might help you if you want to make your own extension for programmatic configuration.