JSF(Java Server Faces), initially implemented by Sun as a Framework and released as JSF version 1.0. Its next release was JSF version 1.1, however, its currently used release is JSF 1.2 under JEE 5.
JSF 1.2 is technology and is intended to develop web based applications quickly. JSF technology specification given by SUN Microsystem and implemented by two vendors :-
1. SUN RI(Reference Implementation)
2. Apache (My Faces)
Other vendor do exists in this arena as given below :-
* Rich Faces
* A4J (AJAX 4 JSF)
* Ice Faces
Like Struts framework, JSF is also implemented based on two popular design patters :-
* Front Controller
* MVC design pattern
----------------------------------------------------
Presentation | Controller | Model Layer
----------------------------------------------------
JSP I/P --> FacesServlet<-->JSF BEAN
web.xml (DD) Model
faces-config.xml
JSP O/P <--
----------------------------------------------------
FacesContext :
--------------
javax.faces.context
Class FacesContext
java.lang.Object extended by javax.faces.context.FacesContext
public abstract class FacesContext extends java.lang.Object
FacesContext contains all of the per-request state information related to the processing of a single JavaServer Faces request, and the rendering of the corresponding response. It is passed to, and potentially modified by, each phase of the request processing lifecycle.
A FacesContext instance is associated with a particular request at the beginning of request processing, by a call to the getFacesContext() method of the FacesContextFactory instance associated with the current web application. The instance remains active until its release() method is called, after which no further references to this instance are allowed. While a FacesContext instance is active, it must not be referenced from any thread other than the one upon which the servlet container executing this web application utilizes for the processing of this request.
FacesContext object is created by the Framework Servlet (i.e FacesServlet). Whenever a request arise, there will be only one FacesContext object. FacesContext object holds the following information with respect to request which is currently under processing :-
1. UIViewRoot (javax.faces.component.UIViewRoot)
2. Error Messages related to validations
3. Error Messages related to converstions
4. Response stream in terms of ByteStream
5. ExternalContext (public abstract class ExternalContext extends java.lang.Object)
6. RenderKit (public abstract class RenderKit extends java.lang.Object)
Wednesday, December 8, 2010
Saturday, January 30, 2010
JNI Tuter
JNI (Java Native Interface) is a standard programming interface for writing Java native methods and embedding the JVM into native application. By writing programs using the JNI, you ensure that your code is completely portable across all platforms.
The JNI allows Java code that runs within a Java Virtual Machine (VM) to operate with applications and libraries written in other languages, such as C, C++, and assembly. In addition, the Invocation API allows you to embed the Java Virtual Machine into your native applications.
Programmers use the JNI to write native methods to handle those situations when an application cannot be written entirely in the Java programming language. For example, you may need to use native methods and the JNI in the following situations:
• The standard Java class library may not support the platform-dependent features needed by your application.
• You may already have a library or application written in another programming language and you wish to make it accessible to Java applications.
• You may want to implement a small portion of time-critical code in a lower-level programming language, such as assembly, and then have your Java application call these functions.
The JNI framework lets your native method utilize Java objects in the same way that Java code uses these objects. A native method can create Java objects, including arrays and strings, and then inspect and use these objects to perform its tasks. A native method can also inspect and use objects created by Java application code. A native method can even update Java objects that it created or that were passed to it, and these updated objects are available to the Java application. Thus, both the native language side and the Java side of an application can create, update, and access Java objects and then share these objects between them.
Native methods can also easily call Java methods. Often, you will already have developed a library of Java methods. Your native method does not need to "re-invent the wheel" to perform functionality already incorporated in existing Java methods. The native method, using the JNI framework, can call the existing Java method, pass it the required parameters, and get the results back when the method completes.
The JNI enables you to use the advantages of the Java programming language from your native method. In particular, you can catch and throw exceptions from the native method and have these exceptions handled in the Java application. Native methods can also get information about Java classes. By calling special JNI functions, native methods can load Java classes and obtain class information. Finally, native methods can use the JNI to perform runtime type checking.
We better start with one example where we can learn how to write program using JNI technology. So, here our mission is to prepare a demo where java program calls method written in C language.
Step1: Java Side
The first step in using the JNI is to create a Java file that will call our native C code.
Create a Java file called Hello.java with the following contents:
//File: Hello.java
class Hello {
public native void sayHello();
static {
System.loadLibrary("hello");
}
public static void main(String[] args) {
Hello h = new Hello();
h.sayHello ();
}
}
There are two items that distinguish this from regular Java code. The first is the
declaration of a native method using the keyword native.
public native void sayHello();
This tells the compiler that sayHello() will be accessed from an external library, and that
it should not look for it in the Java source code. Accordingly, notice that there is no
implementation of this method present in the Java code.
The second unusual looking section of code is the following:
static {
System.loadLibrary("hello");
}
This will load the external library “hello.” In Windows this file will be named
“hello.dll”. The exact name of the file is dependent on the operating system conventions
for naming of libraries.
Rest of the code is easy and regular java code which is understandable.
Step2: C Side
The remainder of the process is concerned with creating the library that will contain the
sayHello() method declared in our Java code.
To simplify the process of creating our library, the “javah” program will automatically
generate the header file for us. Simply execute the following at the command prompt in
the correct folder:
javah -jni Hello
This produces the file Hello.h. It contains the C declarations for the methods that were
declared native in Hello.java. If we open the Hello.h file we will see the following code:
/* DO NOT EDIT THIS FILE - it is machine generated */
#include
/* Header for class Hello */
#ifndef _Included_Hello
#define _Included_Hello
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: Hello
* Method: sayHello
* Signature: ()V
*/
JNIEXPORT void JNICALL Java_Hello_sayHello
(JNIEnv *, jobject);
#ifdef __cplusplus
}
#endif
#endif
The crucial component is the C declaration for our sayHello method.
JNIEXPORT void JNICALL Java_Hello_sayHello
(JNIEnv *, jobject);
Here, we can see how method signature is generated by javah command.
Java_Hello_sayHello - Java_ClassName_methodName
Naturally, this is done to distinguish it from methods that belong to other classes and might have the same name. When we implement the C function, we need to ensure that we use the exact same method signature as is provided in the header file. It is not auto-generated for us, so we have to be careful in this regard.
Create a file called Hello.c. This will contain the implementation of our sayHello()
method. Enter the following code:
//File: Hello.c
#include
#include "Hello.h"
#include
JNIEXPORT void JNICALL Java_Hello_sayHello
(JNIEnv *env, jobject obj)
{
printf(“Welcome to JNI…!\n");
printf(“Congratulations for you first Step…”);
return;
}
Consider each line of this code in turn. First, we include the header, which is
required if we wish to use the JNI. The second line includes our auto-generated header
file. The third line includes the C standard I/O functions, so that we can use printf.
Next we see the method signature that we first saw in Hello.h. The only difference
between this line and the one in Hello.h is that the parameters to the method now have
names specified. Later we will learn how these two parameters allow us to communicate
data to and from our Java code. For now, we can simply ignore them. Using the C printf function, we display the message on the console, and then return from the function.
Step3: Generating Object file without Linking.
For generating object file, we require now gcc command which will be used to generate object file without creating exe file. This object file is further required to generate dll file.
We used MinGW-5.1.2.exe file so that gcc command may be installed in windows as well. Here you need to install this software. Then we will set path variable so that we can access it from any drive or any path. This completes initial set-up and now we are ready to execute gcc command.
gcc -c -I"C:\jdk1.4\include" -I"C:\jdk1.4\include\win32" -o hello.o Hello.c
The -c option tells the compiler not to link the program just yet, since we only want to produce an object file and not an executable.
The -I parameter adds two paths to your standard include paths, so the compiler can
access the necessary JNI header files. The paths are\include and \include\win32, where is replaced with the directory in which the Java SDK is installed on your machine. If the path name contains internal spaces, it has to be surrounded by double quotes for clarity (both for the reader and the compiler). If done correctly, this command will produce a file called hello.o.
Step4: Create Defination File.
In this step, we will create hello.def file which contains only function name which we are calling using JNI. This file format is given below:
hello.def file contains.
EXPORT
Java_Hello_sayHello
Since we have defined only one method, we are here calling only one. But if there are more native functions defined , then we need to include all of them one after another.
Step5: Creating DLL file.
To produce hello.dll, we use gcc one more time.
gcc -shared -o hello.dll hello.o hello.def
This command will generate hello.dll file with the following warning:
Warning: resolving _Java_Hello_sayHello by linking to
_Java_Hello_sayHello@8
This informs you that the compiler is automatically dealing with an issue involving the
calling conventions in Windows. Behind the scenes, gcc converts functionName to
functionName@xx, where xx is the number of bytes passed to the function on the stack.
What the compiler is warning us is that it is automatically associating functionName with
functionName@xx so that when a program looks for functionName in the library, it will
correctly be referred to functionName@xx. For a program as simple as ours, we can
essentially ignore this warning since this is the behaviour we expect.
To verify that the program is working correctly, we can run it as we would with any other Java program.
java Hello
Welcome To JNI…
Congratulations for you first Step…
The JNI allows Java code that runs within a Java Virtual Machine (VM) to operate with applications and libraries written in other languages, such as C, C++, and assembly. In addition, the Invocation API allows you to embed the Java Virtual Machine into your native applications.
Programmers use the JNI to write native methods to handle those situations when an application cannot be written entirely in the Java programming language. For example, you may need to use native methods and the JNI in the following situations:
• The standard Java class library may not support the platform-dependent features needed by your application.
• You may already have a library or application written in another programming language and you wish to make it accessible to Java applications.
• You may want to implement a small portion of time-critical code in a lower-level programming language, such as assembly, and then have your Java application call these functions.
The JNI framework lets your native method utilize Java objects in the same way that Java code uses these objects. A native method can create Java objects, including arrays and strings, and then inspect and use these objects to perform its tasks. A native method can also inspect and use objects created by Java application code. A native method can even update Java objects that it created or that were passed to it, and these updated objects are available to the Java application. Thus, both the native language side and the Java side of an application can create, update, and access Java objects and then share these objects between them.
Native methods can also easily call Java methods. Often, you will already have developed a library of Java methods. Your native method does not need to "re-invent the wheel" to perform functionality already incorporated in existing Java methods. The native method, using the JNI framework, can call the existing Java method, pass it the required parameters, and get the results back when the method completes.
The JNI enables you to use the advantages of the Java programming language from your native method. In particular, you can catch and throw exceptions from the native method and have these exceptions handled in the Java application. Native methods can also get information about Java classes. By calling special JNI functions, native methods can load Java classes and obtain class information. Finally, native methods can use the JNI to perform runtime type checking.
We better start with one example where we can learn how to write program using JNI technology. So, here our mission is to prepare a demo where java program calls method written in C language.
Step1: Java Side
The first step in using the JNI is to create a Java file that will call our native C code.
Create a Java file called Hello.java with the following contents:
//File: Hello.java
class Hello {
public native void sayHello();
static {
System.loadLibrary("hello");
}
public static void main(String[] args) {
Hello h = new Hello();
h.sayHello ();
}
}
There are two items that distinguish this from regular Java code. The first is the
declaration of a native method using the keyword native.
public native void sayHello();
This tells the compiler that sayHello() will be accessed from an external library, and that
it should not look for it in the Java source code. Accordingly, notice that there is no
implementation of this method present in the Java code.
The second unusual looking section of code is the following:
static {
System.loadLibrary("hello");
}
This will load the external library “hello.” In Windows this file will be named
“hello.dll”. The exact name of the file is dependent on the operating system conventions
for naming of libraries.
Rest of the code is easy and regular java code which is understandable.
Step2: C Side
The remainder of the process is concerned with creating the library that will contain the
sayHello() method declared in our Java code.
To simplify the process of creating our library, the “javah” program will automatically
generate the header file for us. Simply execute the following at the command prompt in
the correct folder:
javah -jni Hello
This produces the file Hello.h. It contains the C declarations for the methods that were
declared native in Hello.java. If we open the Hello.h file we will see the following code:
/* DO NOT EDIT THIS FILE - it is machine generated */
#include
/* Header for class Hello */
#ifndef _Included_Hello
#define _Included_Hello
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: Hello
* Method: sayHello
* Signature: ()V
*/
JNIEXPORT void JNICALL Java_Hello_sayHello
(JNIEnv *, jobject);
#ifdef __cplusplus
}
#endif
#endif
The crucial component is the C declaration for our sayHello method.
JNIEXPORT void JNICALL Java_Hello_sayHello
(JNIEnv *, jobject);
Here, we can see how method signature is generated by javah command.
Java_Hello_sayHello - Java_ClassName_methodName
Naturally, this is done to distinguish it from methods that belong to other classes and might have the same name. When we implement the C function, we need to ensure that we use the exact same method signature as is provided in the header file. It is not auto-generated for us, so we have to be careful in this regard.
Create a file called Hello.c. This will contain the implementation of our sayHello()
method. Enter the following code:
//File: Hello.c
#include
#include "Hello.h"
#include
JNIEXPORT void JNICALL Java_Hello_sayHello
(JNIEnv *env, jobject obj)
{
printf(“Welcome to JNI…!\n");
printf(“Congratulations for you first Step…”);
return;
}
Consider each line of this code in turn. First, we include the
required if we wish to use the JNI. The second line includes our auto-generated header
file. The third line includes the C standard I/O functions, so that we can use printf.
Next we see the method signature that we first saw in Hello.h. The only difference
between this line and the one in Hello.h is that the parameters to the method now have
names specified. Later we will learn how these two parameters allow us to communicate
data to and from our Java code. For now, we can simply ignore them. Using the C printf function, we display the message on the console, and then return from the function.
Step3: Generating Object file without Linking.
For generating object file, we require now gcc command which will be used to generate object file without creating exe file. This object file is further required to generate dll file.
We used MinGW-5.1.2.exe file so that gcc command may be installed in windows as well. Here you need to install this software. Then we will set path variable so that we can access it from any drive or any path. This completes initial set-up and now we are ready to execute gcc command.
gcc -c -I"C:\jdk1.4\include" -I"C:\jdk1.4\include\win32" -o hello.o Hello.c
The -c option tells the compiler not to link the program just yet, since we only want to produce an object file and not an executable.
The -I parameter adds two paths to your standard include paths, so the compiler can
access the necessary JNI header files. The paths are
Step4: Create Defination File.
In this step, we will create hello.def file which contains only function name which we are calling using JNI. This file format is given below:
hello.def file contains.
EXPORT
Java_Hello_sayHello
Since we have defined only one method, we are here calling only one. But if there are more native functions defined , then we need to include all of them one after another.
Step5: Creating DLL file.
To produce hello.dll, we use gcc one more time.
gcc -shared -o hello.dll hello.o hello.def
This command will generate hello.dll file with the following warning:
Warning: resolving _Java_Hello_sayHello by linking to
_Java_Hello_sayHello@8
This informs you that the compiler is automatically dealing with an issue involving the
calling conventions in Windows. Behind the scenes, gcc converts functionName to
functionName@xx, where xx is the number of bytes passed to the function on the stack.
What the compiler is warning us is that it is automatically associating functionName with
functionName@xx so that when a program looks for functionName in the library, it will
correctly be referred to functionName@xx. For a program as simple as ours, we can
essentially ignore this warning since this is the behaviour we expect.
To verify that the program is working correctly, we can run it as we would with any other Java program.
java Hello
Welcome To JNI…
Congratulations for you first Step…
Subscribe to:
Comments (Atom)