-
1. Re: It's not about dependency injection
asookazian Nov 4, 2009 6:41 AM (in response to asookazian)And if you are talking about a
better Spring
, 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.e. no connection leaks and boilerplate code). In some cases JPA and/or Hibernate is not a good option for legacy schemas which may be missing foreign keys and not in 3NF, for example. So JDBC or iBATIS (sql mapping) may be better options. Of course, we can use Spring modules as integrations in our Seam apps.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
? -
2. Re: It's not about dependency injection
gavin.king Nov 4, 2009 7:32 AM (in response to asookazian)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.
-
3. Re: It's not about dependency injection
nickarls Nov 4, 2009 8:30 AM (in response to asookazian)
Arbi Sookazian wrote on Nov 04, 2009 06:41:
People are going to evaluate EE 6 and askwhat 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. -
4. Re: It's not about dependency injection
gavin.king Nov 4, 2009 8:36 AM (in response to asookazian)
what added value do we get from a VC backed framwork?Rrrrm, that would be a VMWare backed framework now, Nick :-)
-
5. Re: It's not about dependency injection
nickarls Nov 4, 2009 10:14 AM (in response to asookazian)
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 ;-)
-
6. Re: It's not about dependency injection
asookazian Nov 5, 2009 12:51 AM (in response to asookazian)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 betrivial
for everyone else.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).
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?
-
7. Re: It's not about dependency injection
keilw.werner.keil.gmx.net Nov 5, 2009 4:32 PM (in response to asookazian)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.
-
8. Re: It's not about dependency injection
luxspes Nov 5, 2009 4:33 PM (in response to asookazian)
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'strivial
for you (someone who designed and implemented an ORM technology, for example) does not mean it will betrivial
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!
-
9. Re: It's not about dependency injection
gavin.king Nov 5, 2009 4:47 PM (in response to asookazian)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.
-
10. Re: It's not about dependency injection
babumanoharan Nov 5, 2009 11:33 PM (in response to asookazian)Enjoy
-
11. Re: It's not about dependency injection
gavin.king Nov 5, 2009 11:43 PM (in response to asookazian)Kungfu Panda, please use your real name here. We're fussy about that stuff ;-)
-
12. Re: It's not about dependency injection
asookazian Nov 6, 2009 12:35 AM (in response to asookazian)perhaps that is his real name (e.g. Marilyn Manson and Hollywood actors). and does it really matter? It's bad enough that we're forced to use action-based MVC frameworks in the real world like Struts 1.x and Spring MVC. I'm really starting to get a feel for how unnecessarily complex and over-complicated Spring 2.x framework really is... Missing Seam... Juergen Hoeller is a dork.
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.http://java.sys-con.com/node/366275
The SPI idea is a good one...
btw, I said: Not for me and other corporate developers in the real world.
But that's ok. JBoss is human, or perhaps becoming
oragnicized
with OSGi compliance? -
13. Re: It's not about dependency injection
luxspes Nov 6, 2009 2:41 AM (in response to asookazian)
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 becomingoragnicized
with OSGi compliance?Not sure what do you mean, but I certainly hope JBossAS (and all other Jboss projects) gain OSGi support soon.
-
14. Re: It's not about dependency injection
gavin.king Nov 6, 2009 2:54 AM (in response to asookazian)
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.