This release is part of the ColdBox 5.0.0 upgrade and it is a major release. Below you will find the major areas of improvement for WireBox and the full release notes.

Error Reporting

We have done greats strides in consistency of error reporting during the creation of objects and their wiring. We have also added countermeasures for rogue mappings that could bring entire applications down. You will now get more consistency and better error reporting overall.

AOP Performance

AOP now performs in over 70% faster than previous implementations. In previous versions, we would create intermediate class files that would then be loaded and injected as part of the AOP proxies. This took time and not only that, it would create 1 stub per call to a method implementation. Our strategy worked but lacked performance. In 5.0.0 we completely re-architected the way we did method injection and stub creation. We now take md5 hashes of the source code to be injected and only created the stubs 1 per-lifetime. The improvements are drastic and amazing. Enjoy AOP and don't hold back!

DI Performance

We have moved from an instance scope approach to a variables scope approach with accessors and mutators in 5.0.0 and yet again we benefit from CFML engine speed improvements. Again, thanks to the community for many pull requests.

Virtual Inheritance

We have completely re-engineered virtual inheritance in 5.0.0 and it behaves eerily similar to traditional inheritance at the dynamic level. Not only do we cover public methods like we used to, but also private methods and object state. You can also leverage AOP with virtual inheritance now which was a limitation in the previous version.

We have also added the capability to inherit implicit getters and setters from parent classes.

Listener Registration

You now can register listeners on-demand with WireBox via the registerListener( listener ) method in the Injector.

New onLoad(), onShutdown() Binder Callbacks

Any WireBox binder can now have two new callback methods onLoad(), onShutdown(). The onLoad() is called once WireBox has loaded with logging, caching, and the configure() on the binder has been called. You can use this for leveraging mapDirectory() calls which require the entire event system to be online or any other type of execution that leverages the entire machinery to be online.

The onShutdown() callback is a nice way to shutdown services as you see fit.

function onLoad(){
    mapDirectory( "commandbox.commands" );
}

Binder Is An Interceptor

Release Notes

Bugs

New Features

Improvements

Improvements

Bugs

This minor release brings in some major performance enhancements for the way WireBox maps and creates objects. We highly encourage upgrading to it.

Compatibility Notes

If you are using annotations for component aliases you will have to tell WireBox explicitly to process those mappings. As by default, we no longer process mappings on startup.

New Feature

Improvement

 __          ___          ____
 \ \        / (_)        |  _ \
  \ \  /\  / / _ _ __ ___| |_) | _____  __
   \ \/  \/ / | | '__/ _ \  _ < / _ \ \/ /
    \  /\  /  | | | |  __/ |_) | (_) >  <
     \/  \/   |_|_|  \___|____/ \___/_/\_\

WireBox Manual - Version 5.x

WireBox is an enterprise ColdFusion Dependency Injection and Aspect Oriented Programing (AOP) framework. This project has been part of ColdBox since its early version 2.0 releases but it is also a standalone library that can be used in ANY ColdFusion application or framework. WireBox's inspiration has been based on the idea of rapid workflows when building object oriented ColdFusion applications, programmatic configurations and simplicity. With that motivation we introduced dependency injection by annotations and conventions, which has been the core foundation of WireBox. We have definitely been influenced by great DI projects like Google Guice, Grails Framework, Spring and ColdSpring so we thank them for their contributions and inspiration

Versioning

<major>.<minor>.<patch>

And constructed with the following guidelines:

• Breaking backward compatibility bumps the major (and resets the minor and patch)

• New additions without breaking backward compatibility bumps the minor (and resets the patch)

• Bug fixes and misc changes bumps the patch

License

• Copyright by Ortus Solutions, Corp

• ColdBox is a registered trademark by Ortus Solutions, Corp

Info: The ColdBox Websites, Documentation, logo and content have a separate license and they are a separate entity.

Discussion & Help

Reporting a Bug

Professional Open Source

ColdBox is a professional open source software backed by Ortus Solutions, Corp offering services like:

• Custom Development

• Professional Support & Mentoring

• Training

• Server Tuning

• Security Hardening

• Code Reviews

• Much More

Resources

HONOR GOES TO GOD ABOVE ALL

Because of His grace, this project exists. If you don't like this, then don't read it, its not for you.

"Therefore being justified by **faith**, we have peace with God through our Lord Jesus Christ: By whom also we have access by **faith** into this **grace** wherein we stand, and rejoice in hope of the glory of God." Romans 5:5

This release is part of the ColdBox 4.2.0 update and contains the following updates:

Bug

New Features

Improvements

Introduction

WireBox 2.0.0 is a major release of our Dependency Injection and AOP library with some major fixes and some cool new updates.

Release Notes

Bugs

Improvements

New Features

Major Enhancements

ColdBox DSL Updates

The ColdBox injection DSL has had major updates to get to the ColdBox 4 standards.

• All ocm injections have been removed in preference to

  cachebox injection DSL

• The coldbox:cachemanager DSL has been removed in preference to

  cachebox injection DSL

• All plugin injections have been deprecated in preference to

  model/object injections

• New coldbox:renderer dsl to inject the new ColdBox system

  renderer

Forced Mappings

The map() function on the Configuration Binder now has a force argument which allows you to map no matter if the mapping exists or not already.

Dynamic Custom DSL Registration

Injectors allow you to register custom DSLs at runtime by using the registerDSL() method on any injector. This feature was mostly done for modules, so they could enhance WireBox in a ColdBox context. However, this also allows you to leverage this in any non-ColdBox applications.

Injection By Type: byType DSL

We have expanded our custom DSL and injectors to allow you to do injection by ColdFusion types. This feature is more in-line with features from Java or static languages were you can tell injectors to inject by argument or property type. Let's say you have a package of interfaces with subpackages of implementations:

You then want to rely on the interface type field of properties in my dependent CFCs and leveraging the byType injection DSL. You would first map the right implementation using the alias as the name of the Interface.

• The majority of code examples in this book are done in cfscript.

External Trademarks & Copyrights

Flash, Flex, ColdFusion, and Adobe are registered trademarks and copyrights of Adobe Systems, Inc. Railo is a trademark and copyright of Railo Technologies, GmbH.

Notice of Liability

The information in this book is distributed “as is”, without warranty. The author and Ortus Solutions, Corp shall not have any liability to any person or entity with respect to loss or damage caused or alleged to be caused directly or indirectly by the content of this training book, software and resources described in it.

