Difference between using bean id and name in Spring configuration file - spring

Is there any difference between using an id attribute and name attribute on a <bean> element in a Spring configuration file?

From the Spring reference, 3.2.3.1 Naming Beans:
Every bean has one or more ids (also
called identifiers, or names; these
terms refer to the same thing). These
ids must be unique within the
container the bean is hosted in. A
bean will almost always have only one
id, but if a bean has more than one
id, the extra ones can essentially be
considered aliases.
When using XML-based configuration
metadata, you use the 'id' or 'name'
attributes to specify the bean
identifier(s). The 'id' attribute
allows you to specify exactly one id,
and as it is a real XML element ID
attribute, the XML parser is able to
do some extra validation when other
elements reference the id; as such, it
is the preferred way to specify a bean
id. However, the XML specification
does limit the characters which are
legal in XML IDs. This is usually not
a constraint, but if you have a need
to use one of these special XML
characters, or want to introduce other
aliases to the bean, you may also or
instead specify one or more bean ids,
separated by a comma (,), semicolon
(;), or whitespace in the 'name'
attribute.
So basically the id attribute conforms to the XML id attribute standards whereas name is a little more flexible. Generally speaking, I use name pretty much exclusively. It just seems more "Spring-y".

Since Spring 3.1 the id attribute is an xsd:string and permits the same range of characters as the name attribute.
The only difference between an id and a name is that a name can contain multiple aliases separated by a comma, semicolon or whitespace, whereas an id must be a single value.
From the Spring 3.2 documentation:
In XML-based configuration metadata, you use the id and/or name attributes to specify the bean identifier(s). The id attribute allows you to specify exactly one id. Conventionally these names are alphanumeric ('myBean', 'fooService', etc), but may special characters as well. If you want to introduce other aliases to the bean, you can also specify them in the name attribute, separated by a comma (,), semicolon (;), or white space. As a historical note, in versions prior to Spring 3.1, the id attribute was typed as an xsd:ID, which constrained possible characters. As of 3.1, it is now xsd:string. Note that bean id uniqueness is still enforced by the container, though no longer by XML parsers.

Either one would work. It depends on your needs:
If your bean identifier contains special character(s) for example (/viewSummary.html), it wont be allowed as the bean id, because it's not a valid XML ID. In such cases you could skip defining the bean id and supply the bean name instead.
The name attribute also helps in defining aliases for your bean, since it allows specifying multiple identifiers for a given bean.

let me answer below question
Is there any difference between using an id attribute and using a name attribute on a <bean> tag,
There is no difference. you will experience same effect when id or name is used on a <bean> tag .
How?
Both id and name attributes are giving us a means to provide identifier value to a bean (For this moment, think id means id but not identifier). In both the cases, you will see same result if you call applicationContext.getBean("bean-identifier"); .
Take #Bean, the java equivalent of <bean> tag, you wont find an id attribute. you can give your identifier value to #Bean only through name attribute.
Let me explain it through an example :
Take this configuration file, let's call it as spring1.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans ...>
<bean id="foo" class="com.intertech.Foo"></bean>
<bean id="bar" class="com.intertech.Bar"></bean>
</beans>
Spring returns Foo object for, Foo f = (Foo) context.getBean("foo");
. Replace id="foo" with name="foo" in the above spring1.xml, You will still see the same result.
Define your xml configuration like,
<?xml version="1.0" encoding="UTF-8"?>
<beans ...>
<bean id="fooIdentifier" class="com.intertech.Foo"></bean>
<bean name="fooIdentifier" class="com.intertech.Foo"></bean>
</beans>
You will get BeanDefinitionParsingException. It will say, Bean name 'fooIdentifier' is already used in this element. By the way, This is the same exception you will see if you have below config
<bean name="fooIdentifier" class="com.intertech.Foo"></bean>
<bean name="fooIdentifier" class="com.intertech.Foo"></bean>
If you keep both id and name to the bean tag, the bean is said to have 2 identifiers. you can get the same bean with any identifier.
take config as
<?xml version="1.0" encoding="UTF-8"?><br>
<beans ...>
<bean id="fooById" name="fooByName" class="com.intertech.Foo"></bean>
<bean id="bar" class="com.intertech.Bar"></bean>
</beans>
the following code prints true
FileSystemXmlApplicationContext context = new FileSystemXmlApplicationContext(...);
Foo fooById = (Foo) context.getBean("fooById")// returns Foo object;
Foo fooByName = (Foo) context.getBean("fooByName")// returns Foo object;
System.out.println(fooById == fooByName) //true

