kcw | journal | 2004 << Previous Page | Next Page >>
All week I've been working on this bug. Here's a breakdown.

Monday: Working on something else. Or maybe just goofing off after last week's hard work.

Tuesday: First I had to make sure my environment worked. It's the Cisco CallManager adapter which runs on Windows machines only because it's compiled C code. I couldn't log in to a teleset but communication to the ICM server seemed fine so I didn't worry too much. Spent the rest of the day tracing through code and trying to figure out what I needed to change.

Wednesday: Coding. Only one file is changed in the Java layer. In the C layer several files were changed. I decided to mirror another function and changed all files that the mirrored function exists in. Of course this doesn't prove anything since it's an API. Then I had to code some function calls into the ICM-CM adapter and it crashed.

Crashed without any sort of error which I hate. You can install something so that crashes at least show a dialog box. The problem with C is that if you're not careful a crash doesn't give you any meaningful information. Java will at least dump everything to the console assuming you're using a console. If you're not then Java also fails relatively silently, though a few universal try-catch blocks help a whole lot.

Painstakingly add more log messages. Compile, run, crash. Change a line of code here, a line there. Compile, run, crash. Slowly narrow it down to a specific line. Huh, an error finding the Java method? I'm sure I coded the Java method correctly. Check and recheck -- have no idea what's wrong. Give up for today and on my way home I have a sudden thought: what if the changed Java file is not being used?
Thursday: So one of the problems with the ICSM is that the Java classpath is sort of hidden. There are several places where we pick up Java code and if you're not careful test code doesn't take. So I write a message in the Java class which doesn't up in the logs. Aha! Classpath problem. I move the test class up and now it's being used.

Go back and do the full test and it works! Now to delete the log code. On a whim I want to test the callback API which Aravind added a long time ago. And that doesn't work. I'm getting a Null Function Pointer error. What the? Consult Aravind and apparently he's never tested the API. Sigh.

Trace through the ICM-CM adapter and libraries. Ok, I think the API was never fully implemented. Copy code from a similar API and make several changes in several files. Won't compile. Fix compilation errors, changing some method signatures. Now it compiles but I'm worried I missed something. Test it and now the callback API works, though I'm still worried I made a change that would incompatible with existing 3rd party C adapters.

Friday: I have 6 ARUs to build, an ARU being an official patch in our patch system, though few ARUs are released to customers. It's double the work because I have to build separate ARUs for two different code branches. And I have find out how to replace the SDK ARUs -- the standard ARUs I know how to work with. The SDK ARUs are just zip archives we upload.

Anyway, after a lot of work I build four ARUs. The last two are one-off patches which I can build later if a customer requests it. If a customer isn't going to request it soon, they can wait for a regular roll-up patch. And I'm done and I didn't get any UT testing done.
Copyright (c) 2004 Kevin C. Wong
Page Created: December 5, 2004
Page Last Updated: December 5, 2004