Is this part if a ColdBox app, or WireBox standalone?
What if you run a shutdown() on WireBox when reinitting?
Also is there a chance of scope-widening injection of the injector? For instance, placing a reference to WireBox inside an application, server, or session-scoped object that might be holding a reference to an old injector after you’ve reinitted and created a new one.
I was getting an error with the shutdown method related to trying to shutdown cacheBox. I’m not currently using cacheBox so the instance.cacheBox variable wasn’t set in the injector which caused the instance.cacheBox.shutdown() command to fail (line 190 in wirebox-1.5). I made a small change to the shutdown method in “wirebox.system.ioc.Injector” to get it to work.
The original code was:
// standalone cachebox? Yes, then shut it down baby!
if( NOT isColdBoxLinked() ){
instance.cacheBox.shutdown();
}
I changed it to:
// standalone cachebox? Yes, then shut it down baby!
if( isCacheBoxLinked() ){
instance.cacheBox.shutdown();
}
With the change, the shutdown completes without errors, but if I should be doing something else please let me know.
I’ll try this out in our test environment as see if it resolves the issue.
I have been doing a lot of reinit’s today after adding the shutdown() to my reinit script, and we have had a pretty decent amount of activity on the server. The error only showed up once, which is a pretty big improvement. It happened to an active user, right after I did the reinit. I did another reinit and it fixed the problem.
I’m pretty sure this error will go away once I stop doing the reinit on our testing server… it’s such a time saver though I’m having a hard time forcing myself to restart the app server.
Thanks for all the assistance, and I will let you know if anything changes.
Using a reinit is a brute force of restarting ANY container and in all reality it should be a development tool and not a production approach. With that said, using force reinits can cause side effects in ANY system.
A better approach would be to leverage the ColdFusion “applicationStop()” approach.
Good points. Doing something like a reinit in a production environment would be a bad idea. My main concern with this issue is understanding what is causing it before moving my application into production. I am reasonably sure now that it only shows up after a reinit is done in a shared testing environment, so I am much relieved.
Thanks again for the assistance and for making this excellent set of tools available to the community.
Just wanted to let you know that I was able to confirm that this error is a bug (or incompatibility) with Railo 3.3.1.
I started adding “eagerinit” annotations to some of my singleton components and as soon as I did that this error showed up every time. I ran some tests with Railo 4.0.2 and there were no errors.
There has been a bug related to flex integration in Railo since rev 3.3.1, which has been preventing me from upgrading. The fix is in progress, so hopefully I’ll be able to upgrade soon!