GlassFish v3 is an open source application server and is the first compatible implementation of the Java EE 6 platform specification. To test the examples in this article I will assume that you use GlassFish (or any other JEE6 enabled application server) to run the examples.

Maven2 dependencies

Lets start with the Maven dependencies, you can add them all to the pom.xml of your war. I have also included Sun’s Maven2 repository for downloading the JEE6 dependencies like the javaee-api and Sun’s JAX-RS 1.1 implementation called Jersey.

Both dependencies are scoped as provided because GlassFish already ships with these libraries. In fact, my war file is not bigger than 22kb. JEE6 allowes developers to package full blown JEE application as a web archive file, there is no need for an enterprise archive anymore. This makes JEE6 applications really light weight.

JAX-RS RESTfull services in JEE6

JAX-RS supports configuration through annotations, just like the Spring 3.0 REST annotations. Annotations can be added to both classes and methods. Classes in JAX-RS can be POJO`s. One thing about JAX-RS is that it does not integrate well with other JEE specification, for example the JSR-330 annotations for dependency injection are not supported by JAX-RS (yet), but there is a workaround

Because of the flexibility of JAX-RS it is possible to annotate EJB SessionBean or CDI components with JAX-RS annotations. So when a bean with JAX-RS annotation is packaged in a war file, the annotations are automatically picked up by the JAX-RS implementation (Jersey in this case). Since EJB3.1 SessionBeans and CDI components support all of the dependency injection features offered by JEE6, JAX-RS now does too!

Below is an example JAX-RS annotated class. The goal of this RESTfull service is to expose two methods of the ProductService through a RESTfull interface. The ProductService is injected using the @Inject annotation.

In JAX-RS the @Path annotation is used to map an URI to a REST service. In the example below I’ve defined the @Path annotation on the class, this will map all the URIs starting with /product to this class. I also defined the @ManagedBean (CDI) annotation on the class for the @Inject to work properly.

There are two methods within the service which are annotated with @Path, @GET and @Produces. The @Path is the same as with the class, but in this case it maps URI’s to a method. The URI of a method is relative to URI specified in the @Path annotation
on the class. So the following URLs are mapped in this example:

JAX-WS allowes for mapping HTTP methods like GET, PUT, POST and DELETE to Java methods with the @GET, @PUT, @POST and @DELETE annotations. In this example only the GET method is used. In RESTfull service the HTTP GET is used to retrieve data. To map a GET request to a method you can simply annotate a method with @GET.

The @Produces annotation specifies the Mime-Type of the response data the methods produces. In this example the methods both produce XML data, therefore we need to set the Mime-Type to application/xml. When returning an Object from a method annotated with @Produces, JAX-RS trieds to find an appropriate converter to produces the output. In this case I will use JAXB will to marshall the Objects to XML (see below).

JAXB marshalling

In order for JAXB to marshall the Objects returned, we need to specify JAXB annotations on the Objects returned from the methods.
In this example I’ve added @XmlRootElement to the returned Objects to simply marshall the entire Object to XML.

Adding Jersey to the web deployment descriptor: web.xml

For JAX-RS to work we still need to add a Servlet to the web.xml which maps URL’s to the services. In this case we need to add the JerseyServlet to the web.xml. In the servlet-mapping all /rest/ URL patterns are mapped to Jersey. We can access the REST services using the following URIs: /rest/product/etc.

Conclusion

When building RESTfull services on an JEE6 enabled application server, JAX-RS really makes things easy. You will have to decide for your specific case if you want to use Spring or JAX-RS.

Orginal article posted here.

The Spring MVC controller

The Spring 3.0 REST support relies havily on Spring MVC. We should use the Controller class for implementing a REST style WeService. To declare a Controller I use the Spring annotation based configuration. In this example the ProductRestService class is annotated with @Controller annotation. In order for Spring to pick-up the annotation Spring needs to be configured to scan for annotation (see the Spring configuration section).

REST uses templates that describe the URI to be used to invoke a WebService method. These URI templates can contain variable placeholders which allow for passing information to the WebService. The URI should typically contain all the information required for invoking a WebService method.

The @RequestMapping annotation allowes you to define the URI and HTTP method that are mapped to a method. In this example I have annotated the ProductRestService.getProductById(Long productId) with the @RequestMapping.
The value of the @RequestMapping, in this case: /products/{productId} , defines the URI that is mapped to this method. The productId variable needs to be defined when invoking the method and will be resolved automatically by Spring MVC with the value from the request URI. You can use the @PathVariable to inject the value of the productId variable directly into a method parameter.

The @ResponseBody annotation tells Spring to marshall the return value of the method to the HTTP response body. Spring allowes you to configure HTTP message converters that take care of conversion of the return value to a format which is accepted by the client. In this example the return value will be marshalled to XML using XStream.

package com.oudmaijer.spring.rest;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.ResponseBody;

/**
 *  This is an example REST style MVC controller. It serves as an
 *  endpoint for retrieving Product Objects.
 */
@Controller
public class ProductRestService {

    /**
     * This method returns a specific Product. The URI to request a Product is
     * specified in the @RequestMapping.
     *
     * @param productId the identifier of the requested product
     * @return a Product
     */
    @RequestMapping(value="/products/{productId}", method = RequestMethod.GET)
    @ResponseBody
    public Product getProductById(@PathVariable Long productId) {
        Product p = new Product();
        p.setId(productId);
        return p;
    }

}

Spring configuration

The configuration is where all the magic happens. It is important to define the <mvc:annotation-driven /> element at the end of the configuration file or else Spring will not register the marshallingHttpMessageConverter. It took me some time to figure this out ;(

You need to add the MessageConverters to the configuration in order to get the OXM marshalling to work. Spring uses the requests Accept header to determine which converter to use.

Maven2 dependencies

You need to add a couple of Maven2 dependencies to get the project up and running. Below is the entire pom.xml.

Web deployment descriptor: web.xml

Last but not least the web.xml. Since the REST support in Spring is based on Spring MVC you need to define the DispatcherServlet. Make sure to map the correct URL pattern to the DispatcherServlet.

Invoking the service

This example only supports the HTTP GET method. If you want to test or build a client that uses REST WebServices you should use the RestTemplate in Spring. We can easily validate if the example WebService is running by accessing the service through Firefox. This will result in the following response.

For more information on REST support in Spring 3.0 please refer to the Spring reference documentation.

Both Spring Security 3.0 and Spring 3.0 where released this month. Spring Security provides excelent support for CAS. In Spring Security 3.0 a couple of CAS integration components have been changed (renamed). The configuration is also a bit different from Spring Security 2.0.x.

How CAS works
The CAS Server webapp should be deployed on an application server. Applications can use the CAS Server for the authentication process. CAS only provides authentication and no authorisation. The authorisation should be implemented (using Spring Security) by the applications using the CAS Server.

How Spring Security fits in
Lets say an user tries to access a protected resource within an application using Spring Security. Spring Security intercepts the request and checks if the user should be authenticated. If so, the user is forwarded tot the CAS login page. The users typically enters his username and password and submits it to the CAS server. If the user was successfully authenticated by CAS, the users will be redirected back to the application where it was accessing a protected resource. The redirect URL now contains a ticket generated by CAS. Spring Security will use this ticket to validate against CAS if the ticket is valid for this user. If so, the user details will be loaded by Spring Security. If the user is also authorised to access the protected resource, access will be granted.

Configuration
For my demo I use the CAS server webapp version 3.3.4. I have it deployed on Apache Tomcat 6.0.20. In the demo I access the CAS Server using HTTP, this should be HTTPS in a production environment! I have deployed the applications using the following URLs:

I use Maven2 for managing my dependencies, the following libraries should be added to the pom.xml.

Maven2 dependencies

	
		org.springframework
		spring-core
		3.0.0.RELEASE
		false
	
	
		org.springframework
		spring-webmvc
		3.0.0.RELEASE
		false
	
	
		org.springframework.security
		spring-security-core
		3.0.0.RELEASE
		false
	
	
		org.springframework.security
		spring-security-config
		3.0.0.RELEASE
		false
	
	
		org.springframework.security
		spring-security-cas-client
		3.0.0.RELEASE
		false
	

Spring Security configuration
Please be aware that the Spring Security reference documentation is not 100% accurate on the CAS integration.

web.xml

	webapp

	
contextConfigLocation
/WEB-INF/applicationContext-security.xml
	

org.springframework.web.context.ContextLoaderListener
	

	
		springSecurityFilterChain
		org.springframework.web.filter.DelegatingFilterProxy
	
	
		springSecurityFilterChain
		/*
	

	
		index.html
		index.jsp
	

Thats it, try it yourself!

Original article posted at: http://oudmaijer.com

Spring Framework 3.0 GA

Spring 3.0 GA is compatible with Java EE 6 final in terms of runtime environments now (e.g. on GlassFish v3 as released last week) and supports JPA 2.0 final already (e.g. using EclipseLink 2.0). We also support the newly introduced @ManagedBean (JSR-250 v1.1) annotation for component scanning now, which nicely complements our @Inject (JSR-330) support for annotation-driven dependency injection.

* Spring expression language (SpEL): a core expression parser for use in bean definitions, allowing for references to nested bean structures (e.g. properties of other beans) as well as to environmental data structures (e.g. system property values) through a common #{…} syntax in property values.

* Extended support for annotation-based components: now with the notion of configuration classes and annotated factory methods (as known from Spring JavaConfig). Spring also allows for injecting configuration values through @Value expressions now, referring to configuration settings via dynamic #{…} expressions or static ${…} placeholders.

* Powerful stereotype model: allows for creating ’shortcut’ annotations through the use of meta-annotations, e.g. for default scopes and default transactional characteristics on custom stereotypes. Imagine a custom @MyService annotation indicating @Service, @Scope(“request”) and @Transactional(readOnly=true) through a single annotation.

* Standardized dependency injection annotations: Spring 3.0 comes with full support for the JSR-330 specification for Dependency Injection in Java – annotation-driven injection via @Inject and its associated qualifier and provider model, as an alternative to Spring’s own @Autowired and co.

* Declarative model validation based on constraint annotations: Spring-style setup of a JSR-303 Bean Validation provider (such as Hibernate Validator 4.0). Comes with an annotation-driven validation option in Spring MVC, exposing a unified view on constraint violations through Spring’s binding result facility.

* Enhanced binding and annotation-driven formatting: Converter and Formatter SPIs as an alternative to standard PropertyEditors. Formatting may be driven by annotations in a style similar to JSR-303 constraints, e.g. using @DateTimeFormat. Also, check out the new mvc namespace for convenient setup of formatting and validation in Spring MVC.

* Comprehensive REST support: native REST capabilities in Spring MVC, such as REST-style request mappings, URI variable extraction through @PathVariable parameters, and view resolution driven by content negotiation. Client-side REST support is available in the form of a RestTemplate class.

* Rich native Portlet 2.0 support: Spring MVC fully supports Portlet 2.0 environments and Portlet 2.0’s new event and resource request model. Includes specialized mapping facilities for typical portlet request characteristics: @ActionMapping, @RenderMapping, @ResourceMapping, @EventMapping.

* Object/XML Mapping (OXM): as known from Spring Web Services, now in Spring Framework core. Marshalling and Unmarshaller abstractions with out-of-the-box support for JAXB 2, Castor, etc. Comes with integration options for XML payloads in Spring MVC and Spring JMS.

* Next-generation scheduling capabilities: new TaskScheduler and Trigger mechanisms with first-class cron support. Spring 3.0 comes with a convenient task namespace and also supports @Async and @Scheduled annotations now. This can be executed on top of native thread pools or server-managed thread pools.

Java EE 6

From Roberto Chinnici’s weblog:

With the closing of the final approval ballot earlier today, it is now official: the JCP Executive Committee has given a green light to the release of the Java EE 6 platform specification. The final release will happen on December 10, when GlassFish v3 will be available. For more details of the ballot, with comments from several EC members, please refer to the JCP web site. Of course the excitement of the event drove me to watch live the ballot close at midnight PT and tweet about it!

Several other Java EE component JSRs were approved at the same time: Servlet 3.0, JPA 2.0, EJB 3.1, Connector 1.6, CDI 1.0. All other components, be they full JSRs or maintenance releases (MRs, for insiders), had been previously approved. I should also mention here that, being part of the platform JSR (JSR-316) the Java EE 6 Web Profile too was approved, and so was the Managed Beans 1.0 specification I talked about in prior blog entries. So, yes, now we really have profiles in Java EE: let’s put them to good use!

We are going to have more white papers, tutorials, etc. coming up for the final release in a few days. In the meantime, even a casual perusal of the javadocs will show a number of new APIs in key areas: JAX-RS, Dependency Injection, CDI, Bean Validation. I see a bright future for these APIs, and fully expect them to become key components of Java EE applications in the coming years. I also happen to think that the level of integration that we achieved between these new APIs and some of the existing ones represents a valuable principle that can guide the evolution of Java EE going forward; certainly I expect future Java EE APIs to be held to the same strict criteria for integration with the rest of the platform that JAX-RS, Bean Validation and CDI were held to in this release.

Java EE 6 includes:

• Java Persistency API 2.0
• JavaServer Faces 2.0
• Enterprise JavaBeans 3.1
• Servlet 3.0
• Context and Dependecy Injection (a.k.a. WebBeans)
• Dependency Injection (@Inject)
• JAX-RS
• Web Profile
• and much more…

See also this article for more information: http://java.sun.com/developer/technicalArticles/JavaEE/JavaEE6Overview.html

So if you are bored during the christmas holiday, you can try out the new Java EE 6 features using GlassFish v3 and NetBeans 6.8. But also IntelliJ 9 and Eclipse 3.5.1 feature Java EE 6 support.

I`ve just finished watching the opening session which contained a lot of promotion for JavaFX. Sony talked about Java enabling interactive Blu-ray applications. Verizon anounced a partnership with Sun for  applications for their wireless network.

