This post originated from an RSS feed registered with Java Buzz
by Marc Logemann.
Original Post: sad state of Kodo after the merger
Feed Title: Logemann Blog
Feed URL: http://www.logemann.org/blojsom/blog/default/?flavor=rss2
Feed Description: Marc's thoughts on Java and more
i ve been thinking for some time if i should blog about this topic or not because i like most of the solarmetric guys like Patrick, Abe, Neelan and others but as i got an email from another kodo user who experiences the same problems after the merger, i think its only fair to blog about. Even though its hard because i love kodo.
To be precise now: The quality of support drastically decreased since the merger. You dont get detailed answers on your questions and statements like "its no a bug, it used to be this way" seems common these days. BTW i dont think that leaving out IDs is a feature of a sequence generator class. No matter what. And i am also quite sure that in previous versions, i have never had any holes in my sequences. This just a short notice. I had about 6 questions after the merger, two of them were trivial and were answered instantly, the other 4 were a little bit more advanced, there you have turnaround times that are beyond imagination.
So now i want to use Kodo4. After all i am happy that i got the key finally, because i was not listed as a valid customer. There seemed to be a major problem in transfering customer data from one database (solarmetric) into another (bea). Also as a nice side effect, about 3 open cases were lost because of the transition of the bug database. At the end, nobody could tell me where the cases are. I had a hard time to remember them and to re-enter into the bea customer support system, which is a web based monster where you can click 1323 times before you reach the "create case" button. And btw, i love the pages where you get confronted with the FAQs before you can submit a case. I allways though i am paying for support and people can really believe me that i go through docs before i post a "case". Especially with this bug system.
But docs is another interessting story. The transition from kodo3 to kodo4 is not a no-brainer, so i had to search for some API docs but guess what? There are none. I downloaded the kodo4 distro and the docs folder was completely empty. Wow. Then i searched online and was happy to see "API javadocs", but the overall content of that was about 20 classes. Of course thats not all. So where are the docs?
I also heard that kodo4 will have brilliant Spring bootstrap classes. At this point, i can only say that my current bootstrap approach (outlined in the Spring wiki) doesnt work at all anymore because JDBCPersistenceManagerFactory doesnt use JDBCConfigurationImpl anymore. Of course i ve not seen any examples how to bootstrap kodo4 with Spring and this even both companies have announced the greatest partnership of all times. Wouldnt one expect at least some lousy lines in the docs how to bootstrap that kodo4 thingy with the most modern JavaEE framework in the world, called Spring? Perhaps i have to google some more but using a commercial tool, i am expecting more than googling for things like this for hours. If this is what i want, i could also use Hibernate, right?
At this point, i am thinking about switching to JPA in the mid term, not because its better than JDO2 (its the other way around) but because its free and its open source. Here i dont need to look for missing javadocs, i could just check the source for myself and easily create add-on classes. This would also make the support contract obsolete. Perhaps this is exactly what bea wants, but then they should announce it. I even found out that the JPOX docs are in some areas more intuitive and as we all know, this is an open source project.
Lets see if i can bootstrap kodo4 with Spring 1.2.x anytime soon, i have allready spent 1,5 days without luck (and useful help). And for all Kodo3 users out there. Dont try to think that the migration will be smooth to Kodo4. If you use some more advanced stuff like custom mappings or custom Filters, you will have to rewrite a lot of things. And dont think you can go with the old metadata. There are compatibility switches but again, they dont cover everything, especially not the enhancement part, which has problems with old "detachable" syntax for instance (bea support called detaching exotic, thus no kodo 3.x style supported under kodo4 - whatever exotic means here...)
When i am through this hell, i will blog about what to look out for when doing the migration....
Previous Topic
