I have already approached this subject twice in the past. First, on my post Integrating Bean Validation with JAX-RS in Java EE 6, describing how to use Bean Validation with JAX-RS in JBoss AS 7, even before this was defined in the Java EE Platform Specification. And later, on an article written for JAX Magazine and posteriorly posted on JAXenter, using the new standard way defined in Java EE 7 with Glassfish 4 server (the first Java EE 7 certified server).
Now that WildFly 8, previously know as JBoss Application Server, has finally reached the final version and has joined the Java EE 7 certified servers club, it’s time for a new post highlighting the specificities and differences between these two application servers, GlassFish 4 and WildFly 8.
JavaBeans Validation (Bean Validation) is a new validation model available as part of Java EE 6 platform. The Bean Validation model is supported by constraints in the form of annotations placed on a field, method, or class of a JavaBeans component, such as a managed bean.
Several built-in constraints are available in the javax.validation.constraints package. The Java EE 6 Tutorial lists all the built-in constraints.
Constraints in Bean Validation are expressed via Java annotations:
public class Person {
@NotNull
@Size(min = 2, max = 50)
private String name;
// ...
}
Bean Validation and RESTful web services
JAX-RS 1.0 provides great support for extracting request values and binding them into Java fields, properties and parameters using annotations such as @HeaderParam, @QueryParam, etc. It also supports binding of request entity bodies into Java objects via non-annotated parameters (i.e., parameters that are not annotated with any of the JAX-RS annotations). Currently, any additional validation on these values in a resource class must be performed programmatically.
The next release, JAX-RS 2.0, includes a proposal to enable validation annotations to be combined with JAX-RS annotations. For example, given the validation annotation @Pattern, the following example shows how form parameters could be validated.
Internationalization, or i18n, is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language. Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a “locale”).
Adapting application to various languages is for me, as a Java and HTML developer, more than a common task. Usually the solution involves a set of supported locales, which is very often different from the system locale and/or browser configuration. Majority of such cases are covered by the scenario when user chooses particular language settings and the only place where the locale setting can be stored is the HTTP Session.
Support for this behavior is now handled by majority of frameworks; nevertheless there is still one HTML element that you can’t effectively change - the file upload form field.
If the J2SE platform has come a long way in internationalization, entering non-ASCII text in the J2EE world isn’t nearly as easy.
To achieve the same result you have to make some changes in your code and in your web server settings.
Firstly, to make sure that the right value in the Content-Type header precedes the text/html content so your browser correctly auto-detects the right encoding, place the following declaration at the beginning of the JSP:…
In this article, Bilal Haidar presents the new localization feature provided by .NET framework 2.0. Throughout the article, the new tools provided by Visual Studio 2005 to support localization will be highlighted and used to show you how easy it is to localize your web applications with ASP.NET 2.0.…
In this article, Muhammad Mosa will explore the necessary details for working with resources in ASP.NET applications and for creating international ASP.NET applications based on embedded resources and the integrated localization support.…