Spring Integration
  1. Spring Integration
  2. INT-562

Refactor default-configuring post-processor registration

    Details

    • Type: Refactoring Refactoring
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 2.0 RC1
    • Component/s: Core
    • Labels:
      None

      Description

      Currently, the default-configuring post-processor is being registered once per context, but the check occurs with each parse call. See: INT-532

      Now that this has been address in Spring DM, we should be able to refactor the approachhttp://jira.springframework.org/browse/OSGI-702

      However, this should only be done once the stable release of dm Server is based upon that version of Spring-DM.

        Issue Links

          Activity

          Hide
          Oleg Zhurakousky added a comment - - edited

          Current configuration has also a side effect that was reported by the user (see forum link above).
          To ensure that only one default configuring post processor is registered within the given AC AbstractIntegratioinNamespaceHandlerhas this code"

          alreadyRegistered = ObjectUtils.containsElement(
          	BeanFactoryUtils.beanNamesForTypeIncludingAncestors((ListableBeanFactory) parserContext.getRegistry(),
          	DefaultConfiguringBeanFactoryPostProcessor.class, false, false),
          	DEFAULT_CONFIGURING_POSTPROCESSOR_BEAN_NAME);
          

          ... which attempts to resolve parent/child bean definitions even though at that stage not all parent definition are registered (depends on the order of both definition config files) and when such resolution is not possible it throws the exception. The exception is absolutely harmless at this stage and eventually everything gets resolved.
          To fix this the code is now changed to:

          alreadyRegistered = ((ListableBeanFactory) parserContext.getRegistry()).containsBean(DEFAULT_CONFIGURING_POSTPROCESSOR_BEAN_NAME);
          

          However, we'll keep this issue open as it is still not the real fix. The real one will come with Spring 3.1 when we can use profiles.

          Show
          Oleg Zhurakousky added a comment - - edited Current configuration has also a side effect that was reported by the user (see forum link above). To ensure that only one default configuring post processor is registered within the given AC AbstractIntegratioinNamespaceHandlerhas this code" alreadyRegistered = ObjectUtils.containsElement( BeanFactoryUtils.beanNamesForTypeIncludingAncestors((ListableBeanFactory) parserContext.getRegistry(), DefaultConfiguringBeanFactoryPostProcessor.class, false , false ), DEFAULT_CONFIGURING_POSTPROCESSOR_BEAN_NAME); ... which attempts to resolve parent/child bean definitions even though at that stage not all parent definition are registered (depends on the order of both definition config files) and when such resolution is not possible it throws the exception. The exception is absolutely harmless at this stage and eventually everything gets resolved. To fix this the code is now changed to: alreadyRegistered = ((ListableBeanFactory) parserContext.getRegistry()).containsBean(DEFAULT_CONFIGURING_POSTPROCESSOR_BEAN_NAME); However, we'll keep this issue open as it is still not the real fix. The real one will come with Spring 3.1 when we can use profiles.
          Hide
          Mark Fisher added a comment -

          This might not be necessary, but I'm moving the issue to RC2 for one last look.

          Show
          Mark Fisher added a comment - This might not be necessary, but I'm moving the issue to RC2 for one last look.
          Hide
          Mark Fisher added a comment -

          We will refactor the way default beans are registered once we can rely on support for "profiles" in Spring 3.1 (meaning Spring Integration 2.1). For now, this behavior is working fine, but the refactoring in 2.1 will make it more elegant.

          Show
          Mark Fisher added a comment - We will refactor the way default beans are registered once we can rely on support for "profiles" in Spring 3.1 (meaning Spring Integration 2.1). For now, this behavior is working fine, but the refactoring in 2.1 will make it more elegant.

            People

            • Assignee:
              Mark Fisher
              Reporter:
              Mark Fisher
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: