Event 'afterInstanceCreation' unnecessarily published on singleton objects


When you listen for the event 'afterInstanceCreation' on a regular request and when handler cache is 'true', you will notice that this event is fired off multiple times for a handler. An example is a newly created app will fire the event twice for 'handlers.Main'. Once for 'Main.onRequestStart' and then again for 'main.index'.

The event 'afterInstanceCreation' seems to describe the moment after an instance of an object has been created. For singleton objects, I would expect to see this fired off only once during the lifecycle of the singleton scope cache.


Joel Tobey
December 30, 2017, 3:18 PM

If this is something you feel should be done, I'm happy to fork and give it a go. I would think of checking for an existing instance and returning immediately if it does. Otherwise, I would continue the flow and fire off the 'afterInstanceCreation' event after it's done.

Luis Majano
December 30, 2017, 4:30 PM

I would agree with this ticket . Can you point where in the code is the discrepancy? And please, yes fork away and send pull requests

Joel Tobey
December 30, 2017, 8:22 PM

I just created a pull request. I'm happy to fix any issue you find with it. Please let me know.

Joel Tobey
December 31, 2017, 3:48 AM

I was just thinking about this. I don't like how with my pull request, it now checks twice every time if it exists. Once in the getInstance() method with the exists() call and again within the getFromScope() method. Since the logic to create the instance is orchestrated within the scope, maybe the 'afterInstanceCreation' event should be fired off within the getFromScope() method when applicable. The only thing I don't like about this is that we have to make sure each scope fires the event correctly instead of that logic being in one place. I'm going back and forth on this one. Thoughts?



Luis Majano


Joel Tobey


Fix versions