Group items tagged

"There are pros and cons for considering validation as business logic, and Spring offers a design for validation (and data binding) that does not exclude either one of them. Specifically validation should not be tied to the web tier, should be easy to localize and it should be possible to plug in any validator available. Considering the above, Spring has come up with a Validator interface that is both basic ands eminently usable in every layer of an application. Data binding is useful for allowing user input to be dynamically bound to the domain model of an application (or whatever objects you use to process user input). Spring provides the so-called DataBinder to do exactly that. The Validator and the DataBinder make up the validation package, which is primarily used in but not limited to the MVC framework. The BeanWrapper is a fundamental concept in the Spring Framework and is used in a lot of places. However, you probably will not have the need to use the BeanWrapper directly. Because this is reference documentation however, we felt that some explanation might be in order. We will explain the BeanWrapper in this chapter since, if you were going to use it at all, you would most likely do so when trying to bind data to objects. Spring's DataBinder and the lower-level BeanWrapper both use PropertyEditors to parse and format property values. The PropertyEditor concept is part of the JavaBeans specification, and is also explained in this chapter. Spring 3 introduces a "core.convert" package that provides a general type conversion facility, as well as a higher-level "format" package for formatting UI field values. These new packages may be used as simpler alternatives to PropertyEditors, and will also be discussed in this chapter."

Aspect-oriented computing is continuing to increase in popularity. The modularity inherent in OSGi and Eclipse offers unique opportunities for managing and applying aspects by supplying them in bundles and directing their application to particular sets of bundles. This incubator work area is dedicated to delivering an integration of aspects and OSGi. The goal is to allow developers to use the Equinox together with AspectJ by combining the benefits of both worlds. Using a load-time weaving extension you are able to add AspectJ aspects to your bundle-based system just by putting them into general OSGi bundles. It does not matter if the pointcuts you defined inside the aspects contain join points that are defined by classes within the same bundle or any other bundle in your installation. The load-time weaving extension will take care that your aspects are woven with the appropriate classes at load-time. To illustrate this lets assume the following situation: You would like to write an aspect that traces something within the JDT plug-ins of Eclipse. Without some kind of load-time aspect weaving you would somehow need to recompile those JDT plug-ins using AJDT (for example) together with your aspect. By using the load-time aspect weaving extension all you need is to implement your aspect and add that bundle to your system. The load-time aspect weaving extension takes care of weaving your aspect with the JDT code as it is loaded. And it doesn't matter if a new JDT is installed by the user later on. The next time your application is started the load-time aspect weaving will take care of weaving your aspect into these bundles as well, if necessary. With this technology is becomes possible to modularize crosscutting concerns across different plug-ins while keeping the idea of separate compilation for bundles. Goals Provide Runtime Modularity and Versioning for Crosscutting Concerns: Aspects are used to implement crosscutting concerns. However such concerns usually compr

Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI. CXF includes a broad feature set, but it is primarily focused on the following areas: Web Services Standards Support: CXF supports a variety of web service standards including SOAP, the WS-I Basic Profile, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging, WS-Security, WS-SecurityPolicy, WS-SecureConverstation, and WS-Trust (partial). Frontends: CXF supports a variety of "frontend" programming models. CXF implements the JAX-WS APIs (TCK compliant). CXF JAX-WS support includes some extensions to the standard that make it significantly easier to use, compared to the reference implementation: It will automatically generate code for request and response bean classes, and does not require a WSDL for simple cases. It also includes a "simple frontend" which allows creation of clients and endpoints without annotations. CXF supports both contract first development with WSDL and code first development starting from Java. For REST, CXF also supports a JAX-RS (TCK compliant) frontend. Ease of use: CXF is designed to be intuitive and easy to use. There are simple APIs to quickly build code-first services, Maven plug-ins to make tooling integration easy, JAX-WS API support, Spring 2.x XML support to make configuration a snap, and much more. Binary and Legacy Protocol Support: CXF has been designed to provide a pluggable architecture that supports not only XML but also non-XML type bindings, such as JSON and CORBA, in combination with any type of transport. To get started using CXF, check out the downloads, the user's guide, or the mailing lists to get more information!

"AtomServer is a generic data store implemented as a RESTful web service. It is designed as a GData-style Atom Store. It is based on the following concepts and protocols; REST. REST is a design pattern. It's not a technology like SOAP or HTTP. REST is a proven design pattern for building loosely-coupled, highly-scalable applications. There are important benefits to sticking to the REST design pattern; Simple. REST is incredibly simple to define. There are just a handful of principles and well defined semantics associated with it. Scalable. REST leads to a very scalable solution by promoting a stateless protocol and allowing state to be distributed across the web. Layered. REST allows any number of intermediaries, such as proxies, gateways, and firewalls. Ultimately REST is just a web site, albeit one that adheres to a design pattern, so one can easily layer aspects such as Security, Compression, etc. on an as needed basis. Atom. Fundamentally, Atom is an XML vocabulary for describing lists of timestamped entries. These entries can be anything, although because Atom was originally conceived to replace RSS, Atom lists are Feeds, and the items in the lists are Entries. Atom is a RESTful protocol. AtomServer stands on the shoulders of giants. It is built on top of several open source projects - most notably, Apache Abdera (a Java-based Atom Publishing framework) and Spring. AtomServer is an Atom Store. Thus, it requires a relational database to run. AtomServer currently supports; PostgresSQL, SQLServer, and HSQLDB. Using HSQLDB, AtomServer requires zero configuration and can run out-of-the-box. While this configuration is suitable for many applications, those that see significant load will likely require a database with better transactional semantics, such as PostgreSQL. AtomServer is easy to use. It deploys as a simple WAR file into any Servlet container. Or alternately, can be used out-of-the-box as a standalone server, running with

