org.springframework.beans.factory.config Documentation Differences

This file contains all the changes in documentation in the package org.springframework.beans.factory.config as colored differences. Deletions are shown like this, and additions are shown like this.

If no deletions or additions are shown in an entry, the HTML tags will be what has changed. The new HTML tags are shown in the differences. If no documentation existed, and then some was added in a later version, this change is noted in the appropriate class pages of differences, but the change is not shown on this page. Only changes in existing text are shown here. Similarly, documentation which was inherited from another class or interface is not shown here.

Note that an HTML error in the new documentation may cause the display of other documentation changes to be presented incorrectly. For instance, failure to close a <code> tag will cause all subsequent paragraphs to be displayed differently.

FactoryBean that exposes an arbitrary target bean under a different name.

Usually, the target bean will reside in a different bean definition file, using this FactoryBean to link it in and expose it under a different name. Effectively, this corresponds to an alias for the target bean.

NOTE: For XML bean definition files, an <alias> tag is available that effectively achieves the same.

A special capability of this FactoryBean is enabled through its configuration as bean definition: The "targetBeanName" can be substituted through a placeholder, in combination with Spring's PropertyPlaceholderConfigurer. Thanks to Marcus Bristav for pointing this out! @author Juergen Hoeller @since 1.2 @see #setTargetBeanName @see PropertyPlaceholderConfigurerPropertyPlaceholderConfigurer @deprecated as of Spring 3.2, in favor of using regular bean name aliases (which support placeholder parsing since Spring 2.5)

Factory bean for commons-logging org.apache.commons.logging.Log instances.

Useful for sharing Log instances among multiple beans instead of using one Log instance per class name, e.g. for common log topics. @author Juergen Hoeller @since 16.11.2003 @see org.apache.commons.logging.LogLog @deprecated as of Spring 3.2, in favor of a bean definition that points to the bean class "org.apache.commons.logging.LogFactory" and the factory method "getLog", passing in the log name as constructor argument

Determine whether the .logger field is enabled.

Default is {@code true} when the "warn" level is enabled. Subclasses can override this to change the level level under which logging occurs.

Logs a warning for a bean annotated with @Deprecated. @param beanName the name of the deprecated bean @param beanType the user-specified type of the deprecated bean @param beanDefinition the definition of the deprecated bean

Set the name of the logger to use. The name will be passed to the underlying logger implementation through through Commons Logging, getting interpreted as log category according to the logger's configuration.

This can be specified to not log into the category of this warner class but ratherrather into a specific named category. @see org.apache.commons.logging.LogFactory#getLog(String) @see org.apache.log4j.Logger#getLogger(String) @see java.util.logging.Logger#getLogger(String)

Set the name of the target bean.

The target does not have to be a non-singleton bean, but realisticially realistically always will be (because if the target bean were a singleton, then said singleton bean could simply be injected straight into the dependent object, thus obviating the need for the extra level of indirection afforded by this factory approach).

PlaceholderConfigurerSupport subclass that resolves ${...} placeholders against local properties and/or system properties and environment variables.

As of Spring 3.1, PropertySourcesPlaceholderConfigurer should be used preferentially over this implementation; it is more flexible through taking advantage of the Environment and PropertySource mechanisms also made available in Spring 3.1.

PropertyPlaceholderConfigurer is still appropriate for use when:

• the {@code spring-context} module is not available (i.e., one is using using Spring'ss {@code BeanFactory} API as opposed to {@code ApplicationContext}).
• existing configuration makes use of the "systemPropertiesMode" and/or "systemPropertiesModeName" properties. Users are encouraged to move away from using these settings, and rather configure property source search order through the container's {@code Environment}; however, exact preservation of functionality may be maintained by continuing to use {@code PropertyPlaceholderConfigurer}.

Prior to Spring 3.1, the {@code } namespace element registered an instance of {@code PropertyPlaceholderConfigurer}. It will still do so if using the {@code spring-context-3.0.xsd} definition of the namespace. That is, you can preserve registration of {@code PropertyPlaceholderConfigurer} through the namespace, even if using Spring 3.1; simply do not update your {@code xsi:schemaLocation} and continue using the 3.0 XSD. @author Juergen Hoeller @author Chris Beams @since 02.10.2003 @see #setSystemPropertiesModeName @see PlaceholderConfigurerSupport @see PropertyOverrideConfigurer @see org.springframework.context.support.PropertySourcesPlaceholderConfigurer

Set the name of the target bean.

The target does not have to be a non-singleton bean, but realisticially realistically always will be (because if the target bean were a singleton, then said singleton bean could simply be injected straight into the dependent object, thus obviating the need for the extra level of indirection afforded by this factory approach).