Search This Blog


Friday, July 27, 2012

EL: Expression language 2.2 Distilled

Here I will give a brief introduction and also some improvement done in JSR 245, The Expression Language (also referred to as the EL),
which provides an important mechanism for enabling the presentation layer (web pages) to communicate with the application logic (managed beans).

The EL is used by both JavaServer Faces technology and JavaServer Pages (JSP) technology.

The EL represents a union of the expression languages offered by JavaServer Faces technology and JSP technology.

The EL allows page authors to use simple expressions to dynamically access data from JavaBeans components.

For example, the test attribute of the following conditional tag is supplied with an EL expression that compares 0 with the number of items in the session-scoped bean named cart.

JavaServer Faces technology uses the EL for the following functions:
  • Deferred and immediate evaluation of expressions.

  • The ability to set as well as get data.

  • The ability to invoke methods.

To summarize, the EL provides a way to use simple expressions to perform the following tasks:
  • Dynamically read application data stored in JavaBeans components, various data structures, and implicit objects.

  • Dynamically write data, such as user input into forms, to JavaBeans components.

  • Invoke arbitrary static and public methods.

  • Dynamically perform arithmetic operations.

The EL is also used to specify the following kinds of expressions that a custom tag attribute will accept:
  • Immediate evaluation expressions or deferred evaluation expressions. An immediate evaluation expression is evaluated at once by the underlying technology, such as JavaServer Faces.

    A deferred evaluation expression can be evaluated later by the underlying technology using the EL.

  • Value expression or method expression. A value expression references data, whereas a method expression invokes a method.

  • Rvalue expression or lvalue expression. An rvalue expression can only read a value, whereas an lvalue expression can both read and write that value to an external object.

Immediate and Deferred Evaluation Syntax
The EL supports both immediate and deferred evaluation of expressions. Immediate evaluation means that the expression is evaluated and the result returned as soon as the page is first rendered.

Deferred evaluation means that the technology using the expression language can use its own machinery to evaluate the expression sometime later during the page’s lifecycle, whenever it is appropriate to do so, because of its multiphase lifecycle, JavaServer Faces technology uses mostly deferred evaluation expressions.

Those expressions that are evaluated immediately use the ${} syntax. Expressions whose evaluation is deferred use the #{} syntax.
  1. Immediate Evaluation
    All expressions using the ${} syntax are evaluated immediately. These expressions can be used only within template text or as the value of a tag attribute that can accept runtime expressions.

    The following example shows a tag whose value attribute references an immediate evaluation expression that gets the total price from the session-scoped bean named cart:

    The JavaServer Faces implementation evaluates the expression ${}, converts it, and passes the returned value to the tag handler.

    Immediate evaluation expressions are always read-only value expressions. The preceding example expression cannot set the total price, but instead can only get the total price from the cart bean.

  2. Deferred Evaluation
    Deferred evaluation expressions take the form #{expr} and can be evaluated at other phases of a page lifecycle as defined by whatever technology is using the expression. In the case of JavaServer Faces technology, its controller can evaluate the expression at different phases of the lifecycle, depending on how the expression is being used in the page.

    The following example shows a JavaServer Faces h:inputText tag, which represents a text field component into which a user enters a value. The h:inputText tag’s value attribute references a deferred evaluation expression that points to the name property of the customer bean:

    For an initial request of the page containing this tag, the JavaServer Faces implementation evaluates the #{} expression during the render-response phase of the lifecycle.

    During this phase, the expression merely accesses the value of name from the customer bean, as is done in immediate evaluation.

    For a postback request, the JavaServer Faces implementation evaluates the expression at different phases of the lifecycle, during which the value is retrieved from the request, validated, and propagated to the customer bean.

    As shown in this example, deferred evaluation expressions can be:
    • Value expressions that can be used to both read and write data.

    • Method expressions.

    Value expressions (both immediate and deferred) and method expressions are explained in the next section.
Value and Method Expressions
The EL defines two kinds of expressions: value expressions and method expressions. Value expressions can either yield a value or set a value. Method expressions reference methods that can be invoked and can return a value.

Value Expressions
Value expressions can be further categorized into rvalue and lvalue expressions. Rvalue expressions can read data but cannot write it. Lvalue expressions can both read and write data.

All expressions that are evaluated immediately use the ${} delimiters and are always rvalue expressions. Expressions whose evaluation can be deferred use the #{} delimiters and can act as both rvalue and lvalue expressions. Consider the following two value expressions:

