<xsd:attributeGroup name="beanAttributes">
    <xsd:attribute name="name" type="xsd:string">
        <xsd:annotation>
            <xsd:documentation><![CDATA[
	Can be used to create one or more aliases illegal in an (XML) id.
	Multiple aliases can be separated by any number of spaces, commas,
	or semi-colons (or indeed any mixture of the three).
				]]></xsd:documentation>
        </xsd:annotation>
    </xsd:attribute>
    <xsd:attribute name="class" type="xsd:string">
        <xsd:annotation>
            <xsd:documentation source="java:java.lang.Class"><![CDATA[
	The fully qualified name of the bean's class, except if it serves only
	as a parent definition for child bean definitions.
				]]></xsd:documentation>
        </xsd:annotation>
    </xsd:attribute>
    <xsd:attribute name="parent" type="xsd:string">
        <xsd:annotation>
            <xsd:documentation><![CDATA[
	The name of the parent bean definition.

	Will use the bean class of the parent if none is specified, but can
	also override it. In the latter case, the child bean class must be
	compatible with the parent, i.e. accept the parent's property values
	and constructor argument values, if any.

	A child bean definition will inherit constructor argument values,
	property values and method overrides from the parent, with the option
	to add new values. If init method, destroy method, factory bean and/or
	factory method are specified, they will override the corresponding
	parent settings.

	The remaining settings will always be taken from the child definition:
	depends on, autowire mode, scope, lazy init.
				]]></xsd:documentation>
        </xsd:annotation>
    </xsd:attribute>
    <xsd:attribute name="scope" type="xsd:string">
        <xsd:annotation>
            <xsd:documentation><![CDATA[
	The scope of this bean: typically "singleton" (one shared instance,
	which will be returned by all calls to getBean with the given id), or
	"prototype" (independent instance resulting from each call to getBean).

	By default, a bean will be a singleton, unless the bean has a parent
	bean definition in which case it will inherit the parent's scope.

	Singletons are most commonly used, and are ideal for multi-threaded
	service objects. Further scopes, such as "request" or "session", might
	be supported by extended bean factories (e.g. in a web environment).

	Inner bean definitions inherit the singleton status of their containing
	bean definition, unless explicitly specified: The inner bean will be a
	singleton if the containing bean is a singleton, and a prototype if
	the containing bean has any other scope.
				]]></xsd:documentation>
        </xsd:annotation>
    </xsd:attribute>
    <xsd:attribute name="abstract" type="xsd:boolean">
        <xsd:annotation>
            <xsd:documentation><![CDATA[
	Is this bean "abstract", that is, not meant to be instantiated itself
	but rather just serving as parent for concrete child bean definitions?
	The default is "false". Specify "true" to tell the bean factory to not
	try to instantiate that particular bean in any case.

	Note: This attribute will not be inherited by child bean definitions.
	Hence, it needs to be specified per abstract bean definition.
				]]></xsd:documentation>
        </xsd:annotation>
    </xsd:attribute>
    <xsd:attribute name="lazy-init" default="default" type="defaultable-boolean">
        <xsd:annotation>
            <xsd:documentation><![CDATA[
	Indicates whether or not this bean is to be lazily initialized.
	If false, it will be instantiated on startup by bean factories
	that perform eager initialization of singletons. The default is
	"false".

	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" default="default">
        <xsd:annotation>
            <xsd:documentation><![CDATA[
	Controls whether bean properties are "autowired".
	This is an automagical process in which bean references don't need
	to be coded explicitly in the XML bean definition file, but rather the
	Spring container works out dependencies.

	There are 4 modes:

	1. "no"
	The traditional Spring default. No automagical wiring. Bean references
	must be defined in the XML file via the <ref/> element (or "ref"
	attribute). We recommend this in most cases as it makes documentation
	more explicit.

	Note that this default mode also allows for annotation-driven autowiring,
	if activated. "no" refers to externally driven autowiring only, not
	affecting any autowiring demands that the bean class itself expresses.

	2. "byName"
	Autowiring by property name. If a bean of class Cat exposes a "dog"
	property, Spring will try to set this to the value of the bean "dog"
	in the current container. If there is no matching bean by name, nothing
	special happens.

	3. "byType"
	Autowiring if there is exactly one bean of the property type in the
	container. If there is more than one, a fatal error is raised, and
	you cannot use byType autowiring for that bean. If there is none,
	nothing special happens.

	4. "constructor"
	Analogous to "byType" for constructor arguments. If there is not exactly
	one bean of the constructor argument type in the bean factory, a fatal
	error is raised.

	Note that explicit dependencies, i.e. "property" and "constructor-arg"
	elements, always override autowiring.

	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="no" />
                <xsd:enumeration value="byName" />
                <xsd:enumeration value="byType" />
                <xsd:enumeration value="constructor" />
            </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" default="default" type="defaultable-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="primary" type="xsd:boolean">
        <xsd:annotation>
            <xsd:documentation><![CDATA[
	Specifies that this bean should be given preference when multiple
	candidates are qualified to autowire a single-valued dependency.
	If exactly one 'primary' bean exists among the candidates, it
	will be the autowired value.
				]]></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>