Contributing

Charitable Proceeds

Shalom Children's Home

Shalom now cares for over 80 children in El Salvador, from newborns to 18 years old. They receive shelter, clothing, food, medical care, education and life skills training in a Christian environment. The home is supported by a child sponsorship program.

We have personally supported Shalom for over 6 years now; it is a place of blessing for many children in El Salvador that either have no families or have been abandoned. This is good earth to seed and plant.

Dependency injection is the art of making work come home to you. Dhanji R. Prasanna

Dependency Injection Explained

Advantages of a DI Framework

Compared to manual Dependency Injection (DI), using WireBox can lead to the following advantages:

• You will write less boilerplate code.

• By giving WireBox DI responsibilities, you will stop creating objects manually or using custom object factories.

• You can leverage object persistence scopes for performance and scalability. Even create time persisted objects.

• You will not have any object creation or wiring code in your application, but have it abstracted via WireBox. Which will lead to more cohesive code that is not plagued with boilerplate code or factory code.

• Objects will become more testable and easier to mock, which in turn can accelerate your development by using a TDD (Test Driven Development), BDD (Behavior Driven Development) approach.

• Once WireBox leverages your objects you can take advantage of AOP or other event life cycle processes to really get funky with OO.

Features at a Glance

Here are a simple listing of features WireBox brings to the table:

• Annotation driven dependency injection

• 0 configuration mode or a programmatic binder configuration approach via ColdFusion (No XML!)

• Creation and Wiring of or by:

  • ColdFusion Components

  • Java Classes

  • RSS Feeds

  • WebService objects

  • Constant values

  • DSL string building

  • Factory Methods

  • Providers

• Multiple Injection Styles: Property, Setter, Method, Constructor

• Automatic Package/Directory object scanning and registration

• Multiple object life cycle persistence scopes:

  • No Scope (Transients)

  • Singletons

  • Request Scoped

  • Session Scoped

  • Application Scoped

  • Server Scoped

  • CacheBox Scoped

• Parent Factories

• Factory Method Object Creations

• Object life cycle events via WireBox Listeners/Interceptors

• Customizable injection DSL

• WireBox object providers to avoid scope-widening issues on time/volatile persisted objects

WireBox RefCard

Useful Resources

We touched briefly on singleton and no scope objects in this section, so let's delve a little into what scoping is. WireBox's default behavior is to create a new instance of an object each time you request it via creation or injection (Transient/Prototype objects), this is the NO SCOPE scope.

Scope Annotations

• You can tag a cfcomponent tag or component declaration with a scope={named scope} annotation that tells WireBox what scope to use

• You can have nothing on the cfcomponent tag or component declaration which denotes the NO SCOPE

• You can tag a cfcomponent tag or component declaration with a singleton annotation

Scope Configuration Binder

Internal Scopes

Here are the internal scopes that ship with WireBox:

This is cool! We can now have full control of how objects are persisted via the WireBox injector, we are not constricted to one type of persistence anymore.

WireBox can be downloaded as a standalone framework or it is included with the latest ColdBox Platform release, so no need to install it if you are within a ColdBox application.

System Requirements

• Adobe ColdFusion 11+

• Lucee 4.5+

CommandBox Installation

This will install Wirebox as a dependency in your application into a folder called wirebox. You can then leverage the standalone namespace within your application: wirebox.system.ioc.

Manual Download

Namespaces

Standalone Namespace

wirebox.system.ioc

ColdBox Namespace

coldbox.system.ioc

Another aspect of our objects is when are they created? Good question!

By default all objects are created ONLY when they are requested, in other words they are lazy created. But what if you are spoiled and you want your stuff NOW NOW NOW! Well, you can, cry if you want to! Just tell WireBox that you want your objects to be eagerly created via the mapping DSL asEagerInit() function or a eagerInit annotation on the component.

component extends = "wirebox.system.ioc.config.Binder" {

    function configure(){

        // map with shorthand or full scope notation
        mapPath("model.Coffeshop")
            .asSingleton()
            .asEagerInit();
    }

}

/**
 * Eager Component via Annotation
 */
component singleton eagerInit{

}

The WireBox binder will also be injected with 3 methods that will allow you to talk to your system environment or Java system properties. This will help you with container based applications or applications that rely on environment settings/secrets.

• getEnv( key, [defaultValue] ) - Get a Java system environment value

• getSystemProperty( key, [defaultValue] ) - Get a Java system property value

• getSystemSetting( key, [defaultValue] ) - This method will retrieve a key from the Java system properties and if it does not exist, then it checks the system environment.

Luis Fernando Majano Lainez

Luis has a passion for Jesus, tennis, golf, volleyball and anything electronic. Random Author Facts:

• He played volleyball in the Salvadorean National Team at the tender age of 17

• The Lord of the Rings and The Hobbit is something he reads every 5 years. (Geek!)

• His first ever computer was a Texas Instrument TI-86 that his parents gave him in 1986. After some time digesting his very first BASIC book, he had written his own tic-tac-toe game at the age of 9. (Extra geek!)

• He has a geek love for circuits, microcontrollers and overall embedded systems.

• He has of late (during old age) become a fan of running and bike riding with his family.

Keep Jesus number one in your life and in your heart. I did and it changed my life from desolation, defeat and failure to an abundant life full of love, thankfulness, joy and overwhelming peace. As this world breathes failure and fear upon any life, Jesus brings power, love and a sound mind to everybody!

“Trust in the LORD with all your heart, and do not lean on your own understanding.” Proverbs 3:5

Contributors

Jorge Emilio Reyes Bendeck

Jorge started working as project manager and business developer at Ortus Solutions, Corp. in 2013, . At Ortus he fell in love with software development and now enjoys taking part on software development projects and software documentation! He is a fellow Cristian who loves to play the guitar, worship and rejoice in the Lord!

Therefore, if anyone is in Christ, the new creation has come: The old has gone, the new is here! 2 Corinthians 5:17

Instance Creation

1. Object is requested by name and the Injector tries to check if the mapping exists for that name. If no mapping is found then it tries to locate the object by using the internal scan locations to try to find it. If it cannot find it and there is a parent injector defined, then the request is funneled to the parent injector and we start our process again. If no parent injector is declared and no localization, then we throw a not located exception.

2. If the object was found via the scan locations, then we register a new mapping according to its location and discover all the metadata out of the object in preparation for construction and DI

