Google’s latest OS android 4.0.3

Till now galaxy Nexus is the only handset running Google’s latest OS android 4.0.
But Google recently announced its latest OS Android 4.0.3 which is an advanced release of Ice cream sandwich.
From the side of Android developers it is declared that the new OS will come with new optimization and bug fixes for android based tablets and smartphones.Apart from this optimization,there’s a small amount of new API’S for developers.Android 4.0.3 bring optimization and bug fixes to ICS.Google has listed some of the new API’S in ICE CREAM sandwich. Which includes a social stream API in contacts provider, calender provider enhancement, new and defined camera quality and accessibility refinements.This new API lets apps show users what the people they know are doing or saying along with photos and other contacts information.New camera capabilities enables the apps to manage video stabilization.There is also improvement in graphics ,spelling checking and many more.

J2EE Tutorial-12(Specifying the JNDI Names)

Although the J2EE application client and the Web client access the same enterprise bean, their code refers to the bean's home by different names. The J2EE application client refers to the bean's home asejb/SimpleConverter, but the Web client refers to it as ejb/TheConverter. These references are in the parameters of the lookup calls. In order for the lookup method to retrieve the home object, you must map the references in the code to the enterprise bean's JNDI name. Although this mapping adds a level of indirection, it decouples the clients from the beans, making it easier to assemble applications from J2EE components.

To map the enterprise bean references in the clients to the JNDI name of the bean, follow these steps.

1. In the tree, select ConverterApp.


2. Select the JNDI Names tab.


3. To specify a JNDI name for the bean, in the Application table locate the ConverterEJB component and enter MyConverter in the JNDI Name column.


4. To map the references, in the References table enter MyConverter in the JNDI Name for each row.

Figure 2-1 shows what the JNDI Names tab should look like after you've performed the preceding steps.

 

Figure 2-1 ConverterApp JNDI Names

J2EE Tutorial-6 (Reference Implementation Software)

The J2EE SDK is a noncommercial operational definition of the J2EE platform and specification made freely available by Sun Microsystems for demonstrations, prototyping, and educational use. It comes with the J2EE application server, Web server, relational database, J2EE APIs, and complete set of development and deployment tools. You can download the J2EE SDK from

http://java.sun.com/j2ee/download.html#sdk 

The purpose of the J2EE SDK is to allow product providers to determine what their implementations must do under a given set of application conditions, and to run the J2EE Compatibility Test Suite to test that their J2EE products fully comply with the specification. It also allows application component developers to run their J2EE applications on the J2EE SDK to verify that applications are fully portable across all J2EE products and tools.

Database Access

The relational database provides persistent storage for application data. A J2EE implementation is not required to support a particular type of database, which means that the database supported by different J2EE products can vary. See the Release Notes included with the J2EE SDK download for a list of the databases currently supported by the reference implementation.

J2EE APIs

The Java 2 Platform, Standard Edition (J2SE) SDK is required to run the J2EE SDK and provides core APIs for writing J2EE components, core development tools, and the Java virtual machine. The J2EE SDK provides the following APIs to be used in J2EE applications.

Enterprise JavaBeans Technology 2.0

An enterprise bean is a body of code with fields and methods to implement modules of business logic. You can think of an enterprise bean as a building block that can be used alone or with other enterprise beans to execute business logic on the J2EE server.

There are three kinds of enterprise beans: session beans, entity beans, and message-driven beans. Enterprise beans often interact with databases. One of the benefits of entity beans is that you do not have to write any SQL code or use the JDBC API directly to perform database access operations; the EJB container handles this for you. However, if you override the default container-managed persistence for any reason, you will need to use the JDBC API. Also, if you choose to have a session bean access the database, you have to use the JDBC API.

JDBC API 2.0

The JDBC API lets you invoke SQL commands from Java programing language methods. You use the JDBC API in an enterprise bean when you override the default container-managed persistence or have a session bean access the database. With container-managed persistence, database access operations are handled by the container, and your enterprise bean implementation contains no JDBC code or SQL commands. You can also use the JDBC API from a servlet or JSP page to access the database directly without going through an enterprise bean.

