Spring study [5]

Externalizing properties in spring is easy if you are using an applicationcontext as your spring container. You use spring's propertyplaceholderconfigurer to tell spring to load certain configuration from an external property file.

Single Property File
<Bean id = "propertyconfigurer" class = "org. springframework. Beans. Factory. config. propertyplaceholderconfigurer">
<Property name = "location">
<Value> JDBC. properties </value>
</Property>
</Bean>

multi property file



JDBC. properties
Security. properties
application. properties

$ {database. URL}


$ {database. driver }


$ {database. user}


$ {database. password }

the java. beans. propertyeditor interface provides a means to customize how string values are mapped to non-string types. there is a convenience implementation of this interface-java.beans.PropertyEditorSupport-that has two methods of
interest to us:
■ getastext () returns the string representation of a property's value.
■ setastext (string value) sets a bean property value from the string value passed in.

spring comes with several custom editors based on propertyeditorsupport, including Org. springframework. beans. propertyeditors. urleditor, which is the custom editor used to convert strings to and from java.net. URL objects. some other editm editors that come with spring include
■ classeditor-sets a java. lang. class property from a string value that contain the fully qualified class name
■ customdateeditor-sets a java. util. date property from a string using a custom Java. text. dateformat object
■ fileeditor-sets a java. io. file property from a string value that contains a file's path
■ localeeditor-sets a java. util. locale property from a string value that contains a textual representation of the locale (I. E ., "en_us ")
■ stringarraypropertyeditor-converts a comma-delimited string to a string array property
■ stringtrimmereditor-automatically trims string properties with an option to convert empty string values to null

To use resourcebundlemessagesource, add the following to the bean wiring file:
<Bean id = "messagesource" class = "org. springframework. Context. Support. resourcebundlemessagesource">
<Property name = "basename">
<Value> trainingtext </value>
</Property>
</Bean>

Locale locale =... ; // Determine locale
String text =
Context. getmessage ("computer", new object [0], locale );

In the course of an application's life time, the applicationcontext will publish a handful of events that tell interested listeners what's going on. these events are all subclasses of the abstract class Org. springframework. context. application-
Event. Three such application events are
■ Contextclosedevent-published when the application context is closed
■ Contextrefreshedevent-published when the application context is initialized or refreshed
■ Requesthandledevent-published within a web application context when a request is handled

If you want a bean to respond to application events, all you need to do is implement the org. springframework. Context. applicationlistener interface.

The only thing you need to do to tell spring about an Application Event listener is to simply register it as a bean within the context:
<Bean id = "refreshlistener" class = "com. springinaction. Foo. refreshlistener"/>

In the case of spring beans, comes in the form of the beannameaware, beanfactoryaware, and applicationcontextaware interfaces.

With AOP, you still define the common functionality in one place, but you can declaratively define how and where this functionality is applied without having to modify the class to which you are applying the new feature. cross-cutting concerns can now be modularized into special objects called aspects. this has two benefits. first, the logic for each concern is now in one place, as opposed to being scattered all over the code base. second, our service modules are now cleaner since they only contain code for their core functionality and secondary concerns have been moved to aspects.