Technology Discussion

JSF Life Cycle

2010-07-01T03:01:00.000-07:00

Read lot of article on JSF life cycle and trying to compile a composed one, hope this would help developers to have a better understanding on JSF.

This is JSF Life cycle digram

Phase 1: Restore View:Before getting into this we should understand these·
Initial request: A user requests the page for the first time.
Postback: A user submits the form contained on a page that was previously loaded into the browser as a result of executing an initial request.

When a request for a JavaServer Faces page is made, such as when a link or a button is clicked, the JavaServer Faces implementation begins the restore view phase.In this phase of JSF lifecycle --a request comes through the FacesServlet the Controller of JSF. The controller examines the request and extracts the view ID, which is determined by the name of the JSP page.The JSF framework controller uses the view ID to look up the components for thecurrent view. If the view doesn't already exist, the JSF controller creates it. If theview already exists, the JSF controller uses it. The view contains all the GUI components builds the view of the Faces page and wires the event handlers and validators to thecomponents. The view is saved in a FacesContext object.The FacesContext object contains all the state information JSF needs to manage the GUI component's state for the current request in the current session. The FacesContext stores the view in its viewRoot property; viewRoot contains all the JSF components for the current view ID.In the case of an initial view (the first time a page is loaded), JSF creates an empty iew. The empty view will be populated as the user causes events to occur. From an initial view, JSF advances directly to the render response phase.In the case of a postback the view corresponding to the page already exists, so it needs only to be restored. In this case, JSF uses the existing view's state information to reconstruct its state. The next phase after a postback is apply request values

Phase 2: Apply Request Values
The purpose of the apply request values phase is for each component to retrieve its current state. The components must first be retrieved or created from theFacesContext object, followed by their values. Component values are typicallyretrieved from the request parameters, although they can also be retrieved fromcookies or headers.If a component's immediate event handling property is not set to true, the values are just converted. So if the field is bound to an Integer property, the value is converted to an Integer. If the value conversion fails, an error message is generated and queued in the FacesContext, where it will be displayed during the render response phase, along with any validation errors.If a component's immediate event handling property is set to true, the values are converted to the proper type and validated. The converted value is then stored in the component. If the value conversion or value validation fails, an error message is generated and queued in the FacesContext, where it will be displayed during the render response phase, along with any other validation errors.

Phase 3: Process Validation
The first event handling of the lifecycle takes place after the apply request valuesphase. At this stage, each component will have its values validated against theapplication's validation rules. The validation rules can be pre-defined (shipped with JSF Framework) or defined by the developer. Values entered by the user are compared to the validation rules. If an entered value is invalid, an error message is added toFacesContext, and the component is marked invalid. If a component is marked invalid, JSF advances to the render response phase, which will display the current view with the validation error messages. If there are no validation errors, JSF advances to the update model values phase.

Phase 4: Update Model Values
In this phase updates the actual values of the server-side model -- namely, by updating the properties of applications backing beans (also called managed beans). Only bean properties that are bound to a component's value will be updated. Notice that this phase happens after validation, so you can be sure that the values copied to your bean's properties are valid (at least at the form-field level; they may still be invalid at the business-rule level).

Phase 5: Invoke Application
In this phase the JSF controller invokes the application to handle Form submissions. The component values will have been converted, validated, and applied to the model objects, so this can be now used them to execute the application's business logic.At this phase, developer also get to specify the next logical view for a given sequence or number of possible sequences. You do this by defining a specific outcome for a successful form submission and returning that outcome. For example: on successful outcome, move the user to the next page. For this navigation to work, you will have to create a mapping to the successful outcome as a navigation rule in the faces-config.xml file. Once the navigation occurs, you move to the final phase of the lifecycle.

Phase 6: Render Response
Finally, Render Response brings several inverse behaviors together in one process:· Values are transferred back to the UI components from the bean. Including any modifications that may have been made by the bean itself or by the controller.
The UI components save their state not just their values, but other attributes having to do with the presentation itself. This can happen serverside, but by default state is written into the HTML as hidden input fields and thus returns to the JSF implementation with the next request.· If the request is a postback and errors were encountered during the apply request values phase, process validations phase, or update model values phase, the original page is rendered during this phase. If the pages contain message or messages tags, any queued error messages are displayed on the page.

Spring Autowiring

2010-06-02T23:11:00.000-07:00

Spring Auto Wiring is dependencies through introspection of the bean classes so that you do not have to explicitly specify the bean properties or constructor arguments. Bean properties can be autowired either by property names or matching types. Constructor arguments can be autowired by matching types. You can even specify the autodetect autowiring mode, which lets Spring choose an appropriate mechanism.

no
byName
byType
constructor
autodirect

Consider the below Examples

Spring can scan its configuration file at runtime, looking for a class the same type as a property found on your main object. Once found, it creates an instance of that type and then injects that instance into the object's property. It has been a subject for debate as to whether it is a good idea to let Spring assume this responsibility. The traditional approach has been to wire beans manually, using the ref keyword in a configuration file:

Here, a bean of the 'EmpDao' type is injected into a bean of the 'EmpManager' type, assuming there is a property and setter method in the EmpManager class:

public class EmpManager {

private EmpDao empDao;

public EmpDao getEmpDao() {
   return empDao;
}

public void setEmpDao(EmpDao empDao) {
   this.empDao = empDao;
}

...
}

By using @Autowired, you can eliminate the additional XML in your configuration file that specifies the relationship between two objects. Also, you no longer need methods to set the property in the owning class. Just include a private or protected variable and Spring will do the rest. Here's the modified XML:

