Seam does not even have the equivalent of Spring's JdbcTemplate which is a very useful data access component which makes JDBC much cleaner and easier.

I'm sure you'll find it's trivial to integrate a JDBC framework as a portable extension to CDI. The idea that anyone would choose to adopt the entire Spring application architecture just to get a JDBC framework is absurd.

I'm sure if someone cares enough, they will port the Spring JdbcTemplate stuff to CDI. That's not at all a difficult task.

(It's even completely trivial to integrate iBATIS in Seam.)

People are going to evaluate EE 6 and ask what does this stack offer that we can't currently accomplish with Spring 3 and dm server?

I certainly hope they do, since there are so many good answers to that question.

Arbi Sookazian wrote on Nov 04, 2009 06:41:

People are going to evaluate EE 6 and ask what does this stack offer that we can't currently accomplish with Spring 3 and dm server? 

Shouldn't the first question asked be Now that we get this for free as a standard, what added value do we get from a VC backed framwork? ;-)

And yes, Spring Framework is open source but any project has a number N where N is the number of people removed from the top of the hierarchy after which the project is pretty much doomed. Seam is not exception. That's why standards are good. A vendor switch results in rewriting but the amount of work shouldn't be huge if both are based on the same standard.

what added value do we get from a VC backed framwork?

Rrrrm, that would be a VMWare backed framework now, Nick :-)

Gavin King wrote on Nov 04, 2009 08:36:


what added value do we get from a VC backed framwork?

Rrrrm, that would be a VMWare backed framework now, Nick :-)

Oh right! Forgot about the deal. But the point stands, if company X pays big bucks for something, they will want to have their ROI even if it means twisting the product to whatever their needs happen to be.

Sounds a but FUD:dy but it's not paranoia if they really are out to get you ;-)

That is a little bit like the impression SpringSource's (that would be VMWare now, too ;-) lack of interest in the DI standard (JSR-330) they actually had SpecLead responsibilities in seemed to me...

Twisting the product of course means, people not only have to buy or at least download the latest version, you can also justify the low innovations elsewhere with some changes in this area. And have people pay for training to adopt to those twists.

Arbi Sookazian wrote on Nov 05, 2009 00:51:


Perhaps a lot of these technologies, concepts and integrations, etc. are trivial for the JBoss team.  Not for me and other corporate developers in the real world.  I spent hundreds of hours over the last few years learning EE 5 and Seam, etc. and still don't consider myself a master by any means.

Remember, just b/c it's trivial for you (someone who designed and implemented an ORM technology, for example) does not mean it will be trivial for everyone else.

Totally agree with you here.

Is it trivial to use Hibernate with legacy db schemas that don't have proper referential integrity (i.e. foreign keys) defined in all the places they should be defined?  Most likely not, and then you may choose to use iBATIS or Spring JDBC (yes, I know Hibernate supports stored procs but JPA 1.0 does not AFAIK).

It is not trivial, of course (it is not even trivial to deal with nulls between different JPA implementations)

One of these days, web app technology with AJAX and distributed tx's and HTTP/REST will be very old school.  Isn't the Commodore 64 completely forgotten now?

I can not wait for the day when the world finally leaves AJAX, HTTP and REST behind!

Perhaps a lot of these technologies, concepts and integrations, etc. are trivial for the JBoss team. Not for me and other corporate developers in the real world.

I didn't say that you had to personally do it. But someone will do it. That's the value of having a standard like CDI and the portable extension SPI: it's a common environment that open source framework developers can target. I certainly hope that JBoss are not going to be the only folks building portable extensions for CDI. The whole idea is to open up a new ecosystem there.

Enjoy

Kungfu Panda, please use your real name here. We're fussy about that stuff ;-)

Arbi Sookazian wrote on Nov 06, 2009 00:35:


One goal of the JPA specification was to make the technology pluggable. To enable this, the roles of container provider (the container or the side that has control of the runtime threads and transactions), and persistence provider (the provider or the part that implements the persistence API and manages the persistent entities) were defined, and a service provider interface (SPI) binds the two at deployment and runtime. A compliant JPA host container correctly implements this SPI from the container perspective. A compliant JPA persistence provider implements the SPI from the provider perspective. If both sides follow the rules, a compliant container should be able to run any compliant persistence provider implementation, and similarly, a provider should plug into any container.

Nice idea in theory (that about multiple compatible JPA implementations) not true in practice, but nice in theory.

The SPI idea is a good one...
btw, I said: Not for me and other corporate developers in the real world.

As I was saying, nice in theory, sadly we work in the real world. Unless the TCK (or something equivalent that makes it possible for the community to objectively test compatibility) because easy available interchangable SPIs will remain as only a nice dream.

But that's ok.  JBoss is human, or perhaps becoming oragnicized with OSGi compliance?

Not sure what do you mean, but I certainly hope JBossAS (and all other Jboss projects) gain OSGi support soon.

Nice idea in theory (that about multiple compatible JPA implementations)

Francisco, I'm getting increasingly annoyed with you posting the same pet issue on every single thread in every message board. The Hibernate team has many important issues to deal with like implementing JPA2 and fixing actually important bugs. The question of what exception type gets thrown when you have marked your attribute as not-null at the schema level, but not at the object level (which is more or less your own programming error) is just not one of them. So please give it a rest for f***s sake.

Unless the TCK (or something equivalent that makes it possible for the community to objectively test compatibility) because easy available interchangable SPIs will remain as only a nice dream.

The 299 SPI is part of the spec and therefore it is of course tested by the TCK.

Is it going to be as well-tested by the TCK as other parts of 299, well, no, probably not. Is it likely that there will initially be some teething problems with some kinds of portable extensions? Yes, I imagine there probably will be. However, I'm quite certain that the Open Web Beans, CanDI and Weld teams will all be very keen to work together to get the wrinkles ironed. If anything needs spec clarification, we can do that in the first maintenance release of 299.