migrate4j is a database migration tool. Suppose you determine that you need a new database table for your project. If you develop alone, you could write an SQL script that adds a table and manually apply this to your development system. But if you work with other developers, or need to keep a test system in synch with your development system, this become tedious and error prone. Migration tools make it possible to add your new table (or make any other schema changes) in an automated fashion, ensuring all your systems are always in synch. Migration tools also make it possible to quickly and easily roll back previous changes. Unlike typing commands into an interactive SQL window or storing SQL scripts, migration tools keep a detailed history of how your database schema evolved (just in case you need to go back to a previous version). Finally, migration tools minimize or eliminate the problem of having to use vendor specific syntax - you may never switch database products, but if you do, using a migration tool will make your life much easier. The initial intent of migrate4j was to make a Java version of Ruby's db:migrate. If you've used db:migrate, you probably fell in love with it's simple syntax, easy configuration and ability to roll changes up and back effortlessly. The intent (and the challenge) of migrate4j is to bring the power and simplicity of db:migrate to Java programmers, using familiar type safety and syntax. Along the way, we're adding additional functionality that makes migrate4j more than just another Ruby tool rewritten for Java - it is a Java project intended to make other Java projects even better.

Java Sound API is one of the media API which is used for sound operations like storing, manipulating, editing sounds. Lets see in this tutorial how to use Java Sound API.

AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely used de-facto standard for AOP by emphasizing simplicity and usability for end users. It uses Java-like syntax and has included IDE integrations for displaying crosscutting structure since its initial public release in 2001. In this article we will describe how we can use AspectJ to do the logging job for all methods parameters and methods return values in a Java application

This is an excellent link I find related to Unix find command and how to use find command in unix , I have bookmarked it and using it frequently , It has really improved my productivity over couple of days , I am loving it:)my favorite unix find command example from this blog post is :6) How to find all text file which contains word Exception|,ERROR,Error} using find command in Linux ?

Quick guide on where to use Assertion in Java with code example. Assertion in java is fairly underused feature but if used carefully can complement both Unit Testing and Exception handling. Since Assertion sits on code its gets more expose than unit testing and can test your function with more real data than one or two test data.

Java supports two selection statements - if and switch. These statements allow us to control the flow of the program. Depending upon the expressions or values, the corresponding blocks/statements of code will be executed or by passed. The two statements are if statement is a conditional branch statement. This is a two way branch statement. Depending upon the whether a condition is true or false, the corresponding code is executed. switch statement is a multiway branch statement. Depending upon the value used for switching, the corresponding code is executed. These two statements are very powerful and are used widely across any application. They provide effective solutions for branching problems.

"Stop using Tomcat and wondering why JEE "doesn't work." You're doing yourself a big disservice. Start thinking about JBoss AS 6, or GlassFish v3 - Yes, I know, it's a "Full JEE Container," - it's "Heavy," but with JEE6, that's not a bad thing: It all "Just works" and it works really well. Trust me, the reason people have thought Java EE sucks, is because they try to do this stuff on Tomcat, and say "Why doesn't (JPA, JMS, JTA, EJB, JSF, CDI) work?" Well… that's because Tomcat only gives you Servlet - the Request/Response lifecycle. So people install all these things manually, or try to, and then say, "Wow, Java EE is really hard to use, shit, I'm gonna use Spring or Grails instead.""

Special thanks to Piero Sartini who came up with this alternative. It is basically the same as the previous alternative, but it uses the new JEE6 Context and Dependency Injection (CDI) and session scoped beans instead of EJBs. This alternative should have better performance than using EJBs. Instead of annotating the Vaadin application as a stateful session bean, it should be annotated using the @SessionScoped annotation, like so:

Spring Security is a powerful and highly customizable authentication and access-control framework. It is the de-facto standard for securing Spring-based applications Spring Security is one of the most mature and widely used Spring projects. Founded in 2003 and actively maintained by SpringSource since, today it is used to secure numerous demanding environments including government agencies, military applications and central banks. It is released under an Apache 2.0 license so you can confidently use it in your projects. Spring Security is also easy to learn, deploy and manage. Our dedicated security namespace provides directives for most common operations, allowing complete application security in just a few lines of XML. We also offer complete tooling integration in SpringSource Tool Suite, plus our Spring Roo rapid application development framework. The Spring Community Forum and SpringSource offer a variety of free and paid support services. Spring Security is also integrated with many other Spring technologies, including Spring Web Flow, Spring Web Services, SpringSource Enterprise, SpringSource Application Management Suite and SpringSource tc Server.

