JBossDeveloper

and here's what CBauer would say: submit a patch!

Must…resist…urge…to...answer...aaaarghhhh:  All that needs to be done to fix this is to delete the org.hibernate.engine.Nullability.checkNullability method... do I really need to submit a patch with that?

Sorry, I was not strong enough to resist :'(

Arbi Sookazian wrote on Nov 10, 2009 01:27:


Like .NET, right?  Use what's out of the box...

The problem is that .NET box has a lot of things JEE does not have (Process isolation, Better Generics Support, LINQ, closures, continuations, better DateTime API).. (and JEE also has a lot of things .NET does not have (the UI is truly multi platform, different vendors to choose, multi platform distributed transactions, older and more stable ORMs, lots of free and open source code, vibrant open-source communities )). If I have learned something in all my years of coding... is that all platforms are imperfect....

What I would love to see is strong vendor supporting IKVM to the point that it becomes much easier to share code between Java and .NET (Perhaps now that the JVM is open it could happen)

Arbi Sookazian wrote on Nov 10, 2009 01:39:


So in a way I'm advocating little (or no) use of Seam 3 when creating a EE 6-based application.  Why Seam now?

added value: PDF, excel, remoting, conversational web services, SMPC, hmmmm... and the list goes on.

Exactly, Seam becomes JBoss extensions for (or on top of) JSR-299

Well, IMHO, as much as I like Seam 2.x, I still think Seam was/is a big hack in EE 5.  Although it was necessary to prototype ideas that made it into JSF 2.0 and CDI (among other specs?)

I agree.

But will we really need Seam in EE 6 apps?  Won't there be another way to avoid LIEs without Seam?

Only if the JPA 2.0 guys decided to alter the spec to avoid LIEs.

And the manual flush should have made it into JPA 2.0, no? 

They do not see any reason to do that, and frankly, I do not blame them (I do not see any reason either). BTW Arbi, you are asking too much things about JPA writing in this posts... you could get banned, this forums are not for discussing JPA ;-).

Well hopefully the performance issues with JSF/Seam will be alleviated fully with Seam 3...

Hopefully, but I think many of the performance issues are due to the architecture of JSF... hopefully JSF 2.0 will help with that... but then again, this is not a forum to discuss JSF ;-)...

Don't you think there should be a place where discussing any implementation of JSF, Weld, JEE, JPA should be on topic always? After all, all this efforts are to integrate this 3 technologies, and if there is a bug in one of them that causes problem precisely when it is interacting with the others there is just no (AFAIK) single place where is is right to ask about it.

Arbi Sookazian wrote on Nov 10, 2009 17:35:


Although specs are typically dry and boring, no offense...

I can live with dry and boring specs (it is painful, but I can endure it), the thing I can not endure is ambiguous specs, so I am really happy that the TCK of JSR-299 is public, that way there is not room for ambiguity, if it is in a test, it has to pass the test, if it is not in a test, then a test has to be written. I hope one day all TCKs become open and freely available...

Ummm, yes (probably, depending on what the arrows mean). Not that I'm sure where the question was going, but...

Arbi Sookazian wrote on Nov 10, 2009 17:35:

So why static injection rather than dynamic injection in Weld/CDI?  I thought in Seam, dynamic injection was the big advantage over Spring's static setter or constructor injection...

Performance and simplicity of design, perhaps? I'm not that familiar with Spring DI

Arbi Sookazian wrote on Nov 10, 2009 17:35:

BTW, is there anybody writing a CDI/Weld book or will that sort of be covered in an updated Seam 3 book (the core section)?

I'm sure there will be. There are not m(any?) core technologies in the EE that hasn't been covered by multiple books.

So why static injection rather than dynamic injection in Weld/CDI? I thought in Seam, dynamic injection was the big advantage over Spring's static setter or constructor injection...

In CDI we use proxies to achieve approximately the same effect. It's stll dynamic, just a different kind of dynamic.

Injected fields are (in most cases) proxies that are instantiated. Even if the proxies are static in the sense that they are wired at bean creation time, they point to the current instance (the proxy method handler looks it up before calling the method). So nothing is injected on every/any method call but accessing the injected field (proxy) will always result in the current instance being invoked upon.

Elaborate on different kind of dynamic. What does that mean?

Section 5.4 of the final draft specification. (Client proxies.)

Already fixed.

It's a deliberate error since only $DEITY can make a perfect specification.