3. We now have a guaranteed mapping so we retrieve it and we verify if the mapping's metadata has been processed or not. If the mapping is marked with no autowiring then we skip to the next step. If not, we process the mapping's metadata and prepare it for DI

4. We verify that the scope define for the mapping exists, else we throw an invalid scope exception

5. We ask the scope to produce the mapping object for us. The scope is in charge of persistence, locking, etc.

6. The scope builds the instance by asking the injector to build a new instance with the correct constructor and constructor arguments and stores it in its scope once the injector builds it. The builder decides what type of construction is needed for the mapping as it can be a CFC, java object, webservice, RSS feed, factory method call, etc. Each constructor argument is processed for dependency resolution.

7. The scope then sends the instance for DI wiring and process back to the injector

8. The injector returns the instance

Dependency Resolution

1. Arrive at the desired injection point and get the injection DSL. If the DSL is empty, then it defaults to the id/model namespace. For this injection DSL Namespace we try to find a valid DSL builder for it. If none is found an exception is thrown. If we have a match, then the DSL builder is called with the DSL string to retrieve.

2. The DSL builder then tries to parse and process the DSL string for object retrieval. If the DSL is a WireBox mapping then we try to retrieve the instance by name (Refer back to Instance Creation).

3. If the builder could not produce an instance, it is logged and DI is skipped on it.

If you are using your configuration binder within a ColdBox application you will have some extra goodies in the Binder that come in very handy:

• getColdBox() : Retrieve the instance of the running ColdBox application

• getAppMapping() : Get the current AppMapping, the location of the application on th server, setting for the running ColdBox application

// map the model folder
mapDirectory( getAppMapping() & ".model" );

Each configuration binder has two public properties accessible in the this scope:

1. this.TYPES : A reference to wirebox.system.ioc.Types used to declare what type of object you are registering for construction or wiring

2. this.SCOPES : A reference to wirebox.system.ioc.Scopes used to declare in what life cycle scope the object will be stored under

These two classes contain static public members in the this scope that facilitate the declaration of persistence scopes and construction types for object mappings. Below are the valid enumerations for these two classes:

this.TYPES

• CFC : Construction of a CFC

• JAVA : Construction of a Java class

• WEBSERVICE : Construction of a webservice object

• RSS : Construction of an RSS feed

• DSL : Construction by DSL string

• CONSTANT : A constant value

• FACTORY : Construction by factory method

this.SCOPES

• NOSCOPE : Transient objects

• PROTOTYPE : Transient objects

• SINGLETON : Objects constructed only once and stored in the injector

• SESSION : ColdFusion session scoped based objects

• APPLICATION : ColdFusion application scope based objects

• REQUEST : ColdFusion request scope based objects

• SERVER : ColdFusion server scope based objects

• CACHEBOX : CacheBox scoped objects

The mapping DSL is the way to configure object mappings in WireBox that will represent objects, factories or providers. All mappings DSL methods return back an instance of the binder so you can concatenate methods to create readable execution chains.

The chains are divided into three types:

1. Initiators - Start the mapping DSL process

2. Modifiers - Can modify a mapping with metadata and behavior

3. Destinations - Tells the binder to what object or behavior we should map to.

map( "Luis" )
    .to( "model.Likes.Espresso" )
    .asEagerInit()
    .asSingleton();

We do this by creating a WireBox configuration binder wirebox.system.ioc.config.Binder, which is a simple CFC that defines the way WireBox behaves and defines object mappings. This binder is then used to initialize WireBox so it has knowledge of these mappings and our settings.

The mapDirectory() allows you to leverage closures or lambdas to influence and filter mappings. The arguments are filter to add a filter that MUST return boolean in order to process the mapping and influence that can influence the created mapping with any custom bindings.

// influence only certain components to be singleton
mapDirectory(packagePath="coldbox.testing.testModel.ioc", influence=function(binder, path){
    if( findNoCase( "simple", arguments.path) ){
        arguments.binder.asSingleton();
    }
});

// filter some components from registration
mapDirectory(packagePath="coldbox.testing.testModel.ioc", filter=function(path){
    return ( findNoCase( "simple", arguments.path ) ? false : true );
});

The mapping destinations tell WireBox what type of object you are mapping to. You will usually use these methods by concatenating map() or with() initiator calls:

Here are some examples:

// CFC
map("FunkyObject").to("myapp.model.service.FunkyService");
mapPath("myapp.model.service.FunkyService");
mapDirectory("myapp.model");
// Java
map("buffer").toJava("java.lang.StringBuffer");
// RSS feed
map("googleNews").toRSS("http://news.google.com/news?output=rss");
// Webservice
map("myWS").toWebservice("http://myapp.com/app.cfc?wsdl");
// Provider
map("Espresso").toProvider("FunkyEspressoProvider");
// DSL
map("Logger").toDSL("logbox:root");

// factory methods
map("ColdboxFactory").to("coldbox.system.extras.ColdboxFactory");
map("ColdBoxController").toFactoryMethod(factory="ColdBoxFactory",method="getColdBox");
map("BeanInjector")
    .toFactoryMethod(factory="ColdBoxFactory",method="getPlugin")
    .methodArg(name="plugin",value="BeanFactory")

// Mixin a new method in my object that dispenses users
mapPath("UserService")
    .providerMethod("getUser","User");

Instead of declaring data structures you can use the methods in the binder to configure WireBox for operation. All methods return an instance of the binder so you can concatenate methods.

logBoxConfig( "config.LogBox" )
    .scanLocations( getAppMapping() & ".includes.models" )
    .stopRecursions( "model.BaseService,model.BaseModel" )
    .mapScope( "Ortus", "model.scopes.Ortus" );

The dependencies DSL methods are mostly used to define dependencies and also to activate advanced features on target objects, such as runtime mixins, virtual inheritance, etc.

Note Please note that you can concatenate more than one of these methods calls to dictate multiple constructor arguments, setter methods, cf properties, and more.

/**
* Configure WireBox
*/
function configure(){

    // The WireBox configuration structure DSL
    wireBox = {

        // LogBox Config: instantiation path
        logBoxConfig = "wirebox.system.ioc.config.LogBox",

        // CacheBox
        cacheBox = { enabled = true },

        // Scope registration, automatically register a wirebox injector instance on any CF scope
        // By default it registeres itself on application scope
        scopeRegistration = {
            enabled = true,
            scope   = "application", // server, cluster, session, application
            key        = "wireBox"
        },

        // DSL Namespace registrations
        customDSL = {
            // namespace = "mapping name"
        },

        // Custom Storage Scopes
        customScopes = {
            // annotationName = "mapping name"
        },

        // Package scan locations
        scanLocations = [],

        // Stop Recursions
        stopRecursions = [],

        // Parent Injector to assign to the configured injector, this must be an object reference
        parentInjector = "",

        // Register all event listeners here, they are created in the specified order
        listeners = [
            // { class="", name="", properties={} }
        ]
    };

    // Map Bindings below
}