The JDBC API has two parts: an application-level interface used by the application components to access a database, and a service provider interface to attach a JDBC driver to the J2EE platform.

Java Servlet Technology 2.3

Java Servlet technology lets you define HTTP-specific servlet classes. A servlet class extends the capabilities of servers that host applications accessed by way of a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by Web servers.

JavaServer Pages Technology 1.2

JavaServer Pages technology lets you put snippets of servlet code directly into a text-based document. A JSP page is a text-based document that contains two types of text: static template data, which can be expressed in any text-based format such as HTML, WML, and XML, and JSP elements, which determine how the page constructs dynamic content.

Java Message Service 1.0

The JMS is a messaging standard that allows J2EE application components to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous. For more information on JMS, see the online Java Message Service Tutorial:

http://java.sun.com/products/jms/tutorial/index.html 

Java Naming and Directory Interface 1.2

The JNDI provides naming and directory functionality. It 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 J2EE application can store and retrieve any type of named Java object.

Because JNDI is independent of any specific implementations, applications can use JNDI to access multiple naming and directory services, including existing naming and directory services such as LDAP, NDS, DNS, and NIS. This allows J2EE applications to coexist with legacy applications and systems. For more information on JNDI, see the online JNDI Tutorial:

http://java.sun.com/products/jndi/tutorial/index.html 

Java Transaction API 1.0

The Java Transaction API ("JTA") provides a standard interface for demarcating transactions. The J2EE architecture provides a default auto commit to handle transaction commits and rollbacks. An auto commit means that any other applications viewing data will see the updated data after each database read or write operation. However, if your application performs two separate database access operations that depend on each other, you will want to use the JTA API to demarcate where the entire transaction, including both operations, begins, rolls back, and commits.

JavaMail API 1.2

J2EE applications can use the JavaMail API to send e-mail notifications. The JavaMail API has two parts: an application-level interface used by the application components to send mail, and a service provider interface. The J2EE platform includes JavaMail with a service provider that allows application components to send Internet mail.

JavaBeans Activation Framework 1.0

The JavaBeans Activation Framework ("JAF") is included because JavaMail uses it. It provides standard services to determine the type of an arbitrary piece of data, encapsulate access to it, discover the operations available on it, and create the appropriate JavaBeans component to perform those operations.

Java API for XML Processing 1.1

XML is a language for representing text-based data so the data can be read and handled by any program or tool. Programs and tools can generate XML documents that other programs and tools can read and handle. The Java API for XML Processing ("JAXP") supports processing of XML documents using DOM, SAX, and XSLT. JAXP enables applications to parse and transform XML documents independent of a particular XML processing implementation.

For example, a J2EE application can use XML to produce reports, and different companies that receive the reports can handle the data in a way that best suits their needs. One company might put the XML data through a program to translate the XML to HTML so it can post the reports to the Web, another company might put the XML data through a tool to create a marketing presentation, and yet another company might read the XML data into its J2EE application for processing.

J2EE Connector Architecture 1.0

The J2EE Connector architecture is used by J2EE tools vendors and system integrators to create resource adapters that support access to enterprise information systems that can be plugged into any J2EE product. A resource adapter is a software component that allows J2EE application components to access and interact with the underlying resource manager. Because a resource adapter is specific to its resource manager, there is typically a different resource adapter for each type of database or enterprise information system.

Java Authentication and Authorization Service 1.0

The Java Authentication and Authorization Service ("JAAS") provides a way for a J2EE application to authenticate and authorize a specific user or group of users to run it.

JAAS is a Java programing language version of the standard Pluggable Authentication Module (PAM) framework that extends the Java 2 Platform security architecture to support user-based authorization.

Simplified Systems Integration

The J2EE platform is a platform-independent, full systems integration solution that creates an open marketplace in which every vendor can sell to every customer. Such a marketplace encourages vendors to compete, not by trying to lock customers into their technologies but by trying to outdo each other by providing products and services that benefit customers, such as better performance, better tools, or better customer support.

The J2EE APIs enable systems and applications integration through the following:

• Unified application model across tiers with enterprise beans


• Simplified response and request mechanism with JSP pages and servlets


• Reliable security model with JAAS


• XML-based data interchange integration with JAXP


