JBossDeveloper

I didn't mean any offense by that.

Nono, I did not take offense. I'm just ranting, like usual...

And I appreciate the interest you are taking in the success of this project. Really.

No, @Resource is not typesafe. It uses String-based names to identify the thing to be injected to an injection point.

Well, that's Spring's own semantics for @Resource. That's not how it's defined by the Java EE spec.

And note that this typesafe semantic for @Resource only works if you have only one implementation of the type. True typesafe injection means looking at type+qualifier(s).

Gavin King wrote on Oct 23, 2009 05:18:

• Extensibility: Weld provides very strong support for portable extensions written to the JSR-299 metamodel SPI. This means that frameworks like Seam3 will be able to provide all kinds of additional functionality without resorting to the kinds of hacks that were needed in a plain JSF environment.

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

Seam3 is a set of portable extensions to JSR299. So it will require Weld or some other impl of 299.

I am really confused because, by default, @Resource looks up the bean by its type, at least in Spring (it's the only implementation I've used). 

No, @Resource resolves the bean by name. @Autowired looks up beans by type. And you can add qualifiers if you have registered more than one bean of the same type.

Gavin King wrote on Oct 23, 2009 21:35:

True typesafe injection means looking at type+qualifier(s).

You mean like this:

public class MovieRecommender {
@Autowired
@Offline
private MovieCatalog offlineCatalog;
// ...
}

If you replace @Autowired with @Inject you get CDI code, so CDI really brought nothing new here. Spring supports qualifiers, as the previous poster stated. The most useful feature of CDI I'd say are the conversations, but Spring Web Flow has them too. So, apart from having @Alternative (which I never found much use for) and interceptors/decorators (which are not new but are easier to use than Spring alternatives) , the only thing CDI has on it's side is that it's a standard. I'm sorry but I fail to be amazed.

Gavin King wrote on Oct 22, 2009 09:06:

299 is just much more solid and better thought-out system.

This is a notoriously questionable statement. Example:
how do you inject stuff into a third-party class with CDI? You don't. Yet, Spring has no problem with this. I know there are counter examples as well, but that doesn't help the fact the original statement is questionable.

Anyway, I'm not a Spring evangelist, I'll give a chance to anything that attempts to make my life as a developer easier, I just don't like seeing decent technologies being attacked on some very suspicious basis.

Ronald Tetsuo Miura wrote on Apr 19, 2010 21:50:

No, @Resource resolves the bean by name.

By name first and by type second.

Ruarc O'Connell wrote on May 11, 2010 00:00:

Gavin King wrote on Oct 23, 2009 21:35:

True typesafe injection means looking at type+qualifier(s).

You mean like this:

public class MovieRecommender {
@Autowired
@Offline
private MovieCatalog offlineCatalog;
// ...
}

If you replace @Autowired with @Inject you get CDI code, so CDI really brought nothing new here. Spring supports qualifiers, as the previous poster stated. The most useful feature of CDI I'd say are the conversations, but Spring Web Flow has them too. So, apart from having @Alternative (which I never found much use for) and interceptors/decorators (which are not new but are easier to use than Spring alternatives), the only thing CDI has on it's side is that it's a standard. I'm sorry but I fail to be amazed.

What I said above was (quoting myself):

Weld lets you change the configuration of your system at deployment time, without requiring that you write tedious lists of beans in XML or Java-based DSL, as required by other DI solutions.

Do you see anything wrong with that statement? I don't. So I ask again (again quoting myself):

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?

So if you would have actually bothered to read and understand the whole 6 month old discussion, you would have seen that your objection has already been discussed and dealt with.

Anyway, the original context of this thread is nothing to do with Spring, the original poster asked:

I was wondering what are some of the reasons someone writing a JSF 2.0 application would want to use Weld/CDI/JSR299 over the new @ManagedBean annotations in JSF 2.0?

What are some of the more significant advantages of JSR 299 vs a @ManagedBean that a typical JSF user is likely to encounter?

And my posts in this 6 month old thread were in response to this question, and are addressed to a JSF user who wants to know what they will get out of CDI.

Gavin King wrote on Oct 22, 2009 09:06:

299 is just much more solid and better thought-out system.

This is a notoriously questionable statement. Example:
how do you inject stuff into a third-party class with CDI? You don't.

Actually you can. So I guess you need to get back to actually learning about CDI instead of resurrecting months-old threads for the sole  purpose of arguing your blinkered world-view.

Ronald Tetsuo Miura wrote on Apr 19, 2010 21:50:

No, @Resource resolves the bean by name.

By name first and by type second.

And because it uses a String-based name, it is non-typesafe. Do you seriously want to try and argue that @Resource is typesafe injection? Really? No, I didn't think so.

So, apart from having @Alternative (which I never found much use for) and interceptors/decorators (which are not new but are easier to use than Spring alternatives), the only thing CDI has on it's side is that it's a standard.

Oh and by the way:

• No, Spring doesn't have decorators. They are unique to CDI.


• CDI has typesafe interceptor bindings and


• a typesafe event notification model.


• CDI's conversations are not tied to some XML-based orchestration language. They are useful even in application transactions that are implemented in a single (Ajax-ified) page.


• CDI provides an SPI that allows portable extensions to integrate cleanly with the Java EE container. That's completely new.

So clearly, there were quite a few new things CDI brings to the table here.

Gavin King wrote on May 11, 2010 07:08:

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.

Gavin King wrote on Oct 22, 2009 09:06:

299 is just much more solid and better thought-out system.

This is a notoriously questionable statement. Example:
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?

Gavin King wrote on Oct 22, 2009 09:06:

Do you seriously want to try and argue that @Resource is typesafe injection?

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

Gavin King wrote on May 11, 2010 07:21:

No, Spring doesn't have decorators. They are unique to CDI.

Decorators per se, yes, but you can achieve pretty much the same effect with AOP. Still, as I said, decorators are far easier to use.

Gavin King wrote on May 11, 2010 07:21:

So clearly, there were quite a few new things CDI brings to the table here.

Actually, yes. There were some features I missed. Thank you for pointing them out and thank you for the reply all together. I really admire the time and energy you use to answer even those question you find pointless.



All in all, I'm under the impression that CDI is a decent technology but that it's up to Seam 3 to enrich it's feature set and ultimately decide if it becomes the technology of choice or yet another overlooked piece of Java EE.


P.S.

Sorry for the thread resurrection, but since there's really very little posting on this forum, I honestly can't say I see any harm in that.

It is truly outrageous that the JCP allowed for two competing JSR:s to be submitted if Spring had all this in May 2006!

I was trying to dig for more examples but couldn't find the JSR# for Spring, could you please help me out?