WireBox : Dependency Injection & AOP
2.x
2.x
  • Introduction
  • Intro
    • Introduction
      • What's New With 5.5.0
      • What's New With 5.4.0
      • What's New With 5.3.0
      • What's New With 5.0.0
      • What's New With 2.1.0
      • What's New With 2.0.0
      • About This Book
      • Author
  • Getting Started
    • Overview
    • Installing WireBox
    • Getting Jiggy Wit It!
      • Instance Creations
      • Binder Introduction
      • Scoping
      • Eager Init
      • How WireBox Resolves Dependencies
  • Configuration
    • Configuring WireBox
      • Binder Configuration Properties
      • Binder Environment Properties
      • ColdBox Enhanced Binder
      • Types & Scopes
      • Data Configuration Settings
      • Programmatic Configuration
    • Mapping DSL
      • Mapping Initiators
      • Mapping Destinations
      • MapDirectory() Influence & Filters
      • Persistence DSL
      • Dependencies DSL
        • Mapping Extra Attributes
      • Mapping DSL Examples
      • Influence Instances at Runtime
      • Processing Mappings
    • Component Annotations
      • Persistence Annotations
      • CacheBox Annotations
    • Parent Object Definitions
  • Usage
    • WireBox Injector
      • Injector Constructor Arguments
      • Injection Idioms
      • Common Methods
    • Injection DSL
      • ID-Model-Empty Namespace
      • Provider Namespace
      • WireBox Namespace
      • CacheBox Namespace
      • EntityService Namespace
      • LogBox Namespace
      • Java Namespace
      • ColdBox Namespace
    • WireBox Event Model
      • WireBox Events
      • WireBox Listeners
        • ColdBox Mode Listener
        • Standalone Mode Listener
  • Advanced Topics
    • Providers
      • Custom Providers
      • toProvider() closures
      • Virtual Provider Injection DSL
      • Virtual Provider Mapping
      • Virtual Provider Lookup Methods
      • Provider onMissingMethod Proxy
      • Scope Widening Injection
    • Virtual Inheritance
    • Runtime Mixins()
    • Object Persistence & Thread Safety
    • ORM Entity Injection
    • WireBox Object Populator
      • populateFromXML
      • populateFromQuery
      • populateFromStruct
      • populateFromQueryWithPrefix
      • populateFromJSON
  • Extending WireBox
    • Custom DSL
      • The DSL Builder Interface
      • Registering a Custom DSL
    • Custom Scopes
      • The Scope Interface
      • Scoping Process
      • Registering a Custom Scope
    • WireBox Injector Interface
  • Aspect Oriented Programming
    • AOP Intro
      • Overview
        • AOP Vocabulary
      • Activate The AOP Listener
      • Create Your Aspect
        • MethodInvocation Useful Methods
        • MethodLogger Aspect
      • Aspect Registration
      • Aspect Binding
      • Auto Aspect Binding
        • ClassMatcher Annotation DSL
        • MethodMatcher Annotation DSL
      • Included Aspects
        • CFTransaction
        • HibernateTransaction
        • MethodLogger
      • Summary
Powered by GitBook
On this page

Was this helpful?

Edit on Git
Export as PDF
  1. Advanced Topics
  2. Providers

Scope Widening Injection

PreviousProvider onMissingMethod ProxyNextVirtual Inheritance

Last updated 4 years ago

Was this helpful?

An object that is scoped into request, session, server, cachebox or application scopes and if wired into a persisted object will remain around even when this object has expired from the scope. This is called scope-widening injection and is a problem that must be addressed by NOT injecting them into persisted objects directly but by using WireBox's provider approach. This guarantees that the object's scope lifecycle will be maintained and your singleton or other persistent objects will be decoupled from the scope by accessing the target object via its provider.

For example, let's say you have a handler that wires in a user object that is scoped into session scope, but the handler itself is scoped as a singleton:

component name="handler" singleton{

    property name="user" inject="id:user";
}

//user component
component name="user" scope="session"{
}

So when the handler is created and persisted as a singleton, the user object gets created, stored in session and also referenced into the lifecycle of the handler object. So now, if the user expires from session, the handler does not know about it, because all it knows it that a direct reference to that out of context object still remains. So if the user needed things in session to exist, this will now fail. This problem is much like how Hibernate and detached objects work. Objects are no longer in session, they are detached. This scope widening issue is resolved by NOT injecting the user object directly into the handler but by using a provider.

→ Scope Widening Injection Solution: Object Providers

Below is my favorite approach to solving the issue which is by using provided methods:

component name="handler" singleton{

    function getUser() provider="user"{}

}

That's it! My getUser() method will be replaced by WireBox with a proxy provider method that will request from the WireBox injector the user mapping instance.