Is there difference in defining Id & name in ApplicationContext xml ? No
As of 3.1(spring), id is also defined as an xsd:string type.
It means whatever characters allowed in defining name are also allowed in Id.
This was not possible prior to Spring 3.1.
Why to use name when it is same as Id ?
It is useful for some situations, such as allowing each component in an application to refer to a common dependency by using a bean name that is specific to that component itself.
For example, the configuration metadata for subsystem A may refer to a DataSource via the name subsystemA-dataSource. The configuration metadata for subsystem B may refer to a DataSource via the name subsystemB-dataSource. When composing the main application that uses both these subsystems the main application refers to the DataSource via the name myApp-dataSource. To have all three names refer to the same object you add to the MyApp configuration metadata the following
<bean id="myApp-dataSource" name="subsystemA-dataSource,subsystemB-dataSource" ..../>
Alternatively, You can have separate xml configuration files for each sub-system and then you can make use of
alias to define your own names.
<alias name="subsystemA-dataSource" alias="subsystemB-dataSource"/>
<alias name="subsystemA-dataSource" alias="myApp-dataSource" />

Both id and name are bean identifiers in Spring IOC container/ApplicationContecxt. The id attribute lets you specify exactly one id but using name attribute you can give alias name to that bean.
You can check the spring doc here.

Related

JAX-WS and curly braces syntax

All over the Internet I find code examples of JAX-WS beans being defined in this fashion:
<jaxws:client name="{http://cxf.apache.org/}MyService" createdFromAPI="true">
What is the meaning of the curly braces here exactly?
You might need to specify individual examples of where you've seen it, but from what you've shared here, this seems to be erroneous use of that naming convention.
See, the schema for the Spring-CXF XML configuration document supports two types of "name" attributes:
name: use this to name just the bean within the spring context - treat it no differently as you would adding id to a spring bean. No need for a namespace or prefixing of any kind
serviceName: this name should come from the WSDL as part of the name attribute from the definitions root element. It's this one that uses the QName format - what you have here as {http://cxf.apache.org/}MyService which the CXF API will try to match with what's in the WSDL of the SOAP service you're consuming.
TL;DR: that naming convention with the URL prefix doesn't belong on the name attribute but on the serviceName attribute and its value ought to come from the WSDL file.

Spring Core - Alias and Ids

I started learning Spring today and came across a strange behavior, so seeking any expert help on the behavior. I defined a bean with an id and verified the bean is available via ApplicationContext and Bean factory. Later created more beans with different IDs but created one alias with the exact same Id of the First Bean (xml snippet below)
<!-- Beans -->
<bean id="wolf" class="com.badwolf.spring.SpringWolf">
<constructor-arg type="java.lang.String" value="wolfy" />
<constructor-arg index="1" value="20" />
</bean>
<bean id="sweetWolf" class="com.badwolf.spring.SweetWolf" />
<!-- Aliases -->
<alias name="sweetWolf" alias="wolf" />
Now in the implementation class when getting the bean using "wolf" then getting the bean associated with the "Alias". Is this intended behavior of Spring? Do Aliases take precedence over the bean definition (which seems to be the core of Spring)?
What if my project is split into teams and on integration someone has used the same id and alias and all of a sudden a portion of functionality stops working.
Firstly, there are three Spring bean terminology here, name, alias, and id.
Spring bean can have multiple names, aliases, while it can only have one unique id.
Below is reference from Spring doc
Every bean has one or more identifiers. These identifiers must be unique within the container that hosts the bean. A bean usually has only one identifier, but if it requires more than one, the extra ones can be considered aliases.
So in your case, bean with id of "wolf" has Spring-generated name ("springwolf"), while bean with id "sweetWolf" has two names, Spring-generated name("sweestWolf") and name alias("wolf") (spring-bean-names).
Related discussions for alias vs name (1, 2)
Related discussion for alias vs id (1)

Spring Bean Name with package detail only

I need to create bean with id or name with class name with it's package.
e.g
<bean class="org.chameleon.commons.context.resolver.impl.UserContextResolver" scope="prototype"
/>
and I want it to be like this
org.chameleon.commons.context.resolver.impl.UserContextResolver
but it shows me like this.
org.chameleon.commons.context.resolver.impl.UserContextResolver#if
What to do to get bean as my required name.
You should add an "id" or a "name" attribute to the bean definition, e.g.
<bean id="org.chameleon.commons.context.resolver.impl.UserContextResolver" class="org.chameleon.commons.context.resolver.impl.UserContextResolver" scope="prototype" />
As stated in Spring reference doc 5.3.1 Naming beans1
In XML-based configuration metadata, you use the id and/or name attributes to specify the bean identifier(s). The id attribute allows you to specify exactly one id. Conventionally these names are alphanumeric (myBean, fooService, etc.), but may contain special characters as well. If you want to introduce other aliases to the bean, you can also specify them in the name attribute, separated by a comma (,), semicolon (;), or white space. As a historical note, in versions prior to Spring 3.1, the id attribute was defined as an xsd:ID type, which constrained possible characters. As of 3.1, it is defined as an xsd:string type. Note that bean id uniqueness is still enforced by the container, though no longer by XML parsers.
You are not required to supply a name or id for a bean. If no name or id is supplied explicitly, the container generates a unique name for that bean. However, if you want to refer to that bean by name, through the use of the ref element or Service Locator style lookup, you must provide a name.

Spring Framework (V2.5) - Using actionpath in ref attribute in a bean definition

I am a pretty newcomer for Spring Framework.
This is regarding referencing another bean using ref attribute.
I have a bean definition for an action class like below.
<bean name="/abc" class="com.example.actions.Action" scope="singleton">
<property name="businessLogic" ref="/pqr"/>
</bean>
I am trying to inject another bean into this bean using ref attribute (ie "/pqr").
<bean name="/pqr" class="com.example.businesslogic.PqrBL" scope="prototype" />
Now my question how normal is it to use name="/pqr" kind of a notation for a bean which is not a definition for some action class ? By convention is it an acceptable normal scenario ?
PS: please let me know if information provided is incomplete or the question is not clear.
Thanks
The Spring reference states that
The convention is to use the standard Java convention for instance field names when
naming beans. That is, bean names start with a lowercase letter, and are camel-cased from
then on. Examples of such names would be (without quotes) 'accountManager',
'accountService', 'userDao', 'loginController', and so forth.
It is not normal to use "/pqr" as a bean name but you can do it . I would prefer using more user friendly names to the beans than using a "path" .
Check here for the convention .

Spring bean with no id or name

I'm reviewing some Spring code, and I see a few bean defs that do not have an id or a name.
The person who did it is not around to ask.
The application is working fine.
I am not familiar what this necessarily means.
Anybody know if this means anything in particular?
Some beans are not required to be accessed by other beans in the context file or programmatically. So as mentioned by JacobM, they don't require an id or name as they're not referenced.
Such an example would be a PropertyPlaceholderConfigurer, which reads a property file, then allows for runtime property replacement in the context definition.
The example definition would be
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="myapp.properties" />
</bean>
The JavaDoc provides further documentation on this object, but further on in the file you can reference properties from your file by just using the standard template replace placeholder ${...}.
One possibility is that you can define a bean in place, and so you don't need an id since you don't need to refer to it from anywhere else. Say I have a Foo object that takes a Bar property:
<bean id="foo" class="Foo">
<property name="bar">
<bean class="Bar">
</property>
</bean>
The Bar bean doesn't need a name because it's only used to set that one property.
Check the possibility of auto-wiring. An other bean could reference the unnamed bean by having the autowire property set to byType.
This is just a guess. Without a concrete example, I can't say any more.
The id and name attributes are optional and are used to reference the bean definition from other definitions. Look at the official Spring documentation for more detail.
take a look at https://docs.spring.io/spring/docs/4.3.12.RELEASE/spring-framework-reference/htmlsingle/#beans-beanname it says,
You are not required to supply a name or id for a bean. If no name or id is supplied explicitly, the container generates a unique name for that bean. However, if you want to refer to that bean by name, through the use of the ref element or Service Locator style lookup, you must provide a name. Motivations for not supplying a name are related to using inner beans and autowiring collaborators.
Also, Beans such as BeanPostProcessor, BeanFactoryPostProcessor and PropertyPlaceholderConfigurer are automatically detected by application context and typically won't have name
If you consider any spring bean, Spring mandates it to have an identifier. In case, if you have not provided any identifier (via id or name attribute) to a bean in your configuration, you won't run into exceptions. Spring will manage such situation by assigning a default identifier. it has BeanNameGenerator to assign default name. <bean class="com.package.name.TestBean"> will be named as "com.package.name.TestBean" #Bean kind of beans will have its method name as bean name
thus, in your code, for some reason, you can skip naming few beans and the code still works if you are accessing those beans with their default name
credits : https://www.javacodegeeks.com/2013/02/spring-bean-names.html
Beans without id or name can still be referenced by the class name. Spring names those beans automatically using the class name and if there is more than one bean of the same class it appends a number to them.
Anonymous beans are usually defined inside a property tag, but if they're just there maybe there's autowiring configured in some other beans.
Anyway, I think adding a name or id to those beans won't break your application.
As a couple of people mentioned above, not all bean-grabbing is based on name/ID; some of it is based on type. For example, there is a method
BeanFactoryUtils.beansOfTypeIncludingAncestors(...)
that grabs all the beans of some given type. This is used for example by the Spring Web MVC DispatcherServlet (among many other places) to discover beans by type, such as HandlerMappings, HandlerAdapters, HandlerExceptionResolvers and so forth. Contrast this with cases where the bean must have a specific well-known name/ID to be found, such as the LocaleResolver (ID must be "localeResolver" or it won't be found) and ThemeResolver (ID must be "themeResolver" or it won't be found).
Beans defined without name and ID can be accessed with a generated ID (full package name and class name), for example:
bean defined as
<bean class="pl.finsys.initOrder.TestBeanImpl">
can be accessed by
TestBean bean = (TestBean) ctx.getBean("pl.finsys.initOrder.TestBeanImpl");
//Bean Cfg File without Bean id
<bean class="com.ds.DemoBean">
<property name="msg" value="Hello"/>
</bean>
//We can Access
Object obj=factory.getBean("com.ds.DemoBe
its not a mandatory to provide java Bean Id..If we are not providing Bean Id,our Container Provides the Default Been Id.Default Bean Id look like as
"(Package Name).(Bean Class Name)#N"where N=0,1,2,......etc.
It seems there is a subtle difference between unnamed and named bean behaviour. If you have an XML config file imported twice, each named bean will be created only once, but an unnamed bean will be created as many times as its definition is included. When trying to autowire such a bean by type, it leads to errors like this:
No qualifying bean of type [your.class.Name] is defined: expected single matching bean but found 4

Resources