And the code...

import org.springframework.beans.factory.annotation.Autowired;
public class EmpManager {
@Autowired
private EmpDao empDao;
}

@Autowired is not just for property injection, but also can be used in methods and constructors. You can potentially reduce a great deal of XML and code with this technique. Having said this, autowiring can cause problems in more complex object models. When using @Autowired, if one and only one of the type you are looking for cannot be found, an error occurs. This is an improvement over traditional autowiring which will, by default, fail silently when an exact match cannot be found. Luckily, with @Autowired, you can add a 'Qualifier' attribute to identify by type and name when two objects are of the same type:

@Autowired
@Qualifier("empDao")

As you would expect, @Autowired is not a cure-all and it might not make sense for every situation. It is easy to fall back on traditional configuration when @Autowired does not fit. However, @Autowired is a nice option for developers building Spring applications.


Spring can be configured to autowire dependencies using introspection of the bean classes. This
saves you from having to explicitly specify the bean properties and from specifying the constructor
arguments. In theory, this sounds great. It saves you from some potential typing, it reduces the
size and clutter of your XML Spring configuration files, and it reduces the chance that you'll miss
something in the configuration. This makes for a great demo on how easy it is to use Spring and
get up and running quickly.

But while it's great for a demo on a small project, it's far less useful on a real-world application.
Without having the bean configurations laid-out explicitly, the maintainability of your project
Save yourself the trouble ahead of time. It takes a little longer to get things up and running,
but in the long-term you'll be much better off if you turn off the autowiring capability in the Spring
gets worse; the bigger your project gets, the harder it is to maintain.

Guide To Eh-Cache

2010-01-27T12:46:00.000-08:00

EH Cache:

Ehcache is a widely used java distributed cache for general purpose caching, Java EE and light-weight containers.

It features memory and disk stores, replicate by copy and invalidate, listeners, cache loaders, cache extensions, cache exception handlers, a gzip caching servlet filter, RESTful & SOAP APIs, an implementation of JSR107

Feature:

Fast.

Simple:

Minimal dependency: The only dependency for core use is the JCACHE API.

Scalable:

1.Provides Memory and Disk stores for scalabilty into gigabytes.

2. Scalable to hundreds of caches

3. Tuned for high concurrent load on large multi-cpu servers
4. Multiple CacheManagers per virtual machine

Ehcache 1.2 introduced multiple CacheManagers per virtual machine. This enables completely difference ehcache.xml configurations to be applied.

Flexible:

1. Supports Object or Serializable caching

Non-serializable Objects can use all parts of Ehcache except for DiskStore and replication

2. Support cache-wide or Element-based expiry policies

Time to lives and time to idles are settable per cache. In addition, from ehcache-1.2.1, overrides to these can be set per Element.

#Provides LRU, LFU and FIFO cache eviction policies

#Provides Memory and Disk stores

Ehcache, like most of the cache solutions, provides high performance memory and disk stores.

Distributed:

Ehcache 1.2 introduced a full-featured, fine-grained distributed caching mechanism for clusters, supporting multiple replication mechanisms through plugins

Persistent disk store which stores data between VM restarts

With Ehcache 1.1 in 2004, Ehcache was the first open source Java cache to introduce persistent storage of cache data on disk on shutdown. The cached data is then accessible the next time the application runs.

Flush to disk on demand

With Ehcache 1.2, the flushing of entries to disk can be executed with a cache.flush() method whenever required, making it easier to use ehcache

Listeners

CacheManager listeners

· notifyCacheAdded()

· notifyCacheRemoved()

Cache event listeners

Register Cache Event Listeners through the CacheEventListener interfaces, which provides a lot of flexibility for post-processing of cache events. The methods are:

· notifyElementRemoved

· notifyElementPut

· notifyElementUpdated

· notifyElementExpired

JMX Enabled

Ehcache is JMX enabled. You can monitor and manage the following MBeans:

· CacheManager

· Cache

· CacheConfiguration

· CacheStatistics

Cache Server

Ehcache now comes with a Cache Server, available as a WAR for most web containers, or as a standalone server. The Cache Server has two apis: RESTful resource oriented, and SOAP. Both support clients in any programming language.

RESTful cache server

The Ehcache implementation strictly follows the RESTful resource-oriented architecture style

SOAP cache server

The Ehcache RESTFul Web Services API exposes the singleton CacheManager, which typically has been configured in ehcache.xml or an IoC container. Multiple CacheManagers are not supported.

#Code Samples:

All usages of Ehcache start with the creation of a CacheManager.

Singleton versus Instance

As of ehcache-1.2, Ehcache CacheManagers can be created as either singletons (use the create factory method) or instances (use new).

Create a singleton CacheManager using defaults, then list caches.This method creates a cache manager or return if already provides the CacheManager if already exists. The CacheManager is created for each config file.

CacheManager.create();

String[] cacheNames = CacheManager.getInstance().getCacheNames();

Create a CacheManager instance using defaults, then list caches.

CacheManager manager = new CacheManager();

String[] cacheNames = manager.getCacheNames();

Create two CacheManagers, each with a different configuration, and list the caches in each.

CacheManager manager1 = new CacheManager("src/config/ehcache1.xml");

CacheManager manager2 = new CacheManager("src/config/ehcache2.xml");

String[] cacheNamesForManager1 = manager1.getCacheNames();

String[] cacheNamesForManager2 = manager2.getCacheNames();