JBossDeveloper

Arbi Sookazian wrote on Nov 10, 2009 23:45:


So the from/to concept from Seam is gone.  And replaced with what?

Apparently with Proxies... something, that, BTW, Spring is also able to do... mmmm I guess i should be wrong, but this sounds like Weld pretty much does exactly what Spring does since 2.0.x.

I mean, Weld of course does lots of other stuff that Spring does not (and viceversa), but in this regard, it seems that Weld and Spring are very similar (and the Seam 2 model seems to have been a dead end)...if that is not true, please explain me the difference, because I do not see it...

Francisco, I'm really not precisely sure what your point is, but you're correct that CDI and Spring both copied their scoping features from Seam (which was released more than a year before Spring 2, and 3 years before CDI). And no, neither use the same implementation approach as we used in Seam. But as far as I know, Spring is still using, under the covers somewhere, a string based id for every bean, an approach much more like the contextual variables of Seam. CDI is more evolved in that respect, as I understand it.

But it sounds like you're trying to claim that CDI copied its scoping model from Spring, which is just just completely silly.

And it seems totally bizarre to call something a dead end, when it formed the basis (implementation details aside) of the models now used in CDI and Spring. Remember, before Seam, no DI framework had featured a solution to the problem of cross-scope injection (and Guice still doesn't).

And look: both implementations have a proxy. Both look up the contextual instance dynamically at runtime. In Seam, that happened when the client was invoked. In CDI, it happens when the client invokes its reference. There are pluses and minuses to both approaches, but in the end we all agreed that the CDI approach is on balance better, especially if you're not trying to support outjection.

Gavin King wrote on Nov 11, 2009 16:37:


Francisco, I'm really not precisely sure what your point is, but you're correct that CDI and Spring both copied their scoping features from Seam (which was released more than a year before Spring 2, and 3 years before CDI).

Interesting...

And no, neither use the same implementation approach as we used in Seam.

Intersting too...

But as far as I know, Spring is still using, under the covers somewhere, a string based id for every bean, an approach much more like the contextual variables of Seam. CDI is more evolved in that respect, as I understand it.

As I said, Weld does many things Spring does not, (and Spring does many things Weld does not)

But it sounds like you're trying to claim that CDI copied its scoping model from Spring, which is just just completely silly.

I can see that it can be interpreted like that, but that was not my point, (althought I wanted to know if it was the case), my point is: Since Weld chose to do things in a way that is not the Seam way... is its architecture now more closer to Spring than to Seam?

And it seems totally bizarre to call something a dead end, when it formed the basis (implementation details aside) of the models now used in CDI and Spring.

Well, since since the model followed by Seam is not being continued by Weld, I think it is accurate to call it a dead end. That does not mean it was not a good idea to explore that model by implementing Seam, I do believe it was a valuable learning experience that must have helped the Weld team to avoid the pitfalls of the Seam model (but if it were not a dead end, then Weld would use the same model...no?).

Remember, before Seam, no DI framework had featured a solution to the problem of cross-scope injection (and Guice still doesn't).

Allright, but now that Spring also has support for cross-scope injection, and since Weld choose not to follow Seam model... wouldn't you say that Weld and Spring might be less different than Seam and Weld?

Gavin King wrote on Nov 11, 2009 17:38:


And look: both implementations have a proxy. Both look up the contextual instance dynamically at runtime. In Seam, that happened when the client was invoked. In CDI, it happens when the client invokes its reference. There are pluses and minuses to both approaches, but in the end we all agreed that the CDI approach is on balance better, especially if you're not trying to support outjection.

And you decided  that supporting outjection was not worthwhile because...? And what happens with applications built with Seam 2... doesn't this mean it is going to be hard to migrate them to Seam 3?

And, now that Spring does support cross-scope injection (but AFAIK it does not support outjection)... does that mean that it is going to be easier to migrate an app from Spring 2 to Seam 3 than from Seam 2 to Seam 3?

and Guice still doesn't

Note: Guice will never support cross-scope injection with proxies because it's not a good idea. Sure, it might be easy to write code when you don't have to think about scopes (the code may not do what you think it does), but how am I supposed to understand your code when an instance can magically switch identities from one method invocation to the next?

In Guice, you get an error at initialization (or even build) time when you try to inject an object from a smaller scope into an object in a larger scope. The error is desirable because you probably didn't mean to do that. Then, if that's really what you want, you just inject a provider instead. You control when the object gets resolved from its scope. As a bonus, you don't have to incur the overhead every time you invoke a method on that object.

Since Weld chose to do things in a way that is not the Seam way... is its architecture now more closer to Spring than to Seam?

If I'm correctly understanding how Spring implements scopes and what they're using their proxy for - and I'm 90% sure I do (now) - then I would certainly say that Spring and CDI are quite similar in this respect.

Well, since since the model followed by Seam is not being continued by Weld, I think it is accurate to call it a dead end. That does not mean it was not a good idea to explore that model by implementing Seam, I do believe it was a valuable learning experience that must have helped the Weld team to avoid the pitfalls of the Seam model (but if it were not a dead end, then Weld would use the same model...no?).

I think you're confusing an implementation detail with the model. The model in Weld is a continuation of the model in Seam! It's just implemented differently, in this respect. But now we're arguing semantics, which is kinda pointless.

wouldn't you say that Weld and Spring might be less different than Seam and Weld?

If you focus on this specific implementation detail, then I don't object to that statement. Of course, this is just one detail. Overall, Weld is much more like Seam than like Spring. This should be obvious, since CDI was designed mainly by folks who think Spring is a steaming pile of ....

And you decided that supporting outjection was not worthwhile because...?

Because, on reflection, we decided that having two producer methods share the definition of a bean (which is what Seam-style outjection enables, in the language of CDI) is dangerous. On the other hand, CDI provides producer fields, which are pretty much just a restricted form of outjection (restricted to what we think is safe).

And what happens with applications built with Seam 2... doesn't this mean it is going to be hard to migrate them to Seam 3?

I don't think it's going to be very hard, no. And in case it is a little bit more tricky than I imagine, we're promising inter-operability between Seam2 and CDI beans.

does that mean that it is going to be easier to migrate an app from Spring 2 to Seam 3 than from Seam 2 to Seam 3?

I'm highly skeptical about that, but I guess it depends how much of Spring your application depends upon.

Note: Guice will never support cross-scope injection with proxies because it's not a good idea. Sure, it might be easy to write code when you don't have to think about scopes (the code may not do what you think it does), but how am I supposed to understand your code when an instance can magically switch identities from one method invocation to the next?

In Guice, you get an error at initialization (or even build) time when you try to inject an object from a smaller scope into an object in a larger scope. The error is desirable because you probably didn't mean to do that. Then, if that's really what you want, you just inject a provider instead. You control when the object gets resolved from its scope. As a bonus, you don't have to incur the overhead every time you invoke a method on that object.

Definitely not going to re-do this argument which has been more than done to death. Suffice to say that nobody I know agrees with Google on this one. Anyway, I'm very happy to shut up and let the users decide whether they prefer to use JSR-299 or JSR-330. LOL.

Gavin King wrote on Nov 12, 2009 03:49:


And what happens with applications built with Seam 2... doesn't this mean it is going to be hard to migrate them to Seam 3?

I don't think it's going to be very hard, no. And in case it is a little bit more tricky than I imagine, we're promising inter-operability between Seam2 and CDI beans.

inter-operability between Seam2 and CDI beans? Just to be clear on this... Does that mean I am going to be able to use Seam2 and Weld at the same time, on the same project? and if that is true... Does it also mean I am going to be able to use Seam2 and Seam3 on the same project?

BTW, I hope I understood correctly, because making that possible is IMO a very good idea, because that will make it easy to migrate from Seam2 to Seam3 without having to restart from scratch

inter-operability between Seam2 and CDI beans? Just to be clear on this... Does that mean I am going to be able to use Seam2 and Weld at the same time, on the same project?

Yes, that's definitely going to be possible. Seam2 and Weld can run side by side and their beans will be able to interoperate.

and if that is true... Does it also mean I am going to be able to use Seam2 and Seam3 on the same project?

We are planning on letting you use Seam2 beans in a Seam3 app. That's not quite the same as letting you use Seam2 and Seam3 at the same time.I'm not sure if we'll let Seam2 and Seam3 run side-by-side. We would have to change package names at the very least. But I guess org.seamframework would work.

Things got unfriendly because anyone who criticizes Spring on any grounds ends up the target of ruthless, personal attacks. And because there is plenty to criticize in Spring.

But the bigger problem is that the industry got stuck. Spring was, initially, a very interesting project with some good ideas. But instead of taking those ideas back into the Java standards, the Spring folks decided to compete against the standards and divide the EE development community. Which was their right, frankly, they damn-well should pursue their own business interests, just like the rest of us. But it has made it much more difficult to grow the ecosystem.

I know that GKing does not think that supporting orthogonal concerns via AOP is necessary, but it's nice to be able to add logging and tx's and security to your app without modifying the classes, no?

You need AOP to implement logging and transactions and security?! WTF for? What is it you are trying to do that you can't do with a CDI interceptor binding?

I don't get why people seem to think that transactions and security are things that can just sort of be stuck on later. When I am writing code I usually know exactly what the transactional behavior should be, and expressing that with an annotation in the actual code makes a lot more sense to me than expressing it in an XML document somewhere else entirely.