In my last project I wrote some scripts to handle the automatic integration of libraries from different Version Control Systems into our source code repository.
I wrote a script to generate an XML file, that served as input for an existing perl script.
To generate the XML file I used a groovy script which described the dependent components and the revision as well as the platform dependent location in the VCS (which is omitted here).
Processing this file is a pretty straightforward task.
The reason why I'm writing this up, is to tell that I spent a good amount of time, figuring out if there is a bug in the underlying ConfigObject. The ConfigObject is created by ConfigSluper().parse(...) and represents the data in-memory. Since ConfigObject inherits from LinkedHashMap, one can assume (and I really did!), that the semantics are like using a HashMap. But I was wrong! There happens some _magic_, when you do the following:
In my script there was a piece of code that relied on the sub-node count of the Component node. At a certain point, I was really convinced that I found a bug. But that would have been too obvious IMHO, that this kind of misbehavior had slipped through all testcases.
To make a long story short. I did some investigation and found the reason in the implementation of the ConfigObject
You can find the secret (if you will) in line 8. If you access a key in the ConfigObject that doesn't exist, then there will be an empty one created on the fly. This is not really bad, as long as you don't rely on the amount of nodes before and after querying the ConfigObject.
No comments:
Post a Comment