The former uses immediate evaluation syntax, whereas the latter uses deferred evaluation syntax. The first expression accesses the name property, gets its value, adds the value to the response, and gets rendered on the page. The same can happen with the second expression. However, the tag handler can defer the evaluation of this expression to a later time in the page lifecycle, if the technology using this tag allows.

In the case of JavaServer Faces technology, the latter tag’s expression is evaluated immediately during an initial request for the page. In this case, this expression acts as an rvalue expression. During a postback request, this expression can be used to set the value of the name property with user input. In this case, the expression acts as an lvalue expression.

Method Expressions
Another feature of the EL is its support of deferred method expressions. A method expression is used to invoke an arbitrary public method of a bean, which can return a result.

In JavaServer Faces technology, a component tag represents a component on a page. The component tag uses method expressions to invoke methods that perform some processing for the component. These methods are necessary for handling events that the components generate and for validating component data, as shown in this example:

The h:inputText tag displays as a text field. The validator attribute of this h:inputText tag references a method, called validateName, in the bean, called customer.

Because a method can be invoked during different phases of the lifecycle, method expressions must always use the deferred evaluation syntax. Like lvalue expressions, method expressions can use the (.) and the ([]) operators.

For example,
#{object.method} is equivalent to #{object["method"]}. The literal inside the [] is converted to String and is used to find the name of the method that matches it. Once the method is found, it is invoked, or information about the method is returned.

Parameterized Method Calls
The EL offers support for parameterized method calls.Method calls can use parameters without having to use static EL functions.

Both the . and [] operators can be used for invoking method calls with parameters, as shown in the following expression syntax:
  • expr-a[expr-b](parameters)

  • expr-a.identifier-b(parameters)
In the first expression syntax, expr-a is evaluated to represent a bean object. The expression expr-b is evaluated and cast to a string that represents a method in the bean represented by expr-a. In the second expression syntax, expr-a is evaluated to represent a bean object, and identifier-b is a string that represents a method in the bean object. The parameters in parentheses are the arguments for the method invocation. Parameters can be zero or more values or expressions, separated by commas.

Parameters are supported for both value expressions and method expressions. In the following example, which is a modified tag from the guessnumber application, a random number is provided as an argument rather than from user input to the method call:

The preceding example uses a value expression.

Consider the following example of a JavaServer Faces component tag that uses a method expression:

The EL expression calls the trader bean’s buy method. You can modify the tag to pass on a parameter.Here is the revised tag where a parameter is passed:

In the preceding example, you are passing the string ’SOMESTOCK’ (a stock symbol) as a parameter to the buy method.

Literal Expressions
A literal expression is evaluated to the text of the expression, which is of type String. A literal expression does not use the ${} or #{} delimiters.

If you have a literal expression that includes the reserved ${} or #{} syntax, you need to escape these characters as follows:
  • By creating a composite expression as shown here:
    • ${’${’}exprA}
    • #{’#{’}exprB}
    The resulting values would then be the strings ${exprA} and #{exprB}.

  • By using the escape characters \$ and \# to escape what would otherwise be treated as an eval-expression:
    • \${exprA}
    • \#{exprB}
The resulting values would again be the strings ${exprA} and #{exprB}. When a literal expression is evaluated, it can be converted to another type.

Literal expressions can be evaluated immediately or deferred and can be either value or method expressions. At what point a literal expression is evaluated depends on where it is being used. If the tag attribute that uses the literal expression is defined to accept a deferred value expression, when referencing a value, the literal expression is evaluated at a point in the lifecycle that is determined by other factors, such as where the expression is being used and to what it is referring.

In the case of a method expression, the method that is referenced is invoked and returns the specified String literal.


Saturday, July 21, 2012

JSF: The JavaServer Faces Technology

JavaServer Faces Technology

JavaServer Faces technology is a server-side component framework for building Java technology-based web applications.

JavaServer Faces technology consists of the following:
  1. An API for representing components and managing their state; handling events, server-side validation, and data conversion; defining page navigation; supporting internationalization and accessibility; and providing extensibility for all these features.

  2. Tag libraries for adding components to web pages and for connecting components to server-side objects JavaServer Faces technology provides a well-defined programming model and various tag libraries. These features significantly ease the burden of building and maintaining web applications with server-side user interfaces (UIs). With minimal effort, you can complete the following tasks.
    • Create a web page.
    • Drop components onto a web page by adding component tags.

    • Bind components on a page to server-side data.

    • Wire component-generated events to server-side application code.

    • Save and restore application state beyond the life of server requests.

    • Reuse and extend components through customization.

What Is a JavaServer Faces Application?

