+1 for looking at source to find your answer
Originally, plugins took care of their own object creation. Around ColdBox 3 or so, we switched the plugin service over to use WireBox behind the scenes. I vaguely even remember “new” possibly being deprecated though there’s nothing in the comments saying that was on purpose.
In ColdBox 4, we’ll be getting rid of plugins (by that name) and just treating them as models so you’ll just be asking Wirebox for them just like any other service, bean, library, etc.
So, with that being said we’re unlikely to roll out any changes to getPlugin() since we’re about to deprecate it. What I would actually recommend is seeing if you can just switch over to using WireBox now to get your CFCs. It’s basically the same thing (which is why we’re simplifying the whole process). The only real catch is if you are using any of the frameworksupertype methods or the auto-injected references to logbox, cachebox, wirebox, etc you’ll want to still extend coldbox.system.Plugin or just start auto-wiring those bits yourself.
Now, WireBox doesn’t have any concept of overriding a mapping persistence at the time you request it (which is most likely why that functionality got lost). In WireBox you create a mapping with the persistence properties you want and then just request it. So, if you want to be able to request a mapping that is a singleton as well as a mapping that is a transient (even if they point to the same CFC), you create two mappings in your binder config (WireBox.cfc) and request the appropriate one.
And then do getInstance(“longLived”) and getInstance(“shortLived”).
Also, keep in mind that the DSL in your binder config overrides the annotations in your actual CFC. That means you can simplify your life and put the default persistence settings in the CFC’s annotations and only create a mapping manually for the override.
ColdBox Platform Evangelist
Ortus Solutions, Corp
ColdBox Platform: http://www.coldbox.org