logBoxConfig

The path to the LogBox Configuration object to use. By default it uses the one displayed below. If you are using WireBox within a ColdBox application, the LogBox configuration is taken from the ColdBox application.

wirebox.logBoxConfig = "wirebox.system.ioc.config.LogBox";

cachebox

If you are using WireBox within a ColdBox application this setting is ignored and it will use the ColdBox application's CacheBox configuration. The following are the keys for this configuration structure:

wirebox.cacheBox = {
    // Activate the CacheBox DSL and caching
    enabled = false,
    // An optional configuration file to use for loading CacheBox
    configFile = "coldbox.system.ioc.config.CacheBox",
    // A reference to an already instantiated CacheBox CacheFactory, instead of building one
    cacheFactory = "",
    //A class path namespace to use to create CacheBox: Default=coldbox.system.cache or wirebox.system.cache
    classNamespace = ""
};

scopeRegistration

This structure tells WireBox how to leach itself into any ColdFusion scope when initialized instead of you placing it in the scope.

wirebox.scopeRegistration = {
    // activate scope registration
    enabled = true,
    // The CF scope to place the WireBox injector on
    scope   = "application",
    // The key used to store it in the scope
    key        = "wireBox"
};

customDSL

wirebox.customDSL = {
    // The value of the DSL Namespace is the instantiation path
    // of the DSL Namespace builder that implements wirebox.system.ioc.DSL.IDSLBuilder
    cool = "my.path.CoolDSLBuilder",
    funkyBox = "my.funky.DSLBuilder"
};

customScopes

wirebox.customScopes = {
    // The value of the instantiation path of the custom scope
    // that implements coldbox.system.ioc.scopes.IScope.
    // The name of the scope will be used when registered
    // the scope annotation.
    CoolSingletons = "my.path.SingletonScope",
    FunkyTransaction = "my.funky.Transaction"
};

scanLocations

The instantiation paths that this Injector will have registered to do object locations in order. So if you request an object called Service and no mapping has been configured for it, then WireBox will search all these scan locations for a Service.cfc in the specified order. The last lookup is the no namespace lookup which basically represents a createObject("component","Service") call. If you are using WireBox within a ColdBox application, ColdBox will register the models convention folder for you.

wirebox.scanLocations = ["models","com","org.majano"];

stopRecursions

This is an array of class path's that WireBox will use to stop recursion on any object graph that has inheritance when looking for dependencies.

wirebox.stopRecursions = [ "transfer.com.TransferDecorator", "coldbox.system.EventHandler" ];

parentInjector

This setting is actually a reference to another parent injector you would like this injector to set as its parent injector. Now say this sentence 10 times without hiccuping.

wirebox.parentInjector = application.coolInjector;
// or
wirebox.parentInjector = new coldbox.system.ioc.Injector( "old.legacy.binder" );

listeners

This section only shows you how to register WireBox listeners, so please refer to the object life cycle events section for more information. This setting is an array of listener structure definitions that WireBox's event manager will use when broadcasting object life cycle events.

wirebox.listeners = [
    {
        // The path to the listener
        class="path.to.CFC",
        // A unique name for the listener
        name="UniqueName",
        // A structure of name-value pairs for configuring this interceptor
        properties = {}
    }
    {class="my.AOPTracker"},
    {class="annotationTransactioner",properties={target='*'} },
    {class="Timer", name="CoolTimer"}
];

The next step in our mapping DSL excursion is to learn about how WireBox will persist these object mappings into WireBox scopes. By default (as we have seen), all object mappings are transient objects and they belong to a scope type called NOSCOPE.

However, we need to specifically tell WireBox into what scope the declared mapped objects should be placed on in order for us to leverage caching, the singleton pattern, etc. This is accomplished by leveraging our persistence component annotations or the following methods if you prefer a non-annotation approach:

Note Please note that all WireBox configuration binders have two public properties:

this.TYPES - Enum class (coldbox.system.ioc.Types)
this.SCOPES - Enum class (coldbox.system.ioc.Scopes)

These classes have on themselves several public properties that are a cool shorthand way to link to construction types or persistence scopes

So just remember that these persistence DSL methods are not mandatory. If you are an annotations kinda developer, then you can easily add these persistence annotations to your classes.

// CFC
map("FunkyObject")
    .to("myapp.model.service.FunkyService")
    .asSingleton();
mapPath("myapp.model.service.FunkyService")
    .into(this.SCOPES.REQUEST);
// Java as NO SCOPE
map("buffer").toJava("java.lang.StringBuffer");
// RSS feed
map("googleNews")
    .toRSS("http://news.google.com/news?output=rss")
    .inCacheBox(timeout=60,lastAccessTimeout=15);
// Webservice
map("myWS")
    .toWebservice("http://myapp.com/app.cfc?wsdl")
    .into(this.SCOPES.APPLICATION);

You can use our mapping DSL to register influence closures or lambdas on a per mapping basis. This will allow a developer to influence the requested instance of any object/data element and decorate objects or even return different objects.

This is similar to object providers but instead of overriding the ENTIRE creation process of the object like a provider does, the user might want to simply influence the creation of a normal mapping with some additional flair. This is accomplished via the withInfluence mapping DSL function. It receives a closure as an argument and the closure has the following signature:

/**
* Influence an instance of an object
* @injector The WireBox injector reference
* @object The object to influence
*/
function( injector, object ){}

Here is an example of adding some nice pizzazz to an object:

map( 'myObject' )
   .toPath( 'com.foo.bar' )
   .withInfluence( function( injector, object ) {
      object.customSettings( true );
      object.pizzazz = 'Oh, yes!';
      return object;
});

In this instance, the instance is already built and then passed into the closure for additional influence. Please note, that the object is returned from the closure. You can make this optional, but if something IS returned, it will override the instance which will allow a developer to replace or decorate the instance as they see fit.

