Mule
  1. Mule
  2. MULE-2583

Replace all class name string variables with ObjectFactories

    Details

    • Type: Improvement Improvement
    • Status: 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:
      MULE-2876Remove use of ObjectFactories for anything except components
      MULE-6945Watermark variable and MEL variables valid string differs
      MULE-89Make all Jms class names consistent
      MULE-2022Deprecate RegistryFacade.getEndpointFromUri(String); Replace with getEndpointFromName.
      MULE-7806@Expr annotation always evaluates to a String
      MULE-5082MuleEndpointURI incorrectly replaces curly brackets with braces in a query
      MULE-2787inconsistent class name attribute type
      MULE-1887Non-String Placeholders Fail to Validate
      MULE-1789Delete EJB (and other?) Container Context? - Descriptor assumes all descriptors are class names.
      MULE-2666ObjectToMimeMessage doesn't create DataHandler properly if input is a String

      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

          Activity

          Hide
          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
          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
          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
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development