Boy, its really time to go open source with the persistence tier. I am tired of the german BEA Kodo support and i am tired to have this guilty feeling when reverse engineering closed source code. Perhaps even writing about this could bring me into jail. But anyway…. to the topic.
It seems that i am the only person on the planet using Horizontal mapping with Kodo 3.x who has made the big mistake to make a typo in the JDO mapping file. With this mapping you can declare the parent attribute mappings in the child JDO file by using <extension vendor-name=”kodo” key=”jdbc-field-mappings”>.
One of my parent attribute mapping definitions had a typo in a way that used the wrong name for an attribute like this:
So i typed elephont even though the attribute in the BasicClientMetaData object is named “elephant”. Normally Kodo reports with a error message that signals that the name doesnt match with the objects attribute but not so with this specific mapping. There you get :
kodo.util.UserException: java.lang.NullPointerException at kodo.query.AbstractQuery.executeWithArray(AbstractQuery.java:844)
The experienced programmer now thinks that this cant be too hard to solve, you only have to look at executeWithArray() in the AbstractQuery class (which basically means you have to decompile only one class), but then you encounter something which could have been solved better:
Of course AbstractQuery is only the entry point for a Kodo query and the Nullpointer gets wrapped so that you cant see the exact place of the error in the console. Of course you can debug the catch block and see what implicit “stacktrace” list object “e” has. But this makes it unecessarily complex.
Unfortunately i ended up decompiling some more classes because i have not looked at “e” in the beginning and followed the method calls from AbstractQuery to the lower layers. The way of coding is really questionable because i have a complete different problem in the support queue (for a long time now of course) which looks like the same error. Its the same NullPointer at the same code spot. But this is of course nothing which surprises me because the real problem is not readable in the console stacktrace as mentioned before.
What really makes me mad is that i have to go through this (meaning doing something which feels illegal). I really tried hard to provide a testcase for the error i still have with horizontal mappings and custom field mappings and nobody at BEA (germany) seems to have a clue. I mean, its not that hard to debug if you have the code. I would have found it in a few minutes with the code at hand. Just to remember, i had to decompile the relevant classes which were not obvious for me in the first place and had to put the new Kodo sources for the mentioned classes before the library JAR classloader so that it takes my kodo classes and not the original ones residing in the kodo-runtime.jar (because you cant debug with a decompiled source and the original class because of changed line numbers).
All in all this reminds me how cool open source is. I mean, i am quite good in reading code (when i am not doing work for direct customer projects, i am java consultant, so i am constantly reading code from other developers in various projects), which puts me in a position where its normally not a big deal to find bugs or to see what i am doing wrong with the API.
If i have some time this year, i will finally start migrating to OpenJPA. The last two hours would have been better spent in migrating to JPA instead of decompiling old Kodo classes but as usual, the problem had to be solved, no matter how. I think i will keep the decompiled classes, perhaps i can also solve the issue which is still in support-line-mode and the good thing is, if my business completely fails, i always could ask BEA to hire me for Kodo second level support :)
Previous Topic
