Replace all class name string variables with ObjectFactories

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Won't Fix or Usage Issue
  • Affects Version/s: 2.0.0-M2
  • Fix Version/s: None
  • Component/s: Core: Configuration
  • Labels:
    None
  • User impact:
    Low
  • Similar Issues:
    None

Description

Now that the ObjectFactory framework is in place, we should use it! Basically any String variable with a class name (i.e., String fooClassName = "foo.default.class.Name" should use an ObjectFactory instead which ties it into the standard config/lifecycle mechanism of Mule 2.x (usually Spring) and allows for singleton/prototype/pooled scopes to be chosen.

Issue Links

is blocked by

Sub-task - The sub-task of the issue MULE-2222 Transformers not generated by object factories

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Sub-task - The sub-task of the issue MULE-2229 Custom Connector doesn't use ObjectFactory

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrew Perepelytsya added a comment -

It's not an absolute solution. Many cases do indeed need FQN as strings to avoid compile-time dependencies. Moreover, we already faced a limitation of BDPs - they want class references, thus unnecessarily binding core to the modules (currently need to push everything out to modules and have just 1 line of config and dozen schema declarations instead).

This is only a note of caution to review each case's usage.

Show
Andrew Perepelytsya added a comment - It's not an absolute solution. Many cases do indeed need FQN as strings to avoid compile-time dependencies. Moreover, we already faced a limitation of BDPs - they want class references, thus unnecessarily binding core to the modules (currently need to push everything out to modules and have just 1 line of config and dozen schema declarations instead). This is only a note of caution to review each case's usage.
Hide
Permalink
Travis Carlson added a comment -

I don't think the ObjectFactory would necessarily create a compile-time dependency, since the class name can be specified as a String there as well (it will only resolve the class if/when the object needs to be instantiated via a call to ObjectFactory.getOrCreate()

What is gained is more flexibilty for how/when/how often an instance of the object is created, and the certainty that its created instances will actually get disposed/destroyed at some point.

Show
Travis Carlson added a comment - I don't think the ObjectFactory would necessarily create a compile-time dependency, since the class name can be specified as a String there as well (it will only resolve the class if/when the object needs to be instantiated via a call to ObjectFactory.getOrCreate() What is gained is more flexibilty for how/when/how often an instance of the object is created, and the certainty that its created instances will actually get disposed/destroyed at some point.
Hide
Permalink
Travis Carlson added a comment -

The decision was made to only use ObjectFactory's in Component/Service for the time being.

Show
Travis Carlson added a comment - The decision was made to only use ObjectFactory's in Component/Service for the time being.

People

  • Assignee:
    Travis Carlson
    Reporter:
    Travis Carlson
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: