The org.springframework.beans package adheres to the JavaBeans standard provided by Sun. A Java Bean is simply a class with a default no-argument constructor, which follows a naming convention where (by way of an example) a property named bingo Madness would have a setter method setBingoMadness(..) and a getter method getBingoMadness().
One quite important class in the beans package is the Bean Wrapper interface and its corresponding implementation (Bean Wrapper Impl). As quoted from the Javadoc, the Bean Wrapper offers functionality to set and get property values (individually or in bulk), get property descriptors, and to query properties to determine if they are readable or writable. Also, the Bean Wrapper offers support for nested properties, enabling the setting of properties on sub-properties to an unlimited depth.Then, the Bean Wrapper supports the ability to add standard JavaBeans Property Change Listeners and Veto able Change Listeners, without the need for supporting code in the target class. Last but not least, the Bean Wrapper provides support for the setting of indexed properties. The Bean Wrapper usually isn't used by application code directly, but by the Data Binder and the Bean Factory.
The way the Bean Wrapper works is partly indicated by its name: it wraps a bean to perform actions on that bean, like setting and retrieving properties.
Setting and getting basic and nested properties
Setting and getting properties is done using the setPropertyValue(s) and getPropertyValue(s) methods that both come with a couple of overloaded variants. They're all described in more detail in the Javadoc Spring comes with. What's important to know is that there are a couple of conventions for indicating properties of an object. A couple of examples:
Table . Examples of properties:-
Consider the following two classes:
public class Company {The following code snippets show some examples of how to retrieve and manipulate some of the properties of instantiated Companies and Employees:
BeanWrapper company = BeanWrapperImpl(new Company());Built-in PropertyEditor implementations
Spring uses the concept of PropertyEditors to effect the conversion between an Object and a String. If you think about it, it sometimes might be handy to be able to represent properties in a different way than the object itself.For example, a Date can be represented in a human readable way (as the String '2007-14-09'), while we're still able to convert the human readable form back to the original date (or even better: convert any date entered in a human readable form, back to Date objects).
This behavior can be achieved by registering custom editors, of type java.beans.PropertyEditor. Registering custom editors on a BeanWrapper or alternately in a specific IoC container, gives it the knowledge of how to convert properties to the desired type. Read more about PropertyEditors in the Javadoc of the java.beans package provided by Sun.
A couple of examples where property editing is used in Spring:
Spring has a number of built-in PropertyEditors to make life easy.Each of those is listed below and they are all located in the org. spring fram ework. beans. propertyeditors package.Most, but not all (as indicated below),are registered by default by BeanWrapperImpl. Where the property editor is configurable in some fashion, you can of course still register your own variant to override the default one:
Table . Built-in PropertyEditors;-
Spring uses the java.beans.PropertyEditorManager to set the search path for property editors that might be needed. The search path also includes sun.bean.editors, which includes PropertyEditor implementations for types such as Font, Color, and most of the primitive types.
Note also that the standard JavaBeans infrastructure will automatically discover PropertyEditor classes (without you having to register them explicitly) if they are in the same package as the class they handle, and have the same name as that class, with 'Editor' appended; for example, one could have the following class and package structure, which would be sufficient for the FooEditor class to be recognized and used as the PropertyEditor for Foo-typed properties.
Note that you can also use the standard BeanInfo JavaBeans mechanism here as well. Find below an example of using the BeanInfo mechanism for explicitly registering one or more PropertyEditor instances with the properties of an associated class.
comHere is the Java source code for the referenced FooBeanInfo class.This would associate a CustomNumberEditor with the age property of the Foo class.
public class FooBeanInfo extends SimpleBeanInfo {Registering additional custom PropertyEditors
When setting bean properties as a string value, a Spring IoC container ultimately uses standard JavaBeans PropertyEditors to convert these Strings to the complex type of the property. Spring pre-registers a number of custom PropertyEditors (for example,to convert a classname expressed as a string into a real Class object). Additionally, Java's standard JavaBeans PropertyEditor lookup mechanism allows a PropertyEditor for a class simply to be named appropriately and placed in the same package as the class it provides support for, to be found automatically.
If there is a need to register other custom PropertyEditors, there are several mechanisms available.The most manual approach, which is not normally convenient or recommended, is to simply use the register Custom Editor() method of the Configur able Bean Factory interface,assuming you have a BeanFactory reference.Another, slightly more convenient, mechanism is to use a special bean factory post-processor called CustomEditorConfigurer.Although bean factory post-processors can be used with BeanFactory implementations, the CustomEditorConfigurer has a nested property setup, so it is strongly recommended that it is used with the ApplicationContext, where it may be deployed in similar fashion to any other bean, and automatically detected and applied.
Note that all bean factories and application contexts automatically use a number of built-in property editors, through their use of something called a BeanWrapper to handle property conversions.
Additionally, ApplicationContexts also override or add an additional number of editors to handle resource lookups in a manner appropriate to the specific application context type.
Standard JavaBeans PropertyEditor instances are used to convert property values expressed as strings to the actual complex type of the property.Custom Edito rConfigurer, a bean factory post-processor, may be used to conveniently add support for additional PropertyEditor instances to an Application Context.
Consider a user class ExoticType, and another class DependsOnExoticType which needs ExoticType set as a property:
package example;When things are properly set up, we want to be able to assign the type property as a string, which a PropertyEditor will behind the scenes convert into an actual ExoticType instance:
<bean id="sample" class="example.DependsOnExoticType">The PropertyEditor implementation could look similar to this:
// converts string representation to ExoticType objectFinally, we use CustomEditorConfigurer to register the new PropertyEditor with the ApplicationContext, which will then be able to use it as needed:
<bean class="org.springframework.beans.factory.config.CustomEditorConfigurer">Using PropertyEditorRegistrars
Another mechanism for registering property editors with the Spring container is to create and use a PropertyEditorRegistrar.This interface is particularly useful when you need to use the same set of property editors in several different situations: write a corresponding registrar and reuse that in each case.Property Editor Registrars work in conjunction with an interface called Property Editor Registry, an interface that is implemented by the Spring BeanWrapper (and DataBinder).
Property Editor Registrars are particularly convenient when used in conjunction with the Custom Editor Configurer, which exposes a property called set Property Editor Registrars(..): Property Editor Registrars added to a CustomEditorConfigurer in this fashion can easily be shared with DataBinder and Spring MVC Controllers. Furthermore, it avoids the need for synchronization on custom editors: a Property Editor Registrar is expected to create fresh Property Editor instances for each bean creation attempt.
Using a PropertyEditorRegistrar is perhaps best illustrated with an example. First off, you need to create your own Property Editor Registrar implementation:
package com.foo.editors.spring;See also the org.spring frame work.beans.support.Resource Editor Registrar for an example Property Editor Registrar implementation. Notice how in its implementation of the register Custom Editors(..) method it creates new instances of each property editor.
Next we configure a CustomEditorConfigurer and inject an instance of our CustomProperty EditorRegistrar into it:
<bean class="org.springframework.beans.factory.config.CustomEditorConfigurer">find below an example of using a Property Editor Registrar in the implementation of an initBinder(..) method:
public final class RegisterUserController extends SimpleFormController {This style of Property Editor registration can lead to concise code (the implementation of initBinder(..) is just one line long!), and allows common PropertyEditor registration code to be encapsulated in a class and then shared amongst as many Controllers as needed.
|
|
Java-Springs Related Tutorials |
|
---|---|
Adv Java Tutorial | J2EE Tutorial |
Core Java Tutorial | JSP Tutorial |
Java Servlets Tutorial | Hibernate Tutorial |
Java Tutorial | Framework7 Tutorial |
Java 8 Tutorial |
Java-Springs Related Interview Questions |
|
---|---|
Adv Java Interview Questions | J2EE Interview Questions |
Core Java Interview Questions | JSP Interview Questions |
Java-Springs Interview Questions | Java Servlets Interview Questions |
JMS(Java Message Service) Interview Questions | Hibernate Interview Questions |
Java applet Interview Questions | Java Interview Questions |
Framework7 Interview Questions | Java collections framework Interview Questions |
Java 8 Interview Questions | Java Programmer Interview Questions |
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.