• Simplified interoperability with the J2EE Connector Architecture


• Easy database connectivity with the JDBC API


• Enterprise application integration with message-driven beans and JMS, JTA, and JNDI

You can learn more about using the J2EE platform to build integrated business systems by reading J2EE Technology in Practice.

Tools

The J2EE reference implementation provides an application deployment tool and an array of scripts for assembling, verifying, and deploying J2EE applications and managing your development and production environments. See Appendix B for a discussion of the tools.

Application Deployment Tool

The J2EE reference implementation provides an application deployment tool (deploytool) for assembling, verifying, and deploying J2EE applications. There are two versions: command line and GUI.

The GUI tool includes wizards for:

• Packaging, configuring, and deploying J2EE applications


• Packaging and configuring enterprise beans


• Packaging and configuring Web components


• Packaging and configuring application clients


• Packaging and configuring resource adaptors

In addition, configuration information can be set for each component and module type in the tabbed inspector panes.

Scripts

Table 1-1 lists the scripts included with the J2EE reference implementation that let you perform operations from the command line.



 

Table 1-1 J2EE Scripts 

Script	Description
j2ee	Start and stop the J2EE server
cloudscape	Start and stop the default database
j2eeadmin	Add JDBC drivers, JMS destinations, and connection factories for various resources
keytool	Create public and private keys and generate X509 self-signed certificate
realmtool	Import certificate files, add J2EE users to and remove J2EE users from the authentication and authorization list for a J2EE application
packager	Package J2EE application components into EAR, EJB JAR, application client JAR, and WAR files
verifier	Verify that EAR, EJB JAR, application client JAR, and WAR files are well-formed and comply with the J2EE specification
runclient	Run a J2EE application client
cleanup	Remove all deployed applications from the J2EE server

J2EE Tutorial-5 (Development Roles)

Reusable modules make it possible to divide the application development and deployment process into distinct roles so that different people or companies can perform different parts of the process.

The first two roles involve purchasing and installing the J2EE product and tools. Once software is purchased and installed, J2EE components can be developed by application component providers, assembled by application assemblers, and deployed by application deployers. In a large organization, each of these roles might be executed by different individuals or teams. This division of labor works because each of the earlier roles outputs a portable file that is the input for a subsequent role. For example, in the application component development phase, an enterprise bean software developer delivers EJB JAR files. In the application assembly role, another developer combines these EJB JAR files into a J2EE application and saves it in an EAR file. In the application deployment role, a system administrator at the customer site uses the EAR file to install the J2EE application into a J2EE server.

The different roles are not always executed by different people. If you work for a small company, for example, or if you are prototyping a sample application, you might perform the tasks in every phase.

J2EE Product Provider

The J2EE product provider is the company that designs and makes available for purchase the J2EE platform, APIs, and other features defined in the J2EE specification. Product providers are typically operating system, database system, application server, or Web server vendors who implement the J2EE platform according to the Java 2 Platform, Enterprise Edition Specification.

Tool Provider

The tool provider is the company or person who creates development, assembly, and packaging tools used by component providers, assemblers, and deployers. See the section Tools for information on the tools available with J2EE SDK version 1.3.

Application Component Provider

The application component provider is the company or person who creates Web components, enterprise beans, applets, or application clients for use in J2EE applications.

Enterprise Bean Developer

An enterprise bean developer performs the following tasks to deliver an EJB JAR file that contains the enterprise bean:

• Writes and compiles the source code


• Specifies the deployment descriptor


• Bundles the .class files and deployment descriptor into an EJB JAR file

Web Component Developer

A Web component developer performs the following tasks to deliver a WAR file containing the Web component:

• Writes and compiles servlet source code


• Writes JSP and HTML files


• Specifies the deployment descriptor for the Web component


• Bundles the .class, .jsp, .html, and deployment descriptor files in the WAR file

J2EE Application Client Developer

An application client developer performs the following tasks to deliver a JAR file containing the J2EE application client:

• Writes and compiles the source code


• Specifies the deployment descriptor for the client


• Bundles the .class files and deployment descriptor into the JAR file

Application Assembler

