I’ll blog about this later, but I’m writing a time tracker that uses a Model-Glue application for user and project management and reporting and a Google Talk IM gateway for input. The idea is to create a simple IM-based command line to allow us to input and log our tasks in a database as we go through our days and then be able to pull our timesheets directly from the database. My architecture is simple… it’s a basic implementation of the Command pattern and the commands are registered with ColdSpring so that the first word in a message sent to the gateway has to match a bean registered in ColdSpring.
Simple example: if you send the word “time” to the IM gateway, you get back the date and time. Internally, the gateway fetches the CS beanfactory from the application scope and calls beanfactory.getBean(“time”).execute() and returns the result (a string) to the IM user. I’ll get into the actual architecture in another blog post, but I needed to lay out that much background in order to get on with the rest of this post.
I was perpetually getting ColdSpring errors saying the beans weren’t available. It made no sense, because my HTML pages could get to the beans just fine… the only place I would get these errors was through the IM gateway. To make it even stranger, if I’d run the homepage for the app and then a test HTML page I created in the same directory as the gateway CFC, suddenly my beans would show up again. And, as things often get weirder before they get saner, I have all the calls to the getBean() wrapped in <cfif BeanFactory.containsBean(foo)> and that would pass!!
So I could get to the BeanFactory in the application scope, and containsBean() said it was in the config file, but getBean() would blow up claiming the bean didn’t exist… very odd. And I haven’t yet quite figured out what to do about the actual problem… but I DID find a workaround.
The fix I found was this: by adding lazy-init=”false” to my command beans within the ColdSpring config file, I was able to get these errors to go away.
The moral of the story? Know your Spring/ColdSpring config file options for the bean tags, because one day that bit of knowledge may save you a great deal of pain, frustration, and lost time.