Notice that you do not need a special configuration to register the MessageEventListener with the
ApplicationContext; it is picked up automatically by Spring. Running this example results in the
following output:
Received: Hello World!
Received: The quick brown fox jumped over the lazy dog
Considerations for Event Usage
There are many cases in an application where certain components need to be notified of certain events.
Often you do this by writing code to notify each component explicitly or by using a messaging
technology such as JMS. The drawback of writing code to notify each component in turn is that you are
coupling those components to the publisher, in many cases unnecessarily.
Consider a situation where you cache product details in your application to avoid trips to the
database. Another component allows product details to be modified and persisted to the database. To
avoid making the cache invalid, the update component explicitly notifies the cache that the user details
have changed. In this example, the update component is coupled to a component that, really, has
nothing to do with its business responsibility. A better solution would be to have the update component
publish an event every time a product's details are modified and then have interested components, such
as the cache, listen for that event. This has the benefit of keeping the components decoupled, which
makes it simple to remove the cache if you need or to add another listener that is interested in knowing
when a product's details change.
Using JMS in this case would be overkill, because the process of invalidating the product's entry in
the cache is quick and is not business critical. The use of the Spring event infrastructure adds very little
overhead to your application.
Typically, we use events for reactionary logic that executes quickly and is not part of the main
application logic. In the previous example, the invalidation of a product in cache happens in reaction to
the updating of product details, it executes quickly (or it should), and it is not part of the main function
of the application. For processes that are long running and form part of the main business logic, it is
recommended to use JMS or similar messaging systems such as RabbitMQ. The main benefits of using
JMS is that it is more suited to long-running processes, and as the system grows, you can, if necessary,
factor the JMS-driven processing of messages containing business information onto a separate
machine.
Accessing Resources
Often an application needs to access a variety of resources in different forms. You might need to access
some configuration data stored in a file in the file system, some image data stored in a JAR file on the
classpath, or maybe some data on a server elsewhere. Spring provides a unified mechanism for accessing
resources in a protocol-independent way. This means your application can access a file resource in the
same way, whether it is stored in the file system, in the classpath, or on a remote server.
At the core of Spring's resource support is the org.springframework.core.io.Resource interface. The
Resource interface defines ten self-explanatory methods: contentLength(), exists(), getDescription(),
getFile(), getFileName(), getURI(), getURL(), isOpen(), isReadable(), and lastModified(). In addition to
these ten methods, there is one that is not quite so self-explanatory: createRelative(). The
createRelative() method creates a new Resource instance using a path that is relative to the instance on
which it is invoked. You can provide your own Resource implementations, although that is outside the
scope of this chapter, but in most cases, you use one of the built-in implementations for accessing file
(the FileSystemResource class), classpath (the ClassPathResource class), or URL resources (the
UrlResource class).
Search WWH :
Custom Search
Previous Page
Spring Framework 3 Topic Index
Next Page
Spring Framework 3 Bookmarks
Home