The application assembler is the company or person who receives application component JAR files from component providers and assembles them into a J2EE application EAR file. The assembler or deployer can edit the deployment descriptor directly or use tools that correctly add XML tags according to interactive selections. A software developer performs the following tasks to deliver an EAR file containing the J2EE application:

• Assembles EJB JAR and WAR files created in the previous phases into a J2EE application (EAR) file


• Specifies the deployment descriptor for the J2EE application


• Verifies that the contents of the EAR file are well formed and comply with the J2EE specification

Application Deployer and Administrator

The application deployer and administrator is the company or person who configures and deploys the J2EE application, administers the computing and networking infrastructure where J2EE applications run, and oversees the runtime environment. Duties include such things as setting transaction controls and security attributes and specifying connections to databases.

During configuration, the deployer follows instructions supplied by the application component provider to resolve external dependencies, specify security settings, and assign transaction attributes. During installation, the deployer moves the application components to the server and generates the container-specific classes and interfaces.

A deployer/system administrator performs the following tasks to install and configure a J2EE application:

• Adds the J2EE application (EAR) file created in the preceding phase to the J2EE server


• Configures the J2EE application for the operational environment by modifying the deployment descriptor of the J2EE application


• Verifies that the contents of the EAR file are well formed and comply with the J2EE specification


• Deploys (installs) the J2EE application EAR file into the J2EE server

J2EE Tutorial-3 (J2EE Containers)

J2EE Containers

Normally, thin-client multitiered applications are hard to write because they involve many lines of intricate code to handle transaction and state management, multithreading, resource pooling, and other complex low-level details. The component-based and platform-independent J2EE architecture makes J2EE applications easy to write because business logic is organized into reusable components. In addition, the J2EE server provides underlying services in the form of a container for every component type. Because you do not have to develop these services yourself, you are free to concentrate on solving the business problem at hand.

Container Services

Containers are the interface between a component and the low-level platform-specific functionality that supports the component. Before a Web, enterprise bean, or application client component can be executed, it must be assembled into a J2EE application and deployed into its container.

The assembly process involves specifying container settings for each component in the J2EE application and for the J2EE application itself. Container settings customize the underlying support provided by the J2EE server, which includes services such as security, transaction management, Java Naming and Directory Interface (JNDI) lookups, and remote connectivity. Here are some of the highlights:

• The J2EE security model lets you configure a Web component or enterprise bean so that system resources are accessed only by authorized users.


• The J2EE transaction model lets you specify relationships among methods that make up a single transaction so that all methods in one transaction are treated as a single unit.


• JNDI lookup services provide a unified interface to multiple naming and directory services in the enterprise so that application components can access naming and directory services.


• The J2EE remote connectivity model manages low-level communications between clients and enterprise beans. After an enterprise bean is created, a client invokes methods on it as if it were in the same virtual machine.

The fact that the J2EE architecture provides configurable services means that application components within the same J2EE application can behave differently based on where they are deployed. For example, an enterprise bean can have security settings that allow it a certain level of access to database data in one production environment and another level of database access in another production environment.

The container also manages nonconfigurable services such as enterprise bean and servlet life cycles, database connection resource pooling, data persistence, and access to the J2EE platform APIs described in the section J2EE APIs. Although data persistence is a nonconfigurable service, the J2EE architecture lets you override container-managed persistence by including the appropriate code in your enterprise bean implementation when you want more control than the default container-managed persistence provides. For example, you might use bean-managed persistence to implement your own finder (search) methods or to create a customized database cache.

Container Types

The deployment process installs J2EE application components in the J2EE containers illustrated in Figure 1-5.

 

Figure 1-5 J2EE Server and Containers

J2EE server

 

The runtime portion of a J2EE product. A J2EE server provides EJB and Web containers. 

Enterprise JavaBeans (EJB) container

 

Manages the execution of enterprise beans for J2EE applications. Enterprise beans and their container run on the J2EE server. 

Web container

 

Manages the execution of JSP page and servlet components for J2EE applications. Web components and their container run on the J2EE server. 

Application client container

 

Manages the execution of application client components. Application clients and their container run on the client. 

Applet container

 

Manages the execution of applets. Consists of a Web browser and Java Plug-in running on the client together.

