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.

Jurassic

Well i was hoping to use a "standard" that hopefully Guice and Spring were moving towards. Given the differences between the big 3 it appears while CDI may be a standard, its kind of incomplete and ignored as WELD itself has many extras and while Guice and Spring share some annotations they do work differently and use non standard class/intf. – Jurassic

@mP could you explain (with examples) the desired effect, because I don't know guice – Proud

I second Bozho's request, I'd like to understand what this question is about :) – Recent

@Jesse - i suppose given its your baby its not a shock to hear you say that :) – Jurassic

What's the benefit of using a JCP standard? Spring and Guice have far more users than CDI, flexible licenses, and welcoming user communities. With Spring you can even buy commercial support should you need it. And Guice powers many of your favourite websites, including Gmail! CDI has the JCP stamp, but that's about it. If you want to rely on something, both Guice and Spring have more industry support than CDI. – Voluble

Generrally standards represent stability and choice. The Java platform is a perfect example theres a standard with many implementations. An implementation typically only comes in one form. Guice only comes in one form, with extensions (peaberry) required to solve problems for other platforms like OSGI. Theres also the question of community involvement, in the end Guice is driven primarily by Google's needs, the public basically gets a freebie as the product evolves. – Jurassic

The previous sentence is a real concern for someone who has different needs, as Guice is very much specialised to solve Googles problems first and formost. The Big G doesnt care about my needs. In the end i am stuck with a single choice in terms of who updates, fixes and so on. Dont get me started about forking, its not always an option as it means you are entering a major commitment to the fork. – Jurassic

A standard in the end means choice. Many of the great modern things we ue everyday are in effect real or based on defacto standards. Things like phones, mobiles, cars, electrical devices they all interop because they are based on standards of some sort. Independent products may be successful in their own right but... – Jurassic

With choice at least theres an element of competition between the implementors which means the public i believe gets a better deal. A standard is more democratic while an defacto standard (eg Guice) is more dictatorial. BTW i appreicate this sound a bit idealistic but in general standards help, naturally this is not always an option but if possible its a great direcction to follow. – Jurassic

what does "bind interfaces" mean. I think we'd still need an example in order to understand the question. – Proud

I am making the distinction because Guice returns two builders one to bind types and another to bind constants. The term "intf" here means bind types like interfaces to their impl etc. – Jurassic

Could you provide a simplistic example of what you would need to do? ie. I have a PaymentProcessor interface, and depending on deployment I 'll either use TestPaymentProcessorImpl, USAPaymentProcessorImpl or CanadaPaymentProcessorImpl. – Engleman

I subscribe to the petitions below: explain to us what you are trying to do because most of us do not know Guice. I read about Guice and Guice modules to understand your question - and it is still unclear. Anyway, it looks like you want more flexibility in injection, so I ask: are Instance objects what you are looking for? – Diwan

I am very familiar with Guice and CDI/Seam2. I use them together. They have different design goals. Guice is simple and small, but it doesn't integrate with anything all by itself. If you want POJO flexibility, use Guice. CDI automatically scans for beans and integrates with JSF, etc. If you want to integrate with JSF and EJB, use CDI (otherwise you'll end up writing a lot of code). – Eddaeddana

@Diwan No, he's looking for a way to define beans programmatically in CDI, like Guice does. – Eddaeddana

@Joshua well, you can imagine how hard is to understand what does "define beans programmatically" means if one just know CDI, right? :) I think I (more or less) got it, however: OP wants some way of making POJOs to be injected as beans for some arbitrary injection points, having more control of how to do it and without writing producer methods. If so, it looks like what the OP does want is to not use CDI anyway. The OP just does not want the way CDI works, that is it. Or am I wrong? – Diwan

@brandazzi I think you've got it - there are actually two different points: 1) How to define beans programatically, and 2) how to get 'unmanaged instances'. – Eddaeddana

Are you asking for a Weld equivalent to Guice's bind(FooInterface.class).toInstance(handConstructedFooInstance)? Because if so, so am I. :-) – Opposable

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.

Eddaeddana

Thanx josh, my comments about magic refer to the inability to change the behaviour, how or when it happens. One cannot invoke some method to start, stop, refresh etc. – Jurassic

No problem. Guice and CDI have very different design goals. CDI is geared towards supporting JSF, whereas you'd have to do all that yourself with Guice. Programmatic bean definition sounds good, but in practice I find it to be a source of confusion / errors. – Eddaeddana