The functionality provided by a JavaServer Faces application is similar to that of any other Java web application. A typical JavaServer Faces application includes the following parts:
  • A set of web pages in which components are laid out.

  • A set of tags to add components to the web page.

  • A set of managed beans, which are lightweight container-managed objects (POJOs) with minimal requirements. They support a small set of basic services, such as resource injection, lifecycle callbacks and interceptors.

  • A web deployment descriptor (web.xml file).

  • Optionally, one or more application configuration resource files, such as a faces-config.xml file, which can be used to define page navigation rules and configure beans and other custom objects, such as custom components.

  • Optionally, a set of custom objects, which can include custom components, validators, converters, or listeners, created by the application developer.

  • A set of custom tags for representing custom objects on the page.
Figure 1 shows the interaction between client and server in a typical JavaServer Faces application. In response to a client request, a web page is rendered by the web container that implements JavaServer Faces technology.

Figure 1: Responding to a Client Request for a JavaServer Faces Page.

The web page, index.xhtml, is built using JavaServer Faces component tags. Component tags are used to add components to the view (represented by helloUI in the diagram), which is the server-side representation of the page. In addition to components, the web page can also reference objects, such as the following:
  • Any event listeners, validators, and converters that are registered on the components.

  • The JavaBeans components that capture the data and process the application-specific functionality of the components.

On request from the client, the view is rendered as a response. Rendering is the process whereby, based on the server-side view, the web container generates output, such as HTML or XHTML, that can be read by the client, such as a browser.

JavaServer FacesTechnology Benefits

One of the greatest advantages of JavaServer Faces technology is that it offers a clean separation between behavior and presentation for web applications. A JavaServer Faces application can map HTTP requests to component-specific event handling and manage components as stateful objects on the server. JavaServer Faces technology allows you to build web applications that implement the finer-grained separation of behavior and presentation that is traditionally offered by client-side UI architectures.

The separation of logic from presentation also allows each member of a web application development team to focus on a single piece of the development process and provides a simple programming model to link the pieces. For example, page authors with no programming expertise can use JavaServer Faces technology tags in a web page to link to server-side objects without writing any scripts.

Another important goal of JavaServer Faces technology is to leverage familiar component and web-tier concepts without limiting you to a particular scripting technology or markup language. JavaServer Faces technology APIs are layered directly on top of the Servlet API, as shown in Figure 2.

Figure 2: Java Web Application Technologies.

This layering of APIs enables several important application use cases, such as using different presentation technologies, creating your own custom components directly from the component classes, and generating output for various client devices.

Facelets technology, available as part of JavaServer Faces 2.0, is now the preferred presentation technology for building JavaServer Faces technology-based web applications.

Facelets technology offers several advantages:
  • Code can be reused and extended for components through the templating and composite component features.

  • When you use the JavaServer Faces Annotations feature, you can automatically register the managed bean as a resource available for JavaServer Faces applications. In addition, implicit navigation rules allow developers to quickly configure page navigation. These features reduce the manual configuration process for applications.

  • Most important, JavaServer Faces technology provides a rich architecture for managing component state, processing component data, validating user input, and handling events.

For more information on JavaServer Faces technology, see:

Thursday, July 19, 2012

Glassfish: Dynamic Reloading Feature

Dynamic Reloading

If dynamic reloading is enabled, you do not have to redeploy an application or module when you change its code or deployment descriptors. All you have to do is copy the changed pages or class files into the deployment directory for the application or module. The deployment directory for a web module named context-root is domain-dir/applications/context-root.

The server checks for changes periodically and redeploys the application, automatically and dynamically, with the changes.

This capability is useful in a development environment because it allows code changes to be tested quickly.

Dynamic reloading IS NOT RECOMMENDED for a production environment, however, because it may degrade performance. In addition, whenever a reload is done, the sessions at that time become invalid, and the client must restart the session.

Note: In the GlassFish Server, dynamic reloading is enabled by default.

To Disable or ModifyDynamic Reloading

If for some reason you do not want the default dynamic reloading behavior, follow these steps in the Administration Console.
  1. Open the URL http://localhost:4848/ in a browser.

  2. Select the GlassFish Server node.

  3. Select the Advanced tab.

  4. To disable dynamic reloading, deselect the Reload Enabled check box.

  5. To change the interval at which applications and modules are checked for code changes and dynamically reloaded, type a number of seconds in the Reload Poll Interval field.

    The default value is 2 seconds.

  6. Click the Save button.

Saturday, July 14, 2012

JEE: Java Naming and Directory Interface API (JNDI)