Larry Allison, CEO of Oracle, was the last guest speaker. He talked about how excited he was about the Oracle takeover of Sun and Java being the key platform for current and future Oracle (Fusion) products. He also mentioned that Sun and Oracle maybe hitting the mobile/nettop market and launching a Google Android alike platform.

I`ll be posting some JavaOne updates this week.

OSGi is The Dynamic Module System for Java[TM]. OSGi enables Java applications to become modulair and express dependencies on (versions of) other modules. Which means that your application no longer depend on the classloader (not) taking care of dependencies. There are a number of issues OSGi addresses, but I wont even bother writing them down here since Peter Kriens has an excellent blog post about those issues.

Java 7, and in particular JSR294, also tries to solve the modularisation problem. The expert group is working with the OSGi alliance to implement modularisation in Java, but they still have a long way to go. If you are interested in the progress of the expert group you can follow the JSR294 EG mailing list.

Below is a list of resources about OSGi:

• http://www.infoq.com/presentations/osgi-the-foundation
• http://www.infoq.com/presentations/colyer-server-side-osgi
• http://www.infoq.com/presentations/dm-Server-Rod-Johnson
• http://www.osgi.org/blog/2008_12_01_archive.html
• http://www.theserverside.com/tt/articles/article.tss?l=MigratingPathToOSGi

Now you know!

De overname van Sun door Oracle levert wel een aantal interessante vraagstukken op, wat gaat Oracle bijvoorbeeld doen met Java? Op dit moment is er nogal wat onenigheid over het Java Community Proces (JCP), het standardisatie proces voor Java. Velen hopen dat Oracle de JCP nu echt open zal maken. Anderen zeggen dat er geen sprake van een inspraak proces is. Aan de andere kant, misschien is het wel niet in het belang van Oracle om Java nog opener te maken om het zodoende concurrent IBM lastiger te maken?

Verder zijn er nog NetBeans en  GlassFish? Aangezien Oracle BEA heeft overgenomen, bekend van o.a. de applicatie server WebLogic, is er bij Oracle een overschot aan applicatie servers ontstaan. Zelfde geldt voor ontwikkelomgeving NetBeans vs JDeveloper, zullen beide naast elkaar blijven bestaan of worden ze samengevoegd?

Daarnaast is Oracle plotsklaps eigenaar geworden van MySQL, door velen gezien als het open source alternatief voor Oracle. Moeten we ons nu gaan verdiepen in PostgreSQL?

Voor het orginele persbericht zie: http://www.oracle.com/corporate/press/2009_april/018363.htm

IBM onderhandelt met Sun Microsystems over een overname. Big Blue zou 6,5 miljard dollar voor Sun op tafel willen leggen en met de overname zijn positie op de internet-, software- en telecommunicatiemarkt willen versterken.

De twee Amerikaanse bedrijven zouden deze week al tot een overeenkomst kunnen komen, meldt The Wall Street Journal. De krant weet echter ook te melden dat er nog niets is beslist en dat de onderhandelingen ook zonder succes afgebroken kunnen worden. Sun heeft moeite om winst te maken en zou al meerdere bedrijven over een acquisitie gepolst hebben, maar tot nu toe zonder succes: onder andere HP zou Sun al de deur hebben gewezen. Voor IBM zou het de grootste overname in zijn geschiedenis zijn. Vorig jaar betaalde het computerbedrijf 5 miljard dollar om het in business intelligence gespecialiseerde Cognos in te lijven.

Met Sun in de gelederen zou IBM zijn omzet voor bijna een derde uit hardware halen, waar het zich de afgelopen jaren juist meer op software en diensten richtte. Verder hebben de multinationals een nogal verschillende bedrijfscultuur: het in 1982 opgerichte Sun richt zich vooral op innovatie, terwijl het uit 1911 stammende International Business Machines zich met name op de vraag in de markt oriënteert. Aan de andere kant zijn er de nodige overeenkomsten: de band met Microsoft en Intel is bij beide bedrijven niet sterk en zowel IBM als Sun leunen zwaar op Linux en Java.

Bron: http://tweakers.net/nieuws/59083/ibm-wil-sun-microsystems-overnemen.html