[ruarcoconnell]

Yes, in May 2006 BC.
Really, I wasn't trying to say CDI shouldn't exists because Spring had it all, I just argued that CDI failed to bring enough innovations. Gavin corrected me, I thanked him, stated my opinion on the importance of Seam 3 in that regard and that's it. So your sardonic comment was... unnecessary to say the least.
Anyway, it'd be great if you could answer/correct me on the first two issues in my previous post.

[nickarls]

I'm so sorry, I just continued in the spirit of

Okay... I thought enabling/disabling beans in CDI also requires XML. Hmmm... Maybe I just didn't get you right.

I believe extensions and the SPI can handle both cases but I think Gavin is going to reply on this thread anyway (and more correct) so I'll leave it to him.

[ruarcoconnell]

It's perfectly ok. And regarding the sentence you quoted, it wasn't sarcasm, I was honestly confused and though I didn't understand Gavin properly :)


Same thing goes for the second issue (injecting into a third-party class). I'm really not sure if Gavin referred to calling the third-party class constructor in a producer method and providing injected values as parameters or something else.


And thanks for the reply.

[gavin.king]

And what about beans which are available in some deployments of the system and not others? How do you handle those [in Spring] without specifying each, explicitly, in XML?

Okay... I thought enabling/disabling beans in CDI also requires XML. Hmmm... Maybe I just didn't get you right.

@Alternative stereotypes. Yes, you still need maybe one line of XML to enable the stereotype. What you don't need is an XML list of all the individual beans.

By the way, you can probably add stereotypes to my list of innovative things in CDI. I don't believe that any other solution has anything quite the same. (Spring has something called stereotype, but I don't believe it does the same thing.) For now, stereotypes are a bit incomplete, since the EJB spec doesn't let you put stuff like tx management annotations on them. But that's just a matter of time.

how do you inject stuff into a third-party class with CDI? You don't.

    Actually you can.

Okaaay... After reading all the official documentation and all the blog posts I managed to find, I still have no clue how to do that. Let's say I missed something or misunderstood or whatever, but it still means the docs need improvement. Also, I'd really appreciate if you (or anyone) exemplified this.

Another thing I believe is missing in CDI (compared to Spring) is the ability to declaratively assign scope and other meta-data to any class without the need to write boilerplate producer methods that only return new Something(); anyway. Could I be wrong again?

Well, injection into a 3rd-party class is actually the same problem as declaratively assign scope and other meta-data to any class. As soon as you can add metadata to a class in a 3rd-party jar, CDI can inject stuff into it.

Now, we decided not to completely spec out a solution for this in CDI 1.0. Early revisions of the CDI spec did include a (typesafe) XML-based solution for weaving metadata into pre-existing classes. But we took it out for several reasons:

• There is currently a debate about the best approach to this problem: namespaced XML, or a Java-based DSL ... and each approach has it's advantages.


• Supposedly, the JSR-330 group was going to address this stuff, though this now looks increasingly unlikely.


• Injecting into third-party classes is simply a much, much less common thing to do than inject a third-party class into something else.


• We wanted to simplify the 1.0 version of the spec, so we were looking for stuff to cut.

So what we did instead was include an SPI that lets you solve this problem, along with a number of other even more interesting problems. You could either code directly to the SPI, or you could use a portable extension like this one that provides XML or Java DSL-based configuration.

So if you love specifying metadata in XML, it's now as simple as just dropping in seam-xml.jar to whatever CDI implementation you are using.

Meanwhile we're free to experiment with different approaches for a bit longer before we nail something down in the spec (if ever).

Did I ever try to? I said @Autowired + qualifier was typesafe. I said nothing similar about @Resource.

Right, and @Autowired is a totally non-standard annotation that is not part of any JSR. @Resource actually is defined by a JSR and has somewhat well-defined semantics, though AFAICT, Spring does not actually implement those semantics. But I really, really can't imagine why anyone would want to use either in preference to @Inject.

[ruarcoconnell]

Comprehensive and very informative. Brilliant answer Gavin, thank you very much for taking the time!

[nickarls]

Shervin Asgari wrote on Oct 24, 2009 00:44:


Is Seam 3 using Weld, or is Weld an option to use with Seam 3?

Seam 3 is a set of modules that require a CDI implementation. Currently there are no(?) modules that are Weld-specific and I'm not sure there will be, so you are free to choose. And even if there would be some neat module that would require closer integration to the implementation than the API/SPI allows for, it would probably be abstracted away so it auto-detects what implementation you have available.