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.
DougHughes.net 
Comments on: "IM Gateways and ColdSpring: Odd Behavior and a Workaround" (2)
Sounds like the same issue that affects any external invocation of remote proxies. Unless you use lazy-init=”false” and constructNonLazyBeans=”true”, you have to actually do a getBean() on the target before it creates the bean. If you use constructNonLazyBeans=”true” (which may be the default in the latest version of CS) then you just need to make one request to the app first to have CS initialize and create all the beans that are marked as lazy-init=”false”. Does this sound like the issue you are having?
LikeLike
Yeah, that’s exactly the issue. I hadn’t heard of it before. I was assuming that it would load the defs and then create any bean requested at the time that it gets requested regardless of the type of request being made.
Interesting!
At this point I’m having great success with just lazy-load shut off… it must be that constructNonLazyBeans is defaulted to true then, because the IM gateway has been performing fabulous since I made the change.
Thanks for the input.
LikeLike