Namespace: |
|
Content: |
10 attributes, attr. wildcard |
Defined: |
globally in coldspring-beans-2.0.xsd; see XML source |
Includes: |
definitions of 10 attributes, attr. wildcard |
Used: |
at 1 location |
XML Representation Summary | |||
<... | |||
abstract | = |
xsd:boolean | |
autowire | = |
("default" | "no" | "byName" | "byType") : "default" | |
class | = |
xsd:string | |
factory-bean | = |
xsd:string | |
factory-method | = |
xsd:string | |
init-method | = |
xsd:string | |
lazy-init | = |
("default" | "true" | "false") : "default" | |
name | = |
xsd:string | |
parent | = |
xsd:string | |
scope | = |
xsd:string | |
{any attribute with non-schema namespace} | |||
...> |
<xsd:attributeGroup name="beanAttributes"> <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: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: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, dependency check, scope, lazy init. ]]> </xsd:documentation> </xsd:annotation> </xsd:attribute> <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). Default is "singleton". 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). Note: This attribute will not be inherited by child bean definitions. Hence, it needs to be specified per concrete bean definition. 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: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:annotation> <xsd:documentation> <![CDATA[ Indicates whether or not this bean is to be lazily initialized. If false, it will be instantiated on startup by if the bean is a singleton, and not abstract. 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: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 3 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. 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. 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:restriction> </xsd:simpleType> </xsd:attribute> <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: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. The "factory-bean" attribute must also be present present, which will specify the Bean that the factory-method will be called on. The factory method can have any number of arguments. Autowiring is not supported. Use constructor-arg elements in conjunction with the factory-method attribute. Setter Injection can be used in conjunction with a factory method. ]]> </xsd:documentation> </xsd:annotation> </xsd:attribute> <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> |
Type: |
xsd:boolean, predefined |
Use: |
optional |
Defined: |
<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> |
Type: |
|
Use: |
optional |
Default: |
"default" |
Defined: |
Derivation: |
restriction of xsd:NMTOKEN |
<xsd:attribute default="default" name="autowire"> <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 3 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. 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. 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:restriction> </xsd:simpleType> </xsd:attribute> |
Type: |
xsd:string, predefined |
Use: |
optional |
Defined: |
<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> |
Type: |
xsd:string, predefined |
Use: |
optional |
Defined: |
<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> |
Type: |
xsd:string, predefined |
Use: |
optional |
Defined: |
<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. The "factory-bean" attribute must also be present present, which will specify the Bean that the factory-method will be called on. The factory method can have any number of arguments. Autowiring is not supported. Use constructor-arg elements in conjunction with the factory-method attribute. Setter Injection can be used in conjunction with a factory method. ]]> </xsd:documentation> </xsd:annotation> </xsd:attribute> |
Type: |
xsd:string, predefined |
Use: |
optional |
Defined: |
<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> |
Type: |
|
Use: |
optional |
Default: |
"default" |
Defined: |
<xsd:attribute default="default" name="lazy-init" 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 if the bean is a singleton, and not abstract. 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> |
Type: |
xsd:string, predefined |
Use: |
optional |
Defined: |
<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> |
Type: |
xsd:string, predefined |
Use: |
optional |
Defined: |
<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, dependency check, scope, lazy init. ]]> </xsd:documentation> </xsd:annotation> </xsd:attribute> |
Type: |
xsd:string, predefined |
Use: |
optional |
Defined: |
<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). Default is "singleton". 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). Note: This attribute will not be inherited by child bean definitions. Hence, it needs to be specified per concrete bean definition. 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> |
Defined: |
<xsd:anyAttribute namespace="##other" processContents="lax"/> |
This XML schema documentation has been generated with DocFlex/XML RE 1.8.0 using DocFlex/XML XSDDoc 2.2.0 template set. DocFlex/XML RE is a reduced edition of DocFlex/XML, which is a tool for programming and running highly sophisticated documentation and reports generators by the data obtained from any kind of XML files. The actual doc-generators are implemented in the form of special templates that are designed visually using a high quality Template Designer GUI basing on the XML schema (or DTD) files describing the data source XML. DocFlex/XML XSDDoc is a commercial template application of DocFlex/XML that implements a high-end XML Schema documentation generator with simultaneous support of framed multi-file HTML, single-file HTML and RTF output formats. (More formats are planned in the future). A commercial license for "DocFlex/XML XSDDoc" will allow you:
Once having only such a license, you will be able to run the fully-featured XML schema documentation generator both with DocFlex/XML SDK and with DocFlex/XML RE, which is a reduced free edition containing only the template interpretor / output generator. No other licenses will be required! But this is not all. In addition to it, a commercial license for DocFlex/XML SDK will allow you to modify the XSDDoc templates themselves as much as you want. You will be able to achieve whatever was impossible to do with the template parameters only. And, of course, you could develop any template applications by your own! Please note: By purchasing a license for this software, you not only acquire a useful tool, you will also make an important investment in its future development, the result of which you could enjoy later by yourself. Every single your purchase matters and makes a difference for us! To buy a license, please follow this link: http://www.filigris.com/shop/ |