The Heavyweight Champions are... Springframework and Hibernate?

There are a lot of argumentations exist trying to proof whether a combination of Springframework and Hibernate is still a "lightweight" or already a "heavyweight" champion. Please see following discussions in TSS for some of arguments:

• Ten Common Misconceptions about Spring
• Developing J2EE applications without Spring? Why?
  

My conclusions after working with Springframework and Hibernate in some of my projects are: yes, Springframework and Hibernate are already our heavyweight champions! Why?

1. It's getting on my nerves as I have to create SpringBeans by editing those Spring XML files. This is the same with Hibernate hbml files. I know there are some tools available (e. g. Spring and Hibernate plugins) to help me finish these annoying works. But still... at the end this is just the same as working with EJB 2.x with those deployment descriptors. You might say, I can use annotations. The problem is I still have to deploy in JDK 1.4.x. So annotations just won't work. I also know that Springframework 2.0 uses XML schema so the XML files are easier and shorter to create, but again, I hate creating XML files by hand and you?
2. Special for Springframework XML files and this is often the case: you need one XML file for remote client context, one XML file for local client context and one XML file for test? Gee, how many XML files should I write or copy and paste plus edit?
3. Hibernate should protect us from the database behind it. Is this true? Until a certain level yes, but if you try to work with Oracle and at the same time with MySQL you will still need to understand the differences between those databases! Do you know that Oracle always saves "" (empty string) as a null value? And this is not the case with MySQL! So welcome back to the relational database!
4. Do you know how many methods do we have in Hibernate just to persist or create a new object? What are these methods actually for: save, saveOrUpdate, persist, merge? Man, in SQL we just have one command: insert! Do we really need those different kind of methods just for a simple thing? Why can't we just say "save" and everything will be taken care by Hibernate?
5. I think you already heard a lot about architecture discussion to DTO or not. If not you can check out some interesting discussion in Springframework forum: Transfer Objects. You also can find the same discussion in TSS: Protecting the Domain Model. So, what's the hell why we use POJO if we still have to use DTO? You don't need to use DTO at all - many of us would loudly say, but what if we need to physically separate the tiers? In this case you will meet the most hated exception in Hibernate: Lazy Loading error if you are not carefully design your POJO! So sometimes we need DTO and sometimes not?
6. If you are by fall putting something wrong in the XML files - both Springframework and Hibernate - (not syntactically because your schema will help you in this case) and you get some errors because of these things. Good luck and have fun trying to find them!

So what are your options?

1. Accept those points above and be sure to know them best. Why not? You think, the combination of Springframework and Hibernate is still easier to use than EJB 2.x? More flexible than EJB 3.x? Yes, you are right. So, better to have a bad solution than no solution at all. Wow, you are what I call a pragmatic Java programmer.
2. Use AndroMDAwith the Springframework and Hibernate cartridges. Oh my, I don't want to have something to do with MDA and UML. But what are the advantages of AndroMDA? No need to create those damn XML files - both for Springframework and Hibernate - by hand. You have a standard architecture which will be strongly followed by everyone in your team (if you have one) all the time. Nothing like sometimes with DTO, sometimes without DTO. But still you need to implement those DTOs! Yes, but at least you have the skeletons created for you.
3. Build your own Dependency Injection and your OR mapper framework which are far better than Springframework plus Hibernate and don't forget at the end you should put them as Open Source products and release them through TSS news :-) So we all can admire your new products: oooh a new very easy framework but also it can support any complex situations (= all you can eat framework - and yes, Springframework is probably getting in this direction too. Of course you don't need to use everything but... we have that, we have this, ... You know what I mean).
   

It seems that using the option number 2 you will get back those "lightweight" Springframework with Hibernate (no XML files - they will be generated and we always use the same architecture everywhere)? It could be. With the price of using UML? Is this still "lightweight" or we just move our weight somewhere else? At the moment I prefer to use the option number 2 as I feel that I have lot more advantages in comparison of using the option number 1 or 3. But this should not be a general case and should be proven case by case!
Allright, at the end I admit that there are actually no "heavyweight" or "lightweight" frameworks, everything are relative to what exist and to what you know. In any case just take one of your options above and try to solve the problems you need to solve for your customers.
Happy coding and greets,
Lofi.