J2EE Tutorial -1 (overview)

Today, more and more developers want to write distributed transactional applications for the enterprise and leverage the speed, security, and reliability of server-side technology. If you are already working in this area, you know that in today's fast-moving and demanding world of e-commerce and information technology, enterprise applications have to be designed, built, and produced for less money, with greater speed, and with fewer resources than ever before.

To reduce costs and fast-track enterprise application design and development, the Java 2 Platform, Enterprise Edition (J2EE) technology provides a component-based approach to the design, development, assembly, and deployment of enterprise applications. The J2EE platform offers a multitiered distributed application model, the ability to reuse components, integrated Extensible Markup Language (XML)-based data interchange, a unified security model, and flexible transaction control. Not only can you deliver innovative customer solutions to market faster than ever, but your platform-independent J2EE component-based solutions are not tied to the products and application programming interfaces (APIs) of any one vendor. Vendors and customers enjoy the freedom to choose the products and components that best meet their business and technological requirements.

This tutorial takes an examples-based approach to describing the features and functionalities available in J2EE Software Development Kit (SDK) version 1.3. Whether you are a new or an experienced enterprise developer, you should find the examples and accompanying text a valuable and accessible knowledge base for creating your own enterprise solutions.

If you are new to J2EE applications development, this chapter is a good place to start. Here you will learn the J2EE architecture, become acquainted with important terms and concepts, and find out how to approach J2EE application programming, assembly, and deployment.

Receiving mail with attachment using javamail API

import java.util.*;
import javax.mail.*;
import javax.mail.internet.*;
import javax.activation.*;
import java.io.*;

class ReadAttachment{
public static void main(String [] args)throws Exception{

String host="mail.javatpoint.com";
final String user="sonoojaiswal@javatpoint.com";
final String password="xxxxx";//change accordingly

Properties properties = System.getProperties();
properties.setProperty("mail.smtp.host",host );
properties.put("mail.smtp.auth", "true");

Session session = Session.getDefaultInstance(properties,
new javax.mail.Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(user,password);
}
});

Store store = session.getStore("pop3");
store.connect(host,user,password);

Folder folder = store.getFolder("inbox");
folder.open(Folder.READ_WRITE);

Message[] message = folder.getMessages();
for (int a = 0; a < message.length; a++) {
System.out.println("-------------" + (a + 1) + "-----------");
System.out.println(message[a].getSentDate());

Multipart multipart = (Multipart) message[a].getContent();

for (int i = 0; i < multipart.getCount(); i++) {
BodyPart bodyPart = multipart.getBodyPart(i);
InputStream stream = bodyPart.getInputStream();
BufferedReader br = new BufferedReader(new InputStreamReader(stream));

while (br.ready()) {
System.out.println(br.readLine());
}
System.out.println();
}
System.out.println();
}

folder.close(true);
store.close();
}
}

LOAD THE JAR FILE :  C:\> set classpath=mail.jar;activation.jar;

COMPILE THE SOURCE FILE: C:\> javac ReadAttachment.java

RUN BY :C:\> java ReadAttachment

Google releases 'experimental' full-text search API for App Engine

Google is testing a long-awaited full-text search API (application programming interface) for the Google App Engine, the company said on Tuesday.

The App Engine lets developers build Web applications hosted on Google's infrastructure, and developers have long complained that the current search API is inadequate.

[ Keep up with software development issues and trends with InfoWorld's Fatal Exception blog. | Master the latest in Java development with our JavaWorld Enterprise Java newsletter. | Follow the cloud with InfoWorld's Cloud Computing blog andCloud Computing Report newsletter. ]

"Beside the cruel irony [of] not having full-text search I am starting to wonder why it would take Google so long to implement this," a developer wrote in the App Engine forum last month.

Google released the full-text search API in "experimental" mode and warned it could make changes in future versions that might be incompatible with the current API.

The API will allow users to search by keyword and delineate specific fields and ranges, Google said. The new capabilities also include scoring and snippeting.

Developers can use the API for free up to 20,000 calls a day or a total index size of 250 megabytes.

Cameron Scott covers search, web services and privacy for The IDG News Service. Follow Cameron on Twitter at CScott_IDG.