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(
DefaultConfiguringBeanFactoryPostProcessor.class, false, false),
... 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.