Whether you use WireBox standalone or within a ColdBox context a Binder gets a structure of configuration properties so it can use them whenever you are configuring it or declaring mappings. If you are in standalone mode, the Injector can be constructed with a properties structure that will be passed to the binder for usage. If you are in a ColdBox application the ColdBox application configuration structure is passed for you. You can then use these properties with the following methods:

• getProperty(name,[default]) : Get a specific property

• getProperties() : Get all the properties structure

• propertyExists(name) : Check if a property exists

• setProperty(name,value) : Dynamically add properties to the structure

A part from using the configuration binder, you can also leverage component annotations to dictate behavior on the object.

You can store a-la-carte attributes in a specific mapping so it can be retrieved at a later time by either an AOP aspect or Events. This is a great way to store custom metadata about an object so it can be read later for some meaningful purpose. Let's say you want to tag a mapping with a custom type that is not so easily determined from the object instance itself. You don't want to do all kinds of introspection in order to know what object you received in an aspect or an event.

This mapping declares that an object has some extra attributes that will be stored in the mapping, such as the location and if it belongs to a module. This is then incredibly useful when you have an attached listener to WireBox:

As you can see from this sample, the extra attributes are incredibly essential, as the listener just sends the target object. It would take lots of introspection and metadata inspections in order to determine certain metadata about an object. However, with the extra attributes, it is just a snap!

The following annotations can be placed in the component declaration to tell the WireBox injector where to persist the constructed object. If no scope annotations are found on the component or mappings then the object is treated as NO SCOPE or a prototype/transient object; one that gets constructed and discarded every time.

• singleton - A singleton object that persists for the entire life-time of the application

• scope="registered_scope" : Persist in a registered scope: session, request, singleton, custom, etc.

The injector can be constructed with three optional arguments:

If you are using WireBox within a ColdBox application, you don't even need to do any of this, we do it for you by using some configuration data in your ColdBox configuration file or conventions.

Since version 5.5.0 all mappings in WireBox will only be processed when they are requested for the very first time. This is to enhance performance and increase startup times. Processing means that the object's and its inheritance trail are inspected for metadata, which can be a very time consuming process.

process()

However, you can explicitly process a mapping right after mapping it via the binder's process() method.

That's it! If you call the process() method right after a mapping, it will be automatically processed. This means all annotations will be inspected.

mapDirectory( process=true )

If you are mapping using mapDirectory() then you can pass the process argument to true and all mappings in that directory scan will be processed automatically.

Now that we have constructed our injector let's discuss a little about injection idioms or styles WireBox offers before we go all cowboy and start configuring and using this puppy. Below is a nice chart that showcases the WireBox injection styles, but we really encourage you to review our dependency injection section to learn the different approaches to DI, their values, and when to use them.

These are the three injection styles that WireBox supports and which style you choose depends on your requirements and also your personal taste. The setter method approach is linked to the way Spring and ColdSpring approach it which is the traditional JavaBean style of setXXX where XXX is the name of the mapping or object to pass into the setter method for injection.

Note Whichever injection style you use with WireBox, the target's visibility does not matter. This means that you can create private or package methods and WireBox will still inject them for you. This is absolutely great when you are an encapsulation freak and you do not want to expose public setter methods.

WireBox bases itself on the idea of creating object injectors (wirebox.system.ioc.Injector) that in turn will produce and wire all your objects. You can create as many injector instances as you like in your applications, each with configurable differences or be linked hierarchically by setting each other as parent injectors.

Each injector can be configured with a configuration binder or none at all. If you are a purely annotations based kind of developer and don't mind requesting pathed components by convention, then you can use the no-configuration approach and not even have a single configuration file, all using autowiring and discovery of conventions. However, if you would like to alter the behavior of the injector and also create object mappings, you will need a configuration binder. The next section explains the way to create this configuration binder, below is how to startup or bootstrap the injector in different manners:

No Configuration Binder:

With a Configuration Binder:

Thanks to Phill Nacelli, you can reuse object definitions in your binder or via annotations. This means that you can declare an object with its dependencies and then create other definitions that use all of this parent object's definitions. This saves tons of time in declarations and provides you with great reusability.

Here is a small example:

Talk and get objects from the current wirebox injector

The default namespace is not specifying one. This namespace is used to retreive either named mappings or full component paths.

CFC Instantiation Order

When WireBox builds CFC instances, it is important to know the order of operations. This controls when injected dependencies are available for you to use.

1. Component is instantiated with createObject()

2. CF automatically runs the pseudo constructor (any code outside the a method declaration)

3. The init() method is called (if it exists), passing any constructor args

4. Property (mixin) and setting injection happens

5. The onDIComplete() method is called (if it exists)

Based on that order, you can see that injected dependencies (except constructor ones) are not available yet to use in the init() and you must wait to use them in the onDIComplete() method.

This DSL namespace interacts with the loaded LogBox instance.

We have now coded our classes and unit tests with some cool annotations in record time, so what do we do next? Well, WireBox works on the idea of three ways to discover and create your classes:

So let's do examples for each where our classes we just built are placed in a directory called model of the root directory.

Implicit Creation

Explicit Binder Configuration

Explicit Creation

Scan Locations Binder Configuration

Set Locations Creation

A primer to WireBox usage

Dependency injection and instance construction with WireBox is easy. In its most simplest form we can just leverage annotations and be off to dancing Big Willy style! You can use our global injection annotation inject on cfproperties, setter methods or constructor arguments. This annotation tells WireBox to inject something in place of the property, argument or method; basically it is your code shouting "Hey buddy, I need your help here".

If you don't like annotations because you feel they are too intrusive to your taste, don't worry, we also have a programmatic configuration binder you can use to define all your objects and their dependencies. We will discuss object mappings and our configuration binders later on, so let's look at how cool this is by checking out our Coffee Shop sample class. The CoffeeShop class below will use our three types of injections to showcase how WireBox works, please note that most likely we would build this class by picking one or the other, which in itself brings in pros and cons for each approach.

So let's break this class down. First, you can see a singleton annotation on the component declaration. This tells WireBox that this class should only be created once and then cached in its internal singleton scope of the injector. In other words, this is called object life scopes. You can refer to the persistence scopes annotations later on in the guide to learn all about how to scope your classes.

Second, we built our coffee shop class with three external dependencies: 1 by cfproperty, 1 by constructor argument and 1 by setter injection. Again, you can see later on in this guide the difference between all these injection styles and choose what you prefer. In this example, we just showcase the different injection styles. Also, as you can see from the source code the three types of injection uses the inject annotation but with different content:

If you just mark a property, argument or method with the inject annotation, WireBox will assume it is a mapping and the ID should be either the property name, the argument name or the method name. However, if you want to specify the id in the DSL string, just use the simple id:{mapping} dsl notation. That's it! Isn't that cool, you just mark out your dependencies and WireBox will build and inject them for you!

Thirdly, this class has the following method:

The method has a cool little annotation called onDIComplete that tells WireBox that after all DI dependencies have been injected, then execute the method. That is so cool, WireBox can even open the coffee shop for me so I can get my espresso fix. Not only that but you can have multiple onDIComplete methods declared and WireBox will call them for you (in discovered order). These are called object post processors that are discovered by annotations or can be configured via our configuration binder and we will learn about them later on. WireBox also fires a series of object life cycle events throughout an object's life span in which you can build listens to and actually perform some cool stuff on them. So now that we got all excited about opening the coffee shop let's get into something even more interesting, unit testing and mocking.

Another important aspect leveraging DI concepts when building our components is that we can immediately write tests for them and leverage mocking to test for actual behaviors. This is a great advantage as it allows you to rapidly test to confirm your component is working without worrying about building or assembling objects in your tests. You have eliminated all kinds of crazy creation and assembler code and just concentrated yourself on the problem at hand. You are now focused to code the greatest piece of software you have ever imagined, thanks to WireBox!

Now we can run our tests and verify that our coffee shop is operational and producing sweet sweet espresso!

WireBox Manual - Version 5.0.0

WireBox is an enterprise ColdFusion Dependency Injection and Aspect Oriented Programing (AOP) framework. This project has been part of ColdBox since its early version 2.0 releases but it is also a standalone library that can be used in ANY ColdFusion application or framework. WireBox's inspiration has been based on the idea of rapid workflows when building object oriented ColdFusion applications, programmatic configurations and simplicity. With that motivation we introduced dependency injection by annotations and conventions, which has been the core foundation of WireBox. We have definitely been influenced by great DI projects like Google Guice, Grails Framework, Spring and ColdSpring so we thank them for their contributions and inspiration

Versioning

And constructed with the following guidelines:

• Breaking backward compatibility bumps the major (and resets the minor and patch)

• New additions without breaking backward compatibility bumps the minor (and resets the patch)

• Bug fixes and misc changes bumps the patch

License

• Copyright by Ortus Solutions, Corp

• ColdBox is a registered trademark by Ortus Solutions, Corp

Info: The ColdBox Websites, Documentation, logo and content have a separate license and they are a separate entity.

Discussion & Help

Reporting a Bug

Professional Open Source

ColdBox is a professional open source software backed by Ortus Solutions, Corp offering services like:

• Custom Development

• Professional Support & Mentoring

• Training

• Server Tuning

• Security Hardening

• Code Reviews

• Much More

Resources

HONOR GOES TO GOD ABOVE ALL

Because of His grace, this project exists. If you don't like this, then don't read it, its not for you.

"Therefore being justified by **faith**, we have peace with God through our Lord Jesus Christ: By whom also we have access by **faith** into this **grace** wherein we stand, and rejoice in hope of the glory of God." Romans 5:5

The injection DSL is a domain specific language that denotes what to inject in the current placeholder: property, argument, or method via the inject annotation. This injection DSL not only can it be used via annotations but also via our mapping DSL whenever a dsl argument can be used. This DSL is constructed by joining words separated by a : colon. The first part of this string is what we will denote as the injection DSL Namespace.

Property Annotation

Every cfproperty can be annotated with our injection annotations:

• @inject : The injection DSL

• @scope : The visibility scope to inject the dependency into. By default it injects into variables scope

Constructor Argument Annotation

You can also use annotated constructor arguments with the inject annotation.

Caution In full script components, annotating inline arguments is broken in Adobe ColdFusion 9. You will have to annotate them via the alternative annotation syntax in ColdFusion 9 via the javadocs style comments.

Setter Method Annotation

You can also annotate setter methods with the inject annotation to provide injections

WireBox offers a wide gamut of annotation namespaces you can use in your CFML applications and ColdBox applications. However, we took it a step further and allowed you to create your own custom DSL namespaces making your annotations come alive!

When using WireBox inside of ColdBox, the binder CFC is located by convention in /config/WireBox.cfc. When using WireBox outside of ColdBox, you can create a binder CFC anywhere with any name using one of these two methods:

1. Create a configuration CFC that extends the WireBox configuration object: coldbox.system.ioc.config.Binder and has a configure() method.

component extends="coldbox.system.ioc.config.Binder"{

    function configure(){

    }

    function onLoad(){

    }

    function onShutdown(){

    }
}

1. Or create a simple configuration CFC that has a configure( binder ) method that accepts a WireBox configuration binder object

component{

 function configure(required binder){

 }

 function onLoad(){

 }

 function onShutdown(){

 }

}

From the configure() method you will be able to interact with the Binder methods or creating implicit DSL structures in order to configure WireBox for operation and also to create object mappings. From the onLoad() method you can also use it for mappings with main distinction that the WireBox machinery is now online (logging, events, caching, etc). This is necessary for leveraging mapDirectory() calls.

When you instantiate the Wirebox injector, pass either the CFC path to your binder CFC or an instance of the CFC.

new wirebox.system.ioc.Injector( 'path.to.my.Binder' );
// or
var oBinder = createObject( 'path.to.my.Binder' );
new wirebox.system.ioc.Injector( oBinder );

Gives you the ability to easily inject base orm services or binded virtual entity services for you:

// Generic ORM service layer
property name="genericService" inject="entityService";
// Virtual service layer based on the User entity
property name="userService" inject="entityService:User";

This DSL namespace is only active if using CacheBox or a ColdBox application context.

property name="cacheFactory" inject="cacheBox";
property name="cache" inject="cachebox:default";
property name="data" inject="cachebox:default:myKey";

WireBox also sports a very nice event model that can announce several object life cycle events. You can listen to these events and interact with WireBox at runtime very easily, whether you are in standalone mode or within a ColdBox application.

We have already seen in our previous section all the events that are announced by WireBox, but how do we listen? There are two ways to build WireBox listeners because there are two modes of operations, but the core is the same.

1. Listeners are simple CFCs that must create methods that match the same name of the event they want to listen to.

These methods can take up to two parameters depending on your mode of operation (standalone or ColdBox). The one main difference between pure Wirebox listeners and ColdBox interceptors are that the configure method for the standalone WireBox is different.

