<xsd:enumeration value="byName"/>
					<xsd:enumeration value="byType"/>
					<xsd:enumeration value="constructor"/>
					<xsd:enumeration value="autodetect"/>
				</xsd:restriction>
			</xsd:simpleType>
		</xsd:attribute>
		<xsd:attribute name="dependency-check" default="default">
			<xsd:annotation>
				<xsd:documentation><![CDATA[
	Controls whether or not to check whether all of this
	bean's dependencies, expressed in its properties, are satisfied.
	The default is to perform no dependency checking.

	"simple" type dependency checking includes primitives and String;
	"objects" includes collaborators (other beans in the factory);
	"all" includes both types of dependency checking.

	Note: This attribute will not be inherited by child bean definitions.
	Hence, it needs to be specified per concrete bean definition.
				]]></xsd:documentation>
			</xsd:annotation>
			<xsd:simpleType>
				<xsd:restriction base="xsd:NMTOKEN">
					<xsd:enumeration value="default"/>
					<xsd:enumeration value="none"/>
					<xsd:enumeration value="simple"/>
					<xsd:enumeration value="objects"/>
					<xsd:enumeration value="all"/>
				</xsd:restriction>
			</xsd:simpleType>
		</xsd:attribute>
		<xsd:attribute name="depends-on" type="xsd:string">
			<xsd:annotation>
				<xsd:documentation><![CDATA[
	The names of the beans that this bean depends on being initialized.
	The bean factory will guarantee that these beans get initialized
	before this bean.

	Note that dependencies are normally expressed through bean properties
	or constructor arguments. This property should just be necessary for
	other kinds of dependencies like statics (*ugh*) or database preparation
	on startup.

	Note: This attribute will not be inherited by child bean definitions.
	Hence, it needs to be specified per concrete bean definition.
				]]></xsd:documentation>
			</xsd:annotation>
		</xsd:attribute>
		<xsd:attribute name="autowire-candidate" type="xsd:boolean">
			<xsd:annotation>
				<xsd:documentation><![CDATA[
	Indicates whether or not this bean should be considered when looking
	for matching candidates to satisfy another bean's autowiring requirements.
	Note that this does not affect explicit references by name, which will get
	resolved even if the specified bean is not marked as an autowire candidate.
				]]></xsd:documentation>
			</xsd:annotation>
		</xsd:attribute>
		<xsd:attribute name="init-method" type="xsd:string">
			<xsd:annotation>
				<xsd:documentation><![CDATA[
	The name of the custom initialization method to invoke after setting
	bean properties. The method must have no arguments, but may throw any
	exception.
				]]></xsd:documentation>
			</xsd:annotation>
		</xsd:attribute>
		<xsd:attribute name="destroy-method" type="xsd:string">
			<xsd:annotation>
				<xsd:documentation><![CDATA[
	The name of the custom destroy method to invoke on bean factory
	shutdown. The method must have no arguments, but may throw any
	exception.

	Note: Only invoked on beans whose lifecycle is under the full
	control of the factory - which is always the case for singletons,
	but not guaranteed for any other scope.
				]]></xsd:documentation>
			</xsd:annotation>
		</xsd:attribute>
		<xsd:attribute name="factory-method" type="xsd:string">
			<xsd:annotation>
				<xsd:documentation><![CDATA[
	The name of a factory method to use to create this object. Use
	constructor-arg elements to specify arguments to the factory method,
	if it takes arguments. Autowiring does not apply to factory methods.

	If the "class" attribute is present, the factory method will be a static
	method on the class specified by the "class" attribute on this bean
	definition. Often this will be the same class as that of the constructed
	object - for example, when the factory method is used as an alternative
	to a constructor. However, it may be on a different class. In that case,
	the created object will *not* be of the class specified in the "class"
	attribute. This is analogous to FactoryBean behavior.

	If the "factory-bean" attribute is present, the "class" attribute is not
	used, and the factory method will be an instance method on the object
	returned from a getBean call with the specified bean name. The factory
	bean may be defined as a singleton or a prototype.

	The factory method can have any number of arguments. Autowiring is not
	supported. Use indexed constructor-arg elements in conjunction with the
	factory-method attribute.

	Setter Injection can be used in conjunction with a factory method.
	Method Injection cannot, as the factory method returns an instance,
	which will be used when the container creates the bean.
				]]></xsd:documentation>
			</xsd:annotation>
		</xsd:attribute>
		<xsd:attribute name="factory-bean" type="xsd:string">
			<xsd:annotation>
				<xsd:documentation><![CDATA[
	Alternative to class attribute for factory-method usage.
	If this is specified, no class attribute should be used.
	This must be set to the name of a bean in the current or
	ancestor factories that contains the relevant factory method.
	This allows the factory itself to be configured using Dependency
	Injection, and an instance (rather than static) method to be used.
				]]></xsd:documentation>
			</xsd:annotation>
		</xsd:attribute>
		<xsd:anyAttribute namespace="##other" processContents="lax"/>
	</xsd:attributeGroup>

	<xsd:element name="meta" type="metaType">
		<xsd:annotation>
			<xsd:documentation><![CDATA[
	Arbitrary metadata attached to a bean definition.
			]]></xsd:documentation>
		</xsd:annotation>
	</xsd:element>

	<xsd:complexType name="metaType">
		<xsd:attribute name="key" type="xsd:string" use="required">
			<xsd:annotation>
				<xsd:documentation><![CDATA[
	The key name of the metadata parameter being defined.
				]]></xsd:documentation>
			</xsd:annotation>
		</xsd:attribute>
		<xsd:attribute name="value" type="xsd:string" use="required">
			<xsd:annotation>
				<xsd:documentation><![CDATA[
	The value of the metadata parameter being defined (as a simple String).
				]]></xsd:documentation>
			</xsd:annotation>
		</xsd:attribute>
	</xsd:complexType>

	<xsd:element name="bean">
		<xsd:annotation>
			<xsd:documentation source="java:org.springframework.beans.factory.config.BeanDefinition"><![CDATA[
	Defines a single (usually named) bean.

	A bean definition may contain nested tags for constructor arguments,
	property values, lookup methods, and replaced methods. Mixing constructor
	injection and setter injection on the same bean is explicitly supported.
			]]></xsd:documentation>
		</xsd:annotation>
		<xsd:complexType>
			<xsd:complexContent>
				<xsd:extension base="identifiedType">
					<xsd:group ref="beanElements"/>
					<xsd:attributeGroup ref="beanAttributes"/>
				</xsd:extension>
			</xsd:complexContent>
		</xsd:complexType>
	</xsd:element>

	<xsd:element name="constructor-arg">
		<xsd:annotation>
			<xsd:documentation source="java:org.springframework.beans.factory.config.ConstructorArgumentValues">
				<![CDATA[
	Bean definitions can specify zero or more constructor arguments.
	This is an alternative to "autowire constructor".
	Arguments correspond to either a specific index of the constructor
	argument list or are supposed to be matched generically by type.

	Note: A single generic argument value will just be used once, rather
	than potentially matched multiple times (as of Spring 1.1).

	constructor-arg elements are also used in conjunction with the
	factory-method element to construct beans using static or instance
	factory methods.
			]]></xsd:documentation>
		</xsd:annotation>
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element ref="description" minOccurs="0"/>
				<xsd:choice minOccurs="0" maxOccurs="1">
					<xsd:element ref="bean"/>
					<xsd:element ref="ref"/>
					<xsd:element ref="idref"/>
					<xsd:element ref="value"/>
					<xsd:element ref="null"/>
					<xsd:element ref="list"/>
					<xsd:element ref="set"/>
					<xsd:element ref="map"/>
					<xsd:element ref="props"/>
					<xsd:any namespace="##other" processContents="strict"/>
				</xsd:choice>
			</xsd:sequence>
			<xsd:attribute name="index" type="xsd:string">
				<xsd:annotation>
					<xsd:documentation><![CDATA[
	The exact index of thr argument in the constructor argument list.
	Only needed to avoid ambiguities, e.g. in case of 2 arguments of
	the exact same type.
					]]></xsd:documentation>
				</xsd:annotation>
			</xsd:attribute>
			<xsd:attribute name="type" type="xsd:string">
				<xsd:annotation>
					<xsd:documentation><![CDATA[
	The exact type of the constructor argument. Only needed to avoid
	ambiguities, e.g. in case of 2 single argument constructors
	that can both be converted from a String.
					]]></xsd:documentation>
				</xsd:annotation>
			</xsd:attribute>
			<xsd:attribute name="ref" type="xsd:string">
				<xsd:annotation>
					<xsd:documentation><![CDATA[
	A short-cut alternative to a nested "<ref bean='...'/>" element.
					]]></xsd:documentation>
				</xsd:annotation>
			</xsd:attribute>
			<xsd:attribute name="value" type="xsd:string">
				<xsd:annotation>
					<xsd:documentation><![CDATA[
	A short-cut alternative to a nested "<value>...<value/>"
	element.
					]]></xsd:documentation>
				</xsd:annotation>
			</xsd:attribute>
		</xsd:complexType>
	</xsd:element>

	<xsd:element name="property" type="propertyType">
		<xsd:annotation>
			<xsd:documentation><![CDATA[
	Bean definitions can have zero or more properties.
	Property elements correspond to JavaBean setter methods exposed
	by the bean classes. Spring supports primitives, references to other
	beans in the same or related factories, lists, maps and properties.
			]]></xsd:documentation>
		</xsd:annotation>
	</xsd:element>

	<xsd:element name="lookup-method">
		<xsd:annotation>
			<xsd:documentation><![CDATA[
	A lookup method causes the IoC container to override the given method
	and return the bean with the name given in the bean attribute. This is
	a form of Method Injection. It is particularly useful as an alternative
	to implementing the BeanFactoryAware interface, in order to be able to
	make getBean() calls for non-singleton instances at runtime. In this
	case, Method Injection is a less invasive alternative.
			]]></xsd:documentation>
		</xsd:annotation>
		<xsd:complexType>
			<xsd:complexContent>
				<xsd:restriction base="xsd:anyType">
					<xsd:attribute name="name" type="xsd:string">
						<xsd:annotation>
							<xsd:documentation><![CDATA[
	The name of the lookup method. This method must take no arguments.
							]]></xsd:documentation>
						</xsd:annotation>
					</xsd:attribute>
					<xsd:attribute name="bean" type="xsd:string">
						<xsd:annotation>
							<xsd:documentation><![CDATA[
	The name of the bean in the current or ancestor factories that
	the lookup method should resolve to. Often this bean will be a
	prototype, in which case the lookup method will return a distinct
	instance on every invocation. This is useful for single-threaded objects.
							]]></xsd:documentation>
						</xsd:annotation>
					</xsd:attribute>
				</xsd:restriction>
			</xsd:complexContent>
		</xsd:complexType>
	</xsd:element>

	<xsd:element name="replaced-method">
		<xsd:annotation>
			<xsd:documentation><![CDATA[
	Similar to the lookup method mechanism, the replaced-method element
	is used to control IoC container method overriding: Method Injection.
	This mechanism allows the overriding of a method with arbitrary code.
			]]></xsd:documentation>
		</xsd:annotation>
		<xsd:complexType>
			<xsd:sequence>
				<xsd:choice minOccurs="0" maxOccurs="unbounded">
					<xsd:element ref="arg-type"/>
				</xsd:choice>
			</xsd:sequence>
			<xsd:attribute name="name" type="xsd:string">
				<xsd:annotation>
					<xsd:documentation><![CDATA[
	The name of the method whose implementation must be replaced by the
	IoC container. If this method is not overloaded, there is no need
	to use arg-type subelements. If this method is overloaded, arg-type
	subelements must be used for all override definitions for the method.
					]]></xsd:documentation>
				</xsd:annotation>
			</xsd:attribute>
			<xsd:attribute name="replacer" type="xsd:string">
				<xsd:annotation>
					<xsd:documentation source="java:org.springframework.beans.factory.support.MethodReplacer"><![CDATA[
	Bean name of an implementation of the MethodReplacer interface in the
	current or ancestor factories. This may be a singleton or prototype
	bean. If it is a prototype, a new instance will be used for each
	method replacement. Singleton usage is the norm.
					]]></xsd:documentation>
				</xsd:annotation>
			</xsd:attribute>
		</xsd:complexType>
	</xsd:element>

	<xsd:element name="arg-type">
		<xsd:annotation>
			<xsd:documentation><![CDATA[
	Identifies an argument for a replaced method in the event of
	method overloading.
			]]></xsd:documentation>
		</xsd:annotation>
		<xsd:complexType mixed="true">
			<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
			<xsd:attribute name="match" type="xsd:string">
				<xsd:annotation>
					<xsd:documentation><![CDATA[
	Specification of the type of an overloaded method argument as a String.
	For convenience, this may be a substring of the FQN. E.g. all the
	following would match "java.lang.String":
	- java.lang.String
	- String
	- Str

	As the number of arguments will be checked also, this convenience
	can often be used to save typing.
					]]></xsd:documentation>
				</xsd:annotation>
			</xsd:attribute>
		</xsd:complexType>
	</xsd:element>

	<xsd:element name="ref">
		<xsd:annotation>
			<xsd:documentation><![CDATA[
	Defines a reference to another bean in this factory or an external
	factory (parent or included factory).
			]]></xsd:documentation>
		</xsd:annotation>
		<xsd:complexType>
			<xsd:complexContent>
				<xsd:restriction base="xsd:anyType">