This project will mainly contain utility stuff for diverse purpose. Initially it will primarily comprise of Spring Utilities which will perform the following purposes: Load a single resource properties file from pre-configured locations with priority based override. Application context registrar to make the context available to other interested components. Use Cacheable Jersey Client Use a generic RESTful WS Client OpenSearchDescriptor JAX-RS Provider based on XOM based DOM I/O Useful utilities for Atom Syndication Feed, such as pagination over entities, retrieval of resource to certain depth, etc.

Sapphire - develop UI without wiring individual widgets Little has changed in the way Java desktop UI is written since the original Java release. Technologies have changed (AWT, Swing, SWT, etc.), but fundamentals remain the same. The developer must choose which widgets to use, how to lay those widgets out, how to store the data being edited and how to synchronize the model with the UI. Even the best developers fall into traps of having UI components talk directly to other UI components rather than through the model. Inordinate amount of time is spent debugging layout and data-binding issues. Sapphire aims to raise UI writing to a higher level of abstraction. The core premise is that the basic building block of UI should not be a widget (text box, label, button, etc.), but rather a property editor. Unlike a widget, a property editor analyzes metadata associated with a given property, renders the appropriate widgets to edit that property and wires up data binding. Data is synchronized, validation is passed from the model to the UI, content assistance is made available, etc. This fundamentally changes the way developers interact with a UI framework. Instead of writing UI by telling the system how to do something, the developer tells the system what they intend to accomplish. When using Sapphire, the developer says "I want to edit LastName property of the person object". When using widget toolkits like SWT, the developer says "create label, create text box, lay them out like so, configure their settings, setup data binding and so on". By the time the developer is done, it is hard to see the original goal in the code that's produced. This results in UI that is inconsistent, brittle and difficult to maintain.

"This page describes how you can get an extended WADL from your REST app. It aligns mostly with the extended-wadl-webapp sample and uses these features: Add additional doc tags to the WADL Create JAXB beans from xsd - you might also create the schema from your beans Add the grammars element that includes the xsd file from which JAXB beans were generated to the WADL Add javadoc from your resource classes to the WADL, using most of the supported javadoc tags For getting the extended WADL as described above these things have to be done: Configure the maven-jaxb-plugin to create JAXB beans from xsd - this is described here just to describe what's done in the sample. Add the application-doc.xml and application-grammars.xml to the build classpath Configure the maven-javadoc-plugin with the ResourceDoclet provided by the wadl-resourcedoc-doclet artifact to create the resource-doc.xml. Create a subclass of WadlGeneratorConfig that defines/configures the WadlGenerators to use Specify your custom WadlGeneratorConfig in the web.xml as the WadlGeneratorConfig"

The goal of the Eclipse Scout project is making it easy to build distributed enterprise applications based on the Eclipse platform. It consists of a runtime framework providing transparent service communication between the client and backend part and is shipped with a rich set of common user interface components. The user interface is not built for a particular rendering technology but it encapsulates the core functionality into a headless model. GUI factories are available for rendering the client model into a particular target UI platform. SWT and Swing are supported out of the box and an AJAX GUI factory could be easily added. Developing Scout applications is supported by the Scout SDK, a plug-in set built on top of Eclipse PDE and Eclipse JDT. The Scout SDK works directly on the bare Java resources and assists the development task by providing an augmented view on the underlying Java code. Additionally, it comes with a rich set of wizards and operations for modifying the Scout application project just by editing the underlying Java code. There is no meta-data required. Hence a developer can switch between editing resources using Eclipse's standard editors and leveraging the features of Scout SDK at any point in time. Eclipse Scout can be used to create multi-tier client/server applications, standalone client applications or OSGi-based server applications. Basically, there are three main advantages when choosing Scout as your framework for building such applications. First, the Scout runtime is service oriented by design. Almost every functionality is provided as an OSGi service. Every OSGi bundle may make use of them. Second, Scout provides a rich set of UI elements being uncoupled from a particular GUI technology. And third, building distributed client/server applications is as easy as if both parts would run within the same local JVM.

If you're just starting to build a JSF 2 application, or you've already started building one and you'd like to add ICEfaces, it's simple to do: Add and tags JSF 2 includes head and body components that can be added to the page by using the and tags. ICEfaces 2 makes use of these components to automatically add certain scripts and other elements to the page, so the and tags are required on any pages of your application that use ICEfaces 2.

Ajax Push allows the application to incrementally update any part of the page at any time, for any group of clients. This is a small change in terms of the technical capabilities of Ajax applications, but it is a revolutionary change in terms of what applications can actually provide to users. Ajax Push is the key to building collaborative multi-user applications for the web. Under the Hood The intricacies of the Ajax Push implementation are completely transparent to the ICEfaces developer, as you work with a straightforward set of APIs. It is, however, useful to understand the basic mechanics. Ajax Push in ICEfaces 2.0 leverages an asynchronous notification mechanism call ICEpush. Simply put, ICEpush uses long polling to provide asynchronous notification over standard HTTP, using only standard browser capabilities. The sequence of events involved in Ajax Push is illustrated below.