WireBox's offers a wide gamut of life cycle events that are announced at certain points in execution time. Below are the current events announced by the Injector wirebox.system.ioc.Injector.

Ok, now that we know how to configure WireBox, let's get into the fun stuff of object mapping. How do we do this? By using our DSL mapping initiators that tell WireBox how to start the object registration process. You will then concatenate the initiators with some DSL destinations methods, DI data, etc to tell WireBox all the information it might need to construct, wire and persist the object. Here are the DSL initiators:

If you need to abstract old legacy code or have funky construction processes, we would recommend you build your own provider objects. This means that you will create a component that implements wirebox.system.ioc.IProvider (one get() method) and then you can map it. Once mapped, you can use it anywhere WireBox listens for providers:

• The Injection DSL →

property name="" inject="provider:{name or injectionDSL}";

• The mapping DSL

map("MyCFC").toProvider('name or injectionDSL')

// or
setter,property,methodArg,initArg(name="",dsl="provider:{name or injectionDSL}");

Here is the interface you need to implement:

<cfinterface hint="The WireBox Provider Interface that follows the provider pattern">
    <---  get --->
    <cffunction name="get" output="false" access="public" returntype="any" hint="Get the provided object">
    </cffunction>
</cfinterface>

The CFC you build will need to be mapped so it can be retrieved by name and also so if it needs DI or any other WireBox funkiness, it can get it. So let's look at our FunkyEspressoProvider that we needed to create since we have some old legacy machines that we need to revamp:

component name="FunkyEspressoProvider" implements="coldbox.system.ioc.IProvider" singleton{

    property name="log" inject="logbox:logger:FunkyEspressoProvider";

    public function init(){ return this; }

    Espresso public function get(){
        // log
        log.canDebug(){ log.debug("Requested funky espresso"); }
        var espresso = createObject("component","old.legacy.Espresso").init();
        // add some sugar as the old legacy machine is not that great.
        espresso.addSugar(1);
        // returned provided object.
        return espresso;
    }

}

Finally we map to the provider using the .toProvider() mapping method in the binder so anytime somebody requests an Espresso we can get it from our funky provider. Please note that I also map the provider because it also has some DI needed.

component extends="coldbox.system.ioc.config.Binder"{
    function configure(){
        // map the provider first, so it can be constructed and DI performed on it.
        map("FunkyEspressoProvider")
            .to("model.legacy.FunkyEspressoProvider");

        // map espresso's to the old funky provider for construction and retrieval.
        map("Espresso")
            .toProvider("FunkyEspressoProvider");

    }
}

Cool! That's it, anytime you request an Espresso, WireBox will direct its construction to the provider you registered it with.

The following chart shows you the most common methods when dealing with the WireBox Injector. This doesn't mean there are no other methods on the Injector that are of value, so please check out the CFC Docs for more in-depth knowledge.

If you would like to use CacheBox for persistence for you objects you will need to mark your CFC with the following annotation(s)

• cachebox="[provider]" - The default provider is called 'default', so this annotation can be empty or a named cache provider

• cache - Cache into the default provider, shorthand annotation, no value needed

This annotation has two sub annotations that you can also leverage for granular control of your CacheBox integration:

• cacheTimeout - The timeout in minutes (optional)

• cacheLastAccessTimeout - The last access or idle timeout in minutes (optional)

Caution When storing objects in volatile scopes like cache, session, request, etc. You must be careful of not injecting them directly into singletons or other volatile objects as you could have memory leaks via a side effect called Scope Widening Injection. We recommend combining them via WireBox Providers to avoid this side effect.

Let's get funky now! We have seen how to inject objects and how to scope objects. However, we need to talk about a cool WireBox feature called object providers. We learned that when you request an object from WireBox it creates it and injects it immediately. However, sometimes we need more control like:

• Delay construction of the dependency until some point in time during your controlled execution. Maybe you don't want to construct some dependencies until some feature in your application is enabled.

• You need multiple instances of a class. Like a User service producing transient users, or our espresso machine creating espressos.

• You need to access scoped objects that might need reconstruction. Maybe you want to check the cache first for existence or a ColdFusion scope in order to avoid scope widening injection.

• You have some old legacy funkiness for building stuff that has to remain as its own factory.

All of these areas are where WireBox Providers can really save the day. WireBox offers an automatic way to create providers for you by creating generic provider classes (wirebox.system.ioc.Provider) that will be configured to provide the mapping you want, then injected instead of the real object requested.

This happens whenever you use the provider DSL injection namespace or annotate methods with a provider annotation. It also gives you an interface (wirebox.system.ioc.IProvider), which is very simple, which you can implement in order to register your own complex providers with WireBox.

You would usually do the latter if you have legacy code you need to abstract out, had funky construction processes, etc. Let's start by looking at how registering custom providers works first and then how to use the automatic WireBox providers.

The difference between custom providers here is that WireBox will create a virtual provider object for you dynamically at runtime, configure it to retrieve a specific type of mapping and then use that for you. The provider namespace will take everything after it and evaluate it as either a named mapping or a full injection DSL string.

For example, inject="provider:MyService" will inject a provider of MyService objects, so it will look for a MyService ID in the binder. However, you can also get mega funky and do this: inject="provider:logbox:logger:{this}" and WireBox will create a provider of logbox:logger:{this}.

Caution Remember that the value of the provider can be a simple ID or a full injection DSL.

// use the provider DSL namespace on a property
property name="searchCriteria" inject="provider:requestCriteria";

// use the provider DSL namespace on a constructor argument
function init(coolObjectProvider inject="provider:HardToConstructObject"){
    variables.coolObjectProvider = arguments.coolObjectProvider;
    return this;
}

// To use it
searchCriteria.get().getCriteria();
coolObjectProvider.get().executeSomeMethod();

That's it! You basically use the provider:{mapping} injection DSL to tell a property, setter or argument that you want a provider object instead of the real deal. This will allow you to delay construction of such an object or avoid the nasty pitfall of scope widening injection.

Interact with Java directly

property name="builder" inject="java:java.lang.StringBuilder";

Thanks to our ColdBox Evangelist, Brad Wood, we have a feature in our Providers that you can leverage its onMissingMethod() to proxy calls into the provided object itself. So let's say our provided object has a method called sayHello(), then with an injected provider you must do this:

That is great, but you can proxy calls into the provider itself by removing the extra get() call and doing this:

