Warning message using Wirebox standalone

Hi all,

We are seeing the following warning messages using Wirebox standalone
(i.e. we are not using Coldbox):

WARN wirebox.system.ioc.Builder The DSL dependency definition:
did not produce any resulting dependency ExtraInfo:

We are using Wirebox with simple CFCs. Is this produced when an
instance of a CFC that doesn't have any further dependencies is

And can we avoid / remove this warning?

Thanks in advance!

I get the same thing too except I’m using Wirebox as part as ColdBox. I’m not sure what is causing it though.

Within coldbox, I’ve seen it when you try to wire in an object that doesn’t exist. I’d look at the “DSL” value and ensure that the object exists.

Don’t know how it acts outside of coldbox.

  • Gabriel

It means that it was searching for a model object called brand and could not find it. It should tell you in which cfc it was looking for the dependency so you can fix it.

Luis Majano
Ortus Solutions, Corp

Thanks for the replies and sorry for the delay getting back.

I think the issue is around a particular old CFC I converted to be
used by Wirebox. Usually I do not pass any info to a CFC through
constructor (init()) arguments, but in this case I am passing in a
'brand' and a 'productionMode' as *string* arguments with defaults.
This is needed by legacy code. I would like to inject this into other
objects and if I do that I call init() manually afterwards passing the
required params if the defaults are not good enough.


<cffunction name="init" access="public" returntype="MyService"
hint="Seed with a brand and/or productionmode at this point.">
    <cfargument name="brand" type="string" required="false"
default="myBrand" />
    <cfargument name="productionMode" type="string" required="false"
default="test" />

I presume that Wirebox is trying to wire these kind of dependencies up
in some way. I understand how to inject dependencies using cfproperty,
but how do it do it using init() arguments? Or is there a way to ask
Wirebox to ignore these init() arguments?

Any and all replies appreciated!


That's a bug. Wirebox is mistaking those arguments as something that needs to be resolved to a dependency and is looking for a mapping with that name.

Luis fixed it already on GitHub so WireBox doesn't try to supply init args unless they are specifically set for that. You can ignore the warnings, or remove the constructor args, or map the CFC in your wirebox config and tell WireBox what values to pass into the arguments so it doesn't try to guess.




Hi Brad

That's super - initWith() is exactly the work-around I need for now.

While I am here - can I ask is it poor practice / inefficient to do
some thing like this when you need to get access to a wirebox

<cfset wirebox =
createObject("wirebox.config.WireboxFactory").init().getInstance() />

The getInstance() call does this:

<cfreturn new
wirebox.system.ioc.Injector("wirebox.config.WireboxMappingsConfig") />

I use this on some very busy pages and I was wondering if there is
better or more efficient way to get my wirebox instance?


Are you using WireBox inside a ColdBox framework? If so, you shouldn't need to create it at all. Just ask the framework for it, or use the BeanFactory plug-in facade. getModel("myService") calls Wirebox behind the scenes.
If you have a lot of mappings, re-creating the injector could perform rather poorly as it was more designed to be a singleton.

The WireBox injector is actually capable of registering itself in a scope for you automatically. The default is "application.wirebox". Check the scopeRegistration portion of the config. If you're using WireBox outside of ColdBox, I would create it once when the app starts up, allow it to persist itself in application, and reference it there.



Hi Brad

I am using Wirebox outside of ColdBox.


If you're using WireBox outside of
ColdBox, I would create it once when the app starts up, allow it to persist
itself in application, and reference it there.

The problem there is that it means I need to reference the application
scope - something I would prefer to avoid - however if there is a
performance hit then I think I might have to look into this.

Thanks for the feedback!