The Java Naming and Directory Interface (JNDI) API provides naming and directory functionality, enabling applications to access multiple naming and directory services, including existing naming and directory services, such as LDAP, NDS,DNS, and NIS.

The JNDI API provides applications with methods for performing standard directory operations, such as associating attributes with objects and searching for objects using their attributes.

Using JNDI, a Java EE application can store and retrieve any type of named Java object, allowing Java EE applications to coexist with many legacy applications and systems.

Java EE naming services provide application clients, enterprise beans, and web components with access to a JNDI naming environment. A naming environment allows a component to be customized without the need to access or change the component’s source code. A container implements the component’s environment and provides it to the component as a JNDI naming context.

A Java EE component can locate its environment naming context by using JNDI interfaces. A component can create a javax.naming.InitialContext object and look up the environment naming context in InitialContext under the name java:comp/env.

A component’s naming environment is stored directly in the environment naming context or in any of its direct or indirect subcontexts.

A Java EE component can access named system-provided and user-defined objects. The names of system-provided objects, such as JTA UserTransaction objects, are stored in the environment naming context java:comp/env. The Java EE platform allows a component to name user-defined objects, such as enterprise beans, environment entries, JDBC DataSource objects, and message connections. An object should be named within a subcontext of the naming environment according to the type of the object.

For example, enterprise beans are named within the subcontext java:comp/env/ejb, and JDBC DataSource references are named within the subcontext java:comp/env/jdbc.

JEE: Java EE Connector Architecture (JCA)

The Java EE Connector architecture is used by tools vendors and system integrators to create resource adapters that support access to enterprise information systems that can be plugged in to any Java EE product.

A resource adapter is a software component that allows Java EE application components to access and interact with the underlying resource manager of the EIS.

Because a resource adapter is specific to its resource manager, a different resource adapter typically exists for each type of database or enterprise information system.

The Java EE Connector architecture also provides a performance-oriented, secure, scalable, and message-based transactional integration of Java EE based web services with existing EISs that can be either synchronous or asynchronous.

Existing applications and EISs integrated through the Java EE Connector architecture into the Java EE platform can be exposed as XML-based web services by using JAX-WS and Java EE component models.

Thus JAX-WS and the Java EE Connector architecture are complementary technologies for enterprise application integration (EAI) and end-to-end business integration.

The Java EE 6 platform requires Java EE Connector architecture 1.6.

Wednesday, July 11, 2012

ADF: ADF & JSF Object Scope Lifecycles

At runtime, you pass data to pages by storing the needed data in an object scope where the page can access it. The scope determines the lifespan of an object. Once you place an object in a scope, it can be accessed from the scope using an EL expression.

For example, you might create a managed bean named foo, and define the bean to live in the Request scope. To access that bean, you would use the expression #{requestScope.varName}.

There are three types of scopes in a standard JSF application:
  • applicationScope: The object is available for the duration of the application.

  • sessionScope: The object is available for the duration of the session.

  • requestScope: The object is available for the duration between the time an HTTP request is sent until a response is sent back to the client.

In addition to the standard JSF scopes, ADF Faces provides the following scopes:
  • pageFlowScope: The object is available as long as the user continues navigating from one page to another. If the user opens a new browser window and begins navigating, that series of windows will have its own pageFlowScope scope.

  • viewScope: The object is available until the ID for the current view changes. Use viewScope scope to hold values for a given page.

  • backingBeanScope: Used for managed beans for page fragments and declarative components only. The object is available for the duration between the time an HTTP request is sent until a response is sent back to the client. This scope is needed because there may be more than one page fragment or declarative component on a page, and to avoid collisions between values, any values must be kept in separate scope instances. Use backingBeanScope scope for any managed bean created for a page fragment or declarative component.
Because these are not standard JSF scopes, EL expressions must explicitly include the scope to reference the bean. For example, to reference theMyBean managed bean from the pageFlowScope scope, your expression would be #{pageFlowScope.MyBean}.

Object scopes are analogous to global and local variable scopes in programming languages. The wider the scope, the higher the availability of an object.

During their lifespan, these objects may expose certain interfaces, hold information, or pass variables and parameters to other objects.

For example, a managed bean defined in sessionScope scope will be available for use during multiple page requests. However, a managed bean defined in requestScope scope will be available only for the duration of one page request.

When determining what scope to register a managed bean with or to store a value in, always try to use the narrowest scope possible. Use the sessionScope scope only for information that is relevant to the whole session, such as user or context information. Avoid using the sessionScope scope to pass values from one page to another.