Is there an equivalent in CDI(WELD) to build definitions (as done in Guice modules) and then create an Injector?

Question

I like the way Guice makes it fairly straight forward to manually create your own modules each with their own bindings done in code. CDI on the other hand seems to rely more on magic rather than programmatic access to sest bindings. Am i wrong or how can one achieve the same effect with WELD.

Any code sample would be appreciated...

CLARIFICATION

I was hoping to build a Module(Guice term sorry im unsure of the CDI term) programmatically, using the builder pattern style as given by Guice on http://code.google.com/p/google-guice/.

I am building a dynamic system and there is a need for me to be able to bind types(like interfaces), constants etc rather than just have Weld dynamicaly scan the classpath etc and find and register types. I believe that CDI is static the javax.inject package does not include any interfaces that allow one to programmatically bind types to implementations.

CLARIFICATION PART 2

The basic premise of the original question was the simple observation that annotations are baked in and the rules defined in them to help the inejctor cannot be changed. I originally wanted public access to the same interfaces that the CDI classpath scanner uses to build definitions for its internal use. Basically waht im saying is, i want a layer that allows me to read the annotations and create the definitions for the container. A default provider could be one that does what happens now, but if you want some other strategy then there exists the possibility to do this.

One problem with the current approach is the limitation that one cannot reuse components(classes) with different annotations to select different collaborators. Before you jump let me qualify this statement, yes it can be done with providers and the such but this leads to more artifacts. There should be a simpler way.

Example1

Sorry if this example is poor, my use case is much more involved and the detail would get in the way and make for a much longer read.

Imagine one has a url rewriting component that for arguments sake has some parameters like

• replace this pattern with that pattern.
• maybe a html cleaner

If you wish to inject this same component with two different replace rules but have the html cleaner injector, your stuck. Sure there are ways to get around this but they require artefacts which is of course more code.

All binding rules unfortunately are on the class and not the instance thus every time you ask for a class you get back pretty much afunctionally equivalent instance.

WELD

This question was written a whiel ago, i have given up on Weld.I believe the way it dictates how its magic is done is wrong. I dont like the fact they dictate to me how this happens without providing me a way to control when or how i might want to repeat this action. I dont like this inflexibility.

Answer 1

I use Guice and CDI/Seam2 on a regular basis. The short answer is no, CDI does not support programmatic bean definition ('binding', as Guice calls it).

CDI uses a declarative approach where the container will automatically scan for bean definitions. This can be customized to some extent with the 'alternatives' features, but it's not as flexible as Guice's programmatic approach (where you can do basically anything).

---

My two cents

I use both frameworks: Guice for "lower level" non-enterprise POJO components (where I don't have/need CDI features), CDI for anything where I need the extra features of CDI, things that are plugged into JSF or EJB3. Mainly I started using Guice as a way to get DI in 'adapter' JVMs, which run ouside of the application server cluster. As I get more familiar with CDI, I'm finding less of a need for Guice though. I imageine that when CDI supports 'unmanaged' instances I may be able to replace Guice with CDI (e.g. weld-se).

RE: Weld 'magic' - IMO nothing is 'magic' about bean definition scanning. It's really well defined in the CDI spec, and it is similar to other Java Enterprise frameworks such as JPA and EJB3.

My advice is to you is:

1. Use what works for you. If you don't like CDI, don't use it. For example, I need 'unmanaged instances' in my app, so I use Guice for that.
2. If you think CDI could be better (I do), get involved - participate in the community defining CDI.