The WireBox provider object (wirebox.system.ioc.Provider) has an onMissingMethod() function that will take all missing method calls and proxy them to the provided object. Now, this is great but be ready to lose on performance if you use this approach. That is the only caveat to this approach, is that you will be impacted by performance, not crazy, but try it.

WireBox also comes packaged with our handy object populator that has been so successful in our ColdBox applications. The object populator object can populate objects with data from XML, JSON, WDDX, structures, queries and much more. So we highly encourage you to check it out as it will really help out in your applications.

The way to retrieve it is to use the getObjectPopulator() method on the injector and then call one of our populate methods on the object. You can also use the wirebox:populator injection DSL to retrieve it.

populator = injector.getObjectPopulator();

property name="populator" inject="wirebox:populator";

You can use the mixins() binder method or mixins annotation to define that a mapping should be mixed in with one or more set of templates. It will then at runtime inject all the methods in those templates and mix them into the target object as public methods.

// map with mixins
map("MyService")
    .to("model.UserService")
    .mixins("/helpers/base");

// map with mixins as list
map("MyService")
    .to("model.UserService")
    .mixins("/helpers/base, /helpers/model");

// map with mixins as array
map("MyService")
    .to("model.UserService")
    .mixins( ["/helpers/base", "/helpers/model"] );


// Via annotation
component mixins="/helpers/base"{

}

This will grab all the methods in the base.cfm and model.cfm templates and inject them into the target mapping as public methods. Awesome right?

Tip The list of templates can include a .cfm extension or none at all

This namespace is a combination of namespaces that are only active when used within a ColdBox application:

Single Stage Injections

Two Stage Injections

Three Stage Injections

Examples

// some examples
property name="logbox" inject="logbox";
property name="rootLogger" inject="logbox:root";
property name="logger" inject="logbox:logger:model.com.UserService";
property name="moduleService" inject="coldbox:moduleService";
property name="producer" inject="coldbox:interceptor:MessageProducer";
property name="producer" inject="interceptor:MessageProducer";
property name="appPath" inject="coldbox:fwSetting:ApplicationPath";

While the injector can help in many ways to secure the creation of your objects, it is ultimately up to you to create code that is both thread safe and tested. It is always a great idea to design your objects without the injector in mind for threading and concurrency.

DI is not a silver bullet, but a tool to relieve object creation and not to relieve the burden of good object design. Thread safety is much more complex and can be compromised when using persistent scopes like singleton, session, server, application and cachebox, as more than one thread will be trying to access your code and dependencies.

The only guarantee the injector can provide is the constructor and constructor dependency creation to be completely locked. The following object is to be guaranteed to be locked when created and wired with dependencies:

component{

     /**
     * @log.inject logbox:logger:{this}
     * @dao.inject id:MyDAO
     */
     function init(required log, required dao){
          variables.log = arguments.log;
          variables.dao = arguments.dao;
          return this;
     }

}

Caution The inject annotations are done in comments as ColdFusion 9 has a bug when adding annotations on scripted arguments.

An example of a flawed object could be the following:

component{

     property name="dao" inject="id:MyDAO";
     property name="log" inject="logbox:logger:{this}";

     function init(){
          return this;
     }
}

Why is this object flawed? It is flawed because the majority of DI engines, including WireBox, will lock for constructing the object and its constructor arguments. However, once it is constructed, it will store the object in the persistence scope of choice in order to satisfy the potential of circular dependencies in the object graph. After it is placed in the storage, the DI engines will wire up setter and property mixin injections and WireBox's onDiComplete() method. With this normal approach, the wiring of dependencies and onDiComplete() have the potential of mixups or missing dependencies due to concurrency. This is a normal side-effect and risk that developers take due that Java makes no guarantees that any thread other than the one that set its dependencies will see the dependencies. The memory between threads is not final or immutable so properties can enter an altered state.

"The subtle reason has to do with the way Java Virtual Machines (JVM) are designed to manage threads. Threads may keep local, cached copies of non-volatile fields that can quickly get out of sync with one another unless they are synchronized correctly." From Dependency Injection by Dhanji R. Prasanna

Note This side effect of concurrency will only occur on objects that are singletons or persisted in scopes like session, server, application, server or cachebox. It does not affect transient or request scoped objects.

WireBox, can help you lock and provide thread safety to setter and property injections by providing you with the ThreadSafe annotation or our binder threadSafe() tagging method. So if we wanted to make the last example thread safe for property and setter wiring then we would do the following:

component threadSafe{

     property name="dao" inject="id:MyDAO";
     property name="log" inject="logbox:logger:{this}";

     function init(){
          return this;
     }
}

// or
component threadSafe=true{

     property name="dao" inject="id:MyDAO";
     property name="log" inject="logbox:logger:{this}";

     function init(){
          return this;
     }
}

// or you can bind it as a thread safe component
map("MyObject").to("path.model.MyObject").asSingleton().threadSafe();

Our threadSafe annotation and binder tagging property will allow for these objects to be completely locked and synchronized for object creation, wiring and onDiComplete(). However, circular dependencies will now fail as persistence cannot be guaranteed for the setter or property dependencies. However, since WireBox is so awesome, you can still use circular dependencies by wiring instead our object providers. (Please see providers section). In conclusion, constructing and designing a CFC that is thread safe is often a very arduous process. It is also very difficult to test and recreate threading issues in your objects and applications. So don't feel bad, as even the best of us can get into some nasty wormholes when dealing with concurrency and thread safety. However, always try to design for as much concurrency as possible and test test test!

So let's say that we want to listen on the beforeInjectorShutdown and on the afterInstanceCreation event in our listener.

component{

    function configure(){}

    function beforeInjectorShutdown(event, interceptData, buffer, rc, prc ){
        var injector = arguments.interceptData.injector;
        // Do my stuff here:

        // I can use a log object because ColdBox is cool and injects one for me already.
        log.info("DUDE, I am going down!!!");
    }

    function afterInstanceCreation(event, interceptData, buffer, rc, prc ){
        var injector = arguments.interceptData.injector;
        var target = arguments.interceptData.target;
        var mapping = arguments.interceptData.mapping;

        log.info("The object #mapping.getName()# has just been built, performing my awesome AOP processing on it.");

        // process awesome AOP on this target
        processAwesomeAOP( target );
    }
}

Populate a bean from a query

Returns

* This function returns Any

Arguments

Populate a bean from a structure

Returns

• This function returns Any

Arguments