After struggling a long time with the library, which kept complaining in the log about a NullPointerException and a follow-up about a missing protocol I had to surrender. The library kept it's secrets tightly to it's chest.
While I was thinking about this, thoughts about magicians that pulls rabitts out of black hats came to my mind. The analogy is that the library pulls some configuration out of the Black Hat, but I did not have a clue of what to put in it to satisfy the library. The configuration file contained a property name protocol but it did not make any difference what value I supplied for it.
When I arrived at work a coworker was struggling with an exact analogy. He was using a low-level library (a sort of Data Access component), which was dependent on the HTTP session via JSF FacesContext. The is no recipee for success when using the library in a Axis 1.4 Webservice. Axis does not expose the HTTP session in any way, but some sort of manipulation of Axis could have solved it (e.g. sublassing the Axis Service servlet or with AOP) This is obvious a horrible dependency, but luckily we could get access to the source code and easily patch it.
My coworker coined the phrase I had been thinking of for libraries and components that pulls data from unknown sources as pulling from a black hat.
Another coworker who had been working a lot with this library said this dependency had caused him a lot of trouble while writing JUnit tests. I happen to be Testinfected, and believe libraries/componentes that make Unit tests hard to write should be considered candidates for refactoring and even replacement.
If you encounter Black Hat dependant libraries or components that makes Unit tests hard to write, consider your options:
- Do you have the the source code?
- Can you change it?
- Is it easy to replace? In the long term it can harm your project.
- Do you need it? Can you develop a replacement with the same or less effort as the hazzle struggling with it?
