Dear folks, Welcome back to my blog once again for getting very good information about the commercial products, politics, Hollywood, Bollywood or what ever is happening in the world. Like the same I will going to introduce some thing very interesting for you and you car or any floor. When ever you are searching about the car parts you will always miss the floor-mats. Yes that is the topic I will talk about today.
There are so many floor mats company around the world but you will never see such a good quality product in your life but for sure you will like carid’s floor mats. It will come lifelong and more worth always. Please visit their internet page on floor mats section for more information on this product.
There are many verities like acura, alfa romio, audi, BMW floor mats according to their company and it will fit for their car. Some verities of the floor mats are really fit for their situation like winter season or summer season. The floor mats are also considered according to the luxurious of the car and prices will also varies with low cast plan to medium level. Still reading the same? I did not expect as I gave the path aleady for the best floor mats. I’m going again to the same and lets meet there..
Dear folks, Welcome back to my blog once again for getting very good information about the commercial products, politics, Hollywood, Bollywood or what ever is happening in the world. Like the same I will going to introduce some thing very interesting for you and you car or any floor. When ever you are searching about the car parts you will always miss the floor-mats. Yes that is the topic I will talk about today.
The iBatis framework is a lightweight data mapping framework and persistence API that can be used to quickly leverage a legacy database schema to generate a database persistence layer for your Java application. A set of XML encoded SQL Map files–one for each database table–holds SQL templates that are executed as prepared statements and map the expected results to Java domain classes. From application code, a layer of iBatis Data Access Objects (DAO) acts as the API that executes the SQL Map templates and assigns the results to the corresponding Java domain classes. Therefore, the architectural stack looks like this:
This tutorial will show how to automatically generate the code for these three layers from an existing database. To enable communication among these layers, an XML configuration file describes each DAO interface and implementation class, as well as the location of a second XML configuration file that in turn points to each SQL Map file and contains the database connection information.
This tutorial will focus on using iBatis in a Java application and a legacy MySQL database. Abator, a code generation tool for creating the files mentioned above, will also be introduced, but otherwise, only basic familiarity with Java, XML, and SQL are assumed along with a few common Java tools and libraries including Eclipse, Ant and Log4J.
This introduction assumes a fairly standard project directory structure, including these directories and files directly under the project root:
Other XML files and Java *.properties files not automatically generated by Abator are assumed to be directly under src/ . This introduction shows iBatis configured for a database running on localhost, so obviously a locally running MySQL server is needed.
If you are interested in the Spring Framework’s MVC packages, this could be helpful. It’s a unified description of the life cycle of a web application or portlet request as handled by Spring Web MVC and Spring Portlet MVC. I created this for two reasons: I wanted a quick reference to the way Spring finds handlers for each stage of the request; and I wanted a unified view so I could see the similarities and differences between Web MVC and Portlet MVC.
Spring Web MVC, part of the Spring Framework, has long been a highly-regarded web application framework. With the recent release of Spring 2.0, Spring now supports portlet development with the Spring Portlet MVC package. Portlet MVC builds on Web MVC; even their documentation is similar. My focus right now is on portlet development, and I found it cumbersome to have to read the Web MVC and Portlet MVC documentation simultaneously. So I have re-edited the two together into one unified document. I have also included related information from elsewhere in the documentation, so it’s all in one place.
My idea here is to make it easy to go through your Spring configuration files and ensure that all beans are declared and named as they should be, whether you are using Spring Web MVC or Spring Portlet MVC.
Spring’s Web and Portlet MVC are request-driven web MVC frameworks, designed around a servlet or portlet that dispatches requests to controllers. Spring’s dispatchers (DispatcherServlet and DispatcherPortlet) are also completely integrated with the Spring ApplicationContext and allow you to use every other feature Spring has.
The DispatcherServlet is a standard servlet (extending HttpServlet), and as such is declared in the web.xml of your web application. Requests that you want the DispatcherServlet to handle should be mapped using a URL mapping in the same web.xml file. Similarly, the DispatcherPortlet is a standard portlet (extending GenericPortlet), and as usual is declared in the portlet.xml of your web application. This is all standard J2EE configuration;
In the Portlet MVC framework, each DispatcherPortlet has its own WebApplicationContext, which inherits all the beans already defined in the root WebApplicationContext. These inherited beans can be overridden in the portlet-specific scope, and new scope-specific beans can be defined local to a given portlet instance.
When a DispatcherServlet or DispatcherPortlet is set up for use and a request comes in for that specific dispatcher, it starts processing the request. The sections below describe the complete process a request goes through when handled by such a dispatcher, from determining the application context right through to rendering the view.
For Web MVC only, the WebApplicationContext is searched for and bound in the request as an attribute in order for the controller and other elements in the process to use. It is bound by default under the key DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE.
The locale is bound to the request to let elements in the process resolve the locale to use when processing the request (rendering the view, preparing data, etc.). For Web MVC, this is the locale resolver. For Portlet MVC, this is the locale returned by PortletRequest.getLocale(). Note that locale resolution is not supported in Portlet MVC — this is in the purview of the portal/portlet container and is not appropriate at the Spring level. However, all mechanisms in Spring that depend on the locale (such as internationalisation of messages) will still function properly because DispatcherPortlet exposes the current locale in the same way as DispatcherServlet.
For Web MVC only, the theme resolver is bound to the request to let elements such as views determine which theme to use. The theme resolver does not affect anything if you don’t use it, so if you don’t need themes you can just ignore it. Theme resolution is not supported in Portlet MVC — this area is in the purview of the portal/portlet container and is not appropriate at the Spring level.
Multipart form submissions
For Web MVC and for Portlet MVC Action requests, if a multipart resolver is specified, the request is inspected for multiparts. If they are found, the request is wrapped in a MultipartHttpServletRequest or MultipartActionRequest for further processing by other elements in the process.
Spring looks at all handler mappings (beans implementing the appropriate HandlerMapping interface) in the application context. Any that implement the Ordered interface are sorted (lowest order first), and others are added at the end of the list. The handler mappings are tried in order until one yields a handler. (Note: if the dispatcher’s detectAllHandlerMappings attribute is set to false, then this changes: Spring simply uses the handler mapping bean called “handlerMapping” and ignores any others.)
If a handler is found, the execution chain associated with the handler (pre-processors, controllers and post-processors) will be executed in order to prepare a model for rendering. The handler chain returns a View object or a view name, and normally also returns a model. For example, a pre-processor may block the request for security reasons and render its own view; in this case it will not return a model.
Note that the handler chain need not explicitly return a view or view name. If it does not, Spring creates a view name from the request path. For example, the path /servlet/apac/NewZealand.jsp yields the view name “apac/NewZealand”. This behaviour is implemented by an implicitly-defined DefaultRequestToViewNameTranslator bean; you can configure your own bean (which must be called “viewNameTranslator”) if you want to customise its behaviour.
Exceptions that are thrown during processing of the request go to the hander exception resolver chain. Spring looks at all hander exception resolvers (beans implementing the appropriate HandlerExceptionResolverinterface) in the application context. Any that implement the Ordered interface are sorted (lowest order first), and others are added at the end of the list. The resolvers are tried in order until one yields a model and view. (Note: if the dispatcher’s detectAllHandlerExceptionResolvers attribute is set to false, then this changes: Spring simply uses the hander exception resolver bean called “handlerExceptionResolver” and ignores any others.)
If the handler chain returns a view name and a model, Spring uses the configured view resolvers to resolve the view name to a View. Spring looks at all view resolvers (beans implementing the ViewResolver interface) in the application context. Any that implement the Ordered interface are sorted (lowest order first), and others are added at the end of the list. Then the view resolvers are tried in order until one yields a view. (Note: if the dispatcher’s detectAllViewResolvers attribute is set to false, then this changes: Spring simply uses the view resolver bean called “viewResolver” and ignores any others.)
If the handler chain returns a View object, then no view resolution is necessary. Similarly, if it does not return a model, then no view will be rendered, so again no view resolution is necessary.
If we now have a view and a model, then Spring uses the view to render the model. This is what the user will see in the browser window or portlet.
Developers can now build RIAs using a common set of APIs for both the desktop and mobile platforms, enriched with high-fidelity audio and video, rich text, vector graphics, animation and Web services. JavaFX Mobile runs on Java Platform Micro Edition (Java ME) technology, allowing desktop and Web developers to optimize their applications for the form factor of a specific device, and for particular mobile capabilities, so they are "already pretty far along in delivering [their applications] to mobile devices," said Param Singh, senior director of Java marketing with Sun Microsystems Corp.
"Our vision of providing a programming model that spans across multiple screens is one of the core fundamental changes versus development in the past," said Singh.
The company is taking a different approach to the mobile environment, said Singh, by working with OEMs and operator partners to cover the entire device stack, including mass market and smart phones. "It's really about how do we help build an ecosystem where there are hundreds and thousands of applications that meet the consumer needs" on a variety of platforms, said Singh.
While Sun will continue to focus on the high-end feature phone market, Singh said the company does recognize there is lots of growth in the lower end where those consumers, too, have demands for the same type of cross-platform access to their information.
And basing JavaFX Mobile in Java ME technology, said Singh, responds to operator and OEM partner demands for tighter integration and lowered costs by being able to build upon their investments in the existing Java ME stack. With other vendor platforms, he added, "you can build nice visual applications but then how do you tap into device capabilities? It's at best a very difficult exercise."
Rob Enderle, principal analyst with San Jose, Calif.-based research firm Enderle Group, said the difficulty for Sun in the mobile RIA space is that "they're late to the game and other parties are already in place." Reigning supreme is Adobe Systems Corp., whom even Microsoft Corp. has had trouble displacing, said Enderle.
But that said, the upside is that Java is one of those technologies that does play broadly in the mobile arena "and the idea of being able to use a Java derivative for a more graphically intense experience could be attractive to some developers," said Enderle.
"Depending on how hard it is to move to JavaFX, some developers that otherwise might not even look at it at all, might be attracted to it," said Enderle.
In this article I will present some configuration tips for the Spring MVC framework that could help you manage multiple instances of your Spring-based web application. The configuration management topic is often neglected in the literature, but as we will see, it is very important for real-life web development. It is not directly related to any particular technology, so we will start by explaining the basic concepts of the problem. Next, we will focus on the Spring MVC framework and offer a few solutions for projects developed using this technology.
It is common for a web application to be deployed on more than one host. Take, for example, a website that will have only one instance in production. Beside that instance, you (as its developer) will probably have another (development) instance on your development machine. You may also find useful to maintain another installation of your application on some local development server inside of your company (organization). The purpose of this instance would usually be to give access to web designers, for quality assurance stuff, to people that should document the application, etc.
As you can see, even in this simplest possible scenario there are three instances of the application that we should install, configure, and maintain. The situation is even worse for geographically dispersed teams that work on a project like this. For any non-trivial web application project, you will usually have more that one developer with his local installation of the project and local settings, one installation for running unit tests, and so on.
Many organizations create their products as web applications. You may find examples of such products in various e-commerce systems, content management systems (CMSes), or even blog publishing platforms. Products like these are intended for deployment on as many servers as possible. For successful acceptance of general-purpose web applications, their developers must ensure that their apps are easy to install and integrate well with other web applications. After this discussion, it should be clear that application configuration, which is the topic of this article, is one of the very important issues for developers of general-purpose web application projects.
Version control systems, such as CVS or Subversion, are one of the standard tools used by development organizations. This kind of tool represents a central source code repository of some organization and is used to keep the source code in order. Users are able to track changes of the application's source, show differences among file versions, and make project branches. Also, they make partial updates on the application deployments possible.
It is clear that version control system software is necessary for keeping track of your source code and that it can help in a great deal with the application configuration problems discussed here. Still, in this article, we will not focus on version control systems, as there are lots of great materials that cover this topic. Here, we will focus on just a small subtopic of the version control issue: how to ease the configuration of web applications (particularly those written using the Spring MVC framework).
The question is: what kind of configuration we are talking about here? Well, any web application needs resources that are usually specific to the host on which it is running, such as the database URL, the SMTP server that will send emails, folders that will contain some application-specific documents, etc. Settings like these should be centralized so that application configuration could be as easy as possible.
But this describes only the simplest version of the problem. Sometimes, you need more complex configuration differences among application deployments. This means that you will have to make different bean wirings among deployments, which complicates this issue even further.
Solutions to these application configuration issues have many benefits, ranging from easier installation and configuration of your application to easier source version control, which leads to fewer conflicts in your source repository. Now let's discuss this topic in more detail and through examples.
Let's start with demonstrating the simpler version of the problem we described above. In this scenario, all that you want to change among application deployments are simple configuration parameters, such as URLs, passwords, etc. If you have ever tried to develop a web application using the Spring MVC framework, you know that there are two configuration files that should be used:
/WEB-INF/applicationContext.xml allows you to configure your beans, or to indicate the context of your application. This is the place where you define your business logic beans, resources, and all other beans that are not directly related to the web tier.
/WEB-INF/[servlet-name]-servlet.xml is used to configure the web tier and view resolvers, controllers, validators, and all other beans that you need in the MVC framework. The [servlet-name] refers to the name of the Spring's dispatcher servlet defined in the web.xml deployment descriptor.
So what's the problem here? The problem is that your applicationContext.xml will contain some bean definitions that are host-specific. The most obvious example of this issue is a bean that holds JDBC connection information, but any non-trivial application will have a dozen such beans. Take a look at the following example:
The problem with this solution is in hard maintenance of the applicationContext.xml file. For starters, imagine that you have your project in the source code version control system, such as CVS. Now let's say that you want to add new functionality to your website, and for that, you need to put some extra bean definitions in the application context definition. The problem is how to reflect those changes on the production server.
Usually your local instance of the application will not use the same database as the live site, so the applicationContext.xml file will contain settings to access your local database. When you want to commit your changes in the source repository, you have to take care of synchronization of these host-specific properties. The file in the repository will probably end up with configuration from your local settings. Now, when you want to update the configuration on the production server, you will have to manually synchronize the values of the properties. This can be a very tedious task, and is also very prone to errors.
With every instance of the application, this issue becomes more important. Imagine that three developers work on the code base and that they each use their local database. When you commit your changes, each of them must be very careful when updating source code on their local hosts. Their manual synchronization of your changes, followed by committing of their work, makes the version control system useless for these configuration files. If you've ever used Spring MVC, you know that applicationContext.xml is the crucial element of your application, since it is the glue that holds things together. Therefore, it is very important to find a mechanism that helps us keep things organized in our applications.
As we said earlier, this is the easier configuration problem that you can experience. The harder version of the problem is when you need to have different bean wirings on different hosts. Examples of this kind of problem are very easy to find in everyday software development tasks. For instance, imagine that you have a custom authentication module for your product that is able to authenticate users from relational databases or LDAP servers. Naturally, the authentication module could be configured with the bean that abstracts a certain repository. If you want to change how users are authenticated among different application deployments, you will need to make different bean wirings in your applicationContext.xml file. This kind of configuration issue could be seen in all applications that have configurable features among deployments.
Spring is an open-source application framework, introduced and developed in 2004. The main ideas were suggested by an experienced J2EE architect, Rod Johnson.
He had earlier, written a book titled 'J2EE Develoment without using EJB' and had introduced the concept of Light-weight container. Primarily, his argument is that while EJB has its merits, it is not always necessary and suitable in all applications.
Just as Hibernate attacks CMP as primitive ORM technology, Spring attacks EJB as unduly complicated and not susceptible to unit-testing. Instead of EJB, Spring suggests that we make use of ordinary Java beans, with some slight modifications, to get all the supposed advantages of EJB environment. Thus, Spring is posed as an alternative to EJB essentially. However, as a concession to the existing EJB investments, Spring is designed to operate with EJB if required.
Much of the philosophy and approach of Spring framework, however, predates , the latest EJB vesrion (ie) EJB-3, about to arrive shortly. It is said that EJB-3 has absorbed a number of new ideas suggested by Spring and some more, to answer the criticisms. There is a debate going on in the Java community about Spring and EJB-3. Spring is not a Persistence technolgy but a framework which allows plug in of other such technologies. But EJB-3 is primarily focussed on Persistence Technology and has now incorporated Hibernate, the best ORM todate.Talks are going on to incorpotrate another equally nice ORM Technology known as JDO, which provides for Object Database also. Moreoveer, EJB-3 's Attribute-Orientaed Meta tags, help in vastly reducing the size of XML lines. Some have complained that Spring is still too dependent on XML files. In this tutorial, any reference to EJB, is only to EJB-2.My aim in presenting this tutorial is not to advocate the choice of either Spring or EJB-3, a topic still being devbated by experts but to share my perception with our readers.
In spring, we can make use of plain Java Beans to achieve things that were previously possible with EJB only. The main aim of Spring is to simplify the J2EE development and testing.
EJB has been around since 1988 and is an established standard and specification in Enterprise world. Though there have been numerous Open-source Java technologies recently, no other technology has claimed to be superior to EJB, in its total features.
Rod Johnson, in his book, critices a number of features in EJB. Significantly, he has also spoken approvingly of some features of EJB and has recommended its use in some special circumstances.
EJB is a standard with wide Enterprise-level Industry support.It has been deployed in thousands of successful applications around the world. The EJB specification is a fixed target and so tool-developers are able to develop wizards, which can make ejb development quick and easy. There are many vendors for EJB application server like IBM (Web-Sphere), BEA (Weblogic), Oracle (JDeveloper) etc.
To quote from another book on Spring ("Spring in Action" - Craig Walls-Manning press) " EJB is complex ", as the author put it nicely, "not for just being complex'. It is complex because it attempts to provide solutions for complex problems". EJB is developed mainly for the remote transaction and distributed objects. But a number of enterprise projects do not have this level of complexity and still use EJBs and even the simple application becomes complex. In such cases Spring claims to be an alternative.
Since Spring comes with rich support to enterprise level services, it claims to be an alternative to EJB It is worthwhile to begin with a comparison of EJB-2 and Spring, in some main features.
The main advantages of EJB are :
a) Transaction Management
b) Declarative Transaction support
c) Persistence ( CMP & BMP)
d) Declarative Security
e) Distributed Computing (Container managed RPC)
Spring does not attempt to do everything by itself but supports the best of breed technologies for each of these requirements.
For example, instead of CMP & BMP, it supports several persistence technologies like JDO, Hibernate and OJB. These ORM toools are far more capable than the implementation in CMP.To simplify JDBC coding, there are tools like iBatis and Spring supports iBatis also.
Spring makes use of Acegi, an open-source Security framework and provides declarative security through spring configuration file or class metadata while in EJB declarative security is configured through deployment descriptor.
Spring provides proxying for RMI (special remoting technologies like Burlap) JAX-RPC & web-service while EJB provides container-managed remote method calls.
Spring can offer declarative transaction like EJB. But spring provides declarative rollback behavior also ,for methods and exceptions
Thus, while EJB is monolithic and attempts to do many things, some tasks fairly well and some others not so well, Spring uses ordinary Java beans only and through special techniques provides many of the functionalities of EJB, by integrating with a number of open-source technologies.
Thereby, it gives the following advantages over EJB2.
a) testing is easier. We do not need to start the EJB container , for testing.
b) As Spring is based on the standard JavaBeans naming convention, programmers find it easy to work with.
c) It makes use of AOP(Aspect-Oriented Programming) which is a very recent and useful paradigm., in addition to classic OOP and preserves the purity of OOP.
d) It is flexible.
Spring's goal is to be an entire Application Framework. Other popular framewoks like Struts, Tapestry, JSF etc., are very good web tier frameworks but when we use these framework, we have to provide additional framework to deal with enterprise tier that integrates well with these framework. Spring tries to alleviate this problem by providing a comprehensive framework, which includes
a core bean container,
an MVC framework,
an AOP integration framework,
a JDBC integration framework and
an EJB integration framework.
It also provides integration modules for O/R mapping tools like Hibernate and JDO. Thus spring framework can be thought of as a layered architecture consisting of seven well defined modules.
The function of each component is as follows:
1. Core Container:
The core container provides the fundamental functionality of Spring. It's primary component is the 'BeanFactory', an implementation of the Factory pattern. The BeanFactory applies the IOC pattern to separate an application's configuration and dependency specification from the actual application code.
2. Spring Context/Application Context:
The Spring context is a configuration file that provides context information to the Spring framework . The Spring context supplies enterprise services such as JNDI access, EJB integration, e-mail, internalization, validation, and scheduling functionality.
3. Spring AOP:(Aspect-Oriented)
The Spring AOP module integrates aspect-oriented programming functionality directly into the Spring framework, through its configuration management feature. As a result we can easily AOP-enable any object managed by the Spring framework. The Spring AOP module provides transaction management services for objects in any Spring-based application. With Spring AOP we can incorporate declarative transaction management into our applications without relying on EJB components.
The Spring AOP module also introduces metadata programming to Spring. Using this we can add annotation to the source code that instructs Spring on where and how to apply aspects.
4. Spring DAO:
The Spring's JDBC and DAO abstraction layer offers a meaningful exception hierarchy for managing the databaase connection, exception handling and error messages thrown by different database vendors. The exception hierarchy simplifies error handling and greatly reduces the amount of code that we need to write, such as opening and closing connections. This module also provide transaction management services for objects in a spring application.
5. Spring ORM:
The Spring framework can be integrated to several ORM frameworks to provide Object Relational tool, including JDO, Hibernate, OJB and iBatis SQL Maps.
6. Spring Web module:
The Web context module builds on top of the application context module, providing contexts for Web-based applications. As a result, the Spring framework supports integration with Jakarta Struts, JSF and webworks. The Web module also eases the tasks of handling multipart requests and binding request parameters to domain objects.
7. Spring MVC Framework:
The MVC framework is a full-featured MVC implementation for building Web applications. The MVC framework is highly configurable via strategy interfaces and accommodates numerous view technologies including JSP, Velocity, Tiles and the generation of PDF and Excel Files.
I would venture to suggest that Spring will win sure acceptance among j2ee devcelopers , very soon because of its ready-made adapters for various hot web-tier and presentation technologies.!
For example, there is a great varierty of technologies in the web-tier like MVC PATTERN, STRUTS, JSF, WEB-WORK, JSP, TAPESTRY,FREEMARKER etc. Developers are now puzzled and confused about the relative merits and demerits of all these. Once they choose a technology and start implementing and later want to change over to another technology, it is very difficult. But, as Spring offers modules for aall the above technologies, it is most often simply changing the configuraion file. With this approach, it is even possible for a development team to try and test a given task in all the above forms and see the effect and performance before deciding the choice. Spring offers its own version of MVC architecture. It also offers adapters for Struts.
In the MVC adapter, it offers the following View choices.
JSP is default view template. 'InternalResouceViewResolver' can be used for this purpose. Spring can be integrated with other template solutions like Velocity, FreeMarker, tiles etc., Also Spring can be used to produce dynamic binary Excel spreadsheet, PDF documents etc.,
To configure the velocity engine 'VelocityConfigurer' bean is declared in spring configuration. The view resolver is configured by 'VelocityViewResolver' bean.
To configure the FreeMarker engine 'FreeMarkerConfigurer' bean is declared in spring configuration. The view resolver is configured by 'FreeMarkerViewResolver' bean.
'TilesConfigurer' can used to used to load Tiles configuration file for rendering Tiles view. 'AbstractExcelView' is used to generate Excel SpreadSheet as views. 'AbstactPdfView' supports the creation of PDF as views. 'buildPdfDocument()' is used to create PDF decument. Similarly we have 'buildExcelDocument()' to create the excel document.
For delegation purpose, Spring provides 'DelegatingRequestProcessor' and to use the tiles 'DelegatingTilesRequestProcessor' is used. 'SpringTapestryEngine' is used for integrating Tapestry to Spring. 'FacesSpringVariableResolver' is used to resolve spring-managed beans in JSF.
Next we shall see the main concepts of Spring, Inversion of Control (IoC) and Aspect Oriented Programming. Spring is based on dependency injection type of IoC . We don't directly connect our components and services together in code but describe which services are needed by which components in a configuration file. A container is responsible for hooking it up. This concept is similar to 'Declarative Management'. IOC is a broad concept. the two main types are
1. Dependency Lookup:
The container provides callbacks to components and a lookup context. The managed objects are responsible for their other lookups. This is the EJB Approach. The Inversion of Control is limited to the Container involved callback methods that the code can use to obtain resources. Here we need to use JNDI to look up other EJBs and resources. Because of this reason EJB is not branded as 'IOC framework'.There are some problems in this implementation. The class needs a application server environment as it is dependent on JNDI and it is hard to test as we need to provide a dummy JNDI contest for testing purpose.
2. Dependency Injection:
In this application objects is not responsible for looking up resources they depend on. Instead IoC container configures the object externalizing resource lookup from application code into the container. That is, dependencies are injected into objects. Thus lookups are completely removed from application objects and it can be used outside the container also.
In this method, the objects can be populated via Setter Injection (Java-Beans properties) or Constructor Injection (constructor arguments). Each method has its own advantage and disadvantage.
Normally in all the java beans, we will use setter and getter method to set and get the value of property as follows
public class namebean
public void setName(String a)
name = a;
public String getName()
We will create an instance of the bean 'namebean' (say bean1) and set property as bean1.setName("tom"); Here in setter injection, we will set the property 'name' by using the
setName("tom"); This process is called setter injection.
For constructor injection, we use constructor with parameters as shown below,
public class namebean
public namebean(String a)
name = a;
We will set the property 'name' while creatinf an instance of the bean 'namebean' as namebean bean1 = new namebean("tom");
Here we use the
To set properties that reference other beans , subelement of
Aspect Oriented programming is a new
programming technique that promotes separation of concerns within the system. System are composed of several components each responsible for a specific piece of functionality. Whatever may be the core function of the program, the system service like logging, transaction management, security etc., must be included in the program. These system services are commonly refered to as 'cross-cutting concerns' as they tend to cut across multiple components in a system. AOP makes it possible to modularize and separate these services and then apply them declaratively to the components and we can focus on our own specific concerns. In spring, aspects are wired into objects in the spring XML file in the same way as JavaBean. This process is known as 'Weaving'.
The container is at the core of Spring Container. In manages the life cycle and configuration of application objects. We can configure how each of our beans should be created either to create a single instance of bean or produce a new instance every time and how they should be associated with each other. Spring should not, however, be confused with traditionally heavyweight EJB containers, which are often large. The Spring actually comes with two distinct containers: Bean Factories-defined by "org.springframework. beans.factory.BeanFactory" are the simplest containers, providing support for dependency injection. Application contexts - defined by "org.springframework.context.Application Context" provides application framework services.
Bean factory is an implementation of the factory design pattern and its function is to create and dispense beans. As the bean factory knows about many objects within an application, it is able to create association between collaborating objects as they are instantiated. This removes the burden of configuration from the bean and the client.
There are several implementation of BeanFactory. The most useful one is "org.springframework.beans.factory.xml.
XmlBeanFactory". It loads its beans based on the definition contained in an XML file. To create an XmlBeanFactory, pass a InputStream to the constructor. The resource will provide the XML to the factory.
BeanFactory factory = new XmlBeanFactory(new FileInputStream("myBean.xml"));
This line tells the bean factory to read the bean definition from the XML file. The bean definition includes the description of beans and their properties. But the bean factory doesn't instantiate the bean yet. To retrieve a bean from a 'BeanFactory', the getBean() method is called. When getBean() method is called, factory will instantiate the bean and begin setting the bean's properties using dependency injection.
myBean bean1 = (myBean)factory.getBean("myBean");
While Bean Factory is used for simple applications, the Application Context is spring's more advanced container. Like 'BeanFactory' it can be used to load bean definitions, wire beans together and dispense beans upon request.
It also provide
1) a means for resolving text messages, including support for internationalization.
2) a generic way to load file resources.
3) events to beans that are registered as listeners.
Because of additional functionality, 'Application Context' is preferred over a BeanFactory. Only when the resource is scarce like mobile devices, 'BeanFactory' is used. The three commonly used implementation of 'Application Context' are
1. ClassPathXmlApplicationContext : It Loads context definition from an XML file located in the classpath, treating context definitions as classpath resources. The application context is loaded from the application's classpath by using the code
ApplicationContext context = new ClassPathXmlApplicationContext("bean.xml");
2. FileSystemXmlApplicationContext : It loads context definition from an XML file in the filesystem. The application context is loaded from the file system by using the code
ApplicationContext context = new FileSystemXmlApplicationContext("bean.xml");
3. XmlWebApplicationContext : It loads context definition from an XML file contained within a web application.
Spring is lightweight in terms of both size and overhead. The entire Spring framework can be distributed in a single JAR file that weighs just over 1.7 MB. And the processing overhead required by Spring is negligible. Also Spring is nonintrusive:(ie) objects in a Spring-enabled application typically have no dependencies on Spring-specific classes.
There are other lightweight containers like HiveMind, Avalon, PicoContainer etc., Avalon was one of the first IoC containers. Avalon mainly provides interface-dependent IoC. so, we much change our code in order to use a different container. This couples your code to a particular framework which is an undesirable feature.
PicoContainer is a minimal (very small size nearly 50k) lightweight container that provides IoC in the form of constructor and setter injection. By using PicoContainer we can only assemble components programmatically through PicoContainer's API. But it allows only one instance of any particular type to be present in the registry. Also PicoContainer is only a container. It does not offer various special features as spring like integration.
HiveMind is relatively new IoC container. Like PicoContainer, it focuses on wiring with support for both constructor and setter injections. It also allows us to define our configuration in an XML file. Like PicoContainer, HiveMind is only a container. It does not offer integration with other technology. Thus Spring makes it possible to configure and compose complex applications from simpler components. In Spring, application objects are composed declaratively, typically in an XML file. Spring also provides much infrastructure functionality like transaction management, persistence framework integration, etc., leaving the development of application logic to us.
With this inroduction, we shall see a simple example in Spring in next article.
* Transaction Management: Spring framework provides a generic abstraction layer for transaction management. This allowing the developer to add the pluggable transaction managers, and making it easy to demarcate transactions without dealing with low-level issues. Spring's transaction support is not tied to J2EE environments and it can be also used in container less environments.
* JDBC Exception Handling: The JDBC abstraction layer of the Spring offers a meaningful exception hierarchy, which simplifies the error handling strategy
* Integration with Hibernate, JDO, and iBATIS: Spring provides best Integration services with Hibernate, JDO and iBATIS.
* AOP Framework: Spring is best AOP framework
* MVC Framework: Spring comes with MVC web application framework, built on core Spring functionality. This framework is highly configurable via strategy interfaces, and accommodates multiple view technologies like JSP, Velocity, Tiles, iText, and POI. But other frameworks can be easily used instead of Spring MVC Framework..
Spring is well-organized architecture consisting of seven modules. Modules in the Spring framework are:
1. Spring AOP
One of the key components of Spring is the AOP framework. AOP is used in Spring:
To provide declarative enterprise services, especially as a replacement for EJB declarative services. The most important such service is declarative transaction management, which builds on Spring's transaction abstraction.
To allow users to implement custom aspects, complementing their use of OOP with AOP
2. Spring ORM
The ORM package is related to the database access. It provides integration layers for popular object-relational mapping APIs, including JDO, Hibernate and iBatis.
3. Spring Web
The Spring Web module is part of Spring’s web application development stack, which includes Spring MVC.
4. Spring DAO
The DAO (Data Access Object) support in Spring is primarily for standardizing the data access work using the technologies like JDBC, Hibernate or JDO.
5. Spring Context
This package builds on the beans package to add support for message sources and for the Observer design pattern, and the ability for application objects to obtain resources using a consistent API.
6. Spring Web MVC
This is the Module which provides the MVC implementations for the web applications.
7. Spring Core
The Core package is the most import component of the Spring Framework.
This component provides the Dependency Injection features. The BeanFactory provides a factory pattern which separates the dependencies like initialization, creation and access of the objects from your actual program logic.
The Spring 3 new features:
In this section we will understand the features of Spring 3.0 Framework. The Spring 3.0 Framework is released with the support of Java 5. So, you can use all the latest features of Java
5 with Spring 3 framework.
The first version of Spring Framework was released in the year 2002. And it was developed and released to simplify the development of Enterprise Java applications. Since then it have undergone the major releases Spring 2.0, Spring 2.5 and now Spring 3.0. The Spring Framework is used by many frameworks. You can use the existing frameworks such as JSF, Struts 2, Flex with Spring DS to quickly develop and deploy large scale enterprise applications. The Spring framework simplifies the development of complex enterprise applications.
The Spring Framework simplifies the development, testing, deployment of the application much easier.
Spring 3 what's new
Let's see what all new features are available in the Spring 3 framework.
Features of Spring 3.0 Framework:
• Java 5 Support: The core API of Spring 3.0 framework is using JDK 5, so JDK 5 or above is required to run Spring 3.0 based applications. The Spring 3.0 framework provides annotation-based configuration support. JDK 5 features such as generics, annotations and varargs can used in Spring 3.0 Framework based applications. The Spring 3.0 framework is based on JDK 1.5 and it fully supports JDK 6. The Spring 3.0 is fully compatible with the JEE1.4 and EE5.
• Expression language - Spring Expression Language (SpEL): In this release of Spring framework Expression language support is present. The Spring Expression Language can be used while defining the XML and Annotation based bean definition.
• Support for Comprehensive REST Webservices: Spring 3.0 framework supports REST web services.
• Java EE 6 Support: Spring 3.0 supports many features of JEE 6 such as JAP 2.0 and JSF 2.0.
• Annotation based formatting support: Spring comes with Annotation based formatting support. For example bean fields can be automatically formatted and converted using different annotations. For example you can use the @DateFimeFormat(iso=ISO.DATE) and @NumberFormat(style=Style.CURRENCY) annotations to convert the date and currency formats.
• New module organization and build system:
The modules in the Spring 3.0 framework have been revised and it managed separately with one source-tree per module jar:
Java technology has become a complete software ecosystem that represents different values to different types of consumer and business users. It offers developers a choice of three Java platform editions depending on the need:
* Java technology in small and mobile devices
* Java technology in PC desktops
* Java technology in medium to large businesses
Sun Open Sources Java Platform Implementations
Sun open-sourced its implementation of the Java platform as free software. Get involved! Visit the three open-source Java communities that Sun is seeding and download the code: OpenJDK, Mobile & Embedded and the GlassFish community.
What can Java software do? Take a look at how Java technology is changing the world!
* More about core Java technology
* More about security and the Java Platform
* About Java Web Services
For consumers, Java technology is the first software technology that simply works without a struggle. Consumers are delighted to see applications run reliably and compatibly on such an incredible array of network products - from PCs, game players, and mobile phones to home appliances and automotive electronics. The Java brand has come to represent applications that are lively and interactive. A growing voice among consumers all over the globe actively prefers Java Powered applications and products.
* Java + You
For business, Java technology represents choice, performance, efficiency, and flexibility. The Enterprise Java platform serves as an end-to-end infrastructure that gives IT managers an extremely wide variety of compatible business logic applications, independent of their application server or portal server vendor - whether it is BEA, IBM, Oracle, or Sun. It significantly extends their reach and interactivity among employees, customers, and partners. Just as important, IT managers know there is a global ecosystem of Java developers, support engineers, and knowledge bases to reduce the risk and time to deployment as well as the ongoing cost of ownership and maintenance.
For developers, Java technology allows them to write software on one platform and run it on practically any other platform. It lets them create multi-threaded programs that run within Web browsers and Web services. Also, they can combine reusable Java objects to quickly create unique and highly customized server-side applications, such as online forums, stores, polls, HTML forms processing, and secure transactions. And of course, there's a support community of four milion fellow developers, thousands of independent developer web sites, hundreds of providers that support Java developers, and the Java Community Process (JCP.org).
Java technology is an object-oriented, platform-independent, multithreaded programming environment. It is the foundation for Web and networked services, applications, platform-independent desktops, robotics, and other embedded devices.
Three main technology values of Java include:
* A Richer User Experience - Whether you're using a Java technology-powered mobile phone to play a game or to access your company's network, the Java platform provides the foundation for true mobility. The unique blend of mobility and security in Java technology makes it the ideal development and deployment vehicle for mobile and wireless solutions.
* The Ideal Execution Environment for Web Services - The Java and XML languages are the two most extensible and widely accepted computing languages, providing maximum reach to everyone, everywhere, every time, to every device and platform.
* Enabling Business from End to End - Java technology offers a single, unifying programming model that can connect all elements of a business infrastructure.
* Java Technologies
* Java & Related Technologies
Java Technology in Small and Mobile Devices
The Micro Edition of the Java Platform meets the needs of developers creating applications for the consumer and embedded markets. No other technology provides such robust applications across so many types of size-constrained wireless and wireline devices, from mobile phones and PDAs to set-top boxes and vehicle telematics.
For more information
» Java Mobility
» Java ME
» Java Card Technology
Java Technology in PC Desktops
The Standard Edition of the Java Platform is designed specifically to develop secure, portable, high-performance applications for the widest range of desktop computing platforms possible, including Apple Macintosh, Linux, Microsoft Windows and Sun Solaris. Compatible desktops, especially in heterogeneous environmemts, represent a boost in user productivity, communication, and collaboration, as well as a considerable cost-of-ownership savings.
For more information
» Desktop Java Technology
» Java SE
Java Technology in Medium to Large Busineses
The Enterprise Edition of the Java Platform is especially valuable to growing businesses with broad deployment needs, for example, server and desktop applications as well as mobile wireless and wireline applications. There have been over five million downloads of Java technology for the Enterprise for advantages that apply across virtually all industries and application types, from business process management and enterprise resource planning to supply chain management, sales and service force automation, and office productivity.
The following features are common to all conforming ECMAScript implementations, unless explicitly specified otherwise.
Imperative and structured
Functions are first-class; they are objects themselves. As such, they have properties and can be passed around and interacted with like any other object.
inner functions and closures
functions as object constructors
functions as methods
Unlike many object-oriented languages, there is no distinction between a function definition and a method definition. Rather, the distinction occurs during function calling; a function can be called as a method. When a function is called as a method of an object, the function's local this keyword is bound to that object for that invocation.
Before we start any discussion about Persistence technologies, we need to understand what exactly Persistence is in computer science. Persistence, in simple terms is the ability to retain data structures between various program executions. A perfect example of this would be a word processor saving undo history. In practice, this is achieved by storing the data in non- volatile storage such as a file system or a relational database or an object database.
The popularity of databases has increased manifold in the past few years. Java has become the preferred choice of developers for developing secure, flexible, and scalable database driven web applications. These web applications require objects to be associated with appropriate databases. Hibernate, along with other persistence technologies associate’s objects with the appropriate database in a simple, straight forward and natural way.
Hibernate is one such effort from the Java community to develop many object oriented solutions to data persistence. Any kind of Java persistence solution includes two main elements i.e. ORM (Object Relational Mapping) and OOM (Object Oriented Modeling).
Hibernate has become immensely popular amongst the developer community as it is a free, powerful, high performance open source object - relational mapping persistence Java package that makes it easier to work with relational databases for Java Applications.
Apart from Hibernate, other popular open source Java persistence technologies include JDBC, abates, JDO, Top Link and CMP Entity Beans. These technologies provide a standardized object-relational mapping mechanism.
Java persistence application programming Interface or JAVA Persistence API is the latest version of the Java Data Objects (JDO) technology which was the earlier persistent technology used by developers. JPA or the Java Persistence API is the latest Java Specification standard for java enterprise applications. The Java Persistence API is a java programming language framework that allows developers to manage relational data in Java standard edition and Enterprise Edition applications. Java Persistence API originated as part of the work of the JSR 220 expert group.
The java persistence API’s has been developed after drawing upon the best ideas from other prevalent persistence technologies like Top link, JDO, Hibernate etc. In simple words, Java Persistence API is a Plain Old Java Object API for object /relational mapping and supports a rich, SQL –like query language for both static and dynamic queries.
Vendors involved in application development have found that the use of Hibernate technology with Java persistence API’s helps build flexible, database driven web applications that are highly scalable and involve complex business processes.
The Java Persistence API is the standard object/relational mapping and persistence management interface of the Java EE 5.0 platform and Java Web Services Development . As part of the EJB 3.0 specification effort, it is supported by all major vendors of the Java industry for improving Java Web Development in India and Globe.
Overview of Wireless Communications
Wireless communications is a huge field, encompassing everything from radio and television broadcasting through pagers, mobile phones, and satellite communications. The field of mobile phones is expanding very fast at the same time that standards and protocols are being adopted, used, updated, and sometimes discarded. The other rapidly expanding part of the wireless world is that of wireless local area networks (LANs). Driven by widespread acceptance of the IEEE 802.11 standard, wireless local networking for computers and other devices is spreading rapidly.
Although wireless may seem like a special case, it is actually more intuitive and more natural than wired networking. Some day soon the need to plug a laptop into a network physically will seem quaint and antiquated. The notion that you could walk into a room with your cell phone and have it unable to interact with other devices in the room will seem unbelievably primitive. The future will reveal that wired networks are the special case.
Conceptually, wireless communications can be split into two types, local and wide area. A local device is similar to a key fob with a button that unlocks a car, a 900 MHz cordless phone, a radio control toy, or a Bluetooth network. All of these devices operate over short distances, typically just a few meters.
Wide area wireless devices operate effectively over a much greater area. A pager or mobile phone is a good example; you can talk on your mobile phone to any other phone on the planet. These devices' greater range relies on a trick, however: a more elaborate land-based network. A mobile phone doesn't have that much more radio power than a radio control toy. What it does have is a network of carefully placed radio antennas (cell towers); the phone can continue to operate as long as it is within range of at least one tower. The mobile phone device receives service from a wireless carrier, a company that operates the land-based network.
While a number of industry consortia and standard bodies, such as the, are trying to define or foster the development of standards for the wireless world, today's wireless world is still fragmented and complex. If you buy a mobile phone in the U.S. today, it might run on Motorola's iDEN network or Sprint's PCS network. Take it overseas to Europe and you'll be out of luck--your phone will not work with Europe's GSM network, nor will it work with the PDC network or